The new rampant rabbit MAC command processor will flood your ABP device with ADR requests, particularly if you have told the device to stay fixed to DR5 as you recommend - at present ADR can only be turned off using the CLI
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.
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:
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)… ???
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)
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 probably32 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? )
In the Application layer settings step, the AppSKey must be exactly the same as for your v2 device registration. -( OK AppSKey entered from v2 )
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.)
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.
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.
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.