Thanks AndyG, finally I can connect the gateway to the TTN.
But I have another problem. When I reboot my Raspberry Pi, I got the Kernel Panic error like the picture below shows.
Do you know how to deal with this type of problem?
Hi NorHairil,
I’m definitely not any kind of Raspberry Pi or Linux expert. The error indicates that the Pi cannot find the root file system on the SD card.
The first thing I would try is removing and reinserting the SD card, but I suspect that the file system on the SD card has probably been corrupted somehow.
Have you been getting low power warning messages on the Pi? With the gateway connected you need to make sure that you have a good power supply.
Search the Internet for ways to repair the file system and keep the files. If the SD card has already been used for few years, it is sometimes quicker and safer to redo the build again on a new SD card.
Hi guys , i try to start my gw , but i found this issue root@raspberrypi:/etc/basicstation# systemctl status basicstation.service
● basicstation.service - Basic Sation TTN V3 service
Loaded: loaded (/lib/systemd/system/basicstation.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Tue 2022-01-11 22:19:43 GMT; 3s ago
Process: 1706 ExecStart=/opt/basicstation/bin/station -h /etc/basicstation --radio-init=/etc/basicstation/reset_gw.sh (code=exited, status=1/FAILURE)
Main PID: 1706 (code=exited, status=1/FAILURE)
CPU: 17ms
root@raspberrypi:/etc/basicstation#
Could you please help me with this issue?
Hi Andre.
I think the starting point to investigate your problem is to double check all connections between the Pi and the gateway card. Pay particular attention to which pin the gateway’s reset pin is connected to on the Raspberry Pi. Make sure that you use the correct pin in the reset.sh script.
Make sure that the SPI interface is enabled on the Raspberry Pi.
Also you need a good quality power supply to run the Pi and the gateway card together. I use an official Raspberry Pi power supply. I have tried some phone chargers, but even those rated for 2.2A do not work reliably.
Hi AndyG，
I used a Raspberry Pi 4B and when I want to reset the sx1301(start the reset_gw.sh),I got the error below:
./reset_gw.sh: line 4: echo: write error: Device or resource busy
./reset_gw.sh: line 5: /sys/class/gpio/gpio7/direction: No such file or directory
./reset_gw.sh: line 6: /sys/class/gpio/gpio7/value: No such file or directory
./reset_gw.sh: line 8: /sys/class/gpio/gpio7/value: No such file or directory
./reset_gw.sh: line 10: /sys/class/gpio/gpio7/value: No such file or directory
./reset_gw.sh: line 12: echo: write error: Invalid argument
And the reset_gw.sh is:
#! /bin/bash
SX1301_RESET_BCM_PIN=7
echo “$SX1301_RESET_BCM_PIN” > /sys/class/gpio/export
echo “out” > /sys/class/gpio/gpio$SX1301_RESET_BCM_PIN/direction
echo “0” > /sys/class/gpio/gpio$SX1301_RESET_BCM_PIN/value
sleep 0.1
echo “1” > /sys/class/gpio/gpio$SX1301_RESET_BCM_PIN/value
sleep 0.1
echo “0” > /sys/class/gpio/gpio$SX1301_RESET_BCM_PIN/value
sleep 0.1
echo “$SX1301_RESET_BCM_PIN” > /sys/class/gpio/unexport
First off, is GPIO 7 the signal connected to the concentrator reset on your particular hardware, or did you just copy that from someone else rather than verify it for our specific concentrator to pi adapter board?
And are you actually using basicstation, or did you just post in this topic because of a similar mention?
Not sure if it is the issue, but something I’ve noticed is that on some Linux systems, trying to again export a GPIO that is already exported has the odd effect of unexporting it, causing the /sys/class/gpio/gpio7/ or whatever directory to disappear. If this is such a system and you’re running the script multiple times it’s possible you’ve gotten such a mixed up state.
I’d try the commands manually one at a time checking what’s showing up in sysfs as you do so.
Actually，my concentrator is RHF0M301 and I am setting it through the method.Then I met this error.
My imager is “2022-01-28-raspios-bullseye-armhf.img”，the latest imager download in Operating system images – Raspberry Pi
As cslorabox says, you need to know which RPi GPIO pin is connected to your concentrator’s reset pin.
My notes describe how to make Pin 7 available to use as a reset pin. The script provided works for the adapter board supplied with my rhf0m301 from Seeed Studios which connects Pin 7 to reset. This is a problem with modern Rasbian builds which assume that Pin 7 is available as a chip select pin for SPI.
If your reset pin is connected to Pin 7 you will need to make it available by adding
overlay=spi0-1cs
in the [all] section of /boot/config.txt. This will tell Rasbian not to reserve Pin 7 as a Chip Select pin for SPI.
I think that more recent concentrator cards and adapter boards avoid using Pin 7, so check the documentation to see which pin is being used.
dtoverlay or overlay？
I have already added the dtoverlay = spi0-1cs like you said
Sorry, yes that was a cut and paste error.
The errors you are seeing are pretty much the same as I saw without the dtoverlay = spi0-1cs.
Is there anything else you are doing that might be setting/ resetting the modern RPi defaults for SPI after the boot phase? do you have any other SPI devices attached to the Pi besides the concentrator card?
There is nothing besides the concentrator.
And my situation is just like the NorHairil——it keeps disconnect and connect and repeat
Trace the circuit between the reset pin on the rhf0m301 and the RPi pin to make absolutely certain that you have the correct pin number.
If that is correct, you might try adjusting the speed of the SPI bus down to a lower level. I’m using an RPi 3B+. Is the RPi 4 SPI bus faster?
1 Like
Note that while miswiring or SPI clock issues could cause the concentrator not to operate, neither can explain the software error of the reset script itself.
That script would work just fine on a properly configured pi that didn’t have any concentrator attached at all, it’s the next stage of trying to actually talk to the concentrator where a wiring or signal integrity issue would present itself.
Checking that the pin wasn’t reserved in the boot config for another purpose was a good idea.
Beyond that, I personally would make sure I’d disabled any autorun of the gateway software, then reboot the pi, and try manually doing what the script does while checking to see if the /sys/class/gpio/gpio7 directory gets created and lets me manipulate the IO settings.
my list doesn’t has this directory
And my gpio is just like this
Then you’re in a position to try manually exporting it.
If the directory already existed, it would be already exported.
Hi, This is what I see on my Pi. Note that gpio-7 is not listed as spi0 CS1, and I only have gpio-8 as spi0 CS0
pi@salemfarms2:~ $ sudo cat /sys/kernel/debug/gpio
gpiochip0: GPIOs 0-53, parent: platform/3f200000.gpio, pinctrl-bcm2835:
gpio-8 ( |spi0 CS0 ) out hi ACTIVE LOW
gpio-29 ( |led0 ) out lo
gpiochip1: GPIOs 504-511, parent: platform/soc:firmware:expgpio, raspberrypi-exp-gpio, can sleep:
gpio-506 ( |led1 ) out lo ACTIVE LOW
pi@salemfarms2:~ $
and this is the end of my config.txt file
[all]
#dtoverlay=vc4-fkms-v3d
dtoverlay=spi0-1cs
start_x=0
enable_uart=0
pi@salemfarms2:/boot $
This is after adding the dtoverlay=spi0-1cs in the [all] section at the end of the /boot/config.txt file on a Pi4
pi@raspberrypi:~ $ sudo cat /sys/kernel/debug/gpio
gpiochip0: GPIOs 0-57, parent: platform/fe200000.gpio, pinctrl-bcm2711:
gpio-0 (ID_SDA )
gpio-1 (ID_SCL )
gpio-2 (SDA1 )
gpio-3 (SCL1 )
gpio-4 (GPIO_GCLK )
gpio-5 (GPIO5 )
gpio-6 (GPIO6 )
gpio-7 (SPI_CE1_N )
gpio-8 (SPI_CE0_N |spi0 CS0 ) out hi ACTIVE LOW
gpio-9 (SPI_MISO )
gpio-10 (SPI_MOSI )
gpio-11 (SPI_SCLK )
gpio-12 (GPIO12 )
gpio-13 (GPIO13 )
Note that gpio-7 does not have
|spi0 CS1 ) out hi ACTIVE LOW
And what happens when you try to manually export and operate the GPIO after a fresh boot when the script has never run?