Search all of my sites with Google

Wednesday, November 5, 2008

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. :-)


  1. I have a palm m100 which is sitting around collecting dust that you're welcome to. It has infrared, runs PalmOS 3.5.1, and runs on AA batteries. Works fine, but it's missing the flip-cover. The OS runs out of ROM, so it's not upgradeable but of course you can upload programs to it via serial cable.

    It's yours if you're willing to paypal me $5 or so to offset shipping. I'm "eil" on the ladyada forums. Let me know. :)

  2. hey aw,

    In lieu of an actual spedometer, have you thought of just using a (used) GPS?

  3. Charles, that PDA worked great. :-)

    hzoi, I have considered using a GPS, and even borrowed a friend's cheap Magellan for a day. However it does not work well at low speeds, and often loses track of even which direction it is going at those speeds. Since I am typically going fairly slow, between 5-10MPH in many back street areas, then when I do it simply doesn't really work.

    In some places, with powerlines overhead or lots of tall buildings, it loses track of enough satellites it can't even tell me anything at all.

    Also, with at least that particular GPS unit, the only screen that displayed speed realtime on it had it in very small print in the middle of a bunch of other stuff, making it not all that useful for quickly glancing at during a ride. I could conceivably mask off all but that part of the screen when using it as a speedometer to avoid the delay figuring out which part I'm looking for, but that still leaves the small print problem. :-(

    I would still like to get a GPS for the bike for actually finding my way around, but it'd have to be one with up to date detailed maps that include bike paths, and allow user-editing of the maps to permanently add or remove things from it, both via the GPS unit and via a PC connection. I can't find any of them that do this, at least not used. Maybe newer models would, but I am sure they'd be very expensive.

    It would also need to have a touch screen so that I can change screens or settings during a ride without having to use buttons for this--those tend to be beyond awkward even when just standing in one place to use, with horrible menu systems that aren't intuitive. Even the touchscreens I've used don't really have intuitive GUIs, and could be MUCH better-designed.

  4. This PDA has now been working as my speedo/etc for about a year, and should continue to do so pretty well for some time to come!


Alternate suggestions or improvements to anything that's been posted is very welcome, and extreme detail is preferred to brevity.

Keep in mind that unless you leave an email address in your comment, I haven't any way to reply to you except to reply to your comment here. That means if you want a reply, you'll have to come back to *this* blog entry and it's comments to see my reply to you, unless you leave some method of contact within your comment.