Interference and Data Overload

I have been testing a few GPS prototypes with u-blox 8 chips, which promise better accuracy than the "gold standard" Locosys GW-60 watch. Most of the recent tests were with prototypes that had bluetooth transmitters and/or Openlog data recorders.

Generally, the data from the ublox 8 chips were excellent, but in several tests, I noticed some glitches that seemed to be linked to bluetooth. So I made a new prototype that only records to an Openlog recorder, without any bluetooth connection, and compared it to an older prototype with Openlog where I can connect and disconnect the bluetooth chip. Here's a picture that shows the results:

The top graph shows speed, the lower graph shows the speed accuracy estimate. In about the first half of this test (the left side of the graph), the bluetooth transmitter was disconnected. In the second half, the bluetooth transmitter was connected. This was a stationary test, so the speed should always be zero. For the first half, it was close - usually about 0.02 knots, with a maximum around 0.2 knots. But with the bluetooth receiver turned on, there were frequent spikes of 0.5-1 knot. Usually, the spikes were short, and separated by one or more seconds; but the maximum 2-second speed was above 0.5 knots, which is too high.
In this example, I had not bothered to turn on the GPSLogger program, which means that the bluetooth transmitter was frequency hopping, and using about 2 to 4 times more power than when connected to a phone. In previous tests, I had seen some indications that this increases noise even more; but in a separate test today, I could not reproduce this, the noise level was quite high even when the transmitter was connected.

For anyone who likes to see numbers, here are some statistics for the data above - first for the region with bluetooth off:

All speed numbers are in knots. Both GPS units had very similar results. That changed when Bluetooth was turned on:

The first GPS was the Openlog-only, the second GPS had the bluetooth transmitter and was about a foot away. Turning bluetooth on lead to artifacts from RF interference in both units, but the effects where a bit larger in the unit that had the transceiver. One average, this unit also tracked one less satellite; the RF interference must have reduced the signal-to-noise ratio for the weakest satellite so that it was discarded.

In this test, the effect from bluetooth interference may have unusually large, and it may also be possible to reduce the effect with additional RF shielding or different component layouts. However, I find the Openlog setup more convenient, anyway, and it seems to avoid the interference issue completely, so I'll focus on these prototypes for the time being.

Some readers may have noticed the lines in the accuracy graph that drop to the bottom. These are caused by missing data points, which deserved a bit of investigation. The Openlog recorder has only a 512 byte communication buffer, and records to a micro SD card. This can lead to data loss if the writing of the data cannot keep up with the amount of incoming data. In the tests above, the ublox GPS was sending out data about the basic solution (NAV-PVT) and about the satellites it tracked (NAV-SVINFO) five times per second. The satellite information is not used when calculating speed numbers (except for the number of satellites used, which is available in NAV-PVT). But with about 20 satellites being tracked, logging SVINFO can increase the data amount by a factor of 4. Indeed, changing the configuration to not log SVINFO fixed the problem; so did recording SVINFO just once a second instead of 5 times per second. Theoretically, it is also possible to change the firmware in the Openlog recorder to a version that is better suited to high-rate data logging, but that does not seem to be necessary.

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:

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!

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.