This might be a noob question, but i hope there is somebody here who can help me out.I have been trying for significant time now to get a lora network up and running.
The Gateway
The gateway i am using is Multitech conduit AEP with firmware 1.4.16.
I managed to install the packet forwarder of TTN and i also see the gateway online on the console (gateway).
The Node
I don’t have a lot information about the node. I didn’t construct is by my self but got it from a friend.
The node is supposed to measure vibration in 3 axis, and temperature.
The information that i got from the node are:
DevEUI
AppEUI
AppKey
In the console, I have created an Application and also registered the device with that information. Unfortunately, the devices have so far never been online on the TTN platform.
Whenever I check the gateway side, I see that the gateway has received over 200 messages and the timestamps coincide with the times that i turn on the Node.
First Challenge
The problem i am right now having is that the node have never been online on the Application side, but on the gateway side i can see them sending some payload. How do i get the data to show up on the Application side?
Second Challenge
I am also a newbie when it comes to decoding the payload, How can i decode the payload without knowing how the original data structure looks like? The only thing I have is the decoded payload
I know i am asking for a lot, but i would definitely appreciate all the help i can get. Can you please let me know what data and/or screenshot you might need so we can get to the right solution?
If you don’t have a brand or type, maybe you can try scan the QR code on the PCB or look for text or markings.
Or maybe another user recognise this… I don’t
Thanks BoRRoZ. I didn’t know that t was this hard to get a Node register. I always thought that it didn’t matter what type of the board was as long it has the LoraWan chip onboard, it would communicate.
I Still think that this is the case, because i still see the data coming in at the gateway console.
and i also see what the payload is on the Gateway Console side, but not on the application side.
So the question still remains, what am i doing wrong?
You are seeing join requests at the gateway, as the application does not show any activity one of the EUIs or the key on the device probably does not match the values you entered in the console.
I always thought that it wouldn’t matter was registered on another network. It would always be possible to register the node on any other network. The strength of the openess
If it was previously registered on another network, then TTN should accept it. One cannot register an ABP device with hardcoded keys from another network (DevAddr, AppSKey and NwkSKey). But your device is using OTAA (DevEUI, AppEUI and AppKey), and that should be fine. All is not lost yet.
Do NOT ask your friend to delete anything at this point.
However, in that case, I’d assume you would see errors when trying to register the device with the same DevEUI, AppEUI and AppKey, which you did not mention, so that’s probably not the case.
If your friend used it on another network then TTN should (also) accept it. If your friend did not delete it from the other network yet, then if both networks receive the OTAA Join Request (orange icon in TTN Console), then both could transmit an OTAA Join Accept (green icon). Next, the node would receive the strongest signal (possibly the wrong network; the node would stop joining), or none at all (collisions, after which the node would try again). However, you don’t see that Join Accept in the gateway’s Traffic page at all.
As for not seeing the Join Accept:
The OTAA Join Request is not encrypted (the AppEUI and DevEUI are not a secret). So, in the gateway’s Trafic page you can see the AppEUI and DevEUI that the device sends. (The values you see in that Traffic page are not the ones you registered in TTN Console, but the ones sent by the device. Of course, these should match.) Check and double-check those values, again. And, again!
Clicking an item in TTN Console’s gateway Traffic page reveals more information, which may include some hints. What do you see there?
Any chance the Join Request is received by multiple TTN gateways, and another TTN gateway has a better reception, hence is selected by TTN to transmit the Join Accept? In that case, you should still see the Join Request (orange icon) in the application’s Data page as well, which then also shows a DevAddr, even if the device somehow does not actually receive the Join Accept at all. So, do you see anything in the application/device’s Data page?
Note that seeing a Join Accept only proves that the AppEUI and DevEUI are correct. If the AppKey were wrong, TTN would still send the Join Accept based on that wrong AppKey, which the device could not properly decrypt when the AppKey does not match. But for now, that’s not your problem; you first need to see TTN accept the join.
Unless it’s a really short message which allows for trial and error, in general you cannot. The EUIs are registered to to OnYield Inc Ltd, so it might be an OY1400 LoRaWAN Industrial communication and control unit. But of course, your friend used it, so must have some information too? Also, that would be a different topic.
If the AppKey does not match between end-device and network server, the MIC of the Join Request is invalid and a Join Accept should not be sent to the end-device.
Do NOT ask your friend to delete anything at this point.