RXTimingSetupReq but no RXTimingSetupAns

[FunnyPaul]

I'm fairly new to LoRaWan, but I think I've found a small error.

If the network server sends an RXTimingSetupReq, this should be confirmed with RXTimingSetupAnsaccording to the specification.

Unfortunately, in LoRaWAN.cpp under execMacCommandin the case branch RADIOLIB_LORAWAN_MAC_RX_TIMING_SETUP, the rxDelaysvalues ​​are adjusted accordingly, but apparently no RXTimingSetupAnsis sent, so the network server continues to send with 5 seconds and from that moment on no more packets are received because the window now has the new value.

There is a TODO note in the zar function that something else should be sent, but this is apparently not implemented.

I helped myself by NOT adjusting the rxDelays.

[StevenCellist]

Are you using RadioLib 6.6.0 or current upstream?

[FunnyPaul]

RadioLib 6.6.0

[StevenCellist]

Can you please retry using current RadioLib upstream? If the problem still persists, then please provide the details on your hardware, software used, code used and a debug log using the protocol debug turned on (please refer to the wiki to find details on that).

[FunnyPaul]

First of all, thank you very much for the quick response. I have now downloaded the current version. I will wait until the server fires an RXTimingSetupReq and then get back to you :-)

[FunnyPaul]

Unfortunately, it didn't work with the current library either. You can see that the delay was increased (yellow), but the TTN server still sends with a 5 second delay.

Strange that the status returned is -1116 (RADIOLIB_ERR_NO_JOIN_ACCEPT)?! It wasn't even a join request....

[StevenCellist]

So how did you register your device on TTN and what sketch is running on your device?

[FunnyPaul]

I registered it via OTAA and it works pretty well (for hours) until the TTN server decides to enlarge the RX window...

It is a Lilygo T-Beam V1.2 with an SX1276 (instead of SX1262) installed.

I took the application from https://github.com/designer2k2/tbeam-lorawan-mapper and adapted it for the reasons mentioned above. The pin assignments in the project also didn't fit.

It cost a lot of nerves and time to get started...

[StevenCellist]

To be clear: TTN does not enlarge the Rx window - there's something about most likely the way you registered your device. So please, show us the registration on TTN and the code running on your device.

[FunnyPaul]

As I said, I'm new to this topic. I actually just wanted to quickly put together a mapper to test the range of my newly installed gateway. The code (see above) is quite complex and probably not correct due to my adjustments. If TTN doesn't change the RX window, it's probably some other bug. By the way, I retested the device with the 1.0.3 standard.

When I get the chance, I'll work through the very good examples here and recreate it from scratch. If there are still problems, I'll get back to you. Nevertheless, thank you very much for the quick answers and efforts :-)

[StevenCellist]

Part of the blame should go to the developer of that source code, as there is no mention of the NwkKey used in LoRaWAN v1.1 (which they also fail to mention), but it is configured. As RadioLib runs v1.1 (or v1.0.4 as of from current upstream), this NwkKey is also mandatory. I'm 99% sure your problems stem from a mismatch between registration and code, so I'm going to close this issue for now. If the problem persists after switching to LoRaWAN v1.1 (or modifying the code in main.cpp according to the README in the examples/LoRaWAN folder), feel free to reopen. The maintainer of the linked repository should also improve the instructions on LoRaWAN versions.

But please, you can't point to some code and then say "I've modified it" - exactly those modifications are what we are looking for when hunting bugs!

[FunnyPaul]

Nevertheless, thank you again and sorry for any inconvenience. As I said, I will completely rebuild it using your examples and learn to understand it. I am very excited...