Thanks @arjanvanb nice tool, unfortunately, if I am using the tool correctly, I tried to test with my keys to see if I could get a decoded message and it just came up with fail, as below.
Interestingly through after resetting up and manually setting all the keys etc through the cli I now have a green dot but still “never seen”
Any idea what that means, if anything?
I hope the decoder did not make you doubt your settings. What keys did you use?
The session keys AppSKey and NwkSKey (and the DevAddr) are (re-)generated whenever an OTAA Join Accept is accepted, so are not known yet at the time of an OTAA Join Request. So, for an OTAA Join Request, you need(ed) to enter the AppKey in the AppSKey field, and enter dummy data in the NwkSKey. I’ve just added a bit more documentation about that, and made NwkSKey optional.
The screenshot now showing a DevAddr implies that at least one Join Request was successful, but then I’d also expect to see a timestamp for Status. Maybe I’m wrong and maybe for a first join that’s only set after a regular data uplink. Or maybe it’s a leftover of earlier tries with ABP for the same device?
If you’re still in doubt if the settings are okay then I’d delete the device and add it again. OTAA seems to work just fine for you.
For a regular uplink you may also want to use the online decoder, to check if FCtrl.ADR is set: your OTAA join uses the worst possible data rate, DR0 a.k.a. SF12 BW125, and it would be great if TTN can use ADR to tell the device to use better settings.
Thanks @arjanvanb I used the keys supplied from the manufacture.
Ahh ok as I have not received a join request into the device within TTN yet I have not seen this step/process. Can you point me to the documentation for this as I have not found that or missed it, sorry.
No don’t think its been successful yet I added them through the TTN CLI 
, wont do it again on OTAA, have deleted the device again and re-added as OTAA as per:
https://www.thethingsnetwork.org/docs/devices/registration.html
Now waiting for another join request to come through to see if it hits the device on TTN.
If the TTN documentation is not sufficient comprehensive, then see the LoRaWAN Academy, and the Semtech LoRa Developer Portal’s LoRa library. And of course, it’s in the LoRaWAN specification.
Beware that if the device did in fact receive the OTAA Join Accept, it will no longer try another join. Instead, it will be sending data uplinks, but using a DevAddr and secrets that are no longer known to TTN. So, keep an eye on that gateway Traffic page!
Thanks @arjanvanb have not read it all yet, but just a quick update, still not working 
I just got a join request coming through the gateway as below.
but its not hitting the registered device on the TTN network as below.
Am I right in saying that if the join request was getting through to the device on the TTN network that I should see a join and acknowledgement sequence on the data tab for the device as below?
The issue must be down to rooting and how the request is being picked up by TTN?
Yes, if the configuration of device and TTN match, then you should see an Activation (orange icon) in the application and device’s Data page, if you have that open at the time the Join Request is received. And even if not open, you should see a DevAddr on the device’s Overview page after an accepted Join Request.
From the screenshots, it seems the AppEUI and DevEUI are correct. You can use the online decoder with the AppKey to see if the AppKey is correct too (leave the field for NwkSKey empty); probably not. You may want to reverse the bytes in the key (say, from 01 02 03 ... 15 16 to 16 15 ... 03 02 01) to see if that helps in that online decoder. And if not, use some of the other values that the supplier gave you? It would not be the first time a supplier messed up the keys:
…and from the same topic quoted above, for another device than yours:
Anyway, you can use the online decoder to check; you know that the gateway is receiving the Join Requests, so for troubleshooting there is no need to wait for another Join Request to be sent by the device. Just ensure that the online decoder shows that the MIC is valid and then you know which value for the AppKey to configure in TTN Console.
Thanks for sticking with me @arjanvanb.
Ok, to be supper clear, if I understand correctly I have used the decoder to and copied in the payload from the join request.
I then pasted in all the keys I have into the “Secret AppKey or AppSKey” field and you would expect one of them to NOT to say “Invalid” on the MAC line… unfortunately they all did
Could the two possibilities be that I have the wrong KEY’s or could it be that the device is just not sending right. I then checked out the interface for the device and I see an option for AES key? as below.
I am trying to get more information from the supplier on this but in the mean time I am going to try and set the AES value and see what happens.
Thanks,
Richard.
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…
Still: OTAA Join first!
Yep, reversed all the keys I have had still nothing valid. Going to go back to manufacture and clarify the Appkey for the device.
Its the configuration utility for the device few more screens below.
Thanks again.
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.
There is an “Info window” which just shows the communication with the device but no debug of what the device is doing as far as I can tell.
We do have the following doc on the payload.
Axioma_Lora_Payload_E3_2V00_Extended.pdf (317.2 KB)
@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… 
I think the AES Key field in configuration window is for WirelessMBus encryption only, not for LoRaWAN.
Your configuration software does not include LoRa part, try to use the Android App with a NFC smartphone.
Thanks @nestorayuso I have removed the AES key field and have been able to get another join request coming through my gateway as below.
And I have the device setup for OTAA and manually set the App Key to one provided by manufacture.
but still the join request has not reached the device setup on the TTN network!
I emailed axioma.eu to confirm the keys I have for the device and they say they are correct! 
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.)
Also, @nestorayuso and @duricai, just in case the AppKey is the same for all devices: could you try using yours for @YouGenerate’s packet in the online decoder…?
And curious: do your devices also use the non-EUI AppEUI 0000000000000709?
Aside: note that the DevNonce is still increasing, 0x0096 (decimal 150) for that last one.
Found this recently for anyone needing a e3 or E4 axioma js decoder:
