Im starting to wonder if the RAK831 is sutiable for use with the AU915 band, since it only covers 8 frequencys.
i have had some discussions with microchip today… Out of the box the device is trying to join on channels that the RAK831 is not listening to…
Yes, this is what we were also reviewing. The configuration file shared by you is only enabling 8 channels while our default setting are as per Lorawan specifications (which says 64 channels for 125 KHz and 8 channels for 500 KHz). Device can send a join request randomly on any of the 72 channels.
I will need to check with the software team on how to make the settings for 8 channels on the device. Once I have the update, we will let you know.
On the other hand: a device should not join too often (possibly only once in its lifetime), and the procedure to join is well documented. For 1.0.2:
If using the over-the-air activation procedure, the end-device should broadcast the JoinReq message alternatively on a random 125 kHz channel amongst the 64 channels defined using DR0 and a random 500 kHz channel amongst the 8 channels defined using DR6. The end device should change channel for every transmission.
Unfortunately, the AU915 specifications are a bad copy-paste from the US915 documentation (sometimes even still referring to the US tables), but for US915 this explanation is a bit more extended:
For rapid network acquisition in mixed channel plan environments, it is further recommended that the device follow a channel selection sequence (still random) which efficiently probes the groups of nine (8 + 1) channels which are typically implemented by smaller gateways (channel groups 0-7+64, 8-15+65, etc.).
So yes, joining might take some time, but due to using DR0 (best range) chances are good that when a randomly selected channel is indeed supported by the network, the Join Request will be received.
Next, while 1.0.2 does not support a CFList in the OTAA Join Accept yet, the initial ADR will tell the device which channels to use. (In 1.1 TTN will include the network settings in the Join Accept, like it already does for EU868.)
Good luck trying to find an affordable gateway that can listen to 72 channels simultaneously. There is an “official” subband for AU that is used by TTN, just like the US. Your problem is not the RAK831, it is with your node. There should be a channel mask implemented in its firmware, then it’s a simple matter to make it work. By default,my Rak Wisnode would do the same thing, but setting a channel mask makes it transmit only on the subband my Rak831 is configured to use.
Page 19 of this document clearly explains the subband issue and what to do to set it when you compile the firmware.
Gateways usually support only 8+1 channels and a set of 8+1 channels is called as SUBBAND.
The NA/AU Regional band has 64+8 channels. Therefore there are eight SUBBAND’s in the case of NA/AU region. The application by default is configured to work in SUBBAND 1.
Change the SUBBAND value according to the gateway/NS configuration. If the gateway supports 64+8 channels then the SUBBAND definition must be commented.
1 Like
This two year old post indicates that, like the US, TTN in Australia uses subband 2. If you define (#define SUBBAND 2) this in the config file and compile the firmware, you should be on your way to a working situation.
https://www.thethingsnetwork.org/forum/t/australian-channels-for-ttn-is-there-a-standard/4056/4
Thanks so much for pointing this out to me. I had gone down a rabbit hole by following the guide that is published on TTN, rather than the Microchip doc… It got me mostly working but not entirely working. I’ve modifyed the sub-band, put my gateway back to AU-915, (both changing the global_conf.json and the frequency plan on TTN console ), and now when the device trys to join i see a packet at the gateway and an entry in the traffic page on the ttn console. For some reason TTN is still sending the reply with a EU868 band, even though i’ve set it to use 915.
I tryed deleting the gateway and re-adding it, but it still trys to use 868. there might still be some kind of timeout going on.
EDIT: Yes, it seems if you make a frequency plan change it takes some time for it to update. Was about 10 minutes in my case.
The good news is that now i seem to have a working solution! Thanks so much for your help!
I’m glad you got it working. Your gateway traffic should show that it only takes a couple of mS for a packet to make it from your gateway, through the bridge and then to the LoRa server. If it’s taking tend of mS, then your gateway (rak831) may be pointing to the wrong bridge. (I had this problem).
I’m guessing that the device configuration page is responsible for determining which frequency it replied on. Again, I’m glad it works, but check that your routing is all the way it should be, or it will create unnecessary delays in getting your packets to the ttn application. I’m truly amazed at exactly how fast it all is when it is configured correctly.
The RAK831 seems to be a good piece of hardware, but then the concentrator it’s built from Semtech components. Rak lacks a bit in documentation compared to Microchip, but I suspect they are having some growing pains.
39mS or so. The router is in Australia, so, 39mS is pretty much what i’d expect. If we had somethign more local, we probably would get somethign going faster, most of that time is the latency in the network.
Feb 6 11:31:54 ttn-gateway ttn-gateway[564]: INFO: [up] PUSH_ACK received in 38 ms
Feb 6 11:31:54 ttn-gateway ttn-gateway[564]: INFO: [down] PULL_ACK received in 39 ms
Yes, the frequency plan that you put in on the console is more than just ‘informational’. Its what determines what frequencys things are set up on.
This has been quite educational, but it has shown that ‘LoraWan’ still has some space to go, and provisioning still has its quirks. AU915 is’nt quite a ‘standard’ by itself… its sort of like AU915.2 ( sub-band 2) and that could be quite a challenge for some endusers to understand. Not a problem that makes it impossible but system designers clearly need to put a lot of thought into how end users of devices can use them. Right now its not quite, buy a device at the hardware store and turn it on.
The frequency plan is important, but so is the router setting (directly under the frequency plan setting). What do you have for your router setting and what do you have for your “server” in the json file?
both are set to use
router.au.thethings.network
Also, if you use a PC browser to look at the traffic on your gateway page, when you expand a message, it puts up a cool chart/breakdown/timeline of which bridges and routers handled the packet, like this. My push and pull times are actually larger than yours
Its nice and quick.
I’m jealous now. 
You’ve got a really good SNR too. Mine is usually around 10 or so with that RSSI, but I’ve got a lot of stuff sitting around radiating the room. Are you using the Raspberry Pi’s WiFi, or do you have it disabled?
No. Its disabled.
Hi there, I’m back to CY,
I put my Gemtek mini-hub and RAK831 online.
Recompiled both workshop and vanilla projects.
Both works immediately. Tested with public gateway - also works.
I cannot explain why it had problems in NL. Now ti works with no issues.
Thank you all for input and attention.
I assume that both where using EU868?
Yes, EU868.
A bit odd then, both my RAK831 and the R34 worked fine on 868 without any issue. 915… that was a differnet story.
yes it was weird, and i’ve been able to establish today what was going on with that gateway. It was setup as an EU-868 gateway locally, but TTN thought it was a 915Mhz. After a longer discussion with the owner, it turns out that he had’nt actually connected any 915 devices to it.
good news is that now his gateway is running properly.
I too have had in interesting time getting the SAMR34 to join.
Am in Australia, using a Things Indoor Gateway. As advised in this thread, using AU_BAND and set #define SUBBAND 2, and at each join request nothing seen on the gateway traffic - just could not get it working.
Changed the operation from AU_BAND to NA_BAND, and bingo, join requests seen on the console and are successful (still sub-band 2).
Happy to see it working, but not sure where the problem with AU_BAND operation is, whether a mismatch between the SAMR34 settings and the Gateway settings?