1 second vs 5 seconds

I believe it's still the case that OPUS only processes every 30 seconds. So even 5 seconds is overkill for OPUS. Recording at 5 seconds might be beneficial for processing in other applications.

MY receivers are currently set to collect @ 5 second epochs, BUT I ALWAYS decimate the files to 30 seconds before submitting to OPUS.

30 Second files are much easier to review and edit, AND (as Shawn pointed out above), OPUS decimates all files to 30 seconds anyway.

Loyal

does your receiver do more smoothing if you ask for a lower output rate? Does OPUS do smoothing to decimate or just keep some values intact and throw away the in-between samples?

In the signal processing work I did before retiring, we always used a smoothing filter according to the bandwidth of the signal of interest before we decimated samples. It's an important part of getting the most accurate answers.

I did an experiment with Teqc and found that it decimates by throwing out the extra samples and keeping the desired ones unaltered, no smoothing.

Given that another thread is debating whether 5, 10, or even 100(?) updates per SECOND is useful for base-rover corrections, it would seem suboptimum for Teqc to not do any smoothing to get down to 2 updates per MINUTE. It's throwing away information that might be beneficial.

I am pretty sure that OPUS just runs your file through TEQC with these options:

TEQC -R -C -S -E -O.dec 30s inputfile > outputfile

And I don't think that TEQC does any smoothing.

Actually, PAGES does a pretty good job of cleaning up your input file (fixing ambiguities) and there may be an advantage to not smoothing submitted data as the smoothing operation probably will cause PAGES headaches.

Decimating your file (and stripping SBAS, GAL, BDU and GLO observables) can significantly reduce the size of the submitted file. Zipping it can make it even smaller. For a 4-hour GNSS file with 1-second native observations, stripping-decimating-zipping can reduce the upload time from 10-minutes to 4-seconds at the crumby upload speeds we have at the office. As I am typically submitting 24-hour occupations it is definitely worth the time.

If I was using a memory limited receiver, I would record at 15-second intervals and never look back. If you can control the mask angle for observations, you should think about setting it to 8 degrees. This will save a little more space, but still allow the receiver to be fully locked when SVs reach 10 degrees which is the mask that (I think) OPUS uses internally.

M

I always collect static data at a 15 second epoch interval, unless I am using one of the old Ashtech Z12 then we collect at a 30 second interval because of memory. Whith the modest internet speeds we have at work, I can submitt about thirty 24 hour observations in one zip file without getting a timeout error.

Why not also use Hatanaka compression? https://www.unavco.org/data/gps-gnss/hatanaka/hatanaka.html

Mark Silver, post: 343835, member: 1087 wrote: Actually, PAGES does a pretty good job of cleaning up your input file (fixing ambiguities) and there may be an advantage to not smoothing submitted data as the smoothing operation probably will cause PAGES headaches.

Thanks for an important point.

An interesting article on the issue of decimation of GPS data is here: http://onlinelibrary.wiley.com/store/10.1029/1999GL010832/asset/grl12456.pdf?v=1&t=igu9w2kk&s=fc870435480e117031bc2a022aa293afd5830eed

Unfortunately, I do not know how NGS implements decimation.

Bill93, post: 343799, member: 87 wrote:
In the signal processing work I did before retiring, we always used a smoothing filter according to the bandwidth of the signal of interest before we decimated samples. It's an important part of getting the most accurate answers.

Yes, but as I understand it, there's not a whole lot of system-level improvement (for static users) from sampling faster, because of the nature of the noise processes.

Each carrier sample, taken say every 30 seconds, represents a snapshot of the carrier phase averaged over something like a 50 millisecond window (10 Hz carrier loop bandwidth). At first glance this is a recipe for massive aliasing, and indeed the white, stationary part of the noise ends up quite a bit larger than it would be had you taken samples every 20 milliseconds instead. But the other very non-white noises would hardly be helped at all---when it comes time to postprocess, and you're taking a giant average over 8 hours or 24 hours or whatever, the multipath process has similar amplitude whether you're sampling it at 30 seconds or frantically sampling it at 20 milliseconds. Over such long intervals, the thermal noise becomes microscopically small almost irrespective of the sample rate---it's the slow, drifty, Brownian, poorly characterized multipath/tropo/clock noises (and iono for single-frequency users) that dominate.

The book by Hegarty and Kaplan covers some of these issues, and there's a newer book by Pany focusing on software-receiver signal processing. The whole area is very interesting.

That must be a subscription service. I get "don't have permission" and not even bibliographic info.

That must be a subscription service. I get "Forbidden You don't have permission to access" and not even bibliographic info.

Thanks for the insight.

So in that other thread how is transmitting up to 10 corrections per second giving great improvement? The white noise and multipath will be independent at the base and rover so not helped by any corrections, only by longer averaging times, and the iono/tropo/clock drift reflected in the corrections are slow ...

With respect to the link problem. I accessed through Google Scholar. I am also a ResearchGate member. In any event...

Article is "Theoretically correct decimation of GPS data," by J.M. Sleewaegen of the Royal Observatory of Belgium. It appeared in the Geophysical Research Letters, Vol 26, No 24, pages 3713-3716, dated 15 Dec 1999.

Tried to post a JPEG of the abstract from my computer but couldn't figure how.

http://onlinelibrary.wiley.com/doi/10.1029/1999GL010832/pdf

I haven't digested it, but I note right away that he seems to be working with selective availability enabled, which means we have to be alert for which of his conclusions are still applicable.

Bill93, post: 343906, member: 87 wrote:
So in that other thread how is transmitting up to 10 corrections per second giving great improvement?

I'm not entirely sure. This white paper from Trimble mentions update intervals between 2 seconds and 60 seconds (2 seconds for the satellite clocks, >= 12 seconds for everything else):

http://www.trimble.com/positioning-services/pdf/whitepaper_rtx_fast.pdf

Even 2 seconds seems pretty fast for the satellite clock state. The rate of RTK updates and the rate of rover position solutions are two separate things, and I guess it's possible that for high-dynamics applications like machine control, the rover might want to run its filter at 10 Hz or even 50 Hz. (I have experience only with static.) But it would be inertially aided I assume---the GNSS component need not run so fast (I think).

But I could be wrong. For those RTK systems that update at 10 Hz, what could be changing so fast? Are they trying to track out some of the satellite carrier phase noise? (But doesn't it mostly drop out in the differencing?) I would also like to know.