I have two different gateways, one in the laboratory and another in the field. First I test the new devices in the lab and then I sent it to the field. We tried the migration from v2 to v3 with a single device by registering it in the v3 and changing the appKey in the v2 and it went correctly, so I sent the device to the field and it continues sending data correctly. This was made like two weeks ago.
The problem is when I try to register a new device a few days back, as now we can’t do it in the v2, I did it in the v3. The procedure was exactly as I did with the registration of the migrated device, and the console didn’t show anything, even the message that informs of a device trying to connect. I double checked the credentials and the settings and everything was correct. I registered another device to identify if the problem was the device, and the second device neither connects. I changed the credentials in the v2 console of the migrated device (that still works in v3) to be the credentials of the device I tried to register in the v3. It connected at the first attempt. As it works in v2, we made the corresponding issue to migrate from v2 to v3 and it didn’t work.
The migrated device and the ones we attempted to register were RAK4260. Finally we tried with an Arduino MKRWAN1300 and it neither connects to v3 but it does to v2 correctly. As the devices in the field reboot once a week, I migrated a device that was in the field and when it rebooted it connected correctly to the v3 console. When I try to connect the devices to v3, we see in the gateway transfer that the join requests are sent correctly.
With this information, maybe the problem is in the gateway, but with this gateway i did the migration of the first device correctly, so i don’t think so. This gateway is the “The Things Gateway”, so it should work correctly in the v3 as it did it with the first migrated device.
Thanks in advance for the people that will try to help me and the ones that have read it all.
What do you mean with MLS versión? The one in the gateway?
As we use the same devices that the ones set up in the v2, i set the option that are given in the guide of migration. This are a MAC version lf 1.0.2 wirh the REV B.
Yes, i use OTAA and with reboot i mean that they power off due of the batteries, they power on when they change it. The field is in other town.
Nope, the Microchip LoRaWAN Stack - the MAC / stack you compile against.
Which migration guide? The version needs to match the version that the MLS provides.
This is going to be tricky - the JoinNonce is going to get seriously messed up and you are going to have to sort out something with the command line after every battery change.
Yes, it was me with another account, sorry for the mistake.
To answer the question of the MLS, i need to be in the lab, tomorrow i will try to find it, but i dont really know how to acces that info, i use a code i dont fully wrote myself.
With migration guide i mean a post in the ttn web on how to migrate devices from the v2 to the v3.
Tricky why? The same modus operandi is made with the first device i migrated and it works correctly, when it is powered on another time it starts to send the data like it did it before to run out of charge. Also the device that is in the field and i migrated a few days before follows the same procedure and it works correctly.
This is a little bit confusing, because with the new devices in the lab i did the same way as i did with the first device. And now the new ones doesnt work.
Sorry for the late reply, but i had some internet troubles.
By the time i couldn’t access the v2 console it seems that it had change some features. Now i can’t see the traffic of the lab gateway and it shows me that the gateway is only connected to v2, so it seems like this was what made the devices not to connect the v3.
But now i don’t know how to export this gateway to v3. I will search in the web and in this forum, if any one knows how to do it or where to look for it will be great. The gateway is “The Things Gateway”.
Hey wiki. Have you got any news on this? I’ve had similar experience too. The connected device in TTN v2 has no problem migrating to v3 with the existing session keys etc… However, I can’t do OTAA with new sensors on the v3. I now suspect it has got to do with the default rx1 delay timing in v2 (1 sec) and v3 (5 sec). So these sensors are operating in 1 sec rx1 delay time and so they can’t receive a proper join-accept.
There are two different delays as Jac says above - one for JOIN - which is set to 5s and one for all other downlinks which was 1s on v2 and was extended to 5s on v3, principally to ensure that the Packet Broker system had enough time to work.
The Rx1 delay of 1s is only a recommendation in the RP spec, not a must or shall.
This is not an issue with OTAA joins which will automagically set the Rx1 delay to 5s as part of the Join Accept.
But it is a buggers muddle with ABP figuring the correct incantation & number of chickens to sacrifice for the various permutations of migrated or created devices and the mechanism used. That is to say I’ve rather lost track since a heavy session back in March.
Thanks for the explanation. Sounds much clearer to me now. Still trying to figure out why my node is not receiving the join-accept message even though the message did arrive to my gateway.
I had problems with V3 OTAA in AU915 with Heltec CubeCell boards because I was using the wrong Regional Parameters Version. V2 must have been much less fussy, what worked in V2 was not right for V3. In my case, PHY V1.0.2 REV B was what I needed.
Might be worth double checking the correct settings for your node.
Thanks Andy. I’ve checked and double checked with the manufacturer specs but still not working. I’m using AS923 instead of AU915 as I still have sensors running on AS923. Reading around the forum I did noticed quite a number of people are not having downlink working during OTAA, and so device not receiving join-accept. The sensor I’m trying to get it work now is the Dragino LSN50v2-s31. I wonder if migrating to AU915 would help.