A couple of months ago, some nice guys of the IFISC (Institute for Cross-Disciplinary Physics and Complex Systems) contacted me. They saw the Synchronizing Fireflies and wanted them to demonstrate how simple rules can make patterns emerge from chaos. The main research of the institute is in Nonlinear Physics and Complex Systems.

But why would they want electronic gimicks? Every year, there is a science fair, the “Fira de la ciència” in Palma de Mallorca. The fair is aimed at young students, to introduce them to science with many hands-on projects and experiments. The IFISC is part of this fair and decided to use my fireflies as a demonstration of self organizing systems for one of their projects.

It took a while to figure out how to present the fireflies best. Here are two pictures of the palm tree to which the fireflies are tied. Great idea and it came out really beautiful.

For the fair they built a small cubicle with the palm tree inside. The cubicle was neccessary because the fireflies need an almost pitch back environment to see each other flashes.

As the fair was at Palma de Mallorca, I couldn’t resist to see it in person. Last week my girlfriend and I took some days off and travelled to Mallorca. We visited the fair and met some really nice staff members of IFISC. And there it was, a tiny black cube with a palm tree and fireflies within. Wohoo!

After all I have to say thank you all so much for the warm welcome and showing and explaining all your projects. Thanks for the cool t-shirt, I feel almost as a IFISC member now
And especially thanks to Pep for pushing this project further and further and making it possible. It has been a fantastic experience. You guys rock.

Links

• 64 Synchronizing Fireflies
• Synchronizing Firefly Kit
• Some more videos of the test setup, done by Pep
• IFICS (Instituto de Física Interdisciplinar y Sistemas Complejos)
• Fira de la ciència

It’s Advent season. And what do you do to let your geek shine? An LED Advent wreath of course.

The idea came to me after seeing Sprite’s minimalistic version of the Hackaday’s Flickering LED circuit. It’s a simple circuit that flickers LEDs and detects darkness. I thought that this could make a great little Advent wreath. My version should have 4 LEDs and should be support first, second, third and fourth Advent.

Parts and Schematic

The parts list is rather short:

• ATtiny13V, 8-bit microcontroller, 1k flash RAM, 64 bytes SRAM
• 4 * 3mm LEDs, yellow or orange, forward voltage ~ 2.0 V
• CR2032 coin cell, 3 V, 230 mAh
• Paperclip

There are no current limiting resistors in this circuit. Normally operating LEDs without them is not advisable because the LEDs will get damaged. But under certain conditions the resistors can be left out. For more on this topic, see Sprite’s computation or mine here.

How does it work

The nice thing about this circuit is, that it needs no special components to detect darkness. It uses an LED for that. An LED is also a photodiode that can detect light of the same wavelength it emits. See here for more details. Sprite used an available ADC of the ATtiny13 instead of the “Reverse Bias” method.

Software

The software is heavily based on Sprite’s version. Things I’ve changed:

• Added support for four LEDs.
• Removed calibration, replaced with hard wired values.
• Added a bit sampling to the light measurements, because the values were a bit erratic.
• Added a mode for first, second, third and fourth Advent, stored in EEPROM. Gets incremented at every reset.
• Modified the watchdog code a bit to keep it generating interrupts instead of resets.

After power up, the watchdog gets enabled to generate an interrupt every two seconds. Then the current mode (0-3) is read from EEPROM, incremented and stored back. Then the endless loop is entered, where random values are used to flicker the LEDs. The ISR checks the ambient lighting and if it is higher than a certain level, sets a sleep flag. This flag is monitored in the main loop. If set it sends the controller in to power down mode to save battery power. The next interrupt will wake up the main loop.

Assembly

This circuit is soldered in “free form”, so no PCBs. It takes some time to get it done but it’s worth it.
All cathodes of the LEDs are connected to form the ring. The anodes are bent inwards to be soldered to pin 2, 3, 6 and 7 of the ATtiny13. A short piece of wire is connected to the common cathode and soldered to the GND pin.

