PPK Solutions vs RTK solutions - vertical bust

Joe Paulin

Well-Known Member
I have a project that I just put through DPOS processing and noticed something odd. I have two days of data so far - looking at the results of the second day (points17 and higher) I noticed that heights of the PPK solutions were consistently 0.2'-0.3' higher than the rtk solutions while the horizontal coordinated agreed quite well. I know vertical will vary more than horizontal, but I haven't seen this before where they were almost all higher by 0.2'-0.3'. Could someone take a look and let me know what you think? It's project 20002 Chronister, LS serial number 397, sending the project to support right now.

Thanks!
 

Adam

Well-Known Member
5PLS
Are you certain the base height is correct for day 2? If there is an incorrect base height ppk will be different than the rtk. I bet the ppk is correct.
 

Joe Paulin

Well-Known Member
I just checked in the data, both days the base has the same height above the mark. I use a 2m rod with tripod, so I can't screw that up. With adapter it would be 2.025m, which is what JField has for both days. Just so I am clear, I am not comparing day 1 to day 2. I just saw the issue with day 2 data, rtk vs ppk solutions. Something is going on because when I go to the sigma page in the point details, the base elevation is listed different in the rtk solution vs the ppk solution.
 

Adam

Well-Known Member
5PLS
The reason I ask is because the ppk solution uses the vector from the apc of the base to the apc of the rover then applies the rover antenna height. The base antenna height isn't part of the equation. For rtk it is. Because of this the ppk solution is a check on the base antenna height when compared to the rtk. Ppk will tell you if you had a wrong base antenna height. Any chance you didn't get the rod all the way up? Or did the point possibly move vertically?

It's been a while since I tested this but when we were working on LS as a base I noticed this.
 

Joe Paulin

Well-Known Member
It's a fixed height rod, so it is what it is: 2M. It is possible that the nail moved slightly, but not the amount that I am seeing, say 0.25'. That much change would have been obvious. It appears that the rover ppk solutions are using the base point dpos static session coordinates to compute a solution instead of the known coordinates (which I have selected to control) as the base coordinates. Why else would the base coordinates show up as different values on the sigma pages when comparing the rtk and ppk coordinates?
 

Steve Douty

Well-Known Member
It's a fixed height rod, so it is what it is: 2M. It is possible that the nail moved slightly, but not the amount that I am seeing, say 0.25'. That much change would have been obvious. It appears that the rover ppk solutions are using the base point dpos static session coordinates to compute a solution instead of the known coordinates (which I have selected to control) as the base coordinates. Why else would the base coordinates show up as different values on the sigma pages when comparing the rtk and ppk coordinates?
With the fixed height rods that I own; the fixed height is to the top of the rod. With all JAVAD equipment the height is considerable more because of the necessary adapters for thread differences. I would suggest that you physically measure the height.
 

pappassurveyor

Member
5PLS
Is it possible that you used the CORS/DPOS derived position one of the days instead of your know base point coordinates(or vice-versa). I have seen a shift when using old control form another iteration of state plane and GEOID models.
 
Top