PDOP and Estimated accuracy

[abertier (Andy Bertier)]

I’ve got 2 questions related to the Status-screen of the new ReachView V3, we can see the PDOP and Estimated accuracy.

1. Is it possible to get this data somewhere in the position-output stream?
2. How is the estimated accuracy calculated? or how ‘accurate’ is this number?

It would be useful if I could receive this data in my own application.

Thanks

[wizprod (Christian Grüner)]

@abertier

How is the estimated accuracy calculated? or how ‘accurate’ is this number?

Here is a good starting point: The Space Segment: Dilution of Precision | GEOG 862: GPS and GNSS for Geospatial Professionals

[artem.fomenko]

Hi Andy,

This feature is not implemented in ReachView 3. May I ask you to elaborate on why this data is needed for your use-case? Your feature request will be noted.

The article shared by Christian could be of help regarding the estimated accuracy calculation.

[abertier (Andy Bertier)]

@wizprod : Thanks for that link, I knew DOP had something to do with the ‘position of the stars’ . But this link makes it more concrete/understandable. I’ll check some of the other articles as well, seems a ‘simple’ but good source of information.

@artem.fomenko : A RS2 is used to measure the ‘working height’ of the equipment. The user reported he experienced a couple of cases where the the system was still providing a ‘Fixed’ solution, but the height-information was incorrect. Unfortunately I don’t have any data/logs, so I cannot provide additional context of these issues. But it might be related to Cycle slips? or not? - #24 by abertier (I’m planning a trip to the user beginning next year, so hopefully I can capture some logs for this issue)

Anyways, since the working conditions for my application are not optimal most of the time, it would be valuable to give the user some additional information how reliable/accurate the given data is. So he knows when to trust the given height. (probably the same reason why it’s on the status page of RV3 )

when the DOP is calculated, is it based on all satellites which pass the mask/snr-threshold? I guess cycle slips don’t affect DOP, but are messing with the measurements, and depending on how ‘strong’ the solution was, it will impact the position and/or accuracy. Is this correct? (currently checking out the chapter on cycle slips on the link @wizprod provided )

about the accuracy in meters (not DOP), where does this come from? is it based on remaining errors while calculating a solution?

[polina.buriak]

Hi Andy,

Sorry for the time it took to get back to you. Let me comment on each issue below.

@abertier

The user reported he experienced a couple of cases where the the system was still providing a ‘Fixed’ solution, but the height-information was incorrect.

It’s strange that the user experienced such behavior of the Reach receiver. It should not perform this way. Depending on the baseline and the environmental conditions, there may be difficulties with calculating the Fix solution. However, you can trust what you see in the ReachView App as our receivers are capable of providing a reliable solution in the appropriate environmental conditions.

It’d be great to investigate why this happened. If you had a chance of collecting the position log, the raw data log, and the base correction log, please, share them with us at support@emlid.com or here. This will allow us to check the observational quality of the data, the solution status during the survey and determine if the configurations are correct.

@abertier

when the DOP is calculated, is it based on all satellites which pass the mask/snr-threshold? I guess cycle slips don’t affect DOP, but are messing with the measurements, and depending on how ‘strong’ the solution was, it will impact the position and/or accuracy. Is this correct? (currently checking out the chapter on cycle slips on the link @wizprod provided )

The DOP factor shows the configuration of the satellites in the sky. Based on that, it’s possible to assess if the sky geometry works on your side during the survey.

Strictly speaking, high PDOP indicates the increased uncertainty of the GPS position which is not the same as the incorrect accuracy estimation. The relation between the DOP factor and accuracy is somewhat difficult and non-linear. That’s why it might be difficult to draw specific results from the DOP data on-site.

So, as DOP is still used in accuracy calculations on Reach receivers, it’s easier to assess the conditions with the check of the estimated accuracy. As these parameters are connected, there can’t be a good accuracy with high DOP factors.

However, if you require PDOP information specifically, it’s possible to get it both from the ReachView 3 Status tab and in the position output of the NMEA GSA message. Usually, values lower than 2 are considered a good PDOP.

@abertier

about the accuracy in meters (not DOP), where does this come from? is it based on remaining errors while calculating a solution?

We use RMS for the accuracy estimation in the Status tab: the square root of the average of the squared error. It’s calculated from the error computed relative to a continuously updated average position at the Survey point.

[abertier (Andy Bertier)]

@polina.buriak

It’d be great to investigate why this happened. If you had a chance of collecting the position log, the raw data log, and the base correction log, please, share them with us at support@emlid.com or here. This will allow us to check the observational quality of the data, the solution status during the survey and determine if the configurations are correct.

Continuous logging is enabled, but user issue-reports are sometimes vague. But I’ll try to submit the logs when I encounter a strange situation. (but as you can see from some of my other posts, during a lot of jobs, signal quality is not optimal due to environmental obstructions)

@polina.buriak

We use RMS for the accuracy estimation in the Status tab: the square root of the average of the squared error. It’s calculated from the error computed relative to a continuously updated average position at the Survey point.

So this accuracy (on the status tab, not during point collection) is only relevant when ‘stationary’?
I’m currently processing an LLH-output-stream of RS2. And I’m checking the stdev error in that stream. I this also trustworthy value?

[polina.buriak]

Hi Andy,

Let me explain the accuracy measurements a bit.

We use two methods of accuracy estimation: the first one, where we have a finite set of values, and the second one, where the position is continuously updating.

In case of real-time work, when the position is continuously updating, we can compare values with the theoretical prediction only. This is what you see in the Status tab and in the LLH logs.

With a finite dataset, roughly speaking, we calculate the average from this set, then compare each member of this set with this average. This is the accuracy you see in the Survey tab while collecting a point.

Please note that the ReachView app and RTKLib calculate the accuracy in a different way so the direct comparison between them is not strictly correct.