The microcontroller lies “dead bug” style on the coin cell. The GND pin is bent to the top, now connecting to GND of the battery. The VCC pin is bent to the bottom and soldered to the coin cell holder. The coin cell holder works as a clip, pressing the microcontroller onto the cell.

Some random notes:

• Be patient.
• Use as less solder as possible.
• Don’t heat the pins of the controller for too long.
• Be gentle while bending the controller pins. They come off easily. I added a tiny bit of solder.
• BE patient

The Result

If you make one, please let me know. Send me a picture or post it on the tinkerlog flickr pool.

Happy third Advent …

Downloads and Links

• Source advent.zip
• Minimalistic flickering LEDs at Spritesmods
• Flickering LED circuit at Hackaday
• LED Menorah, also free form at Evil Mad Science

Niklas did an amazing job, letting fireflies play some tunes. It’s almost as if they are alive.

Niklas, I owe you a beer (or Club-Mate or whatever), should we ever met. You made my day!

Last week I invested some time to solder 64 Firefly boards. Only 2.432 solder joints later I was ready for some videos.

Every firefly acts completely autonomously, it has its own tiny controller, eye and luminary. They are all connected for power supply only.

Here are some different configurations.

Links

• See how it’s done in the Synchronizing Firefly Howto
• Grab a Firefly kit at the Tinker Store

If you read about LEDs, you will notice that everyone tells you, that you need a current limiting resistor. But mostly they do not tell you why.

LED with current limiting resistor

If you look at a datasheet of an LED, you will notice that graphs shown are not linear. An LED is a diode, a semiconductor and behaves differently compared to a resistor.

If you apply a specific voltage to a resistor, you can compute the resulting current with:


I = V / R Example: I = 5 Volt / 100 Ohm = 50 mA


Obviously that does not work with LEDs because they don’t behave like a linear resistor. If you look at the graph above, you can rise the voltage from 0 Volt to 1.6 Volt without resulting in noticeable current. Apply a bit more voltage and there is current and the LED lights up. We have reached the Forward Voltage which is needed to open the pn-gate. Forward Voltage (VF) for a typical red LED is 1.7 to 2.2 Volt. Now small changes in the voltage produce large effects on the resulting forward current (IF). Datasheets normally state at least the absolute maximum ratings for IF, eg. 25 mA. If you apply a voltage that results in a larger current, the LED may be destroyed.

So it’s vital to stay within the limits of the LED. If you would attach an LED to a 5 Volt power supply directly, you would burn it instantly. The high current would destroy the pn-gate. That’s the point where the current limiting resistor comes in.

Assuming, we have a red LED with maximum rating of IF: 25 mA at VF: 2.1 Volt. Its VF related to IF is like the curve in the graph at the top. If we want to use it at 5 Volt, we have to use a resistor to dissipate the remaining 2.9 Volt. To compute the resitor, we use:


R = V / I = (5 Volt - 2.1 Volt) / 25 mA = 116 Ohm.


To be safe we use a 120, or better, 150 Ohm resistor. That way we don’t drive the LED near it’s maximum rating. We choose 20 mA, take a look at the curve and see a corresponding VF of 2 Volts. Now we recalculate the resistor.


R = V / I = (5 Volt - 2 Volt) / 20 mA = 150 Ohm.


Ok, 150 Ohm is fine. To be safe with the resistor, we have to take a look at the power dissipation. It calculates as:


P = V * I = 3 Volt * 20 mA = 60 mW


So it’s safe to choose a 150 Ohm resistor with 1/4 Watt rating.

Ok, so far the typical use of an LED with an current limitting resistor.

LED without current limitting resistor

First of all, why would you want to get rid of the resistor? There are two reasons. First is, it wastes energy. It converts electrical energy into heat. But we want to light up an LED. Not good. Second is, you can reduce the number of components. The circuit gets cheaper, because we saved a resistor and maybe space on a PCB.

There are two ways to bypass the resistor. One way is to lower the input voltage. If you are able to run your complete circuit with the same voltage as forward voltage of the LED, perfect. No resistor needed.

Another method is to use pulse width modulation (PWM). That means we are switching the LED on and off. If we are switching fast enough, the human eye can not tell the difference. It integrates the brightness over time, so to speak. Often there is a Peak Forward Current (IF(peak)) rating in the datasheet. As an example:

IF(peak) = 160 mA
Condition: Pulse Width <= 1 msec and Duty <= 1/10

Which means, it is safe to switch the LED with 1 kHz, where the LED is on for 0.1 msec and off for 0.9 msecs.

Most of the times there is no voltage given for IF(peak), so we can not be sure at what voltage we will reach the 160 mA in the example. Looking at the graph, I would assume that you could go up to 3 V, maybe 3.2 V, but I haven’t tested it out.

I used both methods for my 64pixels, where I attached an LED matrix directly to a microcontroller without any current limitting resistors.

The input voltage is 3 Volts, if used with 2 AA batteries or about 2.4 Volts with 2 AA rechargeables. That helps to get closer to VF of the LEDs.

The matrix lets you address only one row at a time. So you set all column bits for row one and enable row one. Then you disable row one, set all bits for row two and enable row two, and so on. So you are cycling through all rows. This is done so fast, that you wont see any flickering. Every row is updated with nearly 2 kHz and with a duty cycle of 1/8 (because of the 8 rows).

If you are using a microcontroller for driving an LED or LED matrix, you have to take care of the current ratings of the microcontroller as well. Every I/O pin can only deliver (source) or receive (sink) a specific amount of current. I used an ATtiny2313 and from the datasheet on page 181, I read

Absolute Maximum Ratings:
* DC Current per I/O pin: 40.0 mA

And on page 182 as a note:

4. Although each I/O port can sink more than the test conditions (10 mA at VCC = 5V, 5 mA at VCC = 3V) under steady state conditions (non-transient), the following must be observed: 1] The sum of all IOL, for all ports, should not exceed 60 mA. If IOL exceeds the test condition, VOL may exceed the related specification. Pins are not guaranteed to sink current greater than the listed test condition.

As I understand that, if you are trying to source or sink more than 10 mA, the voltage VOL (Output Low Voltage) or VOH (Output High-voltage) may drop or rise and exeed the specified values.

Looking at two graphs from the datasheet may help to clear things up.

This figure shows how the output voltage of a source pin is related to the current that it sources at 2.7 V input voltage. 2.7 is not 3 Volts as 2 AA cells can deliver, but close enough for now. What we see, is that the output voltage drops, if we demand more and more current. At 5 mA we have a voltage of 2.5 Volts, but at 15 mA the voltage drops to 2.1 Volts.

This figure shows how the output voltage of a sink pin is related to the current that it sinks. This time the ouput voltage rises, if we demand the pin to sink more current. At 5 mA the voltage is 0.15 Volts but rises to 0.5 Volts at 15 mA.

To check if we are using the ATtiny2313 and the matrix within their specifications, we have to do some math. For the matrix, there is no datasheet with nice graphs but some numbers.

Forward Voltage: 1.80 – 2.20 V
Maximum Rating: Forward Current: 25 mA

We assume the LED runs at 1.8 Volts with 5 mA. That looks reasonable when you take a look at other datasheets. Now, if we insert the 5 mA into the two figures above, we get: 2.5 Volt for the source pin and 0.15 V for the sink pin.


2.5 V - 0.15 V = 2.35 V


So we get that 2.35 V is left for the LED. That is more than we have assumed (1.8 V). Higher voltage for the LED means more current. So this time we will compute with 10 mA. Inserting that again, we get 2.3 V for the source pin and 0.3 V for the sink pin.


2.3 V - 0.3 V = 2.0 V


As you see, if the voltage over the LED rises, the current through it raises as well. But the rising current results in lower/higher output voltage from the source/sink pin. And that means lower current. It is, as if they are fighting each other.

2.0 V at 10 mA looks ok for the LED and the microcontroller.

That was one LED on two I/O pins. What, if we want to control a complete row of eight LEDs?

This time eight source pins, eight LEDs and one sink pin. From the example above, 10 mA per LED sums up to 80 mA (!). That’s a lot. Looking it up on the figure is not even possible. Lets assume, it all sums up to only 25 mA, that would be 3.125 mA per LED. That gives us 2.6 V at every source pin and 1.0 V for the single sink pin.


2.6 V - 1.0 V = 1.6 V


That means, 1.6 V is left for every LED, we are a bit beneath the forward voltage of the LED. So the LED may be a bit dimmer. Again, if the LEDs would suck more current, the microcontroller would deliver less output voltage for the LEDs.

If you look thoroughly at the 64 pixels display, you may notice, that the rows with few pixels lit are a bit brighter than the others.

After all this computing and datasheet staring I think it is safe to let out the current limiting resistor in some cases. You have to take a closer look at specs to get an idea on how it will work out.

If I get something wrong or mixed things up, please feel free to comment on this.

Links

• Datasheet for Atmel ATtiny2313
• Wikipedia: LED

I love Blinkenlights. And all kinds of other blinking and flashing LED stuff. I think, it’s already a form of addiction. When I ran across an LED matrix with square pixels, I thought it would be cool to build a small animated display with it. To keep things simple, the display is attached directly to the microcontroller the “Evil-Mad-Scientist-way”.

The display performs really well, the pixels are bright and the batteries last for over two weeks running non-stop. The microcontroller has 2 k flash RAM. That’s enough for three simple animations and a couple of messages.

If you want to see the guts, then follow me to the 64pixels howto.

And grab a 64pixels kit from the Tinker Store, if you want to build your very own.

Lately I was playing with my dual color LED matrix from Sparkfun. It is a matrix of 8 by 8 dual color (red and green) LEDs that measures 5 cm by 5 cm. I just had some sprites flickering across the matrix as the magnifying glass of my “third hand” came in the way. I realized, that, if in the right distance, it will project the sprites on the ceiling. Although the projection is not very bright, it works, if the room is dark enough. Disco, here I come.

Materials

So here is, what you need to build one:

• Arduino, Boarduino from Adafruits for the breadboard
• Dual color LED matrix from Sparkfun
• 2 * 74HC595 shift register
• 1 * ULN2803 darlington sink driver
• 16 * 100R resistors
• 1 * 10kR potentiometer
• magnifying glass

Schematic

The matrix is orgranized in 8 rows and 16 columns (8 red and 8 green). To address a single LED in the matrix, you have to set one of the 16 column bits and enable the coresponding row. Note that there is always only a single row active. If every row is activated fast enough, a steady picture comes into being. The shift registers are used to provide column data. 16 bits are are loaded serially and put out parallely.

The rows are handled by an ULN2803, an array of darlington transistors. This chip is used to sink the current of the activated row. If every LED in a single row is activated, the current for this row will sum up to 320 mA (16 * 20 mA). Definately too much for a single pin of a microcontroller. The ULN2803 is able to sink up to 500 mA per channel and cheap (about 30 euro cent).

Software

To generate a steady picture, we have to provide 16 bit of data, at least every 2.5 ms  (50 Hz * 8 rows). For this purpose the timer 2 of the ATMega168 is used. This timer normally controlls PWM channels 3 and 11 for Arduinos, so they are no longer accessible. The ISR (Interrupt Service Routine) for this timer takes the 16 bits for the current row and shifts them out. Next time it is called, it will output the data for the next row. Take a look at the great uc Hobby tutorial on Arduino interrupts for more details.

The sprites are organized in 8 bytes (8 * 8 bits). So every sprite can cover the whole matrix for a single color. The screen memory is organized as 16 bytes, 8 bytes for red and green. That way you can print a sprite in red or green. If you print it in red and green, the result is orange.

To control the sprites, I hacked a tiny script language. The scripts are arranged in small sequences. Every sequence consists of commands of one or two bytes. Available commands are:

• select page (none, red, green, orange)
• select sprite
• move sprite (up, down, left, right)
• print selected sprite and selected page
• sleep
• call sub sequence

With the possibility to structure commands in sequences and subsequences it is possible to create more complex animation as with simple frame by frame animation. That may be handy if the memory is limited as it is for the ATMega168 with 16kB SRAM.

Demo

As you can see, the projection is not bright enough to show up on my camera. So I had to switch to “night mode”. That worked but lacked the speed of the animation. It looks much better in real.

Links and downloads

• Dual color LED matrix at Sparkfun
• Arduino interrupt tutorial at uc Hobby
• Arduino 74595 tutorial
• Source sketch matrix.zip

Update 04. Dec. 2008: This article is replaced by the new howto.

This is a remake of the fireflies which I did a year ago. I was always fascinated by the emergence of patterns. One I like most is the synchronization of hundreds or thousands of fireflies. First they flash randomly but after some time and influencing each other, they flash in sync.

This circuit simulates fireflies with small microcontrollers. Note that every firefly acts completely autonomously, it is not a preprogrammed pattern. It is a self organizing system.

The NG version uses a small PCB (Printed Circuit Board) and a RGB-LED.

Software

Each firefly has a value that stands for the power to flash. This value rises over time. If the power reaches a certain limit, the firefly flashes and the power is reset to zero. If the firefly detects another flash nearby, it increases the power by a small boost value. That way it will flash slightly earlier than last time. Doing so over and over again may lead to all fireflies flashing in sync.

The RGB-firefly uses color to express its mood. If all is in sync, it will flash in relaxed and cool blue. If it detects flashes that are not in sync, it will get a bit uncomfortable and the color will slightly change to green, yellow and red.

The circuit

The circuit is rather simple. Main parts are the microcontroller, the light sensor and the RGB-LED. The sensor and R4 are forming a voltage divider. An ADC (Analog Digital Conversion) channel at pin 3 is used to read the values of the sensor. The circuit is designed for 5V power supply. It has no integrated power regulator.

Parts

Here are the parts, that are needed for a single firefly.

• Firefly PCB
• ATtiny13v, digi-key
• RGB-LED, 4000 mcd, generic
• 8-pin socket, generic
• 3 * 100R resistor, R1, R2, R3, generic
• 1 * 4.7kR resistor, R4, generic
• Photoresistor (LDR), 4k to 11kR
• pin header and socket (used for power supply)
• ping pong ball

Various types of photoresistors exist. I tried two different versions and both work well. Only resistor R4 has to be adjusted, as R4 and the photoresistor are building a voltage divider. Choose R4 in a way, that gives you a good range of voltage and still limits the current through the photoresistor.

My latest experiments showed that a phototransistor seems even better suited. Compared to the LDR, it does not have a memory effect and reacts faster (~5ms compared to ~50ms). I chose the SFH 3310 and 100k for R4.

One thing to remember while choosing a light sensor, is that the spectral sensitivity of the sensor has to match the humans eye sensitivity (~400 nm – ~700 nm).

Solder it

First solder the power connectors. Having a female and male connectors on the boards makes it easy to power a couple in a row.

Next insert the resistors. R1-3 are 100R, R4 is 4.7kR (depends on the sensor).

Solder them.

Cut off the legs.

Next insert the 8-pin header for the controller. Note that the notch of the header points up.

Solder the header.

Next insert the LDR. For the LDR the orientation does not matter. For the phototransistor it does! The phototransistor has a long (emitter) and a short leg (collector). Insert it with the long leg at the bottom. And solder it.

Now prepare the LED. Mine are clear and have a lens on top. Use sandpaper to roughen the surface. That way the light of the LED will be emitted in all directions.

The RGB-LED has four pins. Mine is a common cathode.

1. green (short)
2. blue (longer)
3. GND (longest)
4. red (shortest)

Bend the two inner legs a bit off.

Insert the LED. Be sure to have pin 1 in the hole with the square solder pad. The longest leg is in the diagonal opposite corner. Now solder it.

Now it should look like this and we are almost done.

Drill a 4mm hole in the ping pong ball. Use a file to widen the hole a bit. Try to put it on the LED.

Program the controller and insert it into the socket. Take care of the notch.

Here is the final result, the first firefly. Ready for some action.

Issues

There are minor issues that I want to have fixed for the next batch of PCBs.

• I will make the PCB a bit larger to make it more stable.
• The circuit is missing bypass capacitors (100nF and 100uF). It works great without but it’s best practice to have them.
• The sockets for the power supply are not protected against polarity reversal. Not quite sure how to fix this.

Conclusion

Playing with these fireflies is really mesmerizing. It’s not like most computer controlled things because it is non deterministic. Every time you start it, it will produce new patterns and behave differently.

I am quite happy how well the PCB worked out. It was my second design that I have had produced. Now I am feeling confident enough to go for a bigger batch of PCBs.

Downloads and Links

• Buy a kit at the Tinker Store
• Source and schematics (Eagle) rgb_firefly.zip
• Phototransistor SFH 3310 Datasheet
• Synchronizing Fireflies (first version)
• Synchronizing Fireflies (at Instructables)

This is a new version of my Tengu clone. This time on a printed circuit board (PCB). I have them produced by Olimex and I am very pleased with the quality. The PCB worked on the first try and has some minor issues only.

Materials

• Tengu PCB
• Everlight 8*5 LED dot matrix
• ATmega48, 4kB Flash RAM, 512 bytes RAM
• 4 MHz crystal
• LM386 Op-Amp
• 28 pin header
• 8 pin header
• 2 * 22pF capacitors
• 3 * 100nF capacitors
• 10k potentiometer
• 100k potentiometer
• 100k resistor
• 5 * 1k resistors
• 2 * 7 pin header sockets
• 2 pin headers for power supply and microphone (optional)
• Electret microphone (not on the picture)

Note, that the electret microphone has a polarity. On the PCB the inner pin is the positive one. If you connect it the wrong way, it is heating up really quick.

The microphone that I used here has an impedance of 2k. You may have to experiement a bit with different microphones.

The capacitor C2 is used to control the amplification of the LM386. I used 0.1uF but you can use up to 10uF to get a stronger amplification. Here is the amplifier circuit that I used.

PCB design issues

As this is my first design, there are a couple of things that I would redesign.

As I tried to insert the pin header sockets, I realized that the drill holes were a bit too narrow. You have to use a bit of strength to insert the headers, but it works.

All solder pads used for resistors and capacitors are a bit too small. It was a bit difficult to solder them. I would make them a larger next time.

I think I should use a bit less of the silk layer. Some solder pads are covered with silk. Most of the time that does not hurt as it is on the top side. But there are pins that you may wont to solder on the top side, e.g. the power connector.

Improvements

The component count could be reduced if I had dropped crystal. For the animation of the LED matrix the internal oscillator would be sufficient. On the other hand, with a suited crystal, this circuit could be modified to display the time.

I would add an ISP (in system programming) header for easier programming. Now you have to flip off the display, take out the controller, program it, re-insert it and put the display back in place. Not a fast turn around if you want to modify the firmware.

What would you think of an Arduino version of this circuit? The controller could be replaced with an Arduino compatible ATmega168. Or maybe as an Arduino shield?

Conclusion

It is great to see your first produced PCB. Even better if it works on the first try. Maybe I can even build a kit out of it with the next revision of the board.

As I have still two boards left, you can email me at alex at this domain and I will send you the PCB for free. The only requirement would be, that you really want to build it and that you give me feedback on how it worked, what you would change or how you modded it.

Links and Downloads

