I have not yet crossed this item off the list, but naturally in order to get underway I should first at least own a dippy  bird. It turns out they can be had from DealExtreme for a very reasonable $4, so I’m now marginally closer to achieving a life goal. I don’t have an application in mind just at the moment; the classic is pushing a button repeatedly or triggering a motion sensor but to my immeasurable displeasure neither of those represent a problem for me right now. Since I haven’t yet  identified a clever use, today we’re going to talk about  a completely stupid one: a drinking bird as a temperature sensor.

The dippy bird is a popular physics toy, because it demonstrates a lot of interesting thermodynamic principles (actually that’s not entirely true; there’s no such thing as an interesting thermodynamic principle). There is no shortage of explanations online about how the toy works, but to recap:

1. The bird consists of two chambers (body and head) connected by a tube; the body is filled with a volatile solvent.
2. The head is covered in felt; when the felt is wet the head is cooled through evaporation.
3. This lowers the pressure in the head and draws liquid up the neck
4. The bird becomes top heavy and tips over, which empties the liquid back into the lower chamber. Cycle restarts.

The traditional glass of water just serves to keep the felt wet; the bird will continue to dip without it until the head dries.

As mentioned, there is a lot of physics happening in this bird, but as an experimental physicist I have no intention of invoking specific evaporation enthalpies or endoreversible heat engines. What I see when I look at this toy is:

Dip period = f(temperature, humidity, wind)

where f is some function containing thermodynamics voodoo. I don’t particularly care about predicting f, I just want to know whether there is a predictable relationship between dipping period and the ambient temperature. This would form the basis of our temperature sensor. I figure I should be able to just take some measurements and work something out empirically.

Taking data

I set up the bird next to my desk for a few days with some data logging electronics. I’m measuring three quantities: ambient temperature with a DS18B20 temperature probe, relative humidity with an HH10D capacitive sensor and dipping period with a photo-interrupter ripped out of an old CD-ROM drive. (I tacked a piece of business card onto the body to trip the photointerrupter). Since this is indoors, we can eliminate wind as a variable.

Science in action. Humidity sensor not shown

With a glass of water to keep the felt wet, the bird is happy to keep drinking for a very long time. I left this apparatus running for about 2 days, after which I got sick of it distracting me and dismantled it. This length of time constituted something like 5000 drinking cycles. The data is available here if you want to play with it, but allow me to plot it out:

 
Let me first note that the relative humidity (blue trace) is not calibrated (the I2C on that unit appeared to be broken, so I had to just use typical values), though I would still expect it to capture trends in the humidity.

The temperature (green trace) varies periodically over 24 hours as one might expect, but the overall variation is quite small since this is a climate controlled office (19.5 ± 1) °C.

The dipping period (red trace) is extremely noisy, and over small timescales quite unpredictable. I’ve marked two points of significance on the plot above. At some point I opened the window next to the bird, and with the rapid changes in temperature, airflow and humidity the bird went completely nuts (also reflected in the temperature). The second point happened when I topped up the glass the bird was drinking from, I’m guessing this temporarily spiked the evaporation rate.

Our first order of business is to clean up the dip period data, which I’ve done by running over it with a 30 point moving average filter. As you can see, this helped a lot:
 

 
Looking at the long-term trends in the data I can see something of a correlation between drinking period and ambient temperature (which is what we wanted), but the humidity doesn’t look like it’s having much of a bearing. To better demonstrate correlations, we can plot variables against each other:

 
From these we can see that there’s a clear (albeit slightly messy) negative linear relationship between the dipping period and ambient temperature. This is exactly what we would expect; as the temperature goes up the evaporative cooling is enhanced, so the drinking process goes faster. The second plot (against humidity) is a complete mess with no discernible relationship. Not quite what I would have expected, but oh well – for the present purposes it’s a good thing.

To bring things back to the idea of a temperature sensor: by fitting a line to the first  plot  above we get a formula for converting dipping period into temperature. How good is it?

 
Pretty good! And by pretty good, I mean “worst case error of 0.5 degrees in an operating range of 2 degrees, with a response time of approximately 15 minutes”.

Which is to say, barely passable. But hey, cut it some slack, it’s based on a frickkin’ dippy bird.

A dippy bird!

Is your heart made of stone?

Incidentally I did try to repeat the data collection at home where lately the temperature has been hanging around 14°C. Evaporation is then so slow that it takes the bird about 10 minutes to drink; so not ideal for a sensor.

Lest you suppose that I am alone in my ambitions, some kind of weirdo grasping desperately to the dream of a drinking bird toy serving a higher purpose, allow me to offer you some perspective from the scientific literature.

• Ralph Lorenz carried out a quite similar experiment to this in 2006, published in the ever entertaining American Journal of Physics (you should read it, it’s a great paper). As we’ve seen in the preceding plots, the dipping period is very erratic on small time scales. Ralph suggested using this as a seed for random number generation
• Ralph also noted that the water in the glass evaporates 10x faster when the bird is drinking it, and hence suggested that drinking birds might be useful as humidifiers.
• Don Rathjen of the Exploratorium discussed hooking up a ratchet to the bird to create a mighty 1μW engine.
• R. Murrow in a 1966 report proposed using dippy birds to irrigate crops near the Nile. I am not capable of making something like that up.

The madness began with a multimeter cake for a departing lab technician:

Sadly as an engineer he was unimpressed with a measely 3 digit meter

Over time things started to get out of control, with subsequent efforts over the years encompassing entirely edible renditions of:

• A gated silicon quantum dot
• Don Eigler’s quantum corral
• A silicon nanowire, along with a laptop measuring transport through it
• The Kane quantum computer

along with a few others. Sadly I don’t have a full set of photos to show you. Our most recent effort returned to the theme of measurement equipment with the venerable SR830 lock-in amplifier:

>100dB of dynamic reserve and >3 sticks of butter

At some point along the way I got it into my head that the pinnacle of cake achievement would be one of either:

• A cake with (edible) moving parts
• A cake with (edible) electronic functionality

In terms of electronics expertise I am a pretend embedded engineer in my spare time; in terms of mechanical expertise I am an unmitigated disaster who thinks all solutions begin and end with a hot glue gun. I recognize that my best hope of success lies with edible electronics.

You will probably not be surprised to learn that very few electrical components can be rendered in an edible form. Even the most basic element, low resistance wiring, is difficult. The first (edible) thing that comes to mind is something based on salt, but there are two problems with this:

1. Nobody wants to eat a cake decorated with some kind of gross salt paste, with the possible exception of the Dutch (see: Salty Liquorice).  I am all about putting gross salt paste on my toast, but not my cake.
2. Ionic conductivity is not very good. Wikipedia tells me that seawater has a typical resistivity of 20 Ωcm, which means a 10cm long, 5mm diameter tube of it would be about 1kΩ.  This is not outrageous, but suggests that you would need to use something very salty to get reasonable wires.

The breakthrough came when I discovered that edible silver foil is a real thing, that you can buy. It’s popular in Indian sweets, and provided it’s relatively pure it is generally regarded as safe to eat – the foil is only a few microns thick so the quantities involved are low. (As always, you will find dissenting opinions on the internet; certainly go and do some reading if you’re concerned).

In truth it was The Hungry Scientist Handbook that put me onto this, and furthermore they had even gone ahead and done exactly what I had in mind! Their recipe (see here) used silver foil wrapped around liquorice strips to illuminate a chain of LEDs on a cake. (Obviously the LEDs are not edible, but hey, you have to start somewhere)

Clearly it would be necessary to raise the bar. Instead of a chain of static, battery driven LEDs on a cake,  I want … a scrolling LED sign cake.

Ok, so maybe we relaxed our typically stringent aesthetic standards this time…

And that’s exactly what we did. Because writing something in icing is last century my friends. By coating only one side of a liquorice strip with the foil, you can cross wires without them shorting to each other. Then you just have to lay out a matrix and stick your carefully cleaned LEDs into the straps. A microcontroller is driving the LEDs to scroll out a message. For the curious, the source code is here. It’s written for an ATMega8 running on the 8MHz internal oscillator, but will also compile on the Mega48…328 line. It should be easy to employ for any 5×8 LED matrix, cake or not.

It all sounds very easy, and I have so far been describing it in the manner of somebody who has realized absolute success in their venture. Sadly that is not quite the case.  The truth is that the cake was something of a failure, saved only by the temerity of its vision (and also its deliciousness). It turns out that silver foil is extremely difficult to work with. In the final product we ended up with a lot of hairline cracks in the foil which resulted in a number of broken connections. A few LEDs still flashed in time, but not enough to carry the effect.

So the cake ended up being salty anyway. Salty from my tears of shame.

Here is the sign executed on a more conventional LED matrix (halfway through my camera gets out of sync so it looks a little funky). If you’re reading this Mark, here’s what I was trying to say:

I’ve put this post up for two reasons:

1) Despite failing in the end, it was still awesome.

2) Hopefully some kindred spirit out there takes what I’ve learned and has another, more competent attempt at it. Please do, and please let me know how it goes!

P.S. I’ve since seen edible silver paint being used which looks much easier to work with: http://www.youtube.com/watch?v=pdAqI8IAxCE

• Play
• Pause
• Turn it off until the battery runs out

As it turns out, iPods have some remote control functionality through the dock connector, and since we live in the future all the details of the protocol and the connector pinout are  nicely laid out on the internet. The solution to the broken button dilemma was therefore pretty straightforward: employ a microcontroller between the iPod and an external pushbutton, sending serial commands to mimic the behaviour of the regular play/pause button. Essentially I built a single button remote control.

Dock connectors are available at Sparkfun for $4. Looking at it you can see that there’s some space in the shell to stuff some electronics, and even a hole where the cable normally goes that we can use for a button.

Order two; you’re pretty much guaranteed to screw it up the first time

The smallest micro I had on hand was an 8-pin through-hole ATTiny13. This will fit, but only without a PCB. A surface mount version would be more sensible if you wanted to go about this in a more carefully planned manner than me. There’s not a lot else that needs to go in; the Tiny13 has a 9.6MHz internal oscillator and you can steal a clean 3.3V from the iPod on pin 18. The only external components I used were:

1. 10kΩ pullup on the Tiny13 reset line
2. pushbutton
3. 10kΩ pullup on pushbutton
4. 470kΩ across ipod pins 1-21 to enable the serial interface

I just soldered the wires and resistors directly to the Tiny13 and the connector (tricker than it sounds). Unfortunately I didn’t take any pictures, but just imagine a messy pile of crap and you’ll have the idea. The finished product looks like this:

There’s a bunch of hot glue holding everything in place. I actually tried some $0.20 cyanoacrylate superglue first, but that stuff is crazy runny. I was testing the circuit on my own iPod at the time, and the glue immediately wicked up through the connector and backfilled my iPod with superglue. Recoverable, but not cool.

To minimise drain on the iPod battery the program keeps the Tiny13 in power-down sleep mode for most of its life. According to the datasheet this should result in a 500nA supply current, with momentary periods of a few mA when you push the button and wake it up. That’s what the literature says, but purely because I can I went ahead and hooked one up to a preposterously expensive piece of DC measurement gear, the mighty 236-SMU from Keithley:

This was measured with a supply voltage of 3.3V, running initially on the 9.6MHz oscillator then switching into the power down sleep mode. The resulting current draw is a paltry 185nA, better than expected from the datasheet.  Considering that the iPod battery is (I think) 400mAh, it would take nearly 250 years for this thing to drain the battery. Basically what I’m saying is it’s fine to leave it plugged in.

I never cease to be astonished when I make something and it actually works, and this is no exception since it does indeed work very well. The source code is here for those after more details. It’s a very simple control loop based on interrupts from the pushbutton; the most complicated aspect is the software UART. The iPod doesn’t seem very picky about the baud rate; I shot for 19.2k but the stability of the 9.6MHz internal oscillator is not stellar … the thing worked fine regardless.

If you’d like more information, you can read about other ipod interfacing projects here and here

Let me show you where I was actually headed with this project:

That’s right my friends. Gameboy on an oscilloscope. I’ll walk you through the details of what’s going on here, but if you’re feeling impatient there’s a YouTube clip at the end of the post.

This project can be pretty cleanly broken up into two parts: Getting the data from the Gameboy and then displaying it on the oscilloscope.

1) Getting data from the Gameboy

When I discussed the video signals earlier, I implied that they were slow enough to be trivial for your typical 20MHz 8-bit microcontroller. In actual fact a 4MHz datastream is fast! You get 250ns between rising clock edges, and in that time you need to:

• Wait for the clock edge (it’s not perfectly synchronous, so you can’t just use a 4MHz timer)
• Read the digital value on two pins
• Store that value in memory somewhere

At 20MHz, you’ve got 5 clock cycles to do it. Good luck with that.

I thought about this for a while, and decided what I needed was some kind of serial→ parallel conversion. That way I could read in 8 bits at a time on each channel, and only have to do it every (250ns*8)=2μs. Since I’m not yet one of the cool kids who plays with FPGAs, I started doing this with 74 logic – counting clock pulses, latching data from a serial-parallel shift register every 8 counts, so forth and so such. It took a while.

And then a month into setting up this complicated circuit, it struck me that I am a moron; that most microcontrollers already have exactly this feature and it’s called SPI. Also since SPI modules are done in hardware they run much faster than you could do in software, definitely fast enough to keep up with this video signal in any case.

With that little design hiccup aside, the rest went pretty quickly. I’m using an XMega128A1 controller on one of Justin Mattair’s XMEGA development boards. This thing runs at 32MHz, and is a great option for this project because the XMega series have peripherals coming out of their asses. Seriously, there’s 4 SPI modules, 2 DACs, something like 800 timers and probably a couple thousand UART modules, I lost count.

In this case having two SPI modules makes life very easy – one for each data channel. I gave each module one of the data channels and the clock signal from the Gameboy. The HSYNC and VSYNC signals go to IO pins to keep everything synchronized. I’ll try to keep this description fairly high level; check out the source code if you want to get into the details.

The only other thing to attend to is level conversion – the Gameboy is giving 5V signals but the XMega wants 3.3V. Since this is a read-only arrangement, it’s sufficient to just use a voltage divider on every signal line.

The end result of this is that I have a couple of arrays of pixel data that are being updated in real time. All I have to do is find something suitably cool to do with that information.

2) Putting it on a frickin oscilloscope

Here’s a shot of the hardware, which I’m now halfway through describing. The other half consists of the digital-to-analog converters responsible for driving the oscilloscope.

One of the neat things about analog scopes is how easy it is to repurpose the display. You are typically given the option to switch from  the time-sweep mode of operation to instead control the brightness and x-y deflection with analog voltages. Which means you just have to stick some DACs on your micro to produce those voltage signals and you have a video display! There a whole bunch of great projects along these lines; two very noteworthy examples are Jan’s clock and Matthew’s incredible terminal console.

The scope I have is a PM3065, a 100MHz dual channel cathode ray scope and apparently a collaboration between Fluke and Phillips.  I paid AU$130 second hand last year. Importantly it has a BNC input at the rear for controlling the beam intensity (“Z input”), in this case going smoothly from full-on at about 0.8V  to completely blanked at about 1.06V. The exact numbers depend on what you have the intensity knob set to, but 26mV is more or less the range.

Let’s discuss the X-Y control first. Switched to XY mode, the voltage on the first input controls the X-deflection of the spot and the second controls the Y-deflection. By applying sawtooth ramp signals to both inputs you can raster out a square.

Tracing out a square in XY-mode

To match the Gameboy resolution we need a resolution of 160 x 144 pixels (DAC steps), and to get a halfway decent framerate we’re going to need to sweep them pretty fast. The analog voltage range is not particularly important because we can easily adjust the gain settings on the scope.

This is where the boatload of inbuilt peripherals on the XMega comes in handy again – it has 2 inbuilt 12-bit DACs that can run at 1MHz. They have a little bit of non-linearity at low and high values, but with 4096 (12bit) resolution there’s plenty of room to just add an offset to the ramps.

We’re nearly there – all that’s left is to set the intensity at each point of the raster according to the pixel data read from the Gameboy. Sadly we’ve used up the 2 inbuilt DACs to do the rastering, but since we only need 2-bit control a simple R2R ladder will suffice. There’s a little bit of fine tuning required though – for the intensity modulation input we need something like 9mV steps with about 800mV offset. Here’s what I’m using:

Schematic for the R2R DAC controlling spot intensity. Values in red are what I actually used.

Pretty straightforward I hope. I built it all on breadboard with multi-turn potentiometers so I could easily tune resistor values/swap things out. By putting a 2-bit value on DB1 and DB2 with a couple of IO pin on the XMega, we get an analog voltage out with an adjustable step size and offset. A good check that this works is to put the scope on regular (time sweep) mode and watch the R2R analog output. You’ll see the discrete values, and if at the same time you connect that output to the intensity modulation input you get something like this:

Demonstrating intensity modulation

From there it’s easy to play with the various potentiometers until you get 4 different spot intensities (as I have in the picture above).

And that’s pretty much it! The program logic is along the lines of:

Capture a frame:

Listen in on the video data until a new frame starts (VSYNC pulse)

Capture the pixel data for that frame with the SPI ports

Draw the frame:

For each pixel in Y (0…144)

Increment the Y-deflection DAC output

For each pixel in X (0…160)

Increment the X-deflection DAC output

Set the R2R DAC value for this pixel

Repeat

The XMega is capable of capturing data at the full 60Hz that the Gameboy is refreshing, but in the above scheme we stop capturing when we draw a frame to the screen. While that’s going on we miss some frames; at the moment it captures one then skips three. This gives a 15Hz refresh rate on the scope. Here’s a logic analyzer capture that shows this going on:

Logic analyzer of the NintendOscope; showing 6.5 screen refreshes.

The signals of interest here are #3 (Gameboy rereshing screen), #5 (XMega capturing data) and #6 (XMega drawing). #3 is just the VSYNC signal from the Gameboy, while I’m getting #5 and #6 from flashing status LEDs on the XMega board. #5 goes high while it’s reading in a frame, #6 while it’s drawing on the scope.

15Hz is a slow enough frame rate to be kind of annoying. The XMega has the speed to push this up to at least 20Hz,  however at that speed the image starts to look terrible. I’m using a 1μs delay after each pixel to give the DACs time to settle. We can check this out with the scope by looking at DAC sweeps:

Settling times for the horizontal raster DAC (left) and spot intensity DAC (right). Timebase is 2μs/division

