Hi all,
I’m trying to find a way to strobe the whole LED strip on and off at a fairly fast rate. I see the integer loops where 1 is added each time on some code, but that just makes them slowly light up one at a time. How would I go about lighting all my leds and blacking them all out in quick succession?
This could get your foot in the door:
void loop(){
fill_solid(leds, NUM_LEDS, CRGB::White);
delay(20);
fill_solid(leds, NUM_LEDS, CRGB::Black);
delay(20);
}
Go home @Jon_Burroughs , you’re drunk. 
fill_solid() requires a .show() after it to work. showColor() on the other hand does not:
void loop(){
LEDS.showColor(CRGB::White);
delay(20);
LEDS.showColor(CRGB::Black);
delay(20);
}
Alternatively, without a blocking delay, it would look like this:
volatile uint8_t style = 0;
volatile long lastRun = 0;
const uint8_t pause = 20;
void loop() {
if (millis() - lastRun > pause) {
if (style) {
LEDS.showColor(CRGB::White);
} else {
LEDS.showColor(CRGB::Black);
}
style = !style;
lastRun = millis();
}
}
@Ashley_M_Kirchner_No pros/cons for using the blocking delay instead of the time-diff switch?
Blocking delays stops your program for the duration of the delay. While in this particular case it may not matter, learning to program without using delay() will come in handy later on when you have a more complicated program that relies on other things, such as reading data from Serial at any given time, or interlacing reading from an SD card. Having delay()s will be disastrous in those situations.
Depending of the number of your leds you need more or less time to update them. My 256 led matrix (on one dataline) reaches ±120fps if I only call FastLED.show again and again without touching the buffer inbetween. So constantly sending a white and a black frame results in a <60Hz strobe effekt without any delay or counting values.
Probably it is just about POWER?! 
I would say arround 1 ms on, 99 ms off. Maybe place the leds on your closed eyes for a test. The strobes I know work between 5 and 50 Hz.
Clear YES! (If you have not too may of them on one data line.) WS2801 you can drive up to 400 Hz (you can drive them even faster but it makes no sense because they start to flicker), LPD8806 way faster.
About strobes again: a good studio flash has 1200 W output for a very short moment. Disco strobes are even brighter. So you would need A LOT of leds to simulate this effect.
Last note: If I had to create an strobe effect with leds I would go for stuff like this: http://www.alibaba.com/showroom/luxeon-10w-high-power-led.html For one ms you can drive them far beyond the specs.
@Ashley_M_Kirchner_No I’m pretty sure you educated me in the importance of non-blocking delay’s when I was first getting into Arduino and Fast LED. For the record, I was not drunk. Tipsy, but not drunk
Surely you can’t do strobe because the LEDs aren’t bright enough for the short time they are on. As @Stefan_Petrick says you’d need a huge number.
I get about 90fps out of my 288 strip of WS2812B LEDs — that’s with some calcs in between though they’re not serious enough to do any damage. When you figure that each LED takes 30us to write you realise that it takes 8ms or so just to write out the data to the LEDs — so the maximum frame rate for 288 can only be 125fps at the very most anyway.
Thanks to +Daniel Wilson and his “Lightning” code, I was able to tweak it to exactly what I needed. Code here:
#include “FastLED.h”
#define NUM_LEDS 300
#define DATA_PIN 6
#define COLOR_ORDER GRB
#define CHIPSET WS2812B
#define FREQUENCY 50 // controls the interval between strikes
#define FLASHES 8 // the upper limit of flashes per strike
#define BRIGHTNESS 200
CRGB leds[NUM_LEDS];
#define color White;
unsigned int dimmer = 1;
void setup() {
delay(3000); // allows reprogramming if accidently blowing power w/leds
FastLED.addLeds<CHIPSET, DATA_PIN, COLOR_ORDER>(leds, NUM_LEDS);
LEDS.setBrightness(BRIGHTNESS);
}
void loop()
{
for (int flashCounter = 0; flashCounter < random8(3,FLASHES); flashCounter++)
{
FastLED.showColor(CHSV(255, 0, 255/dimmer));
delay(25);
FastLED.showColor(CHSV(255, 0, 0));
delay(40);
}
}
or for the police strobe…
#include “FastLED.h”
#define NUM_LEDS 300
#define DATA_PIN 6
#define COLOR_ORDER GRB
#define CHIPSET WS2812B
#define FREQUENCY 50 // controls the interval between strikes
#define FLASHES 8 // the upper limit of flashes per strike
#define BRIGHTNESS 200
CRGB leds[NUM_LEDS];
#define color White;
unsigned int dimmer = 1;
void setup() {
delay(3000); // allows reprogramming if accidently blowing power w/leds
FastLED.addLeds<CHIPSET, DATA_PIN, COLOR_ORDER>(leds, NUM_LEDS);
LEDS.setBrightness(BRIGHTNESS);
}
void loop()
{
for (int flashCounter = 0; flashCounter < random8(3,FLASHES); flashCounter++)
{
FastLED.showColor(CHSV(0, 255, 100/dimmer));
delay(25);
FastLED.showColor(CHSV(255, 0, 0));
delay(40);
FastLED.showColor(CHSV(170, 255, 100/dimmer));
delay(25);
FastLED.showColor(CHSV(255, 0, 0));
delay(40);
FastLED.showColor(CHSV(0, 255, 100/dimmer));
delay(25);
FastLED.showColor(CHSV(255, 0, 0));
delay(40);
FastLED.showColor(CHSV(170, 255, 100/dimmer));
delay(25);
FastLED.showColor(CHSV(255, 0, 0));
delay(40);
FastLED.showColor(CHSV(0, 255, 100/dimmer));
delay(25);
FastLED.showColor(CHSV(255, 0, 0));
delay(40);
FastLED.showColor(CHSV(170, 255, 100/dimmer));
delay(25);
FastLED.showColor(CHSV(255, 0, 0));
delay(40);
}
}
My eyes … my eyes. So many delays()!
@Ashley_M_Kirchner_No Hahaha, I’m not understanding what exactly the volatile, style, and millis mean just yet in your code!
@J_Bonner check this out to understand the millis magic: http://arduino.cc/en/Tutorial/BlinkWithoutDelay
volatile: The compiler will always try to optimize your code when you compile it. For example, if I were to write:
uint8_t foo = 100; // I’ll explain INT vs uint8_t later
while (foo == 100 {
// call bar
}
If the compiler sees that the program its currently compiling never tries to change the value of foo, it can potentially optimize your code into:
while (true) {
// call bar
}
That may or may not always be true. There may be an external program that the compiler does not know about that will be changing the value of foo. So, by declaring it a volatile, the compiler will leave it alone and knows that the foo variable can at some point change (even if ultimately it never does. It’s called being in control of what the compiler will do with your code so it doesn’t eff it up.)
In my previous example, notice how the variable pause has been made a constant because it won’t ever change. On the other hand, if it will (like some of my programs do), then you’ll want to declare it too as a volatile.
style: That’s simply a variable that’s holding the flip-flop value. When it’s 0, all the LEDs will be off (Black), and when it’s 1, the LEDs will be on (White). This can be extended to hold multiple cases, it doesn’t have to just be a flip-flop.
style = !style is what reverses it. Remember, binary is either 1 or 0. So if I start off with style = 0, the next loop it’ll be 1, next loop flips it back to 0, etc., etc. (This will change if you need more than two states, ON or OFF.)
millis(): That’s the Arduino’s internal timer. It’s a millisecond value from the last reset, starting at 0 and counting up to the value of unsigned long (4,294,967,295). After that it rolls over to zero and start over. Assuming accurate time keeping, that comes out to roughly 49.7 days (1,000 ms per second, 86400 seconds in a day)
By using the timer difference, you can control when something happens without needing to or having to completely block your program with a delay. Imagine if your DVR started recording a program and it knew to stop after exactly 60 minutes. If you used a delay(60 * 60 * 1000); , nothing else could happen during that time, in fact it wouldn’t even record because in order to do that, it needs to be able to control the feed, write data to the disk, buffer the next piece, write to disk again, over and over again. While also updating the display, and possibly also waiting for a command form the remote control since you decided to record one channel but watch another. None of that would be possible with a blocking delay(). A timer difference on the other hand will continue to run everything ELSE in the program and will not trigger a stop till it reaches a check that says, hey it’s been over 3600 * 1000, it’s time to stop the recording. Make sense?
Lastly, uint8_t: The Arduino INT is 16-bit value (2-byte) - I’ve seen instances where INT was defined as a 32-bit value. However, in many cases you don’t need a value that big. Especially for things like FastLED, where all the LED values are from 0 to 255 which can easily fit in an 8-bit (1-byte) container. So rather than using the default INT (or uint16_t), I generally use uint8_t as that limits the value to between 0-255 (int8_t is -127 to 126, notice the difference between int8_t and uint8_t). When you start optimizing memory usage, why allocate 2 bytes for numbers that will fit in 1 byte? This will come in very handy when you start writing large® programs where you start dealing with memory constraints.