Need help adding some unusual LEDs

[bepeit01]

Hello and happy new year!
As christmas is over, everyone is putting the christmas lightning back into the closet, but not me. I want to pimp mine for the next chrismas season. Unfortunately the christmas lights i have, seem to have a protocoll which differs pretty much from what i have seen before and what seems to be supported by NeoPixeBus.

TL;DR;
I need to implement a protocol were each LED is addressed on the bus via an ID, plus some start and end bits. In addition the bus is much slower (35kHz) and the timings are much longer than for the WS28XX. As far a i have seen, i can implement the additional data in the Feature, but the timing needs changes in the method. So, how can i bind a specific Feature to a specific method? (if i go the easy way and just use a modified BitBangingMethod) or how can i influence the timings of the existing methods?

Long Version
I have a "MELINERA Smarthome RGBWW" lightchain from the german discounter LIDL (see https://hueblog.de/2020/12/03/was-taugt-die-zigbee-lichterkette-von-lidl-in-verbindung-mit-der-hue-brigde/ ) which a kind of nice because they are cheap and can be addressed individually (and use zigbee) BUT the effects shipped with it are boring and cannot be changed. That's we i wanted to get rid of the electronics and use WLED with it (which uses NeoPixelBus, that's why i am here). First i got disappointed as i saw that the chain only has two wires, every stripe i know has at least 3... But after hooking it up to my scope i saw that they have modulated the signals onto the 24V supply voltage.
After some time i was able to decode the used protocoll, which works as following (all LSB first)

1. two HIGH Bits (probably to sync the receiver)
2. 9 Bits for the ID of the LED
3. 8 Bits White
4. 8 Bits Red
5. 8 Bits Green
6. 8 Bits Blue
7. One longer HIGH as delimiter

A little bit unsual is that each bit takes between 30us and 33us on the bus. The Timings are as following:

• T0H: 3.6us
• T0L: 25us
• T1H: 7.2us
• T1L: 25us
• Treset: 15us

While studying the code of NeoPixelBus i came to the conclution that i can add the additional needed bits (start bit and ID) in a own ColorFeature and that the timing and probably the delimiter needs to be implemented in a method.

So i have some questions... The only place where i could find timing informations is the BitBangMethod, sure i could just create my own version with my timings, but than i would need to find a way to couple my feature with my method. But i also would love to be more generic and would like to have deveriates of the well working DMA and I2s methods. But for this i would need to find out where i can specify the timing...

I hope you can follow my explanation and understand my problem!
Thanks for your help!

I have attached the pictures of my scope for everyone interessted, perhaps someone knows the protocoll and maybe it is even implemented somewhere?

Thanks!
Benedikt

[Makuna]

What platform? AVR (most Arduinos), ESP8266, ESP32, other? Each has their own set of methods for sending that are specific to their hardware.
Most methods have the assumption that you are sending bytes of data, not individual bits. This was historically for performance and there was no need for anything else. Some hardware is limited to bytes not bits. Due to how ESP8266 and ESP32 hardware is used, they do NOT have byte limitations.

The color Feature is not about hardware protocol. It's the abstract of the data at its essence, header for strip wide configuration, a series of individual pixel values, and a footer for possible strip wide configuration. While the data structures contain the needed data the format does not match the output exactly. It just matches the order of data and not protocol specifics like start and stop bits or even reset times.
The Method is the hardware protocol. It has two jobs today, convert the feature data into readily available stream data as needed by hardware, and interface with hardware (or bitbang) that will stream the converted data with any protocol specifics. This second very low level part is often in a hidden layer in the code shared between methods and the method wraps up specifics to that API (and often duplicates small amounts of code) as needed.

If you glance at the NeoEsp8266Dmx512Method you will see one of the more extreme versions, where it does start and stop bits and packs it into a stream of bytes as needed by the i2S hardware. Non byte sized data is messy and complicated, and you can see this with the Encoder method.

It seems the protocol they have would allow only sending data to update a single pixel leaving the others alone. I can understand why they did this with how slow it is. I suspect it is also so slow due to them modulating it onto the voltage wire which is often inherently noisy. But in the case of NeoPixelBus, it updates ALL pixels in each send. 200 LEDs with the above protocol would be 1.5 ms; so still reasonable for animations.

[bepeit01]

Thanks for your fast answer! I'm planning to use either esp8266 (most probably) or ESP32.
So i should add the ID values in the feature part, as this is basicaly just a "hidden" Color Feature while adding Start and Stop Bits in the method part? I think i can do some tricks with the ID as the chain only contains 200 LEDs and the 9th bit would always be zero in my case, otherwise i could use a 16bit type in the feature and cut of the highest 7 bits in the method part...

The DMA method is the default for esp8266, correct?
I've seen a lot of divisors for the timing eg

const static uint32_t I2sClockDivisor = 4; // 0-63
const static uint32_t I2sBaseClockDivisor = 16; // 0-63
const static uint32_t ByteSendTimeUs = 17; // us it takes to send a single pixel element
const static uint32_t ResetTimeUs = 50;

But what are they referencing to? CPU cycles per second?

It seems the protocol they have would allow only sending data to update a single pixel leaving the others alone.

I had excatly the same thought and was thinking about modifying the update command in the method just to send the diff, although this would cost extra memory...

[Makuna]

In your case, there is no real exposed across the strip properties, so there is no need for a specific feature other than the color order. The color order you need is WRGB, I don't think I have one of those, you can look at the RGBW and see how to copy it and modify it.

The clock divisors, I forget if it's the CPU clock or the peripherals clock. The peripherals clock is slower than the default CPU clock (80mhz?) and is always the same no matter what you set the CPU clock to. But the best thing to do here is guesstimate it values, the use a logic analyzer to tune the values.