Unsurprisingly the culprit is the R2R DAC output, which is being passed back and forth all over a breadboard. It’s taking about 1μs to settle after small changes and nearly 2μs for large changes. Hence the 1μs delay in the raster loop – it sharpens up the picture at the expense of refresh rate.

It would be very easy to improve on this by simply relocating the R2R ladder and amplifier to some stripboard or a proper PCB. Alternatively you could think about scrapping the R2R DAC for a decent IC version, or shopping around for a micro with 3 DACs.

And now I’ll leave you with a video of it in action. Sound is coming from the Gameboy speaker, and the weird horizontal brightness bands are an artifact of trying to film it. Enjoy, and be sure to let me know if you try something similar!

If you read the datasheet for those ICs – the ES519xx series – you’ll make the interesting observation that they all do RS232 compliant output. So a vast number of multimeters – quite possibly yours - are capable of serial communication, but most manufacturers don’t break it out to the front panel for you.

Fair enough perhaps – it adds to the cost and it might not be a popular feature that everybody wants. On high end bench instruments (voltmeters, lock-in amplifiers, electrometers…) it’s a completely standard feature. Typically with those instruments you’re recording a lot of data, and you don’t want to be writing it down on a piece of paper like some chump from the 1960′s. For hobby applications, let’s imagine you want to monitor the resistance of a sensor… once a second. For 2 days. Maybe you want to measure the temperature of a heatsink as a function of the current going into your circuit to determine some operational limits. Maybe you built your own signal generator, and you want to calibrate it by measuring with a multimeter in 1Hz steps. And so forth and so such; I’m basically telling you that this can be a pretty handy tool to have kicking around.

I’m accustomed to only seeing serial output on $100+ meters, and even then it’s not guaranteed. If you’re willing to scrounge around it is in fact possible to find an RS232-enabled meter at a reasonable price – at $35 this TekPower from Amazon is the cheapest I’ve seen so far. But as you might have guessed, if you already own a CyrusTek based meter I’m about to spell out for you how to do it even cheaper by extracting the latent RS232 functionality from it. If you’re willing to cut some holes in your prized possession that is.

I’m going to show you how to do this on an ES51973 based meter that I have lying around, an overpriced $300 ‘ISO-TECH IDM 98II’. For different Cyrustek controllers it will obviously pay to read the datasheet – these are readily available on the net – but I don’t imagine the process will be much different to this.

Let’s crack this thing open and have a look:

The guts of a CyrusTek meter

Let me highlight that this is not an RS232 meter, there is no provision for it anywhere. That said, to enable serial output you just need to touch the ‘RS232′ pin to the ‘V-’ pin. You’ll hear it beep, and you might even see an RS232 segment light up if the LCD has one. Note that this mode is not permanent – you can change measurement settings without losing it but every time you turn off the meter it will leave this mode. You’ll want to rig up a momentary contact, normally open switch across these two pins and make it available from the outside of the case. I’m going to leave the build details up to your engineering imagination, since this is not actually my personal meter and I’m therefore not at liberty to cut holes in it. (“If you can’t open it, you don’t own it. But sometimes if you don’t own it, you can still open it”)

Enter the Konami code Touch these two pins to enable serial output

The meter is now continuously ralphing out data – there is a 3V, 2400 baud serial signal appearing between ‘SDO’ and ‘DGND’:

Serial out!

Note the voltage levels; if you call DGND 0V, the serial signal will go between 0 and -3V. But because it’s battery operated we actually have some freedom to chose where we put the ground reference. To capture some data I attached a USB logic analyzer with it’s ground on SDO and the signal line on DGND. This gives an inverted serial signal which stays positive (0 to 3V).  Here’s what you see:

Capture of the serial data

On the ES51973 it comes in 11 packet chunks (1 packet=start bit+7 databits+stop bit+parity bit), and will tell you all sorts of things including the measurement function, range and the measured value. You can refer to the datasheet to decode the databits. In the example I’ve shown above the meter was set to resistance mode with no probes connected, hence the overload condition.

As long as you’re going to be quite careful about what you do with the multimeter and it also remains battery operated, the easiest way to get data out is to directly wire to the SDO and DGND pins like I’ve done above. In general it’s not a great idea though; you’ll find a more common approach is to maintain electrical isolation by optocoupling the pins. This is also an easy way to see if you have things working – use a visible LED and you’ll see it flashing if you have serial data present. Alternatively if you can find enough room in the case you could think about something really neat like hiding a microcontroller in there to read the datastream, parse it and send it out wirelessly.

To see how the professionals do it, let’s crack open another meter that was built with RS232 in mind. My own primary meter is a freebie SDA2010 (RRP $320) which has a miniUSB jack at the top and some custom software to interpret the data.

The guts of an SDA2010

