Mote stick problem only on phat

I’ve got two mote sets, one with the usb dock and one with the mote phat.
Exactly one of my 8 rgb mote sticks (bought from Pimoroni GmbH) has a ‘sticky’ red led, but only on the mote phat.
If I run the mote example everything is ok.
If I run the mote-phat example, when pixel 12 on the stick is driven with a red value it seems to stick until power is removed. Clearing all channels (and show) leaves just this red led lit. Driving that pixel only with green or blue values works as expected (
If I swap the sticks around the problem moves with the physical stick, the same red led on the same pixel on the swapped stick goes ‘sticky’ and only goes off when the stick is disconnected or powered off.
On the mote dock (no power boost, just usb) with exactly the same 4 sticks in any channel order there is no sticky pixel, everything works perfectly. If I didn’t have a mote phat I wouldn’t have noticed.
I’ve tried the phat on a zero and on a pi 3+ with the same sticky red led problem.
The obvious workaround is to mark the stick as ‘dock only’ but I shouldn’t have to do that.
I suspect that the single apa102 is somehow broken, but why it works on the mote dock is puzzling me.
Is there a rational explanation? Phat power level vs mote dock? Phat driver quirk? Apa102 quirk? Eddies in the space-time continuum?..

Can you get a close look at the die of the apa102s? Do they look subtly different at all? There’s a chance that it’s a last vestige of this problem:

I’ve checked all the dies and, on all the mote strips, they are all the same, the newer, smaller, darker die. I compared them with my Blinkt! and that has the older, larger, greyish die.
I’ve not tried fiddling with the start and end frame timings. I still suspect that the individual pixel is broken or getting stuck from the received data, but it’s rock solid repeatable and doesn’t seem to be random.

This is getting weird. It only gets stuck on if I set a red value more than 127, which implies the data is making it get stuck. Protocol data interpretation wrong?
By the way, I changed the eof code to 32, 42 and back to 36, it made no discernible difference whatsoever. I changed it directly in


Yes, I’m still typing python … rather than python3 …
As an aside, as installed with mote-phat doesn’t set clear on exit to false which means it just flashes the mote sticks briefly and immediately exits and clears the whole lot. That’s also a mystery to me as it’s not new/changed code.
I looked in the github mote-phat repository and seens to have been updated quite a while ago. The one-line installer must still be installing an older version (after all this time).

I have now taken off my quality manager ‘hat’.
Let’s just ignore the fact that one lousy red led in one rgb apa102 doesn’t quite work 100% in all caes. It’s probably about 0.00001% out of tolerance and it works fine with the mote usb dock. (It’s now marked on the back with a red dot)
Instead of looking for problems, let’s just lie back and enjoy all the lovely colours and the very easy setup and programming.
And my infrared re-mote control is working too!!

1 Like

Hey you’re welcome to a replacement if you want one- a fault is a fault and as much as we try to test everything before it goes out I’d wager we’re not perfect :D

The issue regarding and the one-line-installer is a common one actually, I need to find a better solution for examples. The problem is that the OLI installs a specific versioned release of the library, and then grabs the examples for that release (tagged on GitHub as, for example, v0.2.0). If an example has a bug that gets fixed, that fix will go after v0.2.0, and cannot be retrospectively made to an old tag. So the installer will continue to pull down broken code until a new library release is made.

It’s… uh… problematic! But intended to allow us to release new examples alongside new library features without the OLI pulling those down (and them breaking) before the library has actually been released. What a kerfuffle!