Thursday, March 8, 2012

Speed calculations - where do they come from?

When you click on a racer on the IonEarth satellite tracker, it shows you their geographic coordinates, the time of the reading, the race mile, and their speed.  I addressed the question of how they calculate the race mile in this post, and I thought it might be interesting to see how they calculate speed.  One thing that interested me a lot is why their speed numbers are so smooth, compared to the ones being computed by the Spot-based trackers.  The latter can produce quite erratic numbers with a systematic bias on the low side.  Ultimately where I ended up is that the IonEarth GPS units are probably doing more work than I realized, and are another example of good hardware engineering and smart tradeoffs.

Consumer GPS units typically calculate and display speed for you, but they're taking frequent location readings, which drains the batteries pretty quickly.  The IonEarth battery lasts for two weeks in extreme cold, so it's seems unlikely that they're taking frequent readings.  My starting assumption was the obvious bet that they're using the distance between adjacent readings to calculate speed.  I chose Paul Gephardt at random and two readings as he was nearing Rainy Pass: one at 10:20am on Monday and the following at 10:30am on Monday.  Based on the coordinates from the GPS readings, he traveled 1.35 miles in that 10 minutes.  Multiply by 6 (since we've got 6 10-minute periods in an hour), and we get 8.1mph.  However, the tracker says he was traveling 8.4mph in that period.  Why the difference?

So, I backed up to find the difference between the 10:30 reading at the 10:10 reading.  That gave me 2.7 miles in 20 minutes, or 8.1 mph.  Still no match.  Back one more!  Paul traveled 4.1 miles in 1/2 hour, or 8.2 mph.  I'm still not getting the 8.4 mph that the tracker claimed.  So, I went back and calculated the distance he'd traveled since 9:30, or exactly an hour, and I got 7.8 miles - not even close.

This is starting to get annoying.

What I've been doing, here, is trying to calculate what are known as "moving averages."  Moving averages are a terrific way of smoothing erratic data and looking at longer-term trends.  It's a handy tool for taking a look at stock trends, polling data, all sorts of collections of numbers where you're interested in how they change over time.  I've noticed that the Iditarod speed numbers are more consistent than what we'd seen in the Quest and it occurred to me that they might be calculating moving averages on speed (although when they're stopped, they're stopped) as a way of smoothing the speed numbers.  If they are, I can't see it, since the speed numbers all seem to be on the high side of what I'm calculating (you wouldn't see a consistent bias in an average like that).

So, the next candidate is weighting.  Trackleaders knows that since they're calculating speed based on the distance between two points and a racer is never traveling on a perfectly straight line, they need to do something to correct for underestimating the distance traveled and therefore underestimating the speed.  So, they increase the distance by about 7%, or basically multiplying the distance times 1.07.  Is that what IonEarth is doing?  Back to the calculator!  Let's see if the speed calculations are consistently high by some percentage.

So, the tracker says he traveled at 8.4 mph from 10:20 to 10:30.  Based on the straight-line distance he traveled at 8.1 mph.  In other words, the tracker says he traveled about 4% faster than my calculations.  From 10:10 to 10:30 he traveled 1.4 miles.  The tracker says he was traveling 7.7 mph, and by my calculation he was traveling 8.4 mph.  Whoa!  That's off in the other direction, so clearly they're not weighting.

So, so far it's not really clear where the speed calculations are coming from, by just looking at the data being provided to us.  However, my best guess at this moment would be that the GPS is actually taking location readings more often and using those to calculate speed, but the only locations they're displaying on the map are 10 minutes apart.  One of the primary issues here is preserving the battery, and I think it would almost certainly use less power to calculate the speed on the GPS device than it would to uplink the additional data.  If this is what's going on it's another example of excellent hardware engineering on the part of IonEarth.

No comments:

Post a Comment