LEDs flickering while using brightness

Issues
41

The vid from booster is indeed exactly the same “flicker” I have too.
Yeah you can say its flashing.

It also ocures at boot, cos then the brightness is set. Or when turned on.

42

Thanks for testing anyways, found something that shouldn’t have been there, so it’s good to have that fix in at any rate! Problably NeoPixelBus is already dealing with show() being called too frequently internally

1 Like
43

No problem, it isnt that much of a bother anyway.
Only happens during brightness settings, effects and udpraw etc working fine.

Thanks for trying at least :slightly_smiling_face:

44

Yes, @feindsender, and that’s what Makuna did talk about: the NeoPixelBrightnessBus does not honor those bits.

That does not mean that the strip isn’t using the 255 level that come from PWM.
So basicaly the APA102 in combination with NeoPixelBus is “not better than the WS28xx strips” (but it’s not worse, too).

45

I think Makuna means that NeoPixelBrightnessBus is using those bits also it should not use them.
When not using the 5bits the first byte should be 0xff and the 3 other bytes could be used like a normal
RGB strip

46

Hi @Aircoookie, yes, indeed the NeoPixelBus library checks if the brightness has changed and leaves the SetBrightness() function otherwise.

Makuna mentiones in the code that the Dot Stars don’t have a required delay.
So the pure update itself shouldn’t be the problem.

1 Like
47

For the RGB version, Makuna is not using the 5 brightness bits and sets them all permanently to 1:

static void applyPixelColor(uint8_t* pPixels, uint16_t indexPixel, ColorObject color)
    {
        uint8_t* p = getPixelAddress(pPixels, indexPixel);
        *p++ = 0xff; // upper three bits are always 111 and brightness at max
        *p++ = color.B;
        *p++ = color.G;
        *p = color.R;
    }

…but if LBGR is choosen (=RGBW), he uses the lower 5 bits of the brightness for that:

static void applyPixelColor(uint8_t* pPixels, uint16_t indexPixel, ColorObject color)
    {
        uint8_t* p = getPixelAddress(pPixels, indexPixel);
        *p++ = 0xE0 | (color.W < 31 ? color.W : 31); // upper three bits are always 111
        *p++ = color.B;
        *p++ = color.G;
        *p = color.R;
    }
48

Thats right. But when using the SetBrightness() function the 0xff gets overwritten. A call of Show() afterwards sends the wrong values. If i call a other function like SetPixelColor the 0xff gets restored.

49

…now as I read your words, I remember a strange thing with normal WS2812 pixels:

When using the Nightlight function as SunRise (&FX=0&A=5&CL=h00FF0000&C2=h00FFB14A&NL=10&NT=128&NF=2) it should be a transition from dark RED to a bright warm white tone, BUT: is does show a blueish flash at full brightness every few seconds (not regulary - more randomly).

And there is absolutely no code in the handleNightLight function that would explain that.

So maybe this goes in the same direction.

50

What pin are you using. I had mixed success with using GPIO2. Using GPIO3 works much better on my
WS2812. GPIO2 is using the UART1 method while GPIO3 is using a DMA method.

1 Like
51

I’m using GPIO 2 - thx for the hint - I do try it with GPIO3 :smile:

weired: it’s really only in this situation - never seen it before in any other situation.

52

4 (data and clock) wire leds have more succes on gpio3 with most libraries.
But the brightness thing still isnt solved with this tho :wink:

53

For 4 wire leds using gpio13 and gpio14 is probably the best choice. And changing the PIXELMETHOD to one of the SPI modes. This will then use the hardware spi bus.

54

Yeah true, but that still didnt fix the brightness flashing.
Already tried that.
The rest is just working fine with gpio 2 or 3 and gpio0 for the clock.
With ESPHome, I had to use fastledspi and gpio13,14 for it to work perfectly ok.
But WLED is completly different anyway, only using thos apa102 as ambilight behind my tv.
Al the others are WS2812B, so there is no brightness problem.

55

Hi…
Sorry for this dump question, but
Is there a Solution in all the Post ?
I tried to read carefully but i dont see it…

56

Hi,
there is no fix yet. Makuna from NeoPixelBus is working on it.
I will post here if it gets fixed.

57

Ok, Thank you for that…
so we are waiting for a lib to be fixed and with that the problem should be fixed in wled to, right?

58

Yes thats right. Also Makuna suggested not using the NeoPixelBrightnessBus at all.
Maybe @Def3nder or @Aircoookie could take a look at his comment on the NeoPixelBus github.

59

Hi,
Makuna just did an update to the NeoPixelBus Library.
I did a quick test and it seems to be fixed.
Maybe someone else can give it a try.

1 Like
60

…I’ve ordered some APA102 pixels, but unfortunately they are not yet delivered …