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
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.
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).
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.
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.