show_at_max_brightness_for_power flickering

[atuline]

I've been using the power managed delay and show functions on my WS2812B's with an UNO.

I find that when I lower the mA value to something I know will have an effect, rather than decreasing in brightness, the LED's start flickering.

I would have expected that FastLED would modify/override the FastLED.setBrightness() value, i.e. an internal setBrightness() or something.

The functions I'm using include:

setup() {
set_max_power_in_volts_and_milliamps(5, 100);
FastLED.setBrightness( BRIGHTNESS );
}

loop () {
show_at_max_brightness_for_power();
delay_at_max_brightness_for_power(loopdelay*2.5);
}

[kriegsman]

That is exactly what it does internally: temporarily scale down 'brightness'.

How many LEDs are you testing with?
(I'm going to guess: either < 80 or > 200 ?)

[atuline]

That would be 15 LED's, and I'm setting it to 100mA.

[focalintent]

15 LEDs is going to refresh WAY too quickly with the library at the moment - you're talking about 450µs to push out a frame of LED data, which means you're pushing data to the leds at ~1000-2000Hz. (Yes, I know I need to get rate limiting code in there - I almost have a general solution for this but it's not ready for prime time - it may be one of the next things to go into the 3.1 branch, though.

With the WS2812's - if you update them at more than 400Hz, they start to flicker like mad. One of the things I like about the APA102 is I've been able to throw data at them at rates well above 5000Hz, and they stay solid.

[kriegsman]

What Dan said.

Tell your sketch that you have 100 LEDs and see what happens. If that fixes it, that was the problem.

(And we do plan to do something about it inside the library, FWIW, it's just not "scheduled", whatever that means for us.)

[atuline]

Increased NUM_LEDS to 24, then 50, 100, 120 and 200. Still kept on blinking. Also increased 100mA to 200mA and finally to 500mA. Blinked all the way.

[focalintent]

Can you attach the code you're running? It'd be a lot easier to trace what's going on with code (especially since I have multiple installs here running code at those power levels without blinking like you describe)

[kriegsman]

Also if you can, take a video of the blinking and share the URL here -- again, that'll help us get more quickly to that point of Ah hah!

Thanks for this ticket, and the help in diagnosing it.

[atuline]

The unlisted video is at http://youtu.be/JwO5ZyhWWHw. A pastebin of my routine is at http://pastebin.com/2ZhaQVFb.

[focalintent]

Not having a pot around, I needed to have some other method for cycling brightness - so I had something that cycled from 0 to 255 and back down to 0 again. If I change your loop function to this:

void loop () {
  rainbow_march();
  show_at_max_brightness_for_power();
  delay_at_max_brightness_for_power(thisdelay*2.5);

  static signed short bval = 0;
  FastLED.setBrightness(abs((bval+=24))>>7);
  Serial.println(abs(bval)>>7);
} // loop()

(e.g. a sliding brightness shifting up and down smoothly) - I see no flashing at all like what you show - I also tried just manually setting the brightness to a variety of power levels and also saw no flashing. I decided to throw some randomness in there, namely, a 4% chance of setting brightness to 255:

void loop () {
  rainbow_march();
  show_at_max_brightness_for_power();
  delay_at_max_brightness_for_power(thisdelay*2.5);

  // uint8_t potval = map(analogRead(A4), 0, 1023, 0, 255);
  // Serial.println(potval);
 //  FastLED.setBrightness(potval);                          // FastLED brightness limiter
  static signed short bval = 0;
  if(random8() < 10) {
    FastLED.setBrightness(255);
  } else {
    FastLED.setBrightness(abs((bval+=24))>>7);
  }
  Serial.println(abs(bval)>>7);
} // loop()

And now I see flashing that looks quite similar to what was showing up in the video that you posted,
And now i'm wondering if your analog read is giving you spurious values while you are moving the potentiometer around? What happens if you try a simple debounce of the read:

void loop () {
  rainbow_march();
  show_at_max_brightness_for_power();
  delay_at_max_brightness_for_power(thisdelay*2.5);

  static uint8_t lastpotval=0;
  uint8_t potval = map(analogRead(A4), 0, 1023, 0, 255);
  Serial.println(potval);
  // debounce the pot read, require reading the same level two frames in a row for it to take
  if(lastpotval == potval) {
    FastLED.setBrightness(potval);                          // FastLED brightness limiter
  }
  lastpotval = potval;
} // loop()

Alternatively, can you try programmatically setting the values in a way other than using a potentiometer to get exactly brightness values where you have a sustained flashing?

Finally, @kriegsman adds:

IMX reading a pot too often can lead to wraparound on some readings.
Diagnostic: take 500 readings while twisting knob and then print them.
But has to be : read all then print all"

[atuline]

OK, I have now taken the pot out of the equation entirely and just ran .setBrightness in the setup() and not in loop().

I set NUM_LEDS to 100 and mA to 500. According to my chart, the LED's should blink when max_bright is defined at ~76, so:

• I then defined max_bright to 65, compiled and the LED's did not blink.
• I then defined max_bright to 85, compiled and the LED's DID blink.

So, yes, you will get a bit of spurious blinking around the threshold as would be expected. Beyond that, the effect should be pretty consistent.

[focalintent]

And when I take your original code - comment out the pot reading, set max_bright to 85, NUM_LEDS to 100,and mA to 500 I get no blinking.

So now, I need even more detailed information from you:

• what is the exact version of the arduino software that you are using
• what is the exact version of the FastLED library that you are using
• go into arduino preferences, turn on "Show verbose output during compilation" - do a build, and put up a pastebin of the entire build log.
• what is your wiring like, everything in and out of the arduino and the leds.

[atuline]

That would be:

1. Arduino 1.0.5-r2
2. FastLED 3.0
3. The compile past is at http://pastebin.com/zywLFxtd
4. I've removed ALL components and now just have the WS2812B string (of 15 LED's) connected directly to Gnd, 5V and pin 13 on the Arduino.
5. I've been able to repeat this with USB as well as battery power.

OK, I think I know the issue. . . . . pin 13.

You're probably pulsing it as part of the power management feedback. I change to pin 11, and the problem appears to go away. Further testing required on my part.

[atuline]

Awesome! Downloaded the update. Performed a FULL compilation and it now works as expected on pin 13.

[focalintent]

That said - i'd advise against using pin 13 on arduino boards for data output - I have heard about problems in the past with the led there drawing enough current that it causes signal problems for things having off of pin 13. Or at the very least, if you're going to use pin 13 - be ready to switch over to another pin (more likely to be an issue if you're going to do a long cable run).