gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gpsprof: higher resolution


From: Gerry Creager - NOAA Affiliate
Subject: Re: gpsprof: higher resolution
Date: Mon, 17 Aug 2020 22:48:19 +0000

Yo, Gary! (Love that salutation. I need to use it more overall)

On Sun, Aug 16, 2020 at 3:41 PM Gary E. Miller <gem@rellim.com> wrote:
Yo John!

> That's very interesting, Gerry.  I was aware that there is some 12
> and 24 hour periodicity that can affect averaging, but not of the
> mid-term noise.

The GPS sats return to the same position every 12 hours.  So averaging
over 12/24/36/48 hours removes odd orbital harmonics.  gpsprof
shows this effect.

Um, not exactly. There's also some orbital precession due to rotation. The orbit remains dynamic. I'll go see what you did in gpsprof. I suspect you did fix it. When I did this work, it was associated with real-world surveying projects, and looked at what we could get a surveyor to do. As a result, we looked at "How long must we wait?" which was also the title of the long-baseline single session dual-frequency surveying study. NGS confirmed the orbital harmonic issue in a clean-room parallel experiment. I didn't try to mitigate it, just noted it and moved on. Turned out that 4-11 hours was sufficient observation time, and we determined that it didn't get better with the original requirement for 3 different observations with complete tear down and setup in between.
 
> The averages I'm using for this set of tests are the values
> calculated by gpsprof.  I don't know if that does any decimation or
> not.

Nope.  gpsprof uses all the data it collects.  No 'decimation'.  Depending
on your definition of 'decimation', there is low pass filtering in applied
to the data.  That defeats the purpose of gpsprof in show how wild the
data excursions can be.

Turns out the autocorrelation contributes to the wild excursions. The definition of decimation is to use one ob and drop the next 9, rince, and repeat. My caveat wasn't against gpsprof, but of simple NMEA position capture and averaging. 

gpsprof does not care if the data came to gpsd as NMEA or binary.  gpsprof
just uses the gpsd JSON.  Often, but not always, the binary has more
digits of 'precision' than the NMEA.

Well, if you're collecting and averaging ALL the NMEA, the differences between binary collection of observables and subsequent postprocessing to determine a position, without autocorrelation will (or certainly should) show a more accurate positioning than averaging of receiver generated position either in binary or bia NMEA. This, of course, could have changed since I last pulled out the Red Books, but code-phase position determination regardless of how it's reported is supposed to use an autocorrelation function to improve time to location.
 
For the u-blox F9P: RELPOSNED is 1mm precision, and HPPOSLLH is 9
decimal degrees of precision.

For other 9-series POSLLH is 7 decimal digits of fractional degrees.

For the 9-series xxRMC is ddmm.mmmmm, which is about 6 decimal digit or
precision.

To get the most from the F9P requires binary messages, not NMEA, and
fiddling with the sentence mix.

And that is just the start of complications.  Some days have "good"
atmospheric conditions, other days not so much.

Not all scintillation, or wet-delay or multipath. 

For some reason, I suspect you and I are in violent agreement.

Gerry 
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin


--
Gerry Creager
NSSL/CIMMS
(C) 979.229.5301 <--- NOTE THAT MY OFFICE NUMBER HAS CHANGED
++++++++++++++++++++++
The way to get started is to quit talking and begin doing.
   Walt Disney

reply via email to

[Prev in Thread] Current Thread [Next in Thread]