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

[Gary E. Miller]

Yo Gerry!

On Fri, 2 Nov 2018 15:50:04 -0500
Gerry Creager - NOAA Affiliate <address@hidden> wrote:

> > I'm unfamiliar with 'pseudorange rate'.  Is that the same as
> > doppler? RINEX just wants pseudorange, carrierphase and doppler.
> > Doppler is the speed that each satellite is approaching or receding.
> >  
> 
> PRR is indeed doppler, expressed in m/sec. In the world I grew up in,
> doppler was a frequency rate change in hz/sec... Yes, I'm old.

Not that old.  I've been looking at what raw measurements GPS can
output and it was only very recently they seemd to read consensus.

> > Since we can't presently change the GPS receiver firmware, it would
> > have to be done in gpsd, or a gpsd client.  Easy to do, if gpsd
> > has the needed data and algorithms.
> >  
> 
> It's probably marginally do-able in gpsd, but is it worth it? PAGES,
> for example, is stand alone, reads RINEX, and computes the geodetic
> results as an application. Is it useful to overburden gpsd to add the
> functionality?

I'm almost done with a gpsd->RINEX converter.  So that would give us
PAGES.  RINEX is not well documented and the error messages from
RINEX software are near useless...


> > That is why gpsprof and ntpviz compute skewness, kurtosis, and much
> > more.  To clearly show that the data is not even close to a standard
> > distribution.  That has been misleading people for decades.
> >  
> 
> Any idea how long I've been preaching that mantra? My first paper on
> horizontal accuracy and achieving same computed skewness and kurtosis
> and the editors ripped hard-core statistics out as too much
> information/detail.
> 

Hehehe...

> 
> > > > I guess too much to ask for that code to be put in gpsd?  
> > > Depends on how we want to go about it. The decimation approach is
> > > a bit memory expensive but not too bad. Or write it to ramdisk or
> > > a temp file and process from there in a 2-step fashion.  
> >
> > Storage is cheap now.  I just looked at 512 GB SSD for $80.  Run
> > time not an issue since the raw data collection time already many
> > hours long. 
> 
> Sorta how I'm thinking. That's probably the best first-pass approach,
> is fast-epoch data collection, judicious decimation, and then
> averaging. Two strategies for the averaging are an average of the
> whole decimated dataset, or to process twice, removing, for the
> second and final average, obs where any coordinate is > 2SD out from
> the mean.

gpsprof already does long term basic averaging.  Maybe next year worth
revisiting how gpsprof calculates the best guess position.

Before that, I hope to see how post processed RINEX data compares to
the best guess from gpsprof.

RGDS
GARY
---------------------------------------------------------------------------
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

pgpHOSJm5Ko68.pgp
Description: OpenPGP digital signature