Yes, you did right and understood correctly. (Working example.)
Did you also try to revert the byte order of the values your tried in the âSecret AppKey or AppSKeyâ field?
I think itâs really about the device using an AppKey that you do not know. (Bugs aside, really all that can cause a different MIC for an OTAA Join Request is a different AppKey; the other data needed to calculate/verify the MIC are taken from the message itself.)
But what is that programming interface youâre showing there? Any other screens in that application?
As for the AES option: Iâve no idea. Maybe the device allows for additional encryption of the application payload. The application payloads of data uplinks and downlinks are already encrypted (using the AppSKey as derived during OTAA). But in LoRaWAN 1.0.x the application server and network server are not 100% separated, so some feel they need more. (I donât.) Or maybe itâs for non-LoRaWAN operation?
Heads up: the DevNonce, which is also in the Join Request, was hexadecimal 0x008E (decimal 142) for the last message, and 0x0087 in your earlier try. Given only those 2 values, it may be an increasing number, not a random number like LoRaWAN 1.0.x specified. That is not a problem at all, but beware that TTN will remember all DevNonces that the device once used. So, if it ever somehow resets to some factory state and then uses the same sequence of DevNonces, youâll see OTAA shows "Activation DevNonce not valid: already used". (Workaround in that same topic.)
Also, that sequential DevNonce may suggest itâs a LoRaWAN 1.1.x device. That should be backwards compatible with 1.0.x: the Join Request is the same, and given the Join Accept response the device should understand that the server is on 1.0.x, and fall back to 1.0.x. So, Iâm not expecting trouble there, but bewareâŚ
Any chance that also allows you to see some debug logging of the device?
While getting in touch with the supplier, you may also want to ask for the payload format documentation (or even a decoder), which other users of that device have not provided in Axioma QALCOSONIC E3 with OTAA. Aside, in that same topic someone writes:
I donât think that would change the OTAA Join Request message, hence I donât think that applies to you.
@nestorayuso and @duricai just trying to connect a QALCOSONIC E3 to TTN as above do you have any feedback on settings etc⌠How did you get the AppKey? Thanks
Interesting, not related to your OTAA problems, but:
7. Lora ACKAdrReq management
Default data transmission period on our devices are 6 hours, so it means that it is 4 times per day. In order to guarantee the connection with the server ACKAdrReq bit is set every 8th telegram, and the delay for the ACK to get is 4 telegrams. After this, SF is reduced by 1. It is possible to change after how many telegrams ACKAdrReq bit is selected using downlink command which is described in chapter 5.
Assuming they mean ADRACKReq, not ACKAdrReq:
LoRaWAN 1.0.x defines fixed values; ADR_ACK_LIMIT is 64, and ADR_ACK_DELAY is 32. I guess TTN will respond to an impatient device that sends an early ADRACKReq, but there is no guarantee that TTN (or any network) will respond within only 4 uplinks. Even more, unless the device is using the worst possible data rate (DR0, SF12 for most regions), TTN needs about 20 uplinks to even calculate optimized network settings:
To determine the optimal data rate, the network needs some measurements (uplink messages). Currently TTN takes the 20 most recent uplinks, starting at the moment the ADR bit is set. These measurements contains the frame counter, signal-to-noise ratio (SNR) and number of gateways that received each uplink.
The code is open source, so if things go south maybe one can check what happens when fewer than 20 uplinks have been received.
The good thing: at least we now know the device supports ADR, so will hopefully move from SF12 (that it uses for the OTAA join) to a much better data rate. On the other hand: if TTN takes more than 4 uplinks to respond, then the device may actually choose a worse data rateâŚ
Another heads up, as the device seems to use wall clock time: the TTN community network is currently running V2, which uses LoRaWAN 1.0.2. This does not support DeviceTimeReq and TTN will silently drop uplinks that request that. Your manual does not mention this command, so hopefully it has other means to determine the time. Also, hopefully not all devices transmit simultaniouslyâŚ
Thanks @nestorayuso Yeah have looked at that option but unfortunately I donât have an Android phone. Considering getting one just for this! Can you confirm that the Android App will also show the LoRoWan Keys etc⌠as this would be useful for future setups.
No, they are not. Send them the Join Request you captured from the gateway and ask them to validate the MIC⌠You/they should be able to validate the MIC for any Join Request, old or new, using the proper secret AppKey (using the DevEUI, AppEUI and DevNonce as given in the very same Join Request packet).
(Note that if you look at a decoded Join Request, there really is not much in that packet except for the message type, DevEUI, AppEUI, DevNonce and the calculated MIC.)
(Working example.)
