Show "# Sats" in X/Y/Z format

[Vascom]

I want suggest add new number to "# Sats".

Now it is shown like "# Sats: 20/46" for example. That mean:
20 - sats used in position;
46 - sats potentially visible and known by almanac.

New behavior in my view can be this "# Sats: 20/30/46". That mean:
20 - sats used in position;
30 - sats really visible and tracked by receiver (signal have C/N0 value);
46 - sats potentially visible and known by almanac.

This will more accurately reflect the real situation in urban canyons and difficult reception conditions.

[barbeau]

So the current "# Sats" is actually "X/Y", where:

• X is the number of satellites used in computing the position
• Y is the number of satellites with signals visible to the device returned by the Android GnssStatus API, which historically has been signals visible to the device

The number of satellites/signals that have almanac data isn't currently displayed, but could be useful (as well as number with ephemeris).

I'll change the issue to potentially add a count of satellites with almanac and ephemeris data, which might be a good candidate for a more detailed view of satellites as discussed in #313.

[Vascom]

Y - is not the number of sats visible for device. Because even undergrownd it show about 30 and all with almanac.

[barbeau]

@Vascom Hmm, thanks for pointing this out. What device and Android version do you have?

My above reply should have read:

• Y is the number of satellites returned by the Android GnssStatus API, which historically has been signals visible to the device

This code was written way back on Android 1.5, and it looks like it's time to revisit it, as the behavior of devices has likely changed/diverged over time.

I see something similar on a Samsung Galaxy S8+ w/ Android 9 - all signals have almanac data but some do not have C/N0:

But the main screenshot on the Google Play listing, which IIRC is from a Xiaomi Mi8, you can see some records with C/N0 but without almanac data:

Which signals are returned from the API is determined by the device and likely depend on a variety of things like A-GPS/SUPL implementation, so I'll look at refining these counts based on actual C/N0 values instead of just the record count.

[Vascom]

I have Android 10 on Xiaomi Mi 9.

[barbeau]

Looking at the screenshots in https://medium.com/@sjbarbeau/dual-frequency-gnss-on-android-devices-152b8826e1c, behavior still varies across even newer devices.

For example, here's a Huawei Mate 20 Pro that includes satellites in the list that don't have C/N0, almanac, or ephemeris data, but still have elevation and azimuth data:

How does the device know where they are? ¯\_(ツ)_/¯

Same with the Hong Kong variant of the Samsung Galaxy S10, although it's for Beidou:

Most of the other screenshots do either show at least C/N0 or almanac data for the satellites returned in the list.

I also looked at the most recent GnssStatus docs:
https://developer.android.com/reference/android/location/GnssStatus.Callback.html#onSatelliteStatusChanged(android.location.GnssStatus)

...but they don't give any further guidance for what should be in the list - just:

the current status of all satellites.

[Vascom]

Presence of almanac not critical for me or position.
Better know what sats really used and what are really tracked (have C/N0). All other can be in third number of "# Sats" field.

[barbeau]

@Vascom I agree. I think the best solution to avoid confusion with users (especially those that have been using the app for a while) is similar to what you originally suggested - a new format of "X/Y/Z", where:

• X = Number of sats used in fix
• Y = Number of sats visible (i.e., with valid C/N0 values)
• Z = Total number of sats returned by API (i.e., the number of satellites in the UI Status list)

[barbeau]

WIP PR at #368

[Vascom]

Thanks.

[Vascom]

Excellent.