[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] [gpsd] Altitude in TPV
Gary E. Miller
Re: [gpsd-dev] [gpsd] Altitude in TPV
Mon, 29 Oct 2018 15:17:09 -0700
On Mon, 29 Oct 2018 16:50:00 -0500
Gerry Creager - NOAA Affiliate <address@hidden> wrote:
> > The u-blox NEO-M8T reports psuedorange, carrierphase and doppler for
> > GPS, SBAS and GALILEO on the L1 band. I can't get the M8T to output
> > anything for GLONASS. That should be enough for RINEX 3.
> Is pseudorange rate in there, as well? If we've got range and phase,
> we can approximate rate and that'd give us a good shot ad solid 3d
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.
> Single-freq data didn't provide sufficient information in carrier
> phase to resolve either horizontal or vertical, save for RTK, and RTK
> never quite got vertical right although it was better than autonomous
> code phase L1 only. L5 was added to allow a civil code and carrier
> capability. L1C/L2C has mitigated that to a great extent. A lot of
> people have tried to make survey-quality results work with L1/code
> only, and have reported errors unsupported by repeats of their
> studies in an objective manner. You can get close, but it's not
> geodesy at that point.
I'm looking forward to the u-blox 9 series with its multiple frequency
support. That is why I'm trying to update gpsd for what that needs.
> > https://www.ngs.noaa.gov/GRD/GPS/DOC/pages/pages.html
> > FORTRAN 77. Wow. Serious stuff.
> Easy enough even a scientist can learn it.
Something to look at after RINEX support for gpsd.
> > Interesting. Worth some testing. Doing 4 hour data captures a lot
> > easier than 24 hour runs.
> It's actually in the makeup of the constellation. The geoid and
> ellipsoid are straightforward. There's plenty of computational
> horsepower and memory for those datasets and calculations in most
> receivers. I can't speak to the dongles, but even when I started
> playing with "low cost" board level GPS, the processors were
> hard-core and had lots of memory for the time.
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.
> I'll have to find the paper I wrote. Gotta have it somewhere. It
> was enough to get NGC to create NGS-58 at the time.
Wow, 2 cm accuracy 95% of the time, in 1997.
> > Wow, if it takes days of measurements to average then the post
> > processing of short data sets looks a lot better.
> Over time, sure. That said, 10 or so hours decimated will give you a
> good first guess, and you can augment it with another dataset, or 3,
> later improving the estimate. Just remember that your error is a
> least-squared error instead of simple standard deviation.
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.
> > 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.
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
Description: OpenPGP digital signature