Ah, my bad, I thought you were switching between AS920-923 and AS923-925. But AU915 is indeed using quite different RX2 (and RX1) settings. So:
No; the link I provided earlier states for AU915:
Downlink:
923.3 - SF7BW500 to SF12BW500
923.9 - SF7BW500 to SF12BW500
924.5 - SF7BW500 to SF12BW500
925.1 - SF7BW500 to SF12BW500
925.7 - SF7BW500 to SF12BW500
926.3 - SF7BW500 to SF12BW500
926.9 - SF7BW500 to SF12BW500
927.5 - SF7BW500 to SF12BW500
So, it seems there is no difference for RX1 and RX2.
Also, without knowing what type of gateway you’re using, the following might not apply. But it does not make sense that your gateway needs to know the RX1 and RX2 frequencies:
Of course, that only applies to the frequencies used for RX1 and RX2 transmissions. To listen to the right frequencies, the gateway config should indeed be changed. And I guess you’re right that the backend router URL also determines what RX1 or RX2 is assumed by the backend; see https://www.thethingsnetwork.org/wiki/Backend/Connect/Gateway
And as an aside, “authorisation response” is called an OTAA Join Accept downlink.
Also, things moved on. In the new configurations the minimum (tx_freq_min) and maximum (tx_freq_max) transmission frequencies are specified so any transmission frequency specified by the back-end must be in that range. If not the packet will be dropped.
I updated the remote conf file for my device on github so now the router is set to AS2.
I have the global_conf.json file on the gateway set to that for AS2 also.
Unfortunately the join appears still no to be working.
I have all the server and handler settings set for SE-asia and the band plan set to AS923.
My node is set to understand the 2 primary channels for AS923 and I have also set the RX2 settings for 923.2.
For some reason the TTN console is not showing my gateway traffic now but the device data screen is showing the join request data being received.
gateway and test node all doing what they are supposed to now.
Running on AS923 plan.
Not sure what was going on with the traffic page for my gateway.
I seriously doubt that there is another active gateway in my area.
Maybe it just needed a sleep like me.
So, I have learnt that it looks like you need to use a router that supports your selected band plan. The closer (and obvious choice) AU router does not appear to work with AS plans.
Also, by observing the traffic, I can clearly see that the node is using all the available frequencies and that on occassion Rx2 responses are being seen as Rx1 is most probably being missed due to network latency etc (on account of using a server that is in Asia as opposed to Australia).
All looks good.
Now I can press on with my device development knowing that I have a working gateway/network connection that I can use.
It’s the server (TTN) that decides if RX1 or RX2 is to be used. As timing is very strict (nodes will only be listening for a short time at the start of RX1 and RX2), an RX2 response cannot be received in RX1, nor vice versa.
For future readers: that refers to the router address configured in the gateway, right?
What did you use in the gateway settings for Australia? Did you use router.au.thethings.network in the gateway, as listed in the Server Addresses page on the Wiki? That Wiki shows the following options:
Choose the Router instance depending on the frequency plan used in your region. […]
router.eu.thethings.network # EU 433 and EU 863-870
router.us.thethings.network # US 902-928
router.cn.thethings.network # China 470-510 and 779-787
router.au.thethings.network # Australia 915-928 MHz
router.as.thethings.network # Southeast Asia 923 MHz
router.as1.thethings.network # Southeast Asia 920-923 MHz
router.as2.thethings.network # Southeast Asia 923-925 MHz
router.kr.thethings.network # Korea 920-923 MHz
The geographical location of a server and the supported frequency plans are two different things. As the LoRa Alliance publishes more region specifications, we will deploy Routers in datacenters near that region. Also, the yet to be implemented decentralized routing architecture enables community operators to provide routing infrastructure to The Things Network.
However, I was a bit surprised not being able to select a matching Australian Router in TTN Console, though ttn-router-asia-se is selected as a default when choosing Australia for the Frequency Plan:
I think this indicates one could select any option from the Router dropdown in TTN Console and still get the proper downlink settings as long as the gateway uses the router that matches the frequency plan.
So:
For “Australia 915MHz”, did you select the default ttn-router-asia-se in TTN Console while using router.au.thethings.network in the gateway?
For “Asia 923-925MHz”, did you also select the default ttn-router-asia-se in TTN Console while using router.as2.thethings.network in the gateway?
(Wow, this is confusing, “pick a router that is in a region which is close to the location of the router itself”!? It seems “router” is used for two different things here?)
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.
And unfortunately, 
. AU915 has support for the entire band in 8 channel sub-bands as you suggest.