Static Data Collection Rates

[sireath]

How many base stations are you having for the observations?

How long are you going to observe for?

Generally I am getting good results on 2 1hr observations under clear sky at 10s epoch. 1s gave me too much noise during the processing.

Planning software helps a little but do open up the weather forecasts too. When there is a thunderstorm in the vicinity even, my results gets screwy.

Hope this helps you somewhat.

Cheers,

[conrad]

sireath, post: 350362, member: 9370 wrote: How many base stations are you having for the observations?

How long are you going to observe for?

Generally I am getting good results on 2 1hr observations under clear sky at 10s epoch. 1s gave me too much noise during the processing.

Planning software helps a little but do open up the weather forecasts too. When there is a thunderstorm in the vicinity even, my results gets screwy.

Hope this helps you somewhat.

Cheers,

Hey sireath,

I’m sorry I didn’t put it in the OP. 1 hour was to be the session length with a receiver set up at each end – just a single baseline. No thunderstorms. Do you think you could push it out a little without a change in the solution? say 10s or 30s intervals?

[conrad]

Hello Peoples,

I’m sorry but sireath’s post highlighted my omission. I meant to say 1 hour was to be the session length on this 13km (8 miles) baseline.

[pmoran]

Con-
A good recipe to use when planning your static sessions with modern equipment is 10 minutes plus a mile a minute or km. This should resolve any vector as long as you’re not dealing with obstructions. In your scenario I don’t see any mention of existing control.

[dave-karoly]

5 second epochs is more than you will ever need. That is what I do as a default.

I’ve done 1 second epochs while the airplane was in the air but that was for a GPS controlled orthophoto.

[jhframe]

I do 15 second epochs out of old habit. It works well with 1-hour sessions on baselines in the 10 km range.

[Norman_Oklahoma]

pmoran, post: 350413, member: 8922 wrote: A good recipe to use when planning your static sessions with modern equipment is 10 minutes plus … a minute (pe)r km.

For an 8 mile (13km) vector that would make 23 minutes, which seems about right. Say a half hour. I like to collect at a rate that gives me 30-50 epochs in a session at a minimum. 30 minutes at a 30 second rate would satisfy that. If you are set on doing 1 hour sessions then 30 second epochs will be plenty.

Above 20 km it’s 1 hour bare minimum. 20 km is the threshold for atmospheric modelling.

For a shorter vector where the occupation was only 10 minutes, or less, 30 second epochs would not satisfy that 30-50 epoch limit, so I’d up the collection rate. In practice I usually set it to 5 seconds and just leave it there. You can always decimate that data at the office. Memory is pretty cheap. If you decide to break up your data into smaller chunks you will still have enough epochs.

Back when I started doing GPS in the 1990’s a 2Mb data card cost several hundred dollars and could be filled up in a day, easy. Epoch rates were a big deal. Nowadays gigabytes can be purchased for pocket change in the checkout line at Target. Dial it up.

[conrad]

Thanks for the replies guys.

I have my data and just for fun I decimated it at different intervals to see how this 1 hour baseline would process at different rates. I collected and processed at 1s, but also decimated and processed 2s, 5s, 10s, 20s, 30s, 60s, 120s, 180s, 240s and 300s. Well, apparently it makes no noticeable difference whatsoever to the results in horizontal or vertical directions until 180s at which point the ambiguities fail to resolve. So collecting data at 2 minute intervals was fine for the conditions over my baseline/vector/whatever.

To keep the fun going, I decided to process to some CORS stations, one 40km+ away and another just over 100km+ away. Again, no difference beyond a mm here or there until failure to fix at 180 second intervals and above. 30 evenly spaced observations were enough to resolve a 100km+ baseline under good conditions over a 1 hour session.

Well just to see how far this deal goes I did the 40km+ baseline for a session length of 20 mins. Again out to a collection rate of 1 shot every 2 minutes the baseline fixed and showed about 6mm total spread of positions between all the fixed collection rates. So 10 observations over a 20 minute period fixed the baseline about as well as any shorter rate.

So it seems under good sky conditions a high collection rate is overrated, but most experienced users probably know this already. I’d almost go so far as to say, as long as the baseline fixes it’s almost irrelevant. I need to repeat experiment under average and poor conditions and see how things go.

[sireath]

Hi Conrad,

Am interested to see the baseline report and the network report. Looks interesting to study.

Possible to email me at j a n l o i @ h o t m a i l .com

Thanks

[RCliffWilkie]

Fifteeen seconds is the default I have used for years. I have not done any testing of this, dbut do know that faster rates for static positioning are not going to make any difference. What people “normally” use has varied over the years during the development of GPS static positioning. Years ago, Wild equipment recommended 1 minute epochs and they worked fine. For several years I used 30 second epochs just because it was a manufacturer’s recommendation. Then I switched to 15 seconds for the same reason. The tests done by Conrad are very interesting and bear out that it really doesn’t make much difference up to three minutes. Ultimately you don’t want to use a rate that will make the data files too big.

What it really comes down to is how much satellite postitions vary from the predicted orbit over the time interval. GNSS is so far above the earth that it is not affected much at all by local gravity anomalies. In other words during a one minute interval a GNSS satellite covers quite a bit of ground/space but the orbital path is very predictable. So you want an epoch rate that is as large an interval as is readily predictable by the ephemerides and the processing software. From the tests done by Conrad it sounds like three minutes is about the maximum interval. Longer than that and his software is no longer able to predict positions and initialize ambiguities to the correct integer values. This limit may vary with different software packages and different ephemerides.

[john-putnam]

I think the length of baseline is a red herring. In post processing you are trying to track multiple satellites for the purpose of trilateration from multiple receivers simultaneously. The length of the simultaneous observation to solve is related to the distances between receivers. The recording epoch rate just affects the number of trilateration’s that are calculated at any given receiver. For an 8 minute fast static observation at a 15 seconds epoch rate you get 32 points of data while you get 480 if you observe for 2 hours of static data at the same rate. For the same observations at a 5 second rat you get 96 & 1,440 points of data. It does not take a large number data points to precisely track the satellite as it transits above the receiver and the redundant data points do not significantly increase the accuracies of the resulting positions. Greater data collection rated do substantially increase storage requirements though. For fast static observation I have found that a 5 second rate is more than adequate and 15 seconds even okay.

Kinematic GNSS posses a slightly different problem. You only get fixed positions for the data point and anything else in interpreted. The shorter the distance between data points the better the interpretation of the point. If you are driving around on your ATV a 1hz rate might be fine but an jet propelled aerial mapping platform covers quite a bit of ground in 1 second so then you start looking at 2hz and 5hz rates. In my first receiver memory went for about $1000 per meg and it took hours to download 10 megs over a serial cable.

Just my 25 cents worth.

[Bob LeMoine]

I would recommend using a Epoch Recording Interval of 5-seconds. Collect 30-minute Occupations.

Apply the 5-minute minimum Observation, plus 1 Additional minute of Observation time for each KM of separation between stations/GPS Antennas/Smart Antennas.

5 Minimum SV’s, PDOP IMHO, 30-Minute Fast/Rapid Static GNSS Observations are what you should be collecting, fool proof GNSS Post-Processing production work.
-BbB B-)

[spledeus]

I would have added a 3rd GPS within 10 km of both ends. Preferably over a control point or logging for more than 2 hours for an OPUS check. I am not usually in the polygon so OPUS RS is outside of my normal techniques.
I use 5 second in the hipers since the memory is just about full as the batteries peter out.
I use 1 second in the legacy Sokkia units since I can.
I use 1 second in the CHC X91Rs since I can.
Downsampling is an option, upsampling is magic.

[Bob LeMoine]

Have you han an opportunity to take the NGS OPUS Projects Class yet?
This NGS OPUS Projects class delineates pretty much the same field procedure/deployment as you described.
Good luck, these GNSS Receiver recommendations, the 5-second Epoch Recording Interval will cover all your bases, it’ll work for classic NGS OPUS + for NGS OPUS RS.
-BbB B-)