One information if someone have the same issue => when debugging on US915 with a EU868 gateway around both gateway capture the traffic… as a consequence it is a mess as the device is registered twice on TTN and downlink not necessary goes to the right gateway. The use of an attenuator fixed it.
One question:
Since 2 days have an issue: I’m joining network (US915). then I try to do uplink with ack to get downlink and adr. I’m seing the message uplink from the gateway page
but i don’t see it in the Device Data page
I also not see the Downlink response (and I do not get downlink response)
According to the documentation your 0x26012EBC DevAddr seems to indicate it is still being assigned an address for the EU-region:
Within TTN, we assign device address prefixes to “regions” (for example, device addresses in the eu region start with 0x2601).
I don’t know if the documentation is current, and if it matters, but my guess would be that the gateway settings in TTN Console still use the EU router? Or the node’s configuration in TTN Console is still set to use the EU handler?
Maybe people from different regions can post some prefixes here.
Do you mean it’s configured in TTN Console twice? That’s easily solved by removing one?
In case you did not know: devices do not send their uplinks to a specific gateway. Instead, they just transmit, and zero or more gateways might then receive that uplink and forward it to their network. If the network recognizes the device that sent the uplink (here: TTN; any other network will just drop the packet), then it determines which gateway is used for a downlink based on things like signal strength and duty cycle of the gateways that received the uplink.
A network will never make a gateway transmit a downlink if said gateway did not receive the uplink.
Forget this part it was an information, not a question : When you have 2 gateways around, one on US915 and another on EU868, both are capturing the traffic and respond with a joinAccept on different frequencies due to the signal straight too high for a correct frequency isolation.
Thank you for this element. The device has been registered on EU868 but now I don’t see it on the EU868 Gateway traffic and the join accept is coming from the US915 gateway.
The gateway is configured like this:
The gateway itself is connected on:
“server_address”: “router.us.thethings.network”,
In the device itself I did not saw any setting related to location in the console. The device is setup (by TTN) to the corresponding address by I do not see how to clear it:
If it comes from the device adresse How do we manage device moving from a zone to another zone properly ?
If both respond with a Join Accept, then apparently the network is indeed segregating the network for different regions, boldly forwarding the handling to multiple regions as it’s not expecting multiple regions to handle the same uplink. (I’d expect the Join Accepts to have different values for DevAddr and secret keys then.)
When moving the device further away from the gateways you might see that only one is receiving the packets?
I was wrong about the devices; it’s the applications that have a setting for the handler, while in TTN Console devices should then be registered to a single application:
That has indeed not been implemented. Even within the single world-wide TTN community network, I’d assume this needs some roaming just like when it would be different networks, but as far as I know, roaming has not been specified yet, let alone implemented.
You cannot clear the DevAddr; a new OTAA Join will get you a new DevAddr.
I don’t know if changing the handler for an application is properly supported. Maybe deleting and re-creating is a better option.
Moving applications to a different region is not supported, but you can move devices from one application to another if required.
Check this message for a reference to a script to move devices between applications.
But, wait: even if the above is true, then only one of the regions would have an application that knows about the device? Or did you create multiple applications (for different regions) that know about the very same OTAA device, and use the same DevEUI, AppEUI and AppKey? Only when all match, multiple handlers could accept the OTAA Join?
The reason why the two gateway got the message is just the proximity … forget that point in fact. It was just to share my experience if someone will be in the same situation with different gateways, it can create a mess on the communication …
I cleared the device => by creating a new one …
I’ll create a new App, I did not know we have that feature at app level. And I will let you know. (the strange thing is : is was working past weekend)
Currently the US915 gateway is not able to be seen by the US router since 51 minutes. As my other gateways are working on EU area, I assume you have something down on US server, I’ll wait the link to be re-established.
Yeah, I saw you mentioning “forget that” earlier, but: you’ve got a 0x2602 DevAddr now, so I’d assume it was really related.
(As an aside" “both” in “both respond with a Join Accept” referred to regions/handlers, not necessarily gateways.)
For future reference: did you indeed create a new one, and did see which handler the previous one was using? And has there always been just a single application (at least: one that knew this device)?
I’ve created a new one on ttn-handler-us-west the original on was on ttn-handler-eu. The application was created specifically for this device. The device connect for the first time to this application from US915. The gateway use router.us
Previously, the application was on ttn-handler-eu, the gateway configured on US915 frequency. At first the gateway were connected to router.EU. In this configuration the device has communicated for the first time. Then the gateway was connected to router.US.
