I purchased a Eurorack modular case from Needham Woodworks, which included a lighting system controlled by a Pixelblaze V3 Standard - WiFi LED Controller XL. The system has two LED strips (about 112 LEDs each) powered in series from one end using a 5V 8A power supply.
Initially, I noticed red shifting on the farthest strip at full brightness—it would turn orange for some colors. To mitigate this, I kept the brightness low. Eventually, the far strip started flickering, then both strips shut off completely and wouldn’t turn back on.
I replaced the controller and upgraded to a 20A power supply, which restored function but revealed damage—over half the LEDs on the far strip were dead, and some were stuck on white. To fix this, I ordered new SK9822 strips from Electromage and reconfigured the wiring to inject power at both ends of each strip.
However, when powering on, the new strips wouldn’t light up. If I touched the data and clock lines, a few LEDs at the far end would turn on. Trying a 15A power supply had a similar result, though in this case, touching the wires once made the entire strip light up white, with some flickering when tapping the data and clock lines. Adjusting the controller settings didn’t help.
One concern I have is that the controller is powered via the LED power lines rather than directly from the power supply. Could this be causing the issue? What might I be doing wrong, and how can I get the system working properly?
It definitely sounds like you know what you’re doing, and good call making sure that there’s power injection on both ends and ensuring that your power supply can supply enough current.
Did you confirm with Needham that these are in fact, SK9822 LEDs that it shipped with? Because if so, I’d double check the data and clock aren’t reversed. It’s also possible they may have shipped it with three wire LEDs instead, and in that case, I would expect that your pixelblaze has the wrong type of LED selected in the settings page. But it sounds like you checked that. Changes when you give it static from touching the lines is probably a good sign (if also playing a tiny Russian roulette with potential static discharge).
In this situation, powering the controller from the LED strip rails is probably OK, but you wanna make sure with a voltmeter that you are in fact seeing a full 5 V at the controller. The scenario I’d be more concerned with, which it doesn’t sound like is your situation, is when people try to only power a strip from the far data-out side, and are not powering the strip with good power injection close to where the Pixelblaze controller taps off it’s 5 V to operate. Since the Pixelblaze only needs about 200 mA, you can use relatively small wires to get it power.
I measured 5.37V when the LEDs are off and 3.68V when they are on with the 15A power supply. Since they mostly light up full white in this state, it’s clear that voltage drop is a major issue.
I also tried swapping the data and clock lines, but that didn’t make a difference.
To clarify, Needham’s original LEDs weren’t SK9822s but a cheaper alternative. I figured swapping them for SK9822s from Electromage would work without extra adjustments, but something is clearly off.
Regarding touching the data and clock lines, it’s likely a signal issue rather than static—maybe weak data voltage or noise affecting stability. I’ll look into a logic level shifter, but if you have any other ideas, I’d appreciate the input.
It sounds like there isn’t a solid connection from the PB to the clock and data lines. If touching them while connected does anything at all, the LED data+clock input lines are floating, and Pixelblaze never floats it’s outputs. They are either high or low and would be stronger than small voltages injected while touching (unless you have a static buildup of course).
3.68V is definitely low if measured at the start of the LED strip, and you are seeing voltage drop either from wiring resistance or the power supply can’t keep up. Since it’s rated for 15A, my guess is wire resistance. That woudn’t account for not having any patterns show up on the LEDs unless the PB is resetting because of it, but that doesn’t sound like the case.
Signal lines are affected by touching them? This is symptomatic of a situation where the grounds of the PB and the LED strip are not connected together. Just a hunch.
Thanks a lot for all the great suggestions. Using an oscilloscope, I confirmed that Pixelblaze is outputting strong Data and Clock signals when disconnected from the LED strips. When I connect a strip, I still see strong signals at the Pixelblaze output, but when I measure at the far end of the strip, there is no signal at all. I tested this on both new LED strips, and neither one is receiving data properly.
To rule out common issues, I cleaned up the wiring between Pixelblaze and the LED strips, removing an unnecessary Wago lever connector, ensuring solid connections. This actually boosted the power a bit for the controller, but not by much. In any case it reduces variables. Pixelblaze remains stable and does not reset during operation, confirming that power delivery is not an issue. Given that an original LED strip still functions, it suggests that the controller is working correctly and that the problem lies with the new LED strips themselves. It could be faulty LEDs preventing data from passing through, or an issue with internal traces in the flex PCB.
To further diagnose it, I’ve ordered additional LED reels from ElectroMage to test them in three stages. First, out of the box before unspooling to see if they work correctly. Then, I’ll cut them to size and test again to confirm that data is maintained after cutting. Then I’ll install them in the LED channel and check if the mounting process affects functionality. If anyone has experienced similar issues with LED strips or has more suggestions, I’d appreciate any insights. I’ll drop a message here I’ve tested the new reels!
This 100% sounds like a wiring/connector issue. Double check for continuity, shorts, etc. If the LED strip was damaged and somehow shorting the data signals to GND or something, the driver on the PB side shouldn’t be able to pull signal high close to the controller. There’s at least 100 ohms at the output, and that should be much higher than your wire resistance, so a short at the far end should keep the whole signal low.
How far away from the controller are the strips? Is there a length of unshielded four conductor wiring running anywhere near the operating electronics in the case?
Just asking, because I’ve had really weird issues with SK9822 strips that I installed remotely from the controller, approximately 6 feet of twisted pair ethernet cable that I happened to have, and when I located the controller closer to the strips, all the issues went away!
Good luck! Let us know what you find.
Thanks for the suggestions. I ran an additional test after receiving new reels of LEDs. I tested them directly on the workbench before unspooling or cutting and found that they behave exactly the same as the previously installed strips. This suggests that the issue is not related to wiring, connectors, or power distribution introduced during installation, since the new strips fail in the same way before any modifications. This is also a brand new controller and I had it communicating properly with a section of one of my old strips that didn’t burn out. So I’m stumped. Is it certain this could not be a bad batch of LED strips?
I initially suspected a wiring issue as well, so I double-checked all connections and ensured continuity between PB and the LED strip inputs. If the strip was internally shorting Data/Clock to GND, I would expect to see signal suppression even at the Pixelblaze output, but I still see clean waveforms there. This sort of suggests that the signal is being lost somewhere within the LED strip itself. The PB controller is mounted pretty close to the LED strips - there’s a 1 foot cable supplied by Needham Woodworks so that the controller can be mounted on the back of the modular case. I’ve soldered the wires directly to it.
No, that was the original issue when I was using the 8A power supply with only one power injection point at the start of both strips. After upgrading to higher-rated power supplies, injecting power at both ends of each strip, and replacing the Pixelblaze, the new issue is that Pixelblaze is no longer communicating with the LEDs
Ah ok, I’d double check clock and data - the ElectroMage SK9822 strips swap clock and data at the connector, and we include an inline JST adapter to swap em back, and wondering if that could be causing it.
It looks like you have the Pixelblaze connected to the output side of the LEDs. When you touch the wires and they light up, that side is the input side, and you are feeding random noise into the data + clock, causing it to draw incrementally from that end. If you look at the strip itself, you should be able to see a small arrow that indicates the data direction.
The LEDs should have come with the appropriate connector wire (JST female). Let me know if that was missing, I can get that do you ASAP.
I’m sorry this gave you so much trouble! Unfortunately the connectors aren’t standardized, and I think you might have started with the old LED system’s connectors which appear to be opposite of what our LED strips use.
That’s it! I had originally followed the wiring gender from the old Needham setup, which led me to connect Pixelblaze to the wrong side of the LED strip. After swapping the adapter for the opposite gender and connecting to the correct input side, everything started working properly. Thanks for your patience and help in diagnosing this!