Color Holiday Twinkle Lights After all the discussion yesterday,

Archive FastLED Archive
,
1

Color Holiday Twinkle Lights
After all the discussion yesterday, I put together a ‘twinkle lights’ sketch that can use any colors you wish. It’s preloaded with some holiday color schemes to get started:: red&white&green, blue&white, ‘snow’, rainbow, and an approximate color match for incandescent ‘fairy lights’.
Code is here: https://gist.github.com/kriegsman/5408ecd397744ba0393e

The theory of operation is similar to the ‘warm twinkles’ posted here yesterday: https://plus.google.com/112916219338292742137/posts/ScvWcDq1rC5 Each pixel is either black, or it’s brightening up, or it’s darkening down. A separate array called ‘directionFlags’ is used to track whether each pixel should be brightening or darkening.

For illustration purposes, two different implementations of directionFlags are provided in the code. One is simpler but uses up a full byte (8 bits) of memory for each pixel’s direction flag, even though only one bit is needed. This makes each pixel take up 32 bits (24 for the color itself, and 8 for the direction flag).

The second implementation of directionFlags is more complicated, but much more compact: it uses just one BIT of memory for each pixel’s direction flag. Every eight pixels’ flags are packed into one 8-bit byte of RAM. With this implementation, each pixel takes 25 bits total: 24 for the RGB color, and just 1 for the directionFlag.

Yesterday’s implementation ‘hid’ the direction flag in the low bits of the red color channel. This code doesn’t try anything quite that tricky; it gets more difficult if you want to allow any color. Having a separate array of flags simplifies things here.

It’s also worth noting how that brightening and darkening work. Darkening is relatively easy: the three color channels are each reduced by a fraction using nscale8. The brightening takes two steps: first it calculates a fraction of the existing color (again, using nscale8), and then adds that onto the existing color. So provided that the values already in the color are bright enough to have the right hue, this brightening technique works reasonably well. There are cases where it won’t work well, and the hue you wind up with isn’t exactly the hue you were shooting for, but given that it required zero additional RAM, it’s a good option to explore.

Finally, you can make your own sets of color palettes, or write a different mechanism entirely for choosing new colors. Because of the way the colors are chosen and then set for each pixel as it’s ‘lit’ up, there’s a nice cross-fade between the different palettes.

Earlier, Simon Hermansen posted some good code that did something similar. (http://paste.ofcode.org/4t6xQA7DDwbaHaGFtd934j) Visually, the effects are similar, and his code is clear and easy to read. The big difference is that that code requires 56 bits per pixel vs. this code’s 25; the practical upshot of that is that this code can drive more pixels from the same microcontroller before it runs out of RAM. I provided the two implementations of directionFlags to illustrate the trade-offs between code simplicity and memory compactness.
http://www.youtube.com/watch?v=MGHPEwH3eI0

2

I like twinkle lights. . .

3

That’s why we’re all here, innit.

4

Mark K, thanks for this! My wife wanted me to make a string of lights for a door decoration thing at work, and this fits the bill perfectly, without having to do any heavy lifting myself. (: When she wakes up, I’ll see if she wants to stay on a single palette or cycle between a few, or even maybe make my own! (:

5

I think I’m going to use this with a button for wife/tasteful mode.

6

LOL, I like the term “wife mode”. http://www.gadstone.ch/images/product_images/original_images/panic_button_3_63_0.jpg

7

I prefer to think of it as “mellow mode” vs “rave mode”. Alternatively, I sort of think of the crazy mode as “New Year’s Eve”. Having multiple built-in modes is super useful.

The hand-lanterns that I brought to the playa this year actually had four modes:

  • fire: because lanterns need fire inside
  • mellow: slow & mesmerizing
  • rave-y: wild, fast, & bright: because )’(
  • useful tent light: solid warm white

It was very useful to have a couple of different modes built in that could be toggled in under a second, while already field-deployed, by just using a push button (and not a laptop).

The other thing that I’ve found to be very useful and super simple is this: make a Brightness knob. Attach a single potentiometer to an analog input pin (say, pin A3) of your Arduino. Then in your loop() function, add this one line:
FastLED.setBrightness(analogRead(A3)/4);
BAM! Instant brightness control for the whole project.

If you’re feeling ambitious, add two knobs: brightness and speed. Hint:
FastLED.delay(analogRead(A4)/8);

We often build these things for other people, or to be deployed in an area shared with other people (eg family, friends, coworkers). I’ve found that the more you let the other people have simple control (a button, a knob) over the effects, the happier they are to share the space with the new luminous creation. Plus, it lets them have some fun playing with it, too!

8

I am tinkering with the same at the moment. I found that a minimal user interface needs 2 buttons: mode and +. Mode to select programm / brightness and + to step forward. Brightness in just 4 available steps. A 3 button interface is already convenient: mode, + and -. For more complex interaction I used the modes pgm, speed, bri, palette, r, g, b and reset at the moment. It is just difficult to keep track, where you are. So I probably need to add one led indicating by color in which menu I am basically. Working on a minimal but good solution. And on a master speed control for everything.

9

This is one of those times when sometimes a knob or two can greatly simplify things. The other example I always think of is car stereo volume controls: while I’m driving, I just want one big knob I can turn without looking.

10

I agree completely! A long time ago I tryed this one big knob thing with a rotary encoder. Difficult timing. When I had it working, the thing was already too dirty inside to work properly. Next attempt: just one potentiometer and mapping the 10 bit down to five values / modes. Result: It happens often to stop exactely “between” 2 steps. So I started debouncing my 5 values. Paid it with a high reaction latency or a swinging system.
The perfect solution still needs to be developed…

11

Looking good. I need to make a video of my xmas lights. I am giving xmas lights light this for presents this year. I diffuse my pixels with ping pong balls though. I just have a one button interface. You can select a single pattern or have it cycle through all the patterns and using the eeprom you can power it off an on and it will remember where it was.

12

Nice use of EEPROM! That’s great. Would love to see the video and whatever code you can share, too!

13

You know, it occurs to me now that with this basic per-pixel-autonomous fade-in-fade-out infrastructure, we could do all kinds of patterns on top of it, e.g., have patterns of ‘triggering’ other than just random. I mean, of course, right?, but this makes me want to package that infrastructure up, hide the details, and start building on top of it.
Long-time readers may sense a pattern here.

14

I actually use an extra array to hold hue and brightness so that I can adjust the brightness up and down. I use odd brightness values to indicate going up and then even values to go down. I use this in most of my patterns nearly all the time. I just call a fade function that checks the brightness value and adjusts accordingly and then set the Hue.

Just made me think of a cool option to change the hue color as it fades up and then back… So perhaps the pixel starts red and brightens to yellow and then back to red!

15

And if I saw your code correctly Mark I think you were using the Sat value to do up and down on the fading?

16

Idea: just store a single byte, and have that be an index into a palette. Then you can have the palette do whatever you like…

And just use map_data_into_colors_through_palette to transform from the byte values into RGB leds.

Ok, now I have to do this. :slight_smile:

17

I don’t think I used SAT for fading. I just scaled the existing color up or down.
I basically did darkening thus
pixel.nscale8(255-darkening);
and brightening thus:
temp = pixel;
teml.nscale8(brightening);
pixel += temp;

18

I may have missed this in a previous post, what kind of LED’s are those? They seem like ready made Christmas lights with the diffuser and nice white wire.

19

These particular ones are WS2811 pixel nodes with “C9” diffusers. I got them here:
http://www.aliexpress.com/store/701799/search?SearchText=C9

20

I’ve been having fun this last hour attaching pots for speed, brightness and now also DENSITY!

The delay is a bit unintuitively biased - most of it being the slow part - do you already have a non-linear multiplier that you use to make it more natural seeming?

I now understand the brightness 4096/4 right?.
The same for density works well.

I have to say, that I’m so used to programming Android interfaces, I’m really enjoying the hands-on hardware interface! It’s a 16 button pad I’ve had for ages to do the pattern select now…