(2025-11-23, 03:48 PM)ssth@yahoo.com Wrote: (2025-11-12, 10:04 PM)seandepagnier Wrote: what happens if you stop pypilot hat:
sudo systemctl stop pypilot_hat
then run it from the console:
sudo pypilot_hat
and post the output? I am wondering if it is using the wrong lcd driver. Otherwise it could be defective lcd.. Can you connect to localhost:33333 in a browser?
I am going through this step by step as I want this resolved once and for all. This has been a two year process and so far to no avail.
I reloaded all software and started over. On running pypilot from Openplotter, Pypilot 4.0.11opens. Sometimes IMU is detected, on this occasion, IMU is not detected. I checked "Enable Hat Control and clicked the configure button which resulted in the program locking up resulting in rebooting and starting over.
After rebooting, I ran "sudo pypilot .hat from the terminal, resulting in "command not found" Apparently, pypilot.hat is not loaded.
Next step?
Best regards, Steve
There is apparently a problem with the Hat and pin 17 on my R pI 4. Edge Detection Following is a description of my steps using Copilot.
Library mismatch PyPilot HAT may still be using legacy RPi.GPIO calls, which rely on /sys/class/gpio. On newer Raspberry Pi OS builds, GPIO is exposed via /dev/gpiochip* and managed by libgpiod. Edge detection often fails if the library isn’t updated.
Double export conflict If PyPilot HAT tries to export GPIO17 via /sys/class/gpio while libgpiod already owns it, you’ll see “failed to add edge detection” even though gpioinfo shows it unused.
Electrical state Edge detection requires a stable signal. If GPIO17 is floating (no pull-up/down resistor), the library may refuse to register interrupts. You can test by enabling a pull-up:
bash
gpio -g mode 17 up
? Next diagnostic step
Try edge detection outside PyPilot:
bash
sudo gpiomon gpiochip0 17
If this works (you see events when toggling the pin), then the kernel and hardware are fine → the issue is in PyPilot HAT’s code or its use of RPi.GPIO.
If this fails, then the kernel/device tree is blocking edge detection → likely an overlay or driver conflict.
⚡ Practical path forward
If gpiomon succeeds → patch PyPilot HAT to use libgpiod instead of RPi.GPIO.
If gpiomon fails → check /boot/config.txt for overlays using GPIO17 (it’s often tied to hardware functions like UART or special HAT pins).
Would you like me to walk you through patching PyPilot HAT’s Python code to use libgpiod for edge detection, or focus on checking overlays in /boot/config.txt to rule out conflicts on GPIO17?
sudo gpiomon gpiochip0 17
Running
bash
sudo gpiomon gpiochip0 17
is the right way to test whether edge detection works at the kernel level. Here’s what to expect and how to interpret it:
? What happens
If successful, gpiomon will sit and wait silently.
When you physically toggle GPIO17 (for example, press a button wired to that pin, or jumper it to 3.3V/ground), it will print a line like:
Code
event: FALLING EDGE timestamp: 123456789
event: RISING EDGE timestamp: 123456790
If it immediately errors out (e.g., “Operation not permitted” or “Failed to request event”), then the kernel is blocking edge detection on that pin.
✅ How to test
Make sure you have something connected to GPIO17 that can change state (button, jumper wire).
If the pin is floating, enable a pull-up/down first:
bash
gpio -g mode 17 up
or
bash
gpio -g mode 17 down
Trigger the pin by connecting it to ground or 3.3V depending on your setup. Watch for events in the terminal.
? Interpreting results
Events appear → The kernel and hardware are fine. PyPilot HAT’s failure is due to its GPIO library (likely RPi.GPIO vs libgpiod mismatch).
No events, but no error → The pin is floating; you need a proper pull-up/down or hardware signal.
Immediate error → Overlay or driver conflict; something in /boot/config.txt may be reserving GPIO17.
