PostProcessing points Stop&go

Hi all

I have Reach RS and I would like to postprocess some points collected not in RTK but using a rinex provided by public base station.
So the question is if I collect points in single mode for ex 30 sec can I download this raw observations to post process after with RTLIB ?

Or I have to follow other approach ?



Yes, how do you plan to record occupation time?

Are you using RS/RS+ or RS2? This will mean a difference in collection time.

just start/stop logging on rover and record HI for each log file. have base log continuously.
download and post process in RTKLib

Personally I would not recommend doing it like this for RS/RS+. This requires much longer obs times, and you would have to resolve ambiguities first (10 mins) and then collect the data (15 min, for long term static points). Rather collect 1 long log, and then use the survey-tool in Reachview to define the start/stop times.
The positions can then be extracted after PPK using one of the free/donate-to-use utilities, or even a commercial solution like EZsurv.


I use the same method, always logging all survey in continuous, then when a point failed in real time RTK, postprocess it.

I agree with @wizprod suggestion. It’s recommended to write full log of your surveying and then post-process it point by point. You can use Time Start and Time End option for this in RTKLIB software.

Thx for suggestions !

I’ll try


It is too dangerous to do one long continuous survey and then use time stamps to average the points in question. This method works great if you maintain “lock” (integer ambiguities) for the entire survey, but if you loose lock (generally by passing an obstruction like a tree or building) then your results will be float and you won’t know it until you are back in the office and have post processed your data!! If you are lucky you will only loose a few points before lock is reacquired. The most important function of a traditional Stop&Go survey is the ability of the software to throw up a warning telling you that you have lost lock. In this case the survey is stopped and re-initialized. If you are working in a wide open environment, with no obstructions, then you could take a chance and use the time marks to get your points by averaging. But if you work in an environment that might cause lose of lock, like trees or buildings, then I’d just do a static survey for each point. That in my experience means at least 10 minutes on each point depending on the distance from the base station. 10 minutes might seem like a long time and it will extend your time in the field, but that will seem a small price to pay if instead you do one long continuous survey and discover that when you post process your data that you have a bunch of time gaps where lock was lost. Having to return to the field to reacquire critical missing points is a DRAG. Been there, done that. If it is a paying job then the ramifications mean $$, if it for a hobby then it is just lost time.

I have posted on this issue a few times on this forum and my last posting was actually deleted by the moderator! In any case I think this issue of Stop&Go is very important to address because there are a lot of new users of dgps gear trying to collect accurate ground target positions for drone surveys. Many new users just do not understand the ramifications of maintaining lock and that by doing one long PPK survey that your work is happening on a hope and a prayer (blind faith).

Note: if you have an L1/L2 gps then static collections times could possible be reduced a lot. I’m guessing a couple minutes on each point – but I have not tested this.

Please Emlid do something about adding a real Stop&Go (post processing) survey methodology to your software!!


All surveyors who have gone through a classic Stop and Go survey will understand perfectly what you insinuate, but unfortunately not all including those who use Emlid receivers because these are especially designed for a survey or stake out in RTK mode, which is a good thing too it would be interesting to add a stop and go methodology but there are other functions to add first at this moment.

1 Like

Hm, I don’t see the conflict here? Using L1-only, I’d rather have use both options: one long raw-file, and 10-15 min (preferably 15 min) per point (preferably in RTK mode, so I have an indication of fix and PDOP).

In bad reception conditions you might need even longer than 15 mins, to increase your chance of fix. Here the 1 long raw-file can also come in handy. You can use the fix to maintain a better fix, when you have a longer raw-file, and also run the processing backwards or even combined.
A long raw-file gives you a lot of options, not the opposite.

Can you clarify what you would like to see in the future?

1 Like

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.