Wind Sacrifice

I am the wind sacrifice. I'm good at that! Check today's wind meter readings:

At 4:45 pm, I took the bus to Logan airport. The wind did not even wait for me to get there - it picked up to 25 mph less than 30 minutes later. Coincidence? I think not! The forecast was for 16-17 mph; actual reading were in the high 20s for a few hours.

The next couple of days will be windy, too. Tomorrow's forecast is 16 mph again. I may not go quite as high as today, because it's predicted to be more southerly, but who knows? For Thursday, the prediction is in the mid-20s, so we'll see 30s. Some showers and maybe thunderstorms, but there will probably be a few hours in the morning where it's dry and windy.

So go and get some! It may be all over a week from now when I return...

1000 Million Millions

A large number: 1,000,000,000,000,000. That's 1000 million times a million. Or 10 to the 15th (but that sounds smaller). Or 150 dB. Or a quadrillion.

That's (roughly) the difference in the energy level between a typical GPS signal (-150 dBm) and a bluetooth signal being sent out by a Raspberry Pi (0 dBm). WiFi transmissions are about 10 times stronger still.

For reference, let's look at hearing. The human ear has quite an amazing dynamic range - about 12 orders of magnitude, or a million times a million. The lowest level humans can hear is about 0 dB; the level where instant hearing damage is a real danger is 120 dB - that's the sound of a jet engine pretty close to you. The difference between a normal conversation (50 dB) and a really loud rock concert (100 dB) is much smaller.

So we can't really blame a GPS chip for picking up some "noise" if it's placed right next to a transmitter that screams 1000 million million times louder! Yes, bluetooth and WiFi are at a different frequency, but the difference is not huge: 1.575 GHz, compared to 2.4 GHz for bluetooth and WiFi. It's almost as if the GPS is listening to the baritone in an opera while the soprano is singing a quadrillion times louder. I'm amazed it can pick up anything!

Such great listening skills require a closer look:

This is a section from the "noisy" speeds in my recent post. The blue line is the "doppler speed", or more accurately the "speed over ground". The problem is that it cannot go below zero, so it does not fully reflect the variation in speed caused by the noise. For that, we should look at directional speed, the speed vectors. That's what the yellow and red lines are - "north velocity" and "east velocity". The directional speeds can have negative values, so they often vary more than the "speed over ground" - but not always. The up-and-down that can be seen in the first two high peaks is what's we would expect from purely random errors. When the directional speed stays high (or low) for multiple points in a row, that's a possible indication of systematic errors. One potential source of systematic errors is "multipath" noise, where the same signal reaches the GPS over different paths, which include reflections. Since such secondary paths can remain stable for some time, they can "tilt" the solution one way or the other, and introduced biased, non-random noise.

There are a few observations and ideas that spring from the graph above:

• When looking at stationary data, we must examine directional speeds, not just speed over ground
• Moving average filters may be useful to differentiate between random and non-random errors
• For some test speed data, directional speed data may be useful as as estimate of random speed errors. 

The last point is the most interesting. Since we usually sail  in a straight line during speedsurfing, we can re-map the speed vectors into two components: one in direction of travel, and a second one at a 90-degree angle to it. Any sideways speed, especially any fast variation, would definitively be error. It is probably reasonable to assume that the error in the direction of travel is of a similar magnitude.
However, a closer examination shows that this approach probably would work for test drives, but not for speedsurfing. We are most concerned about errors when they reach 1 knot or more, which is about 0.5 meters per second. When measuring at 5 Hz, this would correspond to a 10 cm lateral movement - something that could quite easily be caused by relatively small body movements, for example from a gust or a piece of chop. But when driving around in a car to test GPS units, such lateral movements do not happen, so the approach should be useful there .. especially on streets that go straight north-south or east-west, and that don't have any trees or buildings on the side. Maybe this approach is of somewhat limited usefulness... time to watch some soccer!

Foil Against Noise

Let me start with a picture to make clear what this post is about:

It's about how a little bit of aluminum foil can help against RF noise from Raspberry Pies(the kind shown in the picture above - if other raspberry pies make you noisy, try the gluten free versions!).
The graph above shows the results from a stationary test, with measured speed on top, and accuracy estimates at the bottom. For the first 5 minutes of the test (the left, yellow half), I had covered the Raspberry Pi with a bit of aluminum foil; for the second half of the test, I put the Pi on top of the foil.

The results show that (a) the Pi generates a lot of RF noise that's picked up by the GPS and introduces error, and (b) that this RF noise can be blocked quite easily. For those of you who like numbers, here are the averages and maxima for this test (all numbers in knots):

For the numbers, I divided the second half of the test into two parts: a transition part, where the speeds and error estimates where high; and a "not blocked" part, when the numbers stabilized. Moving the Pi took just a few seconds, but the transition period lasted about 2 minutes. I'm not sure exactly what was going on there - perhaps the software in the GPS module needed a couple of minutes to figure out which satellites and/or noise filters to use. 

The numbers in the table above reflect what I had seen many times before in other data sets:

• At low error estimates (the "with foil" row), actual errors typically are below the error estimates.
• With higher error estimates, deviations larger than the error estimate can be observed more often.
• With poor data quality (high error estimates), the error becomes less random, with extended regions of larger error. This is illustrated by the high (false) speed over 2 seconds of more than 4 knots in the "Transition" period. In this region, 10 successive points had errors over 2 knots, about 2x to 5x as high as the error estimate. This would be extremely unlikely to occur randomly.

While the data shown are from a single test, the results are very reproducible. This is quite easy to do by simply hooking up the GPS to u-center, and opening a few graphs. Here's a screen shot from the part where the Pi was covered with foil:

Changes after uncovering the Pi where quite dramatic:

For a lot of the satellites (but not all of them), the observed signal-to-noise ratio dropped significantly, which reduced the accuracy of the speed calculations. So, if you want to use a Raspberry Pi to capture GPS data: cover your Pi!

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.