The hard RAK831 cafe part 3

A new firmware for #RAK2245 and #RAK831 has been released.
It is based on Raspbian OS and add an operating UI to configure the #LoRa gateway easily.
All of the source code have been updated on #Github.
SX1301 driver lora_gateway v5.0.1 and semtech packet_forwarder v4.0.1

Does this mean you can change frequency bands

It looks like they added something to get the appropriate global.conf.json file copied in during the install. Not sure if they fixed the ublox thing, but it looks like they’re including a new gps.c file. I think I’ll pass for now though. I’m happy with the stability of my gateway as it is.


I am using RAK831, My lora device up. But in the things network map the following information is shown,

Name: unknown
Altitude (m): 100
Placement: unknown
Brand: Raspberry Pi DIY
Model: IMST
Antenna model: unknown

How can I change these parameters.
I am using the following link for making my gateway work.

The UI for configuring the gateway may be new but the used SX1301 driver and packet forwarder are both 2 years old.
(To be exact, this is not firmware but software. Nothing is flashed onto the RAK2243 or RAK831 so this will not update/upgrade the RAK2243 or RAK831 itself.)

don’t shoot the messenger :wink:

Sure. This was just an addition to prevent possible confusion. :slightly_smiling_face:

1 Like

They appear to be replacing a couple of the gateway modules after cloning the git repository. I think I’ll add these to my build after I check to see what they changed.

cp $SCRIPT_DIR/library.cfg ./libloragw/library.cfg

cp $SCRIPT_DIR/loragw_gps.c ./libloragw/src/loragw_gps.c

cp $SCRIPT_DIR/loragw_spi.native.c ./libloragw/src/loragw_spi.native.c

I’m guessing they fixed the ublox message issue. I’m really interested in what they’ve done to the SPI module. I read some posts somewhere that the SPI clock speed was responsible for the gateway failing to start on the first try, leading to the system having to respawn the software a few times.

1 Like

does any one know what the “status” part mean in the header of each of these Lora packets? this is an example of one of the logs Being created from the Util_pkt_Logger program.

"gateway ID","node MAC","UTC timestamp","us count","frequency","RF chain","RX chain","status","size","modulation","bandwidth","datarate","coderate","RSSI","SNR","payload"
"B827EBFFFE11F166","","2019-01-29 23:11:01.855Z", 8888308, 868900000,0, 7,"CRC_BAD", 24,"LORA",125000,"SF7" ,"4/5",-129,-11.5,"DA985AA0-9E2F7B65-557C3962-FA403AF3-4480DFF4-2B46AC7D"
"B827EBFFFE11F166","","2019-01-29 23:11:03.626Z", 10659736, 867300000,1, 8,"CRC_BAD",120,"LORA",250000,"SF7" ,"1/2",-125,-12.0,"66A58D15-F0104693-06E88B3B-319B39C5-3FB44D8A-D9F4B1C9-103225E8-390F6328-DB8FB32C-831149AE-01176877-E2D111A8-7545C81A-EC695651-16A2F1E2-A5F3A9DE-7F2B8074-C55AAB1D-933034D2-9E9D8A76-73D8BAF0-8B32766D-38408F8F-C487C50D-74BD88DE-FF8D0560-4A938826-74DE58EB-9E008B0B-DE280142"

Looking at the content of that field I would think that would be obvious… Each uplink LoRa packet has a CRC that is validated on reception. The packets shown fail the check.

since you are obviously more experienced with LoRa what would you think would be causing the CRC check to be bad? Does that point to an issue with the node that’s transmitting the packet or the gateway that is receiving the packet? Or could it be both and its just a matter of tracking down which device would be causing that?


actually a better question would be: what repository do you suggest using with the RAK831_915 gateway? I am reading through your “Build your own RAK831 based gateway” tutorial on the things network. You are using The “ttn-resin-gateway-rpi”. I have been working with the RAK831-LoRaGateway-RPi repository. Would you recommend a switch to the ttn-resin-gateway-rpi? I would appreciate your opinion on the matter. I am struggling to get passed the CRC check error which I would attribute to my incorrect configuration changes with the RAK831-LoraGateway software I currently am using.

