Roombaduino – part 11 – Wireless Shield

After proving that the breadboarded circuit worked as expected, I charged up the Roomba battery and soldered up the Roombaduino circuit.
This time, I was using double-sided perfboard which has its pros and cons ( for me ).
The pros are that the perfboard is better quality than the paper single-sided board and that the pads are less likely to melt and detach when I solder.
The con ( for me ) is that because the pads are double-sided, the solder flows through to the other side. So, if I’m not soldering a component and I want to lay down a power rail, the solder forms in a bump on the other side of where I’m soldering the rail.
I’m sure other people are perfectly happy with it but it doesn’t work for me so I’m going back to single-sided.

I soldered up 3 parts to the circuit.
Firstly, the connection from the Roomba to the circuit through a 5v power regulator. This allows the Nerduino to be powered from the Roomba without needing a separate power input.
Secondly, the 5v to 3.3v power regulator to provide power to the wireless transceiver.
Thirdly, the connection from the Nerduino to the wireless transceiver using the SPI pins.

While the circuit looks compact on the front, I’m still not happy with my wiring ( but I don’t want to take it apart again – maybe in the future ). I need to be more methodical about how I wire stuff to make it more tidy.

What I *am* pleased about is the shield-like design so that the connection to the Nerduino is done through pins and the Roombaduino circuit can stack on top.

A little redesign

I realized that I didn’t need another ADC to clear down the capacitor. The circuit I’m basing this on uses 2 multiplexers: 1 for the input select to send on to an ADC and one to clear the capacitor for the selected drum input. The design makes sense because you’re selecting the input and those same input selections will also be used to select the clear down.

However, given that the MCP3008 (ADC) has 8 inputs, the first multiplexer is redundant.

So, I now have the ADC and one multiplexer.

I put together a test circuit to make sure that I understood how to talk to the multiplexer and that seems to be working fine.

What’s the (decimal) point ?

So guess who read the capacitance incorrectly ?

4.7uF is *not* the same as 4.7nF. Like I suspected, I’m using a capacitor that’s too big for the job. So, I’ve ordered some nano-Farad capacitors.

I played around with replacing the 1M ohm resistor with a variable potentiometer and that allows me to “tune” the signal a little more so that I can make the circuit more or less sensitive.

I think I also need to change the algorithm that’s sampling the data because it has some problems where it’s still measuring the decay (which should go away once the right capacitor is in place) but it’s also displaying the same measurement in a short period of time (milliseconds ?).

I did have it so that the measurement is only done when the delta between the current reading and the last one was positive ( an increase ) but that doesn’t allow for when I go from a hard hit (high number) to a light tap ( low number ). I figure that if the capacitor was smaller, the voltage will be held for a shorter amount of time and will drop to zero quicker meaning that sampling a positive delta will always be an intended event. TIme will tell. I’m just waiting for the postman now.

It's Alive !

It’s Alive !

The Circuit

I actually got the circuit wired up again and, somehow, it seemed to work this time. I saw a voltage change with small taps and large hits so the next step was to connect the ADC (MCP3008) and the Pi Cobbler (GPIO cable connector).

So, I consulted the project at and wired up the GPIO pins to the ADC per their instructions.

I also took the python script from the same project and hacked it to remove the audio volume stuff.

It was during my initial test that I found I had connected the GPIO cable the wrong way round on the Pi which meant that nothing worked. My first thought was that I’d broken something but I pulled everything out and did a quick LED test ( see ) which proved that none of the GPIO pins were responding as they should have done. So, I took the case apart, turned the cable around and reassembled everything. This time, the LED test worked as I expected (cue a quick Gangnam across the living room to celebrate ).

After wiring the ADC up again, it was a success as this video shows:


Next to do is to remove the capcitor to see if I can get the slope to decay much quicker.

Information burst

More reading, more changes of mind.

As my requirements for this MIDI interface are limited only to sending notes, I came to the realisation that I don’t need to handle journals inbound to me and the only journal I need to create outbound is a Chapter N for NOTE ON/OFF events. After playing with reference implementation and copying most of the sample code from the RFC, I’ve taken it all out again and I’m starting from scratch. The RFC code isn’t the best example of a Chapter N journal so I need to go over the details again and translate the concept. I’m sure it’s relatively simple, I just need to wrap my head around it (I’m a bear of little brain).

I have 2 binaries right now. The first is a simple Avahi registration app that publishes host and port 5004 and the name of the service (_apple-midi._udp). The second listens on the ports for events. The listener app is correctly unpacking the Apple MIDI events. I did clean up some segfaults when the OS X MIDI app ends the session ( by sending a BY event ). I’m debating whether I want to handle just 1 session or multiple.

On the hardware side, having got a little bored of starting at C code, I spent some money at Radio Shack and other places to get capacitors, resistors, diodes and also some 3.5mm audio inputs that are breadboard combatible.

I did some reading up on how to handle the drum pad inputs. As the teardown showed, it’s a piezo trigger and, according to the internet, that requires some special handling.

The following pages are useful information: and

They show the circuits needed to handle a piezo input.

Here’s my problem right now. I built the circuit using the info from Peter Vieth’s page and, if I connect up my multimeter, I can see there is a change in voltage when I hit a pad but it’s very small. Some of the many questions I have is whether I’m supposed to be seeing such a small voltage change ( which I saw when I first tested the pad a couple of months ago ). In some cases, with light hits, I don’t see a change at all.

I connected the drum pads back up to the controller they came with and they play fine. Light hits are registering so I know I haven’t broken anything ( hard to do seeing as it’s a piezo trigger ). The controller uses a 9v DC input and I’ve hooked my circuit to a 9v battery but see little change.

The other question I have is whether I’m actually using my multimeter correctly or if I should even be seeing anything register with a multimeter. The info on the Leucos site shows some good data using an oscilloscope but I don’t want to get into that at my stage of life ( $$$ ).


I guess more reading is in order. I have some work colleagues that are part of Noisebridge ( and they have sessions on a Monday  which helps members learn about circuits’n’stuff so I may check them out.

Playing with hardware

Playing with hardware

My original multimeter failed me. It wasn’t either the battery or the fuse so I revisited Radio Shack and $21 later, I got a new one.

The drum pad just houses a trigger.



So I wired a drum pad and a drum pedal to a 9v battery and attempted to measure the voltage:

The pad seems to vary in voltage when it’s hit. It doesn’t fluctuate when it’s not hit.  I’m quite willing to accept that wiring up a 9v battery is less than ideal here but it’s indicative of the fact I *will* need the ADC.

The drum pedal really acts as a switch so an ADC isn’t required here.