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

[Gary E. Miller]

Yo Anders!

On Sun, 6 Oct 2019 21:04:14 +0300
Anders Wallin <address@hidden> wrote:

> I might be slowly making progress..
> the scons options are now: https://pastebin.com/CgC76V29

Yeah, not good.  Can you provide the build log to see why?

> I've now connected two serial-ports, one for the serial data stream
> from the F9T (as previously), and a new one with the electrical 1PPS
> connected to DCD.

So NEMA on UBS and PPS on Serial.  Why not both on the one
serial port?

> Then through much googling I found how to create a pps-device with
> "ldattach PPS /dev/ttyUSB1"

Yes, I guess gpsd should document that a bit better.  It is automatic when
on the same port of the NMEA serial.

> $ sudo ppswatch /dev/pps0

"sudo" is a really bad habit...

> trying PPS source "/dev/pps0"
> found PPS source "/dev/pps0"
> timestamp: 1570384123, sequence: 4881, offset:  99547497
> timestamp: 1570384124, sequence: 4882, offset:  99560566
> 
> I have tried to make it use the 'assert' edge instead of the 'clear'
> edge, but this doesn't seem to do anything:

It is not "using" either edge.  it is just reportingboth edges.

> $ sudo ppsctl -fa /dev/pps0
> trying PPS source "/dev/pps0"
> found PPS source "/dev/pps0"
> (ppswatch and ppstest still give similar results as above, where
> offset corresponds to the 100ms long pps-pulse, since it seems to
> trigger on clear)

Once again, nothing is "triggered", yet.

> Now, starting gpsd with
> $ sudo gpsd -D 5 -N -n /dev/pps0 /dev/ttyUSB0
> I get output like so:
> gpsd:INFO: PPS:/dev/pps0 Assert hooks called clock:
> 1570384257.000356140 real:  1570384257.000000000: accepted
> gpsd:PROG: PPS:/dev/pps0 Assert accepted @  1570384257.000356140
> offset -0.000356140

Yup.  Notice that gpsd automagically dtects the correct edge.

> gpsd:PROG: PPS:/dev/pps0 Clear ignored 1Hz trailing edge
> (maybe that is all OK?)

Yup, gpsd picked the correct edge, and ignored the other one.

> modifying /etc/ntp.conf to used shared memory drivers also seems to
> work:

Yup.

> (I have used fudge, to correct for the 100ms long pps-pulse)

Don't do that!  You just broke the autodetect!

> $ ntpq -np
>      remote           refid      st t when poll reach   delay   offset
>  jitter
> ==============================================================================
>  127.127.28.0    .GPS.            0 l    -    8  377    0.000    0.188
> 0.408
>  127.127.28.1    .PPS.            0 l    7    8  377    0.000    3.361
> 0.242

Uh, what about your other sources?  NTP needs at least 3 sources to "cluster"
and the "GPS" one does not count.

> However I still don't get a PPS JSON message, connecting with e.g.
> cgps, or a simple python script (below).

And you have still not provided the output of your build process.

> the JSON classes I see are: RAW, TOFF, TPV
> (SKY has disappeared, for some reason..)

You turned off reconfiguration, so you need to manually ensure
the propoer sentences are being sent.

> I don't understand how the WATCH-bitmask works, since I'm trying to
> enable WATCH_TIMING, but the JSON WATCH message shows false.

You are getting TOFF, so you are setting the WATCH_TIMING.

> --python test client--------------------------
>         if report['class']=="WATCH" or report['class']=="VERSION" or
> report['class']=="TOFF" or report['class']=="DEVICES":

Why are you not looking for PPS?

> 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.

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

pgpQM6cXKecbj.pgp
Description: OpenPGP digital signature