clarify the meaning of the solution types

[maltewi]

Advanced Navigation D-GPS driver provides solution type gnss_fix_omnistar. This PR reflects this value by extending GPS_SOLUTION_TYPE with the value OMNISTAR.

[doudou]

I'm not so fond of the idea of adding satellite based augmentations such as omnistar in this enum. OmniSTAR, as other satellite-based augmentations, means that you have a differential solution and I'd rather leave it this way in the field.

if you do want to report which source of differential correction is being used, I would either have a device specific output, or if you want to have it common in gps_base, add a new enum.

I don't know if a receiver would be able to use more than one correction source at the same time. I'm not even sure it makes any sense to do so, to be honest. So the enum would either be a "standard" enum, or one that is compatible with a bitfield (the way it is done for e.g. GNSS_EXTRA_STATUS here.

A receiver can use omnistar corrections to build a RTK_FLOAT solution for instance.

[leifole]

Like @doudou , I would also not add Omnistar in gps_base. It is a vendor-specific service, not a satellite fix class, imo. We would have to add all vendor-specific types here, for example HxGN SmartNet and similar from Leica or national services like SAPOS EPS/HEPS, etc. If a device is supporting a specific service, I would add the extra information in the specific device driver.

[maltewi]

I understand the concern and agree with it.

I like how you solved it here: https://github.com/rock-drivers/drivers-imu_advanced_navigation_anpp/blob/master/src/Constants.hpp#L38 another discussion could be if https://github.com/rock-drivers/drivers-orogen-imu_an_spatial is still required and why. But that's a different topic.

Since we are discussing the GPS_SOLUTION_TYPES data structure: What's your opinion on adding SBAS (Satellite Based Augmentation System) to indicate that a satellite correction signal is used?

A receiver can use omnistar corrections to build a RTK_FLOAT solution for instance.

When reading about it online, it looks like RTK always refers to a signal from a reference station on ground (e.g. according to https://www.trimble.com/OEM_ReceiverHelp/V4.44/en/, https://gssc.esa.int/navipedia/index.php/GNSS_Augmentation#Differential_GNSS). Accordto that, SBAS would there be a different solution type than RTK.

[leifole]

Since we are discussing the GPS_SOLUTION_TYPES data structure: What's your opinion on adding SBAS (Satellite Based Augmentation System) to indicate that a satellite correction signal is used?

The use of SBAS as an own fix class for satellite based augmentation like WAAS and EGNOS seems legit to me.

[doudou]

Accordto that, SBAS would there be a different solution type than RTK.

Well ... it's a solution type in addition to SBAS.

It so happens that if you have a on-ground correction source valid for RTK, there's very little point to use a satellite-based correction system.

In the end, I would prefer keeping the GPS_SOLUTION_TYPE as it is and add a bitfield to list the source of corrections. So, one could have DIFFERENTIAL with WAAS or with base station and RTK with SBAS.

[maltewi]

Still not sure about the usage of the enum.. it's either because of the lack of documentation (plus not enough knowledge to understand it myself) of the enum or because there's something missing.

Maybe answers to concrete cases would help:

• The question is what solution type would be the appropriate GPS_SOLUTION_TYPE when a correction satellite visible? DIFFERNTIAL?
• What would be the setting if there no correction satellite was visible (OMNISTAR correction can't be received)? AUTONOMOUS?

What makes it difficult to follow your idea is this thought: If DIFFERENTIAL says, we have a 'somehow' corrected signal and the means of corrections are encoded in some bitfield: Should not RTK go as well to the bitfield? If not, why?

[doudou]

With GPS, there are basically three and a half types of solutions.

• autonomous: no corrections
• differential: use atmospheric corrections to improve the solution
• RTK_FLOAT: RTK corrections, but the solution isn't "fixed", that is the certainty integral part of the phase shift is not determined with a good enough certainty. This is the "half mode".
• RTK_FIXED: full RTK solution

In principle, RTK is "differential". But it is different enough from the "atmospheric correction" one that it warrants a separate mode IMO. While "differential" only corrects for atmospheric effects, RTK require a base station, allowing the GPS unit to measure phase shifts between this base station and the rover (or two rover in heading mode). "DIFFERENTIAL" really only means "apply atmospheric corrections", no base station with a known position needed.

It turns out that when you do have a base station, the base station also provides the rover with atmospheric parameters, hence my remark that in most cases you wouldn't need a SBAS signal if you do have a base station.

As far as I know, there is, also in principle, no real need to track multiple SBAS (or any ground-based way to get atmospheric corrections) at the same time - SBAS is a mean to get information, not a signal used directly in the triangulation, so two SBAS networks would in principle provide the same information.

However, since we're talking about adding a new stream of information, I thought I would err on the safe side and add a bitfield, which would list all the sources of information (we could add the positioning networks - GPS/Galileo/GLONASS/Baidu - without having to care about which ones are mutually exclusive and which are not.

To finally answer your questions:

• The question is what solution type would be the appropriate GPS_SOLUTION_TYPE when a correction satellite visible? DIFFERNTIAL?

Yes.

• What would be the setting if there no correction satellite was visible (OMNISTAR correction can't be received)? AUTONOMOUS?

If there isn't any other mean of correction, then AUTONOMOUS yes.

[doudou]

Ping ?

[maltewi]

Thanks for the explanation. I try to put the result of it into the type as documentation. Please have a look. Especially about AUTONOMOUS_2D. Since we didn't speak about AUTONOMOUS_2D, so I made something up there:

    enum GPS_SOLUTION_TYPES
    {
        NO_SOLUTION    = 0, //No GPS solution found
        AUTONOMOUS_2D  = 6, //Like AUTONOMOUS, but solution doesn't provide height information. Is 6 for historical reasons
        AUTONOMOUS     = 1, //No correction
        DIFFERENTIAL   = 2, //Atmospheric correction is used e.g. as provided by a Satellite or Ground Based Augmentation System
        INVALID        = 3, //Correction result is invalid
        RTK_FIXED      = 4, //Complete RTK correction
        RTK_FLOAT      = 5  //Real Time Kinematics correction with undetermined phase shift
    };

[doudou]

Looks good. Do you want to implement the enum for the bitfield for correction sources, or are you happy with the status quo ? If it is the latter, I'll merge the PR.

[maltewi]

With the clarification, status quo is okay for me

[doudou]

Sh*t, should have updated the PR title before mergin :(