Timing of a Cheap Strand v 2

Back in late 2020 this discussion ensued here. The discussion was in relation to these rather unique 2812ish LEDs.

As @zranger1 posted in the above-referenced discussion, "They’re beautiful and generally work well, but I’ve had a bit of weird behavior – like they occasionally drop data when changing values rapidly – was just wondering what other people have seen.

(I played with the timing a lot – my best results are with dataSpeed:3200000 )"

I agree, they are beautiful. And for my purposes the durability of better wire and lack of exposed wire ends when compared with the alternative just might seal the deal. However, when controlled with a PB v3 I get super glitchy behavior.

Much of the discussion noted above is about timing settings as controlled in the UI. I am running v3s which do not appear to allow changing of timing. Am I missing something?

Is there a way to do custom timing with the V3?

And incidentally, has anyone had good luck running these with the PB v3?

Final note Re Voltage Drop - Since these LED systems are extremely sensitive to voltage, I measured the voltage an the source power supply and between the last two pixels in the 200 pixel string, running all white -

Source Voltage is 5.0 volts
End of String Voltage is 3.19 volts

Perhaps injecting some voltage at the end of the string would stabilize things to some degree.

I used a Pixelblaze3 to drive two strands of these guys on my Christmas tree last year via a y-cable for data (no expansion board). The PB3 worked really nicely for a single strand, with no noticeable timing problems. But the voltage did drop off pretty quickly - in particular, patterns with a lot of white really got weird towards the end of the strand. And the y-cable driving the second strand actually didn’t work that well for anything but fairly static saturated (i.e. low power) holiday colors. Still, it made a nice tree.

This year I was already planning to, as you suggest, inject power at the end of the strands, and drive the strips with an expansion board. I’ll get the strands out of the holiday box early, and see if I can get the setup working.

I went ahead and ran a string of these, all 200 of them, in a 1 meter cube frame. A v3 PB with output expander was employed. 5v was injected at the near string end. Itried to figure out the color sequence. Seemed to be GBR but then…

Anyway, the KITT pattern runs all “nervous” and there is pronounced color shifting showing for the first 20 pixels or so, plus some scattered individual rainbow coloring.

See the following video, please.

A super simple “all blue” steady pattern comes up rainbow and twitchy.

I tested the rig by swapping out the string in question for a string of another brand, the latter ran just fine.|

So far, I must conclude that these are not the best choice for PB control.

Perhaps we’ll have to make our own strings. Anybody ever done solder re-flow or anything like that? :grin:

Anyway @zranger1 I’d be interested to see if you or anyone else could make some (good!) trouble with this, if you can.

They still work perfectly if driven by just a Pixelblaze 3, no expander. A screenshot of my setup is below. I’m guessing that the expansion board’s timing differs from the PB3, but I don’t have an expansion board I can test with right now. @JustPete, can you test w/my setup and the expansion board and see if it’s still glitchy?

If so, maybe we can ask @wizard for the easiest way to change timing in the firmware to match the PB3 default – I looked, but I’m an STM novice, and there are a lot of timer interactions in there, and lots of different ways to change frequency.)

(the copper wire is VIN, the center wire is GND, the other outside wire is DAT. Pixels are RGB – a rare event!)

You really cant drive these at 100% brightness, and they do use thin wire that will Vdrop faster than other types. I would hope that with power injection things would work out though.

If you adjust brightness while this is happening, does it change behavior? Do you get less glitching with lower brightness levels? Does the pattern make a lot of difference?

How much extra wire (length) do you have from the PB/Expander to the string?

Which output expander are you using? I had made some changes to timing on those over versions. Earlier versions had timing that would sometimes not work 100% right with some LEDs.

Of course variable timing can help overcome problems, but only PB V2 does that currently. It’s harder to do with the driver I’m using on the V3, though I do have more variables I can adjust. The Expanders aren’t adjustable without reflashing new firmware. I had hoped to implement that in firmware, and there is support in the protocol.

Try adding a 500ohm resistor at the end of the string from the data line to GND. Add a 100uF (or whatever you have handy) capacitor on the start and end power. Does that change anything? If I get a free moment, I’ll run similar experiments here, as I have a bunch of these LEDs handy (but lots of projects).

1 Like

Measured voltage drop for the 200 LED string = 5.0 V source drops to 3.19V.

Hence, I am injecting 5V at string end. Injection did not seem to affect the glitchy behavior at all.

The native string without the expansion board runs great on all patterns tried with @zranger1’s settings.

Limiting brightness does not affect things.

I have added less than 1 ft of wire to accommodate the output expander.

So I am figuring added wire is not a problem.

The Expander version I am running is 2.0, vintage 2019. (I have a handful!)

I’d do the things with resistors and capacitors but do not have such in hand at present.

Seems we are in the details alright. But, I am sure we will figure something out! :grinning:

My expanders are of similar vintage. I just ordered a new one though, and I totally don’t mind building and experimentally flashing an older one if necessary. I’ve already got tools and environment set up to work on the sensor board code (working on adding beat detection). The output expander hopefully wouldn’t be a huge leap from there.

1 Like

That would be great if you can do that. Kudos. I’ve got like 8 of those expanders, of the same vintage. If they can prove useful for running these LEDs, so much the better.

Thanks to both of you respondents @wizard and @zranger1, great to be checking out this as potentially viable control for these oddball LEDs. Awesome!

I’ll give it a go. It may take a while - even if I only wind up changing one number, it’s going to take some time to understand the code well enough so I get the right number.

That;s just super fine @zranger1 . It will be interesting to see what we find.

If I need to update to newer expansion boards, well so be it. Just to make it work… that would be great.

On checking it out, these LEDs work really well with the 2021 Pixelblaze Output Expander.

My test setup- of five strings of 200 LEDs, each string running on its own channel works just fine. That’s as far as I have tested to this point. This is a very good result!

I will note that there is significant light intensity droop as one goes down the string with these LEDs and this has nothing to do with Pixelblaze

Footcandles measured directly off the LED with steady-on
hsv = (0.1,1.0,0.75)
h being set to near the max spectral sensitivity of my meter @ around 560 nm

246 fc at beginning of string
65 fc at end of string
158 fc if ground only added at px # 199
222 fc if 5v+ and ground added at px 199

I am not sure that the reduction in light intensity is all that noticeable under dynamic conditions.

BrizLabs sells a 100 pixel string of these weird LEDs. I have not measured brightness WRT string length but know they have reduced the wire diameter to 0 0.016" from the 0.019" wire present in the 200 px strings.

Anyway, Pixelblaxe Output Expanders work great with these 'weird" LEDs.


I read somewhere that these works really well on 3.3v as opposed to 5v.

That’s an interesting option to look into. I would have thought the voltage at string end would be insufficient but its worth a look see.