Unstable 831 Gateway in AU_915, bad radio module?
It looks like I have a problem with my 831 Gateway on the radio receiver side in the AU_915 frequency. This is my first setup of the RAK 831 and I'm not familiar with the device. The setup was straight forward however I noticed a great deal of inconsistency when I started using it. I first tested with the WisNode Lora/LoRaWAN Module and got very poor RRSI results for the distance about 4m, further many of the packets would not arrive at all. Then I tested with the 811 tracker board and the same problem manifested . With only 4m between my end node and the gateway loose most of the packets. I than decided to move the end node directly next to the gateway and for the first time I saw packets arriving SF 8 and it became somewhat better, randomly it would drop back to SF 12. It looks to me that either the firmware is not working correctly which is less likely or do I have a bad radio module?
Is there a way to monitor the incoming packets to the gateway? so I can investigate if my radio module is faulty?
Dose anyone has a stable gateway in the AU_915 band?
Here is a screen shot, all the packets are sent at 4 meter distance, about 50% don't register at all. It is random. Here is a screen shot of some of the received packets.
Have a look at the receiving RSSI -120 and I'm 4 meter of the Gateway!
First, try to see if there are any problems with other frequency bands.
Hi, did you make any progress with this i also have a new RAK831 AU_915 and having exactly the same issue: I have noticed that sometimes a reboot of the pi will improve the reception obtaining a RSSI of -70 (still to low for just a few metres) but this decays back to -119
It's not solved, however I made a lot of progress. The first good news is that at least in my case it is not the gateway and rather the end node causing the problem. Lora has 64 channels and your gateway most likely has only eight. This means you have to restrict your end node to these channels. If you use the AT command set on your end note you can do this with
The problem is that this not for some reason stop OTAA to use any other channel and that is a bug. Peter from TTN has send me a new firmware to which he received from RAK to restrict the OTAA also to the channels you have set in the mask.
I have not installed the new firmware but if I apply the channel mask and with luck and trying achieve authentication via OTAA I can force the packets via at+dr= 0 to 5 e.g at+dr=5 I will receive every packet at SF7 nearly 100% of the time.
You can read this
This will give some more inside.
I have tried with a non RAK end-node and the gateway works perfect. Let me know is you need more info.
PS in this thread above the custom code in included in one of Peters mail.
@xc.c We have now established that the problem is two fold
- The end node needs a channel mask
- The OTAA process even after setting the channel mask is still trying to access channel outside of the mask!
- After you get an OTAA and packets are forced via at+dr e.g. at+dr=5 all works fine! all SF 7-12 work!
This is clearly a BUG, can you please provide and updated firmware which will work, thank you.
Hi, Firstly thanks 88bit, I have this weekend had the chance to do some further investigations and i think i have a different issue although with the same result. Everything seems now in may case to point to the gateway or gateway code. I have ensured that the sensors are broadcasting in the restricted same 8 channels as the global_conf.json. Even purchased and used the RAK fiberglass antenna to rule out a faulty antenna. In my case the RAK starts receiving after a boot with nearby sensors at rssi -40 rssi then abruptly after about 10 minutes drops back to -119. if i restart the sensors it makes no difference still -119 but if i resrart the rak831 then it goes back to rssi -40 for about another 10 of so minutes then drops back to -119. The RAK is not dead it just seems to report attinuated RSSI after a time of being on as (a) it cotinues to receive packets and (b) if i move the sensor away rssi drops to -121 but once its drops to -119 it never again records receiving higher signal strength unless the gateway it is rebooted. All traces from the local syslog and ttn received packet data look similar with same channels uses in both -119 and -14 cases, same spreading factor etc other than the attinuation in rssi.
RAK could you advise how to further investigate this this im am starting to think i have a faulty board.
It turns out that this is an issue operating in the AU_915 band related to end nodes rather than the gateway. Lora offers 64 channel however your gateway most likely only dose 8. In Australia in the TTN the second set of eight is used.
- You will need to assign a channel mask to your end node.
- After applying the channel mask the end node will still try to send the OTTA request on on of the 64 channels, with some luck and random trying you will get your end device eventually registered. Than you can set the data rate via
at+dr=0 to 6 and force the packets to be send with high data rates.
There is new firmware for the 811 Tracker board and the LoraWis node which I have attached which will also force the OTTA packet onto the correct 8 channels.
RAK811_GPS_DemoKit_V20233_AU915.bin (is for the Tracker board)
If you upload this firmware you can use the AT commands from the console via USB cable. 0_1522554247890_New Rack Firmware.zip
RAK811_V20225_DEBUG_AU915.bin ( for the LoraWis board)
I hope this will help some of you.
With this new firmware the boards and the gateway are stable and operate very nicely indeed.
Thanks 88bit, Loaded up the au modified firmware for the tracker board you have provided but I can't seem to send the AT commands, using both UARTTerminal and RealTerm connected over usb com uart with same result. Firmware produces a continuous debug output trace in the terminal showing temperature, power, movement, gps location but if i send a AT command eg at+version <cr><lf> it is not acknowledged. If you have any tips i would be grateful.
@iotnexus I have a config file for Tera Term (ini file). Will send this to you later today. I had some trouble in the beginning , too.
Thanks guys for the discussion. I've recently picked up the 831 and some 811 modules for a proof of concept project, and was striking exactly the same issues. I did manage to flash the most recent AU firmware onto the 811 as it was loaded with US firmware originally, and I did work out the channel mask requirements. But as you have all found it's still mighty unstable.
Very promising to hear that your later firmware is more robust @88bit! I'm about to try flashing that on to our modules to see if we have any luck. I'll let you know. Thanks so much for sharing!
Hey again, so we've done a fair bit of testing with this new firmware and for the most part are really happy with it. It certainly resolves a lot of the issues we were having, and we have successfully tested out to 2.25km range with the glass antenna on the gateway. So thanks very much again for sharing.
One new issue though, is that the at+join=otaa command seems to take a really long time to connect - on the order of several minutes. Previously, this was much faster (when it worked). The bulk of the time there seems to be very little happening, but it will send an initial packet, wait around for ages, send another, and then finally connect.
Is anyone else experiencing this, and have any insight/tips? We want to keep this down to a minimum as we are looking to sleep the entire platform as much as possible.
@bradr hey gradr, can you share your mask and global_conf.json for au915? im getting problems on the OTAA for AU915 , thanks
Hi @audorva, sorry for the delayed response.
Here is my ch_mask: 0,ff00;1,0000;2,0000;3,0000;4,0000
This corresponds to a ch_list of: 0,off;1,off;2,off;3,off;4,off;5,off;6,off;7,off;8,on,916800000,0,5;9,on,917000000,0,5;10,on,917200000,0,5;11,on,917400000,0,5;12,on,917600000,0,5;13,on,917800000,0,5;14,on,918000000,0,5;15,on,918200000,0,5;16,off;17,off;18,off;19,off;20,off;21,off;22,off;23,off;24,off;25,off;26,off;27,off;28,off;29,off;30,off;31,off;32,off;33,off;34,off;35,off;36,off;37,off;38,off;39,off;40,off;41,off;42,off;43,off;44,off;45,off;46,off;47,off;48,off;49,off;50,off;51,off;52,off;53,off;54,off;55,off;56,off;57,off;58,off;59,off;60,off;61,off;62,off;63,off;64,off;65,off;66,off;67,off;68,off;69,off;70,off;71,off
I'm just using the stock AU TTN gateway config.
Still having the issue with the delayed join time - hopefully this can be resolved at some point? Thanks!
Hmm so we've just loaded up some additional modules and have found the join time is fine; I'm now wondering if our dev unit has picked up some unusual config during our testing. This is quite encouraging though, as it appears the issue was simply with that one module (and it's config). Cheers!