Enclosure design

Proposed enclosure design - inside the main body are four black tubes (actually drinking straws covered in black crepe paper but only because I couldn't find any black straws anywhere!)

It still needs four buttons (to turn each of four different channels on and off) and somewhere to put the "tuning pegs" for the potentiometers (which adjust the light sensitivity levels on each input pin) but this is the initial design idea for the enclosure.

The 16x2 character display allows users to tune the inputs and select different keys/sample sets without having to refer back to the PC the device is connected to. The LEDs show which channels are currently on and off. Of course a lot of this information could be display onscreen (on the PC) when used as a USB/HID device, but keeping it off-screen allows us to modify the firmware to create a midi version of the instrument in future.

The invisible instrument - schematics

Here's the latest schematics for our invisible instrument.
This version hasn't even been built yet (not even on a breadboard) but is an idea for improving on the current version.
We're acutely aware that four inputs isn't a massive number for an instrument - we could use "doubling-up" to create up to seven inputs (e.g. accept 1000 as the left-most position, 1100 as the next position towards the right, 0100 as the next, 0110, then 0010, 0011, 0001) but this would stop the instrument being poly-phonic (since 0110 would mean "play sound four" rather than "play sounds 2 and 3 together"). It's swings and roundabouts really.



Despite only four inputs, this does allow a large number of pop (and rock) songs to be played - 90% of popular music consists of three chords, four if you include a relative minor for the middle eight (if none of this means anything to you, don't panic!). Changing the sequence or overplaying chords with different lead lines is what gives most pop music depth. After all, too many chord changes and the song becomes unpredictable: and it's the predictability of music that gives it its "hook" (or, easy-to-recall melody).


Triggering riffs/chord samples with a single input allows songs to be built up from simple, repetitive sequences

This new instrument includes a dial (for selecting the current key/chord/scale if we ever get around to midi output) as well as some buttons and LEDs. The buttons are used during playback to "layer" multiple sounds from a single input:

The idea is to allow the user to load up to four different sounds to be played back whenever an input is trigger. It's a bit like having up to four channels, which can be muted/unmuted. It could be a bassline, guitar chord(s), synth parts and a melody line. When an input is triggered, all four sounds can be played at once. The user can turn off which of these are played by pressing the buttons which latch the sounds on and off. The LEDs show which "channels" are selected for playing when an input signal is detected.

So players can start with just the guitar part playing (for example, channel one active) - playing up to four different chords/riffs/patterns either in sequence or together - then turn on the bassline (channel two) and whenever a single input is triggered, both the guitar and bass parts play. The key to the success of this approach of course is that sound1 on channel 1 and sound1 on channel 2 are in the same key or at least sound harmonious when played together.

By combining these simple channels, it should be possible for someone (with a little practice) to create some rather complex sounding tunes.

I guess the only way we'll ever know, is to build one of these things and try it out!

What does the invisible man play? An invisible instrument

To date, we've been calling our instrument a "shadow harp".
While this is accurate - the instrument detects the presence of shadows in order to play notes - we've been undecided about the name for a while. Really, because Peter DeSimone has already created an instrument he calls a shadow harp (albeit one that was abandoned and replaced with his "pocket harp") and although this instrument was inspired by his, it really is a different project (more in-line with his original pin-hole light harp than his final shadow harp solution).

After a bit of debate and a few beers (ok, a few cups of tea) we decided to call our version the "invisible instrument". It's a specific enough name to convey what the instrument does (it's an instrument but the playing surface is invisible) but vague enough to allow for modifications and changes to the design and behaviour in future revisions!

So from now on, any references to a "shadow harp" are purely accidental - we mean, of course, "the invisible instrument".

It's stopped working!

Last night we celebrated (albeit in true nerd style, with a cup of tea and a Bourbon biscuit) after getting our "shadow harp" working properly.
It was possible to trigger 1,2,3 and even 4 different samples in sequence (one after the other) or together (by spreading my hands sideways and covering all four inputs at once). It seemed to be working exactly as designed.

This morning, keen to repeat the successes of last night, I plugged the new instrument into my PC and tried to play a simple tune. Nothing!
The LDR values didn't seem to change. I altered the sensitivity threshold but only saw activity when it was reduced down to 2 instead of 10 as it was last night. This was so sensitive that other inputs were triggering sounds even at the slightest movement near them.

I noticed that the raw input values had increased from around 220 to 252 and reduced very slightly when the end of each tube was covered.
Thinking about how the LDR works (with a variable resistance from 5Mohm down to a few hundred Kohm) it sort of made sense. During the day, natural daylight floods the room, so the "top" resistance is lower, compared to the fixed 1Mohm resistor to ground. At night, when playing the instrument under artifical light, the somewhat dimmer conditions mean the "top" resistor has a higher value - so the ratio between the top and bottom resistors is lower on each input pin. This theory is in line with the input values seen: at night, the input values are noticeably lower than during the day.

The solution? Not sure - my gut reaction is to replace the bottom resistors with linear pots, so that the instrument can be "tuned" to the ambient light conditions.
A simple set-up screen when the instrument is first switched on will allow the user to find the optimum values for the "bottom" resistor before play commences.
Perhaps something like take a reading from each pin in turn, compare to the mid-point (128) value and display it as a bar on the screen. The user then twiddles each pot in turn, until all inputs are set to about half-way. They can then press a button to start playing the instrument, knowing that hand gestures will be correctly sensed and processed as inputs for the device.

[update: I just tried replacing the 1Mohm bottom resistors with lower valued ones (about 330Kohm) and the instrument once again became sensitive enough to play. It seems that allowing the user to change the initial resistance of the bottom resistors (i.e. replace with potentiometers) could be the way to go!]

How the new shadow harp works

Each of the four analogue inputs as a simple voltage divider.
5V is connected to one side of a light-dependent resistor (LDR), which is wired in series with a resistor to ground. The input signal is taken from between the two resistors.

As the user places their hand over the LDR, the resistance falls, causing the ratio between the two resistors to drop. This variable voltage is fed into an analogue pin, converted to a digital value (0-255) by the microcontroller's ADC hardware and compared to the last value read in.

Even when static, analogue input values tend to "drift" - i.e. float around, +/-1 or +/-2 (so a "constant" value of 128 may actually vary between 126 and 130 over time!)
To overcome this, we take a reading from the analogue pin, compare it to the previous value and if the difference is greater than 2, this represents a genuine change in resistance, which we then process.

In fact, depending on light levels, sometimes it is necessary to adjust this value to 4 or 5, to avoid cross-talk as the user places their hand in a position that influences to LDRs, next to each other. By making this threshold value a variable, we can allow the user to set their own "sensitivity" level for playing the instrument.

In indoor lighting, the LDR inputs typically read around 220.
When you place your hand over an input tube, this value drops to around 205.
Sometimes neighbouring LDR values drop when you place your hand over an input - by setting the sensitivity to 8, in this case, only the sensor with a hand above it actually triggers an input signal.

Triggering inputs is quite simple - if an input value is falling compared to its previous value, this represents the presence of a hand above the input.
When the input value is constant, the hand is still present. When the value is rising, this is the user removing their hand away from the input.

Using Oshonsoft's hidterm DLL and an 8-byte USB buffer, we can send the raw input values AND the trigger values (0 or 1) for four inputs at a time:

Simplified shadow harp

After nearly a week of getting nowhere, we're thrilled to announce that we've (finally) got a working, consistently accurate shadow-type harp! It's much simpler than original designs, using only four LDRs (light dependent resistors) and a modified enclosure.



The original pocket- or shadow- harp designs used a pinhole "lens" to detect the position of the player's hand above the instrument. Even the original instrument's designer, Peter DeSimone, said that his original design was plagued with problems and false-triggers. To solve his false-triggering problems, Peter introduced capacitors and used the LDRs to create an oscillating input (counting the time between pulses to detect the presence - or otherwise - of a shadow).

This seemed like a lot of work for us - the problem is the LDR changes resistance continually, even by small amounts. In theory, a simple voltage divider approach should still work, we just need to eliminate the "false reads" caused by fluctuating analogue inputs.

Using a combination of hardware and software limits and sensitivity settings, we've managed to solve the problems associated with the voltage divider approach and by encasing each LDR inside a black tube, we've also managed to get rid of the cross-talk the plagued other designs.


Our LDR tube sleeves were just drinking straws covered in black crepe paper. There were no black straws in our local Morrisons, so we got these 80s style neon ones and covered them!

We're using just four LDRs and we're treating each as an individual input.
This means that we can trigger four different samples - in software we can decide whether a single sample plays or multiple (polyphonic) sounds can be produced.



Obviously four different notes/chords/samples is a bit limiting, so we're working on a dial that lets the player select a "sample set" during playing - in the same way they can change the key or chord/scale type (e.g. set to C major and the notes could be C, E, G, C, twiddle the dial and the notes could become E,G,A,B from the Em pentatonic scale).

The first thing we need to do is check we've enough spare pins for an LCD display, 4 analogue inputs, 4 LED outputs (an addition that might be useful: an indicator to show that an input has been detected) plus a few extra analogue inputs for the pots/dials. On a beefy 18F4550 that would be a doddle - we've a load of 18F2455 chips lying around from previous projects and it'd be nice to squeeze a bit more use out of those!

Check back for schematics and more videos shortly.......

Pinhole box to focus light beams

Here's the basic idea - to place a row of LDRs (light dependent resistors) in a row, then place the whole lot inside a box. The inside of the box stays darks, and a small pin-hole is placed in the lid. Each LDR can now receive just a little bit of ambient light, but only from a specific direction. By moving your hand around above the hole, each LDR should be affected but only when your hand covers a narrow region above the box.



By doing this, we should be able to map when the user has placed their hand to a specific sound-trigger. I think this is how the pinhole light harp works. We're working on creating a digital trigger device to begin with, then we'll add an ultrasonic range-finder to calculate how high the player's hand is above the instrument (perhaps to increase volume or play different notes).

Light harp for Brighton Fringe Festival 8th May

As part of the Brighton Fringe Festival, BuildBrighton have been invited to take over the Ocean Rooms on Sunday 8th May 2011. We're creating a number of sound- and light- installations for an evening of eletronic music madness.

Of course, the most visually impressive light-to-sound instrument for electroncia is Jean Michel Jarre's Laser Harp. There are quite a few homemade harps around (on Youtube and the like) but even the cheap ones are relatively expensive. The problem is, to get a visible laser beam, you need lots of smoke and something substantially more powerful than a laser pointer off eBay!



I looked into getting a powerful 250mW+ laser and using a galvo to draw the vertical "strings" for the harp - if you look closely on some of the YouTube videos, you can see that this seems to be the current approach as some strings appear to have a bit of flicker (the flicker isn't noticeable when played live, it's just the way digital cameras pick up fast-moving images).

Something like this Light Harp would be very impressive to make too - I love the idea of using some really old retro radio cabinet to house such a cool, futuristic instrument. Using lights instead of lasers also makes it much safer to use in a public space (and encourage the audience to have a go themselves). It plays like a real harp too - with the user "plucking" the light beams to trigger a sound.



The photos and schematics show that a lot of work went into this particular instrument - and the build cost was around $500, a little bit too much for many people to have a got at. In short, it's an amazing instrument, but too expensive and too complicated to try to explain at a single-night event.
What we need is something a little simpler.

Almost all homemade laser harps use some form of LDR (light dependent resistor) and a break-beam sensor to detect when a user has placed their hand over a light source. The laser beam hits an LDR, making the internal resistance low. When a hand breaks the beam, the resistance of the LDR increases and the controller recognises that the user has placed their hand in the beam.
Lasers have a nice, concentrated beam and are relatively easy to work with. LEDs and other diffused light sources are not quite so simple - light can come from a number of sources to strike the LDR, not necessarily from an LED placed over it.

While searching the 'net for "pinhole" lenses (to see if it is possible to narrow a beam from an LED) I came across someone who had a similar idea; only to turn the problem on it's head. Instead of trying to detect reflected (or broken) beams of light, Peter uses a series of light dependent resistors and a pin hole to create "cones" of detection, basically checking for the presence of shadows, as you wave your hand over the instrument.
It's a brilliantly simple but effective idea.



I think it's a project that we should be able to get up and working in a couple of days - and simple enough to create kits for other users to make their own, ready for a "big band ensemble" for the Fringe Festival!

No news is good news

It's been a few days since the last update on the 20 channel servo controller, but that doesn't mean nothing has been happening. Over at BuildBrighton we're anxiously awaiting the arrival of our new laser cutter so all eyes have been on that. A lot of our PCB making equipment is down at The Skiff so it'll be a while before we can get down there and actually make up a working board.

In the meantime, the eeprom chips are on order from Farnell and we're waiting for a load of micro servos to arrive from eBay and until they appear, there's not much more to do on the servo board.

Maybe there's time to look at another project while we're waiting....

Working servo board prototype

Here's a quick video and some photos showing the new 20-channel servo board in action! The actual board registers as a HID device. We're including sample code for Windows (but anyone wishing to port the code to Linux/MacOS should be able to do so using something like HIDApi).



The HID device communicates with the host via an 8-byte buffer.
To move the servos, simply set the 7th byte to value 201 (I don't know why we chose that value to represent the "move servo" command, but we did!) and the zero byte to the servo channel number (1-20) and the first byte to the movement value.
The range of valid movement values changes depending on the servo being used.
In theory, the values should be 100-200. This represents a signal range of 1ms to 2ms.



The mid-point should always be 150 (1.5ms) whatever the servo, but we've found that some of our cheap chinese HXT900 servos accept a much wider range (as low as 30, or 0.3ms and as high as 250 or 2.5ms before they start to "chatter" at the end of their range).


Snapshot of simple VB6 app sending data to a generic HID device through an eight-byte wide buffer

Servo board PCB layout

Here's one PCB layout for the 20-channel servo board (minus eeprom).
For testing, we'll stick to simple USB commands to move servos on different channels. The eeprom chip is connected to pins PORTA.1-PORTA.4 but for now we're just concerned with getting all the servo channels working correctly.

The board is mirrored so it's ready to print straight onto some press-n-peel for toner-transferring onto some copper clad board. It's also a single-sided board, using through-hole (large chunky) components for easy prototyping:



After proving that this design works, we'll add the eeprom chip to the board and post complete and final schematics. The file below is posted on Scribd.com and if you want to make this PCB yourself, you should print at 100% with no stretching (landscape orientation).

Servo Usb Pcb

Servo board schematics

So far, we've decided to build a board that supports 20 servo channels.
As you can see from the schematic, there are still a few spare digital pins.
We have deliberately kept a few PORTA pins free, for the eeprom/memory chip which we'll use to store and play back user-programmed sequences. If the board is for use on a portable device with serial communications, these pins could be recovered and used for analogue inputs, if required. Amending the firmware to use up some of the spare pins would allow up to 25 servo channels, but we decided to keep a few back for now, to see what the board can be used for and to make future development simpler!

In the full and final version, we'll put the eeprom onto pins PORTA.1-PORTA.5

Servo controller with eeprom and playback

Having already successfully create a simple servo board with eeprom and playback we looked at how to improve on a relatively simple design.

We've decided to use a larger eeprom, Atmel's AT45DB041D is a massive 4Mbit device (512kb) with a simple-to-use SPI interface. There are other eeprom chips we could have used, but we are already familiar with this one, from a previous project, and how it's memory space is laid out and addressed (256-byte pages).

In the original servo controller, we had problems getting the playback to sync up with the onscreen editor - mainly because of the way playback was coded.
In this board, we're going to use the same approach for playback as we did for the parallel servo processing. That is, we're going to keep a timer running and compare it's value to a required value. When the running timer value exceeds the required value, we will perform an action. Because we already have a timer raising an interrupt every millisecond and we monitor for 20ms having passed (when all the servo pins are reset to start their repeating signals) it makes sense to use this interrupt for playback timing too.

Simply put, every time we reset the servo output pins, we'll increase an internal (two-byte) counter. So our counter increases by one every 20ms. Using a two-byte counter, that goes up to 65,535 this means we can create playback animations that are 65535/50 = 1,310 seconds in length (almost 22 minutes).

In eeprom, we store animations as a series of servo commands, written as four-byte instructions:

• The first two bytes are the "timecode" of when the animation is to play - i.e. the counter number when the next servo needs to move (so at every 20ms or 50hz, to move a servo after 1 second, the counter number will be 50. To move another servo after 3.4 seconds, the counter number will be 3.4*50 = 170, and so on).
• The next byte is the servo number to move
• The final byte is the degree of movement required.

During the processing part of the main code loop, we can read four bytes from eeprom and compare the current timecode counter (which is updated on an interrupt) to the required timecode for the next servo. When the current timecode counter value exceeds the servo movement timecode, we move the servo in accordance to the other two bytes. When this is done, we can read another four bytes from eeprom.
In doing this, we can create an animation by listing which servos need to move by how much and after how much time. If two or more servos need to move together, the instructions would actually be carried out sequentially (one after the other) but the delay between them would be so small, as to appear to have been carried out at the same time.



Example data for animation playback:
50,1,90 (after one second, move servo one to extreme left)
100,2,120 (after two seconds, move servo two to about 30 degrees)
150,3,200 (after three seconds, move servo three to extreme right)
200,2,200 (after four seconds, move servo two to extreme right)
250,4,150 (after five seconds, move servo four to about mid-point)

We could continue this sequence, for example

300,3,100 (after six seconds, move servo three to extreme left)
300,1,200 (after six seconds, move servo one to extreme right)

Consider the "check-timecode" approach with the data above:
When the timecode counter hits 301, this value is greater than the 300 in the first instruction, so servo three is moved to its new position. Now, we read in the next set of values. Even if the timecode has increased (to 302 or greater) this is still more than the 300 in the second instruction. So servo one is moved to the extreme right and the next values are read from eeprom.

Normally, the timecode counter value will not have had time to increase between moving the two servo values but we can see from the example above that even if it does, the second servo is only about 1/50th of a second late moving and the servo controller board soon "catches up" and eliminates any delay.

The only requirement for this approach to work is that the data stored in eeprom is already sorted by timecode (with earliest instructions first in the list). Because we're going to use some custom built software for allow the user to build their animations, we can get the PC/host computer to do this sorting for us and don't need to worry about implementing a bubble sort in a microcontroller!

Servo board controller - parallel not serial

Many moons ago, we put together a multiple channel servo controller which generated a lot of interest on YouTube.

As part of the newly-relaunched NerdClub website, it made sense to write a few posts about how the all-new 20 channel controller works. Kits will be made available to anyone who just wants to get their hands on a working servo board, without the need to puzzle out all the clever code.

For this board, we're using the trusty old PIC 18F4550 microcontroller. You can use the lower-voltage 18LF version of this chip too, but we're sticking with the 5V version (see schematics later on).

Many people have asked how we managed to get beyond the theoretical limit of 8 servos on a 20ms pulse. For anyone not familiar with servo control, the way a servo works is it receives a signal of between 1ms and 2ms in duration (1ms = extreme left position, 2ms = extreme right). This signal has to be repeated every 20ms.



In practice, a servo signal is usually between 0.8ms and 2.4ms in length. Allowing for up to 2.5ms per servo, and repeating each signal every 20ms, this means we can send 20/2.5 = 8 signals one after the other, before having to return to the first servo to repeat the whole process all over again.



This is where we challenged the assumption that the servo signals have to all be sent serially (one after the other). We took the "parallel" approach - we turn on all servo pins at the same time, then compare the current time (in milliseconds) from the on signal start, to an array of "off values". Every time the current timer exceeds the "off value", the corresponding output pin is turned off.

Let's say we've an array of three off values:
servooff[1]=1000
servooff[2]=1500
servooff[3]=2000

We turn on all three servo pins at the same time, and start a timer running.
During the main code loop, we compare the current running timer value (converted into milliseconds) against each of the three off values. When the running timer exceeds 1000, we send servo pin one low (turn off the servo signal). This is the same as a 1ms servo signal (which sets servo one to the extreme left position). After the timer exceeds 1500 (1.5ms) servo pin 2 goes low (servo two is set to the mid-position) and after the running timer exceeds 2000 (2ms) servo pin 3 goes low (setting servo three to the extreme right position).

Because the signals need to repeat every 20ms, we now have 18ms of hanging around before we reset the running timer and turn on all servo pins again.
(in fact, these 18ms are used for other processing such as receiving and processing user input, getting data from an SPI eeprom chip and so on).

Using this "parallel" method of processing the servo signals, we can have many more than just eight servos. We stopped at 20 because our PIC microcontroller has 40 pins - 4 are used for power and USB, 5 for SPI clocking an eeprom chip, a few push-button inputs, serial comms (send and receive) and we decided to leave a couple of spares.


Parallel method of controlling servo signals - all are turned on at the same time, and switched off at different times (between 0.8ms and 2.4ms after being switched on).

New website and projects

Welcome to the updated, new-for-2011 Nerd Club website!
We've learned from the old site and we're now using the excellent Blogger platform not only for our content, but for images and videos too. We had lots of interest on the old blog site, but when our own server went down, it took all the photos posted on there with it - so lots of posts didn't make much sense without illustrations to explain what was going on!

This new site is an improvement on the old: we're still going to be making cool stuff and writing about it here (including schematics and source code where appropriate) but we've also included links to a video website and even a shop, where you can buy kits of all your favourite geeky gadgets.

Things may be a little slow during these early weeks, as we spend time getting familiar with the hosting platform again, and getting things like the shopping cart integrated with the rest of the site, but don't worry - we'll soon be spouting off about all kinds of nerdy stuff on a regular basis!

In the meantime, here are some links to a couple of other blogs which ramble on about some of the other projects we're involved in:

Ben's Crazy Cube Reader Project
Homebrew Digital Drum Kit
All the latest goings on at BuildBrighton