PDOP and Estimated accuracy

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

1 Like

Here is a good starting point: https://www.e-education.psu.edu/geog862/node/1771

3 Likes

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.

1 Like

@wizprod : Thanks for that link, I knew DOP had something to do with the ‘position of the stars’ :slight_smile: . 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? (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 :slight_smile: )

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 :slight_smile: )

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

1 Like

Hi Andy,

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

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.

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.

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.

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)

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?

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.

1 Like

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.