Thursday, November 30, 2017

An Accurate GPS for $20?

This is a somewhat geeky post. However, if you've thought about using a GPS when windsurfing in the past, you might find it of interest.

Currently, the only "officially approved" GPS that the Locosys GW-60 watch. But the GW-60 has some issues, one of them being the price of about $250.

So - what if we could use something simple and cheap like this:
Here's what you see in the picture:

  1. A Samsung Galaxy J3 Luna Pro phone running Android. I bought it for $30 at Best Buy. 
  2. A USB GPS dongle with a U-blox 7 chip that I bought for $15 from Amazon (like this one).
  3. A USB "On-The-Go" cable for about $5 (like this one) to connect the dongle to the phone (note that the phone must support USB OTG - not all phones do!).
I'm also running the GPSLogit app, which costs about $17. But I had that already, and in the future, there probably will be other free apps that can be used. Similarly, if you already have an Android phone that supports USB OTG (also call "USB Host mode"), you could use that - hence the $20.

For the picture above, I used the free app GNSS Commander to read the data from the USB dongle, and provide them as "mock locations" to GPSLogit. After a successful initial test walk and drive,  I put the entire setup in a ziplock bag and then into a water proof armband, and then went windsurfing. For comparison, I also used a GW-60 watch. Here are the tracks:
The data from the dongle are in red, from the GW-60 in blue. Not a lot of difference! That's a promising start.

The setup above has a few issues, though - the biggest one being that we loose the accuracy data from the GPS chip in the dongle somewhere along the way. The U-blox GPS chips are exceptional in that they provide error estimates for doppler speeds; such error estimates (often call "SDoP") are essential to automatically identify artifacts in the GPS data (like Nina's recent 2 second top speed of 55 knots).

Since the GPS chip in the USB dongle can provide speed error estimates, a bit of hacking was required. I started with some public domain software for USB communication on Android, and quickly got it to read the dongle data. I used the u-center software on Windows to tell the dongle that is should send out data in the format that includes the speed accuracy data (using "ubx" instead of "NMEA" messages); while there, I also told it to send data at a higher rate (5 Hz like the GW-60, instead of the default 1 Hz). The hacked app simply reads the data, shows them on the screen to show it's busy, and write them to a "ubx" file.

Now, a test drive was in order. On the phone, I recorded the GPS data from the dongle with my hacked app, and also had GPSLogit record data from the phone's GPS chip. The speech function in GPSLogit also was on, and told me how fast I was going every 2 seconds. For comparison, I used a GW-60 watch.

Looking at the results back home turned out to be a bit more difficult. My favorite program, GPS Action Replay, is a bit buggy when it comes to reading ubx files, and got the date wrong by about a week. It also did not read the accuracy data correctly. In the alternative program, GPSResults, the accuracy data were displayed correctly, but the speed analysis did not work well, since the dongle data had a lot of missing data points (the distance between 2 points sometimes was 0.4 seconds instead of 0.2 seconds). Since GPSResults is super-strict, it refuses to use any section with missing points for top speeds. However, we a visual comparison of the data shows some interesting trends:
The picture above shows that the speeds from the GW-60 and the USB dongle were very close to each other most of the time. The data from the phone's GPS are often similar, but show a pronounce lag of about 2 seconds every time the speed goes up. I actually noticed that when driving - the speed announcements from the phone alway seemed to lag behind, even after taking some unavoidable lag between the speed measurement and the announcement into account. The cause of the lag is most likely a filter in the phone's GPS firmware. In the example above, the effect is that the phone GPS often understated the peak speed at the end of an acceleration by 1 - 2 km/h. For use outside of competitions, the phone GPS was sufficiently adequate; however, the delay in reporting acceleration might be somewhat detrimental when you want to fine-tune your stance in speed runs.

These first results are encouraging. Obviously, a lot more tests in "real-world" windsurfing conditions are necessary. Even before that, I'll need to look into the cause of the missing data points - it could be something as simple as the phone being to busy dumping data onto the screen, or announcing speeds. Worst case scenario would be to use the dongle at 1 Hz, where missing data points are much less likely.

One of the cool things about using phones for GPS speedsurfing is that they have large displays, sound output, and plenty of memory and processing power. That means you can see and hear your speed while your sailing, and get numbers in categories like alpha 500, nautical mile, and one hour where the GW-60 simply does not have enough "brains" to calculate the results on the fly. Even if you have to buy a phone at a non-sales price (closer to $70 or so), you'll end up with a cheaper and more powerful, albeit perhaps less convenient, solution.  That may require that apps like GPSLogit or Windsport Tracker will support the GPS dongles directly - but if not, app development on Android is pretty easy. With the accuracy data from the u-blox GPS chips, the results should even be useful for competitions like the GPS Team Challenge.


  1. Peter, besides the 'nerd thrill', what was your motivation to go to the extra effort of using the u-blox chip when the smartphone already has a GPS solution? I'll offer some possibilities for the motivation - correct me if I'm wrong or incomplete: 1) increased accuracy (SDop), 2) increased sampling rate and thus better resolution (5 Hz and possibly higher), 3) one known GPS chip-set making 'certification' easier for GPSTC since the variety of GPS chips/phones made certification a nightmare. Thanks.

    1. Barton, each phone has a different GPS chip, so phones will never be acceptable for GPSTC - it would be too much effort for every phone. Also, the Android locations don't have SDoP, will kills any chance of acceptance. So it's mostly 1 and 3. I don't care about higher data rates - all arguments for 5 Hz + as purely theoretical, and ignore what real world data actually look like. But being able to go to 5 Hz + may also make #3 easier, since the authorities are firm believers in high data rates.

  2. Hi Peter, Nice experiment. :-)
    Did you know that Manfred has made a test version of GPS-Logit that accepts data from a GPS via Bluetooth. Roo and I have been playing with it using Ublox8 chipsets connected up with a battery and BT card to transmit the data to an Android phone. Manfred and Roo have had good results with 18Hz recording of the UBX data, but since I am a cheapskate, I am using lower quality cheap Android phones and do get a few too many missing points @18Hz. I have however, found pretty much flawless performance at 10Hz. I have done lots of side by side comparisons with GT-31, GW52 and GW60 units and 10Hz ubx logged this way. The ubx data is as good as, or better than the others in almost every respect. Biggest disadvantage is the very large file size and slow processing in GPS-Results as a result of that.

    1. Andrew, the attraction of my setup was that all parts can be bought, and anyone who can use a phone can put them together. I remember Roo posting some 18 Hz results where the accuracy estimates were way too optimistic.
      The pursuit of ever-higher herz rates is largely based on theoretical considerations which are largely irrelevant to speedsurfing. Attach a GPS close to the center mass of the body, and the real speed changes are slow enough that 1 Hz recordings are VERY close to reality. Put the GPS on the wrist, and what you measure is mostly hand movement in 3D. Have the watch face down, and virtually all high-frequency changes are artifacts.

      The biggest change since using 5 Hz data has been that the difference between max speed and 2 second speed has become larger. Almost everyone emphasizes max speed now. But even the 2-second speed has rather severe limitations. "Max" speed for 0.2 seconds is meaningless - it often has error estimates of 0.5 to 1.5 knots. Since real speed is often rather constant over 2 seconds, max just picks the value that is randomly the highest - so it is an actual overstatement by roughly the same amount as the SDoP. This is an actual measurement (or rather, algorithm) bias, not a theoretical consideration.

  3. Good to see you getting this experiment to fruititon Peter. You have done far better than me with the Arduino board. I look forward to seeing a postive result from your debugging, because as you suggest, its a very affordable solution.( and easy to set up for a lazy potato like me :-)