Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
aalku opened this issue Apr 28, 2024 · 2 comments
Open

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

aalku opened this issue Apr 28, 2024 · 2 comments

Comments

@aalku
Copy link

aalku commented Apr 28, 2024

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 aalku changed the title BUG: fcnt / UpLinkCounter not incrementing fcnt / UpLinkCounter not incrementing so TTN ignores uplink frames Apr 28, 2024
@aalku
Copy link
Author

aalku commented Apr 29, 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

@aalku
Copy link
Author

aalku commented Apr 29, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant