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.