as I am developing my code to transmit to TTN I had a hard time data to end up in the Application. It clearly got received by the gateway but never ended up at the application.
One other clear indication that something is wrong is that the gateway received incorrect number of bytes I am transmitting.
I should expect 6 bytes to receive but I received 14 and wrong bytes.
I managed to fix this by going to your device–> Settings and uncheck “Frame counter checks”.
Now I receive data and this time it is correct. When I enable this checkbox again, it functions normally.
I think there may be an uninitialized variable at the TTN side when the counters doe not increase in sequence but when they revert to 0 when you reupload new firmware to your sensor code. I think TTN somehow is pointing to incorrect receiving data.
If you are using ABP (for OTAA you don’t need to reset counters, TTN does this on a join) you need to reset counters every time you reset the counters on your device by resetting it or loading new firmware.
Only packets with a counter value exceeding the one you used last transmission will be delivered to your application to avoid replay attacks.
The data shown at the gateway is not the just application data you see in the application console. It includes LoRaWAN headers and is still encrypted. You can’t use the data at the gateway level without decrypting and stripping LoRaWAN headers.
Yes, if you reset/reload the node you need to use “reset frame counter” in the TTN console for that node as well. Or, a better solution would be to switch to OTAA. While joining the counters will be reset by the back-end,