Hi!
I’ve attached a screenshot of the packets I’m receiving on my gateway [RPi2 + IMST iC880a] from a SODAQ One v2 as node.
Can anyone help me decode this payload?
Hi!
I’ve attached a screenshot of the packets I’m receiving on my gateway [RPi2 + IMST iC880a] from a SODAQ One v2 as node.
Can anyone help me decode this payload?
It’s a bit hard to copy text from a screenshot , but:
In TTN Console, the Gateway’s Traffic page should already show some non-encrypted details.
Also in TTN Console, the Application’s Data page should show all details, unless you’ve got a private handler in which case TTN won’t know the secret keys.
https://github.com/anthonykirby/lora-packet might help you get started; see also the online version at https://runkit.io/avbentem/lorawan-packet-decoder/branches/master which will show you the same details as the Gateway’s Traffic page. I’d try to paste the long hexadecimal values with the dashes removed (for one of the CRC_OK
lines). Like maybe 00c15e00f07ed5b37052ef1b000ba304002c4a0fb39bac if I did not make an error typing that…
Thanks a lot, @arjanvanb.
I have seen the packet on the TTN console but I was wondering why it is different from the one in the logger on my gateway .
Yes, thank you!
You got that right! Also, how come there is no other information there? For example, the exact payload viz., “SODAQ”. Is this encrypted? Am I missing something?
The payload can only be decrypted if one knows the application’s secret session key (the AppSKey that you can see in TTN Console). The Github library supports providing that secret, but the online version does not provide an input for that. (And obviously does not know the secrets.)
The message is really binary; the very same message can be logged in a readable format in many ways, such as hexadecimal or Base64, or even just as binary ones and zeroes… Your gateway’s logger apparently formats the data as hexadecimal with dashes after each 4 bytes.
As an aside: it seems the Join Request is sent many times, with exactly the same message? That would imply that the DevNonce
is always the same. TTN will accept each value only once. (But you should see an error message in TTN Console for that.)
Ah, the exact same message is only sent 2 or 3 times each try. That might be okay; I’m not sure.
Right, thank you.
Yes, I was sending the join request every few seconds since there were authentication issues. The request would not get accepted. Now I’ve fixed that, though.
What exactly does "value " mean here? Is it the raw payload like “SODAQ”?
@arjanvanbI I followed this site https://lorawan-packet-decoder-0ta6puiniaut.runkit.sh/ to decode the lora packet(“gCsvASaAAAAB0em2Ey6TBps6S/hSVRva”) but maybe it’s wrong.
To decode LoRaWAN packets, you need the full packet. In TTN Console, the device’s Data page only shows the application payload, not the full packet. So, you’ll need to look at the gateway’s logs, or its Traffic page in TTN Console for the full packet. For an uplink, that probably starts with 40
, or 80
for a confirmed uplink.
So indeed, your http://runkit.io/avbentem/lorawan-packet-decoder/branches/master?data=gCsvASaAAAAB0em2Ey6TBps6S/hSVRva should be okay, but as that decodes to an application payload of D1E9B6132E93069B3A4BF8
I assume you’re looking at a different uplink.
Note that the online decoder also shows a different DevAddr. If you copy the OTAA NwkSKey and AppSKey from TTN Console into the decoder you’ll you might also see that they don’t match the message you’re trying to decode.