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.
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?
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?
