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.
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 https://www.thethingsnetwork.org/u/SydneyWater - Meshed - South Windsor - AS923 ?
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?
Uplink:
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
Downlink:
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?
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.
