Is this LoRaServer compatible with RAK831

Gateways
1

Will this Server setup work on the RAK831 hardware ?

3

Yes,
One way to confirm this. If you look on the RAK site you will see the RAK2245 can be run in three different configurations. One is with LoraServer.io running on the Raspberry Pi.

4

And see also this overview: https://www.loraserver.io/lora-gateway-os/overview/ :slight_smile:

5

I had some troubles with getting LoRaServer-OS from Brocaar operating on a RAK-831 pilot gateway.
This gateway has an adapter board with GPS on it between the RPi and RAK831 board.

I installed LoraServer-OS on two of these devices and it mostly appears to function except that the sensor nodes did not hear or receive the joinAccept from the gateway.

It was the typical joinRequest joinAccept loop many have had troubles with.

I was pulling my hair out thinking it was the library used on the Feather M0 board, from mcci-catena. I tried alternative libraries and the problem persisted.

So, I ended up installing Debian Stretch headless and then from RAK Wireless GitHub, their implementation of LoRaGateway for RAK831/RAK2245, which installs LoRaServer.

This then worked first go and the thing I like about it is it is standard Debian and I can update using standard methods.

One thing, the gateway-config from Brocaar is slightly better thought out than from RAKWireless.

I don’t know why the LoRaServer-OS had troubles, but suspect it might come down to a GPIO pin assignment for reset or something similar. Something for me to re-look into at some point as I just need the the packet forwarder and gateway bridge to integrate into a larger LoRaWAN network.

2 Likes
6

Thank you, been trying to set up a RAK831 Pilot Gateway for a while now. After many undocumented modifications, 2 different hardware nodes worked for it intermittently. But, I’m going to give your method a shot.

7

Thanks for this idea. I’m also having the same issues with the gateway-os on an rpi3b+ with ral831.
Will try the debian + rakwireless implementation.

Any further thoughts on why we experienced the join request loops?
@brocaar?

8

I am having the same trouble. I thought it was the endpoint code but I’m using a raspberry pi and RAK831. I can receive packets fine and loraserver says it is transmitting but the RAK831 module never transmits at all.

https://forum.loraserver.io/t/loraserver-with-murata-abz-module/5428

9

This would only explain intermittent complete failures. It would not explain a case where join requests were being received, but join accepts were not.

Gross timing errors caused by severe scheduler lag might in theory explain it, but the receive window for a join accept is so much later than ordinary that this would have to be a really absurd amount of delay.

Your actual issue is most likely not correlated with the change to the gateway at all, but rather purely coincidental.

Further, with an LMiC-based node where you can readily add debug output, there’s really no justification for blindly blaming things; don’t guess when you can debug.

10

I don’t think this can be debugged on the end point side. Logs show downlink on correct channels and timing. I measured the output of the rak831 and see nothing at all. The lack of TX led blinking on the module confirms this even though loraserver says it is transmitting. Since it can receive packets I assume spi comms are good. Anyone know where to look to start debugging this?

11

Which logs? What do the packet forwarder’s logs say? They should tell you exactly what is going on. Not sure with this distro but in mine they end up in /var/log/syslog.

There’s no GPIO that is used for transmit but not receive, so again the theory that this is a GPIO problem is basically invalid. Even if the reset gpio were floating it’s not like it would fail everytime the gateway transmits but then magically start working again in time to receive, and if it did, you’d see that the hardware timestamp kept resetting instead of incrementing until it rolls over in a bit more than an hour. In reality, the exact same SPI communication that accomplishes receive, is what is used to accomplish transmit. Even if you had a power problem leading to brownouts (which is unlikely to be transmit unique as all the digital processing in receive consumes a ton of current), you wouldn’t expect it to be instantly back up and receiving again afterwards, and even if it were the reset timestamp would indict the problem.

12

@cstratton This would only explain intermittent complete failures. It would not explain a case where join requests were being received, but join accepts were not.

Yes, now that I understand a little more now than I did back then on the inner workings of LoRaWAN, I can only agree with you. Maybe I could have written that in a better, more clearer way than I did. I ‘guess’, like so many others, there is a time when we go through much learning and often little problems present as insurmountable obstacles, that later on we look back on and think ‘how naive was I’. In my field of industrial control systems engineering, I can’t afford to make guesses or assumptions and often say to others similar to what you mentioned, and appreciate the reminder to all, not to make wild guesses.

For my project, I tracked down a stumbling block in the LMIC library I was using for the sensor nodes, based on the library from MCCI, as I pointed to in my post. The problem appears that the library has difficulty with the AU915 (Australian Band) when using a sub band as used here, sub band 3. I nutted this out using good old diagnostic methods developed over many years of work in the broad electronics field and worked out a temporary work-around to still use AU915 sub band 3 for this project.

In the next few weeks as time permits, I will re-configure the RAK831 Pilot gateway to again use the LoRaServer-OS from Brocaar as a test to see if the problem is resolved. If the problem still persists, then I would be in a better position to diagnose the situation as I have hopefully learnt a few things since my first post some months ago now.

Paul Alting van Geusau

13

If you figure out what is going on there it would be good to file an issue on the github repo for that library.

14

I ran the lora-packet-forwarder and tried an OTAA join. Getting an error on the join accept message that the TX power is unsupported. The RAK831 is capable of 23dBm so not sure why this is causing this error. Where is the TX power setting for the gateway configured?

INFO: Received pkt from mote: 00000000 (fcnt=0)

JSON up: {“rxpk”:[{“tmst”:1970992684,“chan”:7,“rfch”:1,“freq”:905.300000,“stat”:1,“modu”:“LORA”,“datr”:“SF10BW125”,“codr”:“4/5”,“lsnr”:-12.2,“rssi”:-117,“size”:23,“data”:“AAAAAAAAAAAAaW1ksGEyalBjURDrVdc=”}]}
INFO: [up] PUSH_ACK received in 1 ms
INFO: [down] PULL_RESP received - token[162:143] :slight_smile:

JSON down: {“txpk”:{“imme”:false,“tmst”:1975992684,“freq”:927.5,“rfch”:0,“powe”:20,“modu”:“LORA”,“datr”:“SF10BW500”,“codr”:“4/5”,“ipol”:true,“size”:33,“data”:“IETnjmm4W/32D1LGxKFpZE/Nd3/7g8JTdDyedKrATkoa”,“brd”:0,“ant”:0}}
ERROR: Packet REJECTED, unsupported RF power for TX - 20
INFO: [down] PULL_RESP received - token[162:143] :slight_smile:

JSON down: {“txpk”:{“imme”:false,“tmst”:1976992684,“freq”:923.3,“rfch”:0,“powe”:20,“modu”:“LORA”,“datr”:“SF12BW500”,“codr”:“4/5”,“ipol”:true,“size”:33,“data”:“IETnjmm4W/32D1LGxKFpZE/Nd3/7g8JTdDyedKrATkoa”,“brd”:0,“ant”:0}}
ERROR: Packet REJECTED, unsupported RF power for TX - 20
lgw_receive:1155: FIFO content: 1 ef 1 5 15
lgw_receive:1174: [4 17]
Note: LoRa packet

15

Presumably you want the look up table which is typically in global_conf.json in whatever directory the gateway runs from

eg something with an entry like

“tx_lut_11”: {
“desc”: “TX gain table, index 11”,
“pa_gain”: 3,
“mix_gain”: 9,
“rf_power”: 20,
“dig_gain”: 0
},

16

Well, yes, naturally: LMIC MCCI issue with AU915 sub band

17

Sounds like you’ve got a sub-band selection conflict between LoRaServer and the code, such that your join accept is moving the node away from the channel your gateway is configured to support.

Note that in LMiC the LMIC_selectSubBand() counts from 0.

18

