Foil Jibes, Big Feet, and Forgetfulness

Back in February, I posted about a foil session where I had tons of good foil jibes, thanks to help from Andy Brandt. I should have known that would not last! After all, Andy also taught me how to plane through windsurf jibes ... and then, I had to take another dozen ABK camps where he had to jog my memory how to jibe properly. He was usually able to fix my problems within an hour. But in the weeks and months after a camp, I'd start forgetting, and went back to practicing bad old habits instead.

Windsurfers have to be optimists, so I hoped that this would not repeat itself with foil jibing. But whenever I tried to jibe back home on Cape Cod, a typical result would look like this:

Well, perhaps not always this flashy, but usually wet. Which is a real bummer, since I got that faster foil which really calls for using big cambered sails - sails that I really do not want to waterstart or uphaul all the time!

I was coming close to resigning myself to a lifetime of foil tacks when my endless hours browsing windsurf and windfoil forums paid off. A fellow foiler whom I had met in Corpus Christi posted a picture on Seabreeze that illustrated what had helped him to foil through jibes. The key was to have both feet pointing forward, towards the nose of the board. So a couple of foil sessions ago, when my initial foil attempts had resulted in the usual crashes, I tried his tip. Immediately, my jibes remained dry! They may still have been ugly as hell, with lots of wobbling, but at least I was not falling anymore!

A look at the GoPro footage from the session reveals that the differences in foot orientation were much smaller than I thought. Here's how my feet were placed in the initial crashed jibes:

Note that the back foot is almost perpendicular to the long axis of the board.

For comparison, here's a screen shot from a later (dry) jibe where I tried to have the toes pointing forward:

The difference in foot orientation is much smaller than I thought - maybe a 20 degree difference for both front and back foot. The feet are also closer together in the long direction of the board, as can be seen by looking at the distance from the front heel and the back toes to the black line on the board. This means that smaller steps are required during the foot change. Together, these changes made the "dry rate" in the jibes go from 20% to more than 80%. So far, so good!

Thursday was another great day to work on foil jibes at Kalmus. Just check out the wind graph:

Some Kalmus windsurfers may want to point out that northerly directions are not so great at Kalmus, and use the lulls of 5 mph and gusts up to 25 mph as "proof". But then, neither would they go out in the 10-13 mph averages that we had at the beginning of the session! But northerly wind directions are offshore at Kalmus, meaning the water is very flat. Just perfect for jibe practice! You don't need to be an expert to enjoy the conditions, either - Joanie, who is still a foil beginner, had some very nice long foil rides today with her 5.4 m sail. 

My only goal for today's session was to focus on the foot work in jibes - the initial setup with feet pointing forward, and a smooth(-ish) foot switch. I jibed 15 times in the 2 hour session today. 14 of those jibes were dry, which I am quite happy with. Some where nicer than others; today's GoPro footage was quite useful to get hints about what might cause the problems, and what to try to fix them.

In a few of the uglier jibes, the sail flip felt very unbalanced, and I often had to grab the mast instead of going boom-to-boom. Here's an example screen shot:

That sail has gotten away from me, forcing me to bend over. But why? A look at the board gives a hint: the leeside edge of the board is in the water. That means that the board is carving in the wrong direction! That's clearly visible in the GPS data for this jibe:

During the sail flip, the board turns back by about 15 degrees within one second. That does not really help to complete the jibe! But worse, it puts the sail in a pretty bad position - it's pretty much flagging out to the front of the board. No wonder something felt off!

To understand why this happened, we can look back a bit further in the video:

Check the placement of the old front foot as it is stepping back. The entire foot is on the wrong side of the center line - the lee side. As soon as I lift the old back foot to step forward, this will reverse the carving direction of the board! 

For comparison, here is the foot position at the same point in one of the better jibes of the day:

The new back foot stepped about a couple of inches closer to the old back foot, which makes it straddle the centerline of the board. With weight on the heel of the new back foot, the board will keep turning the right way even as I step forward with the old back foot. Indeed, the GPS tracks for this jibe show that the board kept carving about 10 degrees, from 148 degrees to the wind to 138 degrees. That's 25 degrees better, just because the foot placement is a couple of inches different! With the board continuing to turn the right way, the sail flip on this jibe was easy:

