Running AttNode v1/v2 on TTN v3

As you will probably know, the legacy TTN v2 Stack will be shut down in December of this year, which means nodes on TTN v2 should be migrated to The Things Stack Community Edition (formerly known as TTN v3 Stack). Unfortunately, the TTS stack made it a little harder to run “incomplete” nodes like the AttNode v1 and v2, which in the default firmware don’t support downlink packets, and are therefore not exactly LoRaWAN Spec compatible.

It is possible to create a node definition in TTS WebGUI for a v1 or v2 AttNode which will receive the packets just fine, but unfortunately the stack will try to configure the node via downlinks, which the v1/v2 firmware doesn’t handle. Since the stack expects a respone for these setup packets, it will resend them again and again, creating lots of unneeded downlink traffic.

Fortunately I found a way creating nodes using the ttn-lw-cli commandline utility which does (according to my tests so far) not have this behaviour, meaning, it will not create downlink packets to the nodes. This is achieved by setting all parameters to the defaults of the TTS stack (so that no setup packet is required) as well as disabling device status requests, which are otherwise periodically sent.

So here is the command I used sucessfully:

ttn-lw-cli dev create <application-id> <end-device-id> \
--frequency-plan-id EU_863_870_TTN \
--lorawan-version 1.0 \
--lorawan-phy-version 1.0 \
--abp \
--session.dev-addr <device address> \
--session.keys.app-s-key.key  <AppSKey> \
--session.keys.f_nwk_s_int_key.key <NwkSKey> \
--mac-settings.factory-preset-frequencies 867100000,867300000,867500000,867700000,867900000,868100000,868300000,868500000 \
--mac-settings.rx1-delay 5 \
--mac-settings.rx1-data-rate-offset 0 \
--mac-settings.rx2-data-rate-index 3 \
--mac-settings.rx2-frequency 869525000 \
--mac-settings.status-count-periodicity 0 \
--mac-settings.status-time-periodicity 0 \
--mac-settings.supports-32-bit-f-cnt=false \
--mac-settings.schedule-downlinks=false

You will have to replace the parameters (everything in <>) according to your device. Since I recreated these nodes, I had already generated the address and keys to fill in here. If you create a new device it might be necessary to create a device in the WebGUI, copy the values and recreate the device with the CLI after deleting it in the WebGUI.

I currently have 5 nodes running like this with none of them having a single downlink frame so far. I don’t know if this will hold true with TTS updates further down the line, but at the time of this writing with TTS Version 3.14.2 it seems to work fine.

For information on how to set up the ttn-lw-cli and connect it to your TTS account see the official documentation