search

Lora-net / sx1302_hal

SX1302/SX1303 Hardware Abstraction Layer and Tools (packet forwarder...)
Other
219 stars 271 forks source link

Failed to start the concentrator with kernel 6.6.22 (Pi 4B Bookworm + SX130X) #120

Open timiman opened 2 months ago

timiman commented 2 months ago

I'm unable to start a SX130X as concentrator under kernel 6.6.22 on a Pi 4B. Running reset_lgw.sh, outputs: ./reset_lgw.sh: 26: echo: echo: I/O error ./reset_lgw.sh: 27: echo: echo: I/O error ./reset_lgw.sh: 28: echo: echo: I/O error ./reset_lgw.sh: 29: echo: echo: I/O error ./reset_lgw.sh: 32: cannot create /sys/class/gpio/gpio17/direction: Directory nonexistent ./reset_lgw.sh: 33: cannot create /sys/class/gpio/gpio22/direction: Directory nonexistent ./reset_lgw.sh: 34: cannot create /sys/class/gpio/gpio18/direction: Directory nonexistent ./reset_lgw.sh: 35: cannot create /sys/class/gpio/gpio13/direction: Directory nonexistent CoreCell reset through GPIO17... SX1261 reset through GPIO17... CoreCell power enable through GPIO18... CoreCell ADC reset through GPIO13... ./reset_lgw.sh: 45: cannot create /sys/class/gpio/gpio18/value: Directory nonexistent ./reset_lgw.sh: 47: cannot create /sys/class/gpio/gpio17/value: Directory nonexistent ./reset_lgw.sh: 48: cannot create /sys/class/gpio/gpio17/value: Directory nonexistent ./reset_lgw.sh: 50: cannot create /sys/class/gpio/gpio22/value: Directory nonexistent ./reset_lgw.sh: 51: cannot create /sys/class/gpio/gpio22/value: Directory nonexistent ./reset_lgw.sh: 53: cannot create /sys/class/gpio/gpio13/value: Directory nonexistent ./reset_lgw.sh: 54: cannot create /sys/class/gpio/gpio13/value: Directory nonexistent

By default the reset GPIO pin was pointing to 23, but found that 17 is the correct one for this SX130X. It seems like the GPIO number has changed for 6.6.22 , as I'm getting: grep -s . /sys/class/gpio/gpiochip*/* /sys/class/gpio/gpiochip512/base:512 /sys/class/gpio/gpiochip512/label:pinctrl-bcm2711 /sys/class/gpio/gpiochip512/ngpio:58 /sys/class/gpio/gpiochip570/base:570 /sys/class/gpio/gpiochip570/label:raspberrypi-exp-gpio /sys/class/gpio/gpiochip570/ngpio:8

User running all above is in group 'gpio'.

Does the reset_lgw.sh needs changes to work with new GPIO numbering ?

wildekek commented 2 months ago

Just for confirmation: I just ran into the same issue. [Edit] Seems like GPIO sysfs is deprecated and superseded by libgpiod. We can make a patch to fix the sysfs paths for now, but support for this will likely end in the near future. https://waldorf.waveform.org.uk/2022/the-one-where-dave-breaks-stuff.html

timiman commented 2 months ago

I've seen that article too. I've also sent a tech support to waveshare.

wildekek commented 2 months ago

Looks like it is fairly trivial to use the gpiod command line tools for the reset script: https://manpages.debian.org/experimental/gpiod/index.html

I'll give that a go and let you know if that fixes everything.

wildekek commented 2 months ago

I think that this repo should be marked as deprecated.

I switched to Basic Station using this repo which supports libgpiod.

working docker-compose example for your convenience:

services:

  basicstation:
    image: xoseperez/basicstation:latest
    container_name: basicstation
    restart: unless-stopped
    privileged: true
    network_mode: host      # required to read main interface MAC instead of virtual one
    environment:
      MODEL: "WM1302"
      DEVICE: "AUTO"
      USE_LIBGPIOD: 1
      RESET_GPIO: 17
      POWER_EN_GPIO: 18
      TC_KEY: "***"
      CUPS_KEY: "***"
      SERVER: "***"
timiman commented 2 months ago

I think that this repo should be marked as deprecated.

I switched to Basic Station using this repo which supports libgpiod.

working docker-compose example for your convenience:

services:

  basicstation:
    image: xoseperez/basicstation:latest
    container_name: basicstation
    restart: unless-stopped
    privileged: true
    network_mode: host      # required to read main interface MAC instead of virtual one
    environment:
      MODEL: "WM1302"
      DEVICE: "AUTO"
      USE_LIBGPIOD: 1
      RESET_GPIO: 17
      POWER_EN_GPIO: 18
      TC_KEY: "***"
      CUPS_KEY: "***"
      SERVER: "***"

I think it misses GPS support which Waveshare's SX130X includes in its hardware implementation

mcoracin commented 2 months ago

Hello, This issue will be addressed with the next release of this repo, sorry for the inconvenience. :/ Thanks for the feedback.

KonRoz commented 1 month ago

Is there any fix for the time being?

mcoracin commented 1 month ago

@KonRoz for now nothing official, but in the meantime you can check what has been done here: https://github.com/xoseperez/basicstation-docker/blob/master/runner/reset.sh.gpiod

timiman commented 1 month ago

@KonRoz for now nothing official, but in the meantime you can check what has been done here: https://github.com/xoseperez/basicstation-docker/blob/master/runner/reset.sh.gpiod

From a quick test I've done, it seems to reset correctly now, by using the following values for a Waveshare SX130X board on a RPi4 w/ 6.6.28 Kernel: GPIO_CHIP="gpiochip0" RESET_GPIO="23" POWER_EN_GPIO="18" POWER_EN_LOGIC="18"

davidgs commented 1 month ago

I'm also hitting this problem on a Pi 4. Looks like this repo hasn't had a release in 3 years, and isn't being actively maintained. Is there a better solution? I'd rather not go the Docker route.

mcoracin commented 1 month ago

Hello, I am currently looking into this. I'll post here a new reset_lgw.sh script for gpiod usage to unblock until the release is done. For the later release, I was thinking about making the reset.sh script configurable through the command line, so that one can use the sysfs one of the gpiod one depending on its setup.

timiman commented 1 month ago

That's good news. Although Lora is working just fine on TTN v3, it seems that its GPS cannot return valid data even under clear and direct sky, always while running packet_forwarder. It logs:

### [GPS] ###
# Valid time reference (age: 0 sec)
# no valid GPS coordinates available yet

Maybe this issue should also be checked if it has been broken too, due to newest kernel of Linux ?

mcoracin commented 1 month ago

Hello all, Please find attached an updated reset script using gpiod. I've quickly tested it on a Raspberry Pi 4. @davidgs let me know if it fixes your issue. reset_lgw.gpiod.sh.tar.gz Best regards, Michael

mcoracin commented 1 month ago

@timiman I'll check the GPS on RPi4 too

davidgs commented 1 month ago

At least on my RPI4, with a WM1302, no. 

*** Packet Forwarder ***
Version: 2.1.0
*** SX1302 HAL library version info ***
Version: 2.1.0;
***
INFO: Little endian host
INFO: found configuration file global_conf.json, parsing it
INFO: global_conf.json does contain a JSON object named SX130x_conf, parsing SX1302 parameters
INFO: com_type SPI, com_path /dev/spidev0.0, lorawan_public 1, clksrc 0, full_duplex 0
INFO: antenna_gain 0 dBi
INFO: Configuring legacy timestamp
INFO: Configuring Tx Gain LUT for rf_chain 0 with 16 indexes for sx1250
INFO: radio 0 enabled (type SX1250), center frequency 867500000, RSSI offset -215.399994, tx enabled 1, single input mode 0
INFO: radio 1 enabled (type SX1250), center frequency 868500000, RSSI offset -215.399994, tx enabled 0, single input mode 0
INFO: Lora multi-SF channel 0>  radio 1, IF -400000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 1>  radio 1, IF -200000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 2>  radio 1, IF 0 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 3>  radio 0, IF -400000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 4>  radio 0, IF -200000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 5>  radio 0, IF 0 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 6>  radio 0, IF 200000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora multi-SF channel 7>  radio 0, IF 400000 Hz, 125 kHz bw, SF 5 to 12
INFO: Lora std channel> radio 1, IF -200000 Hz, 250000 Hz bw, SF 7, Explicit header
INFO: FSK channel> radio 1, IF 300000 Hz, 125000 Hz bw, 50000 bps datarate
INFO: global_conf.json does contain a JSON object named gateway_conf, parsing gateway parameters
INFO: gateway MAC address is configured to AA555A0000000000
INFO: server hostname or IP address is configured to "localhost"
INFO: upstream port is configured to "1730"
INFO: downstream port is configured to "1730"
INFO: downstream keep-alive interval is configured to 10 seconds
INFO: statistics display interval is configured to 30 seconds
INFO: upstream PUSH_DATA time-out is configured to 100 ms
INFO: packets received with a valid CRC will be forwarded
INFO: packets received with a CRC error will NOT be forwarded
INFO: packets received with no CRC will NOT be forwarded
INFO: GPS serial port path is configured to "/dev/ttyS0"
INFO: Reference latitude is configured to 0.000000 deg
INFO: Reference longitude is configured to 0.000000 deg
INFO: Reference altitude is configured to 0 meters
INFO: Beaconing period is configured to 0 seconds
INFO: Beaconing signal will be emitted at 869525000 Hz
INFO: Beaconing datarate is set to SF9
INFO: Beaconing modulation bandwidth is set to 125000Hz
INFO: Beaconing TX power is set to 14dBm
INFO: Beaconing information descriptor is set to 0
INFO: global_conf.json does contain a JSON object named debug_conf, parsing debug parameters
INFO: got 2 debug reference payload
INFO: reference payload ID 0 is 0xCAFE1234
INFO: reference payload ID 1 is 0xCAFE2345
INFO: setting debug log file name to loragw_hal.log
INFO: [main] TTY port /dev/ttyS0 open for GPS synchronization
CoreCell power enable on through GPIO18...
CoreCell reset through GPIO17...
SX1261 reset through GPIO5...
CoreCell ADC reset through GPIO13...
Opening SPI communication interface
Note: chip version is 0x00 (v0.0)
ERROR: Failed to set SX1250_0 in STANDBY_RC mode
ERROR: failed to setup radio 0
ERROR: [main] failed to start the concentrator
mcoracin commented 1 month ago

@davidgs which version of the WM1302 do you have exactly (seeed product reference) ? Are the GPIOs correct for your setup ? SPI is properly configured on your RPi ?

mcoracin commented 1 month ago

@timiman I've tested the GPS on my RPi4, and I see no issue, it is working as expected for me.

What do you get when you do a "cat /dev/ttyS0" ?

Have you enabled the serial interface, and modified the /boot/firmware/cmdline.txt to free the serial0 ?

timiman commented 1 month ago

Serial Port is enabled.

