Changing gateway's region in TTN Console does not (always?) change downlink frequency


I tested my new device under different region settings and have a strange behaviour.

When i change my settings, sometimes the wrong downlink frequency are used.

For example, i switched to asia settings with the following settings:

When i test the device with a confirmed message the uplink frequency is OK, but the downlink has the previously tested indian frequency:

Switching to another region and back to asia does not solve the issue.

Has anybody an idea what is wrong or have an idea for a workaround?



Several points/issues here:

  1. Downlink frequency is set at the Gateway and uses appropriate local (regulated) parameters, not something changed on the node
  2. Regional parameters are set to meet local regulatory environment and it is not intended that users chop and change at will and whim - likely you are behaving illegally in your region, unless the region supports multiple/overlapped bands (e.g. Australia supports/allows AU915 & AS923, with various sub-bands)
  3. Unless you are operating/testing in a faraday cage/appropriate/approved test set up you are likley interefering with other users in your area in an unregluated/illegal manner (please dont get TTN/LoRaWAN users a bad name/reputation! :wink: )
  4. Often devices will be optimised for the given bands - e.g. with appropriate RF filters etc., so highly likely that devices may be operating sub-optimally in bands other than those for which they have been design/engineered/certified

Where in the world are you? I assume if you started with the IN865 band that you are on the Indian Subcontinent? Unless developing for wider market and needing to test for alternate deployments (under appropriate controlled and regulated conditions) there should be no need for you to switch regional parameters or router environments (operating across alternate TTN router regions often fails and introduces other strange interop issues and shoudl be avoided)

1 Like

Hello Jeff-UK,

thanks for your answer.

Yes, we must test our device for different regions.

We are aware of the need to comply with the requirements of the authorities. Therefore we use a direct cable connection (with an attenuator) and we additonally use a shielded box for the tests. So in this point everything is OK.

Thanks, for the hint, that the downlink frequency is set by the gateway and is not controlled by the server.


No, I don’t think that Jeff wanted to say that the gateway decides on its own. Reading the whole sentence, it’s just not related directly to whatever frequency the node uses for its uplink:

The gateway is told what frequency (and time) to use by the network server.

What does “sometimes” mean?

For the Basic Station LNS protocol, which your unspecified gateway is probably not using, the server might leave the actual choice for RX1 or RX2 to the gateway. But even then the server will be specific about the allowed choices.

Hello Arjan,

thanks for the additional hint. The gateway is set to the appropriate region each time. If i understand it correctly the server controls in this case the used frequency.

To your question “What does “sometimes” mean?”: If i switch between the different regions, sometime the frequency are correct after a switch and sometime not. From what I’ve tried: If it fails, it always fails until I move to another region.


And you also changed the configuration in the gateway itself? (For example: only configuring TTN to use, say, an IN865 gateway as AU915 won’t work. That also needs the same changes in the configuration of the gateway, and maybe a restart.)

I guess you’d better give us all the details of the changes you make, and what works and what not. And as the Router is also shown in your screenshot: are you always using the same (nearby) router?

However: not changing the gateway’s configuration does not explain why TTN Console shows the wrong downlink frequency in your screenshot. :thinking:

Oh: note that your node’s DevAddr also includes details about the region. You might need to re-join after making changes.

I guess it’s just not worth the trouble to re-use a single gateway and test-nodes for testing with multiple frequencies.

1 Like

Hello Arjan,

Yes, our test setup for the region test is always the same:

  1. Set our device to the new region
  2. Set the gateway to the new region (Router & Frequency)
  3. Set gateway settings in TTN to the new region (Router & Frequency)
  4. Perform a join

Another test procedure for example:

Starting with A923. Everything OK
Switching to KR920. Everything OK.
Switching to AU915. It fails. Join accept answers at 921.9MHz (korean downlink frequency)

I guess it’s just not worth the trouble to re-use a single gateway and test-nodes for testing with multiple frequencies.”:
Maybe there is an easy explantion for this behaviour. If it is more complex, i also think that it is the easiest way to have different gateways for the different regions. If you do not have an explantion for this, we can close this thread.



Clearly not a device (node) issue so likley something in the GW &/or GW/NS interaction…which GW are you using? Which Packet Forwarder and you using?

Can data/config info be being cached locally between changes? Is the local file set being flushed on change?

Hello Jeff-UK,

as Gateway we use an indoor gateway type Dragino LPS8. As packet forwarder we use the LoRaWAN/RAW forwarder (a Semtech UDP Packet forwarder does not exist).

I cannot see, if local file sets are stored or flushed on change. I can only see in the log, that the uplink frequencies are correct for the set region.


As an OTAA Join Accept needs a downlink too, I don’t understand how that (apparently) has succeeded, while a downlink after a subsequent data uplink uses the wrong frequency. Also, your screenshot shows that the downlink counter is larger than the uplink counter? The community TTN network only supports class A, so downlinks can only happen after an uplink, so a downlink counter should be at most equal to the uplink counter? I wonder if TTN somehow thinks these are different devices.

Just a wild guess: maybe caching in the different router/handler regions is troublesome/outdated? What if you leave the gateway at the same (nearby) router (say ttn-router-eu), and use the same region for the application’s handler (say ttn-handler-eu), regardless which frequency plan you select in the device (hardware) and gateway (both hardware and TTN Console)?

1 Like

Hello Arjan,

thank you for pointing that out. I tried the ttn-router-asia-se. The result is the same.

Asia OK
Korean OK
Australia failed. Join accept answers again at 921.9MHz (korean downlink frequency)

I think there is no simple solution.

Arjan i am taking your advice: The best way is to buy multiple gateways one for each region.

Many thanks to you and to Jeff-UK for your support.



If you are using the legacy packet forwarder, is needed also to change the router
to Australia 915-928 MHz

@eduardopfeifer Exactly! This is the problem I had earlier this year with an AU-band gateway. I changed the config in the gateway to the proper router, but I may have made a mistake (not save the config or something) and it was still connected to the EU router. This caused the downlinks in RX2 to be sent in the EU frequency of 869.525 MHz, although the gateway was defined in the TTN portal as “Frequency Plan: Australia 915MHz”

1 Like


@eduardopfeifer, @rharte: Thanks for your hint.

This is not the cause of the problem. I have set the correct routers.
In the meantime I have seen that it is enough to wait a quarter of an hour. Then the correct frequency is used.