In this case the controller is hiding under an epoxy blob, but it’s still pretty easy to see the optocoupling arrangement. An infrared LED placed across the two serial pins shines onto an infrared receiver on a separate board. To be really, really sure about electrical isolation that second board is sealed up in a plastic casing. On that board is a UART to USB chip, powered over USB. All parsing of the serial data happens in the custom PC software.

This seems like a pretty good solution, but again I leave the choice of implementation up to you. Now that you’ve seen how simple it is, go bust open your multimeter in search of an exposed Cyrustek chip! I’d love to hear from anybody that executes a modification like this.

As evidence that I’ll never be a professional electrician, while doing this I managed to accidently short a section of the control board to earth with a screwdriver. While I didn’t die or cause any damage, I did make the door start to close.

As evidence that I’ll never be a professional electrician because I am a too much of a physicist, my next move was to do it again to see if it was reproducible. And yes, here was a way to open and close the garage door – touch these two points with a screwdriver.

And so within about a week I had some wires attached to those two points, running along the rafters and down through the wall to a microcontroller circuit mounted on the external wall of the garage.  If the correct code is entered, a relay does the work of my screwdriver and opens or closes the door. This is a useful function for my parents, saving them from walking the long way around the house if they need to get into the garage but don’t have the wireless remote on them.

(And yes, if you were clever you could just rip the box off the wall and short the relay, bypassing the key-code. But there are other ways into the garage anyway,  so I don’t think you could really call it a security risk.)

The schematics are long gone, but the source is here. I think it was for an ATMega8 (?). I wrote in it about an hour, it just handles a keypad, a relay and plays some super cool tunes on a piezo buzzer. It’s a boring read, but hey whatever floats your boat.

I can however show you a video of the thing in action:

The reader is one of the Omron V3A series, which if you read some of the many websites discussing swipecard readers is a pretty popular choice due to it being easy to interface. Mine is a 4K model ($30 from Digikey) and reads track 2 data. Ideally you want all three tracks, but it gets expensive and for the majority of cards track 2 is where the interesting data is. For an in-depth discussion about swipe card encoding standards the best reference source is the “Magtek IO” pdf , which is very google-able.

Eventually I did get around to hooking it up to a microcontroller and satisfying my curiosity about my various cards. For the most part there was nothing all that interesting on any of them, until I ran my university ID card through. The only data encoded on it was my university ID number!

Why is that significant? Well, that ID card is used to access a variety of offices and laboratories across the campus. Staff and student ID numbers are publicly available. If you had the ability to either fake a card or encode a blank, this implies that you could open any door provided you knew the name of one person authorized to open it. You’d never need to lay hands on their card – just look up their university ID number, operate your device and walk on in. I was dying to know if the situation could really be that bad.

Card writers are readily available – Sparkfun has one for $140 and blank cards for a dollar. However since I’m not actually planning to illegally access anything or steal equipment (most of the good stuff is in my lab, anyway!) I’m not really keen to sink a lot of money into it. $140 is cheap for the technology, but too pricey just to satisfy my curiosity. We are left with option B: a swipe card spoofer. That is, a device which will fool a card reader into thinking you swiped an arbitrary card.

The basic design behind such a device is not my own work and I’m not the first to do this; you can find a few projects around to implement a device like this. That said, I’m just a dude choosing his projects for no higher purpose than his own amusement, so let’s set aside issues of redundancy and enjoy this, a fourth example of a mag-stripe spoofer.

Very basically, a card stripe contains a certain sequence of magnetic fields which the reader detects as you swipe the card through it.  The basis of all the card-spoofing circuits is to make some kind of electromagnet, put it next to the read-head and manipulate the magnetic field in just the right way to mimic a card. My design is heavily based on Jarek’s design which you can find here (highly recommended reading). The idea is to create your own electromagnet by winding a coil, but since your coil will probably not fit inside the card slot you employ a ‘shim’. In this case that means a thin ferromagnetic core for your electromagnet which nicely couples the field to the detector in the card reader.

Before we go too far into the details, let me show you my finished shim so you have some idea of what I’m talking about:

Completed electromagnet

I used an old knife blade for this purpose. You first need to check that the thickness is good for the card slot and that the blade is ferromagnetic (e.g. will a fridge magnet stick to it?). I used a dremel to file out the dimensions I wanted and get all the edges smooth, which generated all kinds of sparks and made me feel extremely manly. Smooth edges are important for the next step; you can see in the picture where I’ve used some black electrical tape to cover some leftover sharp corners.

I then set about wrapping a coil of enamel coated wire around the shim, the thinnest I could get locally (0.25mm diameter, from Jaycar). Enamel coating is important because you don’t want the coil to short itself out. Sharp edges are bad news because they will cut through the enamel coating and give a short.

