Also, in about the same time frame, I got more active in a social media scene, after Google+ launched publicly. Posting about a completed run or ride, including the exact track, has been a reasonably nice use of the platform. And for the morbidly curious, here’s my Strava profile. I typically log all runs there -- I can’t get good metrics on them otherwise -- but I only log notable or unusual bike rides.
Over time, though, I noticed a couple of problems with using my phone to lay down a GPS track:
- Recording adversely affects battery life. I’d get maybe 8-9 hours tops before the phone was nearly out of juice.
- On the phones I’ve recently owned [1], GPS accuracy is fairly poor. In fact, even staying stationary in the open, the GPS position will jitter.
Both of these factors conspire towards making one adopt a behavioral tic: when stopped for a considerable length of time, hit the “Pause” button on the GPS-track recording app [2]. When the ride or run resumes, unpause and resuming recording. Which brings us to another pair of problems:
- Pausing the phone for every traffic light, 2-minute drinking break at a water fountain, etc., is a prohibitive pain-in-the-butt, so you’ll just have to accept the jitter sometimes.
- At the long stops, where you do take the trouble to pause: will you remember to unpause the GPS app when underway again? It’s easy to forget!
It seems most people deal with these problem by buying a Garmin GPS-enabled cyclecomputer or GPS training watch. The latter would be a better choice if running is in the mix. I didn’t give this option too much consideration, though. I like the idea of having a smartphone with a reasonable amount of computing and interactive power recording my ride. I also like uploading activities to the web directly from the device. Tethering [3] my recording device to a full-sized computer at the end of my rides to do anything at all interesting with the data appears to be the usual option with Garmin, and it seems... less appealing. Maybe I’m just impatient, but I like to have the basic thing that I do with a ride taken care of on its completion, not as part of some post-completion task. Sometimes a post-completion task that I’d be hours away from being able to complete -- many of my runs and rides do not end at home.
Then I heard (from an office e-mail list) some prerelease buzz about the Garmin GLO. Part of the context of this discussion was “hey, the Garmin Connect software ecosystem is kinda poor; this would be a way to get good Garmin data without having to butt heads with the software.” This is perhaps hearsay, though; I’d love to hear some more definitive opinions on that in the comments.
The GLO is a small external GPS receiver which connects to a client device via bluetooth. Speaking more accurately, the device locates and tracks GPS and GLONASS satellites; the latter is a parallel system to GPS, largely workalike, with roots in the old USSR aerospace sector. It is also the namesake acronym for the device. An Android or iOS device can be configured to use the GLO as its GPS data source rather than the built-in GPS hardware [4]. The GLO gets its initial GPS fix relatively quickly -- though more on this later -- and once fixed, updates its position at 10 Hz. (With a phone, you’d probably be lucky to get a 1-Hz refresh.) Advertised battery life is 12 hours between charges.
What does it look like? Here: next to a deck of cards, for scale. The GLO is slightly slimmer than the deck.
The middle LED monitors the Bluetooth connection between the device and its counterparty. The lower LED is a GPS signal and battery status indicator. It is mounted on a push button that turns the device on and off.
GPS accuracy with this device was hyped as being quite good. Great! The promise of that was enough to justify the $99 asking price alone. The next potential benefit: a bluetooth GPS unit could be good for phone battery life by offloading power-hungry GPS calls to an external unit (and battery) and substituting lightweight bluetooth calls in their stead.
I hoped that if the battery-life improvements were good enough, maybe I could generally keep the unit recording continuously rather than worrying about pausing at long stops and forgetting to unpause later on.
Setup Guide
Given that there’s no good guide for setting up this device with Android elsewhere on the web, and it wasn’t entirely trivial to figure out, here’s a quick how-to:- Turn both devices on.
- Pair your phone and the GLO via the standard approach for bluetooth devices.
- Install the Bluetooth GPS app onto the android device.
- Launch the app
- Go into the settings, and allow the phone to “Use Insecure Connection” (which isn’t checked-off/allowed by default).
- Back in the Main App screen, check the box to “Enable Mock GPS Provider”. This will take you to a developer option in the phone settings.
- Back in the Main App screen, touch the dropdown to select the source GPS device. It’ll be “Garmin GLO #6eadb” or something similar.
All of this is one-time setup. That done, connecting to the GLO is then just a question of launching the app and pressing the big “Connect” button.
I can’t directly comment on the setup process on iOS, though copy associated with the product makes me suspect it is less involved, as the device is specifically certified as compatible with Apple devices.
Initial Results
GLO accuracy is much better than base phone GPS accuracy. Here’s how a segment of my typical run to work looks if recorded with the base phone GPS (image taken from http://app.strava.com/runs/18462316):
Much smoother, even scaled down a bit so as not to be unwieldy on this page, and generally much truer to my actual path. The GLO will still be off by a bit sometimes -- there are still lots of tall buildings in Manhattan, certainly -- but typically the egregiousness of this error is much reduced.
In fact, the built-in phone hardware was typically overstating the length of my runs by about 10%.
I haven’t yet completely run down the GLO battery in a single go, but the advertised life of 12 hours seems to be about right.
On the phone side of things, though, I wasn’t realizing the gains in battery life I was hoping for. Using the GLO was draining my battery more rapidly! Seemingly relatedly, my phone was warm to the touch after prolonged GLO-linked use.
Debugging battery life issues, and the solution
The first thing I checked was whether explicitly disabling the onboard GPS hardware made a difference when using the “Mock” source instead. This didn’t matter, though.
“Google Maps” was listed as the culprit application or process in the battery usage log, with the Strava App coming in distant second. Hmmm.
Then I noticed that for trips of 3+ hours, the Strava app would have trouble successfully uploading to Strava’s cloud servers at all. Digging into the underlying storage on the phone, I realized that the underlying .gpx files the app was creating were unusually large when using the GLO compared to without.
A-ha! The refresh rate on the GLO is 10 Hz, compared with maybe one update per second with the built-in hardware. How frequently does the Strava App poll for updates? Best as I can tell, it does so continuously, as fast as the device will allow for it. My conclusion is that the app was not engineered for the GLO’s speedy turnaround time, and was running itself (and my phone) ragged trying to keep up with all the updates.
Alas, the Strava app does not allow manually tuning the GPS refresh rate; it only offers ASAP behavior. MyTracks allows for tuning, though. I was able to reproduce the same battery drain & warmth effects with MyTracks at its default settings, but dropping the refresh rate down takes care of it immediately. Battery life was obviously improved with a 1-second polling interval, marginally improved further from there with a 2-second polling interval, and debatably improved again with a 5-second interval. Lately I’ve been using a 5-second interval.
With this tweak in place, battery performance seems to improve slightly over the non-GLO alternative, but not remarkably so. It’s still advisable to pause recording at a long stop [5].
Also, MyTracks’ introduction means that my workflow on the phone does not include automatic upload to Strava when the ride is done. Instead, I save the file to the device in GPX format, and then “share” the track file by email, To: upload@strava.com . It’s unfortunate. If I know a workout will be short, especially if I have means to charge my phone on the other end, I’ll often opt for the Strava app instead, heedless of the battery implications.
I’d also note that even if battery life weren’t at issue, pausing at long stops would still be good idea, if the stop involves a trip indoors. Movement indoors can cause apparent jitter in position even if there is none in actuality, as the GLO gets partial or reflected readings even inside the building.
Not just for run- and ride-tracking
I’ve also paired my phone with the GLO when getting ordinary turn-by-turn directions from the navigation feature of the Maps app. This has been helpful in gauging my position and upcoming turns more accurately. (With built-in GPS, sometimes my phone would lose track of me when driving, e.g., on the elevated Brooklyn-Queens Expressway and decide that I was on one of the parallel frontage roads or on an underlying avenue instead. Eep.)
Other quirks
The first time the device is turned on in a rampantly new geography -- out of doors, with a good view of much of the sky -- it takes maybe 20-30 seconds to get an initial fix on its position. I noticed this when the device was new, and again immediately after air travel. There have been a few instances of the latter. Shorter positional gaps during which the device was off -- between work and home, say, or the 35 miles between my own apartment and my parents’ house -- have delayed initial fix slightly, but less dramatically.
If I start to record an activity before I get initial GPS fix -- something I’d really like to be able to do freely, since I live in an apartment building -- the recording app seems to receive a few stray points from the last place the GLO had a fix on its position, which get inserted as junk data at the beginning of my overall track. If I don’t want to wait before getting underway, I can repair this after the fact by manually editing the .gpx file before loading it. It’s human-readable XML, so this is fairly trivial. Alternately, I may use the “Crop Ride” feature in Strava after upload, though this seems to be slightly too blunt an instrument.
The unit will flash a different pattern on the charging/fix LED if it is running low on power. IME, it will shut itself off soon after that. There’s no way to otherwise gauge the runtime remaining, except to charge it fully. I tend to do this even if I don’t think I need the full runtime, just to make sure the device is in a known state.
If the connection between the GLO and my phone goes sour mid-activity, I’ve found that I have to power-cycle the GLO before it starts serving data properly again. I’ve only seen this happen if I physically separate the GLO and the phone, though. For example, let’s say I lock up my bike and take my pannier, with GLO inside, into a cafe. I put the phone in my pocket. Then I leave the pannier with my family while going to the bathroom 20 yards & a door distant. Oops.
The power button requires a press (for a short count) to turn on, or a press and hold (for a long count) to turn off. This makes it too easy for the GLO to “turn itself on” if put in a pouch or a pocket, and silently drain away its battery out-of-sight. I’ve taken to wedging a small piece of paper between the battery’s contacts and the pickups in the battery slot to keep the GLO off when I really want it off. At other times, I stow the paper harmlessly under the battery cover.
I also worry about the converse problem -- the device “turning itself off” -- but this hasn’t happened yet. In any case, a sliding on-off switch may have been a better design choice.
Conclusions
Despite the quirks, the drawbacks of the polling-frequency workaround, and the fact that phone battery-life improvements are marginal, I do like this device. Seeing smoothly-drawn track lines at the end of a ride or run is much more satisfying than seeing squigglies, and the improved distance accuracy for running trips is very valuable in its own right. It’s enough trouble that I don’t bother with it for ordinary rides to work, but I never bothered with tracking these rides before anyway.
I would probably enjoy using a GPS watch as well, if I had one. Prices are slightly less gentle than the $100 GLO -- figure $170 MSRP for a decent wired-data-transfer GPS watch, or $250 MSRP for one that syncs wirelessly, via ANT+ -- but that wasn’t really the blocking consideration. Mainly, I consider the necessary intervention of a computer to get the data off such a device to be a serious drawback, and I can usually get away without doing this with the GLO. I’d like the GLO even more if I didn’t have to be so careful not to trip over its many quirks, alas. And if these quirks weren’t sometimes easiest to remedy with, in fact, computer intervention.
If you think you might be of a similar mindset, give the Garmin GLO some consideration.
---
[1] GPS accuracy on my current phone, a Samsung Galaxy Nexus, is poor. My previous phone/current backup phone, a Samsung Nexus S, is even worse.
[2] The Strava app has had a “Pause” button as long as I’ve used Strava. MyTracks finally added one a few months ago.
[3] Yes, I realize many devices can communicate wirelessly via ANT+ and don’t require a literal tethered USB cord to transfer data.
[4] Some Android and iOS devices even lack built-in GPS entirely. The most notable examples are wifi-only Apple devices, such as the iPod Touch and the wifi-only iPad.
[5] Lately I’ve been playing games to remind myself to unpause recording before I proceed. The latest: I’ll stash my phone somewhere on my person that I usually don’t -- in a jersey pocket instead of its usual spot in my pannier, for example. When I ask myself later “Hey, why did I take this out of the pannier?”, it jogs my memory. "Oh, right, I need to hit unpause before I put it away."
0 komentar:
Posting Komentar