So I can now confirm these DO have some sort of “memory” for their location. I cut off 10 from the end of a strip of 200, and cleaned the ends (lighter to burn off lacquer coating on wire, use sandpaper so you see shiny metal), soldered to a connector, and hooked up.
With a single normal pixel first (which wasn’t RGB, it was GBR, but…), these still insisted on being 192-200(I couldn’t get the last pixel to light correctly, even telling PB I had 205+ pixels. Either it was off or it would do just red).
With NO pixel in front, these behaved perfectly… told it 200 pixels, and it was 191-200.
First Y works… Independent lights despite the Y of data and power. Wow. Photos soon. But seeing this blows my mind. It’s a whole new ballgame for led wiring addressables.
@wizard’s volumetric cube was done with a pile of expansion boards to ensure each strand didn’t need to run a data line back up to the next… This removes the need for all of that. A single expansion board could drive up to 8x200 (1600! Or more than enough for a 11x11x11 cube!) Lets keep it simple and say 10x10x10… 1000 pixels.
Connect data and power for 15-20 strands of 10 pixels, all soldered together at one end, just 3 wires to many. Layout and map it all, and done.
@Scruffynerf
Interesting! Have those close up photos?
What happens when you combine 2 independent strings of 200? Is the data line electrically connected throughout, as a bus, or chained like regular WS2812?
The author of the GitHub issue above just posted when he combined two full long strings (I’ll assume serially, but I’d assume the same for a data fork as well) that they repeated. He’s got two strings of 100, and they didn’t become a string of 200, they remained 0-99, 0,99 (so they’d repeat)
The justifiable enthusiasm for how this simplifies our serial wiring constraints makes me wonder if anyone’s ever made a cheap WS2812/APA102 digital “delay line” (address offset) so we could have the same flexibility on existing products.
Imagine a small chip that just drops the fist N values after a reset frame, then starts shifting out the subsequent values. You could configure how many positions to drop with a small DIP switch.
Niche market for sure, but could save many awkward wiring moments such as the ones everyone encounters in their internal polyhedra builds.
@jeff,
I’ve heard of folks making those, from the Hackaday.io LED chat.
It was a while ago, and the scroll-back of the HaD chat is super bad. You might have luck posting a question about it there and hope someone remembers more than me
I’ve given it some thought too (for routing and/or protocol translation). Might be a way to make them economically with those $0.03 micros if they don’t have to do too much protocol work. I have the dev kit, but haven’t had the time to experiment much.
One of the ideas floated was that it could consume pixel data for config. So e.g. if you install it at the 100th pixel, that pixel data is really 3 bytes (or any really) of data it will consume for it’s own config before routing data elsewhere.
Being able to add that functionality to existing products would be really awesome, even if it means adding in another piece into your string. Built-in would be best, but it looks like with higher qty pixels that “spooky action” quits with that mystery chip. “Self-Addressable” leds… that would be sweet.
I’m one of the people @wizard mentioned from the Hackaday.io LED Art Chat working on LED strip “router” chips. (I’m not sure what to call these yet, I used “splitter” first but maybe “router” is more accurate.) I’m still in the idea phase, and haven’t prototyped my ideas yet. The other person in the chat has a working design, but it requires custom controller firmware. I want my design to work with any WS2812 controller as is, particularly with Pixelblaze.
I have a project in mind that really needs these router chips, maybe more than one type. I have a cheap waist-high white fake Christmas tree with 80 branches, and I want to put a LED strip on each branch, without looping the strips back on each other. I’m casually starting now, but I’m not sure if this is a Christmas 2020 or Christmas 2021 project
Right now I’m prototyping with ATtiny parts, but the goal is to move to the 3-cent micros if the project takes off.
With these hardcoded ones, easy enough to do, you probably would want 2-4 strands, since the 200 limit would be the blocker. So cost ~$50-100… (Figuring $25 per 200)
With normal pixels, you’d need 80+ “splitters”, each configured uniquely. Plus 400-800 pixels. That seems like way more work. But I look forward to seeing it!
I’m in favor of some tiny microchip that can “route” pixel data, many if it optionally has a pixel on it, so you can easily camouflage it into the mix
The tree has from 4-13 LEDs per branch (assuming 60 LEDs/m). There’s enough branches to hold almost 14m of strip. Just over 1000 LEDs.
The project is a test case for my “splitter” (I still like that name over “router”) ideas more than just wanting a lit up tree. I’m planning to use normal pixels for this project, though I am interested in these new bussed strings maybe for other projects. Each splitter could support more than one branch, I’m considering supporting up to 16 strands. I want to minimize the burden of configuration, so I’m keeping that in mind.
I don’t want to sidetrack the conversation on the bussed strands, but we could continue in a new thread if you want. I’ll post any major updates on the splitters or the tree project in this forum, as I’ll be using Pixelblaze.
wait we can use a PB for controlling RGBW strips? Did I know that?! LOL I just went into the PB gui and sure enough under color order it has options for RGBWs… Niiiiiiice. I’ve been wanting to get some to play with but FastLED doesn’t do it without a hacky hack… this should be cool.
The first link she provides is what I refer to as 3.5 wire ws2812#… They alternate a middle wire. The second link is the ones we’re talking about here. Look closely before you buy.
@Scruffynerf, have you had much chance to play with these things? I’ve been running 2 strands on my Christmas tree. 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, timing matters, which is why I started this thread with that title. We learned only after that of the weird behavior.
I suspect it’s due to the way they read data. And that they do NOT regenerate data like ws2812s. So misformed or slightly off data doesn’t have a chance to be cleaned up by a pixel passing it on.
Consider it another trade-off for using these. Like all choices, some good some bad come from the design.
That makes sense. Especially since they’re not retransmitting the data. I was kinda wondering about voltage drop and signal degradation over that 60 feet of very thin wire, particularly since whites and brighter colors seem to cause problems more often. Totally a compromise I can live with – these things really are ideal as Christmas lights, and my wife is happier if the tree does calm, relaxing things anyway.
It is entirely possible these are reprogrammable still, but nobody knows the secret password (or technique) to unlock it. I really doubt the preprogram these at the chip layer, for mass production.
