I’m using a Arduino based node with the LMIC library and I noticed with “Reset Frame Counters Enabled” and “Frame counter width” set to “16 bit” some of the problems described earlier in this concersation, but after setting to “32 bit” everything seems to work quite well
I also have some problems with frame counter checks using an ABP device.
Does “Reset Frame Counters Enabled” only reset the counter once? Thats what I suppose with my experiments.
In V2 I can disable frame counter checks. Is this also possible in V3?
What have you tried?
Gateway is in V2, Device in V3
- Register Device
- Start sending data. frame counter is increasing.
- Reset frame counters → checkbox to enable. And save.
- Reset device. Device counter will start at 0 and I see the uplinks in V3. Increase frame counter.
- Reset device again. Device counter will start at 0.
Wont’t see any uplinks in V3 console until frame counter reached previous count.
Given how much TTI would like use to use OTAA, that’s not totally surprising.
But I’ve testing some firmware which I normally do with ABP to save on Joins and DevNonces and not see that - I have a tick on the Enabled check box for Resets Frame Counters - which is all a bit ambiguous.
Let me run the device a couple of times to see what actually happens.
I’ve restarted the device a couple of times and got all the uplinks starting from 0 without any issue.
Can you tell us a bit more about the device & how it was registered - particularly if it’s from the device repository.
Indeed now it’s working with a new registered device. I manually registered the device. Maybe I did something wrong the first time. Thanks a lot!
There are many many new settings under the hood, I’m sure science is involved but at present it does feel a bit lottery like!
One more question did you sent on all channels? I checked again and have the same problems if I activate all channels.
If I only transmit on channel 0, I have no problems:
LMIC_setupChannel(0, 868100000, DR_RANGE_MAP(DR_SF12, DR_SF7), BAND_CENTI); // g-band
I’m using a Murata module so it’s not LMIC like at all, but yes, I do have all the channels setup to stop the Network Server drowning me in downlinks.
I think I’ve got LMIC ABP working but it’s been a few weeks since I did that. But each time I’ve setup with all the channels in the device settings on the console.
I can try that later with my Push-to-Send device on my desk - a Feather M0 with RFM95 - currently programmed to OTAA but easy enough to swap over.
Have you manually added the 5 additional frequencies to the ABP device in the console? If not V3 does not know your device knows about the additional frequencies and will drop al transmissions on those frequencies.
If you did not, you will need to add them and reset the ‘session’ for the device. Search the forum on how to do that. (Or just delete and add the device and add the frequencies while creating it)
Ok thats the hint I needed. I did not add the additional frequencies.
Did not know that I have to do this…
Thanks a lot!
Just posting to confirm that there seem to be issues with Resets Frame Counters for 32bit counters.
I have already registered 5 different devices and actually deleted and re registered several times. Every time, the first packet is routed correctly and then nothing.
I’m using a RAK811 based node with ABP on v3 EU868
The node initially uses just channel_index 0,1,2 i.e., 868.1, 868.3 and 868.5 respectively.
Despite that, what I find in practice is that even if I do not explicitly declare the additional frequencies,
the missing frequency definitions, datarates and timing will automatically be sent to the node via “ns.mac.new_channel.request” / “ns.mac.rx_param_setup.request” / “ns.mac.rx_timing_setup.request”
The node will then start using “channel_index”: 3,4,5,6,7 (i.e., 867.1/.3/.5/.7 & .9) and rx1/rx2 parameters as follows
"rx1_delay": 1,
"rx1_data_rate_index": 5,
"rx1_frequency": "868500000",
"rx2_frequency": "869525000",
"priority": "HIGHEST",
"frequency_plan_id": "EU_863_870_TTN"
"rx2_data_rate_index": 3,
"rx2_frequency": "869525000"
"delay": 5
Presumably by declaring the additional frequencies would save downlink(s) as part of the initialisation and would be more efficient.
If you make sure both the node and the stack (advanced network properties) have the same settings that should work.
Hello, I’m having the same issues. I have a device (arduino based esp8266+RFM95 module) setup as ABP and registered into The Things Stack following the steps described here.
Same results as commented by you. The first time device is registered, I can see the uplink routed and showed into application live data.
Then, my device goes to deep sleep mode for an hour and wakes up again to gather the data and send back again. In V2 it worked without any problems, but on TTS as commented, only the first time it’s routed, the following ones aren’t.
I´ve already checked that my device is registered following the recommendations on this thread: 32-bit frame counter width checked and Reset Frame Counters Enabled.
Anyone can look into this? I confirm as well that seems to be issues with Reset Frame Counters for 32 bit counters. Hope it´d be reviewed and fixed.
Many thanks in advance.
Have you been able to test? Looking forward hearing your results. I´m having the same issues as @dmamalis
Thanks in advance!
Not really how it works round here now - we do the debugging and then file an issue - there isn’t anyone to “look into this”.
Let me finish the labels for my new SMD component storage (I live life on the edge at the weekend) and I can take the Feather for a spin.
Sure! apologies if it seemed like a request! It was not my intention at all! I found this post detailing the same problem I have encountered and would like to help so it can be reviewed if possible. Happy to help sharing any details that could lead to detect what’s happing
Thanks a lot! I´ll stay tuned for any advance.
PS: Yeah! weekends should definitely be a time to ‘disconnect’ , in my case it is when I can invest some of my spare time to look into this Thanks for your fast feedback. Really appreciated.
So I used one of my test ABP setups in v2 and took that for a spin as a base line using my on-desk Adafruit Feather M0 with RFM95 using LMIC 4.0.0 which says it is LW 1.0.3 compliant (no reason to doubt it).
Then created the same ABP device but using a slightly different AppSKey in v3 using the CLI (to save on typing in all the frequencies) but without setting Resets Frame Counters to Enabled.
Uplinks were ignored if I reset the device until it reached the last max uplink count.
When I ticked the Enabled checkbox, uplinks were received regardless.
I created a new ABP setup using the CLI but set the Resets Frame Counter and re-flashed the Feather - it received all uplinks regardless of Frame Counter.
ESP deep sleep generally means that RAM is lost, therefore state is lost. But that shouldn’t preclude the reset counters option.
Which LMIC are you using?