Speaker pHAT - vu meter flashing?

I’ve put together a Speaker pHAT, and while playing around with it, I’ve found the vu meter is behaving oddly.

The alsamixer plugin only has the LEDs work for approximately 1/2 second every 4 seconds or so. Turning the LEDs on manually via a script similar to below shows the same behavior:

for i in range(10):
speakerphat.set_led(i, 255)


https://youtu.be/KX9tLeHRCtk shows the behavior I’m mentioning here - the LEDs should be on, period, not flashing! Changing the LED brightness doesn’t appear to affect the flashing, either.

I’m also noting that pinout.xyz reports i2c address 0x54 used by SN3218 (https://pinout.xyz/pinout/speaker_phat ). Oddly, ‘i2cdetect -y 1’ doesn’t show anything for address 0x54.

Notably, audio appears to work fine on here - it’s just the vu meter LEDs that I’m having trouble with. I’ve tried this pHAT on three different Pis - two different Zero Ws and one Pi 3 - and I’ve seen the same behavior on all of these.


Hi there PinkFreud,
Since you’re having the same issue on so many different Pis, could you just double check your soldering please? It sounds like it could just be a simple problem in the a solder joint somewhere. If you can, could you also post some pictures up of the soldering here?

I can do so later on today, sure.

I tried to get the soldered pins from a few angles.

In addition, I’ve checked pins 2, 3, 5, 12, 35 and 40 with a multimeter, first with a probe connected to a jumper in each pin and the other probe pressed to the soldered pin on the top, and second using a mini black hat hacker. I’ve also checked for solder bridges on all 40 pins, but I don’t see any (on at least one of the pics, it looks like a bridge may be present, but the overhead view shows that’s not the case - it appears that the board coating had bubbled from the heat of the iron).

While I do see a few pins where solder didn’t completely cover the copper pad, I don’t see any continuity problems for those.

Did you use the same SD card across all three Pi’s? This sounds like something else is potentially accessing the sn3218 and changing the LEDs.

I did not - each Pi has its own sd card, with the two Zero Ws having the
most recent install of Raspbian (the Pi 3’s software is a bit dated - I
need to update it). I’ll admit that one of the Zero Ws is using an SD card
cloned from the other W, but that’s why I decided to try the Pi 3 as well.

I initially thought this might be software, but I can’t find anything that
would be causing this interference. Also, there’s the weirdness with the
sn3218 not showing up in an i2cdump, which makes me wonder if the 3218 on
this HAT may be to blame.

Well I can certainly say your soldering job looks fine… Soooo shiny! Those are some really nice shots!

OK, sorry, enough about photography. Since your soldering seems OK and none of the three Pis can detect the sn3218 it would seem like a faulty chip, however, it’s strange that you are getting a flashing of the LEDs rather than them just not functioning at all (which I would expect if your Pi can’t see the 3218 at all). It’s almost as if the signal is getting an intermittent connection…

That’s actually normal, and a common red-herring. Missed your mention of that in an earlier post. The SN3218 is write-only, so it doesn’t respond to the regular check for an i2c-detect. If I remember correctly you must i2cdetect -yq 1 for more aggressive detection.

Thanks! :P I used a macro lens to take those, though my available lighting was terrible. I did wind up using a scroll pHAT hd for lighting in a couple of the shots, though. :)

Yep. This is a weird one. I thought it might be software, too, but my Ws are using a base Raspbian Lite install. This is definitely odd.

Ahh hah! That was unexpected.

… hmmmm.

Also, I’ve found that running sn3218.py directly causes it to run a test pattern on all channels. The same weird flashing behavior presents itself here as well, though I suppose that’s not surprising at this point.

I’ve also tried this trick in bash to see if I could catch the 3218 in i2cdetect:

while [ 1 ]; do diff -u <(i2cdetect -yq 1) <(i2cdetect -yq 1); done

After letting this run for a minute or so, I never saw any output. indicating that i2cdetect, at least, never saw the 3218 appear. My knowledge of i2c is still limited, though, so I’m not sure this isn’t normal.

Ack, sorry for the spam.

I figured out the i2cdetect issue:

I2C: SN3218 – LED controller | Wiring Pi mentions:

If you have a Rev 1 Pi, then the i2cdetect command is: i2cdetect -q -y 0 if you have a Rev. 2 Pi, then use i2cdetect -q -y 1

Sure enough, i2cdetect doesn’t like arg stacking. i2cdetect -yq 1 doesn’t work, whereas i2cdetect -q -y 1 (or -y -q 1) does:

There’s that little issue resolved, at least. It doesn’t look like the 3218 disappears from the i2c bus at all.

I’ve discovered that I have another product which uses the SN3218 - my old PiGlow, which was primarily used on my original pre-HAT-capable Pi B.

Sure enough, the PiGlow works just fine on one of the Zero Ws (I haven’t tried it on the other Pis, but I doubt I’ll need to).

In the pic is the bottom of the Speaker pHAT (one of the bolts for the speaker melted after an unfortunate encounter with my soldering iron while soldering the speaker wire - sigh). There’s no damage to the underside of the board, and the SN3218 on the right is undamaged. At the top of the pic is the (working!) PiGlow.

I think everything is pointing to a problem with this particular speaker pHAT.

How do we proceed from here?

Unless Gadgetoid suggests anything else, I’d pop an email to support@pimoroni.com requesting a replacement unit. Hopefully a little testing at Pimoroni HQ will find the problem.

We’ll have to see if they want to go that route - I’m on the wrong side of the pond, alas (I picked up the speaker pHAT from Adafruit over here).

Thanks for your help, RaspberryPicardBox and gadgetoid!

Ah, I see. I’m unsure of re-seller policy stuffs, but I’m sure Gadgetoid will help when he has a minute.
No problem. :)

I’m sure we’d be happy to replace it. Just reference this thread in your email, and pop your full address in so we know where to ship it and stick “Phil says replace it 'cos we’re nice” somewhere in there.

Hah, thanks! I’ve already talked with support, and they’ll be sending me a new one. :)