Same here on or off makes no diffirence
I opened a issue in neopixelbus github with my findings from above.
the NeoPixelBus is okay - you wrote that the 1st byte is used to controll the brightness, but this is not true. The SetBrightness function does the following:
Correct the input value for faster integer processing (to use bitwise shift instead of / ):
uint8_t newBrightness = brightness + 1;
Get a value between 1 and 255 as scale factor (shift target value left 8 bit to get 16 integer (higher 8 bits only) and substract the 1 that had been added in the start):
scale = (((uint16_t)newBrightness << 8) - 1) / oldBrightness;
Get a pointer to the raw pixels:
uint8_t* ptr = this->Pixels();
get a pointer to the last pixel (PixelSize is 3 for RGB stripes and 4 for RGBW stripes):
uint8_t* ptrEnd = ptr + this->PixelsSize();
Do-white loop for ptr from 1st pixel to last pixel:
while (ptr != ptrEnd) {
get the value of the the pixel in the loop:
uint16_t value = *ptr;
Scale the value and shift right again and increase the pointer after taht (++ behind the variable):
*ptr++ = (value * scale) >> 8;
}
_brightness = newBrightness;
this->Dirty();
}
So, everything is fine.
The ptr is iterated in the while-loop.
In your code this would be done three times for every of the 3 bytes and would corrupt the array.
…so: flickering does not come from NeoPixelBus library.
Hi Def3nder,
the APA102 leds are a little special. They use 4 bytes for RGB.
The first byte consists of three 1 bits followed by 5 bits for a global brightness setting.
It is explained here:
The set.Brightness function is modifing all 4 bytes were it only should change the 3 RGB bytes.
Hi @feindsender,
yes, but this is not part of NeoPixelBrightnessBus, it’s part of the library that drives the strip.
This is hardware-specific and we are at a place where this library talkes about RGB or RGBW values only.
The “strip” array does hold the colors - it has nothing to do with the protocal that will be sent to the strip (this is handled by the NeoPixelBus library)
Incase of the APA102 the strip array sadly also holds that first byte.
You are right it should be changed in the led driver.
But both are part of the NeoPixelBus library.
My code was just to test what was the fault.
please check yourself: this->PixelsSize() is 3 for the APA102 (and it will become 4 bytes on the hardware side), but it’s three while in the NeoPixelBrightnessBus library.
…if not we need to open an issue at https://github.com/Makuna/NeoPixelBus
Did you mean PixelSize() ?
This returns 4
PixelsSize() returns 16 in my case because i am only testing with 4 leds
I already opened an issue
okay - this should have been 12 for 4 pixels. Did you enable LEDs are 4-channel type (RGBW): in the LED settings ?
I think there is an error in WLED Nbpwrapper.h:
RGB (for APA102) will use DotStarBgrFeature
and RGBW will use DotStarLbgrFeature ,
but this should be DotStarWbgrFeature
And: the support the a LBGR strip (DotStars that support RGB color and a overall luminance/brightness value) is not “in scope” for WLED currently.
So we would need another #define for APA102LBGR (or similar) that then uses DotStarLbgrFeature and will get the brightness as first byte and the pure RGB colors in bytes 2 to 4.
Could you try this ?
Change lines 85+ in Npbwrapper.h from
#ifdef USE_APA102
#define PIXELFEATURE3 DotStarBgrFeature
#define PIXELFEATURE4 DotStarWbgrFeature
#elif defined(USE_LPD8806)
#define PIXELFEATURE3 Lpd8806GrbFeature
#define PIXELFEATURE4 Lpd8806GrbFeature
#else
#define PIXELFEATURE3 NeoGrbFeature
#define PIXELFEATURE4 NeoGrbwFeature
#endif
to
#ifdef USE_APA102
#define PIXELFEATURE3 DotStarBgrFeature
#define PIXELFEATURE4 DotStarWbgrFeature
#elif defined(USE_APA102_LBGR)
#define PIXELFEATURE3 DotStarLbgrFeature
#define PIXELFEATURE4 DotStarWbgrFeature
#elif defined(USE_LPD8806)
#define PIXELFEATURE3 Lpd8806GrbFeature
#define PIXELFEATURE4 Lpd8806GrbFeature
#else
#define PIXELFEATURE3 NeoGrbFeature
#define PIXELFEATURE4 NeoGrbwFeature
#endif
and change the line 9 from
#define USE_APA102 // Uncomment for using APA102 LEDs.
to
#define USE_APA102_LBGR // Uncomment for using APA102 LEDs.
…this should fix it.
I am not using WLED for testing. I am using the NeoPixelBrightness example sketch modified for
the Dotstar LEDs.
Using DotStarBgrFeature or DotStarLbgrFeature makes no difference. The mentioned DotStarWbgrFeature does not seem to be in the code at all.
I think we will have to wait and see what Makuna from NeoPixelBus thinks.
okay - I’ve prepared a fix for WLED…
…but this is all only “theorie” - so I do wait for the outcome of the issue #339 there…
I could try if that works later on, but I have my doubts, its probably in the driver.
Cos FastledSpi works fine on the spi bus or dma driven on gpio3.
When I used my arduino uno for hyperion with adalight sketch from them, it used also fastled.
Wich was also spi based, with that never a flicker in brightness settings.
For me it only happens with NeoPixelBus, cos in ESPHome with NeoPixel I have the same problem, also need to use Fastled.
So what does Fastled diffirent to the apa102 compared to NeoPixelBus?
just a thought:
could it be that the flicker is just caused by a “too low framerate” ?
I#ve just been in my daughter’s room (with the analog RGBW stripes) and there I see a flicker when changing brightness, too, BUT: if I change colors, it’s not there.
@Aircoookie: AFAIK the framerate is higher when “in transition”, so it’s higher when changing primary colors ?
Makuna just confirmed that NeoPixelBrightnessBus does not honor those special brightness bits.
We have to wait what he will come up with.
But that’s for APA102 only ? (APA102 has only 31 levels of brightness), or does he do this for all types of stripes ?
…just looked at the code: this is for APA102 only - for the other types he does use 255 levels.
And the APA102 are designed to have 31 additional level of brightness (Driving Current) on top of the 255 levels from the RGB values (PWM Duty Cycle). This is what Makuna is referring to - he does not use these “additional 5 bits”
Those additional brightness levels can be used with the DotStarLbgrFeature.
With the DotStarBgrFeature they should stay at 31.
Good call!
I wasn’t actually sure what the framerate in a Brightness transition was, so I took a look at the setBrightness() function and it was possible for it to call show() way too often (potentially every loop)!
This would explain the flicker with APA102 because of misuse (attempting to drive at a way too high framerate).
Can someone try current master to see if the issue is fixed?
1 Like
I can try now, gimme a few minutes
Flickering is actualy the wrong description its more like flashing. The video boostar posted shows it.
Its caused by the APA102 strips getting send wrong data. I verified it by using sigrok and looking at the
spi bus data.
No that didnt fix it.