GPS fix - meaning of QUALITY_POOR?

Yeah, I already looked at this a while ago. There doesn't appear to be anything that allows an field/widget/app to determine the accuracy of a GPS fix. Unless the documentation improves and we get a clear guideline for what the names map to, or we get a new interface that provides the estimated error, you're kinda dead in the water.

Here's an explanation of the constants

QUALITY_POOR - We have a two dimensional fix
QUALITY_USABLE - We have a three dimensional fix and the dilution of precision is > 3.0
QUALITY_GOOD - We have a three dimensional fix and the dilution of precision is <= 3.0

Overall I trust these values because they came from smart people(tm).

One question to the hive mind: is there interest in providing a way to push up our satellite and GPS information pages? I really want to keep the GPS API simple, so if you just want to replicate our satellite information I'd rather just provide a direct way of showing the pages than expose all the GPS information.

-Alpha Monkey

Here's an explanation of the constants

QUALITY_POOR - We have a two dimensional fix
QUALITY_USABLE - We have a three dimensional fix and the dilution of precision is > 3.0
QUALITY_GOOD - We have a three dimensional fix and the dilution of precision is <= 3.0

Thanks (I think!). I'll have to read that Wikipedia entry a few more times...

One question to the hive mind: is there interest in providing a way to push up our satellite and GPS information pages? I really want to keep the GPS API simple, so if you just want to replicate our satellite information I'd rather just provide a direct way of showing the pages than expose all the GPS information.

Not from me. It isn't that I want to show fancy GPS information to users, but rather let my apps make logic/display decisions based on the estimated accuracy of the current position. e.g., does my app tell the user "head North" or does it make sense to say "head 15 degrees for 25 metres".

It would make app logic much easier if the API gave us a simple "estimated accuracy" as a number of metres. The Garmin devices already calculate and display this number to the user when getting a satellite fix.

I think the value of having the estimated accuracy of numbers of meters is that there are many threads (over time) of people trying to troubleshoot GPS fix information. I'd think it'd be super handy for someone to be able to develop an app that's simply "GPS Satellite Fix Happiness" (or related), heck, even by Garmin support. And then someone have a data page that has that information available and possibly recorded. If nothing else, it'd probably cut down on troubleshooting both here and by Garmin support.

I think the value of having the estimated accuracy of numbers of meters is that there are many threads (over time) of people trying to troubleshoot GPS fix information. I'd think it'd be super handy for someone to be able to develop an app that's simply "GPS Satellite Fix Happiness" (or related), heck, even by Garmin support. And then someone have a data page that has that information available and possibly recorded. If nothing else, it'd probably cut down on troubleshooting both here and by Garmin support.

What he said.

On a related note, the SDK 0.2.4 is now returning accuracy=QUALITY_LAST_KNOWN when replaying FIT files. Does this mean we can't tell anything about the accuracy of the GPS fix? The API docs state:

QUALITY_LAST_KNOWN
The Location is based on the last known GPS fix

which I find a bit unclear. Does QUALITY_LAST_KNOWN really mean - "here is a location that I got some time ago, so might be out of date" ? What sort of situations would you get that value? Would you get it in a real device, or only when replaying FIT files since they don't record the GPS quality data?

It means that the position information that you're being fed is based on the last known position data that the device had. I'm thinking that would likely get that if you called Position.getInfo() for location information and the system (based on some unknown criteria) determined that the position data it was providing is stale.

The simulator isn't handling quality properly yet. For FIT parsing, we should be returning GOOD quality. The quality of the GPS is not something that is recorded in the file, so we won't be able to play back that information.

Last known should mean that you do not have a GPS fix, and you are getting the last position that was recorded when the device did have a fix.