@mcvoltaic I believe thanks to @adrianmares this issue was fixed after modifying the traffic flow in nam1.
@cndrxn That is correct, there was a problem between the traffic flow of the things.industries network my application was running on and the things.network network the gateway was registered with.
I moved the device to an application on the things.network and changed the LoRaWAN version to 1.0.3 and was able to successfully transmit data to the gateway.
Thanks to everyone who helped workout my issue.
@adrianmares, was this a Packet Forwarder issue and was it a one-off glitch or something we should be aware of?
I’ve a TTIG on my Discovery instance so it’s not something that’s tripped me up (yet) but I’ll go and look at the meta data to see how the uplinks are being routed.
@cndrxn was kind enough to provide a TTI instance for those who attended the GNSE workshop so there may be a few others with gateways on TTN using their shiny TTI instance.
Packet Broker uplink message routing is based on device address blocks. These device address blocks allow us to efficiently route LoRaWAN traffic based on the device address of the message.
The GNSE workshop instance had a device address block allocated only for the eu1 cluster, while @mcvoltaic has been trying to use it in nam1, and his gateway was connected to TTSCE nam1. Since there was no block allocated in Packet Broker for nam1, only the join requests where visible, but uplink traffic was not routed.
For the record, the GNSE workshop instance is not really required anymore. It is now possible to claim a Generic Node on TTSCE in all clusters, in order to use it with the secure element.
1 Like
Understood.
Excepting that it gives us a full fat instance to play with - nom nom nom!
1 Like