How far from the gateway to the node? Your rssi and SNR values are indicating a very weak signal being received.

Why do you think the gateway is not working? As you’re showing logs that are a few days old, and in another topic you were using software for peer-to-peer LoRa on the device, not a LoRaWAN library, that log could very well be not related to your node’s transmissions at all, but just show some other unrelated radio. (If that peer-to-peer software used the same “(inverted) I/Q” as the gateway, then the gateway would not even hear it. Indeed, earlier I thought the gateway might be the culprit, thinking you had LoRaWAN nodes transmitting. But later on we determined that your nodes are simply not LoRaWAN nodes?)

Are those two lines all you’ve received so far? You might want to post some recent logs in that other topic.

I would rather say that it is not working correctly and I am wondering if we are using the correct program (util_pkt_logger vs. poly_pkt_fwd) in order to get our logs posted to our TTN console. We currently are running the util_pkt_logger which appears to collect the payload from our Node, as well as the meta data, and saves that into a designated log file. Should we be running the poly_pkt_fwd program in addition to the util_pkt_logger in order to get our logs fully pushed through to our TTN console? Our main thought as to why we assume the Gateway is not working is because our traffic section on our console remains blank. On our ‘Overview’ tab, we do see that our ‘Received Messages’ section keeps increasing. However, this ‘Received Messages’ section does not correctly display the same number of payloads that our Node has been sending.

You do not push logs to TTN, you push the data. And for that you need a packet forwarder, not the utilities. Once you run the packet forwarder and run registered nodes with a lorawan stack you will be able to get the unencrypted data from TTN.


you were spot on. we got our nodes registered with the TTN and their status was updated to ‘seen’ . Using the packet forwarder we got join accepted responses from the ttn. How do you see the unencrypted payload though? I cant seem to find it in the TTN console.

You should be able to see the decrypted payload in the application section of the console.

I am setting up the “beacon_pkt_fwd” on the RAK831_915 gateway. The code below is the first portion of my global_conf.JSON saved in the beacon_pkt_fwd directory.

My first question is about the “freq”: value in both the radio_1, and radio_0 section.
I am in the US, so I will need to use the 915 frequency band. Should I set both the radio_0, and the radio_1 section to 915?

My second question is about the “rssi_offset”: value. What does this number do? Is this a value that I should change in order to troubleshoot the rssi I am getting on each transmission? Or is this a standard value that I should just leave alone?

Lastly, should I adjust any the “chan_multiSF_” ?

I am a bit uncertain about all the information in the global_conf.JSON, any help would be appreciated.

    "SX1301_conf": {
        "lorawan_public": true,
        "clksrc": 1, /* radio_1 provides clock to concentrator */
        "radio_0": {
            "enable": true,
            "type": "SX1257",
            "freq": 867500000,
            "rssi_offset": -166.0,
            "tx_enable": true
        "radio_1": {
            "enable": true,
            "type": "SX1257",
            "freq": 868500000,
            "rssi_offset": -166.0,
            "tx_enable": false
        "chan_multiSF_0": {
            /* Lora MAC channel, 125kHz, all SF, 868.1 MHz */
            "enable": true,
            "radio": 1,
            "if": -400000
        "chan_multiSF_1": {
            /* Lora MAC channel, 125kHz, all SF, 868.3 MHz */
            "enable": true,
            "radio": 1,
            "if": -200000
        "chan_multiSF_2": {
            /* Lora MAC channel, 125kHz, all SF, 868.5 MHz */
            "enable": true,
            "radio": 1,
            "if": 0
        "chan_multiSF_3": {
            /* Lora MAC channel, 125kHz, all SF, 867.1 MHz */
            "enable": true,
            "radio": 0,
            "if": -400000

Get the US global config from the TTN github repository, no need to create your own.

1 Like