• Crispin Jones Tengu, the original idea of this device
• Mini Amplifier with LM386
• Tengu clone on prototype board
• Tengu clone on a breadboard
• tengu-clone-rev-1.0a.zip source and Eagle schematics

More at Flickr.

As a demo, I built a “nervous” BlinkM. It is getting nervous, if something moves in its view. And the more it moves, the more it gets nervous.
It consists of my Boarduino clone, a Sharp GP2D12 range sensor and a BlinkM. The Arduino reads the range of the range sensor and computes a value for the nervousness.

Talk to the BlinkM

Interfacing an Arduino with the BlinkM is easy as the BlinkM comes with lots of sample code. You just have to copy an include file (BlinkM_funcs.h) and place it beside your Arduino sketch and include it. All the I2C stuff is taken care of.

After initializing the BlinkM you can send commands to it. You can, e.g.

• fade to a color, defined by RGB
• fade to a color, defined by HSB
• set fading speed
• write a script
• play a script

Code

My two sketches are really simple. One changes the color, the other changes the frequency. Here is the code for the first one.

/*
 * Nervous Blinkm
 * Change the color depending on range changes
 * 2008/03/14
 * http://tinkerlog.com
 */

#include "Wire.h"
#include "BlinkM_funcs.h"

#define RANGER_PIN 3              // pin for the sharp gp2d12 range sensor
#define DELTA_THRESHOLD 10        // threshold for the range sensor
#define MAX_RANGE_CHANGE 50       // max range change that can be detected
#define CALMED_HUE 172            // hue value for calmed state

int blinkm_addr = 0x10; // the address we're going to set the BlinkM to
int distance = 0;
int oldDistance = 0;
int nervous = 0;
int delta = 0;
byte i = 0;

void setup() {
  BlinkM_begin();
  BlinkM_setAddress(blinkm_addr);
  Serial.begin(19200);
  byte rc = BlinkM_checkAddress(blinkm_addr);
  if (rc == -1) {
    Serial.println("rnno response");
  }
  else if (rc == 1) {
    Serial.println("rnaddr mismatch");
  }
  BlinkM_stopScript(blinkm_addr);
  BlinkM_fadeToHSB(blinkm_addr, CALMED_HUE, 0xff, 0xff);
  BlinkM_setFadeSpeed(blinkm_addr, 0x10);
  nervous = 0;
}

void loop() {

  // do 4 samples of the distance to reduce the jitter of the range sensor
  distance = 0;
  for (i = 0; i < 4; i++) {
    distance += analogRead(RANGER_PIN);
    delay(10);
  }
  distance = distance >> 2;
  Serial.print("distance: ");  Serial.print(distance);

  // compute the distance change
  delta = min(abs(oldDistance - distance), MAX_RANGE_CHANGE);
  // sum up (only if delta is noteable)
  nervous += (delta > DELTA_THRESHOLD) ? (delta - DELTA_THRESHOLD) : 0;
  if (nervous > CALMED_HUE) {    // limit the nervousness
    nervous = CALMED_HUE;
  }
  Serial.print(", nervous: ");  Serial.println(nervous);

  // In HSB the hue 172 stands for blue and 0 stands for red.
  // So subtracting the nervous value of the initial hue (blue) results in:
  //   "more nervous" --> "more red"
  BlinkM_fadeToHSB(blinkm_addr, CALMED_HUE - nervous, 0xff, 0xff);
  oldDistance = distance;
  nervous = nervous * 0.9;       // reduce the nervousness with every cycle
  delay(50);
}

Demo

Unfortunately it is not possible to combine the two sketches into one to control the color and the frequency.

Conclusion

The BlinkM is a cute little circuit. It has some computing power on its own and a real bright RGB LED. It is easy to program and you don’t have to bother about PWM. You can even script it. On the other hand it could get pricy if you want to make something that needs more devices than a hand full.

Links

• BlinkM
• ThingM, the makers of BlinkM
• Shop a BlinkM at Sparkfun
• Programmable LED
• Sketch to change the frequency, nervous_blinkm_freq.pde