Understanding how Rx2 frequencies are established (trying to use AS923 instead of AU915 in Australia)

Well.

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.

It all sounds simple doesn’t it???

Cheers

Peter.

1 Like

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 :slight_smile: . 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.

That’s a mistake, I’ll ask someone to fix it.

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.

2 Likes

We get bored easily and like to cause trouble :wink:

1 Like

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.

So does the TTN gateway when purchased as 915 MHz support the AU915 64 + 8 channels?

Radio waves for uplinks and downlinks use different polarization, so this typically shouldn’t lead to problems.

Can you elaborate on this comment, I’m of the understanding that both uplinks and downlinks use vertical polarization.

Perhaps I can clarify a bit here:

Original question was:

htadvisser answered:

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.

Hope this helped a bit.

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.

Sorry for the confusion. I updated my post to clarify that it’s about LoRa :wink:

1 Like