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.
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.
How many leds on each branch?
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.
So one of the people I asked about these interesting new LEDs is “Tim” aka cpldcpu …
He’s still working toward writing his findings up but he hints at it coming next, in this informative post on LED timings, which is loaded in details.
There’s a Twitter thread with a couple Aliexpress links to these LEDs - useful for me and others that don’t have easy access to Amazon US:
Aliexpress link here:
Demo verifying these LEDs keep their addresses:
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
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.
Looks like Tim isn’t going to write a full blog post, but he posted his findings:
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.
This is the first lead I’ve got with respect to these LEDS. I’m sssssssoooooooooo happy!
Even more so to see this:
@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
This is exactly what I’m attempting to do, by which I mean what I want to do . I had in mind a 16x16x16, but really the dimensions are not the most important thing.
I’ve built a 8x8x8 cube (binary state) - (I mean, who hasn’t , right? and I’ve had some fun programming animation patterns - My next aim was to make a hanging cube from these sort of lights.
The notion of doing it with regular WS2812s or similar is quite daunting - driving 256 individual strings - daunting mostly terms of electronics, but also terms of programming.
Seeing these fairylights with their baked-in serial ids makes the project feel withn reach for me.
Is there any further info in the three years since this thread, regarding production/‘programmming’/ordering of the raw string? Is it something one can order and construct? (Ive a 20x20 ‘ready made’ with the usual hooks at the top)
If its not possible to order ‘parts’ to define your own string matrix, then the next solution is to refactor the existing products. Reducing a 20x20 into 4 10x10 would mean I just need to purchase 3 to make a 10x10x12 cube (ok, cuboid)
Anyway, probably got lots ore Q’s but I’ve gushed enough here today… really looking fwd to hear your advice and suggestions.