Problem with delivering messages from gateway to applicaton

End Devices (Nodes)
1

I write software for sensor sending data through TTN. It uses GitHub - beegee-tokyo/SX126x-Arduino: Arduino library to use Semtech SX126x LoRa chips and modules to communicate. It joins via OTAA and it works as expected. Network and application session keys are persisted and after few device restarts messages are no longer being delivered to an application.

Device is in lab, near to gateway I manage. I can see uplink message in gateway console but it does not show in application live data.

When I force OTAA on sensor then it start working again, until few restarts later.

End device in application is configured as follow:

  • Frequency plan: Europe 863-870 MHz (SF9 for RX2 - recommended)
  • LoRaWAN version LoRaWAN Specification 1.0.2
  • Regional Parameters version RP001 Regional Parameters 1.0.2 revision B

When I browse message details in gateway console I see that all messages are using (I think) correct frequencies (868.1, 868.3 & 868.5). End device has default Network layer settings. I also use defaults in SX126x-Arduino library.

I have verified that Network Session Key and Application Session Key are persisted correctly (so library uses them) - and since message is seen in gateway console that mean NSK is correct, right?

How I can debug this issue? Any hints?

2

A joined device in EU868 should use 8 frequencies, not just 3.

There is a whole lot more you need to persist. The frequencies you receive when joining, the frame counters (up and down), spreading factor and transmission power amongst them.

Start by checking the counter values. If they reset messages are considered a replay attack.

3

There’s a whole pile of missing detail and a few assumptions about what’s going on.

So check out the https://www.thethingsnetwork.org/docs/lorawan/ to cover, for instance, when & where the keys are used - hint, NSK being correct is not a requirement for appearing in the gateway console.

As for missing details, there’s an implication that you are restarting the device with some but not all of the session persisted. What is the device and why is it being restarted?

It’s always useful if you can say what you are trying to achieve, as there may be something in the mix that isn’t a good fit for the implementation.

1 Like
4

This will be air quality sensor and it is not battery powered so it has to be able withstand power loss.

Now I know I have to persist much more data and I know how to do it I’ll make change, but I have noticed that after OTAA (when messages are delivered to application) device still sends messages only using 3 default frequencies.
And each message is followed by downlink message to my device so this is probably some MAC command from TTN. I guess I need to ask about that on SX126x library forum.

My question is - can I manually decode MAC command? I guess I should use network session key and raw_payload field?

5

You certainly can. Or you could use GitHub - anthonykirby/lora-packet: LoRa radio packet decoder (there used to be an online instance of the software but it only shows errors so isn’t available)

6

You’d be asking radio hardware people about a software layer …

Just look in the console using Verbose stream on and look at the information in the downlinks.

The firmware you are using was written for the RAK modules so I’d expect it to work like other well developed stacks. Did you make any changes?

7

I’m writing own code (I’m adding LoRaWAN capabilities using this library into mature project which was using only WiFi until now). I have tried SX126x-Arduino library in small project and it was working OK on the same hardware (Heltec module) or I just didn’t notice any glitches.

I have just installed that example project and it is sending data using not only 3 basic frequencies and was adjusting SF according to received MAC commands from TTN. So it looks like library/hardware is OK.

It looks like I need just to do more tests and review implementation in this second project…

8

Or more likely, don’t touch any of the code in the library folder and just use the API calls it supplies - that way it should carry on working per spec!