I use a HP 200LX bought in '95 at home and at work, which spends a lot of time in my panniers on my commute (~5000 km / a). Long ago, I tried to implement a kind of bicycle computer by (mis)using the LX200s serial interface, similar to the approaches discussed on the bikecurrent mailing-list. Well, the problems and the workarounds were quite similar, too.
This time, I applied my new knowledge about how to implement small electronic gadgets using MicroChips PIC processors (for my first toy, see .../mm47/), and so built a device which connects a standard reed contact, as used by most bicycle computers sold around here (Sigma, for example), to the HP.
Using a spare and slightly defective homebrew PCB (size ~1,3 *1,4 inch) as a prototype board, I took a PC16C84 processor, a 4,194,304 Hz quartz, 3 small capacitors, one resistor, a 9 pin RS232 connector and two sockets, in order to build an interface between the HPLX200 and a standard reed contact as used by most bicycle computers sold around here.
My design goals where threefold:
I reached these goals by not doing anything fancy on the PIC, and by sending the data in plain ASCII, via the standard null modem cable, which came with the HP LX 200.
The device is powered from the serial line (the HP delivers a good and stable 5.5 V on one of the lines, which is good for >10 mA, much more than necessary). When the HPs built-in terminal program is started, the device gets power, displays a signon message and asks for the measuring interval in seconds. I tried 1, 2, 5 and 10 and 60 seconds so far (too long an interval is not a good idea because of overflows - I'm using unsigned 16 bit numbers as counters).
For each interval, the PIC collects resp. maintains three informations: the current time (expressed in 16th of a second), the number of ticks in the current interval, and the duration between the last two ticks, i. e. the time for the last revolution of the wheel (expressed in 1/4096 of a second), and reports this after each interval over the serial line, sending one line containing something like
1440 14 1374
every five seconds, when the interval is five seconds.
Why these funny numbers? Well, for technical reasons, it is easier, faster and more precise to use binary fractions and powers of two, wherever possible, on the PIC, and to leave rounding and time consuming arithmetic to the host. The resulting accuracy is dictated by the desire to work with reasonably small numbers, not by what the PIC could do in principle. (It wouldnt be overly difficult to measure one revolution with ~1 µs accuracy, or, to be more precise, the time between two contacts of the reed contact with that accuracy - but this only would aquire excess precision which had to be thrown away afterwards, anyway).
Time for a real example. The following snipped is an actual trace produced by my HPs datacomm application, taken this morning.
Tacho5/Pic16C84 0.5 (c) Strobl 1998 mailto:Wolfgang.Strobl@gmd.de # seconds between outputs?5 * 80 0 0 160 0 0 240 0 0 320 0 0 400 0 0 480 0 0 560 0 0 640 0 0 720 0 0 800 6 2531 880 9 1867 960 16 1174 1040 19 1123 1120 17 1186 1200 16 1238 1280 15 1311 1360 14 1400 1440 14 1374 1520 17 1209 1600 16 1309 1680 15 1426 1760 14 1458 1840 14 1474 1920 14 1456 2000 14 1455 2080 15 1432 2160 14 1450 2240 14 1461 2320 14 1471 2400 14 1560
When feed into Excel, I get these numbers
|************* from PIC **************||One
|Accum. rev #||Distance
In addition to the aforementioned interfaces and data, the device produces some more information which can happily ignored :).
It sends an ASCII BEL (^G, 7(dec)) over the line each time it detects a closed reed contact, this makes the HPs terminal programm beep. Main purpose: it makes other people on the road give you a strange look, occasionally. People aren't accustomed to beeping bicycles. It could be used for implementing ones own counting on the host, to, though (but why would one want to do that?).
There are three output bits for LEDS (connect pin to LED to a resistor to ground), which give different feedback (used that for testing, and left it in the code, afterwards):
About 1.6 - 2.0 mA, when no LED is connected, plus whatever any LED consumes (depends on the LED and the resistor, of course).
When no activity is sensed for 60 intervals (i.e. 5 minutes when using a 5 s interval), the device goes into sleep mode and consumes about 60 µA in that mode. A closed reed contact wakes it up again, where it starts with a zero timer (for convenience, not from necessity), but without asking for an intervall, again.
Usually, the HP goes to sleep after a while too, without data, and so making this inoperative. This could be fixed with a goldcap, but I didn't bother.
Well, as always: how to wrap it up. Today, I put it in a plastic back (because of the rain) and in my Cannondale handebar bag. Ugly, but it worked. The connection to the HP didn't work so well, though. The HPs side connector of the HP cable isn't fixed in any way to the shell, so it always gets loose (four times, this morning). I've either to fix it with some tape (ugly, too), or will have to build my own connector.
Hmm. Are there any programmable palmtops which have a _builtin_ RF link? IR is of no worth in a device sitting in the handlebar bag or in the pannier, and so is a receiver which is connected to the computer with a fragile and vulnerable connector.
There is currently no protection of any kind, not even current limiting resistors on the serial interface or on the lines to the reed relais. The PICs clamping diodes are quite good, but a few more components could make the whole thing a lot more robust and, last but not least, more foolproof.
I'll have to find a replacement for the reed contact, because the old one I'm using just now is not reliable (it doesn't always close when it should), and I'll have to find and work on a casing, and collect some data with it (what worth is a device if one doesn't use it?).
If that is done and finished, I'll perhaps do it again, this time based on a 8 pin PIC, to be mounted directly into a 9 pin RS232 casing.