I finally managed to get my gateway connected and also connect/reuse an old node. I am now trying to write a decoder to get useful data out of the payload. The sensor that i current have connect to the application is a temperature sensor with channels. It actually measure 2 temperature at the same time and sends out the data either after 1 hour or after clicking the button.
The change that i am currently facing is that i have noticed that there are 2 payloads:
The application view,
The gateway view
The issue is that the payload shown in instance 1, doesn’t change when the temperature changes, but the payload in instance 2 does change when the temperature changes. That is why i am assuming that the payload shown in instance 2 (gateway view) is the right payload.
Can somebody perhaps explain what the difference is between the two payloads and why they are so different from each other?
The second Challenge I am facing is that I don’t know how the temperature is computed, meaning i don’t know in which byte (or combination of bytes) the temperature is in. I am now trying to figure out, by trial and error (recomputing known temperatures, like body temperature), which byte(s) are showing the known temperature.
Does anybody know a more effective and efficient way? All the help is much appreciate it.
First, I’d call neither the physical payload. To me, that would be the LoRa radio chirps that transfer the LoRa packet through air, which includes details such as a sync word, an additional header, the error correction coding rate, additional data for that error correction and a CRC, none of which you’ll see in either screenshot. So I’d say that the title “Physical Payload” is confusing.
That said, the payload in the application’s Data page is what you’re after. TTN has already decrypted that for you, and if it’s not changing, then your node’s code is wrong or the sensor is broken.
The payload in the gateway’s Traffic page is the full LoRaWAN packet, which is your encrypted application payload plus some LoRaWAN housekeeping. It’s indeed changing as it includes a frame counter that is incremented for each uplink. That frame counter is also used in the encryption of the application payload and the message integrity code (MIC). So, you’ll see that almost the full message changes when the counter is incremented, even when the (decrypted) application payload is the same. If you’re in for it, you can validate by pasting a few payloads into an online converter.
I hope that’s enough terminology to get you started in searching the documentation.
To decode the temperature you’ll have to start by looking at the code that sends it, but that would be a totally different topic. You should certainly not look at the gateway’s Traffic page, as there, in the full LoRaWAN packet, the application payload is still encrypted so is of no use.
Thank you very much. This helps a lot. And it indeed seems that the problem has to do with the hardware. I am right now trying to figure out where the problem exactly is.
I will try to fix my hardware and once i have figured out what the exact problem is I will report back.
