Unusual DPOS Results

Aaron S

Active Member
Attached are DPOS reports for 3 separate observations I did. Each was 20-30 minutes long. The results I got back are of unusually poor precision. I can't figure out where the problem lies other than one of the RTN stations. Is there something else going on, and can I fix it?
 

Attachments

  • 233_110814.jps.txt
    3 KB · Views: 410
  • 237_123913.jps.txt
    3 KB · Views: 425
  • 238_131312.jps.txt
    3 KB · Views: 407

Matt Johnson

Well-Known Member
5PLS
Are these points in the open or under tree canopy? Alexey would need the raw data files to investigate the results.
 

Aaron S

Active Member
The points were in trees, but all the leaves were off at the time (I've got good fixed solutions from points in worse canopy during this timeframe). One of these static points I got good RTK fixes on, and I was processing the static as a check. The others were situations where I got out there and didn't have cell service. #233 Was too large to upload.
 

Attachments

  • 237_123913.jps
    1.9 MB · Views: 363
  • 238_131312.jps
    1.8 MB · Views: 368

Matt Johnson

Well-Known Member
5PLS
Good results are not usually obtained in areas of multipath with long baselines from CORS stations. Why not use Base-Rover DPOS processing? This is the best way to check the results. How far away was your RTK base station or were you connecting to a RTN?
 

Adam

Well-Known Member
5PLS
From my experience in a state with abundant Cors, rover to Cors processing takes a lot of time. I really never use it. Base to Rover is a much better solution.
 

Alexey Razumovsky

Well-Known Member
JAVAD GNSS
5PLS
Hi Aaron, I reprocessed 238_131312.jps 237_123913.jps. Both points 237 and 238 were in the wood. Screenshats attached. I understand that leaves gone away now but anyway sats tracking was pure. Longest period of continuously sat tracking time does not exceed 4 minutes. Total observation time was 20 minites. Good fixed solutions deals only three stations : MNBJ(41.2 km away), MNSQ(51.1 km away), MNRE(52.3 km away). Stations MNGP(80.0 km away), MNEM (76.4 km away) deal float solutions. As a result we have got big overall rms value in network adjustment with all five solutions. Two last float solutions do not match good first 3 fixed solutions. In the case like this RTK deals more reliable result due to it uses only ONE CLOSEST STATION. I do not recomment to pratique ROVER to CORS DPOS processing when one stay at a point less then one hour. Usually 5 closest CORS are in a range of 100 km. So we need one hour observation for reliable CORS processing in DPOS. I'd like to emphasize one more time that DPOS grabs data from 5 closest CORS, run process and adjustment.
Recomendations.
1. Download your DPOS project from web service, look into project with our free Justin Link software. Inspect solutions and find suspicious CORS. Resubmit files to DPOS once more with CORS exclude list.
2. Follow Adam and look at own base - rover DPOS post processing stage when you stay at a point during short time.
 

Attachments

  • point238.png
    point238.png
    575.1 KB · Views: 370
  • point237.png
    point237.png
    430.9 KB · Views: 376

Aaron S

Active Member
Thanks for all the input. I have been doing it this way in similar conditions for several weeks now, and all my DPOS reports have come back with typical overall RMS values of less than 1 cm using the same method (20-30 minute sessions). I thought this was pretty good results so I kept doing it this way. It was just on the last day that it didn't work.
 

Aaron S

Active Member
Good results are not usually obtained in areas of multipath with long baselines from CORS stations. Why not use Base-Rover DPOS processing? This is the best way to check the results. How far away was your RTK base station or were you connecting to a RTN?

I hadn't been thinking of setting up a base because I'd been thinking in terms of maintaining a radio connection. The project area is 6 miles long and the points are at least 1/4 mile apart, so I was anticipating having to move the base/radio every couple points.

But I suppose I don't strictly need the radio link in the first place if I'm doing DPOS with base-rover pairs? What is the maximum recommended length for base-rover vectors in this case?
 

Alexey Razumovsky

Well-Known Member
JAVAD GNSS
5PLS
OPUS aborted solution for p.237 and it deals "NORMALIZED RMS: 0.446" for p.238. DPOS solution for p.238 is OK. I checked it with GrafNav software.
 

Alexey Razumovsky

Well-Known Member
JAVAD GNSS
5PLS
I hadn't been thinking of setting up a base because I'd been thinking in terms of maintaining a radio connection. The project area is 6 miles long and the points are at least 1/4 mile apart, so I was anticipating having to move the base/radio every couple points.

But I suppose I don't strictly need the radio link in the first place if I'm doing DPOS with base-rover pairs? What is the maximum recommended length for base-rover vectors in this case?
It does not exceed 6 miles. At the over distance iono impact overcomes multipath impact. It's difficult to separate them.
After getting located sats it's enough 3-5 data epochs to get good fix in the open in a range of 3 miles from base. Fixing under canopy depends on surveyor's experience. Am I right, Shawn?
 

Shawn Billings

Shawn Billings
5PLS
One of the many things I like about DPOS over OPUS is the report of Residuals of Position. This information is not included in OPUS reports.

For point 233, we see that MNBJ and MNGP are outliers from the other vectors.

233 RESIDUALS OF POSITION
VECTOR dX,m dY,m dZ,m dN,m dE,m dU,m
MNBJ - 233 0.129 0.386 -0.122 0.207 0.098 -0.358
MNEM - 233 0.016 -0.095 0.000 -0.069 0.024 0.064
MNGP - 233 -0.271 0.140 0.174 0.205 -0.281 0.048
MNRE - 233 0.016 -0.109 0.023 -0.063 0.024 0.090
MNSQ - 233 0.007 -0.109 0.000 -0.079 0.016 0.074


For point 237, we see that MNGP is an outlier.

237 RESIDUALS OF POSITION
VECTOR dX,m dY,m dZ,m dN,m dE,m dU,m
MNBJ - 237 0.020 0.037 -0.008 0.023 0.017 -0.032
MNEM - 237 0.025 0.039 -0.015 0.020 0.022 -0.039
MNGP - 237 -0.174 -0.287 -0.122 -0.303 -0.151 0.114
MNRE - 237 -0.010 0.038 0.117 0.107 -0.013 0.061
MNSQ - 237 0.025 0.021 0.015 0.027 0.023 -0.005

There is less consensus for point 238. MNRE looks good horizontally but is poor vertically.

238 RESIDUALS OF POSITION
VECTOR dX,m dY,m dZ,m dN,m dE,m dU,m
MNBJ - 238 -0.062 0.321 -0.293 0.033 -0.087 -0.429
MNEM - 238 0.047 -0.062 0.146 0.056 0.052 0.147
MNGP - 238 -0.156 -0.254 0.067 -0.150 -0.135 0.229
MNRE - 238 0.030 0.316 -0.327 0.011 0.005 -0.455
MNSQ - 238 0.043 -0.077 0.128 0.033 0.048 0.144

I need to work with Justin Link to see how to exclude vectors from DPOS.
 

Shawn Billings

Shawn Billings
5PLS
It may be good, Alexey, to add the actual vectors and covariance matrix for the vectors in the report. This way, a sophisticated user could bring the vectors into a least squares adjustment software and include or exclude them.
 

Alexey Razumovsky

Well-Known Member
JAVAD GNSS
5PLS
One of the many things I like about DPOS over OPUS is the report of Residuals of Position. This information is not included in OPUS reports.

For point 233, we see that MNBJ and MNGP are outliers from the other vectors.

233 RESIDUALS OF POSITION
VECTOR dX,m dY,m dZ,m dN,m dE,m dU,m
MNBJ - 233 0.129 0.386 -0.122 0.207 0.098 -0.358
MNEM - 233 0.016 -0.095 0.000 -0.069 0.024 0.064
MNGP - 233 -0.271 0.140 0.174 0.205 -0.281 0.048
MNRE - 233 0.016 -0.109 0.023 -0.063 0.024 0.090
MNSQ - 233 0.007 -0.109 0.000 -0.079 0.016 0.074


For point 237, we see that MNGP is an outlier.

237 RESIDUALS OF POSITION
VECTOR dX,m dY,m dZ,m dN,m dE,m dU,m
MNBJ - 237 0.020 0.037 -0.008 0.023 0.017 -0.032
MNEM - 237 0.025 0.039 -0.015 0.020 0.022 -0.039
MNGP - 237 -0.174 -0.287 -0.122 -0.303 -0.151 0.114
MNRE - 237 -0.010 0.038 0.117 0.107 -0.013 0.061
MNSQ - 237 0.025 0.021 0.015 0.027 0.023 -0.005

There is less consensus for point 238. MNRE looks good horizontally but is poor vertically.

238 RESIDUALS OF POSITION
VECTOR dX,m dY,m dZ,m dN,m dE,m dU,m
MNBJ - 238 -0.062 0.321 -0.293 0.033 -0.087 -0.429
MNEM - 238 0.047 -0.062 0.146 0.056 0.052 0.147
MNGP - 238 -0.156 -0.254 0.067 -0.150 -0.135 0.229
MNRE - 238 0.030 0.316 -0.327 0.011 0.005 -0.455
MNSQ - 238 0.043 -0.077 0.128 0.033 0.048 0.144

I need to work with Justin Link to see how to exclude vectors from DPOS.
Thanks to Matt Johnson we have "Residuals of Position"
 

Shawn Billings

Shawn Billings
5PLS
Actually, Aaron, I'm surprised and impressed that you are getting such good results in inclement environments with such short observation times using DPOS. CORS density makes a big difference. This makes it difficult to pin down a recommended minimum occupation time for DPOS CORS solutions.

I've had very good success with DPOS base-rover. When relying on DPOS alone for a position of a point under canopy, I recommend always performing repeat observations so that the solution can be verified. In most instances DPOS can acquire a good solution in the same amount of time that RTK can perform a verified position in canopy (between 3-30 minutes depending on canopy). In the open, as Alexey mentions, only a few epochs are needed. I've had good success with 10 second observations at 1 mile. I've had success on a 2.5 mile vector with only six epochs. And I've tested DPOS base-rover solutions at 9 miles with a six minute observation with good success.

Unless J-Field now allows it (and it might with some of the new features added by @Michael Stazhkov) you cannot do real time from your RTN and later perform base-rover from your own base. This may have changed though. I'd be interested to find out myself.
 

Shawn Billings

Shawn Billings
5PLS
Excluding stations is a great feature when you know there is a problematic CORS, however, I'm speaking about excluding a vector from a solution. If you exclude a station, I suspect DPOS will replace it with another station, perhaps further away with even poorer results in this example. If we could exclude a vector and readjust, we might be able to refine our results. The operator would need to be careful not to exclude too much of course.
 

Phillip Lancaster

Active Member
I hadn't been thinking of setting up a base because I'd been thinking in terms of maintaining a radio connection. The project area is 6 miles long and the points are at least 1/4 mile apart, so I was anticipating having to move the base/radio every couple points.

But I suppose I don't strictly need the radio link in the first place if I'm doing DPOS with base-rover pairs? What is the maximum recommended length for base-rover vectors in this case?

I has to be better than using a CORS 50+km away. You need to throw the radios in the truck and jump on cell. Longer baseline RTK with DPOS.
 

Aaron S

Active Member
Here's a DPOS report that's typical of the results I've been getting using similar occupation times and multipath/canopy conditions. It's generally pretty good, isn't it? Or have I been misinterpreting the results?
 

Attachments

  • 224_135756.jps.txt
    3 KB · Views: 408
Top