[Top][All Lists]

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

Re: [gpsd-dev] [gpsd] Altitude in TPV

From: Gerry Creager - NOAA Affiliate
Subject: Re: [gpsd-dev] [gpsd] Altitude in TPV
Date: Mon, 29 Oct 2018 14:44:22 -0500

I'll keep this here for the lurkers who might find it interesting, but we might end up following up offline. Geeking might occur.
On Mon, Oct 29, 2018 at 2:18 PM Gary E. Miller <address@hidden> wrote:
Yo Gerry!

On Mon, 29 Oct 2018 14:09:01 -0500
Gerry Creager - NOAA Affiliate <address@hidden> wrote:

> Long delayed response (work got in the way of looking at hobby-related
> emails...)

Work happens.

I had to update the supercomputer last week. All last week. 49 hours on the clock last week, the first 10 spent downloading the software I needed after downloading the patches I had been told were required the week before. Long week.

Work, indeed, happens.
> > I have an L1/L2/L5 GPS.  I was expecting great things, but never saw
> > them for real time measurements.
> > 
> Not so much in code phase. Long term averaging of data collected at a
> fixed interval (e.g., 10-30 sec) then decimated would give a better
> representation. We can talk about the need to decimate if you'd like.

I'm currently working on adding RINEX 3 support to gpsd.  At least for
the u-blox and GREIS GPS receivers.  That can give cm accuracy when
long term data is uploaded for post-processing.

Are you recovering carrier or solely code-phase for the three frequencies in your dataset? 

Any way to improve accuracy without internet postprocessing would be

Code exists. I'm partial to PAGES, originally by Mark Schenewerk when he was at the National Geodetic Survey HQ in Silver Spring. Most of the big surveying companies (Trimble, Astech, Javad, etc.) have only proprietary codes to perform the network adjustments. There is MATLAB code available to do it, and if we can relocate a copyof PAGES, that works, too. 
Right now all gpsd can do is long term averaging with gpsprof.  Good
results with gpsprof requires observations in multiples of 24 hours
to get the best results.  Diurnal effects are large.

I believe the diurnal effects may actually be related to a spherical harmonic-induced perturbation to satellite ephemerises. Regardless of the start and stop times imposed, I found that observing times of 4-11 hours (plus/minus) gave the best results for getting height data, but for that matter, also the best for horizontal data, although the horizontal error was smaller overall than the vertical/spherical error. In other words, if I started observing at 12z and stopped observing at 04z, the last 5 or so hours had poorer horizontal and spherical accuracies. By 21 hours of observation, or maybe 22, things slowly started reverting but the solution didn't improve 'til we were at the multi-day point. However, if the observing period was in the range of ~4-11 hours, things were good.

Simple code-phase solutions are temporally autocorrelated. Decorrelation by decimation of a long timeseries dataset, measured in days, with decorrelation to 45-60 sec, or even longer, will improve the long-term average results. In years past, I averaged a lot of L1 code position report averages; the use of decimation was recommended to me by one of the NGS geodesists, rather than being independently derived. I did expand on the decimation parameters, to optimize the result, however.


Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  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
“Big whorls have little whorls,
That feed on their velocity; 
And little whorls have lesser whorls, 
And so on to viscosity.” 
Lewis Fry Richardson (1881-1953)

reply via email to

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