Background: what went wrong in 2001
The 2000 bike trip was cancelled, and I never put the (working!) 2000 Bike Trip Computer Replacement onto a final circuit board. About half of it still sits on the protoboard that I designed it on; the other half has been reused for other projects.
The old design was scrapped because, in 2001, I had an iPaq. I already had utilities for Linux for the bike trip (since I used to use my Libretto for the trip). So the iPaq, running Linux, was a seemingly perfect solution.
If you've seen our Travel Logs from the 2001 trip, then you know that the entire 2001 system failed. In retrospect, it failed because:
- I expected the transition to iPaq Linux to be straightforward, but it wasn't (mainly because of StrongARM byte alignment issues)
- Not enough testing time
- Linux was running as root, and I've proven that it's a bad idea to do any work as root while biking
Looking forward: how I intend to make things better in 2002
So, for 2002, I'm still using the iPaq... but running Windows CE (PocketPC OS 2002), so that I can't destroy it (or at least can't destroy it as easily as I did in 2001). I've written all new custom software in C++ which shows a live map of our location, gathers information from the GPS every few seconds, and displays our route information. Every 20 minutes or so, it dials up the cell phone and uploads our tracking data as well as any travel logs that we have written.
There were some new obstacles to overcome with this design. The software was the easy part, really -- every year, the TIGER mapping engine, which we use fo r our live-updating bike page, dies in the middle of the trip (when everyone starts hitting the page), and we fixed that this year by rewriting most of the web engine to use cached maps from TIGER. So we already had an engine that could display maps and plot data on them.
Who turned out the lights?
But if the iPaq is going to not only be turned on for the whole trip, but is also going to be doing some serious math along the way, then we need to deal with the battery life. The iPaq has a 950 mA internal (non-replaceable) battery, which gives it between one and three hours of runtime (depending on how bright the backlight is and how much CPU you're using). Therefore, the unit must draw between 300mA and 950mA when running. We figure that it will be busy about 80% of the time, so I settled on 800mA as a normal upper bound for my initial calculations. Obviously, having the iPaq work for about an hour per day wasn't going to work; our longest biking day is 6 hours, so we needed to improve battery life quite a bit.
I started out by playing with conventional alkaline AA cells. Unfortunately, the high internal resistance of these batteries makes it a pretty silly replacement; I could only power the iPaq for about an hour from four AAs. The short runtime has nothing to do with the (mAH) capacity of the batteries: it's simply a matter of voltage drop. Simple Ohm's Law: with a fixed resistance, if the current draw goes up (because the device wants a *lot* of current), then the supplied voltage goes down. Because of the high internal resistance, the amount that the voltage drops is significant.
So I quickly switched tracks to NiMH batteries. These have a very low internal resistance and a high capacity, making them much better suited to the task. But I really didn't want to buy several dozen NiMH cells for the trip; it would become a serious investment of cash very quickly.
Then I remembered that I had some old Powerbook 520 batteries lying around. These batteries are probably the worst engineered batteries that I've ever seen. They consist of 8 NiMH "A"-size cells in series. The bad part? When they're charged, they're all charged as one big battery. I'm not going to get into the physics of batteries, but this basically ensures that at least 1 of the 8 cells will die within a year, which will render the entire battery useless... until you buy another $140 battery from Apple.
But Apple's engineering mistake is my fortune: odds are that most of the cells in the batteries will still be good! I scrounged up 6 PowerBook 500 series batteries (two at home and four at work, waiting to be recycled), and rescued a total of 40 working "A" cells. (In case you're wondering, an "A"-size cell is the same length as a "AA" cell, but is a little fatter. They have a higher storage capacity. If you've ever seen the clock battery from an original Macintosh, 128, or 512, then you know what an "A" battery looks like.)
So after about a week of sorting out the cells and testing their capacity, I decided on batteries that consisted of 8 cells -- two sets of 4 series cells in parallel. This gives me just under 5 volts output power, and nearly doubles the length of time that the battery will run. I soldered them onto perfboard, and packaged them in old DLT tape cases. I used 9V connectors for easy (and reliable) connection, and provided jumpers in the DLT cases to let me recharge the batteries better than Apple did in the originals. Here's a picture of the final batteries (with one connected to two chargers):
And in the event of a battery emergency, I've got a holder for 4 AA cells which can stand in (with atrocious performance, but it's just an emergency measure).
Pass the Cheerios
Next problem: interfacing all of the hardware to the iPaq. Our map-drawing solution needs about 80MB of storage for the compressed maps (which are just the maps along our route, giving us a few miles on each side). That means that I have to put a storage card in the PCMCIA sleeve. The iPaq also has an IR port and one serial port. It also needs to talk to the GPS (via 4800 or 9600 baud serial) and the phone (via 9600 baud serial or IrDA). I quickly learned that IrDA would be impossible with my current phone (a Motorola P280): the phone insists that the user press buttons on the phone whenever the IrDA connection is dropped. That left me with two serial devices and one serial port.
Solution: I didn't really need hardware handshaking, anyway. I wired up one of the HwHs lines from the serial port to two relays (switched by a 2222 transistor fed by the battery packs), which switch the send and transmit lines from the serial port. Normally, the serial lines are connected to the GPS. When power is applied to the CTS line of the serial port, the relays switch the connection over to the phone. I packaged the ugly solution into an 8mm tape case. You can see it in this picture:
Fingers crossed...
So, with the aid of a few GPS bike mounts, I can mount the iPaq (in the ruggedized case pictured above), the interface box, and the GPS on the handlebars of my bike. The DB9 in the picture above (which has a 9V connector sticking out of it) runs back the length of the bike to my luggage, where the cell phone and battery packs are. I've been testing this solution for about 3 months now, and it seems pretty good so far...