When collecting static observations for PPK with our local OS Net station (never more than 6km from the area we’re working), I’ve been using six minute observations with our RS2 rover. When processing in RTKPost QT I notice the fix flag (q=1) appears almost immediately, I wonder if we could reduce the static observation time down to two or three minutes? We have another 30 to collect so would speed up the process considerably.
Up to now we’ve been using our own RS2 as a base using NTRIP corrections to the rover but that unit is out on hire at the moment, hence static observations for now.
Just wondering how long others are observing static points on the RS2 with short baselines?
It really depends what you are using your static points for? Can you elaborate?
Yes, we’re collecting GCPs for a thermal survey, using drains and manhole covers as targets as they show up well in the thermal imagery. Accuracy only needs to be 20cm XYZ.
Does static survey need one receiver?
You can use 1 or any multitude of receivers for static. If you use 1, you will have baselines to the surrounding CORS. If you have more than one, you will have baselines to all the others receivers if observation sessions are the same.
So I did a test today, same point for two, four and six minutes. Two minutes gave me a float, but actually within 5mm of the fix xy and 30mm z. Four and six minutes were both fixes, and less than 3mm xyz between them. This was with a low PDOP and good satellite positions. Observed another 12 GCPs at four minutes and got a fix with them all. Still cold on the hands though, but saved 24 minutes of observation time!
The test manhole cover with clear sky view N-S-E but a hill to the west.
So do I understand your flow correctly that you are logging seperate log files for each point?
Correct Christian, I travel between each location in a van, the RS2 remains on all the time, at the first point it’s allowed to settle for a bit before taking the first observation. It can be around 10 - 15 min between points.
I would run it as a Stop&Go flow instead, which basically means running logging all the time, and then use the Survey functionality in Reachview to mark a start and stop time for a given point.
Then you postprocess 1 log file as kinematic, and extract the points from the start-stop times. This can be done automatically by feeding the CSV-file from reachview.
We have tried this before, might give it a go again, however the RS2 is in the back of the van between points so it doesn’t record any sensible observations. This gave us errors during processing, but that was a while back.
I’d not recommend reducing collection time. The time required to obtain a Fix depends on the environmental conditions. If you work under a clear sky view, you can obtain a Fix pretty fast. However, it’s rare to find a survey site with absolutely the same conditions throughout the area. The time you save collecting points can be wasted if you get insufficient accuracy because of this.
I agree with Svetlana. Too little time on station will result in more time finding the problem if one occurs. And you will encounter problems with low observation times. If the points are of any importance, I occupy no less than 5 minutes even out in the open depending on baseline lengths. If you’re in a high multi-path area, a minimum of 30 minutes for occupations.
Also, as I keep repeating here on the forum, short baselines are your friend. Longer baselines=longer occupation time.
What’s the rush ? Enjoy God’s creations and think of how lucky you are to be in this age of electronic wonders.
Haha, the rush is we have 50 of these altogether (more than half way there now) and it’s -2°C out there! Our baseline is only 5km at the furthest point, we did the far end today with 10 minute obs on the furthest two, all processed fine. The next lot are in a more built up area so maybe more challenging.
My approach to this would be collect one long log instead. Mount your antenna on the roof of your car (with i.e. a small magnetic tripod with a quickrelease, or a dedicated rod-holder) so you have good skyview also when under transport.
Then you don’t need more than 30 seconds to 1 minute for each obs.
With the baselines you are running, you don’t need more than that, especially when you only need 20 cm precision.
Only reason to run 5+ min obs for a GCP is if you run it as static stand-alone, processing log by log.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.