96 MHz (overclock) → 72 MHz
ZOMG.
Is that the whole story, at the end of the day?
Congratulations on finding it in time. (Yes?)
(We found someone to come round with a 'scope, and as I was explaining the setup to him and going through the setBrightness() dance to show him the effects, I thought, “Hmm, what if I…” and that was it. Dude had been there for five minutes, hadn’t even taken the scope out of his bag.)
In time, to some extent—as in, I would have preferred to have never set “overclock” in the first place (or maybe I didn’t, is it the default?) and have had the project hardware all done four weeks ago, but today is better than next week.
I heard this first as a teddy bear, but I can’t but help think of this: http://en.m.wikipedia.org/wiki/Rubber_duck_debugging
And hooray for this week. Now go get a beer.
Congrats!!! Indeed troubleshooting can be maddening with so many variables!
Hi @Robert_Atkins ,
First… YEEEAAAAHHHHH !!!
Second, I would have loved it better if you had taken the time to probe around with that scope while Teensy is overclocked and misbehaving.
I am wondering if you are only just below some noise threshold !?
Maybe still misbehaving but just not as visible !?
I just hope someone else can re-open that ‘can of worms’ and ultimately explain what was going wrong and why dropping back the Teensy clock cured that problem.
I think Robert was using WS2811, but I have been seeing lots of weird worms on my end with APA102 flicker which changes nature when you change the CPU speed…just minutes ago I had CPU=24MHz and SPI=12MHz be the most stable, then when I tapped power in @ 1/2way point, I was suddenly getting nasty flicker until I changed the CPU to 72MHz…now its stable again… very strange! I promise that I will do a thorough analysis/blog write-up when I get my new logic analyser and my new APA102 modules which are on order!
-frenchy (Steve French)
http://www.voltvision.com
I would love to see an analysis of what is going wrong with an OC’d teensy, but glad to know that’s what the issue is! What a crazy bug.
Wow, really? Let the insanity stop!
I usually use 96MHz but have only used the Octo output not parallel. The only thing I’ve noticed is that the FastLED delay function is roughly doubled in duration when the Teensy is overclocked. Could it be that the timing of the parallel code needs some fine tuning with a 96MHz Teensy.
I’m glad that it worked for you, I’ll note that I always use 96Mhz for my teensy projects (why would I ever want to underclock? 
with parallel outputs, so I’m still curious what was causing the issue that you’re seeing. @Aaron_Liddiment when you say “delay function is roughly doubled” - what do you mean? (i.e. what does the timing end up being, do you have a test case, and could you please open an issue for this on the issue trucker at http://fastled.io/issues – throwaway statements in comments greatly reduce the odds of something getting looked at/fixed).
Sorry about that @Daniel_Garcia , I should know better having been a developer for over 30 years! It happened when I did a swap from Arduino delay function to FastLED delay. I will try and recreate it and report it if necessary on the issue tracker
@Daniel_Garcia I was fully expecting you to say “Oh well, if you overclock what do you expect?!” (Which would have been fair, I hasten to add!)
There is a small chance I might get back there with a multimeter before I leave town (though not a 'scope), is there anything interesting I could look at?
The FastLED delay function is fine on checking, it took longer due to quantity of leds (360) and temporal dithering was enabled! Brightness was set to 255 but am guessing it was still doing a refresh.
Yeah - and I haven’t yet put code in place for delay to figure out whether it should show or not (e.g. if it takes 30ms to write out a frame and you call FastLED.delay(15), it will write out a frame, which means it ends up delaying for 30ms instead of 15ms).