GNSS Quality Levels Explained

Introduction

LP360 Drone:

At the end of the Post Processing Wizard in LP360 Drone, formerly TrueView EVO, 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 Post Processing Trajectory Plot button on the Sensor tab of the LP360 ribbon (formerly on the TrueView Utilities toolbar), or when you run Complete Job from the Job Manager.

ASPSuite:

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.

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

In LP360 Drone, formerly, TrueView EVO, users may encounter an error message, “An error occurred scanning POS file” at the completion of the Post Processing Wizard.

In ASPSuite, users may encounter an error message, "Compute GNSS Trajectory FAILED!". The pos file is empty if there is no GNSS solution computed.

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: https://support.geocue.com/error-rover-position-file-pos-empty

This can also happen if the ephemeris file is for the wrong date.  If manually downloading ephemeris files, check to be sure you have selected the ephemeris file that corresponds to the flight date.  See the following post for manually downloading ephemeris files: https://support.geocue.com/ephemeris-navigation-data-files

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. The same problem can occur if you try to process data using an orthometric elevation for the base station coordinate instead of using the ellipsoidal elevation.

Probable Resolution#3:

The base station Rinex file contains observations at the beginning and end of the file, but the observations in the middle (during the time period of the flight) are not in the file. This has happened when the internal storage of the base station was full, so the data began storing on the data collector via Bluetooth. When the surveyors traveled beyond the reach of the Bluetooth connection, the data was lost.  When they came back to retrieve the base station, the data began storing again and this caused the file to appear normal when viewing the start and stop times.  However, the static data for the time period of the flight was not contained in the file, hence, the corrections for the flight could not be calculated.

Probable Resolution#4:

Sometimes one or more of the GLONASS satellites is having a problem or has bad ephemeris information causing the whole solution to fail. You may be able to see this by using the diagnostics tools to review the base vs rover information. To resolve, try using GPS only when doing the auto-download of the ephemeris file. Then, process with the GPS only ephemeris rather than the mixed ephemeris and see if the same issue is encountered.

Probable Resolution#5:

Check for gaps in the Loki rover and base station observations files. 

Probable Resolution#6:

Verify the version of the base RINEX file is supported. Currently, RINEX version 2.10, 2.11, 2.12, 3.00 through 3.02.

Q1 - Quality Level 1 - Fixed Solution

This is the desired quality level for all epochs to achieve the highest quality position solution.  Q1 is represented by a green trajectory and events.

Q2 - Quality Level 2 - Float Solution

Q2 can be caused by a bad or noisy satellite.  Q2 is represented by a yellow trajectory and events.

Probable Resolution#1:

Achieving accurate positioning data with PPK requires capturing sufficient GNSS data points during the flight. The exact duration and distance required will depend on various factors such as the GNSS receiver used, the quality of the reference station data, and the flying environment. Generally, it is recommended to fly for a minimum of ten minutes to capture enough GNSS data points for accurate PPK processing.

Probable Resolution#2:

Raise the elevation mask from the default 15° to remove satellites that are low to the horizon from being used in the solution. In LP360 Drone -> Post Processing Wizard or ASPSuite, select on the Tools tab -> Edit flight -> Processing tab, and adjust the Elevation Mask and SNR Mask.

An approach whenever you get a float solution:

• First check the number of satellites. If there are several of them, for example 10 satellites, you know that you can raise elevation mask and SNR mask. If you see the number of satellite too small, e.g. ~ 4 or 5, then check the signal’s SNR.
• The numbers that we usually start with for debugging is 20 for the elevation mask and 35 for SNR mask.
• If it still gives a float solution, increase the elevation mask again to 25. If it gets a fixed solution, then check the number of satellites and see that it’s greater than 4 or 5.  To minimize the chance of having a limited number of satellites, plan your flight during optimum dilution of precision times using a GNSS planner such as Trimble's online GNSS planning tool.
• For the SNR mask, you can increase it in a similar fashion to 45, etc.

Probable Resolution#3:

The Convert RINEX option (LP360 Drone -> Post Processing Wizard or 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#4:

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 LP360 Drone or ASPSuite.

Q4 - Quality Level 4 - DGPS Solution

Not typically seen with LP360 Drone or ASPSuite.

Q5 - Quality Level 5 - Single Solution

During GNSS processing LP360 Drone or 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:

2017 9 19 14 32 38.2000000 GPS TIME OF FIRST OBS
2017 9 19 14 48 35.4000000 GPS TIME OF LAST OBS

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.

 Q6 - Quality Level 6 - PPP Solution

Not currently implemented in LP360 Drone or ASPSuite.