RAK831 config issue?

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

ERROR: [main] failed to start the concentrator

#!/bin/bash 
    echo "17" > /sys/class/gpio/export 
    echo "out" > /sys/class/gpio/gpio17/direction 
    echo "1" > /sys/class/gpio/gpio17/value 
    sleep 5 
    echo "0" > /sys/class/gpio/gpio17/value 
    sleep 1 
    echo "0" > /sys/class/gpio/gpio17/value

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.

3 Likes

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.

1 Like

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. :slight_smile:

Yes, this was already mentioned in some places on the forum, e.g. https://www.thethingsnetwork.org/forum/t/cannot-connect-to-rak831-australia-915-using-ttn-zurich-git/11433/6
Note that it is actually not the pin number but the GPIO port number (the name SX1301_RESET_BCM_PIN is misleading here).
.

For a better Gateway software implementation (than ttn-zh/ic880a-gateway) check the following post:

1 Like

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?

Not exactly:

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.

[off-topic]

FYI: Long ago, when I went to primary school, in the Netherlands Curly Wurly was named Three Musketeers. :slightly_smiling_face:

Ah right!
So far, I’ve tried to set up using this (which has the config “issue” - where you need to change from 25 to 17)
https://www.thethingsnetwork.org/labs/story/rak831-lora-gateway-from-package-to-online

I guess I should try this next (time to get another memory card!)
https://www.thethingsnetwork.org/docs/gateways/rak831/
The github ref is as follows

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.

Why is that? (Unless you plan to manage your gateway with resin.io).

To keep things simple: https://github.com/ch2i/LoraGW-Setup
(The link from my previously mentioned post.)

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.)

See Cannot connect to RAK831 (Australia 915, using TTN Zurich Git)

@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

1 Like

OK - just to say I now have the gateway running using a R.Pi with Rak831 and the Rak831 board using
https://www.thethingsnetwork.org/docs/gateways/rak831/

One difference is that I used 11 for GW_RESET_PIN

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.

https://www.thethingsnetwork.org/forum/t/cannot-connect-to-rak831-australia-915-using-ttn-zurich-git/11433/7

1 Like

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)

2 Likes

To prevent (more) possible confusion:
Which is the GPIO number, not the GPIO name (because that would be something like “GPIO17”). :wink:

For

  • CH2i RAK831 reset pin is GPIO25 (Pin 22) enter in setup script 25
  • CH2i iC880a reset pin is GPIO17 (Pin 11) enter in setup script 17

image

but if you chose the correct board, setup does this for you

image

  • RAK Raspberry Pi Adapter board for RAK831 uses GPIO17 (physical pin 11): GPIO number: 17

What does selecting?:

  1. All other models

Added :wink:

1 Like