How short can be the occupation time in a stop & go survey with a promark3? I'm actually use 15 seconds (as is recommended). any of you has experience working with shorter observation, maintaining centimeter accuracy?

Javier Martinez

It probably doesnt have so much to do with observation time as it does your record interval. You could probably go down to 5 or 10 second occupation time, but I would also adjust the record interval to 1 second. I could be wrong, but in theory it sounds like it would work.

Accuracy is about occupation time rather than the recording interval but there is a bare minimum number of epochs needed to make it work.

If you are going to use less than 15 seconds a one second recording interval will be essential.

You will also need a high tolerance for failure and a bigger error budget.

Test your methods with something where you already know the correct answer.

I always use 2-second intervals and 1/2-1 minute occupations.

I always wonder why I should have 1/2 minute plus occupations, when kinematic collects data per epoch . . . evidently accurately.

When processing kinematic, try removing a couple of vectors before and after a point and reprocess. Interesting results I found when I tried to remove some "bad" vectors. It looks as though the epochs recorded are tied together to hold the accuracy.

I always wonder why I should have 1/2 minute plus occupations, when kinematic collects data per epoch . . . evidently accurately.

You can test this yourself as I did. Set two receivers on two known points less than 10 miles apart. On one unit, run a typical static session (as a base) on the other run it as a kinematic observation. Allow it to run for several hours. Then you can compare the coordinates epoch by epoch to the known coordinates of the point you are occupying with your stationary kinematic receiver.

What I found with my test was that as long as you maintain fix and don't lose lock, epoch by epoch you will have horizontal accuracy well under 0.10' (3cm) and less than 0.15' (5cm) vertically. Now if you don't have very many epochs in an occupation, you will get very poor looking statistics, but the actual coordinates will likely be much better.

If you want meaningful statistics, you need to have about 12-15 epochs. Then the statistics begin to approach the actual accuracy of the occupied coordinates.

15 seconds at 1 second intervals = 16 epochs. 16 being a good statistical minimum. 30 seconds at 2 second intervals is also 16 epochs. Question to answer is how long does it take you to take care of other business at each observation?

I can get a very good position using 11 epochs, 5 minutes of 30 second intervals, L1/L2 OPUS-RS. That is using 6 CORS up to 200Km away. It is a good position but the software reports a statistically better position than it truly is. You want to confirm your positions independantly of a software statistic.

With memory as cheap as it is, no one should have to worry about using 1 second epochs and running out of room at the end of the day.

Paul in PA

I can get a very good position using 11 epochs, 5 minutes of 30 second intervals, L1/L2 OPUS-RS. That is using 6 CORS up to 200Km away. It is a good position but the software reports a statistically better position than it truly is. You want to confirm your positions independantly of a software statistic.

That's a completely different animal from stop and go. Try not to confuse the discussion.

Stop and Go is the resolution of a position from minimal observations. OPUS-RS is the resolution of a position from minimal observations.

Same animal, OPUS-RS has twice as many stripes as PM3 S&G.

OPUS-RS uses more than one base station, nothing prevents the PM3 user from doing that. OPUS-RS uses 6 CORS and 200Km limit to model troposheric corrections. That is uneccessary for short distances.

As I said, said animal. The discussion is about getting a statistically reasonable sample to get a handle on expected precision. With either animal it is possible to get statistically reasonable positions that are in fact incorrect.

Paul in PA

Stop and Go is the resolution of a position from minimal observations. OPUS-RS is the resolution of a position from minimal observations.

No, stop and go is NOT the resolution of a position from minimal observations. The resolution of a stop and go session is identical to that of a static session. The difference is that once the ambiguities are resolved, slices of the observation from the moment of a fix and on are taken to determine a position at some defined segment of the observation. This is why, if you lose lock, you must do something to determine the integer ambiguities before continuing to survey.

Opus-RS on the other hand is a technique for quickly determining the integer ambiguities by surrounding a site base stations. Very similar to ORGI (search this site for details on the ORGI project).

Opus-RS and S&G are completely different animals, serve completely different functions applying completely different techniques.

I did an S&G survey. I did 5 minute occupations on monuments and control points at 5" epochs. I also topo'd some fence for 15" which meant only 3 epochs at each fence shot. The statistics were bad on some of the longer shots but I didn't really care, it was just a fence.

Next time out I did an S&G survey, some topo at 2" epochs for 15" then it occured to me that 16, not 15 is a multiple of 2 so I changed to 16" observations. All observations (again a fenceline) had good statistics, they were also fairly short distance (no more than 300'). I observed some iron pipe centerline monuments for 3 minutes, these were further away.

I have two base stations and the loop closures looked good.

I've been wondering about trying 1" epochs for 5 or 6 second observations; I need to do a science experiment around the block at home.

