Finally gotten around to diagramming and writing this thing up! So after last Wednesday’s session i managed to get my grubby mitts on what i *thought* was a colour sensor. Unfortunately it turned out to be just a light sensor, a TSL230 to be exact. At first i was horribly dissapointed as i desperately wanted to get some colour sensing underway and now i had no colour sensor! But I hatched a cunning plan. First we need to understand a bit about the hardware, the TSL230 is a light sensor, with adjustable sensitivity and a very precise and accurate response to light levels. It has adjustable settings for output type aswell as adjustable sensitivity levels, output offset and output frequency division, without reading the data sheet and pouring over response graphs this probably means very little, but what it amounts to is this: Although the TSL230 only detects light, not colour, it is very good at what it does. I managed to get the chip reading data back into my arduino with this really great tutorial Going through my options to get colour light values out of this chip i first thought of geting 3 of them, putting a red filter over one, a green filter over another and red over the last. Then reading values from each in order to get an RGB value back out. However, i didnt have 3 TSL230s, i didnt have any filters, and even if i had all those things, i couldnt hook up 3 sensors as i need an interrupt pin for each sensor and the arduino has only 2 interrupt pins (more on interrupts later). Hmm Maybe i could take one reading with a red filter, change the filter for green, take a reading and lastly do the same with blue. This would work, but i would be left with the option of either manually changing filters or building a mechanism from a servo or something like that. I still didnt have any filters, and even if i did the whole system would be horribly speed limited by the time taken to change filters. AHH, BUT WAIT! We dont need to filter the light after it comes off the object the colour of which we need to know, we can just shine red light, then green light then blue light, measure the intensity of that light type that is REFLECTED from the object for each colour of light shone at it and form an RGB colour triplet! We even have the perfect colour light source, an RGB LED! So i cooked up a circuit: It’s just how you would hook up a TSL230 as standard, but with an RGB very close to it. Also, not in the diagram, a piece of thick black paper was placed between the sensor and the RGB LED, to ensure that light reaching the sensor came only after it had been reflected off the target object. Here is the code running on the arduino (Based on the above linked tutorial)