The strength of a magnetic field generated by a coil goes linearly with the number of turns, so for best results you want a lot.  I honestly don’t remember how many I did, but it was a lot – maybe 100 or so turns? It was not optimized in any way, I just wanted to be sure it would work first time. If you wanted to keep the size down I’m sure you could do some testing of the minimum field strength required. After I finished I wrapped the coil in some more tape to protect it, and soldered on a standard 0.1″ 2 pin connector.

Now that the difficult part is done, you need something to intelligently power this coil so it creates the right field sequence. I put together an AVR board based on the Tiny2313, which as we will soon discover was not a clever choice.

The features I wanted were:

• Should be as small as practical so I feel more like an awesome spy. Lots of surface mount components, and a professionally made PCB (from batchPCB.com)
• Needs a powerful, compact battery to run the coil. Also needs to be something I have hanging around. I went for a 9V, and designed the PCB to have the same outline as a 9V battery so it could sit on top of it.
• Should be able to store card sequences in memory and let me select which sequence to generate
• Should be able to interface to a card reader so I can record a new card just by swiping it instead of needing a computer
• However if I do have a computer handy, I should be able to use it as an RS232 adapter for the card reader and display decoded info on a terminal.

Here’s what I came up with:

Final schematic

Completed, assembled board

(Note the ‘aftermarket’ resistor at the top – I forgot a pulldown resistor for the transistor base. The schematic has been corrected with resistor R4. Also the pullup R2 was actually 4k7, I’m just lazy with putting in component values on schematics)

There is a main on/off power switch and a 5V linear regulator for the Tiny2313, which is running on an internal 1MHz oscillator. The Tiny outputs the selected card sequence once a second on one of its IO pins, but a momentary push switch isolates that from the transistor driver. So nothing actually happens at the coil unless I’m holding down the ‘SEND’ switch. The transistor driver is required since we want to use the highest current possible to get the biggest magnetic field possible. AVRs have pretty high source/drain ratings on IO pins, but we want even more.

Note that you don’t actually need to swap the polarity of the coil current; it suffices to just switch it on and off. That makes the drive electronics a lot easier. I put a reverse biased LED in parallel with the coil to be my snubber diode for the inductive ‘kickback’. I would not in general recommend this, but it was the only kind of diode I had on hand so I went with it. As a nice side effect you get some visual feedback when the coil operates. It turns out you also get some audible feedback – the magstripe reader makes some sick-sounding bleepy noises when you fire the coil with the shim in place. Not entirely sure why, but it heightens the sense of being a wicked cool hacker from a 90′s film.

The rest is pretty ordinary; a menu switch and some leds to cycle through memory slots, headers for a serial link connection and for a magstripe reader connection. The final assembly looks something like this: (Battery ‘unfolded’ from the PCB; logic analyser on the Omron reader)

Tomfoolery in progress

The good news is that it works! As captured by a logic analyser, here is the output from swiping my real ID card, and under that is the output from faking my ID card. The extra channel on the spoofed data shows you what the I/O pin driving the coil was doing to generate this.

Logic capture of an entire card swipe / fake card swipe

To clarify the operation of the ‘card detect’ signal from the reader: I initially thought this was based on some kind of mechanical switch that detected a card in the slot. But it’s not – it’s just based on getting a certain number of coil toggles. So you don’t need to swipe the shim, you can just place it in the swipe slot so it’s sitting on the read-head and go for gold.

Zoomed out this far it doesn’t look like a very good match, but if we look a little closer we can see that the spoofer did indeed make the card reader produce the same output sequence:

Zoomed in logic captures

(This also hopefully clarifies the coil sequence; within one clock period a single toggle causes data high and two toggles causes data low)

So awesome, I succeeded at the dubious art of magstripe spoofing! However as mentioned earlier the Tiny2313 was a bad choice on my part – there was not quite enough program memory to implement all the neat features I listed above. I should have gone with something like a TQFP mega88. Lesson learned, always leave yourself plenty of headroom while you’re still at the prototype stage. Slashed down source code for the Tiny2313 is available here here (link fixed!). It’s very much thrown together; I’m putting it up so you can pick out any interesting parts if you’re having trouble making your own.

So after this technical diversion, let’s resume the story. Now that I can fake a card, was I able to open a door knowing only an ID number?

Sadly (but at the same time happily) no, it didn’t work. There are a few possibilities here, but my suspicion is that whoever designed this security system did a decent job of it and used more than one data track. So in reality there is probably more than just the ID number on the card, but with only a track 2 reader that’s all I saw. The design of the spoofer I’ve discussed can only fake one data track, which could still be interesting in some applications but is not enough here. (In principle you could fake three tracks at once but you would need a very complicated shim).

