Anyone has experience with needing to reset the RAK831 board or the concentrator will not start?
I have to run below code everytime I restart my RAK831 or the gateway will not work with this error as shown in /var/log/syslog
There should be a start script at /opt/ttn-gateway/bin/start.sh
At the beginning of this script you will find some lines to generate a reset on pin 25. Change the pin number from “25” to “17”.
More info on RAK831 installation and configuration here.
Works well thanks. But I wonder why one will have to change the reset pin? Is it because the or original software is based on ic800a which has a different pin mapping?
It’s just a matter of the wiring between the RAK831 and the Raspberry/Orange Pi that is used to control the RAK. The reset pin on the RAK is 19, which can be wired to any output pin of the Pi. The standard Pi pin for this is 25, but it looks like you are using pin 17. In my set-up I’m using pin 10 of the Pi because the Orange Pi does not have pin 25.
For info
Just got the RAK831 running with a R.Pi 3 B+ using these instructions https://www.thethingsnetwork.org/labs/story/rak831-lora-gateway-from-package-to-online
All was OK, but because I’m using the RAK831 adapter board (it has a GPS), I had to change the “start.sh” script.
I changed this line (near the beginning)
from
SX1301_RESET_BCM_PIN = 25
to
SX1301_RESET_BCM_PIN = 17
This was done using the R.Pi command
sudo nano /opt/ttn-gateway/bin/start.sh
Once you’ve made the change, press “Cntrl and O” to write out the file change and exit using “Cntrl and X” (need to reboot of course)
I’ve got a few of Charles’ boards to try - so I hope to try that soon.
Reason for the post was to record more specific help e.g. how to edit the file and what board was being used at the time.
Thanks for the link - I can see that it is more geared to a R.Pi Zero using the board from Charles (I’ll try to use it next with the board from Charles) - but why is it better for a R,Pi 3B?
Lora Gateway base setup for SX1301 based concentrators
This setup is used for some LoraWAN concentrators based on small computers such as Raspberry PI or others. For example it works fine with the RAK831 PI Zero shield
.
Because it provides a better and more secure implementation of the gateway software: @kersing’s Multi Protocol (MP) Packet Forwarder.
mp-pkt-fwd uses the new protocolbuffers-over-mqtt-over-tcp protocol for gateways, as defined by TTN and used by the TTN kickstarter gateway. Using this protcol the gateway is authenticated, which means it is registered under a specific user and can thus be trusted. Because it uses TCP, the chance of packet loss is much lower than with the previous protocol that used UDP. Protocolbuffers packs the data in a compact binary mode into packets, using much less space than the plaintext json that was previously used. It should therefore consume less bandwidth.
Questions will be asked during setup (but this may not become directly clear from reading readme.md).
For your RAK831 Raspberry adapter board just skip the LED, (switch) monitoring and OLED display stuff when asked during setup.
@Charles added extra features to the setup procedure since I used it. Like questions to skip certain parts of the installation (relevant for specific boards/options only) so the setup can be used for more adapter boards. And there is now support for an OLED display.
(FYI @kersing’s MP Packet Forwarder repository contains the gateway software but not an installer.)
@bluejedi, you read my mind, it’s done now, I test it since yesterday, setup if done by 2 scripts (1 to preconfigure PI and reboot, the other for the setup) asking what board you use and what features you want to install check if RPI 3 or RPI Zero to install correct nodeJS version.
Check out new on the repo the new readme.md
All should go straightforward, let me know in case of bug or if it need some improvement
It is certainly less work to use method 1 , but with this method 2, I can certainly see the value of using Resin.io to remotely manage multiple TTN gateways (based on RAK831).
As I now have 2 memory cards - I can choose which software to use for the time being.
Its great to be able to use Resin for something and see the results (not used it before).
Will try version 3 soon (Charles version) - but I’m thinking of doing that another day now.
One thing though, Method 1 needs “legacy packet Forwader” ticked, but Method 2 (Kersing) does not i.e. Method 2 uses the more “accepted” TTN version (for want of the proper term).
For Method 3 (Charles version), it seems that “legacy packet forwarder” should be ticked - is this correct?
Yes, these differences and inconsistencies are very confusing (I also ran into this issue previously).
Here GW_RESET_PIN actually refers to the PIN number (just like te name indicates, which is correct) and not the GPIO number.
New setup use new kersing MP packet forwarder, but I had issues with some devices what were unable to join with the mp packet forwarder. When I reverted to old packet forwarder issues were gone, this is strange because it’s not the 1st time I see this issue. May be due to device without GPS and time sync drift.
Anyway if you want to switch from mp to legacy forwarder (my version with extended log), just run the script from my repo
./build_legacy.sh
The Reset Pin is asked by the main setup script and it’s the BCM format (GPIO Name)