With "sudo cat /dev/sttyS0" I get fast scrolling text with ( hide/altered with ##'s location data ): `01NTENNA ▒▒▒▒ 300.000,####.553##.95298,E,1,12,M,,7C 757.5539E,134300.000,A,A02,03,08,10,21,20.9,1.1,138 $G1,72,,,,,,,,,1.4,231 $43,312,4248,23,0,##,10,3GPGSV,3,21,60,326,28,05,69 $GP09,32,###5E $G,09,78,06,05,203183,,65,3,070 ,72,038,,118,,8126,71,05SV,3,3,0032,18,0RMC,1343398,N,02,33.97,2A,V39 3.97,T,,A1D $G300.000,24,00,001,01,ANT35 ▒b ▒▒ GA,13430,N,023##,1,12,0.,7F $G7.55395,95298,E,00,A,A4A,A,3,020,21,27,,,1.4,0.38 $GNG72,,,,,,.9,1.1,2GSV,3,1,,312,43,8,23,08,7,10,31,GSV,3,2,,313,,21,171,27,2,15,06,32,50,05E $GLG9,78,09,05,203,,3,,65,82070 $G,09,88,7,87,29,19,325,2626,,07172,22,03D $GNRM.000,A,35,N,0233E,0.00,3V35 $G97,T,,M,.00,K,ADA,13430,05,20248 $GPTX01,ANTEN ▒b ,134302..55392,N,12,0.9,7B $GNG55392,N,4302.000 $GNGSA,21,27,281.4,0.9,,A,3,65,,1.4,0.91 $GPGS,02,43,3,19,248,,217,##,4 3,3,09,3,06,30,324,3##1,27,2815,068 $GLGSV,3,1,09,,203,,75,22,183,70 $GLGSV,3,2,07,29,118,,81,29,,,071 $GLGSV,318,04D $GNRMC,7.55392,N,023##.97,27052TG,33.97,T,,M,0. ,ANTENNA OK350,004B k▒$GNGGA,15389,N,023##.952.9,M,##.9,M,,71,##57.553##.9529,A4F $GNGSA,A,,27,28,34,0.9,1.1,138 ,81,72,,,,,,,,,1 3,2,09,1,,21,60,7,39,1715,122,15GPGSV,3,50,073,3$GLGSV,3,09,262,03,,75,25,82,052 $GLGSV88,72,0329,118,,5,26,71,071 $G,09,72,2,04D $,A,##57.298,E,0.,,A,V3A,,M,0.00$GNZDA,10,27,05,004A $,01,01,AK35 ▒b NGGA,134##57.553##.952980.9,41.9M,,78 757.55387.95298,.000,A,AGSA,A,3,,10,21,2,,,,1.4,138 $G,65,88,8,,,,,1.4,231 $1,09,02,43,312,44,8,24,08,7,10,31,GSV,3,2,09,14,0633,27,39,171,27,8 $GPGSV,3,3,095D $GLGSV,3,1,005,203,,75,22,18070 $GLGSV,3,2,87,29,118,,81,226,,071 $GLGSV2,18,04D $GNRM757.55387,N,02333.97,270524,,,A,97,T,,M,0.00,N,0DA,134304.000,27D $GPTXT,01,01, ▒b ▒,134305.000,##575298,E,1,12,0.9,7A $GNGLL,##57.298,E,134305.000A,3,02,03,08,10,1.4,0.9,1.1,13888,81,72,,,,,,,,1 $GPGSV,3,1,09,19,248,24,08,640,33,064 2,50,073,32,05D78,09,26,203,,75,65,82,0SV,3,2,07,29,118,,81,29,,22,07172,22,03C,1343054,N,02333.97,270V31 $G97,T,,M,1D $GNZDA,13430,00,004C $GPTX01,ANTENx6$GNGGA.55381,N,12,0.9,76 $GNGL5381,N,023##.952A,A42 $GNGSA,A,08,10,21,27,28,.1,138 $GNGSA,,,,,,,,,1.4,0.9,,3,1,09,02,43,314,08,64,217,##,1 $GPGSV,3,2,09,,324,33,27,39,175,068 8,09,26222,183,,0 $GLGS,88,72,0,81,29,322,071 $GLGSV,,18,04D $GNRMC57.55381,0.00,33##

134307.000,##57.299,E,1,12,0.9,4F0A OK*35

$GNGLL,##57.523##.95299,E,134A,A4B $GNGSA,A,08,10,21,27,28,34,0.9,1.$GNGSA,A,81,72,,.4,0.9,1 3,2,09,1,,21,60,7,39,171^C,64,233,064 `

From the test python code of L76K found on Waveshare's site, the GPS data is generated just fine. It seems that its output is clear without any errors or missed characters as shown below: Baidu coordinate ##.96389292167206 , ##.646300276335587 $GNGSA,A,3,02,03,08,21,27,28,32,,,,,,1.8,1.0,1.5,1*39 $GNGSA,A,3,66,88,81,,,,,,,,,,1.8,1.0,1.5,2*37 $GPGSV,3,1,09,02,50,317,41,03,25,255,40,08,56,207,40,10,24,054,08,0*6F $GPGSV,3,2,09,14,06,305,,21,67,333,36,27,30,171,24,28,10,116,23,0*67 $GPGSV,3,3,09,32,46,062,35,0*5D $GLGSV,3,1,10,78,09,262,,66,52,211,36,76,05,203,,75,22,183,,0*77 $GLGSV,3,2,10,65,81,047,21,88,74,076,19,87,22,126,,81,38,329,26,0*7D $GLGSV,3,3,10,71,05,026,,72,21,032,,0*78 $GNRMC,140135.000,A,##57.54932,N,0##37.95252,E,0.00,33.97,270524,,,A,V*33 $GNVTG,33.97,T,,M,0.00,N,0.00,K,A*1D $GNZDA,140135.000,27,05,2024,00,00*4E $GPTXT,01,01,01,ANTENNA OK*35 $GNGGA,140136.000,##57.54932,N,0##37.95253,E,1,10,1.0,47.6,M,37.9,M,,*79 $GNGLL,##57.54932,N,0##37.95253,E,140136.000,A,A*44

Also, if I run packet_forwarder and try the python GPS example, packet_forwarder shows endless scrolling of text, "WARNING: [gps] read() returned value 0", because of the conflict of accessing GPS from two applications at the same time, I guess.

Finally, the baud-rate of the serial port from python example above is set to 9600. Maybe the baud-rate is different on packet-forwarder ?

mcoracin commented 1 month ago

@timiman I've never used the Waveshare board, but I've ordered one to test.

What do you get if you do "cat /boot/firmware/cmdline.txt" on your RPi ?

The baudrate is the same as what is used by the hal to configure the serial port: https://github.com/Lora-net/sx1302_hal/blob/4b42025d1751e04632c0b04160e0d29dbbb222a5/libloragw/src/loragw_gps.c#L58

Maybe you could create a separate issue for this, it is quite different from the initial issue reported here. :)

