RadioLib - downlink only works briefly after join

End Devices (Nodes)
1

Hi all,

I have a weird problem:

Got myself two Heltec_esp32_LoRa_v3 boards and a TTN gateway. Gateway works, Heltec boards nice, didn’t so much like their Arduino library. So I built my own library, which uses RadioLib and where I plan to make everything work, all the examples compile, etc etc. Now that I’m done with the basics, I want to make a few really nice, working, tested, stable LoRaWAN / TTN examples, and I’m running into an issue. I can join, I can uplink, and I get downlink packets. But just a few. After two or three downlink packets, the downlink disappears, never to reappear. ( maybe one in a hundred downlinks arrives.) As soon as I make a new TTN End Device, put the keys in my code, recompile and have it join, the exact same thing happens every time: the first two or thee downlinks are totally reliable, then it disappears. My uplink keeps arriving at TTN just fine. I did think some kind of rate-limit at first, but even if I send in 10 min intervals this happens.

I have questions:

  • Do people use the RadioLib / SX1262 combo successfully for TTN?
  • Is that a good choice? (I would like things to be simple, I like that RadioLib does all this other stuff and other radios too. Have a look at my library at the link above to see what I am trying to do.)
  • Has anyone had the problem of downlinks working quite reliably but only immediately after join and then never again?
  • I see an Arduino library for TTN, but it says it’s deprecated, and then I see lots of enterprise-looking stuff, but not an easy-to-use Arduino library. Am I missing something?
  • This LMIC stuff looks complex and large, and before I dive in, if that’s what I need to be doing instead of RadioLib, I could use a quick three-sentence summary of the current state of play and what to use and what not to use there. It’s not obvious from looking at the repos somehow. Would however really prefer to stick with RadioLib if that’s working for people.

Thanks in advance…

Rop

3

Your topic is unlisted until you modify your code to adhere to the TTN fair use policy and modify your example code accordingly. Transmitting very 10 seconds with SF12 might even be illegal (as in fines and/or jailtime, depending on where you are in the world)

Keep in mind LoRaWAN is complex and relies on MAC commands as described in the LoRaWAN specification. Your code doesn’t seem to implement any of them and as a result will not work with any LoRaWAN compliant network.

4

Whoops, I see what you mean. You didn’t mean my post but the example in the library. (Thank you for looking at it!)

An error escaped. Fixed.

5

The code there is just a LoRa modulation example. For LoRaWan I’m using the RadioLib LoRaWAN node.

6

You were still in breach of the legal limits by a factor to 10.

Yes, the senior dev, @stevencellist and his test bunny, @descartes get on with it just fine. However it is still marked as beta as they widen support for functionality and boards. The prime test target is TTS and is LW v1.1 only. Other stacks may work but for development work you need to be able to reset &/or ignore DevNonces which is readily available in TTS.

This is all over the GitHub repro and the announcement post on this forum asks that RadioLib specific issues are addressed there as issues can get pretty detailed as new corner cases are uncovered. If you aren’t regularly visiting the GitHub repro or searching this forum, please do so.

Not as such, but then we don’t do downlinks on TTN like we are watching - one a fortnight for config / link check is considered appropriate. Again, forum search will reveal more. The FUP policy limits you to 10 a day per a device.

Which, what, where?? I can guess at it, but it’s all volunteers here, please link to resources you want us to comment on. However I suspect you want to look at Arduino for TTN a little harder as to what it is for, plus search the forum as there are a few topics that will fill you in.

Heltec provides an older copy of LoRaMAC-node which is the official reference code, that may suit your ambitions better. However I suspect you want to look at LMIC a little harder as to what it is for, plus search the forum as there are a few topics that will fill you in.

LoRaWAN is like onions & Shrek and not Lego. What suits one person in terms of implementation may not be good for someone else. You can do most things with LMIC due to events system. You can do everything with LoRaMAC-node if invest the time. LMIC-node is a quick start for LMIC but no sleep built in. RadioLib is deep sleeping on ESP32 nicely.

Your very best bet is to learn LoRaWAN with one of the libraries so you know LoRaWAN and then you’ll know what to look for in other libraries. RadioLib’s examples need updating to fit recent updates but relatively are/will be the simplest.

Please confirm your understanding of the FUP and what happens to a gateway when it is transmitting.

7

Thank you for your quick overview of the universe of LoRaWAN. Very helpful.

Reading the FUP was helpful also, and would indeed explain why the network would stop sending responses to my messages, even when I felt I was being quite considerate sending only one every 5 minutes. (It would be cool if on the network side one could see which messages were responded to by the gateway.) Had not occurred to me that the downlink is much more constrained, I tend to think of battery power as the main constraint.

I’ll stick with RadioLib knowing it’s being worked on actively and I’ll report back on the forum when I have an example with LoRaWAN / TTN for people to look at. Right now working on making power management / deep sleep a bit easier for people to work with, using the button on the heltec as on and off (long press).

As fas as I can see RadioLib puts the session information in EEPROM, which on the ESP32 is in turn emulated in a key in the NVS partition. While NVS is a good place for permanent credentials/secrets like joinEUI, devEUI and the keys, the session stuff / nonces etc should maybe live in RTC memory on the ESP during deep sleep, because of the limited number of write cycles on the flash. In the event of the occasional battery depletion / replacement, a new join message can be sent. Does that make sense?

8

The gateway is a dumb media convertor - it doesn’t think, it can’t be bargained with. It can’t be reasoned with. It doesn’t feel pity, or remorse, or fear. And it absolutely will not stop… ever

Any & all responses are detailed in the device console.

Bear in mind that it is still in beta and still subject to testing, QA and amendments. It is likely that those involved will be working on a reference version which is likely to be managed, as per the forum announcement that you’ve no doubt read, on GitHub. It may be more appropriate to open a discussion there on your aspirations to avoid duplication of effort. I gather they know a bit about LoRaWAN so are likely to make a reasonable fist of it but definitely need independent reviewers and testers.

Yes.

However I suspect you want to look at the implementation a little harder as to the flash wearing implementation for f_cnt.

What did you find about gateways & downlinks?

9

Not sure what you mean. Mostly that the downlinks are more constrained than the uplinks, which was non-obvious to me.

10

They aren’t, but they have a huge impact on the reception of uplinks as the gateway can’t talk & listen at the same time. Hence the FUP limit and the guidance.