I have a WIO-E5 module. When I monitor the node on TTN I consistently am receiving
I have verified DevEUI and APPKEY. I have also verified that both firmware and node registered are using 1.0.3. I have even changed APPKEY and updated on FW as prior topics seemed to suggest that could be an issue. The gateway (on TTN) shows join packets coming in with the correct DevEUI.
I am thinking I am doing something incorrect in firmware. Initially I tested this with some github repo code and I was able to make a connection and join the network but alas that code seemed to have issues as I built out my pinout. I then just went back to STM32CubeIDE and started a new project.
The UART debug shows the following:
Can anyone point me in a direction as to what I may be missing in my firmware?
If the join requests show in the application the JoinEUI and DevEUI match. The AppKey is the likely culprit. Make sure not to reverse the byte order for it.
thank you for the response.
I am pretty confident that byte order is not it as I just copy from TTN and paste into code and it worked like that before. Just for grins I swapped the byte order (not bit order) and it still doesn’t work (same message). I really think I am missing something in FW but other than knowing the Lorawan basics on join request/accept and how the appkey is used to authenticate a payload and header I don’t have any idea in code where to look.
Not to muddy the waters but maybe to give insight: The issue with the github code I mentioned earlier (the stuff that wasn’t working well) was TTN got the request successfully then sent out an accept but the firmware wouldn’t handle it correctly (I don’t even know what that means …should it have written it to flash, or what…) Anyway long story short I found that by decommissioning one of the I/O’s (which by all accounts of datasheet, CubeIDE I should have been able to use) TTN would take and register the device. This lead me down the path of some timing issue in the github firmware which lead me to just start from scratch…
Just in case you tried the standard CubeMX for STM32WL config - you need to start from the Seeed variation because they decided to use different pin configurations …
PS, UART output = text = CopyNPasta ≠ ScreenShot please.
So I have been at this for days and I think I have found out the issue.
It appears at this point that TTN requires (using 1.0.3) the AppKey AND NwkKey to be the same on the firmware. If I changed the NwkKey to something else I continually get MIC Mismatch.
My understanding (limited as it is on the subject) was that I only needed to make DevEUI, JoinEUI and AppKey = to the firmware…I didn’t think NwkKey was needed??
Long story short is I am now transmitting successfully.
Oh fooey, apologies, that’s actually a known gotcha for LoRaMac-node that’s not specific to TTN.
Many other stacks (not that there are a lot) just use the AppKey to get setup. Newer versions that are not generally in the wild of LW 1.1 use both keys. I suspect there may have been some cross-over that required LMn to have both keys set the same. They are only used at join, after that they use the derived keys they get from the LNS.
My LMn code base automagically propagates the AppKey in to the NwkKey and in my defence, I did that about two years ago & I’ve slept since. I shall add it to the trouble shooting list.