Speedo From Hell

I have been having a particularly unlucky couple of weeks, in regards to the whole PDA bike computer/speedometer thing. The PDA I'd been using, that Treo PDAPhone with the battery-eating problem, finally ceased to operate at all regardless of what battery I tried in it. It had been getting only a minute or two of operation even on a full charge, and the unit got pretty hot while running, so it was not unexpected.

Before it died, I had tried a few experiments with other PDAs, to no avail. An original Handspring Visor turned out to only have PalmOS 3.1, so I could not even use IR Hotsync on it, and had no cable for it, so couldn't upload VeloAce to it from the laptop. I did finally get VeloAce on it via beaming it from the Treo before it's death, but it just crashes with a fatal exception due to the old OS version (VeloAce only works on 3.5 and up).

I have an old Samsung PDAPhone that doesn't even seem to have a program memory to upload *to*, and doesn't appear to support any upload or even beaming functions at all, though it does have IR, and it's the only other PalmOS unit I even have. Well, there's the Sony Clie that randomly crashes, usually requring a reset that wipes out the VeloAce program (forcing a full resync with a PC to upload it again, as I have no MemoryStick that will work in the Clie to keep VeloAce on). Not very helpful. Other than that I just have the Ipaq Windows-based unit, which while it works well, it won't run PalmOS based apps. :-(


So that leaves me with the options of buying a speedometer (pretty cheap, but it's still spending money *and* it's buying something *new*, which must be done only when no other option exists, for these projects) or making one from something else (or from scratch). I could probably make a mechanical one reasonably easily, or transplant the one off the carcass of a Honda gaspowered scooter someone donated to me, but I choose not to because it's less of a challenge. :-)

There are two options I could do that I thought of during lunch:

One: use an op-amp-based integrator to convert pulses from the wheel revolution sensor into a voltage that I can display on my super-cheap Harbor Freight multimeter, simply scaling the voltage so that it equals 1/10th of the actual miles-per-hour. Scaling down to 1/10th only needed so I don't have to have at least 20-something volts available to the op-amp system, and can use 3.4volts to power the whole thing, and run it off a Li-Ion phone battery, just as I do the actual wheel sensor/debouncer/IR thing I made for the PDA phone. That way I can put it all in the same project box (there's a little room left), and just run a direct connection to the meter's voltage jacks.

This has the advantage that it is very simple to design and build, but the disadvantage that the meter is pretty big and bulky, compared even to a whole PDA (just a bit smaller than a small paperback book). The screen is big enough to easily read, though, and I can install an LED backlight for it, so I can see it at night, too.


Two: use an old step-counter originally made to count the number of steps you take as you walk or jog for exercise, with a handy little LCD already built-in, and run the wheel sensor to the input where the step-sensor goes, instead. Then the reset button gets wired to a timer that clears it to zero at whatever time period is needed so that the display is zeroed just after whatever the actual miles-per-hour reading would be. If I use 10 magnets on the wheel's spokes, evenly spaced around, that's about 1/10th of a second between resets to read approximately correct.

Now, there is a problem in that the screen will be difficult or impossible to read due to the extremely quickly changing numbers, and would probably have to be kept blanked until actually about to be reset, left on for an instant, then reset and blanked again. This might make the display too dim to read, especially since the screen is very small to start with--about 1/4" high, maybe a bit less.

A possible solution that makes it a little more complex to build is to count one "period", then disable the counter input, so it holds the value on the screen for a second. After that second, it resets and counts again, holds, resets, counts, holds, resets, etc. In theory it should work, and not add that much more complexity. Using a 556 with two timers instead of a 555 with one, and double the number of resistors and capacitors, it only doubles the amount of space it will take up, and perhaps double the amount of power it will draw.


I may build both, and use them at the same time to see how well each works compared to the other. The voltage display version will be more instantaneously accurate, and a realtime readout, while the much smaller stepcounter version will have that 1.1 second lag between updates. Safer to use the voltage display version, I guess. :)


I've been trying to think of any other devices I have that could display a number I could reasonably easily generate from the wheel sensor and *very* simple electronics, but there really isn't much that doesnt' quickly get complex enough to be easier to do in software and either use a PDA or a microcontroller, neither of which I know how to program.


The only other displays I have (or could make) that would clearly display my speed are an analog needle magnetic-deflection display (like from an old analog multimeter), or a line of LEDs attached to a level-meter chip or transistor array. Both of these would run off the wheel-sensor-to-voltage converter, just like the DMM, but would be analog instead of digital displays. The LEDs would be easily visible at night, but hard to see in the daytime, unless I made them so bright that they'd blind me at night without adding an automatic dimmer. Much easier to add a backlight LED to the analog needle display, which would be easily visible without backlighting in the day, so the LED would only need to be just bright enough to make the display visible in the dark, and could be switched off manually or by an ALS when ambient light is bright enough to see it clearly by. I'd need to calibrate the display either way and print out a little chart to stick on it or in it with the appropriate MPH labelling for each position.


In all cases, the wheel sensor can remain virtually identical to what I already have: a one-shot debouncer circuit with a one-shot pulse-creator after it, but instead of driving an IR LED to send the pulses to a PDA, it would directly wire to the input of whichever intermediate conversion circuit I'd use. Easy enough to do, since the IR LED in my setup simply plugs into a 1/8" phono jack (salvaged off some motherboard) on the wheel sensor box anyway.


Calibrating the whole thing I can roughly do with the Sony Clie running off the IR LED, and just compare readings as I adjust the converter(s) for each kind of setup until they match the Clie's readout as I ride at different speeds. If that won't work for some reason (like if the Clie just won't work long enough), I may have to borrow another biker's speedometer temporarily to do it, but it should be easy enough to calculate everything so it's pretty close to begin with, and only have to worry about component tolerances not cancelling out for the fine tuning. :-)