SOLVED: Glitchy RGB blinking instead of patterns

Troubleshooting
1

Longtime Pixelblazer, first time caller. :slight_smile:

The problem: Instead of playing selected patterns, my lights are sparkling red, green and blue. It doesn’t matter what pattern I pick - they only sparkle RGB.

This is a new outdoor install of 480 WS2812B strip lights driven by a Pixelblaze v2. Everything is powered by a 5V 60A power supply with power injection every ~5m. The PB is backfed 5V directly from the power supply. The lights are supplied 5V from a separate rail - the only connection between PB and lights is the data line. There’s about 20’ of 18AWG cabling between the PB and LED strips. Measuring the power supply output with a multimeter shows 5V. The setting for number of lights is respected, so if I tell it there are 200 lights, only 200 sparkle. The brightness slider does not seem to be respected, and the blinking is quite bright and uniform along the entire chain.

I tested the PB + lights with a battery before running the long cabling, and they worked fine. What’s changed between then and now: ran 20’ of cabling between PB and lights, switched PB from AP mode to my Wifi, and upgraded PB from 2.21 to 2.23.

Any ideas?

2

You should have a common ground I believe. I suspect the data line voltage is just enough off to trigger the lights but not pass correct data.

I don’t claim to be an electrical expert. Consult Quindor (source of great led info) and Ben and other folks to confirm.

1 Like
3

I’ve definitely seen ground errors before. One thing I did to quick fix was to reduce the power draw of the lights. Maybe make a pattern with a very small number of active lights and see if that works correctly.

4

I had a similar problem before switching to use the pro expander board, which solved it… I think there are some resistors or capacitors off the data line that help with signal weirdness.

You can find a video I made which shows the problem I experienced here: https://youtu.be/jgM8WfJmEX8

5

Try adjusting the data speed timing in settings. Sometimes this can help by increasing the margin between bit signals.

The data signal is always in reference to GND, so PB and the LEDs need to have a GND in common.

It’s likely that GND is tied together at the power supply, and it sounds like the distance from PB to the power supply is small enough that your LEDs GND power line is effectively a reference GND for the data line as well. However if PB is also far away, thats additional difference between GND and data!

In general, it’s best to run ground with data to minimize any potential differences, especially over tens of feet.

If possible, a shielded cable or twisted pair will be better than a single wire. That 20 ft of wire is basically an antenna! Whats happening is that external signals are getting picked up by the wire, and turning zeros into ones, or ones into zeros.

Shielded cable can help by soaking those signals to the GND shield, preventing them from interfering with the data line. Twisted pair where one is GND (connected at both ends) and the other is data ensures that any interference is also induced to the GND signal as well, and since the data signal is interpreted in reference to GND there’s less chance of misinterpretation.

For extremely long runs, a differential signal is required (a twisted pair of data lines that are inverted mirrors of each other), and these can be further improved with isolation. For this, a transceiver is required to convert the signals at both ends. I think you should be able to get 20ft without this though.

BTW thats the kind of thing Ethernet does to get 100 meter ranges with fast speeds over twisted pair.

2 Likes
6

Update: I just shortened the data line by 2’, which fixed the problem.

I also believe the GNDs are tied together at the power supply, which is why I wired it like that. But I will explicitly tie the PB and LED GNDs together as I expand on the system.

This is all extremely helpful information, @wizard. Thank you for the detailed response!

3 Likes