Note for TTN/TTI it should be 26xx xx xx or 27 xx xx xx is (as apears from above) it is 00 xx xx xx or 01 xx xx xx this is for experimental nodes with no network association - you should see the traffic in GW traffic page with the exp node addr but data wont be forwarded to a TTN app. I use these types of devices where I want to quickly test GW coverage and dont want to bother setting up a full app…if I see the message with the target node DevAddr I know its in range, job done 
2 Likes
Thanks @Jeff-UK, So really to configure a device to be compatible with the TTN network I need to change the Dev Addr to one assigned to me by TTN when registering a device?
Ok got a response from the manufacture.
We always configure with OTAA (by default).
Lora settings can be changed sending downlink to the server, and the server will changed.
Will re-setup for OTAA, any one have any idea what is meant by:
sending downlink to the server, and the server will changed
Would this configuration be possible as part of the join process? I read the quick start guide for adding a device but its not clear what happens after you receive the join requests.
So my guess at the moment is that the additional settings I got on the spread sheet are just dummy settings to help get me the device EUI and some of the keys?
thanks,
Richard.
For ABP yes, you use the one that is generated by TTN when you setup or change to ABP
By some magic they are expecting you to know what characters to type in to the device page to send a message (downlink) to the device to configure it. Or does it come with an app (desktop or mobile) or webpage or something?
So what does the gateway’s Traffic page show in TTN Console? Sometimes it shows nothing, or only shows uplinks but no downlinks, all due to being unreliable. So, until you see some Traffic you may need to rely on what the Device’s Status and its Data page show you:
But if the gateway’s Traffic does show traffic, then that helps a lot: if it shows a Join Request (orange icon) while the device’s Status or DevAddr do not change, then you know that the configuration is wrong. You can validate the AppEUI and DevEUI as sent by the device from the Traffic page, so if those are okay then only the AppKey may be wrong. If it shows no Join Request, then the device is probably not sending one, or is out of reach. If it shows the Join Request and a Join Accept, then the device probably has not received that accept downlink.
Thanks @descartes going to go with OTAA for now.
No mobile app for the device but I do have optical serial connection to the device for setup and reading and I have also the LoRoWan documentation which describes what communication is possible with the device but not seen any options as yet to set the LoRoWan settings, have asked for clarification from manufacture.
Thanks @arjanvanb, I did not have any traffic this morning but after forcing the device to send again I got the following join request.
Have confirmed that the Dev EUI and the App EUI are correct. I then checked the AppKey and it was still the default one assigned by TTN when setup. I have now changed that and will try and force another request from the device.
1 Like
Aside: DevEUI and AppEUI (and DevAddr) are not secret. Lucky you, as they’re still visible in the non-encrypted parts of the Physical Payload in your screen capture. You can see in an online decoder, and anyone could grab that payload from the air, in your neighbourhood. 
Things like AppKey, AppSKey and NwkSKey are secret. And the application payload of a data uplink is encrypted.
Another aside, I don’t really like that AppEUI, as that’s clearly not registered by the manufacturer (unless it’s a copier or printer). Probably not a problem, but I’d not buy thousands of those if they use an AppEUI like that. (In fact, I feel each off-the-shelf device should have a unique AppEUI, but I guess I’m the only one.) Strangely, it seems they did properly register the DevEUI.
1 Like
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!
1 Like
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:
1 Like
…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.
2 Likes
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!
1 Like
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… 
1 Like
I think the AES Key field in configuration window is for WirelessMBus encryption only, not for LoRaWAN.