Say I have an existing application A2 on TTN V2 with end device D (using OTAA) which I want to (manually) migrate to TTN V3.
I therefore create a new application A3 on TTN V3, add a new end device D’ to A3 and enter the exact same AppEUI, DevEUI and AppKey as used for end device D on V2.
There are two gateways, one is connected to V2 and the other is connected to V3. (Traffic from TTN V2 gateways on the backend will also be routed to TTN V3.)
I now switch on the device and it will start sending a join request.
If the device joined on V2 traffic apparently will be send to application A2, and if joined on V3, traffic will be send to application V3.
Questions:
To which environment will the device join V2 or V3 and why?
Which aspects play a role here?
Will the device always join on V2 because that somehow has priority over V3?
Does the device need to be deleted from V2 first before it will join V3?
How is routing between V2 and V3 implemented?
When is traffic routed from V2 to V3 and when not?
Will traffic only be routed to V3 if it cannot be processed on V2?
After shutting down my V2 gateways, the device joined to V3 and messages were delivered there.
I was hesitant to remove my devices from V2, but now I’m sure it’s working on V3, I can safely delete them from V2.
Do you mean it depends on which gateway receives the join request first?
If I’m not mistaken, normally only one gateway will send the Join Accept.
But maybe both V2 and V3 will each send a join accept here. In that case it would depend on from which gateway the device receives the Join Accept first.
I tried to make sense from the information in the V3 Live Data views (gateway, application and device). When the device joins to V2 instead of to V3, there is still a lot of information appearing on the V3 console, but I don’t understand all listed events yet. Several are new for V3.
I noticed something unusual in the V3 console:
In the gateway log each uplink message is received once, but forwarded twice.
The application and device logs show that both message are then received, but one of them is dropped because they are duplicates and the other is processed successfully.
Strange enough the SNR values (not shown below) of duplicates messages are different.
Did anyone else observe this behavior?
[Update]
I noticed that messages arriving from other gateways (other than my V3 gateway) in V3 Console Application and Device Live Data views are shown as separate ‘Received data message’ events. This can also be messages coming from V2 gateways via the packet broker.
(I’m not sure if above is true for messages arriving via the Packet Broker only or for all gateways. I am unable to check because I currently only have a single V3 gateway.)
The duplicate messages described below may be caused by one coming from my V3 gateway (my V2 gateways were shut down during the test) and the other possibly from another (V2) gateway ‘nearby’.
I unfortunately have checked the event details for below messages (events).
If so, that does still not explain why each message is forwarded twice as show in my gateway’s Live Data view.
Situation: only V3 gateway active and testing with a single end device that is registered in a V3 application:
For each uplink message the following appears in the gateway, application and device console logs:
Gateway Live Data view for each uplink message shows: (latest on top, all three have same timestamp)
Forward uplink message
Forward uplink message
Receive uplink message
Application and Device Live Data for above show: (latest on top, all have same timestamp as above)
I have also tried connecting my TTIG gateway to The Things Network V3 stack without success. I can understand that I have to wait a bit in now. However, I have another problem. I can not delete my gateway again ??? Can anyone help with that ?? Thanks in advance
@Jeff-UK was not present this year, I’m working on too much projects on the same time for my brain
About the LoraGW setup I can help of course, and even better, open the repo for you so you can publish directly (without fork and all other) just let me know.
Hi. I tried registering one GW, which is alive in V2 on V3 user interface, but it seems not working. It is TTIG gateway converted to TTOG (plastic housing and external antenna, mounted on my antenna mast). How do I register TTIG gateway on new user interface?
You cant, yet! Per other posts on this subject (forum search is your friend) The TIG relies on a CUPS (server) as it uses BasicStation, and then has some glue/translator s/w to bring the data into V2, which doesnt support Basictation implementations. V3 will support Basistation on TTIG’s natively without the glue but TTF have yet to establish the required V3 CUPS (server) and support. This is due in a few weeks as I understand it. BTW TTOG (The Things Outdoor Gateway) is a thing so if looking for support be careful what you post as they are very definetly not the same thing…what you have is still a TTIG…just in an external housing and with augmented antenna. Note also depending on where you are in the world you need to be carefull addiing an external ant if higher dbi (gain) than the original internal one, unless it is purely to compensate for external cable/connector losses, as higher gain units may lead to your device exceeding local RF EIRP limits, I dont think the TTIG has the flexibility to allow you to dial down the TX power to compensate for this.
A slightly more general question regarding TTIG and TTSv3.
I have a TTIG connected to TTNv2, but my devices/sensors are on TTSv3 and everything works fine until now. I have a monitoring project coming up where the intention was to buy a few TTIGs to install them in different locations, with each one serving a few sensors. This is meant to start in May (or earlier) and last for minimum 6 months, but most likely 1 year.
Is TTIG still a suitable option for this, if all the new TTIGs are put now on TTNv2? or will there be a cut-off point in the next months where they have to be migrated to TTSv3, at which point I won’t have access to the gateways and thus potentially they might also stop working (if there is no online/remote way of doing it) and as a results lose data. I understand that the dates set by TTI might not be fully set yet.
I am asking for some advice, as the budget is limited and TTIGs very well priced compared to other gateways. Looking around, I can see that the DRAGINO LP8 gateway seems like a suitable alternative that appears to work with TTSv3 at a slightly higher cost. Anything else seems too expensive.
TTIG reconfigure for V3 will be a remote operation. The gateway reads it config from a remote server periodically. When the config is updated on that server it will connect to the newly configured backend.
Hello @Jeff-UK, thanks for your precisions. I am new to LoRaWAN and i admit it is complicated to know where to find info from. Do you have any updates about connecting TTIG to TTNv3 since your previous post ? Thanks !
Hello @descartes, that’s exactly the point, it doesn’t work that fine for us and i hoped we could use the v3 console to access some more parameters to tweak
The TTIG uses CUPS to be setup - so in some respects there are actually less parameters.
My two TTIGs are fine, there isn’t a wave of TTIG problems on the forum (today!), so let’s fix yours so it works like everyone elses, because the new shiny v3 isn’t available. I’ll respond to your orphaned thread.
Hahah thanks ! For the parameters, i was thinking about the LoRaWAN network-layer settings (two europen frequency plans variants, schedule downlink late, duty cycle, and schedule any time delay).