Trimble RTK default is 5 epochs (5" if the radio doesn't pause) for topo shots. So I was wondering why I couldn't do that with the PM3 S&G for topo (5 @ 1) although RTK has some advantages as in problems are known real-time.

Shawn,

Both are short static observations, from which a position is determined. I don't think a ambiguity resolved while you are going can be used for your solutions. But because moving ambiguities aee solved, the ambiguites for the stopped position are quickly resolved. They may in fact be resolved before you start recording your stop session.

Let me explain a little about OPUS-RS.

OPUS-RS begins by looking at your submitted raw position. From that it selects the 6 nearest CORS with good data, opting if possible to surround your position. It then looks at your observation time and selects a time from 1/2 hour before to 1/2 hour after the mid time. It solves all the CORS to satellite ambiguities, actually twice, the most probable first and then the second most probable. It use that solution to create a data file and resolve the tropospheric corrections. With those corrections in hand and the satellite positions fixed in space from the 6 CORS, it then solves the short rover file. It can solve ambiguities in as short as 3 epochs.

Once ambiguities are resolved the same geometric equation conditions result in your position.

Using RSGPS the exact same program used in OPUS-RS I can solve a network from 6 one hour 30" CORS files in 35 seconds on my home computer. I can then solve a 5 minute, 11 epoch ROVER file in 20 seconds. My answers are the same as OPUS-RS to the 4th or 5th metric decimal place. NGS only gives me ITRF positions to 3 decimal places whereas the OPUS-RS computer has access to the 5 decimal places positions. It is an awesome program, but still has bugs in that the statistical reporting of precision is too optomistic.

David,

Gross RTK problems are known real time, but the actual determination of positional precision is too optomistic. Repeat observations are the only true test.

In both cases it is because the satellite positions are always changing. Sometimes you have perfect geometry, other times not. You are stuck with whatever geometry is up there for the few seconds of your observation. Mathematically s solution can be output with apparent great precision. But when looked at over time the positions can vary by much more than the variance of that short statiscal time in space.

Paul in PA

Paul, I'm convinced that you are completely ignorant of how L1 stop-and-go GPS works. Which is OK. I don't know how to do vector processing by hand so we're both ignorant. The problem is that so many people on the internet know just a little and then start making statements that sound like they are experts. This causes those reading those comments, who are also ignorant, to believe the misinformation by those who think they know what they are talking about.

Stop-and-Go GPS positioning depends upon a fixed solution throughout the session. If the fixed solution is lost, then the fix must be reestablished before survey grade work can continue. Once fix is reestablished, every epoch thereafter is accurate to the +/-3cm range hz and +/-5cm vert.

OPUS-RS, as you alluded to in your post, models ionospheric and tropospheric delay. As I understand it, this is done by using CORS stations that surround the rover station to interpolate the measured delays observed at the CORS sites, similar to a contour map of the atmosphere.

It's all pretty academic and meaningless to the original question, but I would encourage Mr. Martinez and any other readers of this thread to attempt the experiment I outlined above. It does a good job of simulating the real-world capability of stop-and-go epoch by epoch.

Shawn

First off, centimeter ACCURACY to me means that you are really getting accuracy, not simply calculated precision. This means checking lots of points with duplicate observations to provide some measure of redundancy and to give a warm fuzzy feeling that the shots in between your check points were meeting that same QC.

Next, stop and go processing inside software packages has evolved over the years. Older software resolved ambiguities with a static session at first, then processed the kinematic portions to maintain a float or better solution until the next "stop" point. Then it used a Kalman filtering technique to refine the stopped solution, so the LAST epoch of the stop segment was the most accurate and was stored as the final position of that shot. and so on...At the end of the field session you did another long static session. In the office the software looked at this session both forwards AND backwards, processing the end occupation as a static and running the solution towards the front of the file. The software then compared BOTH backwards and forwards processing solutions and reported the best positions.

More recent processing engines look at the whole file, pick the best reference sv, process the file looking for the best ambiguity resolution, throwing out bad sv's etc. and then the stop epochs are averaged as a group to get to the final position of the shot to be stored.

This allowed shorter stop sessions to be very precise (and accurate). 15 seconds of stop time is my personal MINIMUM, and I prefer 30 second stops at a 1 second rate. I still perform a 15 minute static session begin and end of the job and try to hit MANY points over again as intermediate check points during the job.

Remember, when sv's drop in and out of the solution the remaining sv's have to have enough data to keep the fixed solution. Static sessions before, after and during the stop and go work allow the software to "catch up" on fixing and maintaining good, precise solutions.

To me, stop and go is not a race. If you want to run with a prism pole then get an RTK system so you can see the solution on the screen and CONFIRM that you haven't lost lock. If you want to save the bundle of dollars using L1 stop and go, then slow down and take more data and some redundant measurements so you don't have to do the job twice...

I just arrive to the office after a long work in the countryside, and I found with this interesting discussion. I can tell that I have one thing clear: I must do several test by myself, as soon as I have time to do it, later I tell you how it go.

javier

I run 5 second observations all the time. I know folks who run 3 second observations.

The important things are:

1. Use record intervals of 1 second on both the base and rover.

2. Stop-and-Go: You need to STOP, wait for three or four epochs (3 or 4 seconds) then press the log key, wait for the timer to expire, wait an extra second, THEN go. Again: you HAVE to WAIT before you press the log button, after coming to a FULL AND COMPLETE STOP for three seconds.

3. Don't record points closer than 1 meter. If you do, every once in a while two points will get combined into a single point. The point will assigned the ID from the first point and the recorded location will be the average of the two points. (I am told this is a feature.)

If you need to record two points closer than 1 meter, record a dummy point a meter away and come back.

4. Don't expect to get cm accuracy.

5. Check in and out: set some static points around the grid, check in before and after. That way if you generate crap, you stand a chance to know it.

6. Consider purchasing a robotic gun.

M

That's interesting.

I too wait a few seconds before beginning a new point during S & G and I too am slow at removing the GPS when I'm done with the point.

but I'm not really sure why I do it.

i like a few help. am using promark3 for survey for preparing a contour map..i like to know how i can get a brief guidelines for an accurate survey..several time i got loss of lock and what should i do?? i use stop and go method for survey..lot of point i get get float solution..does it work under a tree?? how to prevent that??can i initialize on any point other than bar and what the time i should put for initialisation