I decided to test an L1 static rover, a Promark3, to determine how long I had to occupy a a station to put points along a boundary line. I was not looking to set monuments along the line, rather steel fence posts to mark the line and if they are within 0.2 feet, I'm very happy.
The terrain was open, no obstructions. I established a base using 2 X90-OPUS receivers at 0100 and 0102 about 2885m apart, occupying for just over 2 hours and processing through OPUS-Static. The X90 collects data at 5 sec intervals, decimates to 15sec for OPUS. Coordinates came back using the Ultra-rapid ephemeris and errors below 0.01m. I set a Promark3 on the point to the east and collected data for 5min, 10min, 15min, 20min and 30min in static mode. Number of satellites was good, mostly 9+. I was thinking that the 30min occupation time would be my standard and wanted to see how short a time I could occupy to get close to that position.
After the OPUS solution came back, I ran the original X90 data through GNSS Solutions (L1 only) setting up 0100 and 0102 as control per the OPUS results, then imported the Promark3 datasets (also 5 sec intervals), processed baselines, and adjusted. I'm not sure I believe the result. All 5 results from the rover came back within a 6mm diameter circle with the 5min and 30min datasets being only 3mm apart.
My conclusion is that a short occupation time is adequate. Comments?
Hard to argue with real world results. Back in the day, we tested the ProMark2 similarly, and I found that at a 1000' I could get reliable fixed results (in the open, of course) in 5 minutes. The ProMark3 is quite a bit more sophisticated, when processing against another ProMark3, than the ProMark2's were because of the SBAS processing.
It occurs to me that you weren't processing ProMark3 to ProMark3 in this test, but ProMark3 to X90-OPUS. Nothing wrong with that, I'm just not sure if the SBAS processing works between X90 and ProMark3.
I use 3 PM3s. Two on a control point and one as rover.
When I want something located as accurate as possible, I leave it occupied until the range equals 1.5 times the distance the control points are away in miles.
When the PDOP is low (under 2) and the satellites are many (8 or more) 5min is usually good for less than a centimeter and under clear skies can be spot on.
😉
I would measure using conventional and compare the results.
I just finished a project where RTK and static agreed on several positions. With three record maps saying otherwise I had to revisit. Sure enough, bad positions by 0.6 to 1.4 feet.
Sometimes to good to be true is your brain talking to you...
> I just finished a project where RTK and static agreed on several positions. With three record maps saying otherwise I had to revisit. Sure enough, bad positions by 0.6 to 1.4 feet.
I've never seen a static position out by anything near that magnitude. What kind of observing conditions, and what kind of occupation time?
These were 30 by 30 second RTK and nominal 15 minute rapid static. The base was about a mile away. Mask was 15 degrees or better. The quality indicators were not significantly different than any other points. The unusual part was static and RTK matching a bad position.
I encounter bad redundant RTK at least once every week or two. Folks give me grief for burning the budget with excessive QC. I say the proof is in the pudding...
Had to be set up on the wrong point or something. I can't think of a way in which two independent RTK observations (I'm guessing that's what a "30x30" is) and a static session would give the same wrong answer for a point. I don't buy it. Got to be something else going on.
There aren't two points with the relationship of the error. The 2 RTK shots were taken with the same initialization. The static being screwed up to within 0.08 3d was extremely strange but it happened. This was a large site. I sent the crew back to several suspect points and did conventional checks. We found several more bad positions. The nearest I can figure is the initialization was gained coming out of a bad environment. Most of the points were in the open.
