Skip to content

Breathless Reflections

December 15, 2010

WARNING: This project is a work in progress.

In the weeks intervening between my proposal for my final project (see here: and here at Rest of You: and the moment I actually got up and presented it, I focused on the external representations of my respiration alternative to the screen-based display I had come up with for the midterm.  Despite all the excellent criticism I received during my proposal, I focused primarily on utilizing RGB LEDs, with the idea that they would be installed as buttons in my shirtfront at the location of my diaphragm and belly, and reflecting their behavior.  This was meant to be a quick experiment, and if fruitless, my intent was to pursue some of the other suggestions.

Like many quick experiments, however, it turned into a bit of a rabbit hole.  Setting up the LEDs and getting them to run through their color range was not difficult, but refining their behavior so that they clearly reflected my breathing was time-consuming.  I’ll get to the specifics of the setup and code in a moment, but I want to talk first about what I learned.

First, having the LEDs changing color right in front of my diaphragm and belly is not very compelling.  Mike Doherty suggested I eliminate the color and just play with intensity, and I do think that’s worth pursuing, but I also think that whatever signal is being actuated needs to be separate and apart from the actuator.  It is more interesting when the LEDs are on the breadboard, changing color as I breathe.  I do think they’d be more interesting integrated into some piece of jewelry as I had planned to pursue in my proposal, but this brings me to my next point:

Size matters.  It is simply more interesting to control the large screen-based circles.  They convey more information about the breath because they are also changing diameter as well as color.  The LEDs are more one-dimensional in this respect.  Given that I have been trying to find an alternative to screen-based visualization, I should have worked harder to not rely on light, as was suggested when I presented my proposal.  I’m not saying it cannot work at a smaller scale, but I’m not sure there’s really any additional information there.  The only advantage is that it is portable, and against the backdrop of the screen it is weak.

Here is a mock-up with the LEDs in position:

Admittedly, it would have been more compelling without the screen-based animation behind me, and as well if I had spent some energy on the physical artifact of the jewelry itself, but I was not convinced it was worth it, at least not for the Winter Show, with the technical problems I ran into.  I’ll talk about those now.

First off, as I said, the RGB LEDs are quite easy to use.  I used the 4-pin common cathode ones (cathode goes to ground) from Sparkfun  They have an excellent data sheet and Wiring diagram  The R,G and B pins each get pulse-width modulated (PWM’d) such that the voltage they are fed can be mapped from 0-255.  Here was my breadboard setup:

I’ll talk about what’s going on the big breadboard separately: that’s the setup for my respiration sensors, and wireless XBee communication back to my laptop (you can see that here:  The RGB LEDs are grounded to the common ground at the back of the small board–you can barely see a small black wire behind each of their cathodes, but here’s a closeup:

Initially, I tried some basic code that steps through the spectrum.  At the Arduino Forum there are some good examples, and I began with this:

Once I had an idea of how they behaved, I gave some thought to how I would integrate their output with my Processing sketch.  It was, after all, already processing the data from my respiration sensors and mapping it to values from 0-255.  My initial thought was to simply have Processing send those mapped values back to the Arduino with the handshake, and have the Arduino write them to the LEDs.  This ended up with the LEDs simply glowing a bright white, though, with a slight pulsation.  Reasons I can think of for this behavior are 1) the serial communication is happening faster than the Arduino can pulse those pins, and 2) the RGB values mapped to the screen in Processing do not look the same on LEDs.

Either way, or both, I decided next to disengage the screen draw from the LED draw.  Essentially then, I’d have the Arduino taking the sensor data, writing it to the serial port with a line feed, and then mapping the values from 0-255 and writing them to the LEDs.  The handshaking in the serial connection functions to keep them in synch.  This setup worked pretty well with a hard-wired connection, but for some reason it really started to stutter with the XBees.  On the Processing side I was seeing incomplete transmissions, causing the Processing sketch to jitter.  The LEDs were pretty well-controlled, but the code could use more refinement at the edges of the sensor ranges.  If the values go outside the mapped maximums and minimums, the LEDs jump to the brightest values at the opposite ends of the range.  This mapping problem actually exists within my Processing sketch as well: the sensors are rubber, and have a certain amount of memory after each elongation.  I plan on implementing Chris Allick’s suggestion that I have the sketch reset the maximums and minimums dynamically — in other words, test the existing ones against what’s coming through serial, and modify them up or down accordingly over time.

Here’s the Arduino code:

Respiration Sensor Sketch
modified 11/14/10: added handshaking
modified 12/6/10: Arduino draws RGB values itself, independent of Processing.
They are not screen pixel equivalents.

M. Fleisig

Based on DanO's MultiSensor Send:

This sketch requires two analog sensors.

int minDiaph = 895; // Min Sensor Value
int maxDiaph = 940; // Max Sensor Value
int minBelly = 885; // Min Sensor Value
int maxBelly = 930; // Max Sensor Value


int red = 100; //red (quarter-range)
int green = 2;
int blue = 2;

//BELLY Colors
int red2 = 50; //blue (quarter-range)
int green2 = 50;
int blue2 = 50;

int RedPin = 11;
int GreenPin = 10;
int BluePin = 9;

int RedPin2 = 6;
int GreenPin2 = 5;
int BluePin2 = 3;

int diaphragm; //analog pin 5
int belly; //analog pin 4

void setup() {

analogWrite (RedPin, red);
analogWrite (GreenPin, green);
analogWrite (BluePin, blue);

analogWrite (RedPin2, red2);
analogWrite (GreenPin2, green2);
analogWrite (BluePin2, blue2);


void loop() {

if (Serial.available() > 0) //Only send out if something has come in
//In this case, anything received will trigger a send
belly = analogRead(4);

diaphragm = analogRead(5);


int bellyRB, bellyG, diaphRB, diaphG;

if(( belly >= minBelly) && (belly = minDiaph) && (diaphragm <= maxDiaph))
diaphRB = map(diaphragm, minDiaph, maxDiaph, 0, 255);
diaphG = map(diaphragm, minDiaph, maxDiaph, 0, 0);


red = diaphRB;
if (red 1) &&( blue > 1))
blue = 255 - diaphRB;


red2 = bellyRB;
if (red2 1) && (blue2 > 1) )
blue2 = 255 - bellyRB;

analogWrite (RedPin, red);
analogWrite (GreenPin, green);
analogWrite (BluePin, blue);

analogWrite (RedPin2, red2);
analogWrite (GreenPin2, green2);
analogWrite (BluePin2, blue2);



From → Rest of You

Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: