ASPSuite: GNSS Quality Levels Explained

In step 3 of the processing wizard of ASPSuite the GNSS information is processed in an attempt to generate a good quality rover position file for use in downstream processing. While processing the GNSS solution a command window displays the quality level (Q level) for each epoch of the solution. Review this information for the entire flight post processing using the Diagnostics button in ASPSuite and reviewing the POS file solution plot.

POS Solution Quality Plot showing Q=5

In all cases the desire is to achieve quality level 1 for all epochs of the solution. What do the quality levels mean and how does one resolve the issues they indicate in order to achieve the desired Q1 status?

GNSS Quality Levels:

Q0 – Quality Level 0 – No Solution

Probable Resolution#1:

The rover navigation (ephemeris) file is empty or doesn’t sufficiently cover the period of collection. Often happens with flights less than 15min in length due to the broadcast frequency of the ephemeris information. See the following post for suggested resolutions: http://support.geocue.com/error-rover-position-file-pos-empty

Probable Resolution#2:

Verify the base station coordinate is entered in the correct format. A base station coordinate located far away from the observations, such as swapping lat/lon or having the wrong sign (north latitudes and east longitudes are positive) can result in no data being used.

Q1 – Quality Level 1 – Fixed Solution

This is the desired quality level for all epochs to achieve the highest quality position solution.

Q2 – Quality Level 2 – Float Solution

Q2 can be cause by a bad or noisy satellite

Probable Resolution#1:

Raise the elevation mask from the default 15° to remove satellites that are low to the horizon from being used in the solution. In ASPSuite, click on the gear icon and adjust the Elevation Mask.

Probable Resolution#2:

The Convert RINEX option (ASPSuite -> Gear icon -> Options -> Convert Base Observation File to RINEX 3.0) can be used to convert your base station to the preferred 3.0 format, however, we don’t have a good handle on when that is necessary. We have found it to be a viable solution in one instance if you can’t get a fixed solution (Q1) and are only achieving a float solution (Q2), yet everything looks like it should be achieving a fixed solution. However, we have also seen the opposite, where it was necessary to process without doing this conversion of the base station in order to get a fixed solution. We don’t have a definitive answer yet as to when one or the other should be used.

Probable Resolution#3:

The base station elevation should be entered using the ellipsoidal elevation and the desired geoid adjustment in the options used. In some cases users have been able to fake out the geoid adjustment using the orthometric height for the base station elevation and it has produced a fixed solution, however, that may not always be the case. Users are recommended to use the alternate geoid workaround for geoids not yet supported in ASPSuite.

Q3 – Quality Level 3 –SBAS Solution

Not typically seen with ASPSuite.

Q4 – Quality Level 4 –DGPS Solution

Not typically seen with ASPSuite.

Q5 – Quality Level 5 –Single Solution

During GNSS processing ASPSuite is trying to use both the base station observations and the rover observations to achieve an accurate position for the rover. If, for any reason, RTKLib is able to use observations from only the rover (hence the name “single”), it will give Q=5.

Probable Resolution#1:

The base station observation data is not entered. This is commonly done to field check the rover observations while awaiting the higher quality ephemeris for processing the final solution. If that wasn’t the intention, verify the base station settings, Edit Flight -> Base station tab.

Probable Resolution#2:

The base station observation and rover observation are not recorded over coincident periods of time. Commonly occurs when the user selects the wrong base station file for the flight. The RINEX files used in processing are ASCII text files. Open the observation (*.??O) file for both the rover and base station in a text editor. Review the lines ending in “TIME OF FIRST OBS” and “TIME OF LAST OBS” found in the header of each file. The format is “Year Month Day Hour(24hr) Minutes Seconds” GPS. For example:

Verify the observations overlap. Note the base station should start before, and end after the rover observation file.

Probable Resolution#3:

Verify the base station coordinate is entered in the correct format. A base station coordinate located far away from the observations, such as swapping lat/lon or having the wrong sign (north latitudes and east longitudes are positive) can result in no data being used.