Support for Lumary permanent outdoor LEDs - chipset unknown

[nathankopp]

I purchased Lumary permanent outdoor lights and have attempted to control them with WLED (currently using Athom hardware will be trying an ESP32 also). From what I can tell, WLED uses NeoPixelBus behind the scenes, at least for ESP32 implementations.

The Lumary LEDs are individually controllable 24V RGBW, but I don't know what chip they use. When I configured them as within WLED as SK6812 with order RGB, they ALMOST worked. The red and green channels seem to work correctly. The blue channel seems to be misinterpreting the bits, and the W channel doesn't seem to get above 20% illumination. I suspect that maybe the signal timing needs to be adjusted (increased or decreased), but I'm not sure how to do that.

From what I gather, the WLED build I'm using seems to construct NeoPixelBrightnessBus<NeoGrbwFeature, NeoEsp32RmtNWs2812xMethod> when I select SK6812. Looking at the code, I've found my way to NeoEsp32RmtSpeedWs2812x, which I think defines the signal timings. However, I don't fully understand what's going on here.

Any suggestions for adding support for the chipset in these LED lights?

[Makuna]

Do you have a link to the specific product? I see they sell multiple varieties.

https://lumarysmart.com/products/lumary-rgbai-permanent-outdoor-lights

These seem to be RGB plus Warm White.

Without either a spec sheet or logic capture of the current data stream, that leaves us with only trying different configurations. And WLED doesn't support all the configs yet, so it would be best to use Arduino and my library directly using the test example. If you're up for doing that, let me know.

Test using no effects, just solid colors, to simplify discovery.

