ABP node stopped working -> Fixed by creating new ABP.. Why? :)

Hi all! I have been playing with TTN for a week now and I have a working PROMINI (3,3v, 8mhz, 328) + RFM95 + u-blox GPS node. Everything is working as expected and I have been tracking my activity for a 2 days. The range is excelent btw, had some 10km+ frames near Lopik, NL (Gerbrandy tower) using a simple 86mm wire as an antenna.

I registered my device using ABP and I send 1 frame every minute (only while traveling ± 100 frame per day), packing the GPS data into 2x32bit integers thus sending 8 bytes per frame.

This weekend everything stopped working after one of my soldering joints to the RFM95 module broke. After resoldering the joint everything seemed to work (checked using serial monitor) but I did not receive any frames in the TTN console. I was afraid I bricked something leading to the antenna so I checked the 868mhz spectrum with an RTLSDR stick and everything seemed in order. Still no data om TTN though, not even while driving from Lopik to Utrecht (passing the Gerbrandy tower and having a LOS most of the trip)…

Today I added a new ABP device in the TTN cnsole and uploaded the new keys to my Arduino… And everything started working again! Does anybody know what might have happened? Is this expected behaviour using APB and would this be solved using OTAA? Could the node have been rate limited without warning?

I am very happy everything is working again but I’m not sure how to prevent this in the future. Does anyone have a clue?

1 Like

Hi Johan,

Did you switch on Relax Frame Count in the settings of the device in the TTN Dashboard or reset the frame counter manually after switching on the device after repair?
Otherwise the packets are ignored for security reasons, because the counter will start from zero again.


Hi Nico,

I did. In fact, i did just before leaving the office and breaking the soldering joint. I also toggled the Relax frame count to see what would happen

I’m not sure what the ‘Relax frame count’ option does. I will read up on it :wink: (and stop touching settings without understanding them)


Just a little follow up. I need to RTFM more :slight_smile: I jumped in without understanding the framecount and without realizing my device would reset the framecount every power-cycle thereby making TTN drop the first X frames. I reset the framecount in the TTN console almost every time I started a measurement so it sort of worked, and sometimes I missed a bunch of frames without understanding why.

I understand now, thanks again for the help!

As flipping the switch on the ‘relax frame counter’ imposes replay attacks and thus degrades security you could also use OTAA instead of ABD. When using OTAA, with each join (as I understood it correctly) the frame counter gets reset.
So you’ll keep your security up and won’t get troubles when de-powering your device.

Yeah, OTAA is the best way to go here. Storing the framecount between reboots could be an option but I guess that would mean a manual reset every 2^16 frames. I moved to OTAA last week and it looks promising. Sometimes the joining is a bit slow, and sometimes something goes wrong and it needs to rejoin (need to figure that out). But all in all, it works!

To find the (insecure) “frame counter checks” options (previously known as “Relax Frame Count”):

  • First, read this full post, and its warnings below, and the warning TTN Console shows, so you understand what you’re doing!
  • Log in to the Console at https://console.thethingsnetwork.org
  • Go to your application
  • Click Devices, and find the specific device
  • Just to be sure: write down the current values for “Frames up” and “Frames down”
  • Click Settings, and uncheck the checkbox:
    frame counter checks
  • In the command line interface, see the --disable-fcnt-check option.

:warning: Disabling frame counter checks drastically reduces security and should only be used for development purposes.

:warning: This only affects the server side, hence only affects the uplink frame counter; if you ever reset the counters in TTN (see also the next warning) then you’ll need to implement something similar in your device for the downlink frame counter. (Note that downlinks include MAC commands, like used for ADR, and ACKs for confirmed uplinks.)

:warning: Simply just changing this setting for an ABP device will reset the frame counters in TTN. (Due to a bug for ABP devices, even just changing its description will already reset the counters!) So, the downlink counter will be reset to zero when changing this setting.

Even when the frame counter checks have been disabled, a device will no longer work when it resets after already having used values larger than 16 bits (65,536 and up). In that case, TTN will not be able to validate the MIC. And as a DevAddr is not unique, TTN needs a valid MIC to find the device. (An uplink only holds the LSB 16 bits of the frame counter. For the MSB the server will try the last known value and the next value, to validate the MIC.) (TTN first checks the 16 bits counter, regardless any MSB it knows, so that’s a happy accident in case the device has been reset to zero.)

Also note the “reset frame counters” link next to the last known counter values in the Console. If you really know what you’re doing then you can use this to make the TTN backend set both the counters back to zero when needed, without the need to disable the frame counter checks. Beware that resetting the downlink counter requires your device to do the same, for otherwise the device will ignore any downlinks that use numbers that are lower than the downlink count it knows. (Just the opposite of how TTN will ignore low values for uplink counters.) Also, despite the incomplete warning, if the uplink counter already exceeded 16,384 then TTN will not accept any uplinks after resetting the counter without resetting the device as well. You might want to write down the last known values for both “Frames up” and “Frames down” before resetting anything.

Frame counters

If you messed up, then there’s a small chance that ttnctl might help to make TTN use the true counters again.



I was working with the same setup Arduino Pro mini, RFM95 and Ublox, but I couldn’t get it working. Could you share your sketch,


Great topic, I’ve been working on it too and it seems to be working but I don’t get a valid GPS signal (number of satellites = 255…). I’ll share the code this evening. The node did work if I recall it right.

It would be great to build a few of those them as permanent ttnmapper nodes for members driving a lot.

Hi Marco,

Sure, the repo is a bit messy. It’s a work in progress :slight_smile: Here it is: https://github.com/Teumaat/ttn-tracker

PS: I use http://platformio.org/ instead of the arduino IDE so the project structure might not work in the ardiuno IDE.

1 Like

Hi Johan,

Great, thanks for sharing!
I’ve never heard about platformio or Atom but that looks fine…all day learning :grinning:

1 Like

That’s even faster! Thanks!