Are you changing the region on the node when you also change the global_conf.json file? If not, then that explains a lot about why the gateway doesn’t respond when configured for the AU region. It’s only going to listen to the frequencies specified in the json file. In EU, it’s my understanding that the gateway responds on the same frequency that it received, in other words EU frequencies are bi-directional. In AU and US, there are uplink only frequencies and downlink only frequencies, 8 of each per subband. It sounds like your node may be configured for the EU region, assuming that you aren’t changing it when you switch your json files on the gateway. In US and AU there are also 8 subbands, unlike EU. You have to ensure that your gateway and your node are using the same subband. This is often done by setting a channel mask in the node to stop it from trying to use frequencies that the gateway isn’t listening on. I don’t know anything about your node, does it use AT commands for configuration, or are you compiling and uploading firmware to it?
Edit, I just saw your log messages. Your gateway is transmitting on 9xxMHz because the ttn network told it to. You can’t change that, it’s based on your gateway registration in ttn. You are only going to get this to work by using the correct json file for your region. Your node is apparently configured for EU region, and that is most definitely your problem. ABP would let you get packets to your application, but you will never be able to get confirmation or downlink messages, which is absolutely required to accomplish your OTAA.
Yes, of course. I was carefully matching the Device and the gateway. Thanks for the hint about it being TTN sending the instruction on which frequency to transmit on. I reconfigured everythign to be EU-868 ( including the gateway ) and it joined and i was able to send data. Of course i shoud’tn really be using EU-868 here, but for a few minutes its not goign to be a big problem. ( i’m out in the sticks with a very low gain antenna
It would seem, that there is a problem somewhere with how the SAMR34 is setup with its AU915, or perhaps the RAK831 is not a good choice for AU915 either.
It would appear that when the node is configured for your region, it isn’t setting something correctly. Are there any firmware updates available for it? I think it’s a pretty safe bet that the rak831 is working as it should.
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.
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.
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.
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?
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
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?
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.
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?
