DPOS vs OPUS Discrepancy

Good morning,

I have a base point that I have observed in the past (January 2018) and DPOS agreed quite nicely with OPUS results when processed. I have recently re-observed this point last week and am getting substantially different results in DPOS, mostly in height. From last week I had a session just under two hours and a session over 4 hours long. I just processed the four hour session through OPUS and it agrees with the January observation by 0.07' vertically, I don't have any reason to believe the control point has been disturbed. Have there been changes made to DPOS recently? Can someone take a look at this static data and see why there is such a discrepancy?

The two jps files from last week are 11mb and 24mb, it says they are too large to attach, how can I share them?

I ran all of these through OPUS, the worst discrepancy is vertical between 100 & 101, 34mm=0.11'.

Ran through DPOS, the worst discrepancy is vertical between 100 & 101, 271mm=0.89'.

Somethin ain't right here...
I too am seeing a large difference, I used the NCRTN to get a Point for a base point. When DPOS reduced the gnss base file (83 min), it differs from the NCRTN coordinate by 0.77' vertically. Normally the NCRTN and the DPOS are within a few hundredths. Glad you guys are checking into this.

Matthew D. Sibole

Well-Known Member
I just submitted a file from yesterday to OPUS and the same file through DPOS. The base coordinate was initially determined by a VRS solution on a nail.

VRS Solution
N 3725652.478
E 4701726.852
Elev. 691.943

N 3725652.467
E 4701726.837
Elev. 692.044

N 3725652.5290
E 4701726.8600
Elev. 692.085

The difference between the DPOS derived coordinate is 0.0657' in horizontal and 0.04 in vertical.

I always get the extended output and it specifies the network accuracy of
Horizontal network accuracy = 0.00521 meters. = 0.017'
Vertical network accuracy = 0.00628 meters. = 0.020'

So at least in my area DPOS and OPUS are giving very good results!

I should note that the base was a Triumph LS.
Good to hear and I normally get DPOS results that match up well with OPUS, but my sessions posted above don't jive at all. I will be curious to hear what Alexey has to say.

Alexey Razumovsky

Well-Known Member
Staff member
Yes, Joe!
We have invetigated the problem very closely since the date you have posted it.
A half hour ago we have redeployed Justin engine on DPOS.

An unexpected behavior of ephemeris may causes not accurate results in post-processing with CORS(in heights mostly).
Some ephemeris are coming to Justin project from JAVAD jps . They are correct.
If Interenet ephemeris have been imported after jps data they may overwrite first one. We found that we had wrong understanding of "accuracy" parameter in RINEX nav files. About 2 month ago we have switched from NASA ftp to CORS. At NASA site ephemeris have healthy/unhealthy tag. It's was clear and we had no problems. At CORS ftp ephemeris have "accuracy" number also. Shortly, not accurate ephemeris were used.
Thanks. to your post we have canceled this..

Alexey Razumovsky

Well-Known Member
Staff member

We saw that during last 2 weeks NGS guys updated several times RINEX obs and nav files on ftp for our CORS. Not only numbers but a data structure as well. They removed suspicious ephemeris.