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.
. AU915 has support for the entire band in 8 channel sub-bands as you suggest.
