Your last paragraph in () sums it up beautifully.
Unfortunately the Australian plan AU915 has a number of contradictions.
The simpler AS923 plan appears to be gaining growing support here. It has already been adopted by LoRaTAS as it is seen as a cleaner path to obtaining plug and play node hardware from our Asian neighbours. If we were to adopt it in Australia it would solve a heap of very obvious issues (even to a new comer like me).
Hopefully there will be some other Australian based routers that will pop up soon with support for the AS923 AS1 or AS2 (or both) plans.
For my settings:
I originally selected router.au.thethings.network in my gateway when I was trying to get the AU915 plan to work. But because of firmware issues in my test node, RAK WisNode, I gave this away.
I then changed the plan in my gateway to suit the AS923 AS2 plan. However I forgot to change the router setting. This is where I ran into trouble. I thought be leaving this set to a close router was the right thing. I failed to realise that the au router does not support the AS923 plan.
I now have the router set for as2.thethings.network and I am using the ttn-router-asia-se settings on the console for compatibility. I am not sure that this is strictly correct or necessary, but it works. Albeit with a latency penalty.
I hope that clears up my trials and tribulations a bit.
Ah, it seems that for Australia one could use the first option, meshed-router, to reduce latency:
$ host thethings.meshed.com.au
thethings.meshed.com.au has address 52.62.83.250
$ host router.au.thethings.network
router.au.thethings.network is an alias for thethings.meshed.com.au.
thethings.meshed.com.au has address 52.62.83.250
(The matching IP addresses are just a coincidence; for asia-se.thethings.network vs router.as.thethings.network, router.as1.thethings.network and router.as2.thethings.network this is not the case.)
Reading through this thread I realise how confusing this must be for those that are new to this
The main issue here (which you have already worked out) is:
You must set your gateway’s band-plan in the Console to match that of the gateway-bridge you are connecting to. So if you are connecting to meshed-router aka router.au.thethings.network you must use AU915. Nothing will stop you setting it to AS923, but it won’t work that way.
The good news is that we will soon have an AS923 bridge running in Australia, alongside the AU915 bridge. I will update this topic once it’s live. Also keep an eye on #australia in Slack.
So when using router.au.thethings.network in the gateway settings, and selecting “Australia 915MHz” in TTN Console, one could still choose any value for Router in TTN Console? (Though for smallest latency one should best use meshed-router in TTN Console?)
Is the setting for Router in TTN Console even used for non-TTN gateways…?
Maybe that should read “pick a router that is in a region which is close to the location of the gateway itself”?
That sounds like an issue to me. How can we expect casual users to know which routers use which frequency plan? IMHO once a frequency plan has been chosen the list of available routers should match the ones implementing that frequency plan to prevent mistakes. Is it time for a feature request? (@htdvisser)
Just curious…: so then the gateway is not configured manually to use one of the router addresses as listed on the Wiki, but that is taken care of by selecting a Router in TTN Console? If true, there must be some mapping between that list on the Wiki and the choices in that dropdown?
This used to be straight forward when there was a 1 to 1 mapping.
ie. If you were in Australia, you selected the Australian frequency and connected to the Australian router.
Now we have choice, and that has complicated things
It certainly looks like I have stirred up a hornets nest here.
All I was trying to do was to learn a little bit about TTN by going through the process of setting up a gateway and connecting some nodes.
A length, complicated and confusing experience.
Surely there are some improvements to be made. Particularly for a publicly accessible network.
Maybe we can accept a little complication in setting up a gateway. But the documentation??? needs to at least be clear and CONSISTENT.
The end user connection experience needs to be as close as possible to plug and play. This effectively means that an end user should be able to buy a device off the shelf, log into TTN to configure it and then turn it on. If they are in range of a gateway then the unit should register (otaa join) and everything should work.
Sadly, at least in Australia, we are a still some way away from that.In my mind, adopting the more recent AS923 plan goes some way to addressing this.
Arguably the AS923 plan ultimately will not be able to deliver the capacity required.in high density areas.
Maybe there is scope to have a new plan for Australia (similar to AS923) that is built on similar theory to the AS1 & AS2 setups (sharing 2 common channels) but has multiple 8 channel sub bands defined to fill the entire available spectrum (915-928). That way a consumer could purchase a device off the shelf that has the 2 basic channels enabled and connect anywhere within Australia. The gateway they connect to would simple issue the device with the additional channels on joining. No complicated configurations or special device firmware required and compatibility is maintained with SE Asia.
Surely there are some improvements to be made. Particularly for a publicly accessible network.
Maybe we can accept a little complication in setting up a gateway. But the documentation??? needs to at least be clear and CONSISTENT.
Remember that we are all in this together. TTN is free to use and the documentation can sometimes lag the current release. You can contribute to documentation if you find something out of whack.
The end user connection experience needs to be as close as possible to plug and play. This effectively means that an end user should be able to buy a device off the shelf, log into TTN to configure it and then turn it on. If they are in range of a gateway then the unit should register (otaa join) and everything should work.
This is typically what happens in AU915 today. We’ve configured many kinds of devices for our customers. It’s usually a matter of setting AppEUI, AppKey and Frequency Sub-band. In some cases, there’s no config required at the device at all, and you can just add the programmed AppEUI and DevEUI to your TTN Application.
It’s just as easy on AS923 as well, in fact since there’s no FSB it’s one step easier.
Maybe there is scope to have a new plan for Australia
That would completely negate the benefit of going with AS923! Wasn’t that the point of this topic in the first place . AU915 has support for the entire band in 8 channel sub-bands as you suggest.
There is nothing more inherently complex in AU915 than there is in AS923. Getting devices configured either way is relatively straightforward if you understand the parameters.
Sorry to offend anyone here. That was not my intention.
My comments are based on my experience with purchasing equipment out of Asian (which is where most of our stuff come from anyway) and trying to get it going in Australia.
I admit that my experience has probably been coloured by poor firmware support in the devices I have acquired.
I would be happy to contribute to the TTN documantation, but I haven’t worked out how to do that yet. Another learning experience I guess.
So, theoretically the experience of setting up an AU915 system should be simple. Buy a device and plug it in??? Where do the suppliers get the requirements on which to build their compliant firmware? If it was simple, why did a known, but new, supplier of LoRa equipment appear to get it wrong? The advantage of using the AS923 plan is one of shear volume/market size. Did the guys in Tasmania get it wrong?
I still believe it should be possible to establish a plan for Australia and even New Zealand, that is based on a superset of the AS923 plans. This would enable devices manufactured for these plans to happily operate within AUS/NZ. If we need the extra bandwidth then we simply adjust gateway parameters to suit.
To use an off the shelf node device in Aus against the AU915 plan, it is my belief that you still have to tell the node to restrict its channel use to a subset of those available to work with a particular gateway. This implies that you have some way to access a node to do this. This is not always the case.
AS923 setup, due to its simpler channel structure and common base channels does not need this step!
I agree that from an 8 channel gateway perspective there is little difference in setting up an AU915 vs AS923 system.
It should be all about the end device that the customer has.
From a consumer perspective you shouldn’t have to read the entire instruction manual before you turn a device on. Operation should be as intuitive as possible.
My 2 cents worth, from an end device hardware development perspective.
Sorry, I am getting too old and too impatient these days.
I will leave this sit for the time being while I have a bit more of a look at the AU915 setup.
At the moment the AU915 plan is the only officially supported channel plan to be used in Australia. We indeed received requests for adding support for AS920-923/AS923-925 and are working with our Australian partners (@Maj from Meshed) to support these as well.
These difficulties are mostly caused by the UDP protocol that many gateways use. Forwarders that use MQTT or gRPC inform the network server about which frequency plan they use, and then everything should “just work”. With UDP forwarders we used to “guess” the frequency plan from the uplink frequency, but that doesn’t work anymore, so we determine the frequency plan from the address they forward to. That works pretty well when people follow the LoRaWAN specification and the regional settings that come with it, but things indeed become complicated when our Aussie friends don’t use the Australian frequency plan. Our upcoming v3 backend will hopefully make these things a lot simpler, but until then I’m afraid we’ll have to survive with the current situation.
So where are we with the AU915 and AU923 bands. (By the way is AU923 even a valid band, or should we stick to calling it AS923)?
I have a TTN gateway and have chosen the Australian ‘meshed-router’ and set my gateway to AU915. It works with my LoRa devices which send on 916.8 MHz as the first available frequency. (Not sure why it is called AU915 and not AU916.8)
The uplink frequencies in AU923 are almost identical to the downlink frequencies in AU915, will that cause problems?
AU923 indeed doesn’t exist; its official name is AS923. The official name for AU915 is AU915-928, but we usually shorten it to AU915.
There are a number of countries where both AU915 and AS923 are legal:
Australia, Bolivia, Chile, Ecuador, Guatemala, New-Zealand, Panama, Paraguay, Peru, Salvador, Uruguay
As far as I know the LoRa Alliance still recommends using AU915, as with its 64+8 channels it has significantly higher capacity than AS923 where all devices must share the same 2 channels. Hardware that supports AU915 can be made work on AS923 using a firmware change, but hardware that is specifically built for AS923 might not be able to work on AU915. So if you’re building hardware in a country that allows both, you’re probably best off by building something that can work with both.
LoRa signals for uplinks and downlinks use different polarization, so this typically shouldn’t lead to problems.
What htadvisser correctly referred to is Lora modulation polarization that allows uplinks and downlinks to share the same frequencies. It also helps that GW traffic is not picked by other GWs and it also helps that end nodes don’t pick TX from other nodes when they are listening in their RX window.
In general there is no need to worry about it at all. It is all handled on the LoraWan stack level.
Thanks for that clarification, I was automatically thinking antenna polarization when he referred to radio waves. But, since he was referring to the modulation polarization that comment now makes sense.
And unfortunately, 
. AU915 has support for the entire band in 8 channel sub-bands as you suggest.
