pixelblaze with pro extension board configured for 12V with built in voltage regulator
extension board is connected to PB via 4 wires which I matched in order
PB powers up and I can talk to it fine via wifi
Expansion board status light is on (orange) and it’s making proper 5V for the PB as well as routing the 12V input (which I verified to be proper 12V) to the output pins.
If I use the PB standalone with a 5V neopixel strip, it works
my 12V neopixel strips work fine standalone with a controller
But nothing lights up when I use the expansion board.
They light up randomly if I unplug the data pin and put noise into that, so the power connection is good, too, they just aren’t getting any signal, or not a signal they can read
Board address jumpers were left to 0, and PB is also set to 0
So, how do I debug from there?
How do I know the expansion board is getting the right signal?
How can I debug the expansion board outputting data, or not outputting because it’s not receiving anything (to find if the data output is bad, or no data is output). I mean, yes, logic analyser, but I don’t have one.
Is there any status at all on the expansion board to know what it’s doing or not doing?
Front and back, wires are connected one to one in the same order:
I’m also confused that apparently the expander protocol doesn’t use the clock, and yet there is a clock input pin. Why is it there if it’s not used? Either way, I wired all 4 wires.
If I unplug the LED strip data pins from the board, random noise on the data pins cause LEDs to light up, so they are getting power:
So the board ships with the wrong address by default (7) with all the switches on OFF, which any reasonable person would consider to mean 0, but indeed, the bits are reversed, they are so reversed that the boards are being shipped with the wrong address by default (they are supposed to ship with 0, not 7, I assume).
So I moved all 3 address switches to ‘1’ and now the address is 0 instead of 7 and things work.
Were the switches swapped from the wrong one (NO vs NC or somesuch)?
That’s odd. Thanks for bringing the answer back here.
Hey one other thing I saw in your config screenshot - did you happen to notice in the product description that there’s a limit of 600 or 800 pixels per channel (depending on pixel type)?
I saw you had 1000 per channel so I just wanted to make sure you weren’t planning or reliant on running 1000 per…
About chain length, yeah I know that refresh rate goes way down if you have 1k pixels on a chain for neopixels, but for now I was just trying to get something, anything to light up and indeed due to the address switch issue, nothing was.
For what it’s worth, It is actually working perfectly with 1k pixel per chain on 2 chains, the patterns migrate nicely from the first chain to the 2nd, but by the time I install it, I’ll likely segment further.
That said, while I have you, 3 questions
any idea why there is a less than 1k limit per chain outside of obvious refresh rate issues? Is there some array that will overflow? More generally shouldn’t the UI tell me not to do this like it catches other errors currently?
do I somehow have a bad board/bad build? Are the other ones supposed to have an address of 0 with the 3 switches set to 0 or 1?
I’m still confused about the clock line on input. Why is there a clock line if it’s not being used in the port expander protocol?
These are good questions, and ones that @wizard can answer more definitively. Here are my informed guesses.
First, I’m surprised it’s working with all 1000 LEDs per channel - a year ago I was reminded of this limit the hard way when I forgot about it and had wired a piece with more than this. Hmmm.
As for why the limit, my guess is it has to do with a buffer size or MCU processing speed on the expander, not the frame rate issues. The firmware for the expander is open source on GitHub - you could take a look and even flash your own, though not sure if Pixelblaze would support it in the expander protocol on the sending side. I agree a UI warning would be useful.
Regarding getting it shipped to you with the DIP switches in an unexpected position, I agree this is a confusing experience, but I also suspect that because Pixelblaze manufacturing is a small batch / small team process, this was just unintentional. It might even have been that they came from the manufacturer that way, many were in a sensible default position and thus checking their position after installation and before shipping is not on a QA checklist. Certainly the Pixelblaze philosophy is to either document stuff like this or have a smooth setup experience.
My guess is the clock line is there to just allow people to connect it and do no harm. Certainly in my first few months with LEDs I might have been confused by its absence on an expander, like - is this really unneeded? When is it unneeded?
thanks for your answers. I agree that at some point there is some array size limit, my suggestion for now is to make the web UI limit the chain to whatever the limit in the expander is. Maybe it already does and the limit has been raised to something I didn’t try
Clock line input on the expander board, I was thinking about it more, and maybe it is to allow for some future (faster) protocol that would require a clock line while the current one does not, so it’s ignored.
Either way,
One thing I didn’t find in the docs: if some effects are “too fast”, is there a way to make a playlist and give a speed factor to them, or not so much and the code for each needs to be edited accordingly?
The channel pixel limits are mostly due to the memory limits of the microcontroller. The MCU has changed between expander versions, and limits have increased each time.
The v1 expander could handle 240 RGB / 180 RGBW pixels per channel.
V2 could handle 800/600 V3 can handle 1600/1200. ← this is what you have. Practically, there are few reasons to ever go this high.
APA102/SK9822 uses 4 bytes as well, so has the same pixel limits as RGBW.
The UI will now let you put in anything you want for pixel count for each channel, and Pixelblaze will send that out, BUT the expanders will discard/ignore frames that are too large for it to store. The UI used to validate this in older versions, but since there are 3 variants of expanders, which can otherwise be mixed/matched, I took out the limit instead of making the validation super complicated.
The pro expanders should ship with a default address of 0. Looks like we missed that, sorry for the headache! The board isn’t “bad” per se, just had the toggle switches set wrong.
Kinda. The non-pro expander uses cuttable jumpers, so you’d cut trace(s) to change the address. The pro expander uses DIP switches, but the electrical connection is the same. I haven’t found DIP switches with a matching labeling (with a connection being a zero). The configuration table showing switch positions is in the docs:
The clock signal on the expander input is reserved for future use, but is not currently used. It is wired to the MCU on the expander but the firmware both sides currently do not use it. All 4 connections are also present so that the boards can be stacked (more for the small expander, but the pro has the same connection footprint).
Thanks for all the feedback / questions. It’s good to see where people get tripped up so we can improve things in the future.
This doesn’t exist currently - I end up making a reusable chunk of code that makes a “Speed” UI control and copy-pasta that into every pattern. It’s not great, and Wizard is aware of this as a previous feature request (a global speed slider that could scale time() - but then do you scale delta as well? Or do you make a new API like ramp() or scaledTime() that accepts the global speed?).
It’s pretty tricky to do, but tis the season for me and 8 Pixelblazes out on the house, so I always lust for an extremely basic bit of “global code” / shared functions without having to solve the entire module issue. Even just a block in Settings that is always a dumb text-based prepend to every pattern.
Even this isn’t really straightforward. Since patterns are stored on-device as compiled bytecode, you’d have to either recompile every pattern in a painful background task that starts to not feel atomic, or force the user to recompile every pattern manually and wonder why the global code update didn’t work until then. If a change to the global code block causes a pattern to be invalid and not work - this isn’t really a state that can exist in Pixelblaze right now. So I get it why this is a hard one to crack open.
Thanks for the multiple answers, @wizard
So, several things in this thread, some are buried in the docs, but none are that obvious when you open the box with the hardware, I think would be helpful to put on a small card that ships with each expander.
Namely:
Don’t exceed X pixels per channel
DIP switch ‘on’ means 0, so address 0 is ON ON ON (hopefully most customers understand binary numbers, but knowing it’s inverted, is useful)
Clock wire is not needed, you only need to connect 3 wires
For the pro board, if you change fuses, please do not exceed more than XX amps on the power rail, or you risk melting PCB traces
Or I guess simply the card with a QR code of the URL with the above text (some README first)
And yes, good call to add clock in case you want it for future use, that was my eventual guess, above.
Also, as per feedback on the FB thread, while I originally thought the pro expander was a bit expensive, I also liked what it offered, that it would save me time to do all those things myself, and therefore was worth the money.
The one thing though is you’re missing a waterproof (also playa-proof) enclosure in your store, which I’m going to assume at least half the buyers would want/need. Also maybe offer a waterproof box for the PB given that it may need to be in a different location than the expander for radio reasons (I had to move mine or it wouldn’t see my wifi)
Thanks for your thoughts on the speed UI thing. Do you have your little hack posted somewhere? Don’t laugh, I wrote around 10k LOC for my own PB-ish ESP32 animation controller with wifi support (hence my earlier suggestion/idea of wifi doing client first and then falling back to AP automatically if the client does not connect), but that’s all C++ and I still have to learn javascript
I realize that if some global speed and maybe a per anim speed control, was not part of the original API, it’s a fair amount harder to add it now, but indeed trying some of the effects on my house, some are super fast and will cause seizures to my neighbours
Since you have yours outdoors, may I ask what you use as waterproof enclosures for both PB and expander board? (mine are under the roof, but sideways rain is a thing and they could get wet in a really bad storm)
