Re-commented the delay line and un-commented the show line and I still get 45 real seconds for the expected 60 seconds.
Thank you! Ok NOW I have a theory. Just for the sake of testing, set it up as a 100 pixel string. You don’t have to actually have 100 pixels connected (the Arduino can’t tell anyway!), just set up NUM_LEDS as 100. Leave both show() and delay() in place.
I predict that timing will be “normal” again, but that if you set up for fewer than about 85 pixels, timing will be more and more off, with the “most wrong” situation being at NUM_LEDS being just 1.
I suspect this has to do with the requirement that the WS281X pixels not be updated more than 400/sec, and the FastLED safety feature that makes that work automatically.
Another thing to try to confirm this is replace the FastLED.delay() with a plain Arduino delay(). Timing should revert more or less to correct I suspect.
If this all pans out, we know what to change to improve the timing! (And if not… it’ll be interesting…)
Thank you for the help!
Hi, it is OK as you predicted with 100 LEDs defined !
For the fun of it I defined a huge string of 1 LED but the differential appeared to be no worse than what I got with 25 LEDs !?
Yeah, I think there’s a “lower bound” of bad, and you’re already there.
Ok, thank you for all the feedback and data points. I think I know what’s up and how we might address it in code. Thanks again for the help-- we may ask you to help confirm if/when we have a code change to address this.
With LEDs back to 25, I now changed the line:
FastLED.delay(1000/FRAMES_PER_SECOND);
to:
delay(1000/FRAMES_PER_SECOND);
and it only reduced the differential from 45 seconds to about 54 seconds for a 1 minute count.
Yep. Thanks. All kinda fits, at least in my head. I’ll look at the code with Dan.
I am very happy to help. I will promptly test anything I can with my limited resources and programming skills.
Can you explain (no rush !) why I still got LED animation when I comment out the only visible FastLED.show(); command !?
When you call FastLED.delay(), the library uses the time to keep refreshing the LED strip so that the temporal dithering looks good. There’s a little bit more discussion here https://github.com/FastLED/FastLED/wiki/FastLED-Temporal-Dithering
@Mark_Kriegsman thats great news, i follow the git repo, and i had seen a glimmer of this last week, just as i was thinking “whats the best way to schedule this stuff”.
Awesome!
@Mark_Kriegsman thanks, I now understand why it happened but not sure how ?
Does a FastLED.delay execute only 1 ‘show’ or can it do more ?
Went through the Temporal dithering (again) to understand it better and figured that you probably somehow want a regular time interval between any ‘shows’ to better control the precision of the dithering process.
Having delays auto-executing a ‘show’ although seeming an efficient use of otherwise wasted delay time may prevent getting these regular intervals. Maybe this is already well taken care of… just food for thoughts !
FastLED.delay() will keep doing show() as long as time permits – UNLESS it’s determined that the main loop between regular show() calls is being ‘too slow’ to have the temporal dithering remain invisible.
For example, if your main draw code requires enough computation that it can’t update more than 20x/sec, the temporal dithering automatically shuts off, because at 20 updates / sec, the dithering looks like flickering, not smooth solid light.
I believe we set then threshold at 100 updates/second. Above that, the temporal dithering kicks in. Below that, it shuts off to prevent flicker. It’s all a big trade-off of time vs quality in an environment where the pixels are only really 8-bit, and the smallest hardware brightness steps are pretty visible.
Anyway, at 100 updates/sec and above, the temporal dithering takes place at 50Hz+, which is above the flicker fusion rate for the human eye. (Cats are another story.)
As you might surmise, faster pixels (LPD8806, APA102) can do faster updates, and thus temporal dithering is available more of the time, and looks better.
We put the low-update-rate cutoff in there for situations like the one you hypothesize. We didn’t used to have it, and results were solidly “mixed.” (Meaning: sometimes lousy.) With the low-update-rate cutoff in place, it basically doesn’t turn on the temporal dithering unless it’s going to actually look good. At least, that’s the plan, and how it seems at this point. We’re continuing to evolve it based on actual use, as you can see!
@Mark_Kriegsman Thanks !!! As always, very clear, detailed explanations.
I think this is worth adding in the docs if you ever get the time… 
Just committed some refinements to the clock-adjustment code on AVR; millis() should track noticeably closer to real time now that it did before, and the number of pixels you define should have a much, much smaller effect on the millis() clock overall. There’s still some (unavoidable) interaction, but it’s definitely improved.
https://plus.google.com/112916219338292742137/posts/MKWSjR1VteS