> But first, how did you deal with distance-dependent uncertainies
perform the same test at various ranges from the base. Although in Don's case, he's using an RTN, so this is not really a valid exercise.
>and the question of independent initializations?
a good test, but a separate test altogether from the epoch by epoch precision obtainable from a properly fixed solution.
Mark Silver has an excellent test procedure for the reliability of ambiguity resolution. He has two quick connect mount in which he tests two receivers simultaneously. He disconnects the receivers, dumps them, and sets them on the opposite mount. Once fixed, he takes a shot. He then repeats this test over and over. He then compares the Up value for each point in a spreadsheet with the idea that a bad initialization will reveal itself in the elevation. He performs this test in a very GNSS hostile environment on the North side of a coniferous tree next to a brick building.
>As for cluttered locations, I'd think that would just involve using locations that real world work actually presents, classifying it by horizon masking and possible sources of multipath.
I'm sure there are ways of quantifying multipath. I doubt many users would go to the trouble to do so however, opting more from an experiential judgment call.
> To get back to my original post.To achieve acceptable quality control points, how many times would you need to be re-shooting the points set by the integrated surveying method. The equipment vendors would give you the impression you just shoot once and work away. Now if in reality you have to go back and keeping shooting a lot of points over and over you might just have been better off with a static session in the first place.
That is exactly the right question. The problem is that if the positional uncertainty estimates generated by RTK controllers are optimistic, rather than realistic, the surveyor will assume that points positioned via RTK are better than they really are.
If RTK takes multiple occupations to generate a reliable answer at some realistically estimated uncertainty, then yes, a rapid static session is quite often a superior solution that takes less time when all of the shuttling around to control points is accounted for.
> If RTK takes multiple occupations to generate a reliable answer at some realistically estimated uncertainty
That's a big "IF" that might just prove to be unfounded.
> It is possible to continue to add a never ending inflationary spiral of conditions and qualifiers for a test, such that open ended criteria will effectively prevent any testing of data from taking place - leaving assumptions comfortably and safely unfounded. Brilliant.
>
To me, part of the beauty of GNSS positioning is the ease with which one can test varying methodologies in a variety of scenarios. If you can dream it, it can probably be put to an experiment. I don't have the long experience that Kent has, we've only been testing GNSS (static, stop and go, a brief stint with pseudo kinematic, full kinematic, SBAS - WAAS and LandStar, RTK, high precision SBAS, and RTN) for about 14 years. OPUS makes this testing even easier now as you can build your own laboratory with multiple hours of observations.
> If a technology is so (allegedly) obviously so unreliable, then any and all sample data (including your test in real world conditions) should be dead simple to reveal as "bad", if indeed results are "bad". As for testing in real world conditions, there are several studies published by independent academic institutions that have been commissioned by such bodies as national mapping and surveying agencies (who obviously have a great interest in repeatable and verifiable results). But it is always easier to reject and refute than have to prove.
Agreed
> There are responsible and diligent surveyors everywhere who have done testing to their own satisfaction and some have found different tools to not meet their needs and some who have accepted... convincing some is a toil of Sisyphus; you have offered data to all. You can lead horses to water...
This is one thing I've always wanted to subtly impress upon readers of my reviews (particularly related to GNSS), that you can test your equipment fairly easily and not rely on the statistics provided by the controller nor the word of the manufacturer, but by your own experiments. Then you can see first hand if this technology will meet your needs. Most surveyors I've been in contact with over the past few months, that are using new technology (and I've been in contact with many) are not content to take a new receiver to the job site and try to use it for production. The significant majority are testing this equipment in controlled environments until they become proficient with it. Those that are taking it to the jobsite are using it to locate points located by other methods as a means to test their knowledge and the receiver's capability. Only once have I talked with someone trying to use his receiver on the first day to get a job done. He didn't last long.
> > If RTK takes multiple occupations to generate a reliable answer at some realistically estimated uncertainty
>
> That's a big "IF" that might just prove to be unfounded.
The optimism of RTK controller estimates of uncertainty has been reported by multiple sophisticated users. Whether or not the uncertainties are optimistic or not is simple enough to test if one is ever serious about doing so.
> >and the question of independent initializations?
>
> a good test, but a separate test altogether from the epoch by epoch precision obtainable from a properly fixed solution.
>
> Mark Silver has an excellent test procedure for the reliability of ambiguity resolution. He has two quick connect mount in which he tests two receivers simultaneously. He disconnects the receivers, dumps them, and sets them on the opposite mount. Once fixed, he takes a shot. He then repeats this test over and over. He then compares the Up value for each point in a spreadsheet with the idea that a bad initialization will reveal itself in the elevation. He performs this test in a very GNSS hostile environment on the North side of a coniferous tree next to a brick building.
>
The idea is that if one wants to test the uncertainty estimates of independent RTK solutions on some point, they need to be truly independent. If the question is whether the uncertainty in a position taken from X number of epochs of RTK observations as generated by the RTK controller is systematically in error or not, then one needs to test the uncertainties in RTK positions from X number of epochs, all as independent of one another as possible. An independent intialization for each set of X epochs would seem to be one fundamental requirement.
> >As for cluttered locations, I'd think that would just involve using locations that real world work actually presents, classifying it by horizon masking and possible sources of multipath.
>
> I'm sure there are ways of quantifying multipath. I doubt many users would go to the trouble to do so however, opting more from an experiential judgment call.
The idea is that some real world locations should be used in the test where sources of multipath and cycle slips are present. If the reason why you only tested your system in some wide open setting is that you were unsure how to characterize real world sites, I was merely offering a suggestion of how to do so. Clearly an experienced surveyor will have some idea as to classes of difficulty of GPSability of points in different settings.
At any rate, testing RTK in a setting substantially free of multipath would be of limited predictive value for many real world settings.
It is no longer necessary (in many cases) to have to make two trips. If done carefully you do not have to go out and do control campaigns, adjust and massage, then go back out to do the work
Heck, we've been doing that since the 90's.;-)
Receivers on control, download to a laptop, adjust in GPsurvey, TSO.....all in the field.
Right, Gavin- that's why the NGS single base guidelines were based on pragmatism rather than a set of year-long scientific tests. Never had anyone tell me the criteria didn't work for any of the 4 levels of precision....