Maybe the jibe was not perfect, but I was able to keep the speed above 7 knots, which let me get right back onto the foil after the sail flip - good enough for me!

So the question arises: how can I make sure that the front foot steps back to exactly the right place? One possible solution would be to put the older carving foot further to the outside of the board, so that there is more space for that big front foot as it steps back. But when I tried this in the past, a new problem occurred: when lifting the old front foot to step back, the board tilted a lot, which often resulted in a crash. That sometimes made for great screen shots, where it look like I'm trying rail rides with a foil - but it did not make for dry jibes. In other tries, I would feel the board starting to tilt when the old front foot started to move, and I'd cut the step short to prevent the board from tilting. That, however, would leave it on the wrong side of the board again! So while the tip to "move the carving foot all the way to the outside" may work for some foilers, it does not work for me.

But let's have another look at the last picture above, where the sail flip worked well enough. You can see that both of my feet are in front of the foot pads - in other words, too far forward. That means that the board will go down and touch the water, and won't start flying again until I moved both feet back again. For the goal of fully foiled jibes without water contact, that's not good enough. It is, however, very typical for my "good" jibes: even in my session in Corpus Christi, where I almost foiled cleanly through many jibes, the board would often touch touch briefly just after the sail flip (or, in sail first jibes, the foot switch).

So I really have two problems, let's call them "wrong side" and "too far forward". My lovely wife never experienced these problems, and I think that's simply because her feet are a lot smaller, so it's much easier to find space on the board. Unfortunately, blaming my big feet does not really help. What might help, however, is stepping heel-to-heel, making sure I feel the foot that moves back actually touch the heel of the old back foot. That would place the back foot a bit further back, and the heel on the correct (windward) side of the centerline. If we now assume a constant size for the step forward, the front foot should also end up a bit further back. That would be progress.

But one of the things that I glossed over somewhat was that in the initial setup, I move the feet closer to each other in relation to the long axis of the board: the back foot goes forward a bit, and the front foot goes back a bit. That allows for smaller front-to-back steps during the foot switch, which in turn leads to a steadier flight. To "undo" this, it may be necessary to modify the foot placement during the switch: the old front foot steps behind the old back foot (but still heel to heel). That should make it easier to keep the old back foot from stepping too far forward, and it also should give the foil a little push up to get flying again, or to keep flying. I can't wait to get back onto the water to try!

New foils

I's been windy lately - we've been on the water 7 days in a row at the end of June. Perhaps my definition of "windy" has changed a bit since we started foiling, considering that I was on the foil most of the time, and on the slapper only 2 days, plus part of a couple more days. On the days with better forecasts, there were quite a few people at Kalmus. On some of the very hot afternoons, though, the windsurfers often spend their time re-rigging or waiting for more wind, which often showed up late in the afternoon. On the foil, it did not matter much if the wind was 15 or 25 miles per hour - once we made it out, we usually had plenty of fun. 

As long as the wind comes from SW or WSW, flat water is never far away. On one of the windier days, I even managed to get an Egg Island session on the slapper in, together with Jon. I just love going into a jibe  on flat water at full speed:

But whereas most of my turns on the slapper are jibes, I usually tack on the foil. Here's an example in the flat water on the other side of Kalmus, at the Kennedy Slicks:

On the way to and from the slicks, there is usually some fun chop to play with. That's just an incredible amount of fun, even on the big Slingshot Infinity 84 foil:

Here are the GPS tracks from this session:

After a couple of years on Slingshot foils, we wanted to check out new things. Nina had read a lot about higher aspect foils for winging, and Phil from Inland Sea was happy to let her try his Armstrong foil. He knew why! Nina at first had a bit of a hard time to get going, since the foil is quite a bit smaller than the i84 and i99 foils she had used so far. But once up on the foil, she absolutely loved it, so of course she bought one. It certainly did not hurt that the foil weighs less than half of the (significantly cheaper) Slingshot foils, and that the engineering seem much more solid - but the feeling when foiling was the main motivator. Whereas I make tiny little turns down the waves with some power in the sail, she can often be seen riding swell with the wing flagged out, and a big smile on her face, doing full bottom turns and then going back up the same wave - or perhaps the next, since we're talking about Kalmus, after all. Even though more speed was not a goal in this change, she has gotten quite a bit faster. In the past, I could usually pass her easily with my foil (partly because I need a lot more speed so the foil generates enough lift to push all my extra pounds above the water). But now, her speed matches mine, even when she's just winging along, and I try to catch her.

