After successful installation of a TTN Gateway based on Raspberry Pi and IMST IC880A some weeks ago in my home (i’ve already seen it forwarding data from other people’s devices into TTN), I tried to build an STM32 based node to play around with.
Unfortunately, I can’t get my node to join the application. Now I’m looking for ways to debug the join process to get a clue WHY it’s not working…
The Node is an STM32 NUCLEO-L053R8 board with the SX1272 MB2xAS board on top. I used ST’s I-CUBE-LRWAN example project for this first test.
To play with it, I set up an application in TTN console, registered the device’s EUI (retrieved from the debugging output of the ST example program) and set the LORAWAN_JOIN_EUI and LORAWAN_APP_KEY constants in Commissioning.h of the STM code according to the data provided by the TTN console for my device and also enabled OTAA.
So far so good, When I turn on the Node, I can see the Join Requests coming in via my own TTN Gateway’s Traffic Monitor page in TTN console. The APP EUI and Device EUI are correct, too.
BUT… I don’t see any mention of that Join Request in the data monitor pages of the application and device inside TTN Console.
From what I could find in various posts here and elsewhere, this would most likely happen due to invalid Join requests. Unfortunately, there is no useful feedback from the TTN console about whether there is something strange with a Join request or if it is forwarded towards an application.
I double-checked the AppKey is configured correctly in my STM32 firmware, also the App EUI of the incoming Join Requests displayed in my gateway’s Traffic Monitor in TTN console shows the correct Value. But no information bout that Join Request pops up inside the application console.
Maybe someone can give me a hint where I can find some more useful debug information about the Join Requests in TTN Console or documnetation on how to interpret the “payload” field content of the “Event Data” JSON in the Traffic Monitor? Is there some utility to decode the payload, knowing the App_Key?
I’ve spend an entire day on this without making any progress so far and maybe I’m just missing some detail?
You can validate the MIC of a full LoRaWAN OTAA Join Request (as seen in the gateway’s Traffic page) using this online decoder; set a dummy value for NwkSKey (e.g., 00; it’s not used), and paste your AppKey as known in TTN Console as the AppSKey.
Any chance this is a LoRaWAN 1.1 device, and hence is using an incremental value for the DevNonce? If yes, aren’t you seeing OTAA shows "Activation DevNonce not valid: already used"? Also, do you still see “Status: not seen” for the device? (If not, then the Join Request was accepted at least once.)
(Aside: in the Data page in TTN Console you won’t ever see a Join Request, but an “Activation”. Just like a Join Request in the gateway’s Traffic page, it has an orange icon.)
The online decoder you linked helped me find out the packet MIC is invalid indeed.
Now that you ask, I recognize I’m not actually sure about what LoraWAN Spec. Version the library is actually implementing. It says 1.0.3 in their release notes, but they also mention 1.1 inside the header file. I haven’t seen a “Activation DevNonce not valid” message so far. But since the MIC seems to be invalid, I guess the Nonce inside the MAC Payload is not evaluated at all
Thank you for your hints! I guess I have to spend some more time with understanding how that STM library actually works and also stick my nose a bit deeper into the LoraWAN specifications
So my question for now, regarding debugging possibilites, is definitely answered! Thanks!
A 1.1.x Join Request is compatible with 1.0.x (though using different terminology, and though using an incremental DevNonce). When the device receives the Join Accept, it will know that it actually joined to a 1.0.x network, and will use 1.0.x for subsequent operations.
But the DevNonce is given in the non-encrypted Join Request, so calculation of the MIC should be fine regardless how the DevNonce was generated by the device. That is: if the DevEUI, AppEUI and secret AppKey match.
Are you really sure that the AppKey in TTN Console matches the one in the device? Curious: what values do you see for the DevNonce?
Even i am stuck with stm32f103 blue pill. i am using Arduino IDE and MCCI CATINA LIBRARY. the gateway is all good but stm32 in OTAA doesnt work. make request but cant even send HELLO WORLD.
Yes, I am definitevely sure they match. I checked the C source code and serial debug output of the STM board, it also outputs the very same DevEUI, AppEUI and AppKey values as configured for the device in TTN console. The DevNonce seems to be a random 16bit value, no incrementing counter.
After examining the I-CUBE-LRWAN library and adding some more PRINTF()s towards the serial debug output, I finally managed to get a step further.
The ComputeCmac() function is called with keyID = NWK_KEY which made no sense to me, since the STM can’t know the Network key before the Join? So I changed it to keyID = APP_KEY (in LoRaMacCrypto.c, inside function LoRaMacCryptoPrepareJoinRequest()). Now the MIC is correct, my Join Request is forwarded to the Application and I can see the outgoing Join Accept message in the Gateway Traffic log in TTN console.
Are there other users out there using the combination
STM32 NUCLEO-L053R8
Semtech LoRa board SX1272MB2xAS
ST I-CUBE-LRWAN library v1.3.1
and see a similiar problem? I mean, changing Key type settings inside a library C file to achieve basic functionality seems a bit odd to me. Either the library is not tested before release or I missed some detail in setting up the project configuration. Also, does anyone know where to get older versions of these ST libraries? They only seem to host the most recent version behind their login-wall on the ST website.
Thank you for your commitment, @arjanvanb - searching through the forum, I see you being active a lot here
