8 Mile RTK vector Accuracy

Is 300 epochs your ordinary occupation time? Have you tried shorter durations? I'm thinking 30 epochs or less.

What were the PDOP & multipath conditions like?

I'm starting at 300 to see what I can do and I'll reduce from there. I'm not fond of 30 for control even on short vectors but it's really just based on anecdotal experience. I want to develop some more concrete occupation times.

Points L002, L003 and L004 were very open. L001 was obstructed with tree drip line straight overhead to the north. A power pole about 3 or 4 feet south. Not horrible but realistic.

30 may or may not work out, but I think that the sweet spot will be closer to that than 300 - if the PDOP is under 3. But I don't have any real data on that. Hoping to get some one of these days.

> I observed four points for 300 epochs each from my Triumph-2 base broadcasting 8 miles away over the internet (all coordinates are US Survey Feet):
> N E U
> L001 043.002 165.892 428.292
> L002 020.146 222.194 426.938
> L003 970.653 367.655 421.018
> L004 018.524 825.066 405.828
>
> I then set a base receiver broadcasting UHF on point L003, holding the coordinates from the 8 mile vector for the base coordinates, and I observed L002 and L004 a second time as L002_2 and L004_2. For these observations, I observed for only 120 epochs.

Do you have have the RTK processor estimates of the uncertainties of those coordinates you listed for L001 through L004? Were they on the order of about +/-0.05 ft. as in the results you reported the other day?

Kent,
L001 0.057 0.047 0.080
L002 0.045 0.042 0.048
L003 0.044 0.043 0.049
L004 0.063 0.057 0.052
All are relative to the base 43300 feet away.

L002_2 0.038 0.016 0.068
L004_2 0.037 0.012 0.036
Relative to L003. L002_2 is 153.6' from base, L004_2 is 459.9' from base.

All are 95%. Semi major, semi minor, height.

Short answer: yes, very similar to the last test.

Shawn, If You Have A Few More Minutes With RTK

With good clean data you can get an OPUS-RS position with a 7.5 minute file.

Of course with such a short file it is possible to fall into a PDOP gap.

Test those extra short files yourself. I would not recommend them to a novice, but on some days a planned longer file just never gets going as well as you planned.

Paul in PA

> Kent,
> L001 0.057 0.047 0.080
> L002 0.045 0.042 0.048
> L003 0.044 0.043 0.049
> L004 0.063 0.057 0.052
> All are relative to the base 43300 feet away.
>
> L002_2 0.038 0.016 0.068
> L004_2 0.037 0.012 0.036
> Relative to L003. L002_2 is 153.6' from base, L004_2 is 459.9' from base.
>
> All are 95%. Semi major, semi minor, height.
>
> Short answer: yes, very similar to the last test.

So, in other words the RTK controller estimated that there was a 68% chance that errors in the N and E values of the coordinates as reported were both less than about 0.02 ft. (6mm).

The controller only provides horizontal rms, but it's consistent with the 2.4 scalar, from what I can tell.

For L001, L002, L003 and L004 from 8 miles...
HRMS:
0.030
0.025
0.025
0.035

VRMS:
0.041
0.024
0.025
0.026

> The controller only provides horizontal rms, but it's consistent with the 2.4 scalar, from what I can tell.
>
> For L001, L002, L003 and L004 from 8 miles...
> HRMS:
> 0.030
> 0.025
> 0.025
> 0.035
>
> VRMS:
> 0.041
> 0.024
> 0.025
> 0.026

So, where did the 95%-confidence errors ellipses come from if the controller doesn't generate them?

If I were testing that equipment, one hypothesis I'd be interested in is whether the uncertainty estimates for the horizontal components are similar to those of the height component. That is, if the controller says +/-0.03 ft. s.e. and in reality the results are more than +/-0.06 ft. s.e., I'd wonder if the horizontal uncertainties aren't underestimated by a similar factor.

I do think that testing the equipment in a variety of environments with obstructions or multipath sources similar to those that you'd consider to be feasible to occupy in the course of a survey is a good idea. A better way to test the RTK accuracy would be against some coordinates of known high accuracy, as you could get by a combination of static GPS vectors and total station measurements. The static GPS vectors from the station occupied by the base would provide a fairly definitive means of checking the scale of the RTK vectors since you'd have the option of processing them with the best possible ephemerides.

It only generates individual NEU at 95%. At 68% is provides 2D, H and 3D values, but not N and E.

> It only generates individual NEU at 95%. At 68% is provides 2D, H and 3D values, but not N and E.

If it is generating estimated semi-major and semi-minor axes of 95%-confidence error ellipses, those would be estimates of positional uncertainty, not so much of uncertainty in N and E components although the two are directly related, of course.

