One of the major differences between embedded systems engineers and the general public is that we tend to notice embedded systems a lot more – both when they do something very well, and also of course when they do things not so well. The latter happened to me recently when I was pursuing one of my hobbies, namely riding my bicycle. I’m quite a keen cyclist, in part because I happen to live in part of the world which has some terrific riding country. (To see what I mean, check out the photos of the ride in question. They were taken by my cycling (and skiing) buddy Bill – who I think you’ll agree is a very fine photographer. Click here to see more of his published work. If you hunt carefully, you’ll find some pictures of yours truly).
Anyway at about 25 miles into the ride, I noticed that my Incite bike computer was showing that I had ridden 34 miles. This struck me as unlikely, and so I asked Bill what mileage he had on his computer – 25 being the answer. I thus cycled through the computer screens, until I came to this one (photo courtesy of Bill Tan).
Apparently the computer thought that I had hit 132.6 mph at some point – and obviously sustained it for quite a while for me to gain about 9 miles. Now to understand how this could come about, you need to know a little about my bike computer. The computer consists of two parts, the User Interface (shown above) and the pick up. The pick up senses wheel rotation by a magnet passing close to what I assume is a Hall Effect Sensor. Now whereas many bike computers transfer the signal along a cable to the display, mine transmits it using an RF link – and this I suspect was the root cause of the problem. My guess is that at some point in the ride, I rode into an area of RF interference that the display interpreted as signals from the pickup. The firmware in the bike computer appears to have blithely accepted the RF data as valid and thus produced the ridiculous result shown here.
Now I have often been faced with this kind of problem – and the solution is not easy. However IMHO Incite really fell down on the job here. If I had been writing the code, I suspect that I’d have done the following:
- Median filter the data to remove random outliers. (Incite may be doing this).
- Sanity check the output of the median filter. If the answer is ‘impossible’ (like a human pedaling a bicycle at 132.6 mph), then reject the data and let the user know that something is amiss. Incite did neither of these things.
Rejecting the data is actually a little harder than it sounds. If you reject data, what do you replace it with? Common choices are:
- The most recent valid data
- The average of the last N readings.
Each of these has its place and is application dependent.
Letting the user know that something is amiss, is usually straight forward – flashing the erroneous value is the normal solution.
Anyway, the bottom line is that a wise embedded engineer always sanity checks the incoming (and outgoing) data. If you do you are less likely to end up as the subject of a blog posting.
A personal note
I apologize for the abysmal rate at which I have been posting. I moved house this spring, which coupled with me being extremely busy has resulted in there simply not being enough hours in the day. When that happens, something has to give. I hope to return to my normal blog posting rate in July.