New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

show_at_max_brightness_for_power flickering #89

Closed
atuline opened this Issue Oct 28, 2014 · 14 comments

Comments

Projects
None yet
3 participants
@atuline

atuline commented Oct 28, 2014

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

This comment has been minimized.

Show comment
Hide comment
@kriegsman

kriegsman Oct 28, 2014

Contributor

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 ?)

Contributor

kriegsman commented Oct 28, 2014

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

This comment has been minimized.

Show comment
Hide comment
@atuline

atuline Oct 28, 2014

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

atuline commented Oct 28, 2014

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

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Oct 28, 2014

Member

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.

Member

focalintent commented Oct 28, 2014

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

This comment has been minimized.

Show comment
Hide comment
@kriegsman

kriegsman Oct 28, 2014

Contributor

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.)

Contributor

kriegsman commented Oct 28, 2014

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

This comment has been minimized.

Show comment
Hide comment
@atuline

atuline Oct 29, 2014

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.

atuline commented Oct 29, 2014

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

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Oct 29, 2014

Member

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)

Member

focalintent commented Oct 29, 2014

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

This comment has been minimized.

Show comment
Hide comment
@kriegsman

kriegsman Oct 29, 2014

Contributor

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.

Contributor

kriegsman commented Oct 29, 2014

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

This comment has been minimized.

Show comment
Hide comment
@atuline

atuline Oct 29, 2014

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

atuline commented Oct 29, 2014

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

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Oct 29, 2014

Member

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"

Member

focalintent commented Oct 29, 2014

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

This comment has been minimized.

Show comment
Hide comment
@atuline

atuline Oct 29, 2014

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.

atuline commented Oct 29, 2014

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

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Oct 29, 2014

Member

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.
Member

focalintent commented Oct 29, 2014

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

This comment has been minimized.

Show comment
Hide comment
@atuline

atuline Oct 29, 2014

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 commented Oct 29, 2014

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

This comment has been minimized.

Show comment
Hide comment
@atuline

atuline Oct 29, 2014

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

atuline commented Oct 29, 2014

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

@focalintent

This comment has been minimized.

Show comment
Hide comment
@focalintent

focalintent Oct 29, 2014

Member

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).

Member

focalintent commented Oct 29, 2014

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment