I have never done this before so apologies up front if I didn’t do it right. I am trying to establish a base point using PPK with my RS2 and our DOT published Rinex. Here is a link to the data I have.
Thank you!
Here are my RTKPOST Settings. I really only need the horizontal as I am going to shoot in my GCP’s and apply my leveled elevations.
Looks good to me. What is your baseline? There a few pointers that could be made, knowing the baseline.
It was 11 miles. Like I said, I have never tried going off our DOT logs before so I don’t know what to expect. Here’s what the plot looked like. A 0.3m spread? Including the outliers it was 0.75m.
Are the values at the top right the solution? When I visually pick the center of the mass I get very close to that…
This is what I got from the 30 minute average.
I’m also curious how to do this but I’m in Canada.
You just open those logs and average the main mass in the middle? I use a dit monument for a project I’m regularly working on by sometimes it seems like my staking at a later date is off by a foot or two which makes me wonder if my initial 30min average was long enough to establish the base monument position.
Are you averaging the first occupation and then manually entering the coordinate when you return?
The Q=5 means you have a single solution, sure you have the base rinex entered?
Well I used the OBS file, but wasn’t sure which NAV file to use. Base, rover or both? I used the rover.
Something went wrong as your processing window shows everything as quality 5 meaning autonomous or no corrections.
Maybe your base station files aren’t specified correctly. Use a wildcard character like TXTA322?.20O and RTKLIB will grab TXTA322O.20O and TXTA322P.20O
or copy them in a DOS window: copy TXTA322?.20O BASE.20O
and the file BASE.20O will work
Anyway I did a quick processing of the data. First check the base coordinates. The RINEX header values are quite close to the latest published values though not exact:
TXTA RINEX header coords: 30 33 51.19370 -97 26 42.11575 149.003
latest published 30 33 51.19370 -97 26 42.11582 149.028 NAD83(2011[epoch 2010.0]) [MYCS2]
Using the latest published coordinates with settings quite similar to yours though not exact I get a solution:
GPS+GLONASS fixed: 30 32 21.6296 -97 38 02.5314 190.725 (HAE meters)
30.539341558 -97.634036495
I know you are going to use leveled heights, but just as a rough check the GEIOD18 value here is -25.974 so a rough NAVD88 height assuming a 2.0 meter pole would be 190.725+25.974 = 216.699 meters; ~ 711 feet
Tomorrow once the rapid orbits come out a check could be made with the CSRS PPP service and maybe OPUS RS.
1 Like
Thanks for this J. I don’t quite understand the wildcard workflow. Do I do that in RTKLIB or actually change the names of the files? I can obviously see the files have been pulled in and have never had to do anything like that before so I’m a little daft.
So what’s shown in the image above is just all of the shots from the rover over that period? What about the values at the top right. What do they mean. I have done allot of drone PPK, but this is a little different. 
Am I seeing this right that your observation file for the base runs from 14:00 to 15:00 while your rover runs from 15:05 to 16:14?
edit
Ah, there are two .20O files for the base, make sure you use the second one, then I had no trouble getting Q=1 for 99.1% of observations
2 Likes
Yes! So I got confused on time because we just switched from the dumb USA daylight savings time… This is what I have now. I guess I need to find out what they are actually transmitting.
1 Like
Always think in terms of UTC…this from doing hundreds of astro-observations for azimuth and position from 70’s-90’s. All my house and office time devices are set this way. My wife even has gotten use to it ! Also don’t have to reset clocks except for your body.
4 Likes
What mapping system and ground are you expecting this in?
Yes, the basestation files were one hour off. You needed the “P” and “Q” files, and not the earlier “O” file.
There is a “User Friendly” CORS which might help
https://www.ngs.noaa.gov/UFCORS/
I did send off the rover file to the CSRS PPP service and by accident got back NAD83(CSRS) horizontal coordinates which just happened to match those I posted earlier to better than a centimeter. That was just luck. Doing it again with ITRF coordinates and converting to NAD83(2011) with HTDP did match at the couple cm level.
While what I did above might not be perfect the CSRS PPP result shows the solution is in the right ball park and you should be getting something close - within a few centimeters. If not, we can figure out what’s going wrong.
I did try OPUS RS, but it wouldn’t process the data.
I also get roughly this number (.721) using the data-provided. I had to re-process the RS2 obs from the UBX for some odds reason.
Then I tried using 9 CORS/2010 stations in EzSurv, but it seems there are different Base coordinates on these, as there is a 1.6 meter 3D offset from your provided data (TXTA) to the one I can get with the CORS-station (189.506 meter elipsoid).
Coordinate system? NAD83 (2011) TX-C (ftUS). Elevations are ground leveled from 3rd generation NGS benchmarks. Everything ends up localized of course. I can’t tell you the BS to go through to find out how they got there. I just wanted to make sure they weren’t off somebody’s porch.
1 Like
