My home-designed printed circuit board displaying a test pattern. The rocket will eventually have 8 of these boards, interconnected by ribbon cables, plus several dials, gauges, and a joystick. "Thrusters" and "engines" will be controlled by the board as well.

When Jon first started talking about building a rocket ship treehouse for his kids, it sounded like a static display: other than the shape and the material, pretty much the same as any other treehouse. But then he started talking about features that would make it come alive: pilot-controlled thrusters! A paint-shaker that simulates the rumble of takeoff! I got excited. I told Jon I thought his plans were desperately lacking something. The quintisenntial artifact that screams "1950's-era fictional space program": lots of flashing lights and dials and buttons and beeps.

One of the things I've been meaning to do for the past few years is improve my working knowledge of electronics. And, fresh off completion of my automatic closet light, I was ready for a bigger challenge. I offered my services as an avionics subcontractor, and Jon readily agreed.

My original idea for the control panel, in April of 2009, was relatively simple: lots of seven segment displays, perhaps 30 of them total, arranged in 6 groups of 5-digit numbers of varying colors. I'd imagined them flashing and counting, a constantly changing sci-fi display of random numbers. As we'll see, I rather dramatically under-estimated the ultimate complexity – and fun – of the project. The avionics ended up being

• a stack of over 10 modular, interconnected boards, that
• collects input from dials, joysticks and a keypad,
• emits output via 7-segment digits and car gauges, and
• controls high-current devices, such as solenoid air-valves, that actuate the rocket's "engines" and "thrusters"

My original thought was to do what sounded easiest: get a microcontroller with as many GPIO (general purpose input/output) pins as possible, and attach each segment of each LED to one of them. With my target of 30 digits, each of which has 7 segments plus a decimal point, that's 240 total segments that need controlling. The biggest microcontrollers I could find only had about 100 GPIO pins, so I started thinking of a more complex design: two or three microcontrollers, each controlling half of the digits. My plan was to use "I2C" (a microcontroller communication standard) to have the two controllers talk to each other, in order to synchronize.

Luckily, I ran this plan past my friend Lew before going any further. He knows electronics pretty well, and suggested what I needed were some latches. A '259-model latch is a basic memory device; it can remember 8 bits, and asserts those values on 8 output pins. To change them, you twiddle 5 inputs: first, assert 3 address lines, to tell it which of the 8 outputs you're trying to change; then, assert 1 data line, to tell it what value that output should take; then, "strobe" (i.e., go through an asserted/unasserted cycle) the Enable line.

So, by attaching each of the 8 segments of an LED digit (including decimal point) to the outputs of a latch, it's possible to control all 8 segments using just 5 control lines -- the latch's inputs -- instead of 8. But, more exciting is that this scheme scales well. If I want 24 digits instead of one, I need only 28 GPIO pins: the three address lines and one data line can run on a common bus, shared by every latch. 24 GPIO lines are then needed for each latch's Enable pin, letting us specify which latch we're actually talking to; the rest ignore the address and data lines because they're not being strobed. That is, we can program a latch by asserting the segment number on the three shared address lines (which I'll now call segment select), asserting the value of that segment on the shared data line, and then strobe the one (out of 24) Enable lines corresponding to the digit we're trying to change.

But wait! We can do even better! Another clever device, called a demultiplexer, can reduce our pin requirements even further. '138 series demultiplexers take 3 address lines and one Enable line as input, and have 8 outputs. Unlike a latch, a demux only asserts one of its outputs at a time. When we strobe its Enable line, it strobes whichever of the 8 output lines we've selected using its 3 address inputs. Now, controlling 24 LEDs requires even fewer control lines: we can attach each LED to a '259 latch, with a common bus for the 1-bit data channel and 3-bit segment select, then attach each of the latch's Enable pins to one of the outputs of a demultiplexer. For 24 digits, we'd need 3 demultiplexers, 8 latches on each. Of course, the addressing input lines of the demultiplexers can also be shared. I will now call these shared address lines digit select. Then, connect each of those 3 demux's Enable lines back to the microcontroller. Now we can control each of the 8 segments of 24 LEDs using only 13 GPIO pins: 1 data line, 3 segment select lines, 3 digit select lines, and 3 pins that lead back to the Enable pins of the 3 demultiplexors.

But wait! We're still not done! Now we can add a 2nd layer of demultiplexors. In other words, have one "top-level" demux, and attach each of its 8 outputs to the Enable lines of 8 more demux's. I will call the 3 address lines of this top-level demux the bank select lines. Each of the 2nd-level demux's can control 8 digits, so this is now a total of 64 digits, each with 8 segments (or a total of 512 segments) that can be individually controlled with only 11 output lines on the microcontroller:

1 data line
3 segment-select lines
3 digit-select lines
3 bank-select lines
1 master enable line

Unfortunately we're not quite done. When I showed this plan to my friend and colleague JD, he pointed out a problem. The data and segment-select lines have a rather large fanout: the microcontroller asserts just one data line and it is taken as input to all 64 latches. Most parts are spec'd for a maximum fan-out of 10 or 15. So, we also have to add drivers -- basically amplifiers -- one for each of the 8 banks. That is, the microcontroller asserts data and segment-select lines to 8 drivers; each driver re-asserts it to 8 latches.

While the design seemed reasonable, the idea of assembling such a beast did not. Such a board would have hundreds of signal lines and close to 5,000 tiny holes that would need precise drilling. It didn't seem reasonable to try and fabricate it myself. I'd have to learn another new skill: how to draw a schematic and have a PCB professionally manufactured from it.

Board manufacturers charge by the square inch. We wanted the rows of digits to be spread out (leaving room in between for things like labels, dials, etc.), so I added one final feature to the design. Instead of one huge board with all 64 digits on it, I'd make 8 smaller, identical boards, with their 11 magical lines all connected to each other using a ribbon cable. I'd give each board a DIP switch that would let me tell it which "bank number" it was. I should then be able to put a microcontroller on one of the boards -- it doesn't matter which -- and let the ribbon cable distribute its 11 outputs to all the others. Then, we'd be able to manufacture smaller boards in larger quantities, rather than one huge board. Plus, it has the significant advantage of letting us spread the numbers out in the rocket ship a bit more.

With all this decided, I drew up a basic block diagram showing what each board would look like. I was so excited: the project was already paying for itself in teaching me new things!

The diagram above shows the latches, but doesn't depict the LED or resistors attached to each latch. Also, it shows my cheesy board-select method: each output of the first-layer demux is attached to one switch in a bank of 8 DIP switches. Then all the outputs are bussed together. So, to select (say) board 4, you turn on switch 4, and turn all the others off. With some more complex logic, I could have made it work in binary (allowing you to select 256 boards), but this thing was already complex enough and other aspects of the design limited us to 8 boards per stack anyway.

My next task was to pick a microcontroller. The first sub-task was to pick a brand of microcontroller. My only past experience with them was tinkering with some PICs with my friend Guy back almost 15 years ago.

(Aside: We'd tried to build a board we could install in his apartment's front-door intercom so it would unlock the downstairs door if someone pushed the buzzer with a secret morse-code pattern. We hacked together an assembly-code program that seemed to do the right thing on a test board: lighting up an LED for a few seconds when we pushed a button in the right pattern. But it never worked when we actually installed it. Guy's dad, an electrical engineer, suggested a few changed, including "pull-up resistors", which neither of us had heard of at the time and had no Google to help us, so the project fizzled.)

The microcontroller I picked was the Atmel Atmega8, an 8-bit microcontroller with about 20 digital I/O pins, as well as some analog-to-digital converters, which will come into play later in the story.

By May, I had a detailed plan in place. However, never having built anything even remotely like this before, the plan might have been completely nonsensical. Before drawing a more detailed schematic, I knew I'd have to do some basic component testing, starting simple and gradually getting more complex. I started ordering parts from DigiKey: the 7-segment LEDs, latches, and so forth.

The last time I'd tried to use an LED was when I was about 15 years old. I was really into electronics back then, but didn't have any good reference texts. One day, I saw a 7-segment LED in Radio Shack and thought "Wow, that would be cool to use!". It seemed simple enough: 7 individual power pins, one for each segment, and one common ground pin. I figured if I just attached a battery across the two, it would light up. I took it home and, unfortunately, couldn't get it to do anything. 20 years later, I started reading about LEDs and learned my problem: I had assumed that an LED was a resistive load, just like a light bulb. It turns out, diodes are magical things that cause a voltage drop but don't provide resistance. If you attach a battery directly across a diode, it's no better than a short circuit: the diode will immediately burn out.

The right design is to add a resistor, chosen so that the current flowing through it, taking into account the voltage drop inherent to the diode, is no more than what the diode says it can take. My plan was to run the system at 5V. The LED data sheet said that the diode drop was 2V. That leaves 3V "visible" to the resistor. My target was about 10 mA per segment so I picked a 300 ohm resistor (actually, 270: the closest value I had in stock).

My first test was simply to attach an LED segment to a 5V power supply and a resistor, to see if it would light up:

Wow! This was exciting. I'd already done way better than 15-year-old Jeremy!

Next I decided to try out a latch. I attached two segments of the LED to two of the latch's outputs (with resistors in between). Then I attached three buttons to the latch: one to the data input pin, one to the lowest bit of the "segment select" address line, and one to the Enable pin. And I finally learned just how to use pull-up/down resistors: you attach a high-value resistor to, say, a pin and ground. Then, on the pin side of the resistor, attach a push-button tied to Vcc. When the button is not pressed, the resistor (with no current flowing) keeps the pin at ground. When you push it, you tie it to Vcc instead; the resistor is so strong that the connection to ground is overcome.

If I pushed Enable without pushing Data, the segment would go out. If I hold down Data and then push Enable, it lights up. If I did all of this while holding down the Segment Select line, it would happen to segment #2.

I couldn't believe this was all working! I decided the next step was to get the microcontroller to flip the lines automatically, rather than me doing it manually with buttons. I hooked up all 7 segments to resistors and to the latch, and figured out how to use my new microcontroller programming kit. I made a table defining which of the seven segments should be lit up for each number 0-9, and each letter A-Z. (Some letters, like W, X, and Z, can't actually be represented by these displays.) Then I wrote a program having the controller cycle my LED through the all the numbers and letters. It worked!

Next I added a second digit and a second latch, and a first demultiplexor that would let me select which of the two digits I was controlling. The circuit was really starting to take shape now: I had a real data bus, and real segment-select bus, even though there were only two devices on each bus.

I didn't do any work on the project for several months for a combination of reasons: vacation time, work projects, biking from Seattle to Portland. Finally, at the end of August, I picked the project back up -- goaded by Jon who was making phenomenal progress on the physical rocket.

The next step was to try getting a board manufactured. I redrew my schematic using different software, Eagle, that made it easier to go from a schematic to a physical board. I also added a few other features:

• A new power connector -- with a 2-position locking molex connector rather than the screw-in connectors in my proto-board.
• A programming header, so I can program/test/program without physically swapping the chip between the board and the programmer repeatedly. Completely untested of course (I didn't prototype it -- just drew it based on documentation), but we'll see if it works. The most likely-to-fail thing about the programming header is the reset pin. A pin of the microcontroller, /RESET, has been tied directly to VCC in my prototypes. However, the programming board needs to do something funky with /RESET when it programs. So, I tied /RESET to VCC with a 10k pullup resistor, and put the programming board on the microcontroller side of the resistor. Hopefully, this means that when the programming board tries to actually assert either high or low, it will succeed, and when the programming board is disconnected, the resistor will keep the chip in the not-reset state.
• Horizontal bus connector on the edge of the board to make vertical board arrangement easy.
• Two 3-position molex connectors for attaching analog dials as additional inputs. Each connector has 1 VCC (output) pin, 1 GND (output) pin, and 1 pin tied to an ADC (input) pin on the microcontroller. I hope this will let us use analog dials/pots as input, but of course, this is completely untested.

I learned that it takes a lot of tweaking to get the board nice and compact. Early versions were way too spread out. Partly this was because Eagle's default minimum clearance between traces (i.e., the number of "wires" you can pack into a space) was conservative: 1/20'' (50 "mils") between traces. But, the board manufacturers I found claimed they could make boards down to 8 mils; the board got much smaller when I switched Eagle to using a 10 mil routing grid. I also tried to keep the wires from crossing where I had freedom. For example, the resistor ICs are symmetrical; you can go in on the left and come out on the right, or vice-versa. I had each wire enter the resistor on the same side as it exited the latch.

Finally, I ended up with a nice, compact board!

Exciting stuff! I sent this off to a PCB manufacturer in China called OurPCB and should have the boards back in two weeks or so. I'm getting 10 boards for $110. There's a $50 setup fee and $40 shipping; the boards themselves only cost about $2.50 each! Of course, if there were no shipping or setup fee, I'd make one board, see if it needs a correction, then get more. But since the boards themselves are such a small part of the overall cost, it's more cost-efficient to just order them all up-front if there's even a small chance they'll work. So I ordered 10. Keep your fingers crossed!

A rocketship just wouldn't be a rocketship without some dials to turn. I mean, how else are you going to adjust your fuel flow and tune your navigational radio? With a keyboard? Puh-leeze.

One feature I added to the PCB at the last minute was a couple of headers for analog inputs. Each header has 3 wires: power, ground, and a line back to one of the controllers' ADC inputs. I hoped that by attaching those three leads to a potentiometer, I'd be able to read the position of a dial. Unfortunately I didn't actually get a chance to test this before sending the PCBs out to be produced.

I ordered a bunch of panel-mount 50k pots that arrived yesterday, and scrounged a rocket-looking knob out of the hardware lab at work. This evening I tried hooking them up to my proto-board, and wrote a few lines of code that would read the analog input once every 50msec, scale it to a value from 0 to 99, and display that value on the two LEDs on my protoboard. Amazingly, it worked (almost) without a hitch!

(The only hitch: the ADC input I was using is the same pin as one of the general purpose input/output pins. I had set all I/O pins as output pins, so a low value was being asserted on the same pin the ADC was trying to read, and always returned 0 -- except when the pot was at such a high value that it overcame the internal resistance of the output pin. When I reconfigured the GPIO as an input pin, everything worked.)

Guess what was waiting for me when I got home from work yesterday?

There it is, hot off the Chinese presses -- v1 of the Rocket Panel Printed Circuit Board!

I soldered all the components on, loaded the digit-identifying program onto a new microcontroller, popped it in, and turned it on. It worked on the first try! Isn't it beautiful?

But wait, there's more! I soldered half of a second board together (alas, I had only 4 LEDs left) and put together a 16-pin ribbon cable a few inches long. I connected the two bus connectors and -- voila! Both boards are being controlled by a single processor!

As if that wasn't all cool enough, the programming header works, too! I was able to put new code on the microcontroller in place by just running a cable from the programming kit board to the programming header on my PCB. Total success!

There was one minor board bug I discovered even before receiving the boards: a wire I was supposed to connect, but didn't, that's needed to read from analog dials. But that's easy to manually fix.

Despite the fact that (amazingly) these boards work, I think I'm still going to order the v1.1 boards. They have lots of nice features, such as mounting holes, support for larger LEDs, support for 6 dials rather than just 2 (important because of our joystick, as I described on Sep 16th), and some other odds and ends.

Still on the To-Do list:

• Software, software, software! Jon's collaborating on that.
• Get v1.1 boards manufactured
• Build three special boards:
  • Interface board for the high-current devices like Jon's new solenoids
  • Power conditioning board to give us a nice 5v from the pneumatically-driven alternator
  • Digital potentiomter board to drive the gauges
• Figure out mounting: behind plexiglass?

Can you believe I'm running out of solder? That's like running out of baking soda. I think I've had my current spool of solder since I was in college.

Today I worked on the one part of this project that has been consistently dogged by failure: getting analog gauges attached to the rocket.

It's not too hard to find cheap used car gauges on Ebay. A couple of months ago, I paid all of $0.99 (shipping included!) for really cool-looking electroluminescent oil temperature and RPM gauges. We thought they'd be perfect for the rocket's control panel. Unfortunately, we couldn't figure out how to get them to do anything. They'd power up when attached to a 12V supply, but we couldn't figure out what kind of signal to put on the sense line to get the needle to move.

I learned that car part manufacturers don't document their interfaces as meticulously as most other electronics components. If you go onto Digi-Key and buy so much as a 7 cent LED, it'll come with 8 pages of documentation, exhaustively describing its electrical and mechanical properties. Car gauges seem to come with nothing more than a flyer that says "Put 'er in your car! Then go get a cigarette! Yee haw!"

After hours of web research I found a catalog page for a 3rd party fuel-tank sensor that said "Attaches to standard gauge (60 ohm full - 600 ohm empty)." At last, some data! Apparently you vary the resistance on that signal wire. I tried attaching our fancy gauges to a pot with the proper range but the needle still didn't budge. Finally, I speculated that perhaps the gauges were broken and that's why they cost $0.99. Jon took me on my first trip to a junkyard, charmingly named Pull-a-Part, and I paintakingly extricated a couple of gauges out of the dash of an Oldsmobile (I think). Hooked that up to a mechanical pot, and when I adjusted it with a screwdriver, the needle moved. Hooray! It's too bad those gauges are so ugly. The broken EL gauges looked rocket-y; the ones that work just scream "80s sedan".

That brings us to today. How do you get a microcontroller to provide variable resistance? I discovered a clever device called a digital pot that does exactly that: every time you strobe one of its pins, it increases (or decreases, your choice) its resistance among 100 pre-set values. Easy, right? I ordered a few of them last week, and today tried to get one working.

First try: breadboarded a prototype, using buttons to strobe the inputs, and measuring the outputs with an ohmmeter. Seemed to work, but jumped forward a lot every time I pushed the button. My little oscilloscope confirmed that button bounce was my problem (right).
Second try: I attached a capactior and a couple of series resistors such that the cap would slowly charge and discharge, smoothing the signal. It was sure nice and smooth, and was asserted far more slowly (milliseconds rather than microseconds), but the pot still jumped forward by several steps with each button press. Perhaps I need a smaller cap so the voltage doesn't camp out near the threshold for as long?
Third try: hooked the thing up to a microcontroller that did nothing but strobe pins. I hoped the controller would give cleaner transitions than my mechanical button. Much to my amazement, the pot seemed to just slide between its two extremes. What is going on?

Fourth try: the microcontroller and pot were powered off different halves of my power supply; maybe their grounds are floating relative to each other? I tied the two grounds together, and, success! I can now get the pot to increase its resistance by 10 ohms at a time.

Fifth try: I hooked the pot up to the actual gauge rather than an ohmmeter. Everything broke; when I put the ohmmeter back, the resistance was 10 kohm (even though the pot is only rated to go up to a max of 1 kohm!). Tried with a 2nd digital pot; worked with the ohmmeter, then broke when attached to a gauge. I took another look at the datasheet, and realized that the pot was only rated for 5v across its terminals at a max of 1 milliamp. What the hell use is that to anyone? The gauge has 12v from its its sense line to ground and when I hooked it up to an ammeter, it was pushing 250ma through it. Obviously I was just destroying the digital pots.

So ends the saga for now. I need to order some beefier digital pots and try again.

Everything has been working so well on this project up until now, I guess I was due for some failure!

Really, what is failure but an opportunity for future success? Ha.

I have been spending most of my days lately writing a paper for a work deadline coming up, but my thoughts occasionally drifted back to the problem of driving a gauge. A few minutes searching both Digi-Key and Google revealed that, for some reason, high-current digital pots just don't exist. No one makes them. People on the Internet ask where to find them and they're answered with "They don't exist." I don't understand why.

I started to think about taking a different approach. Really, why does the gauge want to see variable resistance? Presumably because it's measuring the resultant current. So, what if I found some other way to vary the current, other than varying the resistance? Transistors are current amplifiers ... might I use one?

People often use transistors as simple switches, because there is such high gain between what you put in the control pin (the "base current") and what flows through the high-current pin (the "collector current"). Put in any reasonable base current, and the collector current gets driven up to the transistor's maximum. This is called "saturating" the transistor. But there's a range of base currents, before saturation, for which small increases in base current give proportional increases in the collector current. I wondered -- could I try using a transistor in this way?

Yesterday, I measured the maximum current draw required by the gauge at 250ma for full deflection. (0 current gives 0 deflection.) It so happens I have some Darlington transistors here that have a current gain ("Hfe") of 20,000. So if I want 250ma of collector current, I'd need 250ma/20,000 = 12.5 microamps of base current. So I need a resistor on the base that gives me 12.5 micromps. Assume base voltage is 5v, transistor's forward voltage drop is 2v. That leaves 3 volts visible to the resistor. 3v / 12.5ua = 240Kohms. I attached a 200k ohm resistor to the base of my transistor, and sure enough, my gauge's needle went to full deflection and drew about 250ma.

Now, on to gradually reducing this current all the way to zero, so the gauge goes through its range of deflections. The easiest way to do this (rather than hugely increasing the base resistance) is to reduce the base voltage, using a pot configured as a voltage divider. That is, 5v and gnd on the top and bottom, of the pot and the base resistor attached to the wiper, as shown in the diagram to the right. I hooked up one of my mechanical pots and, sure enough, turning the pot got the gauge to gradually move between its two extremes!!

Sep 21st's entry showed a gauge moving when I had a mechnical pot attached, too. But there's an exciting difference here. Today's pot is only passing 12 microamps, not 250ma as before. In fact, I attached an ammeter in series with the pot, and it couldn't even measure the current flowing through it (its resolution was 1 milliamp). A dozen microamps is so small that I should be able to pass it through my digital pot, which is rated up to 1 milliamp, without melting it. I'll try attaching that tomorrow and see if it works! This is so exciting: another tool in my toolbox!

v1.1 of the PCB -- schematic and board layout

Everything in the v1.0 PCB seemed to work, but I decided to go ahead and order the v1.1 PCBs anyway. They have a lot of features that will make life easier and I feel reasonably confident they'll work correctly, given that v1.0 worked so well. So tonight, I spent about 30 minutes putting some finishing touches on the design and sent it to China for production. Most significantly, I changed one of the joystick headers from 4 pins to 5, and brought our one remaining digital I/O pin out to it, so we'd be able to read the state of the joystick button. Once I actually had a joystick in my hand, it was hard to imagine the fire button not doing anything!

I also added a reset button, some nice silkscreened labels on everything, and more generous clearance between pads and vias to make the boards easier to solder without accidentally shorting two nets.

Ever the eternal optimist, I ordered 20 of these boards -- enough for two full stacks, plus a couple of extra for development, or just hanging on my office wall. Why not, they're less than $3 each (plus $90 setup fee and shipping). They should be here October 5 -- something to look forward to after the NSDI deadline has passed!

Here's the final schematic and board layout. Note the schematic is much cleaner once I learned how to attach remote nets just by giving them the same name; the ugly and not-very-informative blue bus no longer snakes its way through the center. Plus, the bus connector's pins are all assigned to a logical name, rather than a microcontroller pin: exactly how it should be, since from revision to revision, we want the mapping of the logical function (e.g., segment select) to position on the bus header to remain consistent, but we don't really care which microcontroller pin is being used to drive the bus.

My beloved rocket panel got no attention for about 2 weeks because of an important October 2 work deadline. But as soon as that passed, back to work!

Today's main project was building a small board that would let the main rocket panel actuate the rocket's "engine" and "thrusters". As Jon briefly describes in his todo list, he's going to run compressed air to the rocket from his garage air compressor. This will power both the rocket's "engines" (actually a paint shaker that will vibrate the rocket for "takeoff"!) and its "maneuvering thrusters" (actually pneumatic engine cleaning guns).

Jon's original plan was to rig up some kind of mechanical valve to let the pilot turn these systems on and off from the cockpit, but I convinced him to buy some $18 solenoid air valves I found on EBay. That gives us the flexibility to have the thrusters controlled both from software and manually by the pilot We're going to write some sort of "launch sequence" program that will fire up the engines and thrusters; once in orbit, the pilot will be able actuate the thrusters using a joystick. Jon was resistant to the idea at first, but as soon as the valves arrived and he saw one turn on his paint shaker, he was glad the rocket's electrical and pneumatic systems would be working as a team!

From my point of view, the plan was to choose one of the eight identical display boards as the controller, leave off one of its LEDs, and use the 8 unused latch outputs as control signals for 8 valves. Unfortunately, the latches can only source 25 milliamps at 5 volts, but the valves need 500 milliamps at 12 volts. The solution: a small board with power MOSFETs, using 5v control signals to switch the larger 12v valve power. More for fun than anything else, I also put LEDs on the board that light up every time one of the channels is active.

Since we only needed one or two of these boards, I just made them by hand rather than getting PCBs professionally manufactured. And, to really give the thing that 50's Fictional Space Program feel, we gave the board a ridiculous name: the High Power Auxiliary Module.

The ultimate plan is to attach them to one of the rocket panel boards. But, I decided (half for fun, and half because it made good engineering sense) to build a small box with manual pushbuttons, and design the HPAM so it could be plugged into either a rocket panel board or the manual button box. For maximum ridiculousness, I used the laser cutter at work to cut the 8 button holes and put a Fake Space Program label on the box. It's the HPAM "Digital Actuator". See, because you press it with your digits. Your fingers. Get it? Yeah, not that funny.

The end result, I must say, is super cool. Here's a video clip of Liesl playing with the button box. Each button press lights up an LED. I also attached a test solenoid to Channel 3; if you turn up the sound you can hear it clicking when she pushes Button 3. I'm heading to Jon's place tomorrow to try it with a solenoid that has real air running through it .... how exciting!

The Version 1.1 boards arrived from China today! I have to admit, I wasn't quite as excited as I was for the v1.0 PCBs. I guess nothing can ever beat your first time.

The v1.1 boards were more evolutionary than anything else, as you might know if you've read the rest of the entries in painstaking detail. Perhaps the most visible change is that it now supports larger LEDs (0.56", vs the original that only supported 0.39"). Through some clever routing, a single board can take either size of LED, or a combination. v1.1 also have some convenience features: mounting holes, a reset button, more analog-to-digital converter pins now available, a joystick port (a single header with 2 ADC inputs, plus a GPIO input for the trigger button), and so forth.

To the right is a picture I took of the first v1.1 board with LEDs soldered in, showing that both the larger (green) and smaller (orange) LEDs work together. This v1.1 board doesn't have a processor yet; it's being controlled via the data bus by one of the older v1.0 boards.

I also have a glamour shot of my "signature" on the new PCBs. By v1.1 I'd figured out how to add custom silkscreening so I put my name on it.

The original bread-boarded prototype of the UART interface to the PC. The extra chip is a MAX-232 level converter that converts between serial port voltages and microcontroller voltages. Also visible is a probe of my oscilloscope.

The final soldered version of the PC side of the clock interface. Serial port data (right) and 5v power (center) are combined into a single 4-conductor cable (left).

The clock side of the interface board. The 4-conductor cable is broken back out into serial and power. The MAX-232 converts the serial voltages down to TTL voltages.

I was away on business travel for 4 days last week so didn't get a chance to do much hardware hacking. But, once I got back, I spent 2 days on a non-rocket use for the v1.1 boards: building a clock! I love clocks, and did my Ph.D. thesis on time synchronization, so this was right up my alley. My plan was to hang it outside my office so people at work would be able to see the cool stuff I'd been working on at home.

Of course, having written a time-sync dissertation, this clock would need to be accurate. My original plan was to signal the start of each second using a single GPIO line, but Jon convinced me to use a full-fledged serial port to send complete time messages. After some resistance (I was afraid the serial port would be too complex) I agreed.

The first step was to establish a data link between my PC and the board. I bought some MAX-232's, which are chips that convert the voltage used by a PC serial port to the voltage used by typical microcontroller. I prototyped an interface board that would take a PC serial port, short-circuit the flow control lines like a null-modem does, and put the 2 data lines into the MAX-232. I wrote code on the controller to configure the UART, accept serial port interrupts, timestamp them with high precision, and enqueue the characters. As a first test, I wrote a simple program that would just read characters and display them. It was surprisingly cool: I could type on my PC keyboard, and see messages scroll across the 7-segment LEDs!

Next, using my newfound power to get messages from the PC to the board, I set out to get my clock to tick correctly. I wrote a small program that runs on the PC which sends a message to the serial port once every minute, precisely at the beginning of the minute, telling the board what time it is. (The PC's clock is synchronized using NTP, via the Internet.) The clock board lets the clock run free in between the messages; when it gets one, it both sets the time and trains its oscillator so that the length of coming free-running minute will be accurate. It annoys me that most time-sync software doesn't do this; usually, they just jump the clock to the right value every few minutes, giving you a clock with a sawtooth pattern.

Finally, I built a permanent pair of small connector boards so I'd be able to feed both power and serial data into a single 4-conductor cable to run from my office PC to the clock.

If this sounds like a project that consists mostly of a hundred tiny little details, you're right. But the result is awesome, and I'd estimate remains accurate to within 20ms of the PC's clock throughout the entire minute between pulses:

It's now hanging on the wall outside my office. If you're ever at Microsoft, stop by 99/2374 and take a look at it!