As I can now start one of your Blinkt! examples, namely larson_hue.py, still none of the LEDs go on. After giving my logic analyzer a try, I found out that there is apparently no clock signal at all at pin #18 (red probe), yet some data are being sent over pin #16 (green probe):
A test of the GPIO pins with gpiotest (from the pigpio package) says that all GPIOs are OK. dmesg does not show any GPIO-related messages.
What’s wrong here (with the Pi maybe)?
What model Pi? If it’s a Pi Zero, did you solder the header on?
Virtual Environment setup?
Pi Zero without 2 or W. Bookworm without VM. I used the hammer header Pimoroni sells.
Do you get a clock signal if you measure from the solder pad on the Pi?
Already done that. Shall I remove the Blinkt and measure for a second time?
OK, I wasn’t sure if you measured from the Solder Pad or the Pin? Do you have another Pi to try the Blinkt on?
I just went and hunted my Blinkt up, and a Pi Zero. I’m going to flash Bookworm to and SD Card and see what I get on the Blinkt.
The hammer headers are not reliable. My own experience. I really like the idea, but it just turns out that they are often the cause of the problem. I never used them again once I wasted a few hours trying to find out what is going wrong.
Yeah, I’d be checking if the signal is getting from the solder pad to the GPIO pin. Just booted up my Pi Zero, and going through the first time run setup.
All good here. I installed the latest Bookworm 32 bit.
Then disabled the virtual environment. sudo rm -rf /usr/lib/python3.11/EXTERNALLY-MANAGED
Then did the full install, curl https://get.pimoroni.com/blinkt | bash
And ran the cpu load example, and got the blinky lights.
So does that mean it’s the Python venv, which interferes with the code addressing the GPIO pins?
You said you weren’t using a virtual environment?
I think you may have a bad connection on that hammer header pin. Or that GPIO Pin output is not working. I’d run some code to put that Pin high, time.sleep then low etc. And put your logic analyzer on it.
Originally yes, but Python refused to start when outside of a venv.
I used a multimeter to measure conductivity on pin #18 (between the solder eye on the Pi’s PCB and the header pin), and the test was positive. But: A lowlevel test of the GPIO pins in question proved that #16 (GPIO23; data) worked, whereas #18 (GPIO24; clock) did not. Here are the commands I used:
mixtile@pizero:~ $ sudo pigpiod
mixtile@pizero:~ $ pigs modes 23 w
mixtile@pizero:~ $ pigs modes 24 w
mixtile@pizero:~ $ pigs w 23 1
mixtile@pizero:~ $ pigs w 24 1
Does this mean that my Pi is faulty?
I think so, yes. Looks like the Pi has a fault.
I tried a last thing: I soldered pin #18 to get better electric contact, but no use: #18 always stays low. So I’ll have to file my Pi for RMA, right?
Looks that way, bummer, but it happens from time to time.