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.
Hi,
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 
Sure. This was just an addition to prevent possible confusion. 
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