That is something Elisa would call “A really big mess!”
I haven’t put it through a rigorous / scientific testing regime, but as far as I can tell, if I use the CLI to setup an ABP device with counter reset turned on from the start, I’ve no issues.
I think I’ve tried doing a manual entry which worked but entering all the frequencies is a bit of a mess, so I haven’t done that in months.
It’s very likely to be the f_cnt starting from zero every time you restart the device when the server is expecting a higher number. This is a security measure to stop replay attacks. You can read about it in the documentation and change the device settings.
Or use OTAA which automatically resets the counters on join.
"when the server is expecting a higher number. "
So nobody can use ABP? Or what can do in the software not to start at zero? start at 100 or so?
OTAA did not worked for me, couldnt get joins. could not solve that problem.
There was no need to switch to OTAA, ABP worked perfect on V2.
security OK. I have a problem…
Is it this counter value that is send?
//Increment boot number and print it every reboot
++bootCount ;
Or is that counter generated by Lmic ?
So how will your device cope when you need it to hear a downlink - discarding OTAA isn’t a solution, it’s ignoring a problem
It’s not available anymore, TTI have moved on, TTS is bigger, smarter, more compliant, more robust, still free to use.
That’s nothing to do with LoRaWAN
In the tangential way that it’s part of the LoRaWAN spec, a fundamental part of it, and so LMIC needs to keep the f_cnt.
Frame counters are so fundamental that your apparent lack of motivation to go and learn about them but to throw questions on to the forum indicates a bit of a loss leader for all those trying to help you as we’ll all be answering questions forever.
I’ve managed to get ABP working flawlessly with V3 on my little temperature sensor, but you will need to disable frame counter checks during your development stages. You can fin this checkbox by going to your end device page, then navigating to General Settings > Network Layer > Advanced Settings, then check the box that says Resets Frame Counters.
That way when your device sends 1, 2, 3, 4, 5, 6… 99, or 100 packets, the server isn’t expecting packet 101 to arrive after the device has lost power or has been reset, as the device will begin at 0 again.
It’s not an insult to point out that we keep saying the same things and nothing is changing - and it certainly wasn’t intended as one, it was definitely designed to try to get you to find out the background to the problem. I would have no knowledge of your age and it is totally irrelevant.
And here’s the issue - if you read the docs you’ll find out it’s not 100, it’s not a specific number, it’s the next number in the sequence, which could be 10,000 or 458 or 6,942 - so if you have a power cycle at some point in a years time, you could be waiting a very long time before the device catches up.
We are all volunteers here, we all have to read the documentation and use the forum search.
“If you give a man a fish, you feed him for a day . If you teach a man to fish, you feed him for a lifetime.”
You will learn far more by reviewing the materials which will give you a better overall picture than having someone just provide a prescriptive procedure for a button that doesn’t exist.
Again, this has nothing to do with the Frame Counter issue you are likely experiencing - it’s just your web browser losing connection to the server - it happens to us all and is dependent on your connection speed & latency
why does that work well, and insert via console cant get i working…
I looked at CLI but it looks too difficult for me…
To me i think the reset counter does not work. There are more users think the same.
I tried to read the docs, but it is to much, and unclear for me.
Maybe some links to read ??