You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 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.
The text was updated successfully, but these errors were encountered:
aalku
changed the title
BUG: fcnt / UpLinkCounter not incrementing
fcnt / UpLinkCounter not incrementing so TTN ignores uplink frames
Apr 28, 2024
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
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.
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.
The text was updated successfully, but these errors were encountered: