Problems with the "hello world" example, payload not sent properly?


#1

Hello,

i managed to program the “hello world” example. The onethinx module joins my LNS without any problems, but regarding the payload there is something strange to me:
I’ve the payload to
TXbuffer[j++] = 0x00
But at my LNS I receive
first uplink message after receiving the join accept: “/Q==” which is 0xFD
second uplink message: “mQ==” which is 0x99
third uplink message: “hg==” which is 0x86
and so on

so the 0x00 that I’ve into the TXbuffer never arrives.
What is my thinking error here?

Perhaps someone has the same problem or maybe someone could help me…

kind regards
Philipp


#2

Hi Phillipp,

It seems you are reading the payload received by gateway instead of reading the decrypted payload from the application server.

If this is the case you should see different payload on each transmission (even if the device’s payload is the same).

Which provider are you using and where do you get the payload from?

Thanks!
Rolf


#3

Hi Rolf,

I’m using the “loraserver” from loraserver.io (this is a private operated LNS). I’ve tested several devices and I’ve never had that kind of problem. Here is a json-excerpt of the received uplink-Frame after join-accept:
“phyPayload”: {
“mhdr”: {
“mType”: “UnconfirmedDataUp”,
“major”: “LoRaWANR1”
},
“macPayload”: {
“fhdr”: {
“devAddr”: “xxxxxxxx”,
“fCtrl”: {
“adr”: false,
“adrAckReq”: false,
“ack”: false,
“fPending”: false,
“classB”: false
},
“fCnt”: 0,
“fOpts”: null
},
“fPort”: 10,
“frmPayload”: [
{
“bytes”: “YA==”
}
]

under “frmPayload” you can find the decrypted payload as base64-string. Does your LoraWan-Stack encode the payload in some kind or will it send the payload as given to the “LoRaWAN_Send” function? I’m passing 0x00 to the function and I’m expecting that this will be receipt by the LNS.

kind regards,
Philipp


#4

Hi Philipp,

The payload isn’t encoded in any way, it’s just encrypted with the AppSessionKey as per LoRaWAN 1.0.2 spec. The fact that you see different payload each transmission points to an incorrect AppSessionKey.

We didn’t test with private network settings and Port != 1 yet.

Did you set the OTAAkeys.PublicNetwork to false?


#5

Hi Rolf,

thank you for your reply - I’ve made a stupid mistake and looked at the encrypted payload - the payload is sent as expected. Sorry for bothering you.

kind regards,
Philipp


#6

Hi Philipp,

Good to know it’s working as expected and thank you for the feedback!

Rolf