TTN gateway for owner only?

Are all TTN gateways public access? I’m trying to join a device to TTN here in Windsor NSW. The only gateway in the district belongs to Sydney Water. I see a new row with time, dev addr, app eui, dev eui for my device on the data console each time it tries to join but it never happens & I’m wondering if that’s because the gateway is for Sydney Water only?

All GW’s are open to all on the TTN irrespective of the privacy settings on the consle page - that serves to limits public disclosure of certain information - inc. if location set to private - actual location/position/existance of the GW on the TTN map… though application would show receipt of packets forwarded from any such ‘hidden’ GW fact you can see as belonging to Sydney Water suggests not set as private…

GW’s placed on a priavte networks and under TTI would not be visible/shared and unless packet broker instanciated traffic would not reach application/console.

That’s an activation. So, that gateway (and/or one or more other gateways) received the Join Request and forwarded it to TTN, which accepted it, assigned a new DevAddr, and will have instructed (one of) the gateway(s) that received the Join Request, to transmit a Join Accept.

So, your problem is not that the gateway is not forwarding your device’s join request.

So the gateway is either not sending the join accept or, if it is, I’m not receiving it? Any idea which is the more likely? Am I right in thinking that if the gateway is receiving my join requests that my device must have the correct settings to receive the join accept?

I guess it’s more likely the device is not receiving it. But if the OTAA Join Accept downlink arrives at the gateway too late due to network latency, then it may be unable to transmit it. You may want to use Meshed to avoid regional traffic.

Your OTAA settings are indeed okay. But not because a gateway is receiving the join request: a gateway does not know what it’s receiving, it just forwards it to TTN. But you know the OTAA configuration is correct because TTN accepted it, and assigned a new DevAddr and updated the “last seen” timestamp in the device’s status.

Other device settings may still be incorrect, making it listen to the wrong channel for the downlink. There’s also a small chance that the gateway configuration is using the wrong frequency plan, but its owner would probably already have noticed that.

Your link seems to be related to gateways? I can’t change anything on the gateway I’m trying to use because it’s not mine (belongs to Sydney Water). I’ve had several goes at configuring applications on the ttn console using various handlers (ttn-handler-asia-se or meshed-handler), all have the same problem (join requests received on the uplink) but no join accept on the downlink. Googling seems to suggest that its common for gateways (like Sydney waters multitech) & devices (like my pycom lopy4) to have different versions of so called band plans in them. Seems to me that pulling off a join is the perview of a technical elite for the time being.

Why? I see:

See also But I hope there’s no overlap between the several options?

And given the ID of the gateway you can get the frequency plan from URLs like

Do you know how I can find the gateway ID? Right clicking on the gateway on the coverage map just has a name

It’s in the metadata when clicking the Activation, in "gtw_id": "arjanvanb-gw-1" below:


Also, when subscribing to the device events (or simply the wildcard #) of the MQTT Data API, you’ll also get it:

  "app_eui": "70B3D57ED0014D45",
  "dev_eui": "0004A30B001C1D1E",
  "dev_addr": "26012B0F",
  "metadata": {
    "time": "2020-10-12T12:39:03.735498171Z",
    "frequency": 868.5,
    "modulation": "LORA",
    "data_rate": "SF7BW125",
    "airtime": 25856000,
    "coding_rate": "4/5",
    "gateways": [
        "gtw_id": "arjanvanb-gw-1",
        "timestamp": 2632004427,
        "time": "2020-10-12T12:39:03Z",
        "channel": 0,
        "rssi": -49,
        "snr": 6.5,
        "rf_chain": 0

See also Determine which gateway is used by a given node.

I clicked on activation in the data window showing my latest attempt at joining & the page just went blank?
Could I get it from a database somewhere with something like - Meshed - South Windsor - AS923 ? should get you going? For example, it explains how to search by location.

Peeking in I assume all those Sydney Water gateways are owned by @maj, so you can be sure their configuration is very much okay. Hence, if there is no overlap in uplink channels for the frequency plans (which I did not validate), then I’d assume that the gateway would support the expected downlink channel when it has forwarded the uplink. (Just very much assumptions though.)

You may want to move closer to the gateway for testing?

Aside: subscribing to the MQTT events and persisting those will really help debugging.

I found the gateway in the list you linked.
“eui-00800000a0004dc1”:{“id”:“eui-00800000a0004dc1”,“description”:“SydneyWater - Meshed - South Windsor - AS923”,“owner”:“maj”,“owners”:[“maj”], “location”:“latitude”:-33.62514114379883, “longitude”:150.80197143554688, “altitude”:66},“country_code”:“au”,“attributes”:{“brand”:“MultiTech”, “frequency_plan”:“AS_920_923”,“model”:“Conduit”,“placement”:“outdoor”},“last_seen”:“2020-10-12T22:12:54Z”}
It says the frequency plan is AS-920-923 but it’s clear from your other link that there are 2 plans for that band AS1 & AS2. How can I find out which one it’s actually using?

I don’t understand why devices apparently get a list of frequencies to use after they have joined? It seems to me they need the list before otherwise they can’t receive their join acceptance?

Looks like the AU bandplan is AS1

923.2 - SF7BW125 to SF12BW125
923.4 - SF7BW125 to SF12BW125
922.2 - SF7BW125 to SF12BW125
922.4 - SF7BW125 to SF12BW125
922.6 - SF7BW125 to SF12BW125
922.8 - SF7BW125 to SF12BW125
923.0 - SF7BW125 to SF12BW125
922.0 - SF7BW125 to SF12BW125
922.1 - SF7BW250
921.8 - FSK
Uplink channels 1-10 (RX1)
923.2 - SF10BW125 (RX2)

My guess is that the problem with the missing join accepts is that the region=LoRa.AS923 line in my lopy4 code is not implementing those downlink frequencies.

Most LoRaWAN gateways only support 8 channels, but LoRaWAN allows for many more. Often LoRaWAN then specifies a set of default channels that all networks (such as TTN) should support for a region, and a network has to make a choice for its additional channels. In regions that support getting a list from the network, the device first uses that limited list of default channels to join (or to try to join, if even that shorter list may not be supported by all networks). After joining, it then gets the full list in the CFList of the Join Accept (if supported, like for EU868 and AS923), or sometimes in the initial ADR request (like for US915 and AU915).

I would guess that if a library offers a setting for a region, that it would then also implement the downlink settings. But you’d have to look at LoPy’s documentation.

Note that the downlinks are not specific for TTN; they are configured using the CFList (if supported) the DLSettings in the Join Accept and then derived from the uplink details. And the rules for that are in the LoRaWAN Regional Parameters specifications. For most regions, a LoRaWAN compatible OTAA device does not need to know anything that is specific to TTN. (I don’t know what’s needed for AS923, nor if AS923 in Australia needs anything special.)

Your device may simply not receive the OTAA Join Accept downlink at all? Take it outside, closer to the gateway?

TTN, not exactly plug & play eh?

Hi @kjm1102, it’s more like food.

You can read the standards documents, write your own code and develop your own hardware = Grow your own food. And learn a lot about gardening.

You can buy and use interesting ingredients and cook your own dish = TTN. And learn a lot about food.

You can go and eat at McDonald’s = Main commercial IoT networks. And pay a lot and get ill.


I tried a different lopy4 & got some console metadata
“time”: “2020-10-13T21:56:51.596937131Z”,
“frequency”: 923.2,
“modulation”: “LORA”,
“data_rate”: “SF10BW125”,
“coding_rate”: “4/5”,
“gateways”: [
“gtw_id”: “eui-00800000a0003c29”,
“timestamp”: 1826404028,
“time”: “2020-10-13T21:56:51.593836Z”,
“channel”: 0,
“rssi”: -121,
“snr”: -10
“gtw_id”: “eui-00800000a00056b7”,
“timestamp”: 1766886308,
“time”: “2020-10-13T21:56:51.593806Z”,
“channel”: 0,
“rssi”: -109,
“snr”: -7.2
“gtw_id”: “eui-00800000a0004dc1”,
“timestamp”: 1677602428,
“time”: “2020-10-13T21:56:51.593772Z”,
“channel”: 0,
“rssi”: -119,
“snr”: -3.8
“gtw_id”: “eui-98208e00000000ce”,
“timestamp”: 2142531180,
“time”: “2020-10-13T21:56:50.593757Z”,
“channel”: 0,
“rssi”: -88,
“snr”: 9.2
sadly still no indication as to if a join accept was sent or not.

As far as I know the CFlist is to configure the allowed uplink channels.

The downlink channel rfor RX1 is chosen by some regional rule that maps the uplink channel, for RX2 it is fixed to a regional default.

When eg TTN EU868 alters the RX2 downlink frequency, that would be done with a RXParamSetupReq MAC command.

Incidentally not all regions even support the idea of a CFList. AU915 does not support having a CFList, but AS923 does.

For AS2, any idea where I can find the ‘regional rule’ for the Rx1 window downlink frequency and the ‘regional default’ for the Rx2 window downlink?

That would be in the regional parameters document from the Lora Alliance. Available here. However your firmware needs to implement these settings correctly, there is not a lot you can do from ‘userland’ on a Lopy.