Three LEDs per controller IC, all showing the same color. https://automatelife.net/govee-dreamcolor-rgbic-led-strip-lights-h61631a1-review-no-hub-required/
Yes, I realize the rgbic strips are essentially a ws2811s (I think that’s the right one)… But that doesn’t describe these copper wire ones.
Anyway, we’ll see what’s what. I’ll be doing some testing and sounds like others are too
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.
I’m going to try some Ys next.
These are cool, I see so much potential.
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?
My test setup: 4 strands of 10 (curled for ease of control), all on one connector.
Excuse the sloppy soldering
Low exposure so you can see each pixel is different and it’s absolutely not mirrored
No, I have not tried putting two strands together, but I’m going to guess they won’t behave well. Until we understand how it retains “position” info
I’m glad I bought 6 sets, as the price at Amazon has gone up $2 already. (10% increase)
I’ll look at doing some video, the stills don’t do it justice.
Uploading video now to YT. Btw, 333ns works fine so far. Perhaps length vs timing is an issue with long runs. TBD.
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)
You know…
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.
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:
https://twitter.com/GeekMomProjects/status/1343355880708816896
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.