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

[Gary E. Miller]

Yo Anders!

On Tue, 8 Oct 2019 19:15:14 +0300
Anders Wallin <address@hidden> wrote:

> >  
> > > TOFF
> > > <dictwrapper: {u'clock_sec': 1570384595, u'class': u'TOFF',
> > > u'device': u'/dev/ttyUSB0', u'real_sec': 1570384595,
> > > u'clock_nsec': 109164451, u'real_nsec': 249441}>  
> >
> > Looking good, you just need the PPS.
> >  
> 
> Some further progress today. Instead of two separate serial ports
> (one for data, one for PPS) I now wired the 1PPS to the DCD-pin of
> the data port. With one single serial port with data+pps there is no
> need for creating the pps-device manually (ldattach), as Gary noted
> before.

Not an option on the Raspberry Pi, or similar, but easiest when possible.

> But how do I now check the PPS using ppswatch/ppstest? I
> don's see a /dev/pps0 or similar.

If you run gpsd on the serial port, it does the ldattach dance for you
and creates the /dev/ppsX for you.

Otherwise, nothing changed, you run the ppsXXX programs on the device
with the PPS.

This works with gpsd runing, or not:

# ppscheck /dev/ttyS0
# Seconds  nanoSecs   Signals
 1570561000.000059734
 1570561000.100038401 TIOCM_CD
 1570561001.000038279
 1570561001.100034774 TIOCM_CD
[...]


If gpsd is running, then it has created the /dev/ppsX for you:

# ppsfind /dev/ttyS0
pps2: name=serial0 path=/dev/ttyS0

The you can use that ppsX:

# ppstest /dev/pps2
trying PPS source "/dev/pps2"
found PPS source "/dev/pps2"
ok, found 1 source(s), now start fetching data...
source 0 - assert 1570561646.100096751, sequence: 20 - clear  
1570561647.000085073, sequence: 21
source 0 - assert 1570561647.100081980, sequence: 21 - clear  
1570561647.000085073, sequence: 21

# ppswatch /dev/pps2
trying PPS source "/dev/pps2"
found PPS source "/dev/pps2"
timestamp: 1570561678, sequence: 52, offset:  51039
timestamp: 1570561678, sequence: 52, offset:  51039
timestamp: 1570561679, sequence: 53, offset:  50877

> This helped, and gpsd now also reports a PPS JSON-message, containing
> the qErr from UBX-TIM-TP.

Good.

> A remaining issue is that with a simple python script (
> https://pastebin.com/NWCYe5w6) I now see two PPS JSON-messages per
> second, like so:
> 2019-10-08 15:49:34.000544 PPS  real: 1570549774 . 0  clock:
> 1570549774 . 95427  qerr: 3682
> 2019-10-08 15:49:34.272920 PPS  real: 1570549774 . 0  clock:
> 1570549774 . 95427  qerr: 3682

I suspect you are reusing stale data.

> The PPS-message appears repeated (with identical content), both close
> to the inter-second boundary, and at around +270ms (the length of the
> electrical pulse should be 100ms, as before)
> This might be related to the cycle-start detector warning I see on
> gpsd? gpsd:WARN: cycle-start detector failed.
> (repeated once per second)
> any ideas?

Why is your cycle start filing?  What is your sentence mix?  How did you
configure your GNSS receiver?

> if it makes any difference, ntpq-output is below, with zero fudge in
> ntp.conf. The machine is synchronized to many stratum-1/2 servers.
> 
> gpspipe -w only shows one PPS-message per second. I don't understand
> why gpspipe -w and my python code give different results (1 vs 2 PPS
> JSON messages per second)

I trust gpspipe to do the right thing.  Recheck your code.

> $  ntpq -np

reasonable results.

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

pgpcqGBm7a9ji.pgp
Description: OpenPGP digital signature