I have just posted a new version of GPS Speedreader at ecwindfest.org/GPS/GPSSpeedreader.html. Since this version adds a feature specifically for dual GPS units, like the ESP/e-ink loggers I mentioned in my last post, I changed the version to 2.0. This version also has a few additional new features, including support for the FIT file format, which is used my many GPS watches. In this post, I'll explain some of the new features, and give examples where they help to improve the accuracy of GPS speeds.
"Intelligent Averages" for dual GPS units
When a speedsurfer in Belgium developed a cheap DIY GPS unit with an e-ink display that can be mounted on both sides of a boom, making it easy to check the current speed when windsurfing, my friend Mike from the GPS Team Challenge suggested to calculate speeds as averages of the two GPS units. In theory, the average of two separate measurements should be more accurate than a single measurement. We discussed a few ideas about how to calculate the averages, and came up with "intelligent averages". Let's first look at some speed data from a recent foiling session:
But that's not always the case. Here is another example from a top-10 second run from a different session:
Here, the green speed track shows a couple of pronounced spikes. The little inset shows the speeds and error estimates for the first spike. For the two points where the green speed is about 1.5 knots higher than the red speed, the error estimates are roughly 50% higher for the green data. Since one of the two tracks is clearly more accurate than the other, it does not make sense to calculate a plain average - instead, GPS Speedreader uses the only speed of the more accurate data. That's the "intelligent" part of the "intelligent average" (the blue lines). Not really hard, so maybe "not dumb" would be a more accurate description, but "intelligent" sounds better.
In the example above, there was a reason why the green GPS had worse data than the red: the green GPS was using only 2 satellite systems (GPS + GLONASS), while the red GPS unit used 3 satellite systems (GPS + GLONASS + Galileo). In the region shown, the additional 5-6 satellites from the Galileo system helped the GPS to be more accurate.
The effect of the artifact in the picture above was small, between 0.1 and 0.2 knots over 10 seconds. But sometimes, we can see much larger differences between two boom-mounted GPS units:
This section is from a crash, where the boom side that the red GPS was on ended up under water, and the boom side with the green GPS stayed above water. Under water, the red GPS lost track of most of the satellites, at times only being down to just 3 or 4 satellites. In contrast, the green GPS stayed above water the entire time, and kept tracking 16-17 satellites. The green GPS correctly reported that my speed dropped from 15 knots to almost 0 in less than a second - but the red GPS kept reporting speeds around 15 knots, eventually even increasing to 27 knots. Very interesting, considering both GPS units were attached to the same boom!
This is very typical behavior for u-blox GPS units in windsurfing crashes. Keep in mind that GPS chips were developed for cars, not for speedsurfing. Cars very rarely end up under water, and when they do, GPS accuracy will be the last thing the driver worries about. But cars often drive under bridges or through tunnels, where they loose GPS reception for a short time. In these situations, the "dead reckoning" behavior that the GPS chip shows is perfectly reasonable - most likely, the car will keep going at about the same speed.
But in windsurfing crashes where the GPS ends up under water, things are different, and GPS chips that "fantasize" about steady or increasing speeds can be a problem. If you look closely at the data in this example, you can see that the error estimates rose quite slowly after the crash - it took almost 8 seconds before the +/- estimates reached 4 knots. An error estimate of 4 knots happens to be the default value for speed accuracy filters in older versions of GPS Speedreader, since this threshold makes sense for Locosys GPS units like the GW-60 watch. But for u-blox based GPS units, it it much too high, as this example shows (and I have seen examples where crashes led to incorrect GPSTC postings, and at least one false personal best).
In GPS Speedreader version 2, this problem is addressed by using different accuracy filter thresholds for u-blox based data. For typical u-blox data (5 Hz or higher), the accuracy threshold has been reduced from 4.0 to 1.2 knots. In the example above, this filters out the speeds in cells with a red background (the blue line is where the error estimates exceeds the old threshold of 4.0). The file format is used to determine which threshold should be used - .ubx and .aoa files use the u-blox threshold, other file formats use the higher (Locosys) threshold.
While it is uncommon for "dead reckoning artifacts" after crashes to lead to errors in top speeds, these artifacts can often distort the total distance for a session. The use of dual boom units and the "intelligent averages" practically eliminates this problem, since at least one of the two units will typically keep good satellite reception, and therefore report accurate speeds.
