If you use my fork of the library that has been ‘fixed’ (== reinstated)
1 Like
Okay, thanks for that information. I hadn’t discovered that you had a fork of the code until after I had picked one and set about fixing it up to work for me. It’s my understanding that yours has some advanced features, in terms of how the traffic is handled on the internet. When I have some more time, I’ll probably switch to your fork. In the mean time, I have a practical use for my gateway and I need to concentrate on getting end node devices figured out. I’m searching for the perfect dev board that can be powered by batteries as my plans include fixed position sensors to monitor water levels in the local drainage system to supplement the sparse county sensor system.
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.