Sorted Speeds and Jibe Analysis

 I just release a new version of GPS Speedreader which has a couple of new tools to analyze sessions: turn analysis and sorted speed graphs. This post gives a few examples of how to use these functions. 

Let's start with the sorted speed graph - here is an example:

The y axis shows speed (in knots). The vertical lines correspond to 10%, 20%, 30%, and so on. So in this example, my speed was below 10 knots for about 80% of the time, and above 10 knots only 20% of the time. In other words, I spend most of my time slogging and waiting for wind. That's also obvious in the colored tracks and the speed graph for this session:

One of those days where the wind started out marginal and then dropped ... but it was fun in the gusts.

The sorted speed graph is quite useful to compare two sessions or parts of sessions. Here is an example:

This is from 1-hour periods from Lake George in February. The red line is from Kato, who set a 29.4 knot hour personal best (PB) on February 7th. The blue line is from my 25.9 knot hour PB on February 20.  Kato sails in a different league, and his hour is one of the fastest hours ever windsurfed (currently ranked #8 on the GPS Team Challenge rankings). So what does the graph tell us about why he was 3.5 knots faster?

His top speed in the session was only 1.5 knots faster than my top speed, so better top speed is not the main reason. If we go towards the left side of the graph, the difference get larger. In the middle, which shows our medium speed, Kato was about 3 knots faster. But the biggest differences are in the slowest 20 percent, on the left side of the graph. Kato spent only about 10 percent of his time getting up to speed (26 knots of more); in contrast, I spent about 20 percent of my time accelerating. To some extend, this is because I jibed more often: 30 times, compared to Kato's 23 times. But this is just a smaller part of the difference; the bigger part was that Kato's jibes were better, and that he accelerated faster after the jibes. I know that I am often am a bit slow getting back up to speed in jibes; I remember a set of slalom races in Hatteras where I had better straight line speed than the two guys who placed in front of me, but at every jibe mark, I'd see them pull away. So that's something I would need to work on to improve my hour. 

But why was Kato's speed in the main section of the graph higher than mine? The obvious answer is that he has mad skills, while my skills are more mediocre, but that does not give hints on how to improve. But since I happened to sail at the same spot when Kato did his hour, we can compare sail sizes: I was on 6.2, and Kato on 6.6 - basically a sail size larger. I remember this day very clearly, since it was the first (and only) time I sailed faster than 40 knots (41.4 knots/2 seconds). Obviously, I was well powered on my 6.2! But Kato, whom I remember as being a bit lighter than I am, was on a bigger sail, which allowed him to sail and accelerate faster. So a concrete goal towards improving my long distance speed numbers is to get more comfortable with larger sail sizes. That is something that I have done over recent years, at least on flat water, but there clearly is room for further improvements.

Now let's get back to the jibes. The new version of GPS Speedreader has a "Turn analysis" function that lets us take a closer look at jibes and tacks in a session. Here are my jibes during my 1 hour PB (as always, click on the image for a larger version):

For comparison, here are Kato's jibes:

To analyze jibes (and tacks), Speedreader looks for the center of a turn, and then examines the 50 meters before and after the turn. The first number to look at is the "Min. speed" column, which shows the minimum speed for the entire jibe. We both messed up one jibe, which shows up with a minimum speed below 1 knot. All my other jibes were above 5 knots, and in about half of my jibes, I maintained a speed of about 10 knots. But Kato kept a minimum speed of more than 11 knots in all of his dry jibes! In his best jibe, he was almost 5 knots faster than I was in my best jibe. So again, there is a lot of room for improvement for me! (To be picky: my GPS data were recorded at 5 Hz, while Kato's data were recorded at 1 Hz, which results in about 1 knot higher minimum speeds; the difference may even be a bit larger due to filtering in the GT31 he used. But even after taking this into account, his jibes were a lot better than mine. Also note that the jibe analysis methods work better with 5 Hz or 10 Hz data, and the program missed 3 of Kato's jibes - but those were just as good as the rest).

One difference between Kato's and my jibes shown in the tables above is the width. Most of my jibes were about 50-60 meters wide, while many of Kato's jibes were 70 or more meters wide. Looking at the tracks, Kato usually went slightly downwind for a bit longer before the jibe than I did; this is reflected in the higher entry speeds. But he also consistently kept at least 40% of his entry speed through the entire jibe, which I managed to do only in my best jibes. It looks like I have to go back to Oz for more jibe practice on flat water!

One of the reasons I added jibe analysis to GPS Speedreader is that I'd like to track my progress on wing jibes using GPS data. Learning wing jibes has been surprisingly hard for me, and I still have a lot to learn. So I'll show the jibe results from my lovely wife instead, who has been nailing wing jibes for a few years already:

If you compare the "% speed kept" column to the numbers for Kato's fin jibes, you can see she kept more than 70% of speed while wingfoiling, whereas most fin numbers are in below 50%. Keeping speed with the "motor off" is much easier when foiling than when windsurfing!

There are a couple of things to keep in mind when looking at the turn analysis in GPS Speedreader. First, keep in mind that turn analysis is new, and will sometimes give wrong results. A jibe may be characterized as a tack, or vice versa; may be missed by Speedreader; or what not really be a jibe or tack. Low frequency and less accurate (e.g. watch) GPS data are expected to have more problems, but some errors will also occur with accurate 5 or 10 Hz data. Hopefully, this will get better in future version, as the algorithms get refined with more data. 

Turn analysis requires that the wind direction is accurate. While Speedreader can often deduct the correct wind direction from the GPS data, this can be quite hard with some foil data. For example, if you always tack, foil through the tacks, and never jibe, it's likely that GPS Speedreader will have the wind direction wrong by 180 degrees. At other times, the error may be 90 degrees, or just a few degrees. For turn analysis, it's always a good idea to check the wind direction in the polar plot, and adjust it by hand if necessary.

GPS Speedreader 2

 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:

The two GPS units mounted on each side of the boom gave nearly identical speeds for the vast majority of points. There were some ups and downs, but they were well synchronized between the units, which indicates that they were probably real changes in speed. Sometimes, these speed changes may be due to boom movements - pumping, for example, is easy to spot. In the graph above, the little spike as the speed drops is due to moving the rig during a tack. When data look like in the graph above, speed averages will be very similar between the two units, and the averages will also be very close.

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.

GPS Tracks in Google Earth

One of the features in GPS Speedreader I like is the ability to export GPS tracks to Google Earth to create pretty "crayon artwork", as Fangy call the images. Here's an example:

There are a few options to customize what you see:

For example, you can set a minimum speed, so that parts where you were going slow are all shown in the same color. A variety of different color schemes are also available. Here's the "high contrast" colors for the same track:

For the lower graph, I had selected the "Include time stamps and speeds" checkbox in the export options. This enables the time line in Google Earth, so you can "play" your tracks. It also write the doppler speed data to the exported file, which you can see as a graph at the bottom of the image (to see the graph, you have to right-click on the "Speed graphs" item in the side bar, and select "Show elevation profile"; then you'll have to click on the "Doppler speeds" in the graph panel). The speed graph also reacts to moving the mouse over it by showing an arrow with the speeds in the image above. You can also select regions in the graph to get average speeds for the region. Go ahead and play with it - downloads are free at https://ecwindfest.org/GPS/GPSSpeedreader.html.

Another new feature in the just-released version 1.2.8 is support for .sbn files from Locosys GT-31 GPS devices.

GPS Speedreader

In recent years, I had gotten a bit frustrated with the existing GPS analysis software. For some of the GPS prototype testing, there were too many bugs that just made the life hard. Furthermore, the "older" software that was developed almost 20 years ago can be painfully slow when looking at new, higher-rate GPS data from the Locosys GW60 or the Motion GPS.

So I wrote my own, and I'm releasing it to the public today. It's free software, supplied without any warranties - but if you want to send me "beer money" to support the further development, that's great! There's a donation button on the  GPS Speedreader Help page for that. 

This post will show a few screen shots, and point out a few useful functions in GPS Speedreader. Here's the main window:

The session shown is my recent 12-hour, 306 km session where Nina grabbed the #1 spot in the GPSTC women's ranking for distance. It's a large file, and trying to see the 1-hour results in GPS Results on my Windows computer took more than 5 minutes. In GPS Speedreader, the file opens in less than half a minute, which includes calculating the results for all GPS Team Challenge categories.

The main window is divided in a left side that shows the GPS points on the top, and the category results on the bottom. The right side can show up to three graphs: tracks on top, doppler speeds in the middle, and error estimates on the bottom. Clicking anywhere will select the point or region; here, I have selected the top 2-second speed. You can zoom in using the mouse scroll wheel or trackpad gestures:

There are a few different dialogs where you can choose what you see, what your time zone is, and so on. Here are the general preferences:

GPS Speedreader was developed specifically with the GPS Team Challenge in mind, and with a lot of feedback from GPSTC advisors. It's pretty easy to post session results to the GPSTC - just select "View results in browser" from the "File" menu. This will open up a browser page with the results:

At the bottom of the results, there's a button. Click on it, and a session page on GPSTC will open, with all the numbers filled in for you. You just have to add a comment and press the "Post" button. 

GPS Speedreader does not have all the functions that other programs have. For example, background images are not supported, and there is no "Jibe analysis" like in GPS Action Replay Pro. I will probably add some more features over time, based on feedback on the Seabreeze GPS forum. But with summer starting here, I'll hopefully spend more time on the water soon!

A couple of things are unique to GPS Speedreader, though, and deserve mentioning. One is the "Compare files" function which I wrote to make comparing different GPS units easy. You can open two (or more) GPS files from the same session, and Speedreader will compare the results in all GPSTC categories. It will even compare the error ranges, and flag any discrepancies with a yellow, red, or orange background. If you want to have a close look at the data, you can pick which columns are shown in the data table:

But that may be more for geeks. Perhaps a thing that's more useful for many is that Speedreader supports opening files by drag and drop. On Mac and Windows, you can drop GPS files onto the application icon; on Mac, Windows, and Linux, you can drop files onto the main window.

To read more about GPS Speedreader, check the online help at https://ecwindfest.org/GPS/GPSSpeedreaderHelp.html. To download the program and start playing with it, visit https://ecwindfest.org/GPS/GPSSpeedreader.html.

Hour Analysis for GPSTC

When playing around with GPS prototypes, I developed my own analysis software to get around limitations and bugs of commonly used programs like GPS Action Replay (GPSAR; version 5.28) and GPSResults (version 6.170). Eventually, I shared my software ("GPS Speedreader") with a few similar-minded folks, so the question came up if Speedreader is accurate enough for posting to the GPS Team Challenge (GPSTC).

That lead to a validation study where I compared the results from more than 50 GPS files, most of them random downloads from ka72.com. This lead to a few interesting observations which might be of interest to anyone who posts sessions to GPSTC. Especially for the "1 hour" category, I discovered a few surprising things.

One of the tracks that stood out was the one you can download from https://www.ka72.com/Track/t/381385

Here's what the speed track looks like if you open it in GPSResults:

The first surprise was that the number GPSResults gave for one hour was lower than the 9.082 knots that ka72.com reported - only 8.466 knots! I checked in GPSAR, and it also reported 8.47 knots. Then I remembered that GPSResults used a minimum speed filter of 5 knots by default. When I disabled it by setting it to 0 knots, GPSResults reported a 1-hour speed of 9.015 knots - much closer to ka72.com. So the first big surprise was:

GPS Action Replay uses a 5 knot minimum speed filter for 1 hour!

I have always used GPSAR for analyzing my files, and never realized that. Even worse, unlike GPSResults, GPSAR does not let you disable the minimum speed setting.

There are different views of the 5-knot minimum filter in speedsurfing. When the older analysis programs were originally written almost 2 decades ago, the GPS Team Challenge did not yet exist. Speedsurfing was about top speed, 5x10 second averages, and 500 meters speed. Results for longer distances, longer times, and total distances were perhaps calculated, but mostly ignored. Furthermore, the GPS units available back then were quite prone to report speeds of 1-2 knots even when stationary. In this context, a 5-knot minimum speed filter makes sense.

But things have changed since then. Some clever Australians developed the GPS Team Challenge to get some team competition going. Having only the established disciplines 2 second, 5x10 seconds, and 500 meter disciplines would have given teams with spots like Sandy Point an unfair advantage, so they added disciplines that are better suited for other spots to even things out: alpha 500; the nautical mile (speed over 1852 meters); one hour average speed; and total distance. To win the monthly or yearly ranking, teams must post good results from all disciplines, since the overall score is computed from the ranking in each category. With 6 quite different categories and a requirement for posts from 2 sailors before it counts, it really takes a team to do well!

Besides the increased emphasis on total distance and long-distance speed on the GPSTC, another change happened over time: GPS units became more accurate. Modern GPS units like the Motion GPS rarely report speeds above 0.1 knots when stationary. Taken together, this makes a 5-knot minimum speed filter a very questionable thing indeed. A good one-hour results is above 20 knots, so it requires sailing about 40 kilometers. At most sailing areas, this requires about 20-40 jibes - sometimes even more. Sure, some of the best speedsailors in great conditions can plane through 40 jibes in a row and sail without crashing for an hour, but most of the time, one-hour runs will include jibes where we loose most speed, or periods of slogging in lulls. Why on earth should those times not count to the 1-hour average? In the example above, the slogging time was not very long, but still, including speeds below 5 knots increased the 1-hour average by more than 0.5 knots.

My conclusion from this is that I will not use GPSAR again for posting to GPSTC if there is even the slightest chance that my distance numbers matter for the monthly rankings.

But the story does not end here. In the track above, my Speedreader gave an even higher number. It selected a slightly different region, which upon close inspection made more sense. So the suspicion arose that there might be undiscovered bugs in the old code for 1-hour speed calculations. When I looked at more files, I found several examples that supported this conclusion, and even provided hints about why the older algorithms sometimes fail.

For an example, let's look at Boz' track from May 15, 2017 (downloadable at https://www.ka72.com/Track/t/305912). Here's the region GPSResults picked for the best hour:

Boz had his GPS set to a minimum speed of 5 knots, so a lot of points where the speed was lower are missing from the track. The reported 1-hour speed is 8.372 knots, corresponding to a travel distance of 15.5 km. But GPS Speedreader gave a higher speed:

By selecting an hour about 10 minutes further back, Speedreader found a region with a travel distance of 17.3 km - about one nautical mile longer! Accordingly, the 1-hour speed is about one knot higher.

Theoretically, this could be some kind of bug in Speedreader, so let's look at this region in GPSAR. First, here is what GPSAR selected as the fastest 1 hour:

 This is the roughly the same region that GPSResults picked. But is that really the region where we travel the most distance in one hour? Let's look at the track points table in GPSAR for the first valid point in the region Speedreader picked:

And for the last point:

The difference in accumulated distance is about 17.7 km, traveled in less than one hour. So this region should have been picked for the best hour in GPSAR, too!

So why did GPSResults and GPSAR (and, most likely, ka72.com) pick the wrong regions? Simple answer - because the 1-hour algorithms were never designed for tracks with a large number of missing points. The typical search algorithm will start at every valid point, find the point one hour after it, and calculate the speed for this region. But look at the graph from Speedreader: the best hour starts in the middle of the missing points! So the programs never even consider that an hour could start there. They can handle missing regions at the end of a one-hour run, but not at the start!

So why does Speedreader find this region? Mostly by luck! Speedreader was designed originally for comparing two GPS files. But if files sometimes miss some points, that can make the comparison complicated, so Speedreader simply fills in missing areas with points of speed 0. That allows it to consider every "missing point" in large missing regions as a possible start, and therefore succeeds in finding the best hour in this example.

There are other ways to also find the best hour, without having to add the interpolated point. Perhaps the easiest is to also look for hours going backwards - from every valid end point, calculate the average 1 hour speed towards the front of the file. This would find the best one hour in this example.

But at least until other GPS analysis software has incorporated such a fix, the best thing to do it to set the minimum logging speed to zero. All the examples of incorrect 1-hour results I have found were from files with a non-zero logging speed. Note that a minimum speed above zero can also affect the nautical mile or alpha results: if those happen to have a point with a speed below the threshold, the run may not be counted due to the missing point.