I've finally created a page for this fun little tilt-sensing toy I made using a MEMS accelerometer, some LEDs, and the LM3914 bar-graph driver. It was knocked together in an afternoon in 2002, so don't look too closely at the somewhat crude construction techniques in this one!

Be liberal in what you accept, and conservative in what you send.

—Postel's Prescription, by Jon Postel

I have a day job as a hardware engineer for a telecommunications company, and in this capacity I'm often designing equipment to be installed in phone company Central Offices (COs). Unlike the designers of consumer electronics or data center hardware, I can rely on having DC available to power my devices; COs have “rectifier plants” that convert mains AC to 48-volt DC and distribute this power through the facility with giant copper or aluminum busbars over the racks.

Most CO equipment uses two-pin Phoenix-style connectors as power inlets. These come with a pluggable terminal block with screw-down style connectors that accept bare wire from the rack's fuse and power distribution panel. Because installers wire this plug on site and mistakes are easy to make, it's good sense (and company policy) for the hardware designer to put a bridge rectifier across the input leads so that this connection can be insensitive to polarity.

This is an application of the first part of Postel's Prescription, “be liberal in what you accept”, to power engineering. If the second part, “conservative in what you send”, has an analogue in this field, it could be this: make sure your power outputs, if any, have clearly defined polarity. Another possible analogue would be: keep the output to a tighter voltage range than the telecom standard 36-72 volts.

As a way of trying out github for myself I uploaded a small script that iteratively solves the Colebrook equation for the Darcy-Weisbach friction factor, which can be used to estimate head loss due to pipe friction; this played a very minor role in my recent MSEE thesis. The script runs in GNU Octave and it certainly should run in Matlab as well, although I haven't tested that.

Of all the 500 series modular scopes made by Tektronix, the 547 is one of the most desirable due to its 50 MHz bandwidth and innovative dual timebases. When released, this machine was way-hot high tech, crammed with a mix of vacuum tubes and discrete semiconductors, and worth as much as a new car. I got mine through a friend who found it at a church rummage sale and paid $10 for it, complete with cart, some extra modules, and manuals for everything. Any problems? Well sure—the thing's been in service for 40 years, knocked about by at least two private companies (judging by the calibration stickers) and its original owner, the United States Navy. A short list:

• The dust filter that covered the fan was missing, because the bolts that kept the bezel on were sheared off—though the bezel came with the scope in the drawer of the cart, at least.
• The original power inlet was cracked, and missing its ground pin, which is more than a little dangerous.
• The fuse holder was chewed up and unable to retain the fuse and cap, which was missing entirely.

Our New Year's Eve fireworks shows are something to see—or so I gather from the reactions of the crowd. I don't really know, to tell the truth. Running around with a blowtorch lighting fuses doesn't give you a chance to watch the show for yourself and see what everyone's ooh-ing and aah-ing about. So for the last couple of years, my friends and I have been working our way towards the holy grail of backyard pyro—complete, automated computer control of the fireworks show. We started out the usual way, with a variety of electrical ignitors hard-wired into a "nail board" or a console of switches; I'll have to write a more complete history of these attempts sometime, more for my dear readers' laughs than for their technical edification. This year, however, we rolled out the first version of something completely different—a 12-channel, serial-controlled, microcontroller-driven, battery-powered, pyro ignition device!

On to the engineering, then: the microcontroller is an Atmel AVR, a 90S8515 running at 8 MHz to be exact (obsolete chip, sure, but I had one lying around—the next version uses an ATMega16 instead). This accepts RS-232 serial via the MAX-232 driver, interprets the byte it receives and fires the appropriate squib by pulling the gate of a NMOS high. The MOSFETs are STI P16NF06L's in TO-220 packages, good for 16 amps of drain current each; this high-current capability is built in to accommodate some types of very low resistance squibs that need a lot of current to fire.

As a temporary kludge for New Year's (I ran out of time as usual), I packaged the board and a 12V Sealed Lead-Acid battery in a tupperware tub. Since this was sited close to my mortar rack, which might spit out flaming bits onto the plastic box, I protected the top with a folded piece of sheet aluminum.