timiman commented 1 month ago

cat /boot/firmware/cmdline.txt gives: console=tty1 console=serial0,115200 root=PARTUUID=0a5e2d69-02 rootfstype=ext4 fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles cfg80211.ieee80211_regdom=GR

mcoracin commented 1 month ago

Could you try to remove the console=serial0,115200 from this file ? This was already required to be removed on previous RPi versions, it creates a conflict on /dev/ttyS0 access. This should allow the packet forwarder to read the output of the GPS.

timiman commented 1 month ago

Could you try to remove the console=serial0,115200 from this file ? This was already required to be removed on previous RPi versions, it creates a conflict on /dev/ttyS0 access. This should allow the packet forwarder to read the output of the GPS.

No change. Same message. I will open a new issue.

mcoracin commented 1 month ago

@timiman even after a reboot of the RPi ? When opening the new issue, could you indicate :

davidgs commented 1 month ago

@davidgs which version of the WM1302 do you have exactly (seeed product reference) ? Are the GPIOs correct for your setup ? SPI is properly configured on your RPi ?

WM1302 Model #WM1302-SPI-EU868-M SPI is set up properly, and the Pins are correct (as best I can tell)

GPIO_CHIP=gpiochip0
GPIO_PIN_SX1302_RESET=17     # SX1302 reset
GPIO_PIN_SX1302_POWER_EN=18  # SX1302 power enable
GPIO_PIN_SX1261_RESET=5     # SX1261 reset (LBT / Spectral Scan)
GPIO_PIN_AD5338R_RESET=13    # AD5338R reset (full-duplex CN490 reference design)
davidgs commented 1 month ago

I have gotten it working. The problem was that I was not using a Pi HAT. I was trying to use the card directly via the M.2 slot on our board, which it turns out does not have access to any of the Pi-header pins.

mcoracin commented 3 weeks ago

I have gotten it working. The problem was that I was not using a Pi HAT. I was trying to use the card directly via the M.2 slot on our board, which it turns out does not have access to any of the Pi-header pins.

Ok, good news. :) So the script that I shared is working for you, right ?

FMMT666 commented 2 weeks ago

Ok, good news. :) So the script that I shared is working for you, right ?

Also thx from over here.

Created a RPi CM4 test setup a couple of days ago and immediately got stuck
due to this obsolete pin control issues.

Thx for sharing; exactly what I needed. A true time saver :)

hereismeaw commented 3 days ago

Hello all, Please find attached an updated reset script using gpiod. I've quickly tested it on a Raspberry Pi 4. @davidgs let me know if it fixes your issue. reset_lgw.gpiod.sh.tar.gz Best regards, Michael

Comfirmed this Works on WM1302 module in SenseCAP M1 AS923 Region.

Debian 12, Kernel 6.6.31

Great work!