RAK831 - RPi3 - failed to start concentrator

VinceC · July 24, 2018, 8:40pm

Hi,

I have the RAK831 + RAK converter board running on a RPi3. I followed the instructions from the 2018 conference “build your own RAK831 gateway”
https://www.thethingsnetwork.org/docs/gateways/rak831/

However, from the Resin IO log window I get a “failed to start concentrator” I

Any help would be appreciated.

Here is the complete log file:
24.07.18 16:38:28 (-0400) main [TTN Gateway]: Resetting concentrator on pin 11
24.07.18 16:38:29 (-0400) main 20:38:29 *** Multi Protocol Packet Forwarder for Lora Gateway ***
24.07.18 16:38:29 (-0400) main Version: 3.0.20
24.07.18 16:38:29 (-0400) main 20:38:29 *** Lora concentrator HAL library version info ***
24.07.18 16:38:29 (-0400) main Version: 5.0.1; Options: native;
24.07.18 16:38:29 (-0400) main ***
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Little endian host
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: found global configuration file /opt/ttn-gateway//global_conf.json, parsing it
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: /opt/ttn-gateway//global_conf.json does contain a JSON object named SX1301_conf, parsing SX1301 parameters
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: lorawan_public 1, clksrc 1
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: no configuration for LBT
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: antenna_gain 0 dBi
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: ConfiguringTX LUT with 16 indexes
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: radio 0 enabled (type SX1257), center frequency 904300000, RSSI offset -166.000000, tx enabled 1
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: radio 1 enabled (type SX1257), center frequency 905000000, RSSI offset -166.000000, tx enabled 0
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Lora multi-SF channel 0> radio 0, IF -400000 Hz, 125 kHz bw, SF 7 to 12
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Lora multi-SF channel 1> radio 0, IF -200000 Hz, 125 kHz bw, SF 7 to 12
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Lora multi-SF channel 2> radio 0, IF 0 Hz, 125 kHz bw, SF 7 to 12
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Lora multi-SF channel 3> radio 0, IF 200000 Hz, 125 kHz bw, SF 7 to 12
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Lora multi-SF channel 4> radio 1, IF -300000 Hz, 125 kHz bw, SF 7 to 12
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Lora multi-SF channel 5> radio 1, IF -100000 Hz, 125 kHz bw, SF 7 to 12
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Lora multi-SF channel 6> radio 1, IF 100000 Hz, 125 kHz bw, SF 7 to 12
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Lora multi-SF channel 7> radio 1, IF 300000 Hz, 125 kHz bw, SF 7 to 12
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Lora std channel> radio 0, IF 300000 Hz, 500000 Hz bw, SF 8
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: FSK channel8 disabled
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: /opt/ttn-gateway//global_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: gateway MACaddress is configured to B827EBFFFE59C97D
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Found 1 servers in array.
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Server 0 configured to “bridge.us-west.thethings.network”
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: filename for statistical performance is configured to “loragwstat.json”
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: packets received with a valid CRC will be forwarded
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: packets received with a CRC error will NOT be forwarded
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: packets received with no CRC will NOT be forwarded
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Reference latitude is configured to 43.649138 deg
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Reference longitude is configured to -79.477223 deg
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Reference altitude is configured to 0 meters
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: GPS is enabled
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Using fake GPS coordinates instead of real.
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Upstream data is enabled
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Downstream data is enabled
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Ghoststreamdata is disabled
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Radiostreamdata is enabled
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Statusstream data is enabled
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Beacon is disabled
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Packet logger is disabled
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Flush output after statistic is disabled
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Flush aftereach line of output is disabled
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Watchdog isdisabled
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Contact email configured to “”
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: Descriptionconfigured to “Toronto West - Swansea - RPi3 + RAK831”
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: [Transports] Initializing protocol for 1 servers
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: [TTN] server “bridge.us-west.thethings.network” connected
24.07.18 16:38:29 (-0400) main 20:38:29 INFO: [main] Starting the concentrator
24.07.18 16:38:29 (-0400) main 20:38:29 ERROR: [main] failed to start the concentrator

kersing · July 24, 2018, 9:59pm

Check you set the variabele for the reset right. Also this error might appear a couple of times anyway, however the concentrator should start within 5 minutes.

knoetje · July 24, 2018, 11:50pm

Hi,

I have the same config.
And had the same error : failed to start the concentrator.

The reset pin is at 11 (used my miltimeter to sort it out)

But. Now a strange behaviour of the config.
When i run the following on the console in resin.io of the device: ./mp_pkt_fwd (or /opt/ttn-gateway/mp_pkt_fwd)
(Execute this command in the directory /opt/ttn-gateway/ otherwise it will not detect the global_conf.json)
After a try or 2-3 it would start… (the reset is done by the phyton script thats doing that every 15 seconds)

Can you try this?

My concusion: My board was not DOA
Hope yours also!

After that:
i’ve drilled down in the run.py script where it probably goes wrong…
My ‘solution’ is at the moment… (strange!?)
Is to alter the second last line in run.py to :

subprocess.call([’/opt/ttn-gateway/mp_pkt_fwd’, ‘-c’, ‘/opt/ttn-gateway/’])

Without the SPI_SPEED part…
Change it on your git clone.

After making a new build the concentrator is starting within the 5 min’s Jac is referring to.

I haven’t had the time to investigate it yet…
Dunno why my config is not liking the os.getenv string…

Hope this helps.

Koen Muis

VinceC · July 25, 2018, 4:21am

Hi Koen,

I tried,"./mp_pkt_fwd" and the concentrator did finally work.

I then tried your second suggestion, modified the run.py file. However, I didn’t do a new build but changed the file directly on the RPi. That seem to do the trick, as the concentrator is now working, and the gateway is showing up on the TTN.

Be interesting to know why? I did read somewhere that the SPI clocking on the RPi3 might be causing problems.

Thanks for all your help!

Vincent

kersing · July 25, 2018, 5:53am

The default SPI_SPEED in run.py is not correct. It should be 8000000. There is no need to fix the script if you don’t want to, just set SPI_SPEED to 8000000 in the environment variables where you set the GW_ID too.

mooo · July 25, 2018, 12:30pm

Hi

From the error it looks like the RAK831 is not reseted properly at boot.

I looked in the guide and the reset pin is not correct in the guide.
It is 17 for the RAK converter board.

Change the reset pin and it should work better.

Following script will also reset the RAK831.

#!/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

akshaim · July 25, 2018, 1:23pm

Did you cross check the pin assignment. You may use the following reference wmcBl

McOrts · July 25, 2018, 1:27pm

Thanks a lot for Vincent and Koen. I have the same problem of all of yours and I’ve fixed with the run.py change.
Hi Mooo, Is your solution related to change the environment variable GW_RESET_PIN value 11 to 17?

kersing · July 25, 2018, 3:05pm

No it is pin 11. Python uses the Physical pin number, not BCM or otherwise. (Keep in mind those instructions have been used by 30 workshop attendees during the conference. A wrong reset pin number in the instructions would have been noticed)

The issue has been fixed in the repository so after pulling updates no fix or environment variable is required.

knoetje · July 25, 2018, 3:57pm

I’ve removed the ‘fix’.
And i created a new clone of the repository.
At the moment i’m running with the env variable.
I will delete that.

And i will post the results.

Now investigating why the gps isn’t working.
The device file seems to be ok…/dev/ttyAMA0
But thats another issue.

Koen

knoetje · July 25, 2018, 5:33pm

I’ve also removed the environment variable SPI_SPEED.
And with the updated version it’s starting.
Thanks Jac

Kind regards,

Koen

kersing · July 25, 2018, 6:30pm

Does cat of the device show valid GPS data? (Including fix?)

knoetje · July 25, 2018, 8:33pm

It is not giving me a straigtforward cat…
But with minicom i sometimes get some nmea data… Not all the times.
minicom -b 9600 -o -D /dev/ttyAMA0

So my conclusion at the moment is the ttyAMA0 is correct configured. But there is something wrong with or the GPS reception. Or the antenna.

There is one question that i have atm.
On the convertor board. (Between Rak831 and raspberry) where the gps is soldered on.
There are jumper pads. For the rx-tx of the gps.
These jumper pads are not soldered but they have a 10Ohm resistor.
This resistor is between the gps tx and rx and the pin14/15 of the raspberry.
Can that trigger some strange behaviour?

Kind regards.
Koen

kersing · July 25, 2018, 8:37pm

I don’t know as I haven’t checked the RAK831 setup with gps. I still have to solder the gps module onto the board.

gmos · July 26, 2018, 12:07pm

Regarding GPS. If you are using the RAK adapter board and a Pi with last raspi_config:

Use sudo raspi_config, option 5 Interfacing -> P6 serial. Set to “No login shell” and “Yes hardware enabled”. This will free the UART from OS use but still load the driver. Might need a reboot to effectuate.
The RAK converter board connects the GPS to the UART via the connector. Older versions had jumpers on the front side but mine came with hard connection.
The GPS then appears on /dev/ttyS0. A sudo cat /dev/ttyS0 should give you a stream of NMEA messages on screen.

knoetje · July 27, 2018, 12:06am

TnX Gijs,

I’ve removed the resin based install and went to (for me much comfortable) raspbian install…
And without any issue i got the device file /dev/ttyS0 talking NMEA to me

So also the GPS is working.
What i did do then is to build the packet forwarder on the raspian install.

Thanks again Jac!

And the RAKWireless Pilot Gateway is up and running…

When i have some spare time i will investgate more into resin.
On Resin build: If i look in to /proc/cmdline : console is using /dev/ttyAMA0…

And i’m to stupid understanding resin to get rid of that console
That’s the reason i got sometimes NMEA output…and stalls…

Regards,

Koen

Baxter · July 27, 2018, 3:23am

i also finally gave up and went to gonzalo’s ttn-zh poly packet on jessie. but maybe we should ceeate a resin package with the poly packet forwarder?

kersing · July 27, 2018, 6:28am

[full disclosure: I am the author of mp_pkt_fwd]

Why would you want to run with software that has not been updated for two years, does not use an authenticated protocol to connect to the back-end and has scaling issues when it comes to downlink traffic?

Koen mentioned his issue was resin.io (settings), not the packet forwarder. So using a resin.io build of another packet forwarder would just reintroduce the issue he was having.

For those really looking for resin.io with poly, no need to create something new, just use GitHub - rayozzie/ttn-resin-gateway-rpi

kersing · July 27, 2018, 6:37am

Did you use a DEV resin image or a production one? The latter should not have a console on the tty, the development imaga has. To disable it on the development image see this resin discussion.

Amedee · July 27, 2018, 7:19am

FWIW…

I was kind of “disappointed” by the RAK831 and its GPS backplane: I had planned a full Saturday afternoon to setup the whole thing, but it just took me 15 minutes start-to-finish to have a running gateway accepting packets and reporting its location
It was my first gateway with a RAK861 board and also my first with GPS and I was expecting much more trouble.

I used the rest of the day to design and 3D print an enclosure

I don’t think there is anything wrong with @jpmeijers resin setup or @kersing packet forwarder with the RAK831/GPS hardware. There are a couple of parameters to set (a bit more for RPi3), but AFAIK they are all documented…
(I am using my own fork of the project because I prefer Collectd for metrology, but it doesn’t matter, it is the exact same code base and setup for the packet forwarder)