My Sodaq One (with resistors removed) is having difficulties transmitting/receiving data through the TTN network. I have borrowed a second Sodaq One (with the resistors still in place) that is receiving/transmitting data much easier (more packets arriving. They are at exactly the same location with the same configuration (ABP, SF7).
One thing i noticed is that when i hit “reset frame counter” in the TTN console, shortly after it will start receiving data again (for a short period of time). Disabling the frame counter check in the TTN console doesn’t make a difference.
I am using the latest sodaq tracker code. Any thoughts on what might be the problem?
This is normal for TTN.
Contact TTN why this doesn’t make a difference
TTN prefer OTAA and not ABP. Can you try to switch to OTAA in your application?
Is this normal for TTN, but still considered a bug, or is it designed like that?
I just heard that the counter is reset with ABP devices when you reboot/repower the device. But in my case it happens even when the device is on all the time.
OTAA wasn’t working for me. By chance i noticed that ABP was working (although the majority of transmission are not received by TTN), that’s why i was using ABP. I concluded that OTAA might needed a more robust/stable connection (for handshake, etc. not sure if that is true). I will try again with OTAA.
I will later on also try the ttnctl tool to disable the framecheck, maybe the option in the TTN Console is not actually implemented / doing something.
TTN is designed to use the packet counter.
When you reboot/re-connect to the network the packet counter is reset on the device. With OTAA it automatic resets the counter. With ABP you have to do it manual or disable the frame counter check in the TTN backend.
Its true that OTAA needs a more stable connecting while its activating.
But once it’s activated it’s operating the same as an ABP device.
You should contact TTN about this question