I’ve just created my first device in the V3 stack. I also have a TTIG gateway. My hardware is built on the Murata ABZ modem running stock AT firmware. When I initiate a join on the module, and I go to the V2 console and look at traffic on my gateway I see the following:
From the hardware’s point of view, the process fails to join, and that is consistent with the presentation in the V2 console as compared with successful joins of V2 devices. When I go over to the V3 console and look at the “Live Data” feed from the device while it attempts to join I see this (this is the tail end anyway):
That’s a lot of activity, but it doesn’t culminate in my device recognizing that it’s connected. Can anyone help me to understand what I might be missing here?
Been doing similar tests today, I’m beginning to suspect that V2 gateways can’t transmit V3 OTAA join accepts, but that’s a working theory, not fact. I’ll report back when I have more detail & wine.
Today I took my V3-registered end-device over to another building to try it out there and it worked. The other building contained a V2-registered Multitech MTCDT-246L Gateway (specifically ttn-ithaca-00-08-00-4a-3c-f6). So… I think that definitively implies a back-end (?) problem specific to TTIGs. Can anyone from The Things Industries chime in here? Happy to provide links to the V2 console pages for the Gateways that I’m using for testing.
If nothing else, my experience from today demonstrates that the problem is not with all V2-registered gateways.
Been hacking away on exactly this issue and some other more depressing issues involving owning a pile of PCB’s I thought I might have to scrap if I couldn’t get the dumber device to work with v3.
Got it working on a v3 on OTAA (hurray) with downlinks (double beer bonus).
Just turned off the v3 gateway and the device under test joined OK and received a downlink.
Probably not politically correct for me to say, but I suspect there is still some work-in-progress going on behind the scenes of TTN v3 and some days are better than others (qf packet forwarder issues on Sat).
We (the mods) have done our best to ask people to figure out the moving parts before any migration of any element and then do cautious tests, preferably with spare gateways & devices. It’s only really been a month, there’s still much to learn, try out & formally test.
The TTIGs do have a tendency to sort of go to sleep if they haven’t had an uplink and with the packet broker in the way there may be some latency issues to solve.
Overall we are still of the opinion that moving gateways should be done at the very last moment. With the TTIG that’s not in anyone’s control as they will migrate when CUPS allows. So any device reliant on being heard by a TTIG shouldn’t really be moved to v3 until the TTIG update is available.
@johan, if we do not put an entry in the v3 console, does this mean our TTIG will stay on v2?
They can be migrated by the owner when the new user interface is available. I didn’t get the impression TTN will force a migration. In that case they would not have to create a user interface as they have the means to mass migrate TTIGs now.
OK, I just brought the V3-registered end-device home and it was able to send data through the V2-registered TTIG gateway now. I’m not sure if that’s because it successfully joined by way of the V2-registered MultiTech gateway earlier today… or if it was just luck / coincidence. I’ll learn more by trying to register more V3 end-devices.
my second V3-registered end-device joined and sent data without a hitch via the same V2-registered TTIG now. I think we’re going to have to conclude that I am a victim of circumstance, I’m afraid.
my second V3-registered end-device joined and sent data without a hitch via the same V2-registered TTIG now. I think we’re going to have to conclude that I am a victim of circumstance, I’m afraid.