It can depend on activity. You wouldn't want GPS used for a treadmill, right? And wouldn't you have GLONASS set for any activity you do on the vahr if it was needed?
Understood, but not allowing the user to select GLONASS for any app that uses GPS, and not allowing the user to turn that feature on & off in the system menu is just plain silly. Seriously.... you have to go to some Garmin native app to enable a particular type of GPS hardware for other apps ?????? Seriously ??? There is absolutely nothing reasonable about that.
Jim's assessment about the lack of a system-wide setting is correct. Many of our devices do have a system setting to enable/disable GLONASS, but the vivoactive HR was designed primarily as a fitness device, and GPS is generally used in the context of an activity. Allowing a per-activity setting gives you better control over when GLONASS will be used (and therefore more control over your battery life).
With regard to Connect IQ, we've discussed this on several occasions in the past. I'll quote myself referring to the ability to control GPS modes (GLONASS, WAAS, etc.) from Connect IQ:
The general rule is that Connect IQ will always receive data from the best available source. In the case of positioning, CIQ can enable location sensors or disable them, but cannot specify the source of the location data (e.g. GLONASS vs. no GLONASS, GPS altitude vs. barometric altitude, etc.). If the host device supports GLONASS and the last native app (e.g. Run, Bike, etc.) used GLONASS, then the CIQ app will use it too. At least that's how it's supposed to work.
We have considered opening things up a little more, but the Garmin perspective has traditionally been that we'd prefer to always provide the best available source. If a Connect IQ app chose to use a less accurate source for some reason, a customer may get the impression that the device performs poorly even though it's the app that has restricted performance. There are some good counter-arguments, however. A good example is obtaining altitude for aviation applications--a GPS altitude is desired in some cases because a barometric altitude in a pressurized cabin will simply be wrong. We're still discussing the best approach.
Hi Brandon, I'm certainly for receiving the best available GPS data, but does the underlying system code actually determine which source will provide the best data ? And... I understand that there are trade-offs to be made concerning power use and there may be a direct trade-off between power consumption and GPS data accuracy. To me, that points at providing the same setting selection for developer apps as you do for native apps, so that the user (with guidance from the developer) can decide whether to select GLONASS for each app that uses GPS, or at least for apps that could benefit from the best accuracy in their GPS data. Since you already do this for the native apps it doesn't seem like much of a stretch to do the same for non-Garmin apps that use GPS. Since the capability is there, why not let the user choose in a way that is as obvious as it is for the native apps ?
Yes, the underlying system code chooses the best available source in some cases (altitude is a good example: if available, we'll provide altitude from the barometer and fall back to 3D GPS, which is typically less accurate).
I don't disagree that allowing the developer more control has advantages. My goal is to explain that there is a rationale behind how things currently work--it's not an arbitrary design decision or some sort of oversight. :) The jury is still out on whether we'll allow more granular control of sensor data sources when more than one is available. I'm optimistic that we'll eventually provide APIs that give Connect IQ developers to either use the default "best source" or choose a specific source.
