Re: gpsprof: higher resolution

[Gerry Creager - NOAA Affiliate]

John

Heads-up that work I did a number of years ago demonstrated that there is an orbital geometry issue that manifests itself at single and multi-frequency long-occupation times. Simply, there is a dimunation of accuracy that's non-intuitive for long-term occupation post-processing that begins to manifest itself in the 10-12 hour timeframe, and remains an issue through 16-18 hours. By 24 hours, the anomaly appears to resolve. We never had the funding or independent time to chase this down but researchers at the National Geodetic Survey and I were of the opinion it was an issue with reintroduction of satellites to the visible constellation and was manifesting itself as a spherical harmonic anomaly in the handling of the ephemeris data. 

The short form is a recommendation that for short-duration recording, stop before 10 hours. For longer-term data, 24-30 hours, 48-60 hours, etc., provide long-term data that are suitable for post-processing. Also, a caveat I'm sure you're aware of, is before you simply average your NMEA data, decimate it to reduce the impact of autocorrelation in the standard position output.

Gerry

On Sun, Aug 16, 2020 at 10:59 AM John Ackermann N8UR <jra@febo.com> wrote:

On 8/16/20 11:29 AM, Greg Troxel wrote:
>
> John Ackermann N8UR <jra@febo.com> writes:
>
>> I just did a test of a u-blox M8P with very high quality RTK (data
>> from same antenna) and high precision (seven decimal place) NMEA
>> output. Running 12 hours of results through gpsprof yields CEP of a
>> few millimeters; very cool!
>
> Do you mean you used a splitter, and some other antenna to make an RTK
> feed, via ntrip, and then received that feed with gpsd and squirted it
> into the receiver, and the M8P did the RTK processing?   If so, posting
> the recipe would probably be interesting to many.

Yes, I've been doing a vast series of tests on seven u-blox modules (8
and 9 series). All are fed from a Trimble Zephyr Geodetic L1/L2 antenna
via several splitters.

The main focus is on timing performance, but I thought I'd do
positioning while I was at it.  So as a first step I collected 12 hours
of autonomous data and did gpsprof plots of each receiver.  (I would
have preferred 24 or 48 hours of data, but the deadline for my paper is
tomorrow. :-) )

On the same antenna is an old Trimble NetRS geodetic L1/L2 receiver
which spits out RTCM v3 messages on its serial port. Ultimately, I want
to set up a "real" ntrip caster on a Linux box, but for quick-and-dirty
I am feeding the RTCM into an instance of the "Snip" server on Windows.
Then the M8P or F9P is connected to u-center running on the same Windows
machine and the u-center ntrip client is turned on pointing to
localhost:2101.  I'm logging the data via u-center, then grep'ing the
GGA sentences out and feeding them into gpsfake/gpsprof.

This is *very* ugly but it was a quick and dirty way to do the test.
When I'm finished I'll wash my mouth out and start over again to build a
proper reference station setup.

> It sounds like you are logging NMEA, vs ublox binary via gpsd.  True?  I
> am curious why (not challenging; expecting to learn something).

As mentioned, this is a rush job and using NMEA seemed simpler given
that I didn't know when I started the collection runs just how I would
process the data.  Several of the receivers have the "high precision"
NMEA enable option that provides seven digits of resolution on the
minute value, rather than four, so I don't think it's giving up anything
to use NMEA in this instance.

> I am also curious if you have compared M8P internal RTK to rtklib.

No, but I did do a PPP measurement using NRCan and that gave a much more
reasonable seeming result for a single-freq receiver of 36mm lat, 41mm
lon, 65mm alt.

That's why I do wonder if the RTK results are real.  But since base and
rover are on the same antenna, you probably couldn't get better
correction data and maybe mm precision is possible in that case.  I
wouldn't expect it in the real world, though.

John

PS -- all this data will be in a paper I'm publishing in the proceedings
of the upcoming ARRL/TAPR Digital Communications Conference.  The
conference is being held virtually on Sep. 11 and 12, and I'll be doing
a presentation there. Info at: https://tapr.org/conferences/

--

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