You can see, I think, why I tend to focus so much on whether the uncertainty estimates the RTK controller generates are realistic or not (and why importing the actual vectors and their uncertainties into an adjustment is such a great way of doing things).

Yes. You are correct. I misspoke regarding NEU, semi-major and semi-minor are what I had in mind. Thank you.

I agree regarding vectors. At some point I intend to develop a serious test. Right now I'm trying to understand what is even possible, or what the question is. Presently I'm pleasantly surprised by what I am seeing.

You aren't the only one to think this way. Carlson has included in the later versions of SurvCE an ability to analyze multiple vectors stored for a single point (in the field on the DC). I believe they claim a least squares balancing, but I am not sure how the software handles it. (The documentation is pretty basic.)

Of course, adding the vectors to StarNet would be the gold standard of least squares.

I am not sure what techniques would be best for using this capability. I would assume a break in fixed status and a break in time would be best (that is what I do).

If you simply used say 100 epochs, and did that three times in a row, I am not sure what you would gain over simply running 300 epochs.

(This is all RTK, of course.)

> Of course, adding the vectors to StarNet would be the gold standard of least squares.
>
> I am not sure what techniques would be best for using this capability. I would assume a break in fixed status and a break in time would be best (that is what I do).
>
> If you simply used say 100 epochs, and did that three times in a row, I am not sure what you would gain over simply running 300 epochs.

Well the contributing unknowns for single-base RTK would include the broadcast orbits and the differences in state of ionosphere and troposphere as the separations between base and rover increase. Eight miles is a significant separation. 500 ft. would likely not be.

So, to be sure that some systematic effect of broadcast orbits wasn't present, you'd need to repeat the vectors on different days, I'd think. The other issues, satellite constellation and unmodeled ionosphere and troposphere effects should be taken care of on a different day unless you are so unlucky as to schedule the repeat occupations exactly on sidereal day later. That's easy to avoid.

As a practical matter, occupations in the morning on one day and in the afternoon (about as far after noon as the morning occupations were) on the next should do the trick beyond reasonable doubt, although it may take several repeats to have a statistically significant comparison.

Naturally, bringing the RTK positions into an adjustment as vectors with uncertainties simplifies the analysis considerably as static GPS vectors, leveling, and total stations measurements are combined with the RTK vectors to test the RTK processor estimates of their uncertainties.

Shawn, If You Have A Few More Minutes With RTK

> With good clean data you can get an OPUS-RS position with a 7.5 minute file.
>
> Of course with such a short file it is possible to fall into a PDOP gap.
>
> Test those extra short files yourself. I would not recommend them to a novice, but on some days a planned longer file just never gets going as well as you planned.
>
> Paul in PA

Paul,

Maybe you can, but I can not. In my experience with OPUS-RS, any static files less than 15 minutes are REJECTED.

How are you able to get OPUS-RS to process 7.5 minutes of data?

Lee Green

Lee, Here Is A 10.5 Minute Solution

FILE: FAMR3124e.14O OP1415845005076

9999 OPUS-RS DISCLAIMER OPUS-RS DISCLAIMER OPUS-RS DISCLAIMER
9999
9999 Your data file spans less than 0.01 days
9999 (14.4 minutes). OPUS-RS
9999 recommends a minimum of 15 minutes of data to obtain accurate
9999 positions. OPUS-RS will not attempt to process datasets under 0.005
9999 day (7.2 minutes)
9999

1009 WARNING! No antenna type was selected. No antenna offsets or
1009 pattern will be applied. Coordinates with reduced accuracy
1009 will be returned for the antenna phase center.
1009
1008 NOTE: Antenna offsets supplied by the user were zero. Coordinates
1008 returned will be for the antenna reference point (ARP).
1008
NGS OPUS-RS SOLUTION REPORT
========================

All computed coordinate accuracies are listed as 1-sigma RMS values.
For additional information: http://www.ngs.noaa.gov/OPUS/about.jsp#accuracy

USER: lplopresti@enter.net DATE: November 13, 2014
RINEX FILE: famr312x.14o TIME: 02:18:29 UTC

SOFTWARE: rsgps 1.37 RS92.prl 1.99.2 START: 2014/11/08 23:01:00
EPHEMERIS: igr18176.eph [rapid] STOP: 2014/11/08 23:11:30
NAV FILE: brdc3120.14n OBS USED: 1107 / 1323 : 84%
ANT NAME: NONE QUALITY IND. 7.33/ 13.30
ARP HEIGHT: 0.000 NORMALIZED RMS: 0.316

REF FRAME: NAD_83(2011)(EPOCH:2010.0000) IGS08 (EPOCH:2014.85469)

X: -384719.602(m) 0.008(m) -384720.409(m) 0.008(m)
Y: -5146143.126(m) 0.023(m) -5146141.719(m) 0.023(m)
Z: 3736349.270(m) 0.025(m) 3736349.136(m) 0.025(m)

LAT: 36 5 18.89449 0.009(m) 36 5 18.91664 0.009(m)
E LON: 265 43 28.51702 0.007(m) 265 43 28.48066 0.007(m)
W LON: 94 16 31.48298 0.007(m) 94 16 31.51934 0.007(m)
EL HGT: 356.886(m) 0.033(m) 355.722(m) 0.033(m)
ORTHO HGT: 385.035(m) 0.038(m) [NAVD88 (Computed using GEOID12A)]

UTM COORDINATES STATE PLANE COORDINATES
UTM (Zone 15) SPC (0301 AR N)
Northing (Y) [meters] 3994526.402 197102.011
Easting (X) [meters] 385175.915 195093.597
Convergence [degrees] -0.75134480 -1.32406022
Point Scale 0.99976245 0.99997459
Combined Factor 0.99970645 0.99991858

US NATIONAL GRID DESIGNATOR: 15SUV8517594526(NAD 83)

BASE STATIONS USED
PID DESIGNATION LATITUDE LONGITUDE DISTANCE(m)
DN6071 MOA2 MODOT ANDERSON CORS ARP N364103.393 W0942618.245 67703.2
DM3513 MOCS MODOT CASSVILLE CORS ARP N363848.209 W0935420.355 70267.8
DI8422 SAL6 SALLISAW 6 CORS ARP N352202.191 W0944858.797 93811.2
DM4682 MOMO MODOT MONETT CORS ARP N365500.486 W0935859.015 95569.8
DE8101 OKTU TULSA CORS ARP N361238.113 W0955115.782 142741.5
DH7105 ARHR HARRISON CORS ARP N361103.236 W0930148.726 112584.3
DL6012 MOBR MODOT BRANSON CORS ARP N364235.201 W0931323.592 116882.9
DL6014 MOCA MODOT CARTHAGE CORS ARP N371039.166 W0942127.243 121070.6
DF7475 OKHV HEAVENER CORS ARP N345447.379 W0943705.092 134070.0

NEAREST NGS PUBLISHED CONTROL POINT
GG0646 FAYETTEVILLE OZARKS ELEC MAST N360349.002 W0941225.704 6742.2

This position and the above vector components were computed without any
knowledge by the National Geodetic Survey regarding the equipment or
field operating procedures used.

Lee, send me a short RINEX file OPUS-RS rejected.

Paul in PA

Shawn for comparison, I just located two witness corners, one at the northeast corner of a section and one at the N1/4.

I had located them in 1998 and still have that GPS file

one is on a local plane projection and the other on a State Coordinate file with a DAF applied.

Both are RTK surveys

from the 1998 survey:

Forward Azimuth 89-44-19
ellipsoid distance 2622.81'

From the 2015 survey

Forward Azimuth 89-44-21
ellipsoid distance 2622.80'

These are two surveys 17 years apart...............

> b) This RTk/RTN thing is not actually the "staff of satan"

I got the idea he was describing RTK surveys he'd made, and probably using more than the two beeps that the typical RTK user will settle for. :>

Lee, Here Is A 10.5 Minute Solution

Paul,

A few weeks ago recorded 12 minutes of static with Hiper SR and sent the TPS file to OPUS-RS.

This is what I got back.

FILE: log20150226_181539.tps OP1424994521722

9999 OPUS-RS DISCLAIMER OPUS-RS DISCLAIMER OPUS-RS DISCLAIMER
9999
9999 Your data file spans less than 0.01 days
9999 (14.4 minutes). OPUS-RS
9999 recommends a minimum of 15 minutes of data to obtain accurate
9999 positions. OPUS-RS will not attempt to process datasets under 0.005
9999 day (7.2 minutes)
9999

2005 NOTE: The IGS precise and IGS rapid orbits were not available
2005 at processing time. The IGS ultra-rapid orbit was/will be used to
2005 process the data.
2005
6029 After the single baseline analysis, fewer than 3 useable
6029 reference stations remain. Aborting.
6029

I have never sent a short file nor a HiPer SR file to OPUS-RS before or since that time. Today I opened this TPS file in Magnet Tools. I noticed 11 minutes of data was Kinematic, and only 1 minute was Static. So I corrected all data to Static, and sent the file to OPUS-RS today. I did receive a solution for just 12 minutes of static data. It does work. Thank you.

Lee Green