Re: moving to 8 digits of lat/lon (gpxlogger, maybe elsewhere)?

[Greg Troxel]

"Gary E. Miller" <gem@rellim.com> writes:

> Yo Greg!
>
> On Thu, 03 Sep 2020 14:48:03 -0400
> Greg Troxel <gdt@lexort.com> wrote:
>
>> I newly have an F9P, and have gotten it to work in RTK mode with the
>> MaCORS ntrip server, just by adding the ntrip:// URL with a mountpoint
>> for MSM, single base, specific station sort of nearby.  At least, the
>> "no RTK" light goes out, and the position wander as seen in josm
>> pointing to gpsd is very small, less than 1m p-p over a few hours,
>> indoors.
>
> Cool.  I have not had such luck with NTRIP a mile away...

will post more as I make progress.

>> I noticed that gpxlogger prints only 6 fractional digits of lat/lon.
>> This is 10cm, and I was seeing many adjacent samples with the same
>> values.  RTK receivers are making cm-level claims for accuracy, and
>> short-term stability may be better.
>
> And some u-blox reports lat/lon to 1e-9 degrees and altitude to 0.1
> mm. See F9P:  UBX-NAV-HPPOSLLH

well, I guess that's 10x more.

> What gpxlogger reads (gpsd) would also have to move to $.8f, so the
> JSON has enough data for you.  Then the other clients.  So a total
> rebuild of all the regressions, which is actually pretty simple to do.

I am a bit shy of rebuilding regression tests myself.  Perhaps I will
stage things on a branch, keep it rebased, and you can review,

>> And, this is a general proposal that whenever anything in gpsd does
>> lat/lon, it uses %.8f, basically, and %.3f for height (in meters of
>> course, and hence mm).a
>
> Works for me.  Maybe evenn %.9f degrees and %.4f meters, so we don't need
> to do again soon.

seems maybe a bit much, but "don't do it again" seems wise, so that's ok
and I will head for that.

signature.asc
Description: PGP signature