Sunday, May 27, 2018

Summer, Speed, and GPS Results

Friday was the first day where it felt like summer. I was perfectly warm in a short-sleeved 3 mm wetsuit, and the Kalmus parking lot saw crowds of windsurfers. The wind was not quite up to summer standards - it was steady at around 18-20 mph until 1 pm, and then went up and down like crazy. At times, the thermals kicked in, and we had 30 mph averages with higher gusts; a few minutes later, it decoupled and dropped to low teens. That happened several times, until it finally cooled of around 5 pm, and the wind was relatively steady .. and in the mid-30s. The Kalmus wind machine is back on!

The forecast for yesterday also held some promise, but the weaker wind did not hold to the surface once it warmed up around noon. Time for some longboard sailing - I explored the little bays close to Egg Island with Gonzalo, who gave me some pointers about longboard racing. Nice!

The summer then ended again today. Temperatures dropped into the 50s overnight, with no sun to warm things up. But we got a rare treat - strong easterly winds! I went to East Bay, and was fully powered on a 6.3 m race sail and the 99 l slalom board. For comparison: on freeride gear, I would have picked a 4.7 and still would have been fully powered! The Kalmus windmeter showed averages around 28 mph, and gusts in the mid-30s. I ended up with a top speed of 32.77 knots, which is a personal best for the spot and the board, and my 5th-fastest session ever. Cool!

I took the opportunity to test my bluetooth GPS prototype again. I had tested it on the water a few times during the last two days, and the results looked great - very close to the results from the "gold standard" GW-60 watch. Here's a graph that compares the 10 second speeds of the bluetooth prototype, my Raspberry Pi Zero prototype, and the GW-60:
Today's results also looked good, but there were a few "red flags" with larger deviations:
I wore two GW-60 watches, one on each arm. However, the differences between the two watches were larger than usual - what was going on? Let's look at the speed graphs in GPSResults:
The two GW-60 watches are on top, the bluetooth GPS is at the bottom. A bit tough to see anything here, but if you look closely at the middle image, you see some missing data points.

I find GPS Action Replay quite useful to have a really close look at data. Here's a movie that shows the aligned speed graphs (after editing out low-speed sections):

I stopped the movie several times when one of the GPS units deviated a lot from the others; usually, it was the red line, the second GW-60 GPS. This GPS simply stopped recording any data points for 50 seconds, and then kept dropping points for several minutes afterwards. Here's a graph from my own analysis software where this is immediately obvious:
The red region means trouble - let's zoom in:
Every time the red line goes from the top to the bottom, one or more data points are missing. The section with 50 seconds of missing data is near the left side of the curve. Because of the missing data, the numbers in the table above were "misaligned" - one top-10 result was missing for the second GW-60. If we take that into account, the numbers look a bit better:
One thing that also differs in this table is the last column. This time, I calculated the difference between the bluetooth GPS and the GW-60 GPS by using the average of the two GW-60 watches (except for the one missing point in each category, of course). I also added a row that shows the average deviation between the two GW-60s and between the bluetooth GPS and the GW-60 averages.
The bottom line is quite clear: the speed results for the bluetooth GPS are very close to the results from the two GW-60 watches. On average, the difference is less than 0.1 knots for 2 seconds; less than 0.05 knots for 10 seconds; and about 0.02 knots for 500 m. It is also well within the "+/-" ranges given by GPSResults (which range from ~0.06 knots for 500 m for the bluetooth GPS to  ~0.35 knots for 2 second data for the GW-60). Looking at the 500 m results in the first table, it is clear that the differences between the two GW-60 watches is larger than the difference between the bluetooth GPS and the first GW-60 watch (which appeared to give more accurate data in this test than the second watch, if judged by the problem areas seen in the movie above).

It's no surprise that the bluetooth GPS is at least as accurate as the GW-60 watch. It uses a GPS chip (the u-blox 8) which is known to be more accurate; this is at least partly due to its ability to use data from various satellite systems at the same time (GPS, GLONASS, and Galileo), while the GW-60 is limited to only satellites from the American GPS satellites. In the tests, the ublox chip was typically able to use 15-19 satellites, while the watch was able to use only 8-10 satellites. More is better!
However, it was still necessary to prove that the prototype does indeed give accurate data, since many things can go wrong, including bad GPS chips and degraded signals from RF interference. The windsurfing tests have consistently shown that the prototype works very well, and actually better than the GW-60 watch when it encounters problems like the one described above.

For those amongst you who love numbers, I'll end with the numbers for the first graph in this post, which includes the accuracy estimates:


Thursday, May 24, 2018

GPS Prototypes

Here's a short video that shows two GPS prototypes ready to be tested on the water:

The one on the left uses a Raspberry Pi Zero W, an e-paper display (similar to what a Kindle uses), and a Stratux GPYes USB GPS module. The one on the right is inside the GoPro case. It's a ublox-8 based GPS connected to a battery and a bluetooth module; the Android phone below it grabs the data over Bluetooth and logs them. Now the wind just has to play along for on-the-water tests tomorrow!

Saturday, May 19, 2018

Almost

Nina almost got a Flaka yesterday. She said that for the very first time, the board kept turning while she was sliding backwards. She probably finished the 360 degree rotation, and maybe even a bit more. But she did not realize she was done until afterwards, so she fell onto the sail. But still, that's big progress.

We sailed Lewis Bay in NE wind yesterday for the first time. In NE, we usually go to Duxbury, Chapin, or other spots, but the tide was too low yesterday morning for most of those, and the wind was predicted to drop early. Lewis Bay was a bit gusty, but otherwise quite nice. But there was a surprising amount of ferry and boat traffic.

I almost got to test my Raspberrry Pi Zero "plug and play" GPS while windsurfing for the first time yesterday. Here's what the setup looks like:
It's a Raspberry Pi Zero, a Stratux GPYes USB GPS dongle, a 2500 mAh USB battery pack, a USB cable, some vecro, a zip lock bag, and a waterproof back. The cost for the entire setup is about $50 - about 1/4th or 1/5th of a GW-60 GPS watch. I did wear this while windsurfing, but encountered one little problem: the battery had switched itself off! No test data this time, bummer.

I had noticed a few times before that the battery turned itself off, but was never quite able to figure out when that happens. When it happened before, I thought that I had forgotten to charge the battery, or that the battery was dying - but I was wrong. A little internet search yesterday showed that the "sleep" function is standard for USB battery packs. They are meant to charge phones, which usually happens at 0.5 amps or more. If the current drops below 0.1 A, they decide that the phone is sufficiently charged, and go to sleep. Lazy bastards!

I did a bit more testing with a USB tester today at home, and discovered why the sleep issue was so confusing. Using a variety of USB dongles and hub, I saw that the battery goes to sleep after about 30 seconds if the current is continuously below 0.1 A. It turns out that the Pi Zero uses just about 0.1 A when it's doing nothing. A USB GPS dongle needs about 20-40 mA, so when the dongle is plugged in, the current increases to about 0.13 A. Therefore, the battery always stays on when I test at home.

One of the things that needs current is WiFi. It's usually on when I'm at home, although the script that starts the logging turns if off when a GPS dongle is connected to extend the battery life; that drops the current by about 20-30 mA. When the dongle is pulled and the logging stops, the WiFi is automatically turned back on.

But what happens when WiFi is on, but no network is available (which is usually the case when windsurfing)? It turns out that not being connected to a network has about the same effect as turning WiFi off - the current drops to about 70 mA (with no GPS dongle connected). So that's what happened yesterday! I turned the Pi on before rigging, and connected the dongle about 15 minutes later ... without checking if the battery still was on. But the lazy thing had gone to sleep.

The little test failure just underscores that you can't see much when you're flying blind - the Pi GPS logger needs some kind of display. I've got a little 2.13 in e-paper hat that has exactly the same form factor as the Pi Zero, and got the demo programs to run. Getting it to work with the logger will require a bit of trickery, since there don't see to be any Java drivers for the display. For now, I'll probably go with some primitive form of inter-process communication between the logger and a Python or C program for the display, maybe through a file on a RAM disk. That's the easiest solution that comes to mind, and would make it quite easy to support other kinds of displays, too.