Finally got RAK831 with raspberry pi and lora-gateway-os working.Not sure why but the global_conf.json was missing all these entries. Put them in /etc/lora-packet-forwarder/global_conf.json OTAA and confirmed packets now work. I took these from the EU config I’m not sure NA would have the same tx power limitations.

    "tx_lut_0": {
      /* TX gain table, index 0 */
       "pa_gain": 0,
      "mix_gain": 8,
     "rf_power": -6,
    "dig_gain": 3

},
“tx_lut_1”: {
/* TX gain table, index 1 /
“pa_gain”: 0,
“mix_gain”: 10,
“rf_power”: -3,
“dig_gain”: 3
},
“tx_lut_2”: {
/ TX gain table, index 2 /
“pa_gain”: 0,
“mix_gain”: 10,
“rf_power”: 0,
“dig_gain”: 1
},
“tx_lut_3”: {
/ TX gain table, index 3 /
“pa_gain”: 0,
“mix_gain”: 14,
“rf_power”: 3,
“dig_gain”: 2
},
“tx_lut_4”: {
/ TX gain table, index 4 /
“pa_gain”: 1,
“mix_gain”: 10,
“rf_power”: 6,
“dig_gain”: 3
},
“tx_lut_5”: {
/ TX gain table, index 5 /
“pa_gain”: 1,
“mix_gain”: 12,
“rf_power”: 10,
“dig_gain”: 2
},
“tx_lut_6”: {
/ TX gain table, index 6 /
“pa_gain”: 1,
“mix_gain”: 12,
“rf_power”: 11,
“dig_gain”: 1
},
“tx_lut_7”: {
/ TX gain table, index 7 /
“pa_gain”: 1,
“mix_gain”: 12,
“rf_power”: 12,
“dig_gain”: 0
},
“tx_lut_8”: {
/ TX gain table, index 8 /
“pa_gain”: 1,
“mix_gain”: 14,
“rf_power”: 13,
“dig_gain”: 2
},
“tx_lut_9”: {
/ TX gain table, index 9 /
“pa_gain”: 1,
“mix_gain”: 13,
“rf_power”: 14,
“dig_gain”: 0
},
“tx_lut_10”: {
/ TX gain table, index 10 /
“pa_gain”: 2,
“mix_gain”: 9,
“rf_power”: 16,
“dig_gain”: 2
},
“tx_lut_11”: {
/ TX gain table, index 11 /
“pa_gain”: 2,
“mix_gain”: 11,
“rf_power”: 20,
“dig_gain”: 1
},
“tx_lut_12”: {
/ TX gain table, index 12 /
“pa_gain”: 2,
“mix_gain”: 13,
“rf_power”: 23,
“dig_gain”: 1
},
“tx_lut_13”: {
/ TX gain table, index 13 /
“pa_gain”: 2,
“mix_gain”: 15,
“rf_power”: 25,
“dig_gain”: 2
},
“tx_lut_14”: {
/ TX gain table, index 14 /
“pa_gain”: 3,
“mix_gain”: 10,
“rf_power”: 26,
“dig_gain”: 2
},
“tx_lut_15”: {
/ TX gain table, index 15 */
“pa_gain”: 3,
“mix_gain”: 10,
“rf_power”: 27,
“dig_gain”: 1
}

19

Yes LoRaServer is compatible with RAK831 this is a RF front end of a LoRa™ gateway. It is able to receive on different frequency channels at the same time and is able to demodulate the LoRa™ signal without knowledge of the used spreading factor of the sending node.

1 Like
20

I would actually recommend the RAK7243 Pilot Pro :wink: t’s a bit more expensive, but you get the hat integrated with the rPi and very nice case. And it’s been running uninterrupted for several weeks now without issues.

I got mine setup in matter of minutes and configure with TTN first. Switching the configuration to Loraserver took a couple of trials but it was due to errors on my part. The configuration menu and documentation are pretty good as well.
I haven’t tried the Loraserver.io OS image yet ad I am not sure it has been well tested on that specific device. And I don’t mind doing manual upgrades using the apt repos for now.

1 Like