I have a number of (identical) props that are currently using signal repeater/splitters to copy one WS2811 signal, giving well syncrhonized effects. I would like to keep this, but also allow for treating as a big daisy-chained pixel strip. I want something that doesn’t rely on laggy WiFi sync or the like, major software mods, or etc.
So here’s my idea: a signal duplicator ↔ daisy chain switch.
Each prop has a sacrificial first pixel and additional switch logic, which switches the source of the downstream data signal from the LED Controller’s data line (in dup mode) to the Dout of the prop.
The switch starts in dup mode, but can be switched to daisy chain by giving it a specified data value (e.g. in the first byte), which must take effect before the next pixel’s data is output by the WS2811. The RESET resets the switch.
In WLED, the sacrificial pixels can be in their own segment. For dup mode, you only need the one, since the data is being dup’ed.
Here’s a conceptual diagram of the relevant bits.
Why do you need the sacrificial pixel at all? As long as your Switch x devices are not physical switches, but logic devices (74AHCTxxx family), they’ll buffer the data signal as required.
Depending on how many Prop devices you want to control at once, you can simply use multiple GPIOs on an ESP32. Then this becomes a software problem w/segments and or ledmaps.
If the Props need to be far apart, you may do as well to simply use TxRx boards. You can effectively replicate your “switch” design by adding a 2nd Tx (Tx2) board onto the Rx A+/B- lines at the Prop. Your control signal just tells the Tx2 board whether or not to transmit to the next Prop.
There needs to be some data to drive the switches, and rather than deal with emulating the WS2811, I’d rather run a WS2811 in parallel to gobble up the data.
I haven’t thought too much about the switch. Maybe edge counting could work, e.g. with alternating 0,1 to manipulate the count. Also I’m not sure whether some additional signal conditioning would be required. Any advice would be greatly appreciated.
I’d like to avoid running each (of the six) props on its own data line. Also, the ESP-M2 is my platform of choice.
The whole installation covers under 10m, including the daisy chaining, so I don’t think distance will be an issue (it isn’t with the duping I am doing now with repeaters - mostly for signal reflection issues I think). Japan semi-urban
Still don’t know why you think you need a sacrificial pixel.
The original data comes from the ESP32, if you want to “duplicate” or share that data stream you can use an AND (74AHCT08) or OR (74AHCT32) gate chip and drive multiple outputs from 1 chip.
With ~6 (8?, 10?) Props, the distances will probably be fine.
You still haven’t described what’s controlling all these switches and what kind of an effect or result you’re hoping to achieve.
The WS2812B data signal from my ESP-M2 running WLED is driving the switches.
Like the WS2811, the switch reads the signal and looks at the first 24bits to decide which input to output. It starts in the state of outputing IN1, and reverts to that on RESET. If it gets a magic value, it switches to outputing IN2.
I’m not sure whether I can do this easily with discrete logic only, not being an EE. But together with a small MCU, I will be able to manage.
This type of problem is similar to the discussion on creating “icicle” style Xmas lights where a “T” junction sends data either to a “drop” set of LEDs or on to the “main” bus of LEDs.
It’s not a trivial a problem to solve as the timing of the LEDs is pretty critical and depends on a bunch of factors including the total # of LEDs and the length(s) of the drops/side branches. Overlayed onto that is the timing of a full “set” of LED data can only be delayed by less than 50us before you trigger an automatic display of current data received.
It’s doable, just not trivial.
I still stand by my comment that you don’t need the sacr. pixel as 1 gate can drive 2 inputs simultaneously with no loss of data integrity. The only time that’s an issue is when trying to send 3.3V ESP data to the 1st pixel. After that, everything is 5V data.
@divsys I don’t want the switching data appearing on my pixels. That is why the sacrificial pixel.
I hope by using the WS2811 for the data path (except for switching before the WS2811 outputs downstream data) that I won’t have any timing issues. I just need a switch that can react within, say, 16bits of data (40us in low speed, 20us in high speed mode, according to WS2811 datasheet).
Sorry, there’s no such thing as “switching data” an LED data stream is intact from start to finish.
After a previous Reset/display pulse, LEDs start to accumulate any data they see until the next Reset pulse.
If an LED sees more than 24bits of data, it just passes it on.
Your switching scheme has to accommodate these timings for all Props in the set.
In other words, once any Prop sees more than a 50us wait for data, it will Reset/Display.
All the sacr. pixels will do is add one more “unused” pixel to the Props.
That won’t give you time to do much of anything given the speed/pulse width of the data stream.
But, hey if you can make it work, good luck to you!
I beg to differ on there is no such thing as ‘switching data’. You were suggesting a logic IC.
I think I will use a multiplexer ‘bus switch’, 2:1 inputs to output, as switching bus signals seems to be what they are for. E.g. PI5A3157, 1 channel 2 inputs to 1 output, with a switching time of under 25ns and signal propagation delay of 1ns. (Allowable jitter for WS2811 is +/-150ns). $0.45 a pop. I’ll probably use some ATtiny to do the magic value recognition, RESET recognition, and to output the switch control toggle.
Another adventure Thanks for the good wishes.
Prototype schematic. The ATtiny202/402 has hardware support for decoding digital signals aka ‘input capture’; it looks perfect for decoding the WS2811 protocol.