So my suspicious looking entry device was rejected and my office door remains secure against this manner of skulduggery.

However the upshot of such a dismal screen is that the battery life is phenomenal, and this was instrumental in the Gameboy being such a spectacular success.  And when lots of big developers get involved, you get graphics that are actually pretty nice.

Brilliant pixel art in 4 shades

Twenty years later the hobby electronics scene is thriving and there is a wide variety of powerful, cheap hardware. You now have an army of people like me who are not embedded engineers, but have 20+MHz microcontrollers and a passionate desire to build stupid, pointless crap with them.

And those people may be interested to learn that because it’s so low-spec,  it’s quite straightforward to hijack the gameboy display for whatever nefarious purposes you please.

[EDIT: Based on some of the feedback I might not have made the point of this project perfectly clear. I'm not interested in re-using the screen (because the screen is terrible as discussed above). I want to access the video data from the gameboy so I can display it on something more interesting. You may of course do whatever you please with this information]

Let’s discuss how to go about this. A good source of information about the gameboy hardware is devrs.com. Particularly handy is the schematic by Jeff Frohwein:

Direct your attention to the “LCD Display” block on the left

The signals we are interested in are VERTSYN,HORSYNC, DATAOUT0, DATAOUT1 and CLOCK. These are the control lines for the LCD coming from the central processor (which is not shown in this schematic). I’ll explain how these control lines work in a moment. First we’ll discuss how to tap into them, which should enable us to reconstruct the images being sent to the LCD.

Just opening a Gameboy turns out to be one of the most difficult steps, thanks to stupid Nintendo and their stupid tri-wing screws. After several attempts with flathead screwdrivers I gave up and bought a triwing driver from ebay for a few bucks. Unless you’re happy to smash up the case, I suggest you do the same.

Once you do have it open, it’s not hard to find the signals we’re after with an oscilloscope or logic analyzer:

The LCD connector

Handily they’re 5V logic levels, but if your instrument does not have robust input protection then be careful of the -30V DC contrast signal! (I forget exactly which one, but it’s one of the lower 10 pins – use a multimeter to find it if you’re worried). The pitch is not particularly tight, so I simply soldered some ribbon cable to the LCD connector. It’s possible (but tight) to then feed this through the cart slot and still have access to the pins with the Gameboy closed up again.

With the gameboy on, this is the kind of data you’ll see:

Logic capture of one display line. This is too zoomed in to see any VSYNC pulses

Let’s discuss how these signal lines operate. The controller scans through each frame line by line, setting each pixel in sequence to whatever colour value is required. We start at the upper left of the screen, and start belting out pixel values.

The pixel clock pulses once for each pixel.  At the falling edge of the CLOCK signal, , DATA1 and DATA0 give you the 2-bit colour value corresponding to that pixel. You can see in the capture above that there is a large section of one colour in the middle of this line, where the colour value is 0b11.

Once all 160 pixels in the first horizontal line are done, we wait for a signal to move down and start the next line underneath. This is the role of the HSYNC line, and the signal is a rising edge.

Once 144 lines have been drawn, we wait for a signal to go back and start all over again with a new frame. This is the role of the VSYNC line, and the signal is a rising edge.

From the logic capture you can see that when a line is finished, the controller does not immediately start the next one. In fact over half the time assigned to each line is not used;  the pixel clock is not running. Specifically, we get 68.9us of deadtime after all 160 clock pulses before the next HSYNC pulse happens. After all 144 lines, we get 1.1ms before the next VSYNC pulse. This is not really an awful lot of time, so to do anything practical with this data you’ll probably be skipping some frames. Remember that 60Hz is the LCD refresh rate, but it’s not necessarily the speed at which the central processor is updating the screen.

As a proof of principle I exported a capture of the signal waveforms (with the excellent Saleae Logic) to my graphing software of choice (the excellent Igor Pro). After throwing together a very simple script to process the signals, we can indeed reconstruct the image!

Good grief, it worked!

If you’d like to play with this yourself, raw data from a frame (it’s not the same frame as the image above) and the Igor script are available below. Since WordPress apparently won’t let me post *.txt files, I have renamed them as doc files. I leave it “as an exercise for the reader” to change the file extension back if required.

Raw data

Igor script (be warned that it’s really something quick and dirty I threw together)

I have plans for this, and in a future post I’ll discuss doing something with it in (semi) real-time.

P.S. Of course I understand that you could get the same result, possibly a lot easier, with an emulator. But there’s just something pure about working with original hardware.

P.P.S. Navy Seals is an absolutely dreadful game. The other game I have on hand is Hook, which is even worse

[EDIT: Followup post here]

[EDIT (30/12/2011): If you came looking for gameboy hardware info, another great resource is this report by John Ernberg]