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)
Hi Charles,
I’m will soon be trying your software with a R.Pi3 (B+) and RAK831 board - which option would this be? (or have you done this already )
Thanks for doing this BTW
There have been issues a number of times with delays in the packet processing for the TTN protocol in the back-end. I’ve seen delays of several minutes, at those times any response (OTAA and downlink) will be useless as the node will not be listening…
