gpsd-dev
[Top][All Lists]
Advanced

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

Re: gpsprof: higher resolution


From: John Ackermann N8UR
Subject: Re: gpsprof: higher resolution
Date: Sun, 16 Aug 2020 14:17:26 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

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. For the purposes of my current work (which is mainly comparative performance) I don't think it's an issue, but certainly something to keep in mind where the results matter.

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.

Thanks for the info!

73,
John
----

On 8/16/20 1:41 PM, Gerry Creager - NOAA Affiliate wrote:
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 <mailto:jra@febo.com>> wrote:

    On 8/16/20 11:29 AM, Greg Troxel wrote:
     >
     > John Ackermann N8UR <jra@febo.com <mailto: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
/



reply via email to

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