#define TSL_FREQ_PIN 2 // output use digital pin2 for interrupt#define TSL_S0	     5#define TSL_S1	     6#define TSL_S2	     7#define TSL_S3       8#define RED          10#define GREEN        11#define BLUE         12#define REDO          3#define GREENO        5#define BLUEO         6
unsigned long pulse_cnt = 0;unsigned long refTime = 0;boolean       BlueState = 1;int redVal;int blueVal;int greenVal;
void setup() {
// attach interrupt to pin2, send output pin of TSL230R to arduino 2  // call handler on each rising pulse
attachInterrupt(0, add_pulse, RISING);
pinMode(TSL_FREQ_PIN, INPUT); pinMode(TSL_S0, OUTPUT); pinMode(TSL_S1, OUTPUT); pinMode(TSL_S2, OUTPUT); pinMode(TSL_S3, OUTPUT); pinMode(RED, OUTPUT); pinMode(GREEN, OUTPUT); pinMode(BLUE, OUTPUT); pinMode(REDO, OUTPUT); pinMode(GREENO, OUTPUT); pinMode(BLUEO, OUTPUT);
digitalWrite(TSL_S0, LOW); digitalWrite(TSL_S1, HIGH); digitalWrite(TSL_S2, HIGH); digitalWrite(TSL_S3, HIGH); delay(500); Serial.begin(9600);  refTime = millis();}
void loop() {   digitalWrite(RED, LOW); delay(330); Serial.print("R");   redVal = pulse_cnt * 4; Serial.println(redVal); pulse_cnt = 0; digitalWrite(RED, HIGH);  digitalWrite(GREEN, LOW); delay(330); Serial.print("G");   greenVal = pulse_cnt * 5; Serial.println(greenVal); pulse_cnt = 0; digitalWrite(GREEN, HIGH);  digitalWrite(BLUE, LOW); delay(330); Serial.print("B");   blueVal = pulse_cnt * 3; Serial.println(blueVal);  pulse_cnt = 0; digitalWrite(BLUE, HIGH);  analogWrite(REDO, (1023 - ((redVal - 50)*8 )   ) ); analogWrite(GREENO, (1023 - ((greenVal - 50)*8 )   ) ); analogWrite(BLUEO, (1023 - ((blueVal - 50)*8 )   ) );  }
void add_pulse() {
// increase pulse count pulse_cnt++; return;}

So now we are at the point where i have to talk about interrupts. If we were to want to take input from, say, a button, we would have to __constantly__ as part of our loop() read the input of the button. This works just fine with buttons, as when we press them we (in computer timescales) press them for a very long time, hundreds of milliseconds, plenty of time for the loop to always catch the press. But our TSL230 outputs very short pulses of +5v and sends them to a pin on our arduino, and lots of them. The more pulses per second the more light it is seeing. So we have to count those pulses to derive a value from the sensor. If we were to use the same method as we did above with the button, just constantly looking once every loop() we would miss LOADS of pulses because the little pulses are so short and frequent that while our code was off doing non-pulse counting things pulses would be coming in uncounted. This is a common issue in computing, and we have a solution. Interrupts. Look at this line in ”setup()” attachInterrupt(0, add_pulse, RISING); The parameters are:’0′ which means we want to use this interrupt on the arduinos zeroth interrupt pin, which is pin 2.’add_pulse’ which is the function we want to call when the interrupt happens’RISING’ which is the kind of action we want to happen in order to trigger this interrupt, ‘RISING’ means a rising edge, which is the very start of a pulse. This all means that when we get a RISING edge on PIN2 (Interrupt 0) we will call the function ‘add_pulse’. Here is the code for ‘add_pulse’ void add_pulse() { // increase pulse count pulse_cnt++; return;} So basically, when we get a rising edge on pin2, arduino will pause what it is doing, and add 1 to the pulse_cnt variable. The code works like this: Do some setup stuff to set the sensitivity etc of the sensor. The in the loop: Turn the RGB LED to RED; Set pulse_cnt to 0; Wait for a little while for the pulses to come in.Save the value of pulse_cnt as the red intensity value. Turn the RGB LED to GREEN; Set pulse_cnt to 0; Wait for a little while for the pulses to come in.Save the value of pulse_cnt as the green intensity value. Turn the RGB LED to BLUE; Set pulse_cnt to 0; Wait for a little while for the pulses to come in.Save the value of pulse_cnt as the blue intensity value. We now have a value for each colour! combined they give use an RGB value (With a little tweaking as there is some leakage and different sensitivity for each colour) We can go put on another RGB led as an output, which will turn the colour of the target object (Kinda, at the moment it just turns either completely red, or green, or blue, whichever the target is closest to, not a nice mix to create exact colour reproduction which will need a lot of time consuming calibration.) And finally a video of the thing working! Video!

A little fun with PureData

| June 29th, 2011

Puredata is a visual programming language and development environment mainly aimed towards audio creation. It is quite similar and created by the same guy as the somewhat more mainstream Max/MSP


Hipster kitty

The basic premise is to create blocks which perform functions on data passed into them, and output it onto other blocks, and eventually out into your audio device in order to create sound.

Max differs quite a lot from conventional imperative programming, like C and Java ( where statements are executed sequentially one after another branching at conditional statements like “If” and so on. As such Max and PD are nothing like the visual programming environments such as “Scratch” where visual blocks that substitute lines of imperative code are arranged to form a sequential structure of logical statements.

Instead Max and PD are closer to functional programming languages like Haskell and LISP where data moves non-linearly between many functions without the system holding a single specific state.

Enough programming chatter! What did I actually do?

I wanted something that would pull in data from the “real world”, i.e from sensors and inputs outside of the computer, and use these to modulate the sound produced. I started out with a wii-nunchuk connected to the computer via an arduino to grab the accelerometer data from the nunchuk over i2c and send it to the computer via USB-Serial. Once data is sent to the computer’s serial port it can be accessed from within puredata by using the comport external. (An ‘external’ is PD slang for something akin to a library in normal programing terms, providing extra functionality/features)

This provided a really nice easy way to muck about in puredata and create simple noisemakers and learn the ropes while having a fun and intuitive way to input variable data to get a bit of variety and see how my experiments reacted to changing inputs.

Then in June I went to the Rockness festival, and ended up watching a DJ set by Sub-Focus. As I was watching, something caught my eye, he was using some sort of range finding device and his hand in order to modulate the wobble bass.

Watch carefully in this awful bit of camera-phone footage starting at around 20seconds and you can see him doing this, along with the green laser spot that must be the range-finder’s emitter beam.


This bit of footage isnt a particularly great example, its just the only bit of footage I can find with him using it.

I thought that was pretty damn cool, and if it was good enouhg sub focus, then it was good enough for me. However I don’t have much in the way of lasers or time of flight sensors, so I was going to have to do a poor man’s equivalent. I used a TAOS TSL230R light sensor, which is a little chip that I have used quite a lot, very sensitive and easy to work with. I rigged it up in a standard circuit connected to an arduino like so:

I could then shine a bright light on the sensor and moving my hand closer or further from the sensor would change the amount of light falling on the sensor, and thus the readings from the sensor. The Arduino was programmed to read the sensor and just hand off the values over serial to PD using the comport module like before.

Using this awesome tutorial for MaxMSP on creating that stereotypical Dubstep wobble I went about doing some porting to PD along with swapping out the boring manual inputs for super cool subfocus-inspired hand distance wobble control.

Making all those connections in PD just to create some “wub wub wub” really made me appreciate how much actually goes into what, to a total audio-layman like me, sounds so simple. There was actually quite a few more dimensions to each “wub” than I had anticipated, I decided that I needed more inputs as a way to control more aspects of the sound.

I really wanted an accelerometer, but my arduino/serial port was being hogged by the light sensor, and having to multiplex 3 accelerometer channels along side a light sensor and pull them apart on the other end wasn’t an idea I relished. Instead of using a nunchuk via an arduino I decided to just go the whole hog and throw in a bluetooth connected wiimote. There’s even a premade external for wiimotes so that’s easy!

NO. ITS NOT EASY. I spend a whole evening hair pulling and source-rejigging and all mannner of filthiest darkest deep majick and made sacrifices to the elder gods of unix. Eventually the external was wrangled into working, *just*. I honestly don’t know what it was I changed or fixed, but my takeaway from this is that if you want to use a wiimote with Max or PD I would just use a Mac and Osculator to grab the data.

In the end I managed to get everything tied together and working. Using the light/distance sensor to control the frequency of the lower frequency of the wobble along with the accelerometer of the wiimote to change the frequency of the saw-toothed wave which ‘rides’ that lower frequency wobble. Kinda like amplitude modulation in AM radio’s, the light sensor controls the signal, the accelerometer controls the carrier wave. That’s the best way a non-audio guy like me can explain what is going on inside.

Pics of the final rig and video of it in action to come once they upload!


Rather nice looking by the looks of things!

The first true mechanical watches were incredibly expensive, technological marvels of their time. The mechanical pocket watch represented a engineering marvel, they required no pendulum like previous static timepieces, which enabled them to be moved and carried on a person.
The initial social implications of wearing or owning a pocket watch were huge. Of course one had to be very wealthy to even purchase one, but also the buyer would probably have had need for precise time on demand. The combination of wealth and a need for precise timing would have meant that the owners of watches would be important people, doing important business, almost certainly on a schedule.
It was this initial status of the first watch owners that endeared watches with the status symbol position they still hold today.
Despite the coming of quartz timed digital watches, able to tell time far more accurately and cheaply than any mechanical watch, people still buy expensive, Swiss hand made watches. Why? Status, Fashion, Expression of personality.
People purchase watches which are intentionally needlessly complex, based on mechanical designs. These being far more expensive, less accurate and more delicate than a simple Casio digital wristwatch. Current fashions in upmarket watches tend towards expressive complexity and the display of that complexity.


Even digital movement watches are beginning to partake in the trend towards complexity. The company Tokyo Flash is renowned in geek circles for its complex artistic patterns, often forgoing numeric displays and using binary encoding to represent time.

People do this, because they want to differentiate themselves from others, in order to stand out. Being that the origins of the status symbol position which watches hold in our culture was their technological complexity it is no wonder that the primary way to differentiate a watch is the technology of the piece itself. A watch is a representation of personality embodied in technology as much as it is a teller of time.