Change gpiochip0 to gpiochip15

[t984447]

I got an issue where the UI never manages to connect to the LoRa Radio (?) and I suspect I need to change which gpiochipX is used.
How do change this value?

Below is the results of running the doctor.

USERNAME@clockworkpi:~ $ meshcore-console doctor
[OK] linux: Expected Linux host
[OK] spidev: Expected SPI1 device /dev/spidev1.0 — ensure dtoverlay=spi1-1cs is in /boot/firmware/config.txt
[FAIL] gpiochip: Expected GPIO chip /dev/gpiochip0
[OK] pymc_core: Python module import succeeded

I suspect the issue is that its trying to find the radio on gpiochip0
while a recent forum topic hints that it might be gpiochip15: Solved: Meshtastic connection failed?.

I forgot to mention that even after installing a fresh install of Meshtastic it still wasn’t opening. I found the issue. On the pi 5, the GPIO header isn’t assigned to gpiochip0 like Meshtastic expects by default—it’s assigned to gpiochip15. Because of that, Meshtastic was trying to access the wrong GPIO controller and crashed during startup. After I changed the Lora configuration text file to use gpiochip: 15, Meshtastic started working.

Cannot find gpiochip0

With aiov2_ctl lora on I find no gpiochip0

USERNAME@clockworkpi:~ $ find /dev/ -name "gpiochip"
/dev/gpiochip15
/dev/gpiochip14
/dev/gpiochip13
/dev/gpiochip12
/dev/gpiochip11

My setup

HG = Hackergadgets

• uConsole
• CM5 16 GB + Wifi + LITE [CM55116000]
• HG AIOv2

Runnig Rex's Debian Trixie with the new kernel akrex-kernel-7.1

[zomgugoff]

A temporary fix is to make a symlink from gpiochip15 to gpiochip0. This can be done to survive reboots with a udev rule. Create the file /etc/udev/rules.d/99-gpiochip.rules and add this to it:

KERNEL=="gpiochip15", SYMLINK+="gpiochip0"

Save and reboot.

[t984447]

A temporary fix is to make a symlink from gpiochip15 to gpiochip0. This can be done to survive reboots with a udev rule. Create the file /etc/udev/rules.d/99-gpiochip.rules and add this to it:

KERNEL=="gpiochip15", SYMLINK+="gpiochip0"

Save and reboot.

Thanks for the tip. I tried it (both manually linking or using the udev rule) but neither seems to work fully.
The app now connects but the LoRa seems defen. Not sure if there is something else..

Running doctor gives no fail now which is positive.

USERNAME@clockworkpi:/home/USERNAME# meshcore-console doctor
[OK] linux: Expected Linux host
[OK] spidev: Expected SPI1 device /dev/spidev1.0 — ensure dtoverlay=spi1-1cs is in /boot/firmware/config.txt
[OK] gpiochip: Expected GPIO chip /dev/gpiochip0
[OK] pymc_core: Python module import succeeded

[cwill747]

Opened #89 to make this configurable properly, so the udev symlink isn't needed.

What was wrong: the app hardcoded /dev/gpiochip0 and never passed the radio driver's gpio_chip parameter, so there was no supported way to point at chip 15. @zomgugoff's symlink was the only workaround.

#89 adds three hardware settings — Settings > Hardware, or env vars:

Env var	What it does
MESHCORE_GPIO_CHIP=15	which /dev/gpiochipN to open
MESHCORE_EN_PINS=16,17	GPIO pins driven HIGH at init to power the radio
MESHCORE_USE_GPIOD_BACKEND=1	poll for IRQ edges instead of using edge interrupts

doctor also stops asserting chip 0 and now tells you what your host actually has:

[FAIL] gpiochip: Configured GPIO chip /dev/gpiochip0 not found — available: 11, 12, 13, 14, 15.
       Set it in Settings > Hardware or via MESHCORE_GPIO_CHIP (CM5/Pi 5 kernels usually put
       the 40-pin header on 15, not 0).

---

I can't reproduce this locally — I don't have CM5 hardware — so I'd rather not ship it unverified. If either of you is able to test from the branch:

git clone -b fix-85 https://github.com/cwill747/meshcore-uconsole
cd meshcore-uconsole
uv venv --python python3 --system-site-packages && uv sync
MESHCORE_GPIO_CHIP=15 uv run meshcore-console doctor

Remove the udev rule first, so we're testing the real fix rather than the symlink.

@t984447 — on the "connects but the LoRa seems deaf" part, that's likely a separate problem from the chip number, and I have two guesses:

1. The AIOv2 has a LoRa power-enable line that we never drive. The driver supports it and we now expose it, but I don't know which pin(s) HackerGadgets used. If you can find that in their docs or schematic, try MESHCORE_EN_PINS=<pin>.
2. The Trixie/akrex kernel may be rejecting the GPIO edge request, which would leave the radio initialised but never firing its receive interrupt — exactly "connects but deaf." Try MESHCORE_USE_GPIOD_BACKEND=1, which switches to a polling thread instead.

Worth trying them one at a time so we know which one mattered. If neither helps, uv run meshcore-console export-logs output from a failed connect would tell me a lot more than the doctor summary does.

[zomgugoff]

The AIO V2 enable pin is 27: https://hackergadgets.com/pages/hackergadgets-uconsole-rtl-sdr-lora-gps-rtc-usb-hub-all-in-one-extension-board-setup-guide

[zomgugoff]

Trying this fixed version, the program is still trying to use gpiochip0. It at least now warns that the setting needs to be changed, but the variable appears to be ignored. Trying to boot the fixed version without the variable provides the same warning, and a 'settings' button that doesn't pull up the settings.

That said, creating the symlink to get access to the settings and changing the GPIO pin does work.

[cwill747]

I pushed another fix - can you try?

[zomgugoff]

That works. The variable works and the settings button dismisses the warning.

[cwill747]

Pushed one more change to that PR that fixes that the settings weren't actually showing up