Re: [gpsd-users] UBX-TIM-TP on F9T?

[Gary E. Miller]

Yo Anders!

On Fri, 4 Oct 2019 16:54:37 +0300
Anders Wallin <address@hidden> wrote:

> > > That sounds good! I will try looking at the current PPS message
> > > asap, and building from the latest gitlab when you have pushed
> > > this.  
> >
> > It is an easy message to parse.
> >  
> 
> with "ubxtool -e PPS" I do not see a PPS message on the gpsd debug
> output or receiving messages with python.

Big jumps there.  Some details: 

This has nothing to do with the JSON: "ubxtool -e PPS".  If you can
point to any doc that suggested that it needs to get fixed.

There are many ways to build gnsd that result in no PPS.  Rather that
walk you through all the possible mistakes, can you supply the output
from when you configured your gpsd?

Also, unless a client is running, the PPS is not sent, even in debug mode.

Here is the easy way to see the PPS messages:

# gpspipe -w -n 30 | fgrep PPS
{"class":"PPS","device":"/dev/ttyS0","real_sec":1570212884,"real_nsec":0,"clock_sec":1570212884,"clock_nsec":846,"precision":-20,"qErr":-627}
{"class":"PPS","device":"/dev/ttyS0","real_sec":1570212885,"real_nsec":0,"clock_sec":1570212885,"clock_nsec":87,"precision":-20,"qErr":-7264}
{"class":"PPS","device":"/dev/ttyS0","real_sec":1570212886,"real_nsec":0,"clock_sec":1570212886,"clock_nsec":729,"precision":-20,"qErr":8438}
{"class":"PPS","device":"/dev/ttyS0","real_sec":1570212887,"real_nsec":0,"clock_sec":1570212887,"clock_nsec":1025,"precision":-20,"qErr":4603}
{"class":"PPS","device":"/dev/ttyS0","real_sec":1570212888,"real_nsec":0,"clock_sec":1570212888,"clock_nsec":508,"precision":-20,"qErr":-3407}
{"class":"PPS","device":"/dev/ttyS0","real_sec":1570212889,"real_nsec":0,"clock_sec":1570212888,"clock_nsec":999999718,"precision":-20,"qErr":9063}

You will not see the "qErr" yet.

> I do however see a TOFFS message with the same fields as your
> PPS-message above - is that correct? Would the qErr field show up in
> class=TOFFS in my case with the F9T?

The TOFF is about the timming of the NMEA messages.  The PPS is about
the timing of the PPS.  The messages are identical, now.  After I 
finish my changes, and make a push, the the PPS may have "qErr"
if that data is available and valid.

> > You saw gpsrinex?  Is that useful?
> >  
> 
> yes at minimum gpsrinex.c shows how to generate valid RINEX3.

Note that "valid RINEX3" is very subjective!

> Some older tools will want RINEX2, and most analysis wants a single
> 24h GPS-time day (30s interval) starting at 00:00:00 and ending at
> 23:59:30.

I played with RINEX2.  My take was the value of the data was not worth
the effort.  

gpsrinex is configurable, so 24h at 30 second intervals is trivial.  My
testing shows that anything past 6 hours add very little, if any, value.

> I keep looking at the u-blox doc.  I can not find where they say to
> > add, or subtract, qErr from the measured PPS time.  Do you know?
> >  
> 
> We should be able to verify the sign/usage of qErr once we get a bit
> further. We can measure the PPS-signal from the F9T against a stable
> atomic clock and see what sign of qErr smooths the data.

I have an Rb, but no way to line up the data as needed.  You'll just have
to tell me if I guessed wrong.

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

pgplQC10iiRc6.pgp
Description: OpenPGP digital signature