HelTecAutomation / Heltec_ESP32

Arduino library for Heltec ESP32 (or ESP32+LoRa) based boards
Other
580 stars 219 forks source link

fcnt / UpLinkCounter not incrementing so TTN ignores uplink frames #144

Open aalku opened 2 months ago

aalku commented 2 months ago

TTN is rejecting many of the uplink messages because the field fcnt of the frame header is not incrementing between cycles.

The LoRaWAN spec states that it must be incremented for every message and messages with repeated or decrementing fcnt must be ignored by the receiver, so TTN is working as expected but Heltec_ESP32 LoRaWAN implementation is not, at least in my case.

I found where it is supossed to be incremented in the code, I think it's here: https://github.com/HelTecAutomation/Heltec_ESP32/blob/a7b37d5b8975bb66d7a2b6c3f8f2d510d965fc3e/src/loramac/LoRaMac.c#L1551C21-L1551C34

I don't know why it's not incremented in my case. Incrementing it in ACK or timeout, as I think it does, seems to not being working. Maybe I messed with something in my code? I don't know. Why is it not incremented when sending the message instead of doing it on ACK or timeout? I guess it's so you don't increment it in retries but maybe there's a better way to handle it.

Thanks for your help.

aalku commented 2 months ago

It seems this is related. I'm getting a Tx timeout and that's when fcnt is not incremented.

I don't understand that timeout as there are no retries or anything, just timeout. As you can see there were retries in the first cycle but not in the second one.

12:29:36.167 -> LoRaWAN EU868 Class A start!
12:29:36.167 -> 
12:29:36.276 -> 
12:29:36.277 -> joining...
12:29:36.277 -> TX on freq 868100000 Hz DR 3 power 14
12:29:36.496 -> Event : Tx Done
12:29:59.463 -> RX on freq 868300000 Hz at DR 3
12:29:59.713 -> Event : Rx Done
(User app logs here)
12:30:14.880 -> TX on freq 868100000 Hz DR 5 power 14
12:30:14.958 -> Event : Tx Done
12:30:19.923 -> RX on freq 868100000 Hz at DR 5
12:30:20.022 -> Event : Rx Done
12:30:20.022 -> deepsleep time:113157 ms
(User app logs here)
12:32:20.983 -> TX on freq 868100000 Hz DR 5 power 12
12:32:26.725 -> Event : Tx Timeout
12:32:27.746 -> deepsleep time:119303 ms
aalku commented 2 months ago

It seems my mistake was to add some delay after LoRaWAN.send(); so the user can read the screen. It seems LoRaWAN.send(); must be the last thing in the loop cycle so the library can handle TX/RX correctly. I expected it to use interrupts or being tolerant as there are no comments in the example and I didn't find any documentation for the API use.