The Feature controls the color order and size mostly (https://github.com/Makuna/NeoPixelBus/wiki/Neo-Features)
The Method defines the timing mostly (https://github.com/Makuna/NeoPixelBus/wiki/Neo-Methods)

The WS2812x is the most compatible on timing. I think it's really unlikely that the protocol/speed is the issue, so this should be the last thing tried. Often if it is, then you would not see consistent all Green and Red channels working correctly. You would see each pixel acting different and often showing nothing or twinkling.

[nathankopp]

Yes, that is the product. I'm using the "118ft with 78 LED Lights" variation.

I just finished testing some of the NeoPixelBus examples using a NodeMCU-32S board. Here's the results:

• NeoPixelBus.ino, using NeoRgbwFeature, NeoWs2812xMethod: works great. The first four pixels blink slowly as red, green, blue, and white. I tried with colorSaturation at values of 10, 128, and 255 and they all seemed to work correctly.
• NeoPixelFunFadeInOut.ino, modified to use RgbwColor: Fading in and out of some colors works great, while fading other colors causes flickering during the fade. It is NOT a smooth fade-in flickers significantly during the fade-in and during the fade-out. The colors that flicker the most are ones that include both blue and green channels. I tried driving a single pixel (PixelCount = 1) and I also tried driving a full string of 13 pixels (PixelCount = 13), and both tests exhibited the same behavior for the lit pixels. I also tried with a lower max luminance (FadeInFadeOutRinseRepeat(0.05f)) and it still blinked during the fading for green and blue-green color hues, but no blinking for red or orange or purple color hues.

[nathankopp]

Any ideas about what could cause this behavior? If not timing, what else could cause this? If I want to play around with timing to experiment, how would I do that?

[Makuna]

Since the NeoPixelFunFadeInOut sketch will update the LEDs as fast as it can while the test one has delays in it, this points to a possible reset time issue. This following change will check if the LEDs need a longer reset time.

In the sketch after the show, add a delay(20) like

        // the normal loop just needs these two to run the active animations
        animations.UpdateAnimations();
        strip.Show();
        delay(20);

Include a link to your modified code. It could also be a simple typo, it could be bug, but a reproducible sketch that I can use will help.

[nathankopp]

Adding the delay did not work. I took some oscilloscope readings from the control wire of the provided controller and compared it to the data output for NeoPixelBus using NeoEsp32I2sSpeedWs2812x. Both of these signals light up the red lights, but the signal from the provided controller lights up the channel much brighter.

I see three differences:

1. The provided controller provides a 50% higher voltage on the data wire.
2. The pulse frequency from the provided controller is slower: ~678 kHz vs. 800kHz
3. The wave shape from the provided controller is not a square

I can use a level shifter to boost the voltage of the data line, but I think the problem is most likely with the pulse frequency. Is there a way to lower the pulse frequency for NeoPixelBus?

[nathankopp]

Here's the plot:

[Makuna]

The Apa106 method (NeoEsp32Rmt0Apa106Method or NeoEsp32I2s1Apa106Method) runs at about 600 kHz. You can try it.

When you capture from the luminary controller, try to capture the reset time (the low signal time between bursts). Here is an example from my logic analyser. You can see 77us reset time between the bursts. This is an important data point.

The signal "ugliness" of being rounded over like the luminary controller output from your capture is usually due lack of a correct resistor and capacitor to smooth the signal. It's almost at art form to what the correct values are and it all depends on the length and shielding the wires are between your controller and the first LED.

Are you capturing the above while connected to the LED strips? The strips may have them present so without it being attached it may not look as clean.

I suggest you stick with RMT until you get it running. It's easier to "adjust" the timing and its more versatile in the timing.

class NeoEsp32RmtSpeedWs2812x : public NeoEsp32RmtSpeedBase
{
public:
    const static DRAM_ATTR uint32_t RmtBit0 = Item32Val(400, 850); // Bit 0 = 400ns high followed by 850ns low
    const static DRAM_ATTR uint32_t RmtBit1 = Item32Val(800, 450); // Bit 1 = 800ns high followed by 450ns low
    const static DRAM_ATTR uint16_t RmtDurationReset = FromNs(300000); // 300us

    static void IRAM_ATTR Translate(const void* src,
        rmt_item32_t* dest,
        size_t src_size,
        size_t wanted_num,
        size_t* translated_size,
        size_t* item_num);
};

class NeoEsp32RmtSpeedApa106 : public NeoEsp32RmtSpeedBase
{
public:
    const static DRAM_ATTR uint32_t RmtBit0 = Item32Val(350, 1350); // longer pulses
    const static DRAM_ATTR uint32_t RmtBit1 = Item32Val(1350, 350);
    const static DRAM_ATTR uint16_t RmtDurationReset = FromNs(50000); // 50us

    static void IRAM_ATTR Translate(const void* src,
        rmt_item32_t* dest,
        size_t src_size,
        size_t wanted_num,
        size_t* translated_size,
        size_t* item_num);
};

[nathankopp]

Update: I took a little break from this project but now am back trying to figure it out again.

Using a level-shifter to increase the voltage to 5v did not seem to have any effect.

I ended up using the following timing so that the oscilloscope waveforms would match very closely in timing, but this also seemed to make no difference:

    const static DRAM_ATTR uint32_t RmtBit0 = Item32Val(250, 1300);
    const static DRAM_ATTR uint32_t RmtBit1 = Item32Val(800, 750);
    const static DRAM_ATTR uint16_t RmtDurationReset = FromNs(300000); // 300us

None of the changes to timing or voltage seem to have had any impact on the behavior.

Here are some examples of how it behaves incorrectly:

• When I send 255 for red and 0 for the other channels, the pixels all light up red, but they do not light up as brightly as when the stock controller.
• If I slowly fade in the red channel from 0 to 255, the LEDs all fade in as red as expected until they reach about 50% or 60% of their maximum brightness, then they stop getting brighter and hold steady through the rest of the fade-up time. The bits seem to be sent correctly, based on what I'm seeing in the oscilloscope.
• If I slowly fade up blue channel, it achieves maximum brightness before the byte value reaches 255, then it drops back down to a dimmer value and then fades up again and then dims again. It's almost as if the LED chip is interpreting the bit order differently.

So, I'm still stuck. Any help from the community would be appreciated.

[Makuna]

Keep using your scope on the output pin and clean up the signal. Check before AND after the level shifter. Further, the original controller's output should NOT be rounded over like your capture showed, it should be much more squared off. If you could clean that up and capture it might lead to a better understanding. This could be your scope is not capturing at a high enough frequency rate, but often this is due to poor resistance and grounding. See the [Adafruit best practices] (https://learn.adafruit.com/adafruit-neopixel-uberguide/best-practices) for some suggestions. Make sure to capture with the LEDs in place, as they be providing the extra resistance already.

Focus on the first 32 bits (first RGBW pixel) and the reset time (time the signal is low before that first 32 bits). Is what you see what you expect? Compared to original?

Try simple things, you already tried the NeoPixelBus.ino and stated it worked. I have no idea what that is. I suspect you meant NeoPixelTest.ino? Confirm that you stated you used different saturation values and they worked fine. Correct brightness levels? This means the data signal is generally correct.

You never provided what the reset signal timing was. This is that low signal BEFORE the first pixel of data. How long is it in us (microseconds) from your controller and then from examples?