This, of course, created an untenable situation. I needed a faster foil! Never mind that other windfoilers have posted much faster speeds on the foils I have. I tried plenty of times, but for me, going significantly faster than 15 knots on my i84 was a really hard thing to do. My typical cruising speeds were closer to 12 knots. Surely, faster foils would fix the problem!

I got on the North Beach Windsurfing web site and started a chat with Karen and Britt, who not only know a lot more about fast foils, but also sell them. We exchanged some pictures of fuselages to figure out what would work, and I ended up buying a Starboard GT-R Plus foil with a 95+ fuselage, 85 cm mast, and 800 front wing. If arrived quickly, and after some more help from Britt over the phone, I was even able to put it together.

Of course, I had to try the new foil right away, so we went foiling even though the wind looked marginal. I rigged my 7.8 m freerace, 3-cam sail to have a chance to get going. I also put a cheap phone into a waterproof armband and had it announce my speed - after all, I was going to be on a fast foil!

I got the foil out of the water on my very first run. But after about 30 yards on the foil, there was a loud "bang", and I crashed. In less than 15 minutes, and after fewer than 100 attempts to pump up onto the foil without any success, I realized that something must be wrong, and turned the board over. Instead of pointing straight up, the mast of the foil now was tilted at a 30 degree angle. The back screw in the tuttle box had come out! Fortunately, the other screw had held (although I later noticed a pronounced S-turn in it when I disassembled the gear). Back to the beach (slowly!); to the car to get a new screw (a longer one that actually reached the barrel nut this time); and back onto the water. Ah, much better!

Being a rather cautious person with a strong aversion to high-speed catapults, I proceeded to investigate the low-speed potential of my new foil. I pumped a but harder than necessary on my i84, and when I heard "10" (knots) from my phone, I'd step on the tail to pop the foil out of the water. Up I went! And then, I plopped straight back down. I repeated this multiple times, before I finally realized that I needed a speed of about 13 knots before the foil would fly consistently. That actually makes sense - for my i84, I need about 8-9 knots, but the i84 is about 2.5 times larger, and has a much thicker profile. The bigger difference, though, is how to get the foils going. With the i84, I need just a bit of board speed before I step on the tail to pop up, and then accelerate once flying. With the GT-R+, I need to reach about 12 knots before going up. Which, actually, has one big advantage: I get a much better workout!

When powered, the foil made it quite clear that it wants to go fast. Whereas I have to work hard to push the i84 over 15 knots, the GT-R with the 800 front wing definitely wants to go faster. The phone often announced 16 or 17 knots, even though I was doing what I could to slow things down! For a slow learner like me, it will take a bit to get comfortable with higher speeds when foiling with an 85 cm mast in 90+ cm chop. Sure, the GT-R is not nearly as affected by the up-and-down motion that waves and chop create in the water, but it is still affected somewhat. 

For my 4th session on the GT-R, I finally got some flat water: offshore NE wind at Kalmus! It may have been a bit gusty, with meter readings between 8 and 28 mph, but between the lulls and big gusts, there was a range where it was just real fun to sail along. At least until the next big, fat gust hit, which would want to make the foil come out of the water - either because I tried to sheet out, which takes pressure of the nose, or simply because the foil started going faster, which generates more lift. Interestingly, the rhythm of this setup is very different from the i84 - partly because of the much longer fuselage. That makes the foil less nervous, but it also makes it a bit slower and harder to push the nose down when it wants to come up. I'll definitely need a few more practice sessions before I get used to this!

Despite my general efforts to keep things slow and controlled, I ended up finally going faster than 20 knots on a foil. My 2-second top speed was just below 20 knots, but that's still 2 knots faster than the top speed on the i84, which I got in very flat water (the Kennedy Slicks) on a day with stronger and more consistent wind. That felt just about as fast as doing 35 knots on a slalom board - and definitely faster than the 29 knots I had done a couple of days earlier at Egg Island on my freestyle board. Being a foot or two above the water, with the prospect of a full speed catapult if you let the foil rise just one more foot, must distort the perception! But should I ever get used to this feeling, the setup should be able to go at least 5 or 6 knots faster. And after that, there are smaller front and back wings for even more speed!

