A data logging tool for the bicycle

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:

• get it done on one Sunday afternoon,
• do the hard work (i.e. precise timing and counting) on the PIC, leave the math to the host computer, and
• make it work with standard programs on the HP.

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 wouldn’t 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

Some random remarks and additions

Bells and whistles

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

• LED 1 toggles between on and of at each tick. This consumes the most current and shouldn't be used.
• LED 2 blinks for 0.1 s when the contact is  closed.
• LED 3 blinks for 0.05s when an output line is sent.

Power consumption

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.

Open problems and caveats

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.

What to do next

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.

(C) Wolfgang Strobl 1998