Add visual info for ephemeris and almanac for each satelite

[tomikmar]

It would be great to have also visual information if ephemeris and/or almanac are known for each satellite. This info is available in the API and can be easily added.

Using my modification I found that my three Android devices behave totally different and feedback from API is sometimes strange and sometimes obviously wrong (e.g. I have a fix, but the API says that there is no ephemeris and almanac available).

With visual info it is much easier to report a bug.

Here there is an example how this feature looks like (white=has ephemeris, green=has almanac):

[mvglasow]

First of all, sorry for getting back to you so late. Showing almanac and ephemeris is a great idea, but there are a few "dimensions" of information that I'd like to represent somehow.

Currently I have a simple color coding scheme: blue is for satellites used in the fix, red for those which are not use. This is used both in the sky plot and the bar chart. SNR is represented by dot size in the sky plot, and obviously by bar size in the bar chart.

I am myself not completely happy with the way the information is represented but have yet to figure out a satisfactory way to display all of the following:

• whether the satellite is used in the fix or not (currently represented by colors)
• SNR (currently represented by dot/bar size)
• which system (GPS, GLONASS, Beidou, other) the satellite belongs to (currently not shown in sky plot but represented by position in bar chart, though I might want to add labels)
• availability of almanac/ephemeris (which you implement in the sky plot, at the expense of showing which sats are used in the fix)
• which satellite in the sky plot corresponds to which satellite in the bar chart (could be implemented by adding numbers on the sky plot, but that requires some planning for collision avoidance and the plot would quickly get crowded)

Any ideas on how to represent all of this information nicely would be very much appreciated.

[tomikmar]

1. I believe that my implementation generally doesn't remove fix/no fix information, because it is painted at the end. Yet, it is true that it may not be visible for very small SNR.

2. I agree that it is a good idea to add labels to show which system a satelite belongs to. To be honest I wasn't aware that this information is available.

3. Maybe it would we good to allow selection of information needed, i.e.

   • snr (size) + fix/no fix color (current version)
   • snr (size) + fix/no fix color + almanac/ephemeris (e.g. my implementation)
   • snr (size) + satelite system color

   Requested information could be selected in application menu or as sub-tab (see mock-up below).

   

[mvglasow]

my implementation generally doesn't remove fix/no fix information, because it is painted at the end

indeed, taking a closer look I realize what you mean. However, the colors blend into each other so that the blue dots appear greenish – maybe that can be fixed by choosing a color palette whose hues are spread out more evenly.

I've since added a fix which specifies dot size in display-independent pixels (as a function of SNR), which should make dot size less of an issue on high-DPI displays.

To be honest I wasn't aware that this information is available

This is easy to obtain by analyzing satellite numbers (see wiki for more details on this). The API treats GLONASS, Beidou and various augmentation systems as if they were extra GPS satellites. You'll see that some of the grid lines in the SNR graph are white, while others are gray. The gray ones are just for visual orientation (one grid line every 4 bars), while the white ones separate the different systems (only systems which have actually been observed on the device will show).

Maybe it would we good to allow selection of information needed

That might work as a last resort, though I'd prefer having everything at a glance. We have five "dimensions" of information, which we'd need to match to visual dimensions:

• used in fix: fill color
• SNR: size
• system: shape (triangle, square, circle, asterisk)?
• almanac: ?
• ephemeris: ?

Other candidates would be luminance and saturation, as well as border color, or maybe using hollow vs. filled dots. I'm a bit cautious about some combinations: using both luminance and saturation would give us 4 variations per color, but they might be hard to tell apart. The border color might wash into the fill color, especially at small dot sizes.

We could also decide to represent some of these dimensions only in the sky plot, or only in the SNR graph – unless doing so would discard information.

[gdt]

It seems the almanac covers everything, so I wonder if you are seeing almanac status different for different satellites within a constellation. And, a satellite appearing in the sky view means there is almanac, more or less. (Or ephemeris, in which case it doesn't matter if almanac is present.)

Garmin units have hollow bars for satellites being tracked that don't have ephemeris yet. I have never been sure if that includes satellites with ephemeris but not in the solution -- or even if such a case exists.

Assuming almanac, there are four cases, and I suggest a new color scheme to replace the red/blue one:

• not being tracked : red
• being tracked, no ephemeris: orange
• being tracked, ephemeris, not in solution: yellow
• being tracked, ephemeris, in solution: blue

This keeps the blue meaning, and shifts red to orange. It should be possible to just add colors in sky view, add a bar color (red won't appear), and give more information without it being too confusing.

[kroeckx]

Something else that would be useful is knowing if WAAS / EGNOS / whatever is available / being used.

[gdt]

On Garmin units, satellites that are using differential corrections have a "D" in the signal strength bar. It is ambiguous if that means that the satellite has differential corrections available or if it also means that it is in the solution and the solution is differential. We could use "d' for available, "D" for in a differential solution (and be yellow for not in solution). Probably the only cases we will see is a bunch of "d" and no "D", or a bunch of "D" -- if the API supports that.

[kroeckx]

You might want to read: http://www.catb.org/gpsd/faq.html#waas

[mvglasow]

Augmentation systems present themselves as extra satellites, see https://github.com/mvglasow/satstat/wiki/NMEA-IDs#sbas, therefore they should show up just like the other satellites.

[mvglasow]

I've opened a new issue to discuss this; please leave comments there.