For the time being, though, I'll probably grab my Slingshot foil for many of my foil sessions. Slowly playing with chop and swell is plenty of fun, and the shorter 71 cm Slingshot mast works better for sessions near low tide. But it's great to have the option for a very different level of foiling fun!

Exploring Plug and Play GPS Options

 I have spent quite a bit of time exploring different options of "plug and play" GPS loggers, specifically for the GPS Team Challenge (GPSTC). This post is a summary of what I've learned so far about using several different loggers: the original Openlog; the Openlog Artemis from Sparkfun; the Adafruit Clue; and the M5Stack Basic.

1. Openlog and Beitian BN880

The two units on the left side of the picture above are my "old", GPSTC-approved prototypes that are based on Beitian GPS and Openlog chips. Here's a closer look at the lower one:

The Openlog is a little chip with an SD card that's widely used for logging GPS data from drones; it's on the right side in the image above. Openlogs are available for about $15 from Sparkfun, and about $5 on eBay (but beware - some of the cheap modules do not work as shipped!). I used it with a Beitian BN880 GPS chip (about $20 on Amazon) to create a prototype logger that has been approved for GPSTC postings. My prototype did not qualify as "plug and play", because it involved it required some soldering between the logger and the GPS chip, and to connect a battery (like the 400 mAh LiPo battery shown above) to power everything. Some of this soldering could be avoided by using a Sparkfun Openlog with headers, and a BN880 GPS chip that comes with cables. But you'd still need to connect everything to a battery, which would typically require soldering. 

A second issue with this approach is that you need to change the configuration of the GPS chip for GPSTC postings. By default, the GPS chips provide updates once per second (at 1 Hz), and in a text format (NMEA sentences). But the text format does not provide speed accuracy information that is required for GPSTC postings, and higher data rates give more accurate speeds. Therefore, the GPSTC requires that data are logged in a binary format (the UBX format in this case), and are recorded at 5 Hz or higher.

This is easy enough to change using the Windows program "U-center". But it requires hooking up the GPS chip to a computer using a serial-to-USB converter, which adds another level of complexity; and a bit of learning how to change the required settings in U-center.

If you know how to use a soldering iron, and don't mind spending a couple of hours to hook up everything and learn how to use U-center, this is a perfectly good option to create a GPS logger for about $50. But since soldering is required, it does not qualify as "plug and play".

2. Sparkfun Openlog Artemis and Sparkfun Quiic GPS 

A couple of newer products from Sparkfun offer a way to get around around the soldering requirement: the Openlog Artemis (OLA), and GPS chips that use the Quiic connector and a u-blox chip. In this setup, the logger and the GPS chip are connected using a cable. The OLA can be powered with a LiPo battery or a USB power pack, so no soldering is required. 

Bottom view of the OLA-M8 GPS, showing the OLA

Top view of the OLA-M8, showing the SAM-M8 GPS chip

 I have tested this setup with three different GPS chips: the SAM-M8Q ($40), the NEO-M9N with a chip antenna ($70), and the NEO-M9N with a U.FL connector ($65) and an external active antenna ($15). The chip antenna was to weak to give decent data, so I returned the chip right away, but the two other chips worked ok. For using the SAM-M8Q, I had to modify the OLA firmware, since the GNSS logging firmware from Sparkfun only supports the newer chips. However, installing new firmware on the OLA is very easy.

The one caveat with the OLA-Quiic GPS setup is that reliable communication requires a small change on the GPS chip: the "jumper" for the I2C communication needs to be scratched out. This is quite easy, takes just a minute or two, and there is a video tutorial on the Sparkfun site. Without this small modification, the data can be corrupted, which leads to lost data points due to checksum errors. 

The more expensive NEO-M9 GPS chips theoretically have several advantages over the older M8 GPS chips, which include the option to use 4 GNSS systems at the same time (vs. 3 for the M8), and faster data rates of up to 25 Hz. In reality, however, I discovered that the M9 chip reduces the maximum number of satellites used to 16 when logging at 10 Hz or above. This reduces the advantage of the extra GNSS system significantly, to a point where it is questionable that the data from the M9 chips is indeed "better" than data from M8 chips.

Compared to the first solution (Openlog and Beitian GPS), the OLA approach is significantly more expensive. If you include the cost for a battery (about $10), the total cost is about $100 with a M8 chip, and about $130 for the M9 chip. 

