pHAT BEAT RGB on 100% randomly on powerup

My pHAT BEAT pivumeter doesn’t work right.
Visually board looks OK, but:
On every boot (after the initial curl https://get.pimoroni.com/phatbeat | bash full install)
random combination of LEDs light up - and stay on, no matter what I try.
Sometimes first tree, sometimes one, seldom none.
Always (what seams to me) at full brightness.
No combination of gpio setting to pins 12, 16 or 18 (or any other I’ve tried) seem to change anything.
They get rather hot after some time obviously.
None of python examples give any effect.
Nothing after python calling phatbeat.set_pixel(params), phatbeat.clear(), phatbeat.show() .
The audio part works as expected, same with buttons (apart from hue-control.py not changing colors obviously).
I’ve checked whether there are short-circuits between header pins, or if there are some lack of connectivity in header connector - all comes out fine (I did reflow on header just to make sure).
I’ve even made simple oscilloscope from my cellphone - using https://f-droid.org/packages/org.billthefarmer.scope/ and mic connections from phone minijack - and there seems to be an digital signal on 16 and 18 pins ( without resistors even - i know- risky ).
Reboot (not cutting power to hat) does not change the random LED configuration, only shutdown and new start.

Is this some weird timing issue? Or just faulty hat?

Hey there,

Curious. The LEDs are controlled by an IC so you won’t have any joy setting gpio pins manually. Do you get any output from rainbow.py that would suggest something is wrong?

Which user are you running the script as? The account will need to be a member of the group gpio to post commands.

It may be worth giving it a go on a clean image of Raspbian to rule out any issues with your current install.

Yeah, i2s (GPIO 12, 16 and 18) is a digital data signal. Its a series of ones and zero’s. Manually setting those pins to a 1 or 0 is likely just going to mess things up.
What model Pi? And what Version of Raspbian are you using?
Anything else connected to the GPIO?

Currently running apt-updated Raspbian 9 from 2019-04-08-raspbian-stretch-lite.img
Standard pi user with gpio, i2c, and spi group membership.
Reinstalled Raspbian couple of times (primarily was running full with X.org, but it was just slowing the reboot iterations of stuff to figure out this problem).
After removing from /etc/asound.conf all pivumeter mentions leaving just the:

ctl.!default {
type hw 
card 0
}

lines, there is no random LEDs light up on start, only after first call of library like rainbow.py.
(or my cutdown version without loop and single call to set_pixel with static params , and show() )
Random lights (last time: three, and with different colors: one yellow and two blue, bright) and no more response afterwards.
I’ve noticed, that if I pull the power plug and power it too fast (say 0.4 second) most but not all LEDs light up very slightly for a very short time.

Original rainbow.py gives me no erros bar the ^C ending the run.
Same with the cut-down one-call version.

No other stuff plugged into GPIO. Just PI Zero W v.1.1 ( 2017 model ) and Phat Beat (and USB hub with kb/mouse and power and HDMI out).

I had a similar issue that just went away and never came back.

Best guess is I had a bad connection somewhere.

I’ve seen that, but all it gives me is hope that it ma by just my sloppy header soldering.
So - i go with the old take the plastic header off, unsolder all of connectors, suck the solder off board, put connectors into header, solder on the wrong side, do it again - routine… ;P
Will noitify if it’ll help.

I have one of the original ones. I do believe there has been one minor hardware revision. I get a couple of pops in my speakers during boot up. My VU meter flashes very briefly with each pop sound. Is that when yours lights up?
Have you tried a new fresh image from scratch, and maybe do it on a different SD card.

Nope, VU never worked from the start.
Resoldering headers did nothing.
Same effect - first attempt to show() sets permanent random values.
Looking around https://github.com/raspberrypi/documentation/tree/master/hardware/raspberrypi/revision-codes
there was only one revision of Zero W - the v1.1 aka 9000c1 (the one I’ve got).
So it’s unlikely that there was some braking version changes.
I’m assuming broken board - will talk to seller about replacement.

The revision was to the pHat Beat. A minor hardware revision, I forget what for now? You would have the newer version. if purchased recently anyway. I bought one of the early ones when they first came out. Working fine, gets regular use too.
On the main Shop page there is a contact us link. You can e-mail tech support directly via that link. I’d put a link to this thread in the e-mail. That should get somebody from Pimoroni here to help sort it out or maybe send you a replacement. It kind of sounds like yours may be defective?

Final update:
Got replacement (took me some time to send it out),
After soldering the headers - only partial success:

  • on boot occasionally some random LED (or three) will start on)
  • pivumeter works great, test.sh, et all,
  • python libraries - not so:
    After running hue-control.py or rainbow.py LEDs are going bezerk.
    Even after BTN_ONOFF in hue-control while most of LEDs went dark, there were some still randomly blinking.
    Even after calling only phatbeat.set_all(0,0,0,0,0) and show().
    No madness after only calling .clear() in script.
    But - this time turning off pivumeter ( cleaning up asound.conf as mentioned in msg 4 above )
    and rebooting - all python example scripts work OK.
    So - it’s the C vs python libraries apparently again.
    Some logic leaks out :P
    I’m leaving it that way:
    Either PIVuMeter, or python stuff, not both at once.
    I can live with that.

Yeah, if you have installed and are using the Pirate Radio, its doing stuff on its own on every boot up.
I have mine playing some classic rock in the background as I type this. =)
One thing you could do is setup two different SD cards. One for tinkering and one for playing tunes. Tailor your installs on each one to a specific task / usage. Then just swap cards to play around with the VU meter.

One more thing:
if I disable puleaudio (sudo service pulseaudio stop )
Both pivumeter and python calls work OK.
Not that it resolves the overall problem ;P