RAK5146 (SPI) not detected on RAK7391 — chip version 0x00 on both mPCIe slots - Am I dealing with a faulty module?

[Qfournier (Quentin Fournier)]

Hello everyone,

I’m setting up a RAK7391 WisGate Connect (CM4) with a RAK5146 (SPI, SX1303) concentrator, and the concentrator is not detected. The SPI interface opens fine, but the SX1303 always returns chip version 0x00 and never enters STANDBY_RC. I’ve done quite a bit of troubleshooting and I suspect a hardware fault, but I’d like a second opinion before requesting an RMA.

Hardware

• Gateway: RAK7391 WisGate Connect
• Concentrator: RAK5146 SPI (SX1303), Model RAK5146
• OS: RAKPiOS 0.9.0 (Bookworm), kernel 6.6.31+rpt-rpi-v8, libgpiod 1.6.3

Symptom

• Semtech sx1302_hal chip_id: “Opening SPI communication interface / Note: chip version is 0x00 (v0.0) / ERROR: Failed to set SX1250_0 in STANDBY_RC mode”.
• RAK udp-packet-forwarder Docker image (auto-detect, SPI): “ERROR: DEVICE set to auto discover but no concentrator found! (INTERFACE set to SPI)”.

What I’ve already tested

• SPI bus opens with no access error; /dev/spidev0.0 is free (fuser confirms).
• mPCIe slot #1: /dev/spidev0.0 + reset GPIO17 (per RAK7391 datasheet) → chip 0x00.
• mPCIe slot #2: /dev/spidev0.1 + reset GPIO6 (per RAK7391 datasheet) → chip 0x00.
• Reset sequence via gpiod (gpioset, held states, low-high-low) runs with no error.
• Card physically reseated; LoRa antenna (u.FL) connected to ANT1.
• Tested with both the Semtech HAL and RAK’s official udp-packet-forwarder — same result.

Since the SX1303 doesn’t respond on two different SPI buses with two different reset GPIOs, using both the Semtech HAL and RAK’s own forwarder, I’m leaning towards a faulty module. Am I missing anything, or does this look like a hardware fault to you?

logs :

$ cat /etc/os-release | head -2
PRETTY_NAME="RAKPiOS 0.9.0 (bookworm)"
NAME="RAKPiOS"

$ uname -a
Linux rakpios 6.6.31+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.31-1+rpt1 (2024-05-29) aarch64 GNU/Linux

$ ls -l /dev/spidev*
crw-rw---- 1 root spi 153, 0 /dev/spidev0.0
crw-rw---- 1 root spi 153, 1 /dev/spidev0.1

$ gpioinfo gpiochip0 | grep -E "line +(6|17|18)"
line   6:  "GPIO6"   unused  input   active-high
line  17:  "GPIO17"  unused  output  active-high
line  18:  "GPIO18"  unused  input   active-high

$ gpioset --version | head -1
gpioset (libgpiod) v1.6.3

# Clean gpiod reset on GPIO17 (slot #1), then chip_id:
$ ./chip_id
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: failed to start the gateway

The reset on GPIO17 runs cleanly via gpiod (no error), and chip_id still returns 0x00 immediately after. Same result on slot #2 (spidev0.1 + GPIO6) and with RAK’s own udp-packet-forwarder image. This is why I suspect a faulty module.

[Nikola (Nikola Semov)]

Hello @Qfournier ,

As far as I can see, you are setting up the correct settings. You should be able to run the concentrator on mPCIe slots 1 and 2.
Can you please show me a picture of the concentrator lable on direct message (personal message)?

Best Regards,
Nikola Semov

[Qfournier (Quentin Fournier)]

Hello Nikola,
it seems I can’t send you a message.
Do I need a status upgrade to talk to moderators ?

Best regards,
Quentin

[Nikola (Nikola Semov)]

I wrote you message; can you see it? I will check the rights.

[Qfournier (Quentin Fournier)]

Thank you for your Answer Nikola, here are the pictures of the configuration I am trying to put together.

Quentin

[Nikola (Nikola Semov)]

The concentrator is USB, not SPI.
Check if you see it on the USB bus. The reset pin is PIN13 of the concentrator, which is GPIO12 on mPCIe slot 1.

You can check if you can get the concentrator running like that. If you have no success, you can contact [email protected] (so we can check the order number or exchange other sensitive information and keep it confidential because this is a public thread and anyone can see it)

Nikola