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:
- A Samsung Galaxy J3 Luna Pro phone running Android. I bought it for $30 at Best Buy.
- A USB GPS dongle with a U-blox 7 chip that I bought for $15 from Amazon (like this one).
- 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.
