Last time I checked the specification there was an ADR bit in the packet header specifying if the network could control the nodes data rate. If it is not set the backend should not send any ADR command. So the node can signal the network it won’t do ADR and the stack has to refrain from sending ADR MAC commands, no need for cli commands.
As far as I know I linked to the latest docs on github - last edited 6 days ago. But clicking on the “edit on github” link takes me to GitHub - TheThingsIndustries/lorawan-stack-docs: Documentation for The Things Stack (last edited 4 days ago), not to GitHub - TheThingsNetwork/docs: Documentation for The Things Network. Yet another very confusing thing about the migration from v2 to v3 
Yup, makes sense that it makes no sense.
I shall look in to it at LMiC and the various modules I have, but I think this is probably going to be a little esoteric for many makers.
The console has come a long way since this guide was written. When registering an ABP device I now see an option:
My expectation from this is that the 8 frequencies should be automatically set depending on which frequency plan I chose at the top.
I’ve registered a device to test, but I do not see any “Factory programmed frequencies” set in the advanced network settings. Packets are however received, unlike in the past when they were dropped when the frequencies were not set.
What is the current expected behaviour, and do we still need to manually set the factory programmed frequencies for ABP devices?
Hi, first post on this forum. It seems my problem fits the topic.
I am trying to migrate ABP devices from V2 and I can’t make it work. However I could migrate the same kind of devices without any problem a few month back (let’s say April 21).
I check the config of my previously migrated devices and it is the same as the devices I want to migrate now.
Since the UI has changed (missing reset frame counter checkbox) I was wondering if something changed in the device creation or if I am missing something new ?
What I did step by step:
- Create device from the V3 console carefully copying devAddr AppSKey and NetSKey from V2
- Changed keys on V2 to avoid Network server conflicts
- Realised I doesn’t work
- Realise I did not check “reset frame counter checkbox” because it is not available in the console anymore
- Remove the device from the console
- Create device with CLI
- Still don’t work
- Asking the community
This is what is used to create my device from the CLI:
ttn-lw-cli end-devices create myapp mydevice \
--frequency-plan-id EU_863_870_TTN \
--lorawan-version 1.0.2 \
--lorawan-phy-version 1.0.2-b \
--abp \
--session.dev-addr 111111 \
--session.keys.app-s-key.key 11111111111111112222222222222222 \
--session.keys.f_nwk_s_int_key.key 11111111111111112222222222222222 \
--dev-eui 1111111111111111 \
--mac-settings.factory-preset-frequencies 868100000,868300000,868500000,867100000,867300000,867500000,867700000,867900000 \
--mac-settings.resets-f-cnt=true \
--mac-settings.supports-32-bit-f-cnt=true \
--mac-settings.rx1-data-rate-offset 0 \
--mac-settings.rx1-delay RX_DELAY_1 \
--mac-settings.rx2-data-rate-index DATA_RATE_3 \
--mac-settings.rx2-frequency 869525000
Is there option for migrationg many ABP devices to V3? The post above says
[to be added later]
I was trying to add some of my V2 gateway in V3 console without success. Now I will have 4 scrap gateways. I bought new mikrotik console and registered in V3. I hope I could migrate devices now… Could soumeone point to the correct instructions for batch migrate (looks like I will have a bunch of useless devices soon)… ???
Please don’t post a duplicate of the same sort of question.
Try reading the docs as a first port of call, then you can ask better questions.
What GW’s? why scrap? What have you tried? What firmware & packet forwarder are you running? How is that linked to
I can get it the v2 application/device to show, but not in v3. Someone please tell me where I am going wrong! The gateway is added to V3, and I can see the node hitting the v3 gateway. But no data/traffic shows in the Application or Device side. It was working in v2.
-
If you don’t have an application in V3, add a new one.
- The Application ID does not have to match your V2 application ID.
-(
OK,Done:created new app in V3, Application ID does not have to match your V2 application ID)
- The Application ID does not have to match your V2 application ID.
-
Add a new End Device in V3.
- Follow the manual steps:
- Select Activation by personalization (ABP)
-( OK DONE)
- The LoRaWAN version is probably
v1.0.2.
-(
tried 1.0 and 1.0.2 using ESP8266+RFM95 radio LMIC code)
- In the Basic settings step, the End device ID does not have to match your V2 device ID.
-( OK End device ID is new/different than in v2)
- The DevEUI is optional.
-( OK DevEUI is not set. This is different from the in v2 device where it did have a value, however there is no way to set DevEUI on my device anyways)
- In the Network layer settings step, Select a Frequency Plan. For EU868 devices coming from v2, you select Europe 863-870 MHz (SF9 for RX2 - recommended).
-( OK set to USA FSB 2 902-928 used by TTN, gateway says sender is using on 903900000 and SF7125)
- The Regional Parameters version is probably
v1.0.2 rev B
-( greyed out but show PHY V1.0 in TTN Device Settings)
-
Your device does not support class B or class C
-( OK no checkbox class b or c)- The DevAddr and NwkSKey must be exactly the same as for your v2 device registration.
-( OK DevAddr and NwkSKey exact as in v2 )
- The Advanced settings must be set on registration.
Changing these settings later may not work.- The Frame counter width is probably 32 bit
-( OK 32bit set )
- The RX1 Delay is 1 second
-( OK 1sec set )
- The RX1 Data Rate Offset is 0
-( OK offset 0 set )
- The device probably resets frame counters
-( OK check the box reset frame counters set )
- The RX2 Data Rate Index for EU868 devices coming from v2 is 3
-( OK defaulted to 8 for US/915, also tried setting to 3 per 2.2.3 from spec manual )
- The RX2 Frequency for EU868 devices coming from v2 is 869525000
-( OK defaulted to 923300000 for US/915, )
- The Factory Preset Frequencies for EU868 devices coming from v2 are:
- for all devices:
868100000,868300000,868500000 - for devices that use 8 channels
867100000,867300000,867500000,867700000,867900000
(in addition to the 3 channels above )
-( not entered, do i have to type in 64 frequencies manually for US/915? )
- for all devices:
- The Frame counter width is probably 32 bit
- In the Application layer settings step, the AppSKey must be exactly the same as for your v2 device registration.
-( OK AppSKey entered from v2 )
- The DevAddr and NwkSKey must be exactly the same as for your v2 device registration.
Deleting the Device from V2
With the registration in v3 set up, you need to prevent the V2 Network Server from handling traffic for your device. You can do that by deleting the device from V2.
-( OK deleted device from v2 )
Connecting Your Gateway to V3
Because your device is still using a V2 DevAddr, Packet Broker won’t route traffic for it to the V3 Network Server if your gateway is still connected to V2, so you have to connect your gateway to V3.
-( OK gateway added to v3, and i can see the abp node sending traffic in the gateway and the DevADDR etc Receive uplink message, but noting in Application or Device side.)
why cant i see it in v3 device traffic?
good details so far but what is device? what firmware/library are you using? COTS or DIY?
Hello, thanks for taking time to respond. The node is an ESP8266 nodemcu or lolin d1 DIY with ablkbox BB-frm9x-x semtech SX1276 based radio module. The code is borrowed from Thomas Telkamp and Matthijs Kooijman and seems to be using the older IBM LMIC.
Key point being
The MK implementation long since deprecated and unsupported IIRC - key now is to get you on to something closer to playing nice with TTN V3 - look at the MCCI implementation… etc. Forum search will help you find current candidates.
Hi there.
I am reposting because I haven’t had any answer yet.
Does anyone can help me ?
Thank you 
Hi, I hope this may help:
Recently we have done some testing in our community with the Migration tool of TTN that is documented here: https://www.thethingsnetwork.org/docs/the-things-stack/migrate-to-v3/migrate-using-migration-tool/
We successfully migrated active sessions in both ABP and OTAA from V2 to V3. worked like a charm.
1 Like
Thank you very much, it worked perfectly !
ABP devices were exported from V2 and successfully imported to V3
I migrated a number of devices from TTN V2 to TTN V3.
To maintain device compatibility the units are being used in ABP mode and with the RX1 Delay set to 1 sec in the TTN V3 console.The devices are also using Acknowledged Packets.
I have noticed the occasional missed packet.
A check of the missed packets on the TTN V3 console shows that the DELAY parameter in them is shown as “5” instead of “1”. The packets which succeed all show the correct delay of 1 sec.
This may pint to a bug somewhere in the code which sees the downlink packets occasionally picking up the default delay rather than that programmed in to the device.
Who’s code?
How often are the devices uplinking?
This should be used only sparingly, and even then well within the TTN FUP limit of 10x per day max…think more in terms of 10x per month!