The green boards in the OLA setup are 4 cm x 8 cm, a size that fits into a waterproof housing for a GoPro 3 which is available for about $10 on Amazon, and can easily be attached to a windsurf helmet.

3. Adafruit Clue and Sparkfun Quiic GPS

While searching for other GPS chips that also use Sparkfun's Quiic cable system, I discovered the Adafruit Clue.  At $40, it's a bit cheaper than he Openlog Artemis. It does not have a built-in SD card for logging, but it does have a display that seems just large enough for reading speeds while windsurfing.  For initial tests, the Clue offers 2 MB of internal flash storage that can be used to store GPS data, but that's only enough for at most one hour at 5 Hz.

Another thing about the Clue that I found attractive is that it can be programmed using Python, a programming language that is much more modern (and popular) than the C / C++ language used for the OLA. After developing software in Java for the last couple of decades, going back to C / C++ is quite painful, so Adafruit's "CircuitPython" looked quite tempting.

The language change turned out not quite as easy as I had hoped. While there are plenty of things in Python that I love, I have gotten used to seeing any typing and syntax errors right away while I type, and to access the source code for any library classes with a single keystroke. That's not possible in Python, which assumes "if you type something I have not seen before, you probably mean it", and reveals errors much later, when the mistyped piece of code actually runs. Documentation is a very different thing, too. The first issue is that Python has changed a lot of time, so you often see "do this in Python < 3, but this in Python 3.0-3.5, and that in the newest versions". To this, we need to add that CircuitPython is a variation of MicroPython, which itself is a "dialect" of Python; and that error message you get during runtime are often quite misleading. All that means that little things that should have taken just 15 minutes often took many hours. But eventually, I had some Python scripts that received the data from the GPS, logged them, and showed speeds on he screen.

For windsurfing use, though, being able to log sessions longer than one hour is essential, and that's where things got difficult. Staying with the "plug and play" theme, I wanted to use a variation of the Openlog that has a Quiic connector, which is advertised as "the smarter and better looking cousin to the extremely popular OpenLog". Sounds fantastic! Well, I should have known better than to believe the marketing guys...

The first issue I encountered was that I2C communication, which the Quiic connectors use, is very different from serial communication. Think of serial communication as a TV that's alway on, blaring away in the background. The original Openlog is then a voice recorder that will record the noise from the TV as soon as it is turned on.

In contrast, I2C communication is more like Siri or Alexa: it will sit around, patiently waiting until you ask it a direct question. Without a direct question, it won't say a word - the "mute" button stays pressed. So instead of just connecting a few pins, the software on the Clue actually needs to tell the Quiic Openlog "now save these data, please".

That's not really hard, once you understand the difference, and I had the Quiic Openlog recording data from the GPS through the Adafruit Clue quickly. But reading these data was an entirely different issue: files always were a lot shorter than expected, and data were corrupted. A few hours of detective work traces the cause down to the firmware in the Quiic Openlog (QO). Whenever the QO got a "packet" of data, it would know the length of the data, but nevertheless determine the length of the data again, using the "good old" strlen function in C. Anyone who ever did a bit of programming in C know will know what the issue with logging binary data is: strlen searches for the first "0", which is used in C to mark the end of a string. But binary data often contain "0", which does not mean "end"! 

Fixing this in the QO firmware was a trivial thing, even for someone who has a strong dislike of C. But updating the firmware on the Quiic Openlog chip was a very different story, since that has to be done through a serial-to-USB converter connected to some holes on the QO. I still had one of those lying around, but all attempts to "burn" the firmware failed. Since I can be stubborn, I eventually succeeded, after soldering pins to the UART holes, and connecting the Quiic cable to supply power. After that, I was finally able to log GPS data to a file on the micro SD card.

But obviously, this is no longer a plug-and-play solution, so I looked for alternatives. The Adafruit Clue follows ideas from the micro:bit board, so theoretically, it allows making electric connections with screws. And windsurfers know how to screw, from plenty of training with fin, even before foils with their screw multitude became popular. 

In comes the gator:log: another version of the Openlog, this one with micro:bit-like holes. A quick look at the diagram seemed to indicate that the holes would like up, and a "Clue-gatorlog-screw" solution might be possible. Alas, that was too optimistic. In their wisdom, Adafruit decided that having vary the distance between the holes in the Clue, so that only 3 of the necessary 4 holes line up. Arrgghh! But it turned out that if you tweak things a bit, you can get everything screwed together. Here's a closer look:

Adafruit Clue - M9 - Gator:log

When I tested it, this setup worked .. mostly. About every 10-15 minutes, there would be a gap in the data, with 3-4 missing points (and that was after I fixed the code so that it would not just stop due to garbage collection issues - but that's a story for another time). Even worse, I sometimes got obscure errors in the I2C communication. It seems that the I2C bus sometimes requires pullup resistors to work well. The "sometimes" depends on factors like cable lengths, how the port on the chip is wired, and which other thingies are on the I2C bus. In the picture above, you may notice the black chip in the middle. That's an I2C switch, intended to turn off the GPS when not logging. But when I connected this switch, the I2C communication became really unreliable, to the point were it was definitely useless. Perhaps all this could be fixed by soldering in a couple of resistors - but that's not plug and play anymore.

After two close misses, it was time to look against something else. Ideally, something with a screen, an SD card slot, a battery, and USB and I2C cable connections. Surely, such a thing must already exist?

4. M5Stack

My countless hours of searching Amazon, Google, Sparkfun, and Adafruit for new gadgets seemed to come to fruition when I discovered the M5Stack: a 5 x 5 cm thingies with a powerful microprocessor, LED screen, SD card, I2C and USB cable connectors, and plenty of connection options - all for less than $40, and in little housing that almost looks like a Motion or GW-52 GPS. Too good to be true?

Perhaps. I certainly ran into quite a few problems. The first one was that the built-in battery did not work for more than a few minutes at first, and then gave up completely. Since the battery was very small, and one with 5x more capacity was available for less than $10, I ordered that one ... only to find out that it was not the battery, but rather the internal wiring that was broken. Bummer, but not a killer - everything works fine when hooking up a USB battery pack.

The only issue when hooking up USB was that the M5stack would issue a very annoying, high-pitched squeak. That's a known issue that M5 just never bothered to fix. Turning the amplifier down helped only a little, so I ended up simple removing the speaker.

The next issue was trying to get the Sparkfun I2C chips to work with the M5. In comparison, the Adafruit Clue was (a) easier and (b) better. Easier because the Python documentation for the M5stack is very poor (to phrase that as positively as I can ... don't ask me after I've had a few beers, or I will use very different words!). The Clue was better because I could at get hour-long and longer recordings that were mostly complete most of the time. With the M5stack, I'd get some communication between the GPS and the board sometimes. 

I had also ordered another "module" for the M5stack that promised to allow the use of USB peripherals. That would have been a very neat way to use a cheap M8-based USB GPS chip. Alas, once I got the module and spent a few hours looking for documentation, I realized that M5 provided absolutely no Python support for the module. Seems they are so busy coming up with multiple different versions in different sizes that they don't have time to provide decent software support (or even just organized documentation).

After quite a few frustrating hours, I finally remembered that I had some more Beitian BN880 GPS chips lying around, and matching cables that just might be useable with the pins that the M5stack has at the bottom. Finally, something worked! Here's a closeup:

No soldering, so it qualified as plug-and-play. Now, the lack of a working battery in the M5stack ended up not being a problem anymore, since I used a flat USB power pack and some velcro to put everything together (check the first picture in this post). 

I have tried the M5stack-BN880 and the OLA-M8 combo a few times on the water windsurfing and foiling, and the results were just as expected: very close to the results I get with my "approved" prototypes or Motion GPS units, all of which use very similar GPS chips. Here's a short section from a recent windsurfing session:

Speeds are very similar. The "noise" does not align well mostly because I had the Motion and the M5 on different arms, and the OLA on top of my helmet. When recording at 5 Hz or higher, we can actually see different movements of different body parts in the GPS tracks. The error estimates (lower panel) are slightly lower for the OLA-SAM M8, which reflects that the GPS on top of the helmet had the clearest view of the GPS satellites, without the signal distortions from head and body that the GPS units on the arms had. After several sessions with similar results, there is no doubt that the two "plug and play" GPS units based on the Openlog Artemis with the Sparkfun SAM-M8 GPS and the M5stack with the Beitian BN880 are suitable for competitions like the GPS Team Challenge, since the quality of the data they produce is at least comparable to the quality from other approved and currently commercially available units.

Measuring GPS Speed Accuracy

 How do you know how accurate your GPS is? This question once again came up when I started looking into a "plug and play" GPS. Unfortunately, there's no simple answer to this question, so there will be a few posts looking at different aspects.

In search of the answer, the first thing to try is to use two GPS units right next to each other, and compare their speeds. Here is an example where I compared two Motion GPS units in a driving test:

The speeds from one unit are drawn in red, the speeds from the other unit in blue. A lot of times, the speeds are so close that only one color is visible. Here's a zoom-in:

In the selected 10 second region (highlighted in yellow), the two GPS units gave almost identical speeds. For individual points, the speed differences were mostly below 0.1 knots; over the 10-second region, the average speeds were 13.482 and 13.486 knots. That's a rather small difference of 0.004 knots!

But the graph shows that this is not always the case. If we look at the region to the right, the observed differences get much larger:

Here, one GPS reports a 10-second average speed of 19.926 knots, while the other GPS reports 19.664 knots - a difference of 0.262 knots. In the context of a speed competition like the GPS Team Challenge, that's a pretty large difference. One interesting thing to note is that the speeds some times deviate significantly for more than a second; the dip in the red track in the picture above, for example, is about 3 seconds long. This is non-random error: in the 10 Hz data for the graph above, the "dip" extends over almost 30 points, which we'd expect to happen once every billion points by chance. We'll get back to this when we look at estimating the likely error of speed results.

The most straightforward way to compare different GPS units is to compare the results in different top speed categories. Here's a look at some of these, generated using the "Compare files" function in GPS Speedreader:

The table shows the speed results for the two devices, as well as the "two sigma" error estimates in the "+/-" column. The calculation of the result error estimates assumes that the errors are random, so that they would cancel each other out more and more when we look at more points: longer times or longer distances. This leads to higher error estimates for the 2 second results, roughly 2-fold lower estimates for the 10 second results, and very low estimates for the nautical mile (1852 m) and the 1 hour results. About 95 out of 100 times, we expect the "true" speed to be within the range defined by the +/- numbers. Most of the time, we expect the ranges of the two devices to overlap. Only about 1 in 10,000 results would be expect random errors to cause the results to be so different that the ranges do not overlap - which GPS Speedreader highlights by using a red background.

But the table shows that 5 of the 14 results are more different than expected. 5 out of 14, not one in ten thousand! There are three possible (and not mutually exclusive) explanations for this:

1. One (or both) of the GPS units is not working correctly.
2. The error in not random, so that the conclusions based on assuming random error are incorrect.
3. The single-point error estimates that the GPS gives are too optimistic.

Let's have one more look at the data, and this time, include a graph of the single-point error estimates:

We can see that the point error estimates in the regions where the curves diverge are larger, which is a good sign. But do they increase enough? And is the difference that we see due to one GPS being "wrong", or do both of them disagree, and the truth lies somewhere in the middle? To answer these questions, we need more data.

Fortunately, this was a driving test, so getting more data was easy: just put more GPS units on the dash board! So I added a few more: a couple of Locosys units (a GW-52 and a GW-60), a couple of u-blox prototypes that have been approved for use in the GPS Team challenge (a BN880 and a BN280, both Openlog-based), and my current u-blox Neo-M9/Openlog Artemis prototype. That makes a total of 7 GPS units: two with a Locosys Sirf-type GPS unit, and five with a u-blox based design. All units were set to log at 5 Hz for this drive. Here's an overview:

What is immediately apparent is that the error estimates differ a lot more than the speed estimates. In particular, the error estimates from the Locosys units, shown in purple and green, are much higher than the u-blox estimates, except when the car was stationary.

Here is a zoom-in picture:

Most of the GPS units are pretty close together for most of the time, but several units stick out a bit by showing larger and more frequent deviations. But just like in the first and second picture in this post, the details vary quite a bit between different sections of the drive.

So we're back at the question: how can we quantify the error of each of the units, using all the information in the tracks, instead of limiting us to just a few top speeds? 

Along the same lines, what can we learn about the point error estimates ("Speed Dilution of Precision", or SDoP, in Locosys parlance, and "speed accuracy", or sAcc, in u-blox parlance)?

I'll start looking at answers to these questions in my next post.