Using an IDE 1.0.5-r2, FastLED 2.1beta, an Arduino Micro,

Archive FastLED Archive
,
1

Using an IDE 1.0.5-r2, FastLED 2.1beta, an Arduino Micro, and UCS1903’s with a Memsic2125 Accelerometer. The following code will not allow me to fade all the way out to black, there is the tiniest of flicker going on. Using the UCS1903B setting has the same effect, but slightly worse. Any recommendations?

====================CODE
float brightness;
long fadeTimer;
#define fade .9
#define fadeWait 20

void peakTrigger(){
if((accelerationX > 3800.00) || (accelerationY < -3800.00)){
brightness = 255;
fadeTimer = millis();
}
if(brightness > 1){
if(millis() - fadeTimer > fadeWait){
brightness = brightness*fade;
if(brightness <= 1){
brightness = 0;
}
fadeTimer = millis();
}
}
for(byte i = 0; i < NUM_LEDS; i++){
leds[i] = CHSV(hue, 255, brightness);
}
}

2

FastLED.setDither(0) took away the flicker.

3

A few thoughts:

  • What does brightness get down to given this algorithm? Does it actually hit zero? (You can tell with Serial.println often…)

  • You’ll get full benefit (and best visual results) from FastLED v2.1 if you fill the pixels with full-brightness colors, and then adjust the rendered brightness of the whole strip with FastLED.setBrightness. This comes out much better than dropping the brightness of the individual pixel values.

  • I’ll double-check that HSV2RGB returns pure black when V=0, but I’m pretty sure it does.

  • What visual do you get if you just do this:
    for(;:wink: FastLED.show( CRGB::Black);
    Do you get pure black or the same dim twinkling?

4

  1. Serial readout from algorithm:
    255.00
    229.50
    206.55
    206.55
    …
    1.31
    1.18
    1.18
    1.06
    1.06
    0.00

  2. CRGB::Black gives me black. The only time I have the flicker is with dither enabled.

5

leds[i] = CHSV(hue,1,255);
LEDS.setBrightness(brightness);

This took the flicker away with dither enabled.

6

Thanks for checking the values; looks like your getting to zero which is good and as intended.

I’m a little confused, and the terminology is new here so bear with me. Are you using FastLED.setDither to actually disable and enable dithering? If not, it’s always on, regardless if what colors your working with.

The test with Black was just a sanity check.

Ok, last thing: what are the RGB values winding up in ‘leds’ when your brightness variable is zero? Are they all zero or maybe something else low, like { R=1 G=0 B=0 } ? Again, you’ll have to print( leds[0].r ), and then .g and finally .b

We’ll get it figured out. Thanks for all the feedback so far!

7

Sorry if you’re confused, let’s see if we can keep posting at the exact same time.

Using this code:
CHSV(hue,1,brightness);
I get the flicker when dither is enabled, RGB values are 1,1,1 when it is supposed to be black.

CHSV(hue,1,255)
LEDS.setBrightness(brightness);
No flicker when dither enabled, RGB values are 0,0,0 for black

8

Thanks for the diagnostics. I’ll see what’s up with 1,1,1 coming out when it should be 0,0,0.

9

Speaking of .setBrightness(), it’s still doing half steps in 2.1, yes? (Or powers of 2 if you prefer that term.)

10

BY DEFAULT, it does integer scaling as before BUT with the new temporal dithering, the output is visually much better and smoother at low brightnesses.

HOWEVER, if you turn OFF temporal dithering with FastLED.setDither(0), it’ll do what it’s always done.
Well, it’ll do what it’s always done plus or minus a few corner cases we think we improved. But mostly: same.

11

Would you mind explaining the LEDS.setCorrection() ? I try the SMD5050, and when I show CRGB::White, the color is noticeably more red.

12

Jon: great question. I’m going to start a new post to discuss it (in the morning…)

13

Post posted: https://plus.google.com/112916219338292742137/posts/XgvxWxdmcrJ

14

CHSV(0,0,0) == CRGB(1,1,1) with Dither ON
After some testing with different code where I used the CHSV(0,0,0) to show black. CRGB::Black fixed the issue of the one’s showing up for now.

15

This is tonight’s project :slight_smile:

16

The interesting thing is that the 1’s seem to show up on the even numbered LEDs of my small 2x8 matrix only. I’m trying to confirm this with serial data next.

17

Serial data for one frame of led data using CHSV(0,0,0) to get Black:
1r,1g,1b,0 <—led#
1r,1g,1b,1
25r,25g,25b,2
25r,25g,25b,3
25r,25g,25b,4
25r,25g,25b,5
1r,1g,1b,6
1r,1g,1b,7
1r,1g,1b,8
1r,1g,1b,9
1r,1g,1b,10
1r,1g,1b,11
1r,1g,1b,12
1r,1g,1b,13
1r,1g,1b,14
10r,10g,10b,15
40r,40g,40b,16
10r,10g,10b,17
1r,1g,1b,18
1r,1g,1b,19

However, I can visually confirm with my eyes, that the even numbered pixels are lighting up only. The odd numbered pixels do not visually show data, that serial.print says, is in the leds[] array.

18

Hey @Jon_Burroughs , for giggles, turn off dithering, see what happens. Something like:
LEDS.addLeds<LPD8806, DAT_PIN, CLK_PIN, RGB>(leds, NUM_LEDS + 1).setDither(DISABLE_DITHER);

19

Dithering off, CHSV(0,0,0) for black:
,1r,1g,1b,0
,40r,40g,40b,1
,10r,10g,10b,2
,40r,40g,40b,3
,10r,10g,10b,4
,1r,1g,1b,5
,1r,1g,1b,6
,1r,1g,1b,7
,10r,10g,10b,8
,40r,40g,40b,9
,10r,10g,10b,10
,1r,1g,1b,11
,1r,1g,1b,12
,1r,1g,1b,13
,1r,1g,1b,14
,1r,1g,1b,15
,1r,1g,1b,16
,1r,1g,1b,17
,1r,1g,1b,18
,1r,1g,1b,19

20

Wicked. Ok, put this on @Mark_Kriegsman 's operating table …