Hi @davo30au and @dbrosy, I replied to you yesterday but I can’t see my posts on this thread, so trying again…

In addition to @arjanvanb’s reply,
AU915 UDP gateways should point to
AS923 UDP gateways should point to
AU915 and AS923 MQTT (and other) gateways should point to (or

Nothing has changed in this respect, but the recent (8-Jul) upgrade means that incorrectly configured gateways will end up with the wrong downlink frequencies, hence why joins will fail.

Running ttnctl gateways info might show the incorrect band plan for your gateway. Don’t worry about this, it is incorrect. It’s because ttnctl doesn’t support the new V3 gateway offloader completely.


Just to be sure: “incorrectly configured” refers to using the wrong URL, right? (Not to some mismatch in Meshed’s Console, which only then yields wrong frequencies for gateways that also use the wrong URL.)

incorrectly configured

Good point. I was referring to gateways using the wrong server address, but they need to be configured for the right band plan in the console too.

So the gateway’s frequencies in global_conf and the server URL in global_conf (or local_conf) and the Frequency Plan in the TTN Console all need to match.

1 Like

The main Semtech UDP forwarder page could do with an update to reflect getting AU915 onto an explicit address.

I created a pull request to reflect this.

1 Like

This fixed my issue. awesome thank you

Hi @Maj, I’m having similar problems to those mentioned in this thread where the gateway is being instructed to use a different download frequency band to the upload frequency band. I’m based in NZ and trying to use the EU_863_870 frequency plan. The uplink frequencies are in the 860 MHz range but the gateway is being told to use a downlink frequency of 923.3 MHz.

Running ttnctl gives:

ttnctl gateways info <gateway-eui>
      Gateway ID: <gateway-eui>
  Frequency Plan: EU_863_870
          Router: meshed-router

ttnctl gateways status <gateway-eui> --router-id meshed-router
  Frequency Plan: AU_915_928
          Bridge: gs.v3.

I’m using a Semtech UDP type gateway and I’ve tried routing to, and, and but it all results in the same behaviour.

I’m reasonably new to TTN and have read the associated slack thread but have run out of ideas. Do you know of a way to change the frequency plan of the underlying gateway status to be EU_863_870?

Hi @Maj

Thanks for the concise set of links. BTW, this is the first time I have seen the need for a gateway to point to , I always thought it was for Au915. That’s the address published on TTN web site when registering a new gateway.

Couldn’t work out why I had never seen this before and went and searched and from what I can see this is the first time “” has been published on this forum.

I’m wondering if some of this can be rationalised and realigned with the TTN naming convention used elsewhere around the globe by editing the DNS records for some of these domains.

Just a thought.


Thanks @TonySmith, the problem is that on V2, each bridge handles a different gateway type. AU915 UDP, AS923 UDP and MQTT (both AU915 and AS923) are handled by different bridges.

On the V3 architecture, one Gateway Server will handle all those gateway types, as well as Basic Station, so there will eventually be just a single endpoint - which I envisage will be or (same endpoint, different DNS entry).

So yes you’re right, these should come together soon. When they do, we’ll leave the existing DNS entries indefinitely, but consider them legacy and all new gateways can point to the primary site.


Heads up for those not on Slack:

@Maj 2020-07-28 02:53 AM

Hello Australia users. Please be aware that at 4:15pm AEST we will be resizing the Australia cluster to improve performance and address a couple of related issues we are seeing. If all goes well, it will take less than 15 mins. Please direct any replies to the #australia channel.

See also How do I get a Slack invite?

Oh, wait, maybe that already happened, Time in Australia now -

Thanks @arjanvanb. Yes, upgrade has been performed now.

Hello everyone (@Maj), how are you doing?

I’m wondering if there’s any current issue with the Meshed router? I have some configuration where the Gateway is sending data to the Meshed Router (udp:// and the Application is based on the Asia-SE Handler (ttn-handler-asia-se).

The behaviour is that I can see messages arriving in the Gateway “Data” tab, but nothing arrives in the Application “Data” tab.

ps.: I can’t migrate the Application to the Meshed handler because this is using an HTTP Integration, which is not available in the Meshed handler.

edit1: I have tried on a test gateway to use another router and that works fine. So it seems to be an issue for messages coming from Meshed gateway to be delivered to Asia-SE handler.


Hi @wisen, it’s the cross-region routing issue that we seem to experience on and off. (worldwide issue)

You can add any integration you like, but you need to use the local console to do it.

Thanks for the update and local console URL. I’ll check how complex can be to migrate the application the Meshed handler.