This story begins in Summer 2007. Eliot is five.
Our back yard is mostly dominated
by a rotting deck, and the few square feet left over for lawn are
colonized by a knot of weeds. Christina decides it's time to landscape
the back yard, "for the children."
Christina shows me a sheet of paper with her plan for the yard:
a modest set of stairs here, mostly lawn, a flower strip along the
fence, and here under the trees: a treehouse for Eliot!
"Have you told Eliot about this already?" I ask, cautiously.
"Oh, yeah! He's really excited about it!" says Christina.
"Greeeeat." I say, realizing I've been committed. Then inspiration
strikes. Unfunded mandate? Fine. "Okay, I'll build a treehouse,
but I'm not going to spend a month just to make an ordinary
Nope, we're going to Boeing Surplus."
Before it closed
at the end of 2007, Boeing Surplus was a staple
in the Seattle maker world. There was a lot of junk there,
but many reports of great finds by the patient scrounger.
I live too far away to go often enough to get the really good stuff.
But Eliot and I scored four big sheets of really cheap sheet aluminum
(some polishing required), a bunch of smaller aluminum shelving,
and three 24-foot thick-walled aluminum tubes. We strapped our loot
precariously to the roof of the Ford Escort,
and drove home on a non-freeway route, to prevent the airplane parts from
become airborne before they were made into an aircraft.
Now how would I assemble this scrap into a treehouse? Welding aluminum
is probably more than I want to learn. I could bend and rivet it...
I spent a bunch of time on the bus designing a geodesic structure
that I could make by cutting triangles, bending flanges to make rigid edges,
and riveting the flanges together.
I brazed together a sheet-metal bender at my father-in-law's shop.
I wasn't sure the design was going to be big enough to be fun to play
in, so I set about building a full-scale model in the basement. Fir strips
represented the edges, and zip-ties secured them at the vertices.
I built one layer of the structure, and it wobbled so enthusiastically,
I couldn't make it stand up.
This experience made me doubt my extensive knowledge of geodesic
structures (specifically, I had heard of them before), and sort of put
the project on hold for a while.
(I suspect that, had I completed the structure, it would have been
somehow holistically rigid. But the balloon of enthusiasm had been deflated.)
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.
Jeremy Elson – jelson at the domain "gmail dot
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
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
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"
A year went by. Eliot got older. People asked about the sheet aluminum
in the garage, and I had to temper the story with caveats like
"if I finish before he graduates college."
Somewhere along, it occurred to me that my prior plan had some
unnecessary conditions: aluminum bend and rivet construction,
an understanding of actual engineering.
But this structure isn't actually going to get launched anywhere.
Weight is not a consideration.
Why not relax those constraints?
How about I just weld together a rigid steel frame,
rivet the aluminum onto that,
and be done with it already?
With this new freedom, I broke out my python 3D model again.
I built a simpler model, a series of tapered hexagonal prisms.
It looks more rocket-y, less lunar-lander-y.
In the model here,
the the opening in the lower section is the "door" hatch,
and the opening in the upper section in the "window" (to let
in a reasonable amount of light for play).
The topmost cone also hinges up.
The design called for creating in-plane quadrilateral surfaces on
the metal frame, so that each aluminum panel can be riveted along
all of its edges.
Father-in-law Dick pointed out to me that the hack welder uses square
tube, because it makes all the joints so much easier to assemble.
So I designed each face to consist of three segments of tubing that
share a plane with the corresponding aluminum panel. The fourth edge
of the panel lines up with the (tilted) corner of the tube for the
adjacent face; so a strip of steel is welded onto that tube to complete
the quadrilateral. This made for a minimal number of components.
The next challenge was figuring out how to cut the correct angles on
the ends of the tubes. I'm pretty good at working out the side-length
trigonometry for the wire frame, but those compound angles really made
I had a bill-of-materials spreadsheet that converted coarse measurements
("bottom segment has radius 24 inches") into lengths and quantites of
I extended it to also tell me what compound angles to cut on the end
of each tube.
The math was hard enough that I was still unconvinced that it would
work on real metal, so I then built a little python script that
simulated the effect of each cut on the miter saw, and emitted a
PostScript page that cuts and folds into a paper model.
One tube on each face requires two compound cuts on one end, to
provide clearance for the bottom edge of the adjacent face.
The math was indeed hard; the paper models showed an error on pretty
much every step.
I dropped a couple hundred bucks on steel at
I suppose this is a good place to go if you're, you know, some
sort of industrialist who actually builds things with steel.
The guy behind the desk always seemed to be "swamped" with work,
in a union-employee sort of way that meant he could talk to me for
10-15 minutes about why he hadn't even pulled my order off the teletype
yet. The yard guy, on the other hand, was much cooler; I think he
enjoyed the absurdity of putting a few hundred pounds of steel on
the roof of my Ford Escort and watching the suspension droop.
Cutting the compound angles was itself a trick, since my
Harbor Freight metal cutoff saw
offered only a simple miter fence.
I solved this by building tilt jigs.
I computed the compound tilt angles I'd need,
collapsing a few close angles together.
The angles came in complementary pairs, since the
miter fence has a reasonable range of +/-45 degrees,
but tilting can easily pass through all 90 degrees.
For each of the four complementary angle pairs,
I set the table saw tilt to the smaller of the two angles
(that is, the one the saw could tilt to), and ripped a strip
of 2x2 lumber so that the saw came out through the corner.
The two strips could then be glued down to a flat strip of
wood, leaving open a right angle tilted at the requisite angles.
I built the lid layer first, because it was the smallest, least
sensitive to sloppy construction, and wasted the least steel if I
I didn't quite blow it, but it certainly didn't come out very straight.
From the twisty construction of the lid, I understood my mistake.
First, I'd established the angle between the edges on each individual
face just by the miter angle cut into the tubes. There was enough error
in this angle that, once welded, it was impossible to assemble the
final 3D structure to the right shape.
Second, it was hard to even hold the six faces together long enough
to tack weld them; just too many moving parts. Magnets were no help,
since the tubes were never coplanar or perpendicular.
So, for the next section, the lower section, I built an 8x8 platform
from a couple pieces of plywood and some studs.
I screwed pegs down to the panel to make a jig, holding each tube at
the precise final-assembly angle, and tack-welded them in place.
(I did more than tack weld, until I realized that the smoking
plywood was probably interfering with the weld quality.)
Then, to solve the challenge of holding all six pieces in place simultaneously,
I laid out the hexagonal base of the prism on the plywood platform,
screwed in pegs around the perimeter, and propped the C-shaped faces
up in the hexagon.
This worked much better than trying to freehand 30 degrees of freedom.
Imprecision made it inclined to pop out of shape,
but my friend (no, not the first-grader pictured here)
stood in the middle to hold things in place while I tacked the joints.
The final assembly came together quite nicely,
and we got to see the basic chassis together for the first time.
By the way, I wondered before starting this project whether I could
get away with the cheeseball Harbor Freight welder
that goes on sale for $90 every so often.
I learned stick and gas welding in high school.
A few years ago, I picked up the electrode again to make a
ridiculous tandem bicycle,
the local welding store rented me a Miller 110V MiG setup with gas.
It was wonderful, but also wonderfully expensive; $480 back then, and
already up to $700 these days.
The Internet isn't kind to this welder. "Dangerous," they say (the
tip is electrically hot whenever the power switch is on, not just
when the trigger is pulled). "Poor duty cycle." "Ugly welds."
Well, the dangerous part is right; no excusing that.
So far, I've only ever tripped the thermal overload switch
(amazing that it has one..)
a handful of times,
so the duty cycle just hasn't been an issue
for my hobby-level work.
The welds are indeed ugly; there's quite a lot of spatter when welding
at the high-current setting. The gas-shielded MiG was quite a treat;
a rank amateur could really run a decent bead with only twenty minutes'
The Harbor Freight welder is quite a lot messier, and you pay for it
in time spent with the $15
Harbor Freight angle grinder.
Still, for a guy goofing around in the garage, you can make a lot of
progress for $90. (Add another $100 for
a decent helmet,
respirator with appropriate filters,
and a high-current extension cord.)
I've pushed about eight pounds of wire through my welder already.
Next was manufacturing frames for the door and window hatches,
and hinges for those and the lid hatch.
This took longer than you'd think for the amount of metal involved.
Here's a tip when drilling: clamp that metal down really well,
or you'll blast lots of drill bits apart.
I welded pairs of tabs where the top and bottom segments meet, so I could
bolt them together.
Next, I welded 1"-wide strips of 16-gauge sheet metal onto the chassis
to complete the fourth (right) edge of each planar face.
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
before going any further. He knows electronics pretty well, and
suggested what I needed were
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
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,
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
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
Awesome! And suddenly I more deeply understand how a computer's
memory bus works.
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
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
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
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.)
I spent a day or two comparing Atmel, PIC, TI and a few others,
and finally decided on Atmel. I liked them most of all because
they're open: with a gcc-based toolchain and open-source C library
the environment felt comfortable. Though I wasn't expecting to
write assembly language, the instruction set for Atmel's
microcontrollers seemed much easier than PIC's somewhat bizarre
and tortured design. The Atmel has 32 registers -- more than my
desktop machine has! The PIC is so weird that GCC can't even
target it. The PIC's development board seemed a little better
(cheaper, and USB rather than serial-port based), but ultimately I
decided on Atmel.
The microcontroller I picked was
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
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
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 was excited by my success so far but still had a way to go. The
ultimate goal was to manufacture a real printed-circuit board, but I
didn't feel ready to do that: too many components were still
untested, and I didn't quite know what I was doing yet. I wanted to
test things like the board-select circuitry and the driver that
would amplify the data bus. However, I was running out of space on
breadboard. Also, as the number of wires went up, it got harder
to keep the thing working without a wire popping out or two
resistors touching each other. I needed something with more space
and that would be more sturdy. I decided to solder together a
prototype using a prototyping board.
The first step was to draw a real schematic; this was starting to
get too complicated to keep everything in my head reliably.
Next I laid out all the components on the protoboard to get a sense
for how they'd all fit together. This required working out a bunch
more details, like finding a DIP switch, power connector, a
connector for the control bus (and mating ribbon cable and socket),
and a socket for the microcontroller (so I could swap it in and out,
instead of soldering it permanently). I also switched from the
individual wire-lead resistors to IC-shaped resistor chips --
basically just 8 resistors in a 16-pin package.
I soldered the components in, and, following my schematic, started to
painstakingly make all the electrical connections. The process of
cutting a wire to the right length, stripping the ends, and soldering
it in is surprisingly time-consuming. It took many hours over
several evenings, after which I'd only fully connected 2 LEDs. I
decided there was no point in continuing. A board with 2 digits was
complete enough to test what I wanted to test. I'd test with a
2-digit board and let a PCB manufacturer do the hard work of
running every wire to a fully populated board.
I turned the thing on and was sad to discover it didn't work. After a
while with a voltmeter, I concluded the driver wasn't working
properly. Of course, the real problem was that I didn't understand
how it was supposed to work. I'd thought that if you put a
voltage in (low or high), the same voltage would come out. Not so:
it's what's called an "open collector" driver. That means if you put
in a low voltage, a low voltage comes out, but if you put in a high
voltage, nothing comes out; the circuit is open, and whatever's
on the other end just floats. The fix ended up being easy: I attached
a pull-up resistor to each of the four outputs of the driver. Then it
Next, I wrote a test program that commands all 64 LEDs in the
entire board stack to identify themselves once per second. For
example, LED digit 3 on board 5 is told to display
"b...5...d...3". This test served two purposes.
First, it let me test the board-select circuitry. As seen in the
video below, if use the DIP switch to configure the board as Board 2,
the right most digit says "b2d0". Then, if I change it to Board 4, it
starts to display "b4d0". Cool -- it worked! The test was also useful
because it shows the microcontroller (running at 1MHz) has plenty of time to
individually program all 512 segments (8 segments x 64 digits) with no
Then I turned to the "gantry", the triangular pyramid that holds the
rocket high off the ground.
Before welding, I match-drilled each steel angle to a matched length
of aluminum tube.
The biggest trick, again, was building alignment jigs on the plywood
platform to hold the tilted members in place while they're tack welded.
The completed frame is a rigid, gusseted triangle.
The aluminum tubes bolt into the corner sleeves of angle iron.
The opposite ends bolt to concrete pier blocks which will be buried,
adding further rigidity.
I climbed up on the assembled gantry, and it was pretty solid.
If I shake vigorously, I can get the aluminum tubes to wobble a little,
but the geometry makes it pretty difficult to put them out of column
or make them buckle.
I think this is pretty much how NASA designed the Gemini vehicles:
they'd weld something together, and then an engineer would clamber on
top, wiggle around a little, make some erudite comments, and pronounce
The main chassis is beginning to rust in earnest;
I'm eager to complete the welding work so I can get it painted.
Jeremy found me some cutoffs of thick expanded steel for only $40
on craigslist. The guy was in Bremerton, but no problem: Jeremy also
flew me over to Bremerton airport (KPWT) in his Cardinal.
He took the seller's kid on a trip around the pattern,
then we wrapped the steel in a tarp to avoid snagging the plane's
upholstery, and flew it back home. Ah, the $100 craigslist bargain.
I've welded a joist across the bottom hexagon,
and cut two panels of expanded steel to serve as the floor.
A few weeks into this project, JD
suggested that for the toy to be really fun, the kids should be able
to interact with it in some way. It's not very fun to just look at a
bunch of random digits endlessly being displayed. To really let the
kids imagine they're flying a spaceship, we needed buttons to push and
dials to turn! And have those buttons and dials actually do
Of course, as soon as he said this, I realized he was right. So I
added another new feature: a 16-key membrane keypad, pictured below,
that I bought on Ebay for $3 directly from some random electronics
house in China. In fact, I bought two of them, since shipping was $4
no matter how many you buy. I'm not sure yet exactly how the toy will
actually work; maybe if you push "A" and then punch in a number, a row
of digits labelled "A" takes on that value and starts counting up or
down. Or something. But, hey, the Apollo missions flew to the Moon
using just a keypad and some
rows of 7-segment LEDs so I'm sure I can do something at least as
The keypad has a simple interface: 8 conductors, one
for each row and one for each column. When a button is pushed,
it creates contact between one of the row and column
So, the procedure for scanning the keypad is
Attach the column wires to microcontroller inputs, with
internal pull-up resistors activated. (Internal pull-ups are a
really useful feature of many microcontrollers!)
Attach the row inputs to microcontroller outputs
Assert low on the first row, and high on the other three.
Scan each of the four inputs; if any are low, the key in the
corresponding column of the first row has been pressed.
Repeat the previous two steps for the second, third, and fourth
The connector for this keypad had a single-row,
interface with standard (0.1'') spacing.
It so happened that I'd already decided to make the board-to-board
control bus a 2-row (16-pin) connector of the same spacing.
So I thought I'd do something clever: try to save pins and connectors
by plugging the keypad right into the
bus connector. Unfortnately, I made a mistake.
The assignment of signal pins to positions on the bus connector is
I reasoned that if I assigned the pins carefully, I could
just plug the keypad right into the bus connector, and not even use
any extra GPIO lines on the microcontroller.
I assigned 8 address lines to the first row, and made sure the
Enable pin was on the second row. I figured that as long as I kept
the Enable pin un-asserted, I would be
able to twiddle the other output pins in order to scan the keypad
without affecting the state of the latches. I
thought this was a clever way to conserve microcontroller IO pins.
I updated the software to periodically switch into keypad-scanning
mode: switch 4 of outputs to inputs and scan using the procedure
described above. This scanned the keypad perfectly. Unfortunately,
what I failed to forsee is that if one of the keys is still being held
down when the
controller goes back into display-updating mode,
the digits don't get programmed properly. The depressed key is now tying
together two outputs that might be fighting over keeping their
respective lines in different states. Oops!
To fix this, I updated the schematic to bring 4 dedicated input pins
out to the first row of the bus connector, and move four of the
outputs to the second row. Of course, there was no way I was going to
update the physical wiring to test this...the test will have to wait
until the prototype PCB arrives.
In the meantime, to test the scanning procedure, I changed the
software to display the key pressed for 3 seconds after the key is
released. That is, I could press "5" (the display failed while the key
is pressed), and after releasing the key see "5" appear on the display
for 3 seconds. Yay!
Today I used naval jelly to clean the rust off the bottom tubes of the
floor section, then trimmed the expanded-steel floor panels and
welded them into place. I'd done a poor job on one panel (before I figured
out to test with a cardboard mockup first), leaving a half-inch gap that
required some ridiculous fill-welding.
After a few hours of welding, grinding, and wire-brushing,
I went after the whole thing with naval jelly (sulfuric and phosphoric
acid that dissolves rust). Paint paint paint, scrub scrub scrub, then
a good hosing down. Wow, so shiny! Wait, what's happening? The whole thing
is turning orange! Even the parts that weren't rusty before! Wait! STOP!
I have no idea what made the chemistry go so horribly wrong.
I wire-wheeled much of the light layer of orange stuff off,
but with all the surface area of the expanded steel, and lots of tight
corners, I pretty much destroyed the wire wheel.
I decided that it would have to do, and laid down a thin coat of primer
over most of the surface with a spray gun.
Twenty minutes later, it began to rain. Sheesh.
The idea of letting the other stuff rust got to me.
I started the day blowing $160 at Harbor Freight
(four more pounds of weld wire, three more wire wheels,
metal polishing tools...)
and Home Depot (naval jelly, primer, mineral spirits, galvanized bolts).
Then I cleaned the rust off the rest of the completed parts
and gave them a coat of primer.
There are a few places I'll have to scrape the paint off and weld in
a bolt point, but better that than more rust.
And by "rope", of course, I mean "steel cable".
Last week I picked up stainless steel aircraft cable from Harbor Freight.
West Marine wanted $1.50 apiece for sleeves and stops in individual
baggies; I ended up ordering aluminum ones by the box from McMaster-Carr.
Eliot and I rode to Home Depot last night to pick up a crimper;
at $30, it beat the $187 Nicopress branded crimper. How can Harbor Freight
not stock this particular type of fastener?
We cut up some 3/4" steel stock and drilled them to make rungs for our
"rope" ladder, and made the weld-on tabs that the ladder will hang from.
The window face will be open about nine feet off the ground, and I know
that if I didn't protect it, someone would be tempted to try to climb
out there. I would, if I were seven.
The screen is a 3/4" steel frame around a panel cut from the last sheet of
expanded steel (use the whole buffalo, I've always said).
It drops into these angle brackets and bolts in place.
Since I had the welder out, I also welded on the eye tabs that the
rope ladder will hang from.
I sketched out some very rough dimensions for the astronaut couch,
the paint shaker mount, and the interior ladder that leads to the upper
I cut and drilled tabs for each (a total of nine tabs), and welded them
on to the main chassis components.
After lupper, I cut and welded together the interior ladder, too.
All of today's work needs to be grounded & wire-wheeled, but once that's
done, I'll be able to paint the main components "for real",
which means it'll be time to rivet on the body panels! Whoo!
I ground and wire-wheeled the window screen and the ladder,
plus the spots on the main chassis that had tabs attached.
I primered all the parts. Boring work, six hours, but important.
When I got done, Jeremy had checked in with his
for today, an early draft of the PCB layout.
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.
Eagle is cool: after you draw a logical diagram of your
circuit, Eagle converts it into a physical board layout (with help
from you). It has an extensive library of various commonly used
electronics components, and both their electrical and physical
characteristics. After connecting all the pins together in the
logical diagram (schematic), you switch to a physical diagram where
all parts are drawn to scale, including their pin positions. You
place the parts where you want and hit a button, and it figures out
where to put traces on the printed circuit board to make the
electrical connections specified in the schematic.
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!
I was so excited about getting the boards sent out that I started revising
the design even before the first batch arrived!
The biggest difference in v1.1 is that the board now supports two
different sizes of 7-segment LED displays. The original board only
supported 0.39" high digits, because they're cheapest. But there are
a couple of models of cheap 0.56" high digits too, which, being
bigger, are naturally cooler. For maximum coolness, we really wanted
to be able to mix up the sizes -- have a wall with digits in a variety
of colors and sizes. But, for simplicity, we only wanted a single
board, so our idea was to have a board that has two sets of mounting
holes (and associated traces), fitting both sizes. This version of
the board now has this feature. It mainly required learning how to
extend the parts library in my PCB design software, since this
particular type of 7-segment display wasn't in its pre-defined
And, hats off to Lite-On, the manufacturer of these LEDs. Their pin
layouts really makes board design a lot easier. One, their two anode
pins are 3 and 8, which are the middle pins in both rows. This means
two good things: first, the supply line can run horizontally all the
way across the board, without any turns. Second, you can mount LEDs
upside-down, which is useful to make a clock (mounting every other
digit upside-down gives you a series of colons, rather than decimal
points). Also, even though their 0.56" LEDs have horizontal rows of
pins, rather than vertical as in the 0.39" version, the segments are
controlled by pins in the same quadrant, making the superimposition I
was trying to do quite easy. And the supply lines end up being simple
vertical tendrils off the long horizontal supply line for the smaller
LEDs. The extra traces were all quite short
and didn't intersect with each other. At right is a screenshot of two
adjacent digit positions, each of which is a 0.39" and 0.56" LED
superimposed so that either can be mounted.
I learned lots of other new features of my schematic editor, which let
me do other cool things:
Per-IC capacitors. JD warned me that each IC should
really have a cap. However, I couldn't figure out how to do this
before, since when I made a row of caps next to each other, the
auto-router routed the caps to each other, rather than having each
lead of the cap going to the relatively far-away Vcc pin of each IC.
Finally, I figured out how to manually route traces, and was able to
put the caps in properly. Also, in v1.0 I'd accidentally and incorrectly
used the footprint of a capacitor that looks like a miniature oil
drum, rather than the M&M-shaped caps I was actually using. This is
fixed in v1.1 too.
Wider power and ground leads. JD warned me I should use
wider leads for power and ground, but an online trace-width
calculator told me that 6 mil was good enough, and the traces were
already 10 mil. Yesterday I realized that the boards I ordered were
1oz copper, but the calculator's default value is 2oz copper and the
power leads should have been 12 mil. I widened them, and made all
the other leads a narrower 6 mil to save space. (Eagle makes it
super easy to say "make the following nets 12 mils wide".)
Silkscreening. I hadn't bothered to learn how to do a
silkscreen layer before sending the first boards out, but once I
figured it out, I put nice little labels on all the headers
(e.g. PWR, BUS, PROG). I also added credits :-).
Mounting holes. Oops! I realized after I sent the
boards off that I had neglected to add holes that could be used to
mount the board to a panel (or standoff). The v1.1 board has
A square board. Yeah, long story, but, Eagle's
snap-to-grid feature acts a little unusually, and the dimensions of
my v1 board ended up being something like 6.50032234 inches by
2.30002451 inches, with non-square corners. I figured out how to
enter nice round dimensions and fixed it.
Alas, I have already found a bug in the v1.0 boards that I have not
yet fixed in v1.1 -- the footprints for the power and gauge connectors
are wrong. I thought I'd found the right connectors in Eagle's
library, but when the actual connectors arrived today from Digi-Key,
they didn't match a 1:1 scale printout of the board schematic.
I'll have to manually solder in power and ground wires for the v1.0
boards, I guess. If there's a more serious bug, I'll just spend
another $110 and get v1.1 produced; they'll be way cooler with all of
today's improvements, anyway.
I also blew another $75 at DigiKey today, getting enough ICs to build
3 fully-populated 8-LED boards (when the v1.0 PCBs arrive), and some
other odds and ends. In particular, 4 electronic potentiometers so
that the microcontroller can control the needle on a car gauge, and
some manual knob potentiometers so the kids can twirl some knobs. I
have a board design in mind to support the gauges, but that'll have to
for another post.
Here's the latest schematic and board layout, both with and without
the traces visible.
Friday and Saturday:
I did a bunch of priming.
I discovered that the spray paint gun works a lot better
when you clean it out.
I think priming is finally done;
Jeremy popped in, and sanded the ugly off of one of the aluminum tubes.
He commented that the "electronics cabinet" was coming along nicely.
For the past few days I've been thinking more seriously about the
software that will run in the rocket. I wanted to figure out two
things. First, what kind of software will be fun and thematic?
It has to do something interesting that exploits all the interesting
capabilities of the hardware.
Second, what's the right software structure that will let us add
features and models without the code turning into spaghetti?
Luckily, software is my specialty; it's the hardware stuff that's so
alien to me.
Sure, the hardware's not here yet.
But, since when is a lack of completed hardware an excuse not to work
on the software?
I spent an hour or two writing a little Rocket Panel Simulator that
runs on the console under Linux. It's essentially just a display
module that I can link against the same code that goes on the real
rocket. When the code is compiled in simulator mode, the functions
that assert real I/O pins are replaced with functions that interact
with my simulator module.
To the right is a screenshot of the simulator, configured to display 6
8-digit numbers, running the digit-identification program.
I also made some minor updates to the schematic and board
Primarily, I corrected the footprint of the dial connectors.
Since the real footprints are
smaller, there was also space to add a 3rd one.
I also found the connectors at DigiKey that match the
templates I used on the v1 boards. If the boards actually work,
I may as well just buy the connectors that fit on the boards
instead of doing something hacky.
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
Got the rest of the black paint dispensed. I used a little paint thinner
this time, and the paint came out of the gun much more enthusiastically.
Wish I'd tried that many paint-hours ago.
Jeremy convinced me to buy from ebay a set of five electrically-triggered
solenoid valves, to enable the electronics system to control the
various pneumatic functions. His argument was that I'd spend almost
as much rigging them mechanically anyway, and that once I attached the
valve, everything on the "electrical side" becomes his problem. :v)
I did a major revision of the schematic this evening, primarily because of
yesterday's fantastic success with the analog dials. I wanted
all the analog-to-digital converter inputs to be
available to attach to pots. I completely changed the assignment of
logical output pins (e.g. segment select 0-2) to physical pins on the
microcontroller so that none of the ADC pins are used for generic
digital I/O any more. Then I brought all the ADC pins out to
their own headers.
One motivation for doing this is that Jon I were scheming
today a way to attach a joystick (which is basically 2 pots attached
to a lever) to the microcontroller. As the pilot moves the joystick,
outputs will electrically control the solenoid air
valves that actuate the thrusters and paint-shaker. I'll write more on this once
we flesh it out.
I'd hoped that the 2nd batch of PCBs would have only tiny revisions
compared to the first, to minimize the chance of introducing new bugs. But
the changes are pretty substantial at this point. Oh well!
The valves came today. I tore open the box, trundled down to the garage
right away, and plumbed one together.
Here's a lousy video clip showing
the instant gratification. This rocket is going to be sweet.
Jeremy reported at work that the v1 PCBs came today, too. Yaaay!
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.
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
Drizzly rain kept me from cutting aluminum today, but I did spend several
hours on the software, programming against Jeremy's simulator.
I wrote a nice modular event scheduler (fashioned after Bill Bolosky's
Farsite scheduler), and an "overlapping windows" display driver.
Jeremy sent back a video of my brand new code running on the real hardware!
Sunny again. I tidied up the code some more over breakfast,
then broke out the sawhorses and started working on the aluminum
panels. I test-fit with some cardboard, then cut the real thing.
A lot of Formula 409 and elbow grease took care of the red "ALCOA"
printing. There are lots of other ugly blemishes on the aluminum
I haven't figured out how to polish out, so they're staying there.
We riveted on the first panel -- a moment Eliot has been waiting
for for a long time!
It's 1am Sunday. I've hacked on the boards all day (Saturday) and
it's really incredible: they work. I tested
The bus & programming header
The keypad -- complete with the fix allowing the keypad not to
cause two outputs to short, as happened with the protoboard
The ADC reading analog dials, complete with exponentially-weighted moving average filter
Getting a periodic timer interrupt, which enables all the
event-driven software Jon and I are developing.
This evening, Jon was so excited that he used the simulator to write a
ton of code that would make modules easy to write, and finally wrote a
module that would scroll a message across the LEDs. After a little
tweaking I got it to run on the real hardware:
Today I worked on the one part of this project that has
been consistently dogged by failure: getting analog gauges attached to
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
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).
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
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
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?
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
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")
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
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
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
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
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!
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
remain consistent, but we don't really care which microcontroller pin
is being used to drive the bus.
I've written quite a bit of the software stack here and there over the
last few weeks.
Last week, Jeremy gave me a zip-loc baggie containing one of his v1.0
rocket control panel boards, plus all the components needed to populate it.
I finally had time to build mine today,
just after building my adafruit AVR USB programmer dongle.
It's gorgeous! I phoned Jeremy to share the joy of the "first boot" moment.
I worked an eleven-hour day today. About eight hours went into cutting, filing,
sanding, cleaning, and polishing ten aluminum panels, completing the dozen
main body panels. (That leaves six small panels to go, the ones that cover
the lid hatch.) They're cut but not installed; I'm expecting Eliot will
want to help with riveting.
I also sanded the last aluminum leg, so I'm ready to bolt all three to
the gantry and dig the concrete pads into place in the back yard.
Three more hours went to making the main booster bracket.
I computed the final dimensions, cut the steel, drilled holes for bolts
that attach to the paint shaker and to the tabs on the gantry,
and welded it to shape.
It still needs to be ground and painted, but it's far enough now that
I can bolt it onto the rocket to try it out (whee!) and measure for the
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
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
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
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!
I spent this morning writing code for the rocket, mostly cleaning up the,
er, video driver.
Jeremy showed up about 10:20 to test his High Power Auxiliary Module,
the hand-built protoboard that takes signal-level outputs from the
microcontroller board and switches transistors to drive higher current
devices, like the solenoids. We tested the paint shaker (video), and
got some satisfying blasts out of the thruster jets.
Then I ruined one of the jets trying to "improve it" in the shop.
After Jeremy headed out, Eliot and I riveted two panels onto the lower
Oct 4's entry described how the microcontroller will be able to
actuate the thrusters. But how does the microcontroller
For it to be fun, the pilot (i.e., kid) needs to be able to actually
"steer". The obvious choice: a joystick!
After some research, we discovered that old-style PC joysticks are
actually just two potentiometers, one for the vertical and horizontal
directions. Joystick buttons are just plain old pushbuttons that
ground their inputs. This should make it easy to attach a joystick
to a microcontroller. In theory.
Step one was finding a joystick. Modern joysticks are
digital monstrosities with USB interfaces. We needed a 1990's
era joystick, and they were surprisingly hard to find. No one
uses them any more. Finally, one popped up on Craigslist for $1
nearby in Redmond, so I biked over there after work one afternoon
a couple of weeks ago and picked it up. The 5-year-old previous
owner was excited to hear his old toy was going into a rocket ship.
I promised him a ride once it was finished!
Tonight I sat down to see if I could get the microcontroller to read
the joystick's position. I thought it would be easy; I assumed that
the top and bottom of the joystick's pot would be attached to +5V and
GND, meaning the output would be some voltage in between, linearly
mapped to the joystick's position, that could be easily read by the
ADC. But... surprise! It turns out that for some reason, joysticks
don't attach the bottom of the pot to GND, they just let it float.
They just vary their resistance, as shown in the diagram to the right.
The resistance varies between 0 and 100k ohms; 50k is center.
I think the easiest way to sense an unknown resistance when you have
an ADC is to attach a series resistor between the joystick's output
and ground, then read the voltage on the joystick side of that
resistor. The problem is, no resistor value is ideal. This is
illustrated in the plot on the right, which shows joystick position
vs. voltage for 5 different series resistors: 1k, 10k, 35k, 75k, and
100k. The small resistors let you use the entire range of the ADC,
but concentrate most of the precision on a small part of the
joystick's range of motion. Higher values are closer to linear, but
throw away 3/5ths of the ADC's precision across the board since they
only vary by 2 volts. How annoying. I think I'll use the 35k
resistor; that seems like a good balance. Unfortunately, this also
means needing a small interface board between the joystick and rocket
panel with nothing on it but 2 resistors. Again, annoying.
Wait, what am I talking about? Random stray circuit boards
scattered around the rocket will just make it better!
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
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.
I picked up a new long-handled riveter this week, so Eliot would
be able to pull rivets.
He woke me up at 7:10 this morning to get started. We put on the last
lower panel and another upper panel, and Eliot pulled almost all the rivets
himself. He did a great job with a tool that's a good fraction of his own
I got back from a conference in Montana last night.
Tonight, we tucked the girls in bed right after dinner, and Eliot
and I headed down to the shop to rivet the rocket door --
too dark outside to work on the main chassis.
Eliot measured, center-punched and pulled every rivet on the door
The idea for an astronaut suit started with a cheesy play helmet
about 6 months ago (Eliot's birthday). Then it became apparent that
the scope and scale of the rocket project was calling for something
more ornate. The look was for big zippers, lots of velcro on the
sleeves and arm pockets and neato space patches.
Now to get this thing finished before Eliot has grown out of it or
lost interest. How long do you think it will stay white? Oh, who
really cares! :v)
After two fittings, here's what we have so far. Once we know it fits
I will be putting in the hefty black metal zipper up the front, then
a black thick cowling-like collar (to keep the helmet "air tight" -
ha, like a fuzzy space helmet will need that. But, you know, it's
the look we're after here.)
The parachute straps and wide belt are pinned on in their general
planned locations. Belt carriers will be added on the shoulders and
waist to keep them in place. Hummm, looks like the shoulder strap
covers up the NASA patch, so we might have to figure out a different
place for it.
Just had to have the original NASA patch :v) Also I think we might
need a patch for this mission: Ravenna Ultra-Low-Altitude Vehicle
I snuck out to the back yard after one torrential rain, and managed to put
on two more panels on the upper ("torso") layer of the rocket, the biggest
panels. I made a big mess with the silicone on the
second one. Just as I was finishing, the next torrential downpour arrived.
Whew. There's only one more of those to go, plus the window panel (which
Eliot and I can do in the shop).
A very big day today. In the morning, I riveted on the last panel
on the torso section.
Jeremy called to say he and Alex could come over later to help with an
old-fashioned community rocket-raising.
So I focused on critical jobs:
I dug the holes for the footings and leveled them, and
replaced the dozen leg-to-gantry bolts with 1/2"-longer ones
that left room for washers.
With more time left to go before they arrived, I cut and welded some extra
bracing onto the paint shaker bracket, hoping to lose less vibration
to the springiness of the bracket.
Finally, Eliot and I riveted the last big panel onto the door for the
torso hatch (aka window).
Jeremy and Alex arrived, bearing cupcakes to celebrate the momentous milestone.
Eliot and I spent another fifteen minutes pulling the rivets on the window
before the silicone set.
Then we all went outside.
We spent a few minutes trying to figure out how to actually get the
80-pound torso section onto the hip section:
Should we bolt it together first and tip the entire 15-foot structure up
and carry it into place?
Or should we right just the legs-and-hips section,
leaving us with the challenge of lifting the torso section ten feet up
to its mounting spot?
We settled on the latter plan.
The three of us had no problem righting the legs-and-hips section,
and then trotting it across the yard to the concrete footings.
We bolted the legs to the footings, and within moments Alex and Eliot
had clambered into the rocket, seven and a half feet high.
Jeremy and I inverted the torso section,
and held its open edge up to a matching edge of the hip section.
Alex and Eliot turned a couple straps into an ersatz hinge.
Jeremy ran a strap from the inverted top of the torso up to Alex.
Jeremy and I swung the torso halfway up, so that it was lying sideways,
then Alex pulled his strap to right it the rest of the way.
We hacked a few cedar sprigs out of the way, and bolted on the torso.
I brought out the entry hatch (at the hip level), hung it on the hinges,
and secured it with cotter pins.
Next came the window hatch (with the silicone still wet),
followed by the window screen.
Wow! It stands up nice and high, and sure looks like a rocket.
What a cool treehouse. Today's a big day.
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
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
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
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!
I primered the paint shaker hangar and the thruster mounting brackets.
Painting just a few things is a huge hassle:
15 minutes to get everything out,
and another half hour cleaning the sprayer and putting everything away;
a lot of overhead for a few square inches of painting.
I buried the block that steadies the rope ladder,
and put the paint coat on the hangar & brackets.
To cut down overhead, I tried painting with a refillable spray-paint
style bottle, but it "sprayed" in ridiculous big blotches rather than
a fine mist. So, another hour on cleaning stuff.
I think future small parts will just get the paintbrush treatment.
I also got half of the aluminum skin prepped for the upper (lid) hatch.
Today was a big day: I got a big and complicated part of the system to
work properly. Even if I stop work today and never assemble another
panel, the piece I have working right now would be enough to make the
rocket cool. Specifically, I have the joystick controlling the
rocket's thrusters (i.e., solenoid air valves).
I don't think I really appreciated how complex this project had become
until I sat down yesterday to make this all work. I was shocked to
discover that there are no less than 6 separate components that must
be chained together in a long line:
A small joystick interface board with two resistors, forming two
voltage dividers that can be read using the processor's ADC.
A rocket panel board with a processor on it. The joystick
interface board plugs into the CPU board's JOY1 input header.
A display board specially hacked so that one of its latch outputs
goes off-board on a 5-conductor cable rather than to LEDs. These 5
outputs go to the...
HPAM (High Power Auxiliary Module), described in an earlier post,
which takes low-current, 5-volt control inputs and uses power MOSFETs
to switch a high-current 12V supply into up to 4 devices.
The solenoid air valve itself, which takes 12V @500ma.
The past two days were mostly spent building all the special cables
to connect the components to each other and writing software.
ADC-read voltage values from the joystick are converted into positions
assuming the hyperbolic resistance-to-voltage
curve shown in the joystick
I settled on 40k resistors. The positions are scaled to a value from
-99 to +99, with 0 at center. Hysteresis is used to threshold the
joystick positions; +/-50 triggers, and +/- 30 releases.
Depending on the joystick direction, one of the three thrusters is
fired. It all works!
With intentions of finishing up the suit on Saturday, I pulled
together all the stuff that I could conceivably need and we headed
over to the rocket launch pad location. It was time for a final
fitting before I begin making things really permanent and that can't
be reversed. Fitting looks good.
So: Next step: get the zipper installed. Find the zipper in the
big bag of stuff. No zipper. A huge bag of anything I "might" get
to, and the next step item was missing. So off to Jo-Ann's, 10 mile
round trip, to get another zipper (actually got two varieties just
in case...) Got home and the girls were up from their nap. Whee!
So we happily had kid/grandparent playtime, read Box Car Children
with Eliot, ate pizza, more fun playtime, then kiddo's bedtime. Ah,
time and energy gone, so it was time to go home, dragging the suit
home in just about the exact same state I had taken it over in.
Which was OK, because I would much rather play with the kids. :v)
Sewing I can do at home.
So today I pinned, then basted in the zipper. Several pin pricks
later I was ready to sew the thing in. Wow! Installed in the first
attempt. Yeah! While sewing I was contemplating what to do about
the tricky design of the collar, and began wondering - is this thing
going to be a scratchy, bothersome thing that he might not like
anyway? So we await the verdict on that from the rocket
manufacturer and the astronaut who will have to live in it for awhile.
After Eliot was in bed, I went down to the shop and cut up some steel
to make handholds and latches.
I love making the beefy handholds from 1/2" steel rod, because step 2 is
clamping rod into a vise and beating the baloney out of it with
a sledge hammer. If it ends up the wrong shape, you clamp it differently
and then beat the baloney out of it with the sledge hammer.
It's nice when you run across problems so simple that you can fix them
with a sledge hammer.
A few days ago, Jon and I sat down to figure out what the
final rocket control panel should look like. We'd had vague
plans for a while -- a Lunar Distance display here, a
Thruster Actuation Status display there. But last weekend,
Jon, Alex and I actually put the rocket up (see Jon's Oct 18 entry)
so the time finally
came to decide exactly which displays would go where, and in
what colors and sizes.
I used PowerPoint to draw a dozen different proposed panel
modules. Then, one evening after work, Jon and I clambered into the
newly risen rocket with a dozen correct-scale printouts of a rocket
panel. We cut each module out and
pasted the ones we liked all around us. I have to say, seeing
all those displays up in the rocket, even though they were just paper,
was pretty exciting.
Tonight, I started the process of building all the final boards --
labelling each one with its intended function, and taping all the
right colors and sizes of LEDs into it. It feels like we're almost there!
I had an unrestful night and didn't feel so good in the morning, so I stayed
One thing led to another, and I found myself in the shop, welding
those sledge-hammered handles together and putting on a coat of primer.
(I still stand by my decision, though -- I had plenty of opportunities to rest
today, including in the rest-room.)
I parted with $100 (what we're coming to call a "rocket nickel") at
Morgan's Plumbing, Home Depot, and Lowe's, collecting all the goofy
little fittings I need to transition between 1/4" NPT air fittings,
1/2" sweated pipe (cheap!), and 3/8" compression fittings (adjustable).
Strangely, one specific fitting was out of stock at all three stores.
I hope no-one else is building an identical rocket just down the street.
Got the babies in bed, then Eliot and I scooted down to the basement.
We bent up the rest of the aluminum lid skin. We read a book and tucked
Eliot into bed. Chase appeared shortly thereafter, so he got pressed into
rivet-pulling duty. The lid is done!
In the morning, I had to retire Halloween block party duties, mowing the lawn
and putting up a shelter for the cider stand.
Then back to work on the rocket!
I installed the finished lid on the rocket, cotter-pinning the hinges,
and made tabs for the lid-limit cable.
Then I built the over-center lock for the inside ladder.
That took three tries (measure thrice, cut thrice, I always say):
On the first try, the linkage tried to fold itself outside the aluminum panel.
I adjusted the lengths, and on the second try, it tried to fold itself
the other way, through the ladder pole.
The third time was a charm; it's now ready to tap, paint, and bolt into place.
Lots done today!
The entry handholds are bolted into place, so climbing into the rocket
is now much easier. The entry hatch has handles to open and close it,
and there's a magnetic latch to hold the main hatch shut.
(Unfortunately, it's so strong that Eliot can't open it -- some adjustment
will be required.)
I tapped the mounts for the over-center lock, test fit it, trimmed off the
extra metal (from yesterday's fiascos), cleaned it up, and primered it.
I tapped the mounts for the lid cable tabs, and primered them.
That tied up a bunch of loose ends, and left me ready to start in on one of
the remaining big steps...
Primary pneumatic power.
The rocket uses pneumatic power for primary boost
and orbit-adjustment rockets.
Specifically, I'll be running a pipe
from an air compressor ($90 on sale) in the shop.
In the rocket, it will provide opportunities for valves, pressure gauges,
and leaky-gas noises. And also, it'll power a
paint shaker (also $90) bolted below the chassis, for shuddering takeoffs.
(We're planning to add some suitable higher-frequency takeoff noise
to go with it, in the electronics subsystem.)
Then, once in orbit, orientation and smaller adjustment burns will
be provided by blasting jets ($8 each)
of dihydrogen monoxide reaction mass. (This was a component I thought for sure
would require custom machining, but no, Harbor Freight wins again.
Early playing with these, showed that the RC delay in a 15' air hose
is so great that the vapor sort of hisses slowly to a start and again to stop.
To get a satisfyingly sharp retro "blast", I had proposed to connect
a joystick mechanically, through bike cables, to actuate the thrusters.
Along the way, Jeremy convinced me that it was much better to actuate
them electrically; he found solenoids on eBay for $15 apiece.
So, today, I launched into the pneumatic plumbing.
I bolted all three thrusters into place, and bolted the booster (paint shaker)
hangar into place.
Each thruster received its series of 1/4" NPT fittings:
an elbow, a male-male coupler, a solenoid valve, and a
3/8" compression-fitting coupler.
That takes the output end of the plumbing as far as I can; I'm still waiting
for a fourth solenoid valve to return from Jeremy's avionics shop.
Next, I started on the distribution manifold.
It begins as a 1/2" sweat-fit copper pipe,
passes through the propellant master valve,
and splits through a manifold to three female 1/4" NPT fittings.
Each fitting feeds a regulator and pressure gauge, and terminates
in a 3/8" compression fitting.
The third output is not yet soldered in place,
because I need to pick up a third regulator.
I have to have the whole stack of NPT fittings together to be sure
that, once soldered, the stack gets tight just as the gauge is facing up.
So, I'm already most of the way through the plumbing! I'll need to add a
supply pipe plus a half-dozen runs of soft 3/8" tube between the compression
I confess that an important benefit of getting the plumbing so far today
is that it will make Jeremy itchy anxious to start clicking those
Tonight I completed and tested the pneumatic distribution manifold. Air
arrives on the right, passes through a main shutoff valve, and is
distributed to three regulators with gauges. The leftmost regulator's
output is closed, so that its gauge always reads supply pressure. The
other two regulators supply air to the thruster air circuit and booster
Jeremy came over this morning before work.
I put in the soft copper compression tubing, and we rolled out the air
compressor and an extension cord for the power supply.
We tested the thrusters (they're thrusty).
The air system leaked quite enthusiastically,
until we went around putting a bunch more torque on each fitting.
We got into the rocket and fired the main booster.
It was fantastic! It's the first time we've done it with the rocket's
aluminum skin on -- the booster shakes everything including the skin,
producing subsonic and low sonic tones that really feel blast-off-y.
I tried to mount the over-center lock, and that didn't go so well.
For reasons I don't understand, the screws bound up in the tapped holes.
One, when I tried to back it out, even broke off in the hole! Bummer.
I came down with a cold last week, which impeded my ability to get
much work done, actual or rocket-wise.
I did cuddle up under a blanket,
heated by the waste heat from my laptop's Core 2 Duo,
and tidy up the rocket software a bit.
That had a few fun components. First, somewhere along the line,
the rocket became a distributed system. The Elson Avionics bus supports
eight 8-digit displays per processor, and on panel design day, we ended up with
a total of twelve displays. Furthermore, there will be an audio board,
with its own microcontroller, to add some environmental acoustics.
These three controllers will be interconnected by the "three-wire interface"
(TWI), one of three bus standards implemented on the Atmega microcontroller.
(TWI is a multi-master bus; SPI is a single-master bus, and UART is a
So I implemented a TWI module in the simulator,
wrote the rocket networking stack against the simulator,
and wrote a bunch of modules that ship keystrokes and thruster status
My first cut at the networking stack was a clumsy state machine.
Jeremy, drawing on his extensive background writing little tiny network
stacks, pointed out the world of software maintenance pain that I'd opened
I started experiencing that pain within 48 hours of the first implementation,
so I rewrote the stack using his recommended architecture.
Then I organized the remaining modules and filled out the remaining display
functions. Mostly, this meant dragging modules from their rough prototypes
to completed, integrated components. For example, when the "Launch" function
is selected, it draws a giant countdown on the bitmapped display,
updates the Mission Clock, and advances the speed and lunar distance displays.
I still need to implement and test the TWI stuff on real hardware,
but this is all pretty satisfying:
Once we build, mount, and wire the hardware, we can turn it on and start
firing the thrusters with the real software.
Cold number two arrived hot on the heels of cold number one.
I'm concerned that, in a Cat-in-the-Hat sort of way, observers
may decide that the "colds" are implausibly convenient reasons to stay
home on the sofa writing rocket code.
In any case, I used Audacity
to make some rumbly rocket booster noises.
I also mixed together some clangs from the web to make a docking noise,
and sliced up the classic Pong beeps and boops.
I wrote up the code in the simulator that will drive the audio board,
and the sound stuff all works in simulation now.
I still need to plumb the hardware side through (SPI to the flash chip
that will hold the sample buffer, writes to the DAC that drive the amplifier,
and the TWI that carries network messages among boards) and make sure
it sounds good.
My McMaster-Carr order,
with parts for the DHMO Reaction Mass Reservoir,
showed up early this week.
Today, armored in a sweatshirt, I braved the slight cool of the basement
to assemble the reservoir.
Then I hung it on the rocket with zip ties and connected up the thrusters
with vinyl hose and barb tees.
Maybe half an hour's effort, but satisfying none the less.
Jeremy assigned me to populate four of the avionics boards;
specifically, the set that make up the bitmap display.
Tonight, I spent a nice evening chatting with Chase and soldering.
I got two boards completed, in about 80 minutes per board.
In the photo, you can see that I'm using a rubber-jawed soldering
Andy, a good friend that taught me all about electronics
and computers and math and pretty much everything else,
loaned that to me when I was little.
Andy passed away recently.
Every time I solder a project with it, it's bittersweet.
I finished up the other two boards today, getting even a little
Part of the time Evan was here.
He watched me bending the pins on the chips against the table,
then poking them through the board,
then flipping the board over in the vise,
and then holding the chip in place upside down while I tacked its corner
legs with the soldering iron.
He asked why I bent the pins against the table.
I explained that you had to bend them to get them into the rows of holes.
Then I said that it was frustrating, but DIPs always come that way,
with the pins flared out a little farther than will fit.
And then I surmised that was probably because, in industry, the chips can
be installed by a machine and they'll stay stuck in the board, so that when
the board is manipulated before soldering, the chip won't fall out because
the pins spring against the holes.
And then I thought there was probably some sort of tool for holding the
pins together until they're slipped through the hole,
and specifically, that actual tool was probably sitting in a drawer
in my basement.
So I went down to the basement, got the chip inserter, and started popping
chips in. They dutifully sprung into place, and soldering got a lot easier.
The cold front finally passed this afternoon.
Eliot's been eagerly waiting to help dig the trench.
Evan helped a bunch, too.
I expected to have to route under a couple tree roots, but I was
completely unprepared for one major treeway interchange we found.
The choice was to settle for about a 5" burying depth, or keep digging.
After an hour on hands and knees, we finally broke through our own little
I'll have to solder the pipes in situ,
since the tunnel is too narrow to push a joined pipe through,
and the pipe has to take a quick turn to avoid the next root underpass.
For those of you keeping track, the trench has become a
Multi-Purpose Service Infrastructure Component.
Here's what we're burying in it:
Eliot and I spent a very productive day in the yard today. We brazed in the
copper air pipe, glued in the PVC electrical/data conduit, and pulled the
polyethylene water tube through and zip-tied it to the conduit.
The water filled up the reservoir just fine,
and we tested the air all the way through to blast the thrusters.
One cool feature is that the water line has an
air hookup: when freezing temperatures are forecast, I can close
the water valve, plug the compressor into the side, and blast
the water out of the buried water line through the reservoir.
We tested this out, and it worked great.
JD taught me how to feed the pulling line through the conduit: tie
it to a little bit of plastic bag, and suck it through with a shop-vac.
That worked pretty well. Unfortunately, we weren't able to pull the 14ga
power wire back through the conduit's seven (yikes!) 90-degree bends.
Hopefully it'll go better on another try, with two adults working at it.
We filled the trench back in and got our yard back. I hope the conduit
doesn't put up too much more of a fight!
I fought Crashy Cinelerra to bring you the Trench Day video on the
Nov. 27 entry.
I proofed a version of the "astronaut couch" in wood and muslin,
and cut the metal for it out of the few bars still littering the shop
floor. It's mostly made of 3/4" square tube, and after I cut the pieces
I needed for the couch, I had left a sliver less than 1/2" wide. Whew!
The over-center brace that holds the interior ladder in place turns out
to be rather wobbly from side to side.
While I had the metal tools out, I cut a diagonal brace to fix it up.
Eliot showed off the thruster for his grandma today. The water supply
was pretty weak and intermittent. I realized that was because I had
so carefully teed all the water supply lines into a single circuit,
so the thruster was drawing air out of the other two thrusters. The
fix is to do the simple thing I should have done in the first place:
dip three separate water pickups into the tank.
Jeremy showed up after breakfast to help pull wire through the conduit.
We used JD's further suggestion of first pulling just a pull-wire through,
with lots of wire lube, to get the conduit slippery.
Then Jeremy fed the 14-2 romex through, followed by a pair of cat-5 cables.
Definitely a two-person job. Complete victory this time!
Jeremy headed back home to build the power distribution board.
I welded up the modified ladder over-center bracket
and the metal frame for the astronaut couch.
Fitting and cutting the frame's mounting brackets, drilling, welding,
grinding, and wire-wheeling those parts pretty much soaked up the
whole afternoon, especially with the 4:30 sunset.
At dusk, I unwrapped one of the $1.50 Harbor Freight 9-LED flashlights
and tried it out in the rocket. Wow, it's going to look great!
I took a break from rocket work for about a month;
it was taking too much time and
away from "real" work projects.
But, in the past few days, I've been getting back to it.
Oh dear rocket, you lovable little scamp, I could never stay mad at
In the intervening weeks, Jon finalized all the rocket software
and populated 4 of the circuit boards, so things feel like
they're much closer to done now anyway.
Yesterday, I went to Jon's house to help him pull wires through the
trench he'd built between the rocket and the basement.
The trench will carry compressed air and water for the thrusters,
power for the boards, and data between the house
and the rocket. (The rocket has more utilities coming into it
than my apartment!)
We realized that the next step on the critical path was
a board that would distribute power from the house supply out to
all the various panels.
We'd planned on having such a board from the beginning --
I ordered the necessary components from Digi-Key 3 months ago --
but hadn't needed to put them together until today.
I had a busy weekend, so only had an hour or so for board-building
time. I thought for a while about the best way to construct the
power board, drew a schematic, threw it out, drew a 2nd one,
and then prototyped it on a breadboard. It'll have
a big red power switch, two indicator LEDs,
12 5.5V outputs and 3 12V outputs, with room for
Some evening this week I'll build the real board.
Eliot and I did some errands today, buying extension cords for Christmas
lights and such. And, of course, rocket parts.
I picked up more LED flashlights.
A trip to The Shack yielded a bunch of resistors to control them,
plus some parts to build an audio amp.
I grabbed a pair of bookshelf speakers and a pair of computer speakers from
the thrift store, hoping to score an audio amplifier and maybe a speaker
with enough bass to make a passable launch sound.
Another Home Depot visit netted more bolts (for the couch and mounting the
flashlights). At Joann's, I got a yard of safety-orange duck cloth for the
Tonight I tore apart the speakers.
The bookshelf speakers are probably
going to work for the bass, but something bigger would be nicer.
The amplifier for the computer speakers was apparently in the subwoofer
piece, which wasn't at the thrift store, so I'm still shopping.
Crimped some awful Molex connectors to make a power cable for the raster
display (group of four boards), and updated makefiles to talk to the new
ATMega328p chips we're using. (They're drop-in replacements Jeremy found for
the ATMega8s we started with, but with lots more memory. Yes, the rocket
operating system and avionics software outgrew the first chipset. :v)
Unfortunately, I can't get the actual code running on the new chip yet,
and it's time for bed.
Tonight I soldered together the final power board.
On the far left is the input section.
We'll terminate the Romex cable coming through the conduit
from Jon's house
with a couple of
that will attach to the board with screws.
The input is 12V;
a green LED shows that house power is on.
Lower left is a 3-pin terminal where we'll attach the master
That will feed power to both of the output sections:
12V and 5V.
The 12V output section
is just the raw house power, switched but unregulated.
It will feed the cockpit lights
and the HPAM --
which, in turn, switches power to the thrusters and
Power for the
5V output is generated by a switching power regulator
and will be used for all the avionics panels.
Both output sections have red LEDs showing they're active.
Right now the 5V output section only has 5 connectors,
but that's just because I ran out of connectors.
There's room for 18.
The photos on the right both show the new power board.
The second photo
the new board powering the mission clock panel
and was taken with the lights off
making the LEDs more clearly visible.
Wow, those hundreths-of-a-second LEDs are ridiculously bright!
Good thing we moved them from my office wall
(where they're distracting)
to the rocket
(where they're just pure awesome).
Since Monday, I finished getting the code fixed up for the ATmega328p.
The hardware target had also rotted a little bit (as the underlying OS
got updated to handle my door nametag projector board at work); I patched
that up tonight. Then I lashed the boards together and played a little pong!
Today started with some more grotty debugging. Some code that runs
in the simulator crashes on the boards.
I figured out a few: a 16-bit register overflow produced a negative Time,
a stack overflow fixed by hiding data in program space,
and a display thread hogging CPU even when invisible.
There's still one module broken, though: the one that reads the joystick
and fires the thrusters.
Eliot and I brushed a coat of black paint on the parts dangling from joists
over the shop.
I measured in the rocket for an aluminum box (plexiglas face) to house
the air manifold assembly.
My first try failed in a way I hadn't experienced before:
when I made the first bend in the brake, the metal was very stiff,
and I heard a weird crackling or splintering sound.
I pushed it the rest of the way through the 90 degree bend,
and by the time I was done,
the flanges had cracked along the bend about halfway along their length. Yikes!
I hypothesized that it was temperature related. Seems unlikely -- I mean,
it's been cold around here, but our basement isn't that much colder
But I heated up the metal with a torch, and did a few more bends that
came out great. Wild.
So I marked up a new piece of aluminum, cut it to shape, and carefully
preheated each line before bending it, getting pretty good results
marred only on the second bend, where I tried to rush things a bit and
apparently didn't add enough heat.
I also figured out how to mechanically wire the flashlights for external power.
I found some grommets that made a tight fit to our power wire.
To connect them, I found I needed to remove the bulb head from the
flashlight body tube. This I achieved by the graceful method of slipping
the flashlight over a piece of 1/2" PVC pipe, setting a block of wood
on top, and giving it a whack with a hammer.
After the switch-and-battery-ectomy, the new light has an attractive fixture
and I think will retain its waterproofness.
I found and fixed the "last" bug that was crashing on the real hardware:
the joystick code had local definitions pointing at hardware ports for
version 1.1 boards that were interfering with my version 1.0 debug prototype.
I touched up the paint on the couch and ladder bracket.
I popped all the LED flashlights apart. I realized at one point that
part of my technique involved shearing a ring from the aluminum tube.
I tried to modify the technique to avoid that, but it turned out the
ring was distributing the force and protecting the circuit board;
two casualties resulted. I went back to the original technique,
disassembling and drilling grommet holes in all of the flashlights.
I measured out a bunch of the boards, meters, and switches, and made
Inkscape drawings for laser cutting the plexiglas panels they will mount to.
After work, Jeremy and I visited the laser cutter in the shop and
cut the first mounting panel for the avionics:
the Multi-Function Display (MFD), a whopping four Elson display
boards smooshed into a 256-pixel raster display. In the video, the board
displays a giant countdown in 32-point URW Gothic L Semi-Bold.
The ribbon cable I have to test with precludes plugging in all
four boards plus a keypad at the same time.
I worked around this by creating an "Autotype" thread that
just types in a given string at a given rate.
It did have one funny little bug: the check for a zero
terminator was incorrect, so it kept on typing out the rest of the .text
section, eventually typing keypad 'D', which aborts the launch sequence.
Over the past few days I've been soldering together
the rest of the final rocket panel boards.
Jon put together the 4 boards for his awesome
I've been gradually assembling the other 8.
In reality this was a form of procrastination:
I really need to design the audio board,
but that requires some careful thought.
Late at night just before bed, it's easier to do some
thoughtless assembly rather than circuit layout.
Pictured at right are the final boards:
(top) One of the two
Flight Computer displays;
(center) Azimuth, Elevation and Roll Angles;
(bottom) Lunar Speed;
(left) The second HPAM board for controlling 12V equipment.
Including prototypes, I've now assembled about 15 of these boards,
each of which has 20 chips and 8 LEDs on it. That's 420
individual components. I soldered the first 419 perfectly.
The very last one -- I mean, the very last chip on the very last board --
I managed to solder in upside-down.
To make things worse, I didn't discover this until soldering the chip
completely in. The somewhat violent process of removing it lifted
one of the solder pads off the circuit board, breaking that circuit trace.
Unfortunately that pin was an important one, so I ended up putting an
extra wire on the back to replace the broken trace.
Eliot had his friend over today, and while they played,
I installed the couch in the rocket.
While Captain Eliot and First Officer Zach flew all over the galaxy,
visiting no fewer that ten alien-inhabited planets,
I installed the new, more-rigid upper ladder brace,
and I replumbed the thrusters so they each have their own dip tube and
receive a consistent flow of dihydrogen monoxide reaction mass fluid.
Unfortunately, at one point, Captain Eliot popped open the top hatch
so enthusiastically that it popped out the rivet that holds the limit cable
bracket in place. The hatch continued around its pivot until it impacted
the aluminum skin, cracking it.
Fortunately, the cabin atmosphere leakage through the crack is minimal.
We replaced the broken rivet with a through-bolt.
I also replumbed the supply side of the water line,
installing the solenoid valve and a new air-purge valve
to replace the one I damaged by over-torquing it.
I built and installed two of the electronics boxes this morning.
Jeremy came over and wired the trenched power to the power distribution
We tested out the power panel with the overhead light ... and the ammeter
has already paid for itself: it read 3A, indicating that we'd plugged the
overhead light into the 12V bus, when its resistor was configured for
the 5V bus.
Enough items on the power and HPAM panels needed tweaking that we took
it back apart. Jeremy took some boards home to modify.
I modified the power panel, adding connectors and rearranging
a few incomplete circuits.
I labeled all the circuits on the power panel to avoid a recurrence of
the 12V/5V fiasco.
I learned that Dymo label tape is heat sensitive,
and that when shrinking heat-shrink tubing, it's really easy to set
nearby tape to all ones.
I also built more of the boxes; there are only two left to go.
(Remember that I have to heat up
my sheet aluminum to get it to bend without cracking?
Over Christmas break, my cousin-in-law, who is a mechanical engineer
and shop guy, heard about this, and immediately replied, "Oh, yeah, that's
what's gonna happen with sixty-sixty-one. If you want to bend it, you
should be using fifty-series." Yeah, I should. So now I know a little tiny
bit more about metal alloys. (Turns out mine is 7075, which is probably
even more brittle than 6061. The number 7075 is printed in 2" red letters
on every square foot of the sheet...)
Bending was getting slow tonight because my propane cylinder was almost empty;
a trip to Home Depot yielded a new cylinder that heated things up much
faster, including my left index finger.
I laid out the remaining plexiglas panel (ready to laser-cut) and boxes
(ready to construct in the shop).
This entry's title is a little underspecified, but that's because we got
so much working today!
I finished up all of the mounting boxes,
and installed all but the one that's still missing its plexiglas panel.
Jeremy came over and did some finish work on the power panel and the HPAM
While I was mounting boxes, he completed wiring the water fill line.
Then he started routing display bus and power cables inside the rocket,
while I added flashing to the lid to reduce rain ingress.
I replaced some zinc hardware with stainless bolts,
and Jeremy wired up the joystick and the
I bent the plexiglas for a cover for the pneumatic manifold.
I spliced in some of the thrusters and thruster lights.
Late in the evening, we pulled the CPU 0 panel and downloaded its firmware.
Although only two display panels and the power panel have enough wiring
complete to function, the rocket has a beautiful red glow.
As switches are thrown, lights show up one at a time,
then twos and fours, then by the dozens.
Push a switch on the panel; a blue light lights, a small click comes from
across the yard, and water burbles into the thruster reservoir.
Turn the master pneumatic valve; air hisses and the pressure gauges come alive.
Press HPAM-DA channel 0 for the one completed thruster;
a brilliant white jet of vapor blasts out
and spreads out over the ground.
It's pretty amazing. I can't wait to get the rest of the
pieces wired into place!
It took a lot of tongue-biting, but I did keep the secret until Jon's
Christmas present was revealed. A captain can't fly without his
second mate being suited up, so there just had to be a second
astronaut suit. A bit of tweeking here and there, add the sleeves
belts, and then it will be ready for the maiden flight. Looks like
we have another deadline to meet, since the rocket is just about
ready for the launch pad!
I was a little concerned that the swelling action of a blind rivet would
split plexiglas, but on a previous project it worked out okay.
But before we go install all the placards on the plexiglas panels with
rivets, I thought it would be worth a test run.
Rivet #1: no problem. Rivets #2, #3, and #4 split the plexiglas like an
adverb splits an infinitive.
Looks like we'll need some other plan for the placards:
probably just some kind of glue.
The nice new keypads have a different pinout than our earlier ones,
so I made a little protoboard adaptor and mounted the keypad in its panel.
When Jeremy wired the rocket last weekend, he found it easiest to
split the Elson Parallel Bus cable at the entrance to the raster
display. Splitting it is done with a male-to-male header connector.
But, as far as I know, that's not a standard part. As you can see,
it's not a very elegant hand-wired part, either.
The first time we
downloaded firmware to the rocket,
we had to remove seven sheet metal screws, four machine screws,
and two cable connectors to be able to plug the USB programmer into the
CPU board. We'll need who-knows-how-many firmware updates as we work the
bugs out, times three CPUs in the rocket -- that's a lot of screwing
and unscrewing and potentially broken wires.
The solution: bring each CPU's programming header out on a ten inch pigtail.
When not in use, they're tucked behind the panel;
for servicing, we can pull them out and plug them in.
Jeremy had an even grander vision: use the Atmel's self-programming facility,
and make them programmable over the network, via the through-the-trench
UART line. Yeah, I have to admit, being able to beam software updates to
the spacecraft from the living room sofa would be pretty cool. I mean,
it worked for the Mars rovers!
Jeremy came over this afternoon, and we got a bunch of little odds and ends
wrapped up, zip tied, and soldered together:
Jeremy soldered all the thruster and booster solenoids and lights
to their connectors, and built cables to connect them to their HPAM ports.
(My soldering iron is too wimpy even for 16ga wire. Jeremy became very
skilled with the little butane torch, the kind chefs use to carmelize crème brûlée, to the point that he could solder without singeing
the insulation, and even shrink the shrink wrap.
I wired in the (still unmounted) three interior lights and the overhead
light (pictured at right).
Lights are a pretty simple circuit, but it's pretty delightful that two more
rocker switches do something exciting now.
I've been visiting the rocket during rainstorms to learn where the
water sneaks in. Today I squirted a thick bead of silicone around the
apex of the lid.
I added a little aluminum flange to keep the lid's PVC strip from getting
closed in the window.
I took the window off to add PVC strips, but ran out of PVC, and didn't
make it to the store. I put it back on the rocket, since the rain is supposed
to return tomorrow.
Jeremy helped me install the box for the flight computer panel,
the last to go. No wiring on that bus yet; we're still waiting to get
the TWI bus in place.
Jeremy crimped on another IDC,
and plugged in the EPB adaptor,
making the raster board come alive with the control panel text.
I crimped on a power connector that brought the lunar distance & speed
panel online, so now all eight panels on CPU 0 are active.
Jeremy fixed the joystick software bug last night,
so I downloaded new firmware.
In this terrible video, you can see me moving the joystick,
and each thruster fires in response.
That was pretty satisfying!
the programming pigtails
I made them to avoid having to unscrew and uncable each CPU to reprogram it.
The pigtails also cut the 5V line, because when the laptop's 5V is connected
through the pigtail, it tries to drive four amps' worth of LEDs, and the USB
This they succeeded at; unfortunately, there was another problem:
the SPI lines used for programming are also used to drive the
Elson Parallel Bus, and now that we have ten feet of ribbon cable on that
bus, the bus capacitance is way too high and scrambles the bits going into
the laptop. Whoops.
I could fix this with the soldering iron,
adding a separate switch or header to make it easier to disconnect the
EPB when programming.
Or we could go all the way and figure out how to program them online,
and connect to it via the TWI bus (and eventally the UART).
That would be pretty keen.
I added some visual effects to the software:
A screen blanker takes over all of the LED displays (including the
bright white interior lighting) to blank
them when "idle", to flicker them when the booster is firing,
and to flash synchronized colors in "disco" mode.
In docking mode, pushing the joystick button fires the booster
(including rumbling audio and light flickering).
Getting this working involved transmitting new messages across the
rocket's TWI network; there are now five protocols running on the
The microcontroller boots up almost instantly, which of course will not
do at all.
I added a gratuitously slow bootup sequence modeled after the Bendix IFR GPS
in Jeremy's Cardinal, the fanciest display in his panel, and hence the
slowest to boot.
After adding all this stuff, I realized I'd once again blown past our
2K RAM budget, so I spent a little while trimming memory, mostly convincing
modules to time-share their offscreen bitmaps.
I worked on the audio software today on the plane home from San Diego,
connecting the (simulated) flash memory through ring buffers,
a stream compositor, then another ring buffer to the (simulated) output DAC.
It doesn't actually work yet.
Most of the day went into wiring.
I wired up the two boxes that host the four boards on CPU 1,
with an Elson Parallel Bus to connect the boards together,
power from the power panel,
and a TWI network cable from the CPU 0 panel.
I bundled up the wiring along with wires for the lighting on that side
of the rocket, and fastened it all nicely to the wall.
I also tidied up the lighting and CPU 0 wiring on the other side of the rocket
that Jeremy rough-fit a few weeks ago.
This morning Eliot and I took out the window panel, drilled the rivets,
and installed strips of PVC to help shed water before it leaks inside.
I fashioned some straps and little metal brackets to fasten them to
the couch frame, to make the seat more comfortable.
I'll put the couch back into the rocket tomorrow.
Today I started laying out the joystick mount box.
Eliot and I bolted the improved couch back into the rocket.
Eliot made a hook to which he plans to clip flight plans,
and riveted it into his rocket.
I wired together the compressor relay switch and LED circuit,
and installed it in the power panel.
I made a little plastic standoff for the power panel
that helps support it,
mounts the lighting resistor breakout board,
and provides a strain relief post to which incoming cables are zip-tied.
Finally, I made these aluminum mounting brackets for the exterior thruster
lights, interior lights, and interior overhead light.
I've had this pack of
sitting around in my shop forever, waiting for a chance to try them
on something with no requirements of strength, reliability, or aesthetics.
It's basically solder for aluminum: it has a lower melting point, and is
supposed to bond to the base metal without melting it.
I think I got it to work right, but I'm glad the only thing hanging on the
brackets are flashlights.
Yesterday, while Eliot and I were working in the rocket,
we noticed some weird artifacts on bus 0 (the one with a running CPU):
a sporadic minus sign flickered in front of the Lunar Distance readout,
and some of the segments on the raster board were incorrectly lit or dark.
What's going on? Why did this start now?
And why do the symptoms change when I put my hand alongside the cable?
Yikes: looks like the capacitance of the really-long Elson Parallel Bus
cable has finally caught up with us. It was working fine the day before,
but Sunday I rolled up the ribbon cable and stuffed it into the guide tube,
a little closer to the huge conductive plane of the rocket's skin.
It probably added just a bit more capacitance, enough to round off the
signals' edges so the latches sometimes saw the wrong value.
Now, flickery, slightly-incorrect displays add a certain amount of
hard-core intergalactic realism, kind of like stained and marred aluminum
skin. :v) But I think we'll fix this anyway; it should at least be working
correctly before first launch. Jeremy suggests we can clear it up with a
NOP (a "no-operation" instruction) that delays a little, giving the signal
time to settle before telling the latches to accept it.
I want to see the mucky signal on an oscilloscope first; I should assemble
my new Sparkfun oscilloscope kit,
take it out there, and check it out!
This got me thinking again about the fact that I can't program the boards
while they're plugged into the EPB.
The first problem was that the USB programmer was trying to power the entire
bus (seven amps worth of LEDs...), which I fixed by making
pigtails that separate the 5V line,
so the boards get rocket power, but data can flow from the programmer.
the pigtails weren't enough:
The EPB reuses some of the programming pins, and
the capacitance on the EPB was too high (even before Sunday's wire bundling)
for the data rate used by the programmer.
So tonight I made a new pigtail for bus 0:
it has a copy of the 5V-separated programming header,
and also an EPB interface with a 7407 driver
(not shown in the picture -- Jeremy brought some in,
but I left them on my desk)
isolating the high-capacitance side of the bus
from the CPU board and programming header.
I sure hope it works this time!
I made it out to the rocket tonight to try out the new EPB buffer.
Once I had plugged the programming header in the correct direction,
it worked perfectly: I can program the rocket without disconnecting
Unfortunately, the displays remain flickery and inconsistent, even
though I tried adding NOP delays before the latch strobe.
I really need to take a look at those lines with an oscilloscope.
So I came inside and put together my SparkFun Jyetech scope kit.
I got the Sparkfun oscilloscope working tonight.
(Turns out time scale "1m" meant one minute, not one millisecond.)
I scoped the EPB. I saw some mealy looking traces,
but not what I was expecting:
rather than every pulse drooping in a capacitative way,
most of the pulses were fine, but sometimes a pulse went by looking lousy.
What's going on?
I played more with slowing down the EPB clock, and still no dice.
It's surprising how consistent some of the display errors are:
certain segments seem to like to light up together.
I finished drawing plans in Inkscape
for the aluminum box that mounts the control
sidestick next to the pilot's seat.
I printed out them out at 1/3 scale and made a little paper model
to fold together to make sure it made sense.
(Yes, I know, Brian, I should really learn SketchUp already!)
It's ready to commit to aluminum.
Over the weekend, Jeremy researched the EPB problem,
which we now think is crosstalk: the wiggling address and data lines are
probably coupling inductively to the STROBE line, generating spurious
signals that latch incorrect segments.
Jeremy found a chapter in "H&H", the canonical EE textbook,
all about exactly what we were doing:
So, I'm trying to slog through 13 complex pages but they are basically
summed up by this sentence: "The signal pickup problem makes direct
logic drive with bundled multiwire cables almost hopeless."
So much for my EE degree. Every sentence of this chapter says
"You know that thing you did? Don't do it."
Jeremy and I grabbed JD today to sort things out.
In classic JD form, he asked "you are alternating signal and ground
on the ribbon cable, right?" Um, no.
Jeremy went through all the ideas he got from H&H,
and I also suggested the nuclear option: running TWI and breaking datagrams
back out to EPB using a separate microcontroller at each remote panel
JD's recommendations were pretty accessible. Plan A, the easiest thing to try,
is to string a separate, shielded wire for STROBE,
isolating it to protect
it from transients on the data channels. This involves only about five solder
splices into the ribbon cable.
If that doesn't work, we'll try Plan B: wire up a third variation on the
EPB buffer board with resistors between
the drivers and the long cable.
The cable's capacitance together with the resistors should form a little RC
circuit that limits the slew rate: how quickly the signal voltage
ramps from ground up to 5V.
Inductance is a function of that rate. Right now, the rate is "infinite".
By tweaking resistors, we can slow things down to reduce the inductive effect,
and then slow the software down to give the lines time to settle before we
strobe them into the latch.
I told Jeremy I'd run home and try Plan A right away, since it was so easy.
He said no way! I must wait until he gets his new used eBay oscilloscope
in the mail so we can look at the broken signals and see how things change
with the new wiring. Obligingly, I worked on the sidestick box tonight instead.
I made it down to the shop about 9pm, after Eliot got to bed.
There waiting for me was the full-scale plan sheet for the sidestick
box. Punch, scribe, drill, shear, file, heat, hammer, bend, and then
rather than rivet, I went to town with the Alumi-Weld.
It's lovely, by R-ULAV standards. A mere 2 1/2 hours. I'm glad there's
only one aluminum box left to build, the mount for the audio amp and
I gutted the Altec Lansing computer speaker system tonight, to figure out
how to mount it in the rocket.
The good: I was able to inject 12VDC after the transformer and rectifier
circuits and power both the subwoofer and main speaker amp boards.
The ugly: there are three biggish circuit boards to make all this go. It's going
to take a pretty big panel to mount it all.
The weird: when I powered it off of a wall wart, it made a quite noticeable
hum. This surprises me, since I'd assume that the supply current coming
from the rectifier would also be noisy; I figured that the power regulator
would be downstream of where I injected my noisy DC. (Although the giant
heat-sunk thing I took for a regulator might have been the final-stage
power transistor, now that I think about it.)
This may be a non-issue since we're feeding the rocket fairly clean power,
and perhaps not dirtying it up too much with our load -- only the 5VDC switcher
would likely generate much junk on the 12VDC side. We'll see.
The bad: the speakers had pretty substantial plastic housings, with obviously
deliberately-designed acoustic ports. When I pulled that all out, the woofer
wasn't quite so bass-y, and was a bit more rattle-y. I'm sure my
aluminum-and-plexiglas mounting box won't be acoustically decent in any
regard; hopefully it still sounds rumbly when it's all assembled.
I traced out the parts, came back upstairs, and drew everything up in Inkscape.
I wanted a cool hexagonal panel for this one, but it won't all fit in a
single laser cutter panel! Here's a draft drawing with two hexagons.
Maybe I'll do an irregular hexagon.
With mom's cool flight suits, and Noa's great logo design, how could we
not have patches made?
I spent a few hours with SophieSew last night
and tonight, and digitized the logo into an embroidery file.
I'm hoping to run it on an embroidery machine at the Portland TechShop;
we'll see how that goes.
On one hand, I'm terribly delighted that SophieSew exists: a free tool
that lets you control embroidery machines, in contrast with the heinously
expensive proprietary stuff from the machine manufacturers.
On the other hand, the tool is orphaned and pretty buggy. The UI is
mostly there to do tasks (spline manipulation, path operations) that
other programs (inkscape) already do much more easily. It's modal,
cumbersome and clumsy; just deleting objects is difficult, and undo
is actually impossible.
Setting the color of a stitch region is a seven click process, and
you have to do each separate region one ... at ... a ... time.
I finally got my design mostly done, and tried exporting it, and the
export code crashes with a null-pointer exception!
Oh man, is that frustrating, after hours of fiddling with the clunky UI.
I suspect I'll be able to tediously copy and paste the parts out of the
broken document and into a fresh document, using divide-and-conquer
to take only a logarithmic number of steps, until I've eliminated the
broken data structure. But what a humongous pain.
I really hope the author chooses to open-source the app. The best
outcome, I suspect, would be to rip out the file-format-export code
(the "secret knowledge") and the code that fills regions with stitches,
and use them to write a no-UI back-end to inkscape that consumes SVG
and emits embroidery control files.
I think Jeremy's coming over tomorrow with his new oscilloscope to debug
the EPB problem. Yay!
Jeremy came over this afternoon with his new oscilloscope, and
we diagnosed the ribbon cable crosstalk problem.
Here, we're running software that pulses all of the address and data
lines (one shown in cyan), but never the strobe line (yellow);
yet you can see the strobe line coupling pretty enthusiastically to
Four volts of enthusiasm, in fact.
Yup, apparently violating all thirteen rules of capacitative and inductive
coupling has resulted in a measurable amount of coupling.
Notice also that even the valid signals are wandering -2V to +7.5V,
on a system with only a 5V power supply.
Jeremy snipped the strobe line in preparation for replacing with a shielded
wire. He measured the effect again -- and we saw 2V of coupling just from
the nine inches of ribbon cable leading out of the CPU0 board.
But what really freaked Jeremy out was this: When he measured
the strobe line on a board that wasn't plugged into the CPU,
it was still coupled!
The only coupling was through the power supply: the meteoric slew rate
on the signal lines was enough to swing the power supply voltage almost
a volt. Ouch.
Our plan is to first install the shielded conductor for the strobe signal,
which should reduce the wire-to-wire coupling back down to 2V, which
while ridiculous, will probably get the rocket working again.
If it doesn't, I'll rebuild the buffer board a third time with JD's
proposed resistors to damp the slew rate to something finite,
which should clean everything up quite a bit. Here's hoping!
I poked at the scavenged audio amp stack for a while, rearranging the
wiring with my dremel and soldering iron, and making aluminum brackets
to stack the circuit boards together. It's now ready for making a plexiglas
panel and aluminum mounting box.
I pulled the joystick out of the rocket to mount it to the sidestick
mount box, and discovered that in the process of laying out the sheet
metal plans, I built the box inside out, so the joystick either doesn't
fit into the elegant profile I built, or points the wrong direction.
Dang dang dang!
I'm hoping to correct the situation without rebuilding the box
by pulling the joystick apart and turning the handle around.
I finished up the layout for the audio boards, including the plexiglas laser
cutter input files and the paper templates for cutting and bending sheet
I tried to export my patch design from SophieSew, but it kept throwing
an exception. I guessed that I had somehow created an object with a broken
internal data structure, so I spent a delightful hour using divide-and-conquer,
deleting some objects and testing to see if it would crash on export or not.
Wow, I really am starting to loathe SophieSew; it makes a fun task tedious
and crashy! (I don't actually loathe it; the author has done a great thing.
But it desperately needs to be set loose into a community of open source
hackers who will repair it.)
I eventually got the file salvaged. Then I went through and tidied up
the stitching order, and added some more design elements.
Then I applied the Jeremy Elson principle: I shopped on alibaba
for a bargain on an embroidery machine direct from Taiwan.
I cut the audio panels on the laser cutter this afternoon.
Tonight I mounted the five speakers to their panel, which
mostly worked, but it turns out the bass driver's excursion is
deeper than the spacer I made for it, and it rattles when playing
the bassy rocket rumble. So I need to make another spacer.
I mounted the stack of three audio circuit boards to their plexi panel.
Then I alligator-clipped a wall wart onto the power input,
plugged it into my computer,
and started playing the
brand new Majorstuen album.
Man, those guys are really amazing.
The speakers weren't too bad, either, considering the acoustic chamber
was a cardboard box.
The last thing I got done was the joystick.
I had to take the joystick's guts out,
rotate the handle 180°, and put it all back together.
Then I screwed the joystick to the aluminum mount box.
It looks good; hopefully I didn't break anything.
I some time on the Seattle side before running an errand this morning,
so I went out to the rocket, snipped the STROBE
line out of the ribbon cable, and spliced in the shielded wire.
I did this first for the 15-foot long run of cable, put it all together,
and it worked much better, but a still segments still showed noise.
There was still a two-foot section left leading to the HPAM panel,
so I opened that panel up to cut its STROBE as well.
When I did so, I noticed that the board had no power attached!
Hmm; maybe that was causing a little trouble, too, drawing a good part
of an amp through the EPB! Yikes.
I spliced in a shielded strobe wire, plugged in a power lead,
and put everything together. It works great! I haven't seet a flickery
Because we're still violating twelve of the Thirteen Rules Of Ribbon Cable,
there's probably still lots of ugly on the wires; perhaps Jeremy will bring
the scope back and we can re-check sometime.
But it's working fine now, which is good enough for a treehouse.
Even a rocket treehouse.
Last night I started out on getting the protocol working between rocket
processors. It's a two-wire protocol called "TWI" or "I2C"
(depending on manufacturer). I'd gotten serial ports working a few
months ago for my clock, but TWI is way more complicated. Serial is a
basic point-to-point, self-clocking protocol with two, non-interfering
one-way channels; using it very simple. Just write a byte, and it goes
out. TWI is a bus protocol with lots of flexibility (a.k.a. complexity)
for doing things like framing bytes into packets, addressing packets to
specific recipients on the bus, and allowing multiple masters to arbitrate
for the bus. The processor's datasheet has a 35 page chapter describing
how to use it!
I started working through this, luckily with my trusty logic analyzer
which has I2C bus decoding logic built-in. (This task would have
been impossible without it.) There were a bunch of hard-to-track-down
software bugs to work out, but the biggest problem turned out to be an
electrical one. For bus sharing, TWI bus members are "open collector"
-- that is, the bus needs pull-up resistors so that it is defined as
being high if no one has seized the bus. Each TWI bus member can drive
the bus low, but the only way to make it high is to disengage the drivers
and let the pullup resistor bring the line high again.
The issue was that the resistor had to be small enough that it could
"charge" the bus back to Vcc in a timely manner. The definition
of "timely" is a combination of the configured bit rate (i.e.,
how quickly the edge needs to reach its intended value) and the total
bus capacitance (larger caps need more current to charge in that time).
I arbitrarily picked a 10k resistor, since that's more or less the
"usual" value of a pullup resistor, but things were acting very
strangely. Out of desperation I searched the internet for advice on
how to pick a TWI pullup resistor value, and found conflicting answers.
One source said "I've seen values from 1k to 48k". Another said
"4.7k is the standard value." Really, how much of a difference
could it make to go to 4.7k to 10k?
Out of desperation, I tried it anyway. Watching the logic analyzer's
signals go by, things seemed to work for the first time! Then they
stopped. Then they started again. I finally decided to get out my new
analog scope -- the one we used to diagnose the problems on our other
bus -- and there it was, clear as day (image above).
This is a picture of the bus with 4.7k resistors. Wow. Those
"square" waves aren't very square. It takes so long to charge
the bus that the line isn't even getting all the way up to Vcc before
it's time to discharge again for the next clock cycle -- it's about
a volt shy. 10k resistors probably were, in fact, right on the edge:
just a little bit slower, they charged the bus just a little less --
less than the detection threshold.
I fixed this in two ways. First, I changed the resistors to 2k resistors.
Second, I reduced the bus speed from 500KHz to 100Khz (which is the TWI
standard anyway). And now, voila!
We're reaching Vc and staying there for a while before it's time to
discharge again. Now everything works -- here's the logic analyzer
snooping on my first "hello" message from one CPU to another.
You can't quite see it at this scale but there's acking of each byte.
The first block ("02 Write") means the master is saying "I want
to send a message to node 2". The sliver after that is node 2 acking
that it's ready to receive. Then, the master sends a series of bytes,
each of which is individually acked by the receiver. Finally the master
sends an end-of-message signal and releases the bus.
I haven't pulled the TWI all the way through into the networking stack
yet but, that's tomorrow's project.
The audio system wasn't working right in the simulator (no hardware yet),
and the first problem was that I couldn't emit a smooth stream of samples.
I poked at it for a frustratingly long time.
As far as I can tell, the O_NONBLOCK mode of the Linux
/dev/dsp driver is broken; I worked around it by forking a child
process to spoon-feed audio samples to /dev/dsp using blocking
writes. Now the simulator's output works correctly; I can move on to
getting the actual rocket audio code debugged.
In other exciting news, a KSEA (Seattle airport) air traffic controller
has tentatively agreed to provide voice talent for the rocket, in the role
of ... air traffic controller! Now I need to write a script for the part.
That's a processor programmed as a TWI receiver displaying its output. A 2nd processor is attached that's sending a hello message once per second.
I just checked in a big pile of code. I refactored the network stack so that network.c is strictly packet-oriented, and the framing code is separated (but not working) in a separate file called framing.c, used for underlying physical interfaces that are byte-oriented.
I'm confident enough in this that I'm going to bring CPU1 in tomorrow so Jon can install it.
Jeremy, having finished TWI, sent the second CPU board home with me today.
After getting the girls to bed, Eliot and I went out to the rocket to
install it. It's beautiful, of course!
Unfortunately, we didn't get very far. The keypad didn't work, which seems
to be because the circuit board traces peeled off my little adaptor board.
Eliot went to bed, then I made a new, sturdier adaptor and replaced the
resistors on the TWI hub board. Hopefully we'll have some keypad and TWI
This RASA update is being blogged live from the RULAV. I have made
the short TWI cables, and installed them on the TWI/joystick board, and
replaced it in the panel.
I corrected a soldering error in the new keypad adaptor, and verified with
Jeremy's standalone test program that the keypad is now working on its CPU.
I installed the TWI standalone tests, and verified that TWI packets are
successfully flowing in both directions across the rocket bus!
I reflashed the rocket code into the CPUs, and unfortunately, not all is
First, I can't seem to flash CPU1 if CPU0 is sending anything on the TWI
bus. Not sure why that is, but it can be worked around by unplugging the
TWI cable during programming.
Second, CPU0 loops during boot if it is connected to the TWI bus board.
Not even to another CPU, just the two lonely resistors are enough to
send it astray. It can be worked around by pulling the TWI cable to let
the boot sequence begin, then plugging it back in.
Third, and most sadly, even with app/rocket running on CPU0
and app/rocket1 running on CPU1, no data seems to flow:
Keypress events from CPU1 don't arrive at CPU0, and screenblanker and
thruster status events generated on CPU0 don't arrive on CPU1.
The one mysterious exception is that if CPU1 is attached during boot,
it indeed blanks its screen, as it should in response to the
screenblanker message CPU0 sends to black the displays during the startup
So, another mystery or two to solve. But the unit tests show that the
hardware is indeed functioning! That's really exciting.
I found a used, older-model personal embroidery machine on Craigslist
over the weekend, and found time last night to drive the 100-mile roundtrip
to pick it up in Stanwood. (Yes, I'm the guy who drives 100 miles to buy
a machine for $195 to save the $150 I'd have had to spend to have the
patches made professionally. Look, it's the journey, not the destination,
I did battle over breakfast with virtual machines, Windows XP, and a USB flash
programmer even more obsolete than XP. Eventually, by a complicated process
involving a chain of clunky software and two separate computers, I'm able
to migrate designs from SophieSew to the writable embroidery card and
transfer them to the machine.
Tonight, I came home, plugged everything in, strapped in some fabric,
and threaded the machine.
And, just like that, Noa's pixels rendered in threads!
The color scheme on this first one didn't come out perfectly,
and there are a few other little alignment problems and minor bugs,
but overall, it's pretty darn neat!
It took about an hour of machine tending to sew. I think that was about
half an hour of stitching, and another half hour of thread changes; the
design has a ridiculous sixteen thread colors.
In Yakima for most of the weekend. Eliot and I embroidered seven mission
patches plus five specialist role tags.
Embroidery is really a CNC operation, which means the operator doesn't
require much skill beyond threading the needle and listening for the
machine to start sounding wrong. Eliot embroidered two of the patches
When we got home, Eliot and I installed the joystick mounting box.
Then we installed the mounting brackets for the three interior lights,
the top-hatch-mounted overhead light, and the three thruster lights.
We pulled the extra slack out of the wires; bit-by-bit the rocket is
looking tidy and finished.
And then we flipped the propulsion circuit switch, which has absolutely
nothing at all to do with the interior lighting,
and the interior lights went out. What the heck?
By doodling with the various switches, I could get the lights to glow
brighter or dimmer. This can't be good.
The flashlight cases are tied to the LEDs' cathodes, and mounting them
tightly to the aluminum mounting blocks made good enough electrical contact
to "ground" them to the rocket chassis. I use scare quotes because we don't
actually deliberately ground the rocket. But anyway, why should it matter?
Because the cathodes aren't actually at ground: the interior LEDs are wired
common-anode, with a resistor between cathode and real ground. So the various
lights were shunting random voltages to the chassis.
I clipped the zip ties, insulated the mounting blocks with electrical tape,
and zipped the lights back into place; all is better now.
I mounted the audio circuits and the speaker box behind the couch.
In so doing, I noticed that I hadn't actually connected one of the sets of
speakers, and rectified that.
It's a shame to hide that glorious hexagonal speaker box with its
finely-laser-cut grille back there, but it really was the best spot for it
in an increasingly crowded capsule cabin.
So many loose ends tied up, let's keep going! I pulled the HPAM panel
and soldered a new pigtail on the flaky thruster0 connector.
(The old pigtail was made with 6" of Harbor Freight's 250-Foot Wire Storehouse,
which I really cannot recommend; the insulation is way too thick for molex
connectors. But if you insist, I'm sure you can find a 249½-Foot Wire
Storehouse available on clearance at the Bellevue store.)
Only one HPAM was actually connected to the Elson display board, and that with
a way-too long cable; the other was hard-wired with a jumper. Jeremy had
made me a replacement set of HPAM cables a couple weeks ago, but cautioned
me to double-check the pinout. A good warning: they indeed didn't match
the insalled cable. I poked out the molex pins and reordered them, and
put the HPAM panel all back together.
Unfortunately, the lights (which were hard-wired before) have stopped working,
and when I plug the hobbs meter into its HPAM port, the CPU reboots. Drat!
Well, by this time it's 10:30; enough for one day.
I made a few more rocket patches with the new embroidery machine over the
last few evenings.
Tonight I got out to the rocket with the laptop and debugged a few problems.
Since I'd turned the joystick around physically, I had to turn the signs
around in software so the correct thrusters fire.
We had two problems -- the booster was always on,
and the lights were off -- that when described together suggest an obvious
cause: the software mappings from symbols hpam_booster
and hpam_lights to LEDs were incorrectly initialized. Swapping
those two fixed things right up.
Plugging in the hobbs meter resets the CPU. This appears to be just
a voltage sag from the inductance of the motor inside the hobbs meter;
Jeremy thinks adding a cap to the HPAM board will clear it up. In the
meantime, it doesn't keep the rocket from working, since the latch holds
the meter running during the first reboot cycle, preventing a loop.
Now the rocket emits a soft "tick tick tick" of the meter running.
So the rocket is mostly back together and play-withable now. Yay!
We still need to sort out the TWI bug, so that the keypad can be used to
activate the various software programs.
I did use the "autotype" module to test disco mode, which was indeed
pretty down and fun-kay.
I have a pile of other plans, including getting the rocket to work.
Which I did. The rocket works. I'm 99% certain if you go to the back
yard and reprogram it, it'll work.
Well, my friend, I'll take those odds, because you're
I'm sitting in the R-ULAV right now. svn up, make, attach cables
while making, and everything just works, right out of the repository.
The photo shows the test rig I used to get the rocket to today's glorious state.
Center: sender and receiver boards running twitest. Left: My new TWI
bus board (v2!), with extra headers for test probes and even a power
light. Back: the Rigol scope and USBee logic analyzer. Center: two
Once Jeremy got the TWI network going,
most of the rocket functionality was working.
There were a few bugs, though:
when the software turned the hobbs meter on, the processor reset; and
when the software flickered the lights, the thrusters would randomly pulse,
The first problem wasn't a big deal, because processor would turn on the
hobbs, reset, then proceed normally; it wouldn't reset unless it went idle
and then woke back up.
The second problem was even less worrisome: everybody agreed that the
little blasts of thrust kind of added to the liftoff sequence.
But it still bugged me that there were (probably electrical) problems;
I wanted to fix them, and then put the random blasts back, in software.
This morning, I got out to the rocket and soldered in some big (2200µF)
caps on the lighting and hobbs busses. My "clever" wiring carried only the
switched ground back to the outgoing circuits, so I also added separate
+12 wires. I think the caps were the important part, but both bugs are now gone.
I also terminated the audio board and added a header to the power distribution
board to power it. Now the speakers pop when the rocket is turned on, and
hiss out a little noise. Jeremy's still building the board that produces
the audio signal.
Nearly a year ago, Eliot asked,
"I want to have a rocket birthday party.
Will the rocket be ready by my birthday?"
Ha ha ha! No, son, feature creep must run its course!
But it's finally done, or done enough to have a party.
Eliot made up this schedule for a birthday party that involves
a rocket trip to the moon, a rocket puzzle, and of course a
A month or so ago, HPAM 0 failed: the lights stopped turning on,
and the Hobbs meter stopped working.
Those were the only two occupied channels on HPAM 0, and the other two
channels continued to work.
The failure was weird: the indicator LEDs would come on initially,
then fade back off.
Jeremy and I discussed the possible causes at great length:
did we use the wrong diode to protect the MOSFETs, and induction voltage
spikes cooked them? Why both at the same time?
We came up with a bunch of theories, and Jeremy gave me a little baggy
with some better-chosen diodes and spare MOSFETs,
plus advice to inspect the copper traces carefully.
I poked at the board for a half an hour, replacing out the channel 3 diode
and MOSFET. Things didn't get better. I poked at it some more with a voltmeter,
trying to compare its behavior to the working channel 1.
The indicator LED wasn't even working;
could it have failed, breaking the circuit?
I eventually noticed that one of the cuts in the protoboard went a little
too far across a neighboring trace. It looked like a mere scratch
in the copper, but the ohmmeter showed otherwise.
Sure enough, bridging the scratch with soldered cured the board.
Apparently there had been just enough copper there to conduct a little
current through the LEDs, but even the 10mA of current was enough to heat
it up and change its resistance it so that it no longer conducted enough
current to light the LED.
After that minor victory,
I also gathered up the two quad encoder knobs,
used a couple LEDs to figure out their pinouts,
and made pigtails to connect them to the CPU1 board.
A couple nights ago I hacked out the code to run the quad knobs and
to encode an analog pot to generate input events, too.
Today I got out to the rocket with Eliot and his friend.
We installed the repaired HPAM
and fixed a wire splice that got broken during the Great Wire Bundling.
We chose a few nice knobs for the pots and quadrature encoders,
took them back to the shop to drill them out to the right diameter,
and then installed them.
I uploaded the new software.
I noticed that uploading on rocket1 is flaky; that's the CPU whose
programming port doesn't have the bus isolator.
The second quad knob didn't work immediately;
I'd put the ground pin on the wrong side of the connect.
The potsticker code had a bug or two
that I diagnosed from the orange couch.
One quadrature knob and one pot are working correctly,
and now Eliot can play Pong with round knobs, as it was meant to be.
I sped up pong a little, and tuned the response rate on the knobs.
I arranged for the second pot to tweak the lunar velocity display.
I also noticed that, if you bump the programming header
into the rocket's aluminum skin,
it gives off awesome sparks!
Oh yeah -- 5V. I should insulate that.
At Hallowe'en we showed the rocket off to some neighbors,
and were reminded that the takeoff, while rumbly,
sure could use a little more rocket-y noise.
And we already have an amplifier and woofer installed!
And software mostly written!
And audio samples created!
Eliot wondered just why we have a space in the panel marked
"audio board" with no actual audio board.
So I sat down to begin prototyping an audio board.
I got partway through, and fired off a long list of
questions to Jeremy.
Jeremy pointed out that he'd already breadboarded
much of the design last year.
And hand-sketched it up on a sheet of graph paper.
And scanned it.
And checked it into the rocket source code repository
And maybe I ought to start with that.
Armed with his schematic and recently-arrived Sparkfun and Digikey
orders, I prototyped the 3.3v conversion and SD slot, the pieces that
Jeremy hadn't yet prototyped. To be able to learn anything from the
prototype, I included a CPU, programming header, MAX232 and RS232
serial output port.
The only thing missing now is (a) software to talk to the SD card
and (b) a serial port. I forgot that modern laptops don't have serial
ports, so it's time to find a USB-serial dongle.
I spent the day at Jeremy's, poking at the SD card with the Atmega
and peeking at it with the logic analyzer. We almost got it working,
but our 8-bit SPI bytes seemed to only have 7 bits.
We later figured out this was because our 5-to-3.3 volt level
converter was actually emitting 2.5V;
changing the resistors found the missing clock pulse.
When I got home, I knew things were working well enough that it
was safe to start melting lead.
I had been layout out the protoboard on bus commutes,
so I was ready to start (images at right) placing the sockets,
marking the copper side for selective removal,
dremeling away the unwanted copper,
soldering in the sockets,
and then soldering in the rest of the components.
Today I finished up the rest of the board.
Eliot and I made a dash to Radio Shack for some very large resistors,
and I had to add some bigger capacitors to the MAX232 serial driver,
but otherwise the board mostly worked as it should.
Today I took the board and its USB cables with me on the bus.
I was excited to convert from
the polling-based test code to the
interrupt- and continuation-driven style needed to make the
SD-card stack integrate with the rest of the rocket operating system.
I finally got it working today;
in the screenshot, I wrote "Hello, world" to the card from my laptop,
plugged the card in, and read the string back out from rocket code.
Today I soldered in a needed capacitor for the audio output
(It turns out picofarads are 10^6 smaller than microfarads,
not 10^3. How embarrassing!), and getting the audio output code working.
I had audio streaming off the SD card by the evening.
In rocket tradition, I called Jeremy and Leisl to play the Apollo 11 countdown
over the phone.
Today I hammered out most of the rest of the software layers,
wiring the audio streaming module to get called by the existing code that
receives network packets telling it what should play.
The main board in the rocket is already issuing these packets;
it's just that for the last year they just fell out the end of the
network cable and drop through the perforated floor to the dirt below.
Today was different. There were some false starts: I needed to add a power
cable to the rocket, and I spent a long time with an oscilloscope
and a spare rocket board discovering that I'd just failed to set the
audio board's network address (blush).
But at 10pm, I went out to the rocket with a pair of headphones and the
audio board, and plugged it in.
When I turned on the master switch, I got the splash screen ... and a
(A quindar tone
is the beep that started and ended NASA Apollo transmissions.
They were only heard by the viewing public, not the vehicle crew, but
they're now so iconic that the R-ULAV is going to use them whenever possible.)
Pong beepend and booped exactly as expected.
And when I started a launch, the Apollo 11 countdown played in perfect
synchronization with the giant rolling digits. Success!
I've been hacking on the audio board every so many evenings for the last
couple months. I'm a little stuck; it seems to be having some analog-side
problems both with the DAC audio out and the TWI sections. So I'm sitting
on that until my fantastic Rigol scope shows up on the slow boat from
So a few other electronics treats have shown up. Jeremy and I discovered
the Atmega 1284, equipped like our workhorse 328, but in a 40-pin
through-hole package with a metric boatload of RAM and program flash.
I also grabbed a $4.50 LCD screen from eBay.
As an excuse to play with them,
I came up with this little toy for Eliot.