The hard RAK831 cafe part 3

Gateways RAK Gateways
36

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"
37

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.

38

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?

39

@kersing

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.

40

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

41

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.

42

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.

43

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.

44

@kersing

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.

45

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

46

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
        },
47

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

1 Like
48

Hello .
Some one can suggest me a tutorial about how can use ( rak831 + FT2232HL in ubuntu ) ?
thanks in advance

49

You may do better looking for info on the RAK833, which is basically the same LoRa concentrator as the RAK831, but has an optional FT2232H on-board. Then make sure you wire yours so that the SPI signals (and if you can, reset) are mapped to the FT2232H in the same way as the RAK831 does.

But it would really be better to use SPI if possible. Most embedded platforms should support that, the exception would be if you’re trying to use a PC.

50

Also have a look at the new RAK2245 its the same chips but in a different package and with an improved receiver.

51

That’s potentially very interesting for the next round of gateway builds given the improved heatsink situation.

However, I was recommending that @momo look at the setup documentation for using the RAK833 version with the build in FT2232H via USB in order to achieve their goal of using their existing RAK831 with an FT2232H. I wasn’t recommending that they go purchase a different concentrator than the one they already have - if they wire their RAK831 and FT2232H up like the internals of the RAK833, then they should be able to use the RAK833 USB instructions.

But if that was pre-purchase research then yes, avoiding USB would be best and the RAK2245 looks potentially better than the RAK831

1 Like
52

cslorabox, TonySmith thanks for your reaction !!
yes i have alredy rak831
i will try your proposition and keep you informeds.

53

I have multiple RAK831+rpi 3 868mhz gateways (complète product with enclosure from AliExpress, no hardware mods) where I have seen a problem with the util_pkt_logger. Every time I remove and put back the SMA antenna it stops receiving any messages. Even a slight touch/vibration on the antenna could cause this problem.

I have also seen other people in the forum getting this issue. But I don’t know if it is caused by the same thing.

A quick fix is to just reset the GPIO pin 17. But that’s not reliable.

Anyone having the same problem and or a fix? I am using this software: https://github.com/Lora-net/lora_gateway

54

Note: this should not be done with the device powered as if there is a Tx from the card during the time without ant/load there is a high chance of the Rf self destructing! :scream: or at least overload and later self annealing, leading to poor future performance/latent failure.

If doing this with device powered down and then restarting results in the unit appearing to be deaf then likely that is the system not effectively asserting reset on the Concentrator and/or an SPI speed issue. the causes and solutions for these are well documented on the forum (search) - GIFY.

This suggests either 1) antenna is not secured/screwed on correctly or 2) Ant defective or SMA pad is poorly constructed/part open circuit - check ant by substitution, open unit and inspect SMA landing pad for crack/bad solder joint - may be device has suffered impact damage or lateral stress! (Also check pin structure of SMA and Ant - too often I have seen female SMA Ant added to female SMA socket (i.e. neither side having a centre pin!) causing either no connect or at best capacitive coupling (poor) or very bad mechanical connection resulting in slight touch/movement loosing signal)…this is all basic trouble shooting… :slight_smile:

There is no connection with the packet forward used in this case as this is software only and it only act after any LoRa signal received and demodulated - the packet forwarder just sends the received decoded (if not decrypted!) packets on to the back end. Poor RF behaviour may result in increased CRC errors that result in dropped packets and no data being provided to the packet forwarder to send on…

55

@momo

You mean this? : http://docs.rakwireless.com/en/LoRa/RAK831-LoRa-Gateway/Software-Development/RAK831-FT2232HL-Quick-Start-Guide-V1.2.pdf.pdf