I’ve tested this in the US and it works, but it’s somewhat tricky.
What exactly do you mean by “V3 device”? Do you mean “device registered with the TTN V3 console with a V3 application”?
To avoid confusion, I’ll refer to the ultimate consumer of the data (generally not the TTN console) as the “server”. It might be a service like MyDevices, or you might be running some other application.
Have you checked the TTN V3 console data display? Is data getting there? If the device is joining, data is almost certainly getting there. It’s hard to see how you could join, but not be able to get data to the console.
The routing of the V3 application to your server generally is different than the routing of the V2 application. Depending on how your server works, , and requires (essentially) entering a second connection, possibly both at the server and at the TTN V3 console.
With V3 I mean the device that sends data to Datacake via TTN V3. The other device sends via TTN V2 to the same Datacake application. I have not seen the packages getting lost either. So far, both devices have run stable. Thanks for your support. If the test is successful I would give the link on your git to the developers of the software if that’s ok.
Sure. In fact, I’ve structured things to allow sending a clean pull request to them once we confirm that everything is working well. Everything is documented at my repo in case they don’t want to wait for me to do a PR. I’ve made changes to HEAD as well as the 1.14.0 release (which required a new branch).
Both devices ran stably and without problems over the weekend. The only difference to your fork is the call in multigeiger.ino to poll_transmission () in loop ().
From my point of view you can send the pull request with this adaptation.
Thank you again for your support.