How can I indicate the GPS status/fix

Continued from: https://forums.garmin.com/developer/connect-iq/f/discussion/399601/position-altitude-activity-info-altitude

I made some debugging, because I'd like to add some GPS indicator to the app. Something similar to the colorful circle or line at the beginning of an activity, that indicates if the GPS is ready or the user should wait a few more seconds before starting to record the activity. So I added some more logs:

10:51:39 onStart
10:51:40 timerStart
10:51:49 onPosition: ac: 4, al: 28.794516, h: 0.722252, p: N 41.761165°E 024.768223°, s: 0.000000, w: 10:51:49, ai.al: 13.034976
10:51:50 onPosition: ac: 4, al: 42.072090, h: 0.722252, p: N 41.761095°E 024.768148°, s: 0.000000, w: 10:51:50, ai.al: 26.321882

What I am interested in is how can I use Position.Info.accuracy ("ac" above). When I start the app I also start the GPS sensor. On the screen I start to display the elevation from ActivityInfo.altitude ("ai.al") and what I saw was "--" for a few seconds, and then 13 and then 26 (close enough to the actual ~22 where I was standing). I thought that I'll see the accuracy increase in the 1st seconds from 0 or 1 (when I saw "--") and then to 2 (when I saw 13) and then to 3 or 4 (when I saw 26)

Especially because of the 2 "jumps" (between -- to 14 and from 13 to 26) I was hoping that the accuracy will be increasing and that I could use that to indicate red/orange/yellow/green, but apparently not

If someone knows how to acquire the data that can be used for such GPS status/fix indicatior in an app, please share your code!

0 jim_m_58 4 days ago

When you enableLocationEvents, start watching the accuracy in the callback and look for something like > Position.QUALITY_POOR

The best is Position.QUALITY_GOOD (quality goes from 0 to 4)

You don't get the same level of info as you see in native apps

When enabling GPS, using different constellations/configurations can and do impact things. So going from basic GPS to All Multiband can impact things a fair amount

Also note that elevation based on GPS can be way off. Also note that QUALITY_USABLE is when you get a reasonable 3d data (lat/lon/elevation)

0 FlowState 4 days ago

For anyone else reading, the context is that Position.Info.accuracy is an enum [Position.Quality] with 5 values:

It seems that the complaint here is that the quality is immediately 4, as opposed to starting at 0 or 1 and moving through some intermediate values until it finally reaches 4?

TL;DR at least in my experience, the CIQ GPS accuracy field is always 0, 1 or 4. I've never seen 2 or 3 in practice. Also, just like when the native GPS indicator is green, I think a value of QUALITY_GOOD does not necessarily indicate a solid GPS fix. (Both the native GPS indicator and CIQ accuracy value are a little optimistic / premature in some cases.)

[1/3]

0 FlowState 4 days ago

My 2 cents:

- this is the only GPS quality indicator CIQ has

- I think the CIQ GPS accuracy value pretty much reflects the native indicator, at least in the sense that that if Position.Info.accuracy or Activity.info.currentLocationAccuracy is 4 (the best possible quality), then the activity GPS indicator will be green and vice versa. Does the CIQ accuracy indicator closely mirror the intermediate native GPS states? Probably not. You can try to verify what I'm saying by building a CIQ data field which shows the current location accuracy, installing it in an activity, and comparing the value to what the native GPS indicator shows. Or you could use AppBuilder 5 with the formula LocationAccuracy.

- if the implicit concern is that the quality indicator is somehow fake or useless because it returns 4 all the time [when it isn't 0 or 1], I will say that the native GPS indicator isn't much better. Assuming your EPO is up to date, as soon as you go outside, the native GPS indicator will turn green very quickly. However, in my experience, the watch usually does *not* have a solid GPS fix at this point, especially if you are around tall buildings. I can tell because the pace field is fluctuating wildly (and sometimes showing impossibly fast speeds), even if I'm standing still. I usually have to wait 30 seconds to a couple of minutes for the pace field to settle to 0:00. When this happens, I feel secure that I actually have a solid GPS fix. If I don't wait for the pace field to settle and I start running right away, then the first part of my activity is usually messed up (bad GPS track with unrealistic paces and incorrect distance).

[2/3]

0 FlowState 4 days ago in reply to FlowState

- I made the above observations on a 935, 945 LTE and 955, both with the native indicator and the GPS indicator in a device app of mine. In my device app, I generally observe that the GPS quality goes from 0/1 to 4 very quickly. Even in the cases where it takes a bit longer to get a fix, I don't think I've ever seen 2 or 3

So yeah, maybe the CIQ GPS accuracy value is a little optimistic, but so is the native GPS indicator. Unfortunately there isn't much you can do it about it.

What I do in my app is show a colour-coded "GPS" text label to indicate the quality of the fix:

- Red [0xff0000] for 0 and 1 [*]

- Orange [0xff5500] for 2

- Yellow [0xffaa00] for 3

- Green [0x00ff00] for 4

[*] QUALITY_LAST_KNOWN / 1 is kind of a special case, which is why I lump it in with QUALITY_NOT_AVAILABLE / 0

Yeah, it just so happens that I've never seen orange and yellow in my app, but what can you do? It seems that QUALITY_NOT_AVAILABLE (0) corresponds to all intermediate native indicator states (i.e. partially filled red GPS progress bar), and there's no way in CIQ indicate "how close" you are to getting any kind of fix, as there is with the native indicator.

If you want to show a "progress bar" that incrementally fills up like the native GPS indicator, I don't think it's possible in practice. Of course you could implement such a bar based on the 5 distinct GPS quality values, but if your experience matches mine, the end user will only ever see the progress bar at its minimum value or maximum value, never anything in between.

So to avoid misleading the user, maybe it would be better to just use a color-coded or binary scheme. e.g.

- GPS text with 4 (or 5) different colours as above

- GPS text with two states: text with slash through it which indicates no GPS fix, text without slash which GPS fix

[3/3]

0 FlowState 4 days ago in reply to FlowState

My additional 2 cents:

- imo the end user only cares whether they have a good GPS fix or not, so your GPS indicator may as well be a binary state indicator anyway (as it is for my app, for all intents and purposes, where GPS is pretty much always red or green).

- as mentioned above, even when the native indicator is green and/or CIQ accuracy is QUALITY_GOOD / 4, that doesn't necessarily mean you have the best fix possible, so giving the app access to more granular accuracy info isn't really gonna to help matters in that regard (it might make for a prettier UI tho)

What *might* be useful is some way to indicate QUALITY_LAST_KNOWN as a special state (although the native indicator doesn't do that afaik.) That might be a little hard to explain to end users, as well as having very limited practical utility tho