embedded software boot camp

Sanity checking data

Sunday, May 29th, 2011 by Nigel Jones

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:

  1. Median filter the data to remove random outliers. (Incite may be doing this).
  2. 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:

  1. Zero
  2. The most recent valid data
  3. 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.

13 Responses to “Sanity checking data”

  1. Fernando says:

    ItΒ΄s nice to heard about you after so long. IΒ΄m still waiting for the “Hardware questions” article.

    Best regards,

    • Nigel Jones says:

      Thanks Fernando. The hardware questions article is almost done. I have been holding off on it because I suspect it will generate a lot of comments (good and bad!), and so I want to make sure I have the bandwidth to answer them.

  2. Ales says:

    Hi Nigel,

    that was interesting. Thanks for sharing your experience with your bike computer.
    Now I am glad that I have picked for myself a normal, wired bike computer. πŸ˜‰

    PS It is really nice to hear again from you.


  3. George Pikoulis says:

    Also don’t forget that a 2’s complement checksum in the transfer protocol could save the day.
    That is ofcourse if the bogus data were actually caused by RF interference.

    • Nigel Jones says:

      I forgot to mention that I think the RF link is strictly analogue, so that no error detection can be built in. I think the latest Incite bike computers use a digital protocol – so hopefully it does have some form of error detection.

      • Lundin says:

        Pure analogue? What if they manage to sell more than one unit of it? It would catch the signals from other bikes. Giving them unique frequencies will solve nothing:

        – The number of frequencies in whatever band they are using will only last so far.
        – There is the issue with image frequency which may be interpreted as a valid signal by other bikes.
        – It will catch every other signal appearing on the radio band. If it is for example working on one of the public ISM bands, it could never be used near cities, because of the large number of radio signals in the air.

        I work with industrial radio myself. This is how radio transmission was done 50 years ago, before CPUs were invented. The only serious way to design these products is to use a digital protocol with unique serial numbers for every unit sold. Also, why they aren’t using low cost Bluetooth or Zigbee is beyond me.

        Perhaps a sanity check is more appropriate on the person who designed this system! πŸ™‚

        • Travis says:

          It’s very possible that the pickup unit has no processing power at all, just an analog blip that happens on every switch closure as the magnet passes by.

          Another approach the computer might have employed would be to use the inertia of the wheel to help the filtering, implementing a sort of software-based PLL. The speed of the wheel can’t vary quickly; using the latest “good” values to form a window of allowed values for the next event. If the last read speed was 90 RPM, we can expect the next signal to arrive in 1/90 seconds, plus or minus a reasonable amount.

          • Nigel Jones says:

            I’m fairly sure that this is indeed the case. I agree that a software PLL might be a good idea. However as someone else pointed out, perhaps the lack of code space prevented this.

        • Anders says:

          Serious or not, this is still the way a lot of this kind of fitness monitoring systems work. I own a relatively cheap Suunto heart rate monitor with analogue transmission. It works fine when I’m outdoors or when at the gym, *except* when I use one of the fitness bikes. This bike automatically picks up my heart rate from my chest strap; but my *watch* all of a sudden loses the signal intermittently during the ride.

          But my signal is also picked up by the bike next to me… And this is a rather expensive industrial strength (or rather “gym strength”) fitness bike.

  4. david collier says:

    Hi Nigel,

    your posts are always welcome and thought-provoking, but we don’t expect you to run your life just to keep us amused πŸ™‚

    Looks to me like the choice of a non-digital comms method here was always going to be iffy, but no sanity-check is a silly bit of corner-cutting, assuming they haven’t run out of therir 1K of code space!


Leave a Reply