Here is the full specification for the Trimble R8:
[pre]
Positioning Performance (See Footnote 1)
Static GNSS Surveying
High-precision static
Horizontal. . . . . . . . . . . . . . . . . . . . . 3 mm + 0.1 ppm RMS
Vertical. . . . . . . . . . . . . . . . . . . . . . 3.5 mm + 0.4 ppm RMS
Static and FastStatic
Horizontal. . . . . . . . . . . . . . . . . . . . . 3 mm + 0.5 ppm RMS
Vertical. . . . . . . . . . . . . . . . . . . . . . 5 mm + 0.5 ppm RMS
PostProcessed Kinematic (PPK) GNSS surveying
Horizontal. . . . . . . . . . . . . . . . . . . . . 8 mm + 1 ppm RMS
Vertical . . . . . . . . . . . . . . . . . . . . . 15 mm + 1 ppm RMS
Real-Time Kinematic Surveying
Single Baseline <30 km
Horizontal. . . . . . . . . . . . . . . . . . . . . 8 mm + 1 ppm RMS
Vertical . . . . . . . . . . . . . . . . . . . . . 15 mm + 1 ppm RMS
[/pre]
[pre]
(Footnote 1) - Precision and reliability may be subject to anomalies due to
multipath, obstructions, satellite geometry, and atmospheric conditions.
The specifications stated recommend the use of stable mounts in an open sky
view, EMI and multipath clean environment, optimal GNSS constellation
configurations, along with the use of survey practices that are generally
accepted for performing the highest-order surveys for the applicable
application including occupation time appropriate for baseline length.
Baselines longer than 30 km require precise ephemeris and occupations up
to 24 hours may be required to achieve the high precision static
specification.
[/pre]
In other words, as I noted, the Trimble RTK accuracy specification depends upon occupation time. I assume that the folks at Trimble knew that some RTK users would be wanting to blast out over 30km and thought to cover that possibility with a broad warning.
So Kent. Do you think that 8mm+1ppm, as provided by Trimble, is a realistic error estimate for RTK?
> So Kent. Do you think that 8mm+1ppm, as provided by Trimble, is a realistic error estimate for RTK?
I think that, as the Trimble spec reflects, in ideal conditions, with sufficiently long occuptions, RTK accuracy can approach being as good as PPK accuracy*
*Precision and reliability may be subject to anomalies due to multipath, obstructions, satellite geometry, and atmospheric conditions. The specifications stated recommend the use of stable mounts in an open sky view, EMI and multipath clean environment, optimal GNSS constellation configurations, along with the use of survey practices that are generally accepted for performing the highest-order surveys for the applicable application including occupation time appropriate for baseline length.
Naturally, that doesn't describe typical RTK use very well.
Shawn - Speaking of baseline length
> The standard "iono-free" solution (as many folks call it) has seen strides, and the old rule of thumb at 10km from yesteryear gets talked about as more like 30km (that is definitely debatable). But anyhow, we now see specs for 30km.
I posted the Trimble specs for their R8 receiver above, you'll note what they recommend at 30km is essentially a static solution. Their claim for the horizontal accuracy of a position determined from a 30km PPK vector would be +/-3.8cm = 0.12 ft. RMS, but under perfect conditions.
http://beerleg.com/index.php?mode=thread&id=321177#p321381
Shawn - Speaking of baseline length
> So it was Ok for me to mention RTK and an aside contrasting RTN and RTK. RTN were developed to free people from short baseline restrictions.
So, basically you were chastising single-base RTK users for not using a Real-time network ?
Hey! Stop misrepresenting what people are saying!
> RTK has strengths, and so does RTN - it is important that people know what those are, and better yet - actually test it for themselves and apply appropriately.
Well, I guess I assumed that the point you were trying to make had something remotely to do with the subject under discussion, which was the errors in an RTK survey. The single-base RTK accuracy is fairly substellar per the manufacturer's claims, so you chimed in urging everyone to try some RTN. If you in fact were not claiming that you expected the RTN results to be better, then my apologies. I definitely should not read what you post in the context of the subject under discussion, but as some precious insight unrelated to the topic. My bad.
Speaking of the original post...
So what you are actually saying is that a positional tolerance of 0.12' in context of a 23000 acre survey is sub-stellar. As if that premise isn't delusional enough on its face, I would suspect Andy had some error in his own determination of the point. So it's possible, perhaps even likely that this 'outlier' is positionally more accurate than the 0.12' residual mentioned.
Speaking of the original post...
> So what you are actually saying is that a positional tolerance of 0.12' in context of a 23000 acre survey is sub-stellar.
LOL! What the point of the OP was that this magic RTK was giving essentially exact results in agreement within a hundredth with some other value determined by another surveyor by some unknown means. For the sake of the proposition, suppose that the other unknown means were basically perfect, a static GPS network properly adjusted, with uncertainties at the 1mm level in N and E. That is significantly difficult to do (and unlikely to have been done).
What seemed the obvious point to me is that an RTK positioning method that delivers positions for which the manufacturers claim horizontal RMS uncertainties in the range of +/-(1cm + 1ppm) to +/-(8mm +1 ppm) isn't going to deliver the sort of +/-2mm horizontal RMS uncertainty that would be needed to accomplish agreement of 3mm at distances up to 5km from the base.
> As if that premise isn't delusional enough on its face, I would suspect Andy had some error in his own determination of the point. So it's possible, perhaps even likely that this 'outlier' is positionally more accurate than the 0.12' residual mentioned.
Your argument is obviously with the GPS manufacturers. In perfect conditions, the claim is +/-(8mm + 1ppm) horizontal RMS for a single-base RTK vector with Trimble R8. In Kris's real world example, the accuracy was significantly worse, more in line with a horizontal RMS of +/-(3cm). But either way, +/-1.3cm (over a 5km line) or +/-3cm, the relative positional accuracies between two points positioned via RTK vectors with those uncertainties is going to be sloppy if they are very close at all.
RTK deviations
Hello Kent and gschrock,
As RTK and RTN seems to be all the rage around here lately I thought I'd test the manufacturers spec. So on-site today while traversing around I set up our RTK rover and started streaming corrections from a single base station 5.1km away. Everyone loves a scatter plot so here are all 22,000+ instantaneous RTK positions at 1 second intervals.
I do not know the actual position of the receiver. The standard deviation of all the points is 6mm E and 8mm N. This is 10mm position SDEV which stacks up very well against the manufacurers specs for the GX1200 receiver and AX1202 antenna for a single RTK epoch. Every single point falls within about 75mm E and N, with the overwhelming majority falling within about 25mm E and 35mm N.
Consecutive 2 minute windows look like this:
It can be seen that due to poor geometry or rising and setting satellites some 'bad' solutions stay in 'outlier' territory for up to 15 minutes at a time. The standard deviations for the 2 minute windows was reduced slightly to 5mm E and 7mm N. My interpretation of the (only) slight improvement in deviations shows how the slow moving nature of the GPS constellation and solution just cannot be overcome with short observation windows. But as expected, windowing does greatly reduce the effect of the 'outliers'.
As a side note I observed 9 points throughout the day using 5 minute static-type RTK observations. I also took the raw observations from these occupations and post processed them. The post processing did nothing to improve the standard deviation of the group of 9 points. The E and N spread, and the STDEV of the 9 points actually got a little bit worse. I'm not sure of the significance in such a small sample. Also processing the points from a virtual reference station (VRS) created only 50m away from the receiver did nothing to improve the spread of points. It appears more range from a base station is needed to see the flattening effect of a network solution on range-based errors when compared to single base.
I would describe the site conditions as friendly to GPS. On a GPS friendly site, at these kinds of ranges, based on the data collected, averaged RTK should produce results accurate to a few cm with little fear of 'wrong' answers. My feeling is that session length is far more important than the choice of either RTK or PP occupations, both of which should produce answers of similar quality over similar occupation times. The published Leica 1200 GNSS horizontal RTK specs appear accurate.
RTK deviations
It's good to have some data that is statistically significant in this discussion, instead of just isolated cases where it was great or terrible.
The presentation of your data requires a little thought, as the change of scales loses the visual impact of averaging's effect.
The manufacturer's specs are likely to be pretty close to truth under the conditions they tested, and you may need to allow for poorer conditions.
If they give standard deviations or probable error, or you have estimated that from your own measurements, you need to ask yourself how often you are willing to be off further than that. Adjust your expectations according to the Rayleigh (bivariate normal) distribution statistics. Is 95% confidence enough? You're still wrong (outside your confidence limit) one time in 20. That is in addition to the risk of a bad initialization. Don't bore me with examples of the 19 that were inside; I want to know how much trouble it caused when you were outside.
Like some people have said in these discussions, no measurement should go unchecked.
If I were a user of RTK with needs at the very-few-cm level, I'd have a rule that every point had to be measured at least twice with a half-hour or more between measurements, and if the discrepancy seemed significant continue until I had a majority that agreed well enough. Two independent measurements will both be off more than the 95% confidence limits once in 400 times, and I can recognize it in the majority of those cases by the disagreement.
RTK deviations
It should be noted that manufacturer's specifications are normally published at one sigma, but good luck finding that in the small print. Your results are EXACTLY what I would expect.
A retracement and you find an "original" monument out less than an inch. Im holding it as good and not touching it.
RTK deviations
> It should be noted that manufacturer's specifications are normally published at one sigma, but good luck finding that in the small print. Your results are EXACTLY what I would expect.
Actually, it says it right in the specs that Kent posted. RMS is short hand one sigma. You have to multiply the number by 4 to get a real sense of the 95% confidence on the ground.
RTK deviations
If a surveyor is doing a retracement and when taken to that coordinate can't find the marker put there using a similar RTK, WELL THEN maybe time to change careers.
GPS is a good measuring system. Since it is based upon a world 3D system the problem comes in reducing the more or less true measurements to some projection (flat earth). I think most of the problems occur in the math reduction of the real measurements to the flat earth we seem to want to visualize. And then on top of all the reduction to the flat earth we want to further massage the data with some least squares deal and then claim its good to 5mm. Well, if all the math procedures where done right probably so, but with all the math in the hands of the somewhat clueless you might get anything after the crank is turned.
For me, if I get there within a tenth of a foot I'm good. Most times that will set you down on the marker.
Now for some getting to within a foot of the marker isn't good enough. They find the marker BUT, it's not under the point of the pole so it can't be accepted. Not doing retracement but rather stakeout of the coordinates. If you are one of these guys WELL, 5mm is probably disturbing. So how do you retrace, according to the law or the technical math?
RTK deviations for Conrad
> Consecutive 2 minute windows look like this:
>
>
>
> It can be seen that due to poor geometry or rising and setting satellites some 'bad' solutions stay in 'outlier' territory for up to 15 minutes at a time. The standard deviations for the 2 minute windows was reduced slightly to 5mm E and 7mm N. My interpretation of the (only) slight improvement in deviations shows how the slow moving nature of the GPS constellation and solution just cannot be overcome with short observation windows. But as expected, windowing does greatly reduce the effect of the 'outliers'.
So, basically, your test demonstrated that the average of 120 RTK positions over 2 minutes had a standard error in the horizontal of about +/-9mm, with the unknown being whether there was some systematic error that the scatter doesn't reflect.
The Leica spec is +/-(8mm + 1ppm) for RTK positions isn't it, so the standard deviation of the individual epoch solutions would be fairly consistent with the specification. The ensemble average of 120 consecutive epochs is not smaller in proportion to the square root of the number of obserations, indicating that there are systematic unmodelled effects present over periods of 2 minutes that tend to cancel in longer occupations and the longer occupation is necessary to improve the reliability of the solution, even in the perfect conditions you described.
> As a side note I observed 9 points throughout the day using 5 minute static-type RTK observations. I also took the raw observations from these occupations and post processed them. The post processing did nothing to improve the standard deviation of the group of 9 points. The E and N spread, and the STDEV of the 9 points actually got a little bit worse.
The advantages that I see to post-processed solutions are:
- the ability to inspect and improve solutions by strategies including eliminating satellites. I take it that this was not likely needed in the setting you described if there were no obstructions or multipath sources,
- ability to use improved epherides, and
- simpler operational logistics (shuffling base receivers or repeaters around in areas well outside of cell phone coverage to maintain a radio link burns up lots of time on the sort of rural tracts familiar to me).
I've concluded from the general scarcity of RTK users who bother to import RTK vectors into a least squares adjustment program for adjustment and error analysis that it must be that many RTK manufacturers do not support this or do so in a way that locks the user into their proprietary software, whereas the formats of post-processed vector solutions are somewhat more widely understood by third-party software such as, say, Star*Net.
RTK thoughts for Kent
Hello Kent,
The manufacturers spec for the 1200 GNSS series is 10mm+1ppm for kinematic observations.
The standard deviation of a single measurement for the 22,000+ shots is barely any different to the standard deviation for windowed observation averages up to the 2 minutes I tested. I put this down to the nature of the GNSS problem as I understand it. That is, there is some noise epoch-to-epoch which can be smoothed using relatively few observations (e.g. 10 or so), but the smoothed solution still moves around quite slowly due to the slowly changing constellation, and there is absolutely nothing any of us can do about it, Rapid Static or RTK.
For this reason single GNSS epochs/observations do not lend themselves to the sqrt(n) rule, presumably due to a very high epoch-to-epoch correlation. Each epoch used in a PP or RTK solution probably cannot be considered an independent observation. Leica at least seem to know this. Their point coordinate quality indicator does not count down in the sqrt(n) fashion the longer you occupy a point. I find it generally gives quite realistic quality estimations.
>The advantages that I see to post-processed solutions are:
>- the ability to inspect and improve solutions by strategies including eliminating satellites. I take it that this was not likely needed in the setting you described if there were no obstructions or multipath sources,
>- ability to use improved epherides, and
>- simpler operational logistics (shuffling base receivers or repeaters around in areas well outside of cell phone coverage to maintain a radio link burns up lots of time on the sort of rural tracts familiar to me).
Agreed on all points.
RTK deviations for Conrad
> Hello Kent and gschrock,
>
> As RTK and RTN seems to be all the rage around here lately I thought I'd test the manufacturers spec. So on-site today while traversing around I set up our RTK rover and started streaming corrections from a single base station 5.1km away. Everyone loves a scatter plot so here are all 22,000+ instantaneous RTK positions at 1 second intervals.
>
>
I imagine this has already occurred to you, but it would be interesting to derive the function describing the relationship between the standard error of an average of n consecutive positions as the number of epochs increases.
The other piece of information that interests me would be the direction of the vector to the base plotted on the scatter diagram. That is, I wonder whether the outliers show a trend that is even roughly correlated with direction to base.
One more query: what was the Aussie weather like the other day when the above test was made? Am I right in thinking that around the Aussie Winter Solstice GPS vector solutions tend to be freer of noise than closer to the Summer Solstice?
RTK deviations for Conrad
> I imagine this has already occurred to you, but it would be interesting to derive the function describing the relationship between the standard error of an average of n consecutive positions as the number of epochs increases.
>
> The other piece of information that interests me would be the direction of the vector to the base plotted on the scatter diagram. That is, I wonder whether the outliers show a trend that is even roughly correlated with direction to base.
Hello Kent,
Firstly I reduced the data so the base is at 0,0. So 5 squares up the page and 1 square across will give the vector.
I didn't derive a function but did examine the moving averages of consecutive groups of varying lengths. Some of things I noticed follows. It seems epoch to epoch variations of a few cm are easily taken care of by averages of 10-20 points. After that the movement is the occasional mm over the next few minutes. Your 20 points are a pretty good representation of where the solution will be for the next couple of minutes. After that the solution could be switching position by 20mm rapidly over the next minute or so, or it could be hanging around within a few mm for the next ten minutes. There doesn't seem to be much rhyme or reason to it; I don't imagine it will submit to a meaningful statistical analysis as there appear to be random short period changes superimposed on longer period changes, neither of which show predictable trends. I attach 2 x different 1 hour sections of the east coordinate for fun.
RTK deviations for Conrad
>There doesn't seem to be much rhyme or reason to it; I don't imagine it will submit to a meaningful statistical analysis as there appear to be random short period changes superimposed on longer period changes, neither of which show predictable trends.
It looks very much like a Brownian bridge, which is susceptible to statistical analysis.
https://en.wikipedia.org/wiki/Brownian_bridge
Probably the most striking thing about the plots you've made is the rough periodicity. Those explain fairly well why sampling over a period of time much greater than two minutes is practucally guaranteed to give a better result.
The obvious test from your data would be to compare estimates taken as the means of two, one-minute segments of data but separated by some period of time on the order of roughly half the period. Operationally, it would be a mess on many projects to do, but it would be a simple demonstration of the value of time separation.
The other thing that would be interesting would be to investigate whether there is any time correlation between the passage of plasma tubal structures in the upper atmosphere. At first impression, the periods of both appear to be similar.
http://www.theregister.co.uk/2015/06/02/electrons_ride_huge_plasma_tubes_above_earth/
RTK deviations for Conrad
Looks like about a 900-1000 second period crest to crest or trough to trough, around 15-18 minutes. It would be interesting to average consecutive epochs for different lengths of time to see what the point of diminishing returns would be. I've been thinking about "convergence" for a while. You somewhat reference it in your 20 second to 2 minute comment. The average seems to converge at some point and may rest there for a considerable time until something changes and the solution begins to deviate from that average.
In my brief testing on my 9.5 mile test baseline, it seems that the solution converges (horizontally) in about 4 minutes. From 4 minutes to 10 minutes, the average position doesn't change. This isn't to say that the solution is accurate, only that it has met its best precision by then. Vertically, the solution needed 8 minutes to converge. I'll be playing around with that more soon. This 4 minute convergence period is not required for shorter baselines. On site baselines (a few hundred meters) converge much more quickly.