I have a set up problem with my gateway.
I am trying to get my gateway working in Australia and have been trying to use either the AU915 or AS923 band plans.
I think I have everything set correctly but I can not seem to get the registration acknowledge to be seen by the end node.
I can see traffic on the gateway traffic page but the authorisation response frequencies do not appear to agree with the LoRa standard.
The log shows that the authorisation response is either being sent out on 923.3 or 923.9MHz.
I believe that for AS923 (the plan I currently have set) the response should go out on 923.2Mhz.
For AU915 the response should only go out on 923.3.
Can someone please help outline how the TTN system sets these frequencies, and other associated parameters, in the gateway and what I might need to do to set my system up correctly (to work with either AS923 or AU915).
I think I may have worked out what is going on.
When changing from the AU915 to AS923 plans I forgot to update my device specific json file on github.
This file specifies the router as the au one.
I think I need to change this to the AS2 one to work with my changed settings.
So just changing the band plan settings on the console does not appear to be the complete answer. I think you need to change the router details in the json files also.
It would help if someone could confirm that this in fact the correct behavior for the system.
I will be testing further over the next few days.
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
And unfortunately,