• gpsd no PPS output

    From Jim Pennino@21:1/5 to All on Wed Jul 28 09:56:27 2021
    Using Ubuntu 20.04.2 and gpsd 3.20.

    I replaced the long running USB GPS with a serial device, reconfigured
    and rebooted.

    NMEA data is just fine and ppscheck works but gpsd is not processing the
    PPS signal on CTS.

    ppstest and ppswatch fail, xgps does not show PPS, and ntpshmmon shows
    only NTP0, i.e. not NTP1 and NTP2.

    I ran gpsd as a regular user with -D3 -N to look for errors but it
    looked OK and was accepting PPS. ntpshmmon showed NTP2 and NTP3 and xgps
    did show PPS.

    Guessing it was some sort of permissions issue I had introduced over the
    years, I did an apt purge gpsd, apt install gpsd and started fresh with
    a reboot.

    No change.

    Thinking maybe apparmor was doing something, I stopped it and did a
    teardown.

    No change.

    Now I have no clue...

    Any suggestions?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to Jim Pennino on Wed Jul 28 20:03:03 2021
    On 07/28/21 17:56, Jim Pennino wrote:
    Using Ubuntu 20.04.2 and gpsd 3.20.

    I replaced the long running USB GPS with a serial device, reconfigured
    and rebooted.

    NMEA data is just fine and ppscheck works but gpsd is not processing the
    PPS signal on CTS.

    ppstest and ppswatch fail, xgps does not show PPS, and ntpshmmon shows
    only NTP0, i.e. not NTP1 and NTP2.

    I ran gpsd as a regular user with -D3 -N to look for errors but it
    looked OK and was accepting PPS. ntpshmmon showed NTP2 and NTP3 and xgps
    did show PPS.

    Guessing it was some sort of permissions issue I had introduced over the years, I did an apt purge gpsd, apt install gpsd and started fresh with
    a reboot.

    No change.

    Thinking maybe apparmor was doing something, I stopped it and did a
    teardown.

    No change.

    Now I have no clue...

    Any suggestions?


    One possibility might be that the pps is at ttl level, while a serial
    post needs rs3232 +/- levels to trigger properly. You can buy ttl to
    rs232 board level adapter for a few $ on Ebay, which is what i'm
    using here. Single supply line, 5 or 12 v, don't remember, that you
    can tap off from the host b/board...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Wed Jul 28 12:22:04 2021
    chris <chris-nospam@tridac.net> wrote:
    On 07/28/21 17:56, Jim Pennino wrote:
    Using Ubuntu 20.04.2 and gpsd 3.20.

    I replaced the long running USB GPS with a serial device, reconfigured
    and rebooted.

    NMEA data is just fine and ppscheck works but gpsd is not processing the
    PPS signal on CTS.

    ppstest and ppswatch fail, xgps does not show PPS, and ntpshmmon shows
    only NTP0, i.e. not NTP1 and NTP2.

    I ran gpsd as a regular user with -D3 -N to look for errors but it
    looked OK and was accepting PPS. ntpshmmon showed NTP2 and NTP3 and xgps
    did show PPS.

    Guessing it was some sort of permissions issue I had introduced over the
    years, I did an apt purge gpsd, apt install gpsd and started fresh with
    a reboot.

    No change.

    Thinking maybe apparmor was doing something, I stopped it and did a
    teardown.

    No change.

    Now I have no clue...

    Any suggestions?


    One possibility might be that the pps is at ttl level, while a serial
    post needs rs3232 +/- levels to trigger properly. You can buy ttl to
    rs232 board level adapter for a few $ on Ebay, which is what i'm
    using here. Single supply line, 5 or 12 v, don't remember, that you
    can tap off from the host b/board...

    Nope, this is a RS-232 device connected to a RS-232 port and as I said, ppscheck works fine and PPS seems to get processed if gpsd is run as an ordinary user, but not if started by root and run as gpsd.

    This is NOT a hobby device.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to chris on Wed Jul 28 19:30:33 2021
    On 2021-07-28, chris <chris-nospam@tridac.net> wrote:
    On 07/28/21 17:56, Jim Pennino wrote:
    Using Ubuntu 20.04.2 and gpsd 3.20.

    I replaced the long running USB GPS with a serial device, reconfigured
    and rebooted.

    NMEA data is just fine and ppscheck works but gpsd is not processing the
    PPS signal on CTS.

    ppstest and ppswatch fail, xgps does not show PPS, and ntpshmmon shows
    only NTP0, i.e. not NTP1 and NTP2.

    I ran gpsd as a regular user with -D3 -N to look for errors but it
    looked OK and was accepting PPS. ntpshmmon showed NTP2 and NTP3 and xgps
    did show PPS.

    Guessing it was some sort of permissions issue I had introduced over the
    years, I did an apt purge gpsd, apt install gpsd and started fresh with
    a reboot.

    No change.

    Thinking maybe apparmor was doing something, I stopped it and did a
    teardown.

    No change.

    Now I have no clue...

    Any suggestions?


    One possibility might be that the pps is at ttl level, while a serial
    post needs rs3232 +/- levels to trigger properly. You can buy ttl to
    rs232 board level adapter for a few $ on Ebay, which is what i'm
    using here. Single supply line, 5 or 12 v, don't remember, that you
    can tap off from the host b/board...

    Although a theoretical possibility, it is highly doubtful, as most
    serial cards do NOT follow the standard for rs232 ports, but will
    happily use TTL levels. This has been true now for about 40 years I
    believe. One problem with the adapters is that they can easily introduce
    delays into the signal. They may well be inconsequential for your
    purposes, and I would expect them to be on the microsecond level, but do
    not know for sure.

    You do need something to actually respond to the serial port interrups--
    ie a serial port interrupt driver. Linux includes on


    I have a "gps" script in /etc/init.d

    ------------------------------

    #! /bin/sh
    #
    # gps Support for NTP i gps clock.
    #
    # chkconfig: 345 70 15
    # description: gps is a module to read the PPS from a gps parallel port
    # clock and start the shm ntp daemon to deliver the time to ntp.
    #
    # processname: gps

    # Get config.
    . /etc/sysconfig/network

    # Get functions
    . /etc/rc.d/init.d/functions

    module="gps"
    device="gps"
    mode="664"
    group=wheel

    echo gsp $1 >>/tmp/gps

    # See how we were called.
    case "$1" in
    start)
    echo "Starting gps pps service"
    modprobe pps-ldisc
    ldattach 18 /dev/ttyS0
    ;;
    stop)
    echo "Stopping gps pps service"
    killall ldattach
    ;;
    status)
    status ldattach
    ;;

    restart)
    $0 stop
    $0 start
    ;;

    *)
    echo "gps wildcard">>/tmp/gps
    gprintf "Usage: gps {start|stop|status|restart}\n "
    exit 1
    ;;
    esac

    exit 0

    ----------------------

    I do not use gpsd however.





    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to William Unruh on Wed Jul 28 13:28:09 2021
    William Unruh <unruh@invalid.ca> wrote:

    <snip old stuff>

    You do need something to actually respond to the serial port interrups--
    ie a serial port interrupt driver. Linux includes on


    I have a "gps" script in /etc/init.d

    gpsd does all that for you and simplifies configuration, which is why
    I'm using gpsd at all.

    I did a modprobe check to make sure all the pps stuff was loaded; it
    was.

    Next is a post to the gpsd support group.

    If all else fails, gpsd gets dumped and ntpd gets configured for the
    NMEA interface.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to Jim Pennino on Wed Jul 28 22:18:32 2021
    On 07/28/21 20:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/28/21 17:56, Jim Pennino wrote:
    Using Ubuntu 20.04.2 and gpsd 3.20.

    I replaced the long running USB GPS with a serial device, reconfigured
    and rebooted.

    NMEA data is just fine and ppscheck works but gpsd is not processing the >>> PPS signal on CTS.

    ppstest and ppswatch fail, xgps does not show PPS, and ntpshmmon shows
    only NTP0, i.e. not NTP1 and NTP2.

    I ran gpsd as a regular user with -D3 -N to look for errors but it
    looked OK and was accepting PPS. ntpshmmon showed NTP2 and NTP3 and xgps >>> did show PPS.

    Guessing it was some sort of permissions issue I had introduced over the >>> years, I did an apt purge gpsd, apt install gpsd and started fresh with
    a reboot.

    No change.

    Thinking maybe apparmor was doing something, I stopped it and did a
    teardown.

    No change.

    Now I have no clue...

    Any suggestions?


    One possibility might be that the pps is at ttl level, while a serial
    post needs rs3232 +/- levels to trigger properly. You can buy ttl to
    rs232 board level adapter for a few $ on Ebay, which is what i'm
    using here. Single supply line, 5 or 12 v, don't remember, that you
    can tap off from the host b/board...

    Nope, this is a RS-232 device connected to a RS-232 port and as I said, ppscheck works fine and PPS seems to get processed if gpsd is run as an ordinary user, but not if started by root and run as gpsd.

    This is NOT a hobby device.



    Worth a try. It was the problem on the setup here, a s/hand 1u
    time tools gps ntp server, and a micro atx motherboard running FreeBSD.
    The time tools pps is ttl, as are all the other gps do boxes here, from
    several vendors collected over the years. While such mismatch may
    work with some interfaces, there's no guarantee, as the voltage levels
    are incorrect. Even if it does work, there may be excessive jitter,
    which doesn't help performance. Propagation delay using a drive chip is
    only 10's of nS, havng measure it on a scope, so can be ignored.

    If the only thing changed is the serial card then it's most likely
    something related...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to chris on Wed Jul 28 22:24:49 2021
    On 07/28/21 22:18, chris wrote:
    On 07/28/21 20:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/28/21 17:56, Jim Pennino wrote:
    Using Ubuntu 20.04.2 and gpsd 3.20.

    I replaced the long running USB GPS with a serial device, reconfigured >>>> and rebooted.

    NMEA data is just fine and ppscheck works but gpsd is not processing
    the
    PPS signal on CTS.

    ppstest and ppswatch fail, xgps does not show PPS, and ntpshmmon shows >>>> only NTP0, i.e. not NTP1 and NTP2.

    I ran gpsd as a regular user with -D3 -N to look for errors but it
    looked OK and was accepting PPS. ntpshmmon showed NTP2 and NTP3 and
    xgps
    did show PPS.

    Guessing it was some sort of permissions issue I had introduced over
    the
    years, I did an apt purge gpsd, apt install gpsd and started fresh with >>>> a reboot.

    No change.

    Thinking maybe apparmor was doing something, I stopped it and did a
    teardown.

    No change.

    Now I have no clue...

    Any suggestions?


    One possibility might be that the pps is at ttl level, while a serial
    post needs rs3232 +/- levels to trigger properly. You can buy ttl to
    rs232 board level adapter for a few $ on Ebay, which is what i'm
    using here. Single supply line, 5 or 12 v, don't remember, that you
    can tap off from the host b/board...

    Nope, this is a RS-232 device connected to a RS-232 port and as I said,
    ppscheck works fine and PPS seems to get processed if gpsd is run as an
    ordinary user, but not if started by root and run as gpsd.

    This is NOT a hobby device.



    Worth a try. It was the problem on the setup here, a s/hand 1u
    time tools gps ntp server, and a micro atx motherboard running FreeBSD.
    The time tools pps is ttl, as are all the other gps do boxes here, from several vendors collected over the years. While such mismatch may
    work with some interfaces, there's no guarantee, as the voltage levels
    are incorrect. Even if it does work, there may be excessive jitter,
    which doesn't help performance. Propagation delay using a drive chip is
    only 10's of nS, havng measure it on a scope, so can be ignored.

    If the only thing changed is the serial card then it's most likely
    something related...
    \
    Here's the relevant fragment from ntp.conf, dcd line as pps input:

    server 127.127.22.0 minpoll 2 maxpoll 2
    fudge 127.127.22.0 flag2 1 flag3 1 flag4 1

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Jim Pennino on Wed Jul 28 22:22:42 2021
    On 2021-07-28, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    William Unruh <unruh@invalid.ca> wrote:

    <snip old stuff>

    You do need something to actually respond to the serial port interrups--
    ie a serial port interrupt driver. Linux includes on


    I have a "gps" script in /etc/init.d

    gpsd does all that for you and simplifies configuration, which is why
    I'm using gpsd at all.

    Except it does not work!


    I did a modprobe check to make sure all the pps stuff was loaded; it
    was.

    Do
    cat /sys/devices/virtual/pps/pps0/assert and
    cat sys/devices/virtual/pps/pps0/clear
    to see if either is giving you signals once a second when the gpsd is
    supposed to be servicing the interrupts.

    (run each successively)
    It is usually assert you want. Your gpsd might be trying to read the
    clear, and it never changes.



    Next is a post to the gpsd support group.

    If all else fails, gpsd gets dumped and ntpd gets configured for the
    NMEA interface.

    If all you want is the time to the nearest second then that is fine. If
    you want it to better than a few tens of ms, then it is not.





    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to chris on Wed Jul 28 22:30:51 2021
    On 2021-07-28, chris <chris-nospam@tridac.net> wrote:
    On 07/28/21 20:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/28/21 17:56, Jim Pennino wrote:
    Using Ubuntu 20.04.2 and gpsd 3.20.

    I replaced the long running USB GPS with a serial device, reconfigured >>>> and rebooted.

    NMEA data is just fine and ppscheck works but gpsd is not processing the >>>> PPS signal on CTS.

    ppstest and ppswatch fail, xgps does not show PPS, and ntpshmmon shows >>>> only NTP0, i.e. not NTP1 and NTP2.

    I ran gpsd as a regular user with -D3 -N to look for errors but it
    looked OK and was accepting PPS. ntpshmmon showed NTP2 and NTP3 and xgps >>>> did show PPS.

    Guessing it was some sort of permissions issue I had introduced over the >>>> years, I did an apt purge gpsd, apt install gpsd and started fresh with >>>> a reboot.

    No change.

    Thinking maybe apparmor was doing something, I stopped it and did a
    teardown.

    No change.

    Now I have no clue...

    Any suggestions?


    One possibility might be that the pps is at ttl level, while a serial
    post needs rs3232 +/- levels to trigger properly. You can buy ttl to
    rs232 board level adapter for a few $ on Ebay, which is what i'm
    using here. Single supply line, 5 or 12 v, don't remember, that you
    can tap off from the host b/board...

    Nope, this is a RS-232 device connected to a RS-232 port and as I said,
    ppscheck works fine and PPS seems to get processed if gpsd is run as an
    ordinary user, but not if started by root and run as gpsd.

    This is NOT a hobby device.



    Worth a try. It was the problem on the setup here, a s/hand 1u
    time tools gps ntp server, and a micro atx motherboard running FreeBSD.
    The time tools pps is ttl, as are all the other gps do boxes here, from several vendors collected over the years. While such mismatch may
    work with some interfaces, there's no guarantee, as the voltage levels
    are incorrect. Even if it does work, there may be excessive jitter,
    which doesn't help performance. Propagation delay using a drive chip is
    only 10's of nS, havng measure it on a scope, so can be ignored.

    Nice theory. But AFAIK almost noone builds RS232 chips/booards with
    follow the RS232 guidelines. I do not say noone because you may well
    come up with an example, but why should they follow the standards?
    Nothing else does. That standard was set about 1950, (Oops I exagerate,
    it was 1960)when they were
    driven by tubes.



    If the only thing changed is the serial card then it's most likely
    something related...

    It is possible. Just as it is possible that if your car does not start,
    you have to insert a crank into a little hole under the radiator and
    turn it.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Jim Pennino on Wed Jul 28 22:54:13 2021
    On 2021-07-28, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    chris <chris-nospam@tridac.net> wrote:
    On 07/28/21 20:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/28/21 17:56, Jim Pennino wrote:
    Using Ubuntu 20.04.2 and gpsd 3.20.

    I replaced the long running USB GPS with a serial device, reconfigured >>>>> and rebooted.

    NMEA data is just fine and ppscheck works but gpsd is not processing the >>>>> PPS signal on CTS.

    ppstest and ppswatch fail, xgps does not show PPS, and ntpshmmon shows >>>>> only NTP0, i.e. not NTP1 and NTP2.

    I ran gpsd as a regular user with -D3 -N to look for errors but it
    looked OK and was accepting PPS. ntpshmmon showed NTP2 and NTP3 and xgps >>>>> did show PPS.

    Guessing it was some sort of permissions issue I had introduced over the >>>>> years, I did an apt purge gpsd, apt install gpsd and started fresh with >>>>> a reboot.

    No change.

    Thinking maybe apparmor was doing something, I stopped it and did a
    teardown.

    No change.

    Now I have no clue...

    Any suggestions?


    One possibility might be that the pps is at ttl level, while a serial
    post needs rs3232 +/- levels to trigger properly. You can buy ttl to
    rs232 board level adapter for a few $ on Ebay, which is what i'm
    using here. Single supply line, 5 or 12 v, don't remember, that you
    can tap off from the host b/board...

    Nope, this is a RS-232 device connected to a RS-232 port and as I said,
    ppscheck works fine and PPS seems to get processed if gpsd is run as an
    ordinary user, but not if started by root and run as gpsd.

    This is NOT a hobby device.



    Worth a try. It was the problem on the setup here, a s/hand 1u
    time tools gps ntp server, and a micro atx motherboard running FreeBSD.
    The time tools pps is ttl, as are all the other gps do boxes here, from
    several vendors collected over the years. While such mismatch may
    work with some interfaces, there's no guarantee, as the voltage levels
    are incorrect. Even if it does work, there may be excessive jitter,
    which doesn't help performance. Propagation delay using a drive chip is
    only 10's of nS, havng measure it on a scope, so can be ignored.

    If the only thing changed is the serial card then it's most likely
    something related...

    What changed is I replaced the USB GPS with a GNSS disciplined OCXO
    box which has an RS-232 interface and a specified PPS accuracy in the nanoseconds.

    It remains to be seen if it actually does nanoseconds, but the 10 MHz
    +/- 0.0002 Hz output has been verified.

    Which is pretty useless for timing purposes.
    Also that is one part in 10^11, and GPS is incapable of giving that.
    I presume that the PPS output is once per second, and that the pulse
    width is not too small (milliseconds) , or gpsd might well have trouble recogizing it as
    a pulse.



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Wed Jul 28 15:43:12 2021
    chris <chris-nospam@tridac.net> wrote:
    On 07/28/21 20:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/28/21 17:56, Jim Pennino wrote:
    Using Ubuntu 20.04.2 and gpsd 3.20.

    I replaced the long running USB GPS with a serial device, reconfigured >>>> and rebooted.

    NMEA data is just fine and ppscheck works but gpsd is not processing the >>>> PPS signal on CTS.

    ppstest and ppswatch fail, xgps does not show PPS, and ntpshmmon shows >>>> only NTP0, i.e. not NTP1 and NTP2.

    I ran gpsd as a regular user with -D3 -N to look for errors but it
    looked OK and was accepting PPS. ntpshmmon showed NTP2 and NTP3 and xgps >>>> did show PPS.

    Guessing it was some sort of permissions issue I had introduced over the >>>> years, I did an apt purge gpsd, apt install gpsd and started fresh with >>>> a reboot.

    No change.

    Thinking maybe apparmor was doing something, I stopped it and did a
    teardown.

    No change.

    Now I have no clue...

    Any suggestions?


    One possibility might be that the pps is at ttl level, while a serial
    post needs rs3232 +/- levels to trigger properly. You can buy ttl to
    rs232 board level adapter for a few $ on Ebay, which is what i'm
    using here. Single supply line, 5 or 12 v, don't remember, that you
    can tap off from the host b/board...

    Nope, this is a RS-232 device connected to a RS-232 port and as I said,
    ppscheck works fine and PPS seems to get processed if gpsd is run as an
    ordinary user, but not if started by root and run as gpsd.

    This is NOT a hobby device.



    Worth a try. It was the problem on the setup here, a s/hand 1u
    time tools gps ntp server, and a micro atx motherboard running FreeBSD.
    The time tools pps is ttl, as are all the other gps do boxes here, from several vendors collected over the years. While such mismatch may
    work with some interfaces, there's no guarantee, as the voltage levels
    are incorrect. Even if it does work, there may be excessive jitter,
    which doesn't help performance. Propagation delay using a drive chip is
    only 10's of nS, havng measure it on a scope, so can be ignored.

    If the only thing changed is the serial card then it's most likely
    something related...

    What changed is I replaced the USB GPS with a GNSS disciplined OCXO
    box which has an RS-232 interface and a specified PPS accuracy in the nanoseconds.

    It remains to be seen if it actually does nanoseconds, but the 10 MHz
    +/- 0.0002 Hz output has been verified.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to William Unruh on Wed Jul 28 23:58:42 2021
    On 07/28/21 23:30, William Unruh wrote:
    On 2021-07-28, chris<chris-nospam@tridac.net> wrote:
    On 07/28/21 20:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/28/21 17:56, Jim Pennino wrote:
    Using Ubuntu 20.04.2 and gpsd 3.20.

    I replaced the long running USB GPS with a serial device, reconfigured >>>>> and rebooted.

    NMEA data is just fine and ppscheck works but gpsd is not processing the >>>>> PPS signal on CTS.

    ppstest and ppswatch fail, xgps does not show PPS, and ntpshmmon shows >>>>> only NTP0, i.e. not NTP1 and NTP2.

    I ran gpsd as a regular user with -D3 -N to look for errors but it
    looked OK and was accepting PPS. ntpshmmon showed NTP2 and NTP3 and xgps >>>>> did show PPS.

    Guessing it was some sort of permissions issue I had introduced over the >>>>> years, I did an apt purge gpsd, apt install gpsd and started fresh with >>>>> a reboot.

    No change.

    Thinking maybe apparmor was doing something, I stopped it and did a
    teardown.

    No change.

    Now I have no clue...

    Any suggestions?


    One possibility might be that the pps is at ttl level, while a serial
    post needs rs3232 +/- levels to trigger properly. You can buy ttl to
    rs232 board level adapter for a few $ on Ebay, which is what i'm
    using here. Single supply line, 5 or 12 v, don't remember, that you
    can tap off from the host b/board...

    Nope, this is a RS-232 device connected to a RS-232 port and as I said,
    ppscheck works fine and PPS seems to get processed if gpsd is run as an
    ordinary user, but not if started by root and run as gpsd.

    This is NOT a hobby device.



    Worth a try. It was the problem on the setup here, a s/hand 1u
    time tools gps ntp server, and a micro atx motherboard running FreeBSD.
    The time tools pps is ttl, as are all the other gps do boxes here, from
    several vendors collected over the years. While such mismatch may
    work with some interfaces, there's no guarantee, as the voltage levels
    are incorrect. Even if it does work, there may be excessive jitter,
    which doesn't help performance. Propagation delay using a drive chip is
    only 10's of nS, havng measure it on a scope, so can be ignored.

    Nice theory. But AFAIK almost noone builds RS232 chips/booards with
    follow the RS232 guidelines. I do not say noone because you may well
    come up with an example, but why should they follow the standards?
    Nothing else does. That standard was set about 1950, (Oops I exagerate,
    it was 1960)when they were
    driven by tubes.


    Sorry William, but do this sort of hardware design for work and every
    pc with serial ports i've seen, has some sort of level conversion to
    generate the rs232 levels, or at least a negative and positive going
    waveform. Might not meet the older rs232 spec and some may work
    with ttl input, but that's not guaranteed. For timing applications,
    it's important to avoid jitter on input transitions, so why not do
    the design right, rather than bodging it ?. Might be ok for a
    home hack, but not for professional work, not here anyway...

    Ymmv, of course...






    If the only thing changed is the serial card then it's most likely
    something related...

    It is possible. Just as it is possible that if your car does not start,
    you have to insert a crank into a little hole under the radiator and
    turn it.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Woolley@21:1/5 to William Unruh on Thu Jul 29 00:01:21 2021
    On 28/07/2021 23:30, William Unruh wrote:
    But AFAIK almost noone builds RS232 chips/booards with
    follow the RS232 guidelines.

    I think you will find they do. Line receivers are allowed a threshold
    anywhere between -3V and +3V, so a threshold compatible with TTL is in
    spec. I think there is also a part of the specification that requires
    control lines to read OFF when the driver is powered down, which implies
    the threshold is > 0.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to Jim Pennino on Thu Jul 29 00:03:42 2021
    On 07/28/21 23:43, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/28/21 20:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/28/21 17:56, Jim Pennino wrote:
    Using Ubuntu 20.04.2 and gpsd 3.20.

    I replaced the long running USB GPS with a serial device, reconfigured >>>>> and rebooted.

    NMEA data is just fine and ppscheck works but gpsd is not processing the >>>>> PPS signal on CTS.

    ppstest and ppswatch fail, xgps does not show PPS, and ntpshmmon shows >>>>> only NTP0, i.e. not NTP1 and NTP2.

    I ran gpsd as a regular user with -D3 -N to look for errors but it
    looked OK and was accepting PPS. ntpshmmon showed NTP2 and NTP3 and xgps >>>>> did show PPS.

    Guessing it was some sort of permissions issue I had introduced over the >>>>> years, I did an apt purge gpsd, apt install gpsd and started fresh with >>>>> a reboot.

    No change.

    Thinking maybe apparmor was doing something, I stopped it and did a
    teardown.

    No change.

    Now I have no clue...

    Any suggestions?


    One possibility might be that the pps is at ttl level, while a serial
    post needs rs3232 +/- levels to trigger properly. You can buy ttl to
    rs232 board level adapter for a few $ on Ebay, which is what i'm
    using here. Single supply line, 5 or 12 v, don't remember, that you
    can tap off from the host b/board...

    Nope, this is a RS-232 device connected to a RS-232 port and as I said,
    ppscheck works fine and PPS seems to get processed if gpsd is run as an
    ordinary user, but not if started by root and run as gpsd.

    This is NOT a hobby device.



    Worth a try. It was the problem on the setup here, a s/hand 1u
    time tools gps ntp server, and a micro atx motherboard running FreeBSD.
    The time tools pps is ttl, as are all the other gps do boxes here, from
    several vendors collected over the years. While such mismatch may
    work with some interfaces, there's no guarantee, as the voltage levels
    are incorrect. Even if it does work, there may be excessive jitter,
    which doesn't help performance. Propagation delay using a drive chip is
    only 10's of nS, havng measure it on a scope, so can be ignored.

    If the only thing changed is the serial card then it's most likely
    something related...

    What changed is I replaced the USB GPS with a GNSS disciplined OCXO
    box which has an RS-232 interface and a specified PPS accuracy in the nanoseconds.

    It remains to be seen if it actually does nanoseconds, but the 10 MHz
    +/- 0.0002 Hz output has been verified.



    I've used ex telco gps do for frequency standard work for years and they typically have a pps offset in the 10nS range. You can even adjust the
    antenna cable length to compensate. Have a look at the time nuts
    mailing list for more info...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Wed Jul 28 15:48:05 2021
    chris <chris-nospam@tridac.net> wrote:
    On 07/28/21 22:18, chris wrote:
    On 07/28/21 20:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/28/21 17:56, Jim Pennino wrote:
    Using Ubuntu 20.04.2 and gpsd 3.20.

    I replaced the long running USB GPS with a serial device, reconfigured >>>>> and rebooted.

    NMEA data is just fine and ppscheck works but gpsd is not processing >>>>> the
    PPS signal on CTS.

    ppstest and ppswatch fail, xgps does not show PPS, and ntpshmmon shows >>>>> only NTP0, i.e. not NTP1 and NTP2.

    I ran gpsd as a regular user with -D3 -N to look for errors but it
    looked OK and was accepting PPS. ntpshmmon showed NTP2 and NTP3 and
    xgps
    did show PPS.

    Guessing it was some sort of permissions issue I had introduced over >>>>> the
    years, I did an apt purge gpsd, apt install gpsd and started fresh with >>>>> a reboot.

    No change.

    Thinking maybe apparmor was doing something, I stopped it and did a
    teardown.

    No change.

    Now I have no clue...

    Any suggestions?


    One possibility might be that the pps is at ttl level, while a serial
    post needs rs3232 +/- levels to trigger properly. You can buy ttl to
    rs232 board level adapter for a few $ on Ebay, which is what i'm
    using here. Single supply line, 5 or 12 v, don't remember, that you
    can tap off from the host b/board...

    Nope, this is a RS-232 device connected to a RS-232 port and as I said,
    ppscheck works fine and PPS seems to get processed if gpsd is run as an
    ordinary user, but not if started by root and run as gpsd.

    This is NOT a hobby device.



    Worth a try. It was the problem on the setup here, a s/hand 1u
    time tools gps ntp server, and a micro atx motherboard running FreeBSD.
    The time tools pps is ttl, as are all the other gps do boxes here, from
    several vendors collected over the years. While such mismatch may
    work with some interfaces, there's no guarantee, as the voltage levels
    are incorrect. Even if it does work, there may be excessive jitter,
    which doesn't help performance. Propagation delay using a drive chip is
    only 10's of nS, havng measure it on a scope, so can be ignored.

    If the only thing changed is the serial card then it's most likely
    something related...
    \
    Here's the relevant fragment from ntp.conf, dcd line as pps input:

    server 127.127.22.0 minpoll 2 maxpoll 2
    fudge 127.127.22.0 flag2 1 flag3 1 flag4 1

    gpsd uses the type 28 driver.

    Most versions of ntpd will silently change a minpoll of 2 to 4. You can
    verify with ntpq -p. If it says poll is 16, your's is one of them. The
    ntp documentation for reference clocks explicitly says setting minpoll
    to less than 4 is a waste of time and poll will always be 16, so setting
    max poll has no effect.

    YMMV

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to Jim Pennino on Thu Jul 29 00:57:22 2021
    On 07/29/21 00:24, Jim Pennino wrote:
    William Unruh<unruh@invalid.ca> wrote:
    On 2021-07-28, Jim Pennino<jimp@gonzo.specsol.net> wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/28/21 20:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/28/21 17:56, Jim Pennino wrote:
    Using Ubuntu 20.04.2 and gpsd 3.20.

    I replaced the long running USB GPS with a serial device, reconfigured >>>>>>> and rebooted.

    NMEA data is just fine and ppscheck works but gpsd is not processing the
    PPS signal on CTS.

    ppstest and ppswatch fail, xgps does not show PPS, and ntpshmmon shows >>>>>>> only NTP0, i.e. not NTP1 and NTP2.

    I ran gpsd as a regular user with -D3 -N to look for errors but it >>>>>>> looked OK and was accepting PPS. ntpshmmon showed NTP2 and NTP3 and xgps
    did show PPS.

    Guessing it was some sort of permissions issue I had introduced over the
    years, I did an apt purge gpsd, apt install gpsd and started fresh with >>>>>>> a reboot.

    No change.

    Thinking maybe apparmor was doing something, I stopped it and did a >>>>>>> teardown.

    No change.

    Now I have no clue...

    Any suggestions?


    One possibility might be that the pps is at ttl level, while a serial >>>>>> post needs rs3232 +/- levels to trigger properly. You can buy ttl to >>>>>> rs232 board level adapter for a few $ on Ebay, which is what i'm
    using here. Single supply line, 5 or 12 v, don't remember, that you >>>>>> can tap off from the host b/board...

    Nope, this is a RS-232 device connected to a RS-232 port and as I said, >>>>> ppscheck works fine and PPS seems to get processed if gpsd is run as an >>>>> ordinary user, but not if started by root and run as gpsd.

    This is NOT a hobby device.



    Worth a try. It was the problem on the setup here, a s/hand 1u
    time tools gps ntp server, and a micro atx motherboard running FreeBSD. >>>> The time tools pps is ttl, as are all the other gps do boxes here, from >>>> several vendors collected over the years. While such mismatch may
    work with some interfaces, there's no guarantee, as the voltage levels >>>> are incorrect. Even if it does work, there may be excessive jitter,
    which doesn't help performance. Propagation delay using a drive chip is >>>> only 10's of nS, havng measure it on a scope, so can be ignored.

    If the only thing changed is the serial card then it's most likely
    something related...

    What changed is I replaced the USB GPS with a GNSS disciplined OCXO
    box which has an RS-232 interface and a specified PPS accuracy in the
    nanoseconds.

    It remains to be seen if it actually does nanoseconds, but the 10 MHz
    +/- 0.0002 Hz output has been verified.

    Which is pretty useless for timing purposes.

    True, but it is just fine and dandy for calibrating frequency counters without having to send them somewhere and it allows testing of radio
    dial accuracy no matter the state of the ionosphere.

    Also that is one part in 10^11, and GPS is incapable of giving that.
    I presume that the PPS output is once per second, and that the pulse
    width is not too small (milliseconds) , or gpsd might well have trouble recogizing it as
    a pulse.

    This is a commercial box sold specifically as a time and frequency
    standard and purchased because it's specifications are only a bit worse
    than a rubidium standard and about $600 cheaper.

    I have already verified that gpsd CAN recognize the PPS on CTS, but NOT running with the permissions that it needs to feed ntp.



    Interesting, as some serial device chips have internal hardware locking
    between some of the control functions. I used the dcd line for the
    system here, which was fine, but haven't tested with the cts line...






    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to William Unruh on Wed Jul 28 16:24:50 2021
    William Unruh <unruh@invalid.ca> wrote:
    On 2021-07-28, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    chris <chris-nospam@tridac.net> wrote:
    On 07/28/21 20:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/28/21 17:56, Jim Pennino wrote:
    Using Ubuntu 20.04.2 and gpsd 3.20.

    I replaced the long running USB GPS with a serial device, reconfigured >>>>>> and rebooted.

    NMEA data is just fine and ppscheck works but gpsd is not processing the >>>>>> PPS signal on CTS.

    ppstest and ppswatch fail, xgps does not show PPS, and ntpshmmon shows >>>>>> only NTP0, i.e. not NTP1 and NTP2.

    I ran gpsd as a regular user with -D3 -N to look for errors but it >>>>>> looked OK and was accepting PPS. ntpshmmon showed NTP2 and NTP3 and xgps >>>>>> did show PPS.

    Guessing it was some sort of permissions issue I had introduced over the >>>>>> years, I did an apt purge gpsd, apt install gpsd and started fresh with >>>>>> a reboot.

    No change.

    Thinking maybe apparmor was doing something, I stopped it and did a >>>>>> teardown.

    No change.

    Now I have no clue...

    Any suggestions?


    One possibility might be that the pps is at ttl level, while a serial >>>>> post needs rs3232 +/- levels to trigger properly. You can buy ttl to >>>>> rs232 board level adapter for a few $ on Ebay, which is what i'm
    using here. Single supply line, 5 or 12 v, don't remember, that you
    can tap off from the host b/board...

    Nope, this is a RS-232 device connected to a RS-232 port and as I said, >>>> ppscheck works fine and PPS seems to get processed if gpsd is run as an >>>> ordinary user, but not if started by root and run as gpsd.

    This is NOT a hobby device.



    Worth a try. It was the problem on the setup here, a s/hand 1u
    time tools gps ntp server, and a micro atx motherboard running FreeBSD.
    The time tools pps is ttl, as are all the other gps do boxes here, from
    several vendors collected over the years. While such mismatch may
    work with some interfaces, there's no guarantee, as the voltage levels
    are incorrect. Even if it does work, there may be excessive jitter,
    which doesn't help performance. Propagation delay using a drive chip is
    only 10's of nS, havng measure it on a scope, so can be ignored.

    If the only thing changed is the serial card then it's most likely
    something related...

    What changed is I replaced the USB GPS with a GNSS disciplined OCXO
    box which has an RS-232 interface and a specified PPS accuracy in the
    nanoseconds.

    It remains to be seen if it actually does nanoseconds, but the 10 MHz
    +/- 0.0002 Hz output has been verified.

    Which is pretty useless for timing purposes.

    True, but it is just fine and dandy for calibrating frequency counters
    without having to send them somewhere and it allows testing of radio
    dial accuracy no matter the state of the ionosphere.

    Also that is one part in 10^11, and GPS is incapable of giving that.
    I presume that the PPS output is once per second, and that the pulse
    width is not too small (milliseconds) , or gpsd might well have trouble recogizing it as
    a pulse.

    This is a commercial box sold specifically as a time and frequency
    standard and purchased because it's specifications are only a bit worse
    than a rubidium standard and about $600 cheaper.

    I have already verified that gpsd CAN recognize the PPS on CTS, but NOT
    running with the permissions that it needs to feed ntp.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to William Unruh on Wed Jul 28 16:13:19 2021
    William Unruh <unruh@invalid.ca> wrote:
    On 2021-07-28, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    William Unruh <unruh@invalid.ca> wrote:

    <snip old stuff>

    You do need something to actually respond to the serial port interrups-- >>> ie a serial port interrupt driver. Linux includes on


    I have a "gps" script in /etc/init.d

    gpsd does all that for you and simplifies configuration, which is why
    I'm using gpsd at all.

    Except it does not work!

    Yeah, tell me about it.

    It does in the general case as I have other serial systems that use gpsd
    and PPS with no issue.

    I did a modprobe check to make sure all the pps stuff was loaded; it
    was.

    Do
    cat /sys/devices/virtual/pps/pps0/assert and
    cat sys/devices/virtual/pps/pps0/clear
    to see if either is giving you signals once a second when the gpsd is supposed to be servicing the interrupts.

    (run each successively)
    It is usually assert you want. Your gpsd might be trying to read the
    clear, and it never changes.

    When running, gpsd takes control of /dev/pps0.

    A cat of both assert and clear both give 0.000000000#0

    If I run gpsd as a regular user in debug mode, I can see that it does
    ouput PPS but not from the privileged shared memory segment needed for
    ntp.

    That says to me there is something hosed in the permissions within the
    gpsd PPS processing and that it is not a signal level problem.


    Next is a post to the gpsd support group.

    If all else fails, gpsd gets dumped and ntpd gets configured for the
    NMEA interface.

    If all you want is the time to the nearest second then that is fine. If
    you want it to better than a few tens of ms, then it is not.

    Well, since the 4 machines with a USB GPS all show an average error of
    about 1.5 milliseconds with a standard deviation of about 0.5
    milliseconds and the other PPS machine shows an average error of about
    2 microseconds with a standard deviation of about 150 microseconds,
    the time accuracy on the network appears to be OK.

    This new device is a GNSS disciplined OCXO in a 4"X4"X2" high box which
    will supposedly give me nanoseconds if I can get PPS working on that system.

    The 10 MHz +/- 0.0002 Hz frequency reference output seems to be working
    OK, so if I could get PPS to work with gpsd...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to Jim Pennino on Thu Jul 29 01:02:50 2021
    On 07/29/21 00:32, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:

    <snip old stuff>


    I've used ex telco gps do for frequency standard work for years and they
    typically have a pps offset in the 10nS range. You can even adjust the
    antenna cable length to compensate. Have a look at the time nuts
    mailing list for more info...


    I bought this thing because I was interested in the state of the art of affordable devices.

    I am well past the point in my life when I would haunt surplus stores
    looking for treasure. I might violate that if I find a good source of
    really cheap wave guide.



    Depends on the item, but have more or less equipped the lab here with
    older high end test gear, even some parts / repair. Trade time against
    money. Never get tired of just making stuff work...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Wed Jul 28 16:32:31 2021
    chris <chris-nospam@tridac.net> wrote:

    <snip old stuff>


    I've used ex telco gps do for frequency standard work for years and they typically have a pps offset in the 10nS range. You can even adjust the antenna cable length to compensate. Have a look at the time nuts
    mailing list for more info...


    I bought this thing because I was interested in the state of the art of affordable devices.

    I am well past the point in my life when I would haunt surplus stores
    looking for treasure. I might violate that if I find a good source of
    really cheap wave guide.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to chris on Thu Jul 29 00:59:34 2021
    On 07/29/21 00:57, chris wrote:
    On 07/29/21 00:24, Jim Pennino wrote:
    William Unruh<unruh@invalid.ca> wrote:
    On 2021-07-28, Jim Pennino<jimp@gonzo.specsol.net> wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/28/21 20:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/28/21 17:56, Jim Pennino wrote:
    Using Ubuntu 20.04.2 and gpsd 3.20.

    I replaced the long running USB GPS with a serial device,
    reconfigured
    and rebooted.

    NMEA data is just fine and ppscheck works but gpsd is not
    processing the
    PPS signal on CTS.

    ppstest and ppswatch fail, xgps does not show PPS, and ntpshmmon >>>>>>>> shows
    only NTP0, i.e. not NTP1 and NTP2.

    I ran gpsd as a regular user with -D3 -N to look for errors but it >>>>>>>> looked OK and was accepting PPS. ntpshmmon showed NTP2 and NTP3 >>>>>>>> and xgps
    did show PPS.

    Guessing it was some sort of permissions issue I had introduced >>>>>>>> over the
    years, I did an apt purge gpsd, apt install gpsd and started
    fresh with
    a reboot.

    No change.

    Thinking maybe apparmor was doing something, I stopped it and did a >>>>>>>> teardown.

    No change.

    Now I have no clue...

    Any suggestions?


    One possibility might be that the pps is at ttl level, while a
    serial
    post needs rs3232 +/- levels to trigger properly. You can buy ttl to >>>>>>> rs232 board level adapter for a few $ on Ebay, which is what i'm >>>>>>> using here. Single supply line, 5 or 12 v, don't remember, that you >>>>>>> can tap off from the host b/board...

    Nope, this is a RS-232 device connected to a RS-232 port and as I
    said,
    ppscheck works fine and PPS seems to get processed if gpsd is run
    as an
    ordinary user, but not if started by root and run as gpsd.

    This is NOT a hobby device.



    Worth a try. It was the problem on the setup here, a s/hand 1u
    time tools gps ntp server, and a micro atx motherboard running
    FreeBSD.
    The time tools pps is ttl, as are all the other gps do boxes here,
    from
    several vendors collected over the years. While such mismatch may
    work with some interfaces, there's no guarantee, as the voltage levels >>>>> are incorrect. Even if it does work, there may be excessive jitter,
    which doesn't help performance. Propagation delay using a drive
    chip is
    only 10's of nS, havng measure it on a scope, so can be ignored.

    If the only thing changed is the serial card then it's most likely
    something related...

    What changed is I replaced the USB GPS with a GNSS disciplined OCXO
    box which has an RS-232 interface and a specified PPS accuracy in the
    nanoseconds.

    It remains to be seen if it actually does nanoseconds, but the 10 MHz
    +/- 0.0002 Hz output has been verified.

    Which is pretty useless for timing purposes.

    True, but it is just fine and dandy for calibrating frequency counters
    without having to send them somewhere and it allows testing of radio
    dial accuracy no matter the state of the ionosphere.

    Also that is one part in 10^11, and GPS is incapable of giving that.
    I presume that the PPS output is once per second, and that the pulse
    width is not too small (milliseconds) , or gpsd might well have
    trouble recogizing it as
    a pulse.

    This is a commercial box sold specifically as a time and frequency
    standard and purchased because it's specifications are only a bit worse
    than a rubidium standard and about $600 cheaper.

    I have already verified that gpsd CAN recognize the PPS on CTS, but NOT
    running with the permissions that it needs to feed ntp.



    Interesting, as some serial device chips have internal hardware locking between some of the control functions. I used the dcd line for the
    system here, which was fine, but haven't tested with the cts line...


    Ignore above but how about permissions on the serial device itself ?...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Wed Jul 28 18:11:56 2021
    chris <chris-nospam@tridac.net> wrote:
    On 07/29/21 00:32, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:

    <snip old stuff>


    I've used ex telco gps do for frequency standard work for years and they >>> typically have a pps offset in the 10nS range. You can even adjust the
    antenna cable length to compensate. Have a look at the time nuts
    mailing list for more info...


    I bought this thing because I was interested in the state of the art of
    affordable devices.

    I am well past the point in my life when I would haunt surplus stores
    looking for treasure. I might violate that if I find a good source of
    really cheap wave guide.



    Depends on the item, but have more or less equipped the lab here with
    older high end test gear, even some parts / repair. Trade time against
    money. Never get tired of just making stuff work...

    The inducement here is that while GPS disciplined oscillators are very
    old technology which used to live in 19" 5U rack mount boxes and cost
    tens of thousands of dollars, they now consist of some chip sets on a
    circuit board in a 4"X4"X2" high box and costs about $180 with shipping.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Wed Jul 28 18:02:15 2021
    chris <chris-nospam@tridac.net> wrote:
    On 07/29/21 00:24, Jim Pennino wrote:
    William Unruh<unruh@invalid.ca> wrote:
    On 2021-07-28, Jim Pennino<jimp@gonzo.specsol.net> wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/28/21 20:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/28/21 17:56, Jim Pennino wrote:
    Using Ubuntu 20.04.2 and gpsd 3.20.

    I replaced the long running USB GPS with a serial device, reconfigured >>>>>>>> and rebooted.

    NMEA data is just fine and ppscheck works but gpsd is not processing the
    PPS signal on CTS.

    ppstest and ppswatch fail, xgps does not show PPS, and ntpshmmon shows >>>>>>>> only NTP0, i.e. not NTP1 and NTP2.

    I ran gpsd as a regular user with -D3 -N to look for errors but it >>>>>>>> looked OK and was accepting PPS. ntpshmmon showed NTP2 and NTP3 and xgps
    did show PPS.

    Guessing it was some sort of permissions issue I had introduced over the
    years, I did an apt purge gpsd, apt install gpsd and started fresh with
    a reboot.

    No change.

    Thinking maybe apparmor was doing something, I stopped it and did a >>>>>>>> teardown.

    No change.

    Now I have no clue...

    Any suggestions?


    One possibility might be that the pps is at ttl level, while a serial >>>>>>> post needs rs3232 +/- levels to trigger properly. You can buy ttl to >>>>>>> rs232 board level adapter for a few $ on Ebay, which is what i'm >>>>>>> using here. Single supply line, 5 or 12 v, don't remember, that you >>>>>>> can tap off from the host b/board...

    Nope, this is a RS-232 device connected to a RS-232 port and as I said, >>>>>> ppscheck works fine and PPS seems to get processed if gpsd is run as an >>>>>> ordinary user, but not if started by root and run as gpsd.

    This is NOT a hobby device.



    Worth a try. It was the problem on the setup here, a s/hand 1u
    time tools gps ntp server, and a micro atx motherboard running FreeBSD. >>>>> The time tools pps is ttl, as are all the other gps do boxes here, from >>>>> several vendors collected over the years. While such mismatch may
    work with some interfaces, there's no guarantee, as the voltage levels >>>>> are incorrect. Even if it does work, there may be excessive jitter,
    which doesn't help performance. Propagation delay using a drive chip is >>>>> only 10's of nS, havng measure it on a scope, so can be ignored.

    If the only thing changed is the serial card then it's most likely
    something related...

    What changed is I replaced the USB GPS with a GNSS disciplined OCXO
    box which has an RS-232 interface and a specified PPS accuracy in the
    nanoseconds.

    It remains to be seen if it actually does nanoseconds, but the 10 MHz
    +/- 0.0002 Hz output has been verified.

    Which is pretty useless for timing purposes.

    True, but it is just fine and dandy for calibrating frequency counters
    without having to send them somewhere and it allows testing of radio
    dial accuracy no matter the state of the ionosphere.

    Also that is one part in 10^11, and GPS is incapable of giving that.
    I presume that the PPS output is once per second, and that the pulse
    width is not too small (milliseconds) , or gpsd might well have trouble recogizing it as
    a pulse.

    This is a commercial box sold specifically as a time and frequency
    standard and purchased because it's specifications are only a bit worse
    than a rubidium standard and about $600 cheaper.

    I have already verified that gpsd CAN recognize the PPS on CTS, but NOT
    running with the permissions that it needs to feed ntp.



    Interesting, as some serial device chips have internal hardware locking between some of the control functions. I used the dcd line for the
    system here, which was fine, but haven't tested with the cts line...

    There are no "serial device chips", there is a commercial PCI interface
    board specified to work as RS-232 ports with full hardware handshake.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Wed Jul 28 18:03:34 2021
    chris <chris-nospam@tridac.net> wrote:

    <snip old stuff>


    Ignore above but how about permissions on the serial device itself ?...

    The problem seems to be permissions related to shared memory segments.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Jim Pennino on Thu Jul 29 03:38:50 2021
    On 2021-07-29, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    chris <chris-nospam@tridac.net> wrote:
    On 07/29/21 00:24, Jim Pennino wrote:
    William Unruh<unruh@invalid.ca> wrote:
    On 2021-07-28, Jim Pennino<jimp@gonzo.specsol.net> wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/28/21 20:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/28/21 17:56, Jim Pennino wrote:
    Using Ubuntu 20.04.2 and gpsd 3.20.

    I replaced the long running USB GPS with a serial device, reconfigured
    and rebooted.

    NMEA data is just fine and ppscheck works but gpsd is not processing the
    PPS signal on CTS.

    ppstest and ppswatch fail, xgps does not show PPS, and ntpshmmon shows
    only NTP0, i.e. not NTP1 and NTP2.

    I ran gpsd as a regular user with -D3 -N to look for errors but it >>>>>>>>> looked OK and was accepting PPS. ntpshmmon showed NTP2 and NTP3 and xgps
    did show PPS.

    Guessing it was some sort of permissions issue I had introduced over the
    years, I did an apt purge gpsd, apt install gpsd and started fresh with
    a reboot.

    No change.

    Thinking maybe apparmor was doing something, I stopped it and did a >>>>>>>>> teardown.

    No change.

    Now I have no clue...

    Any suggestions?


    One possibility might be that the pps is at ttl level, while a serial >>>>>>>> post needs rs3232 +/- levels to trigger properly. You can buy ttl to >>>>>>>> rs232 board level adapter for a few $ on Ebay, which is what i'm >>>>>>>> using here. Single supply line, 5 or 12 v, don't remember, that you >>>>>>>> can tap off from the host b/board...

    Nope, this is a RS-232 device connected to a RS-232 port and as I said, >>>>>>> ppscheck works fine and PPS seems to get processed if gpsd is run as an >>>>>>> ordinary user, but not if started by root and run as gpsd.

    This is NOT a hobby device.



    Worth a try. It was the problem on the setup here, a s/hand 1u
    time tools gps ntp server, and a micro atx motherboard running FreeBSD. >>>>>> The time tools pps is ttl, as are all the other gps do boxes here, from >>>>>> several vendors collected over the years. While such mismatch may
    work with some interfaces, there's no guarantee, as the voltage levels >>>>>> are incorrect. Even if it does work, there may be excessive jitter, >>>>>> which doesn't help performance. Propagation delay using a drive chip is >>>>>> only 10's of nS, havng measure it on a scope, so can be ignored.

    If the only thing changed is the serial card then it's most likely >>>>>> something related...

    What changed is I replaced the USB GPS with a GNSS disciplined OCXO
    box which has an RS-232 interface and a specified PPS accuracy in the >>>>> nanoseconds.

    It remains to be seen if it actually does nanoseconds, but the 10 MHz >>>>> +/- 0.0002 Hz output has been verified.

    Which is pretty useless for timing purposes.

    True, but it is just fine and dandy for calibrating frequency counters
    without having to send them somewhere and it allows testing of radio
    dial accuracy no matter the state of the ionosphere.

    Also that is one part in 10^11, and GPS is incapable of giving that.
    I presume that the PPS output is once per second, and that the pulse
    width is not too small (milliseconds) , or gpsd might well have trouble recogizing it as
    a pulse.

    This is a commercial box sold specifically as a time and frequency
    standard and purchased because it's specifications are only a bit worse
    than a rubidium standard and about $600 cheaper.

    I have already verified that gpsd CAN recognize the PPS on CTS, but NOT
    running with the permissions that it needs to feed ntp.



    Interesting, as some serial device chips have internal hardware locking
    between some of the control functions. I used the dcd line for the
    system here, which was fine, but haven't tested with the cts line...

    There are no "serial device chips", there is a commercial PCI interface
    board specified to work as RS-232 ports with full hardware handshake.

    But those "PCI interface board" contains "serial device chips"



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Miroslav Lichvar@21:1/5 to Jim Pennino on Thu Jul 29 07:31:02 2021
    On 2021-07-28, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    ppstest and ppswatch fail, xgps does not show PPS, and ntpshmmon shows
    only NTP0, i.e. not NTP1 and NTP2.

    I ran gpsd as a regular user with -D3 -N to look for errors but it
    looked OK and was accepting PPS. ntpshmmon showed NTP2 and NTP3 and xgps
    did show PPS.

    How exactly is gpsd started? With the serial device specified on its
    command line, or is it added only later by gpsdctl (via udev+systemd)
    when gpsd already dropped the root privileges?

    --
    Miroslav Lichvar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Woolley@21:1/5 to chris on Thu Jul 29 12:47:02 2021
    On 29/07/2021 00:03, chris wrote:

    I've used ex telco gps do for frequency standard work for years and they typically have a pps offset in the 10nS range

    Offset relative to what? Do you have an atomic clock that is traceable
    to UTC?

    The official GPS time transfer accuracy is <= 40ns, so whilst 10ns may
    be achievable most of the time, it isn't guaranteed.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to William Unruh on Thu Jul 29 06:37:17 2021
    William Unruh <unruh@invalid.ca> wrote:
    On 2021-07-29, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    chris <chris-nospam@tridac.net> wrote:
    On 07/29/21 00:24, Jim Pennino wrote:
    William Unruh<unruh@invalid.ca> wrote:
    On 2021-07-28, Jim Pennino<jimp@gonzo.specsol.net> wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/28/21 20:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/28/21 17:56, Jim Pennino wrote:
    Using Ubuntu 20.04.2 and gpsd 3.20.

    I replaced the long running USB GPS with a serial device, reconfigured
    and rebooted.

    NMEA data is just fine and ppscheck works but gpsd is not processing the
    PPS signal on CTS.

    ppstest and ppswatch fail, xgps does not show PPS, and ntpshmmon shows
    only NTP0, i.e. not NTP1 and NTP2.

    I ran gpsd as a regular user with -D3 -N to look for errors but it >>>>>>>>>> looked OK and was accepting PPS. ntpshmmon showed NTP2 and NTP3 and xgps
    did show PPS.

    Guessing it was some sort of permissions issue I had introduced over the
    years, I did an apt purge gpsd, apt install gpsd and started fresh with
    a reboot.

    No change.

    Thinking maybe apparmor was doing something, I stopped it and did a >>>>>>>>>> teardown.

    No change.

    Now I have no clue...

    Any suggestions?


    One possibility might be that the pps is at ttl level, while a serial >>>>>>>>> post needs rs3232 +/- levels to trigger properly. You can buy ttl to >>>>>>>>> rs232 board level adapter for a few $ on Ebay, which is what i'm >>>>>>>>> using here. Single supply line, 5 or 12 v, don't remember, that you >>>>>>>>> can tap off from the host b/board...

    Nope, this is a RS-232 device connected to a RS-232 port and as I said,
    ppscheck works fine and PPS seems to get processed if gpsd is run as an
    ordinary user, but not if started by root and run as gpsd.

    This is NOT a hobby device.



    Worth a try. It was the problem on the setup here, a s/hand 1u
    time tools gps ntp server, and a micro atx motherboard running FreeBSD. >>>>>>> The time tools pps is ttl, as are all the other gps do boxes here, from >>>>>>> several vendors collected over the years. While such mismatch may >>>>>>> work with some interfaces, there's no guarantee, as the voltage levels >>>>>>> are incorrect. Even if it does work, there may be excessive jitter, >>>>>>> which doesn't help performance. Propagation delay using a drive chip is >>>>>>> only 10's of nS, havng measure it on a scope, so can be ignored. >>>>>>>
    If the only thing changed is the serial card then it's most likely >>>>>>> something related...

    What changed is I replaced the USB GPS with a GNSS disciplined OCXO >>>>>> box which has an RS-232 interface and a specified PPS accuracy in the >>>>>> nanoseconds.

    It remains to be seen if it actually does nanoseconds, but the 10 MHz >>>>>> +/- 0.0002 Hz output has been verified.

    Which is pretty useless for timing purposes.

    True, but it is just fine and dandy for calibrating frequency counters >>>> without having to send them somewhere and it allows testing of radio
    dial accuracy no matter the state of the ionosphere.

    Also that is one part in 10^11, and GPS is incapable of giving that. >>>>> I presume that the PPS output is once per second, and that the pulse >>>>> width is not too small (milliseconds) , or gpsd might well have trouble recogizing it as
    a pulse.

    This is a commercial box sold specifically as a time and frequency
    standard and purchased because it's specifications are only a bit worse >>>> than a rubidium standard and about $600 cheaper.

    I have already verified that gpsd CAN recognize the PPS on CTS, but NOT >>>> running with the permissions that it needs to feed ntp.



    Interesting, as some serial device chips have internal hardware locking
    between some of the control functions. I used the dcd line for the
    system here, which was fine, but haven't tested with the cts line...

    There are no "serial device chips", there is a commercial PCI interface
    board specified to work as RS-232 ports with full hardware handshake.

    But those "PCI interface board" contains "serial device chips"

    Yes, they also contain capacitors, resistors, crystals, etc.

    An interface board is a commercial item with a specification, i.e. the
    board is specified to work in a PCI slot, provide RS-232 ports that have standard connectors with full hardware handshaking and work with all
    native OS serial drivers.

    Since the board obviously works to specification, obsessing to what may
    or may not be happening at the chip level seems to me to be pointless.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to Miroslav Lichvar on Thu Jul 29 06:45:47 2021
    Miroslav Lichvar <mlichvar@redhat.com> wrote:
    On 2021-07-28, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    ppstest and ppswatch fail, xgps does not show PPS, and ntpshmmon shows
    only NTP0, i.e. not NTP1 and NTP2.

    I ran gpsd as a regular user with -D3 -N to look for errors but it
    looked OK and was accepting PPS. ntpshmmon showed NTP2 and NTP3 and xgps
    did show PPS.

    How exactly is gpsd started? With the serial device specified on its
    command line, or is it added only later by gpsdctl (via udev+systemd)
    when gpsd already dropped the root privileges?

    It is started by systemd with the options in /etc/default/gpsd which
    are:

    # Use USB hotplugging to add new USB devices automatically to the daemon USBAUTO="false"

    DEVICES="/dev/ttyS4 /dev/pps0"

    # Other options you want to pass to gpsd
    GPSD_OPTIONS="-n -b -s9600 "
    GPSD_SOCKET=/var/run/gpsd.socket

    So a ps shows:

    gpsd 1483 1 0 Jul28 ? 00:00:52 /usr/sbin/gpsd -n -b -s9600 /dev/ttyS4 /dev/pps0

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Miroslav Lichvar@21:1/5 to Jim Pennino on Thu Jul 29 14:54:34 2021
    On 2021-07-29, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    So a ps shows:

    gpsd 1483 1 0 Jul28 ? 00:00:52 /usr/sbin/gpsd -n -b -s9600 /dev/ttyS4 /dev/pps0

    Is that /dev/pps0 necessary? IIRC that is needed only when gpsd cannot
    create the PPS device on its own (similarly to ldattach). If it is
    needed, is gpsd started when it already exists?

    --
    Miroslav Lichvar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to Jim Pennino on Thu Jul 29 17:11:29 2021
    On 07/29/21 14:37, Jim Pennino wrote:
    William Unruh<unruh@invalid.ca> wrote:
    On 2021-07-29, Jim Pennino<jimp@gonzo.specsol.net> wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/29/21 00:24, Jim Pennino wrote:
    William Unruh<unruh@invalid.ca> wrote:
    On 2021-07-28, Jim Pennino<jimp@gonzo.specsol.net> wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/28/21 20:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/28/21 17:56, Jim Pennino wrote:
    Using Ubuntu 20.04.2 and gpsd 3.20.

    I replaced the long running USB GPS with a serial device, reconfigured
    and rebooted.

    NMEA data is just fine and ppscheck works but gpsd is not processing the
    PPS signal on CTS.

    ppstest and ppswatch fail, xgps does not show PPS, and ntpshmmon shows
    only NTP0, i.e. not NTP1 and NTP2.

    I ran gpsd as a regular user with -D3 -N to look for errors but it >>>>>>>>>>> looked OK and was accepting PPS. ntpshmmon showed NTP2 and NTP3 and xgps
    did show PPS.

    Guessing it was some sort of permissions issue I had introduced over the
    years, I did an apt purge gpsd, apt install gpsd and started fresh with
    a reboot.

    No change.

    Thinking maybe apparmor was doing something, I stopped it and did a >>>>>>>>>>> teardown.

    No change.

    Now I have no clue...

    Any suggestions?


    One possibility might be that the pps is at ttl level, while a serial
    post needs rs3232 +/- levels to trigger properly. You can buy ttl to >>>>>>>>>> rs232 board level adapter for a few $ on Ebay, which is what i'm >>>>>>>>>> using here. Single supply line, 5 or 12 v, don't remember, that you >>>>>>>>>> can tap off from the host b/board...

    Nope, this is a RS-232 device connected to a RS-232 port and as I said,
    ppscheck works fine and PPS seems to get processed if gpsd is run as an
    ordinary user, but not if started by root and run as gpsd.

    This is NOT a hobby device.



    Worth a try. It was the problem on the setup here, a s/hand 1u >>>>>>>> time tools gps ntp server, and a micro atx motherboard running FreeBSD.
    The time tools pps is ttl, as are all the other gps do boxes here, from
    several vendors collected over the years. While such mismatch may >>>>>>>> work with some interfaces, there's no guarantee, as the voltage levels >>>>>>>> are incorrect. Even if it does work, there may be excessive jitter, >>>>>>>> which doesn't help performance. Propagation delay using a drive chip is
    only 10's of nS, havng measure it on a scope, so can be ignored. >>>>>>>>
    If the only thing changed is the serial card then it's most likely >>>>>>>> something related...

    What changed is I replaced the USB GPS with a GNSS disciplined OCXO >>>>>>> box which has an RS-232 interface and a specified PPS accuracy in the >>>>>>> nanoseconds.

    It remains to be seen if it actually does nanoseconds, but the 10 MHz >>>>>>> +/- 0.0002 Hz output has been verified.

    Which is pretty useless for timing purposes.

    True, but it is just fine and dandy for calibrating frequency counters >>>>> without having to send them somewhere and it allows testing of radio >>>>> dial accuracy no matter the state of the ionosphere.

    Also that is one part in 10^11, and GPS is incapable of giving that. >>>>>> I presume that the PPS output is once per second, and that the pulse >>>>>> width is not too small (milliseconds) , or gpsd might well have trouble recogizing it as
    a pulse.

    This is a commercial box sold specifically as a time and frequency
    standard and purchased because it's specifications are only a bit worse >>>>> than a rubidium standard and about $600 cheaper.

    I have already verified that gpsd CAN recognize the PPS on CTS, but NOT >>>>> running with the permissions that it needs to feed ntp.



    Interesting, as some serial device chips have internal hardware locking >>>> between some of the control functions. I used the dcd line for the
    system here, which was fine, but haven't tested with the cts line...

    There are no "serial device chips", there is a commercial PCI interface
    board specified to work as RS-232 ports with full hardware handshake.

    But those "PCI interface board" contains "serial device chips"

    Yes, they also contain capacitors, resistors, crystals, etc.

    An interface board is a commercial item with a specification, i.e. the
    board is specified to work in a PCI slot, provide RS-232 ports that have standard connectors with full hardware handshaking and work with all
    native OS serial drivers.

    Since the board obviously works to specification, obsessing to what may
    or may not be happening at the chip level seems to me to be pointless.



    Depending on the chip id, some functions may be inhibited if the control
    lines are in the wrong state. So yes, chip hardware architecture does
    matter and not always something that can be abstracted away within the
    device driver. Devil is in the detail, as usual...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to Miroslav Lichvar on Thu Jul 29 08:36:59 2021
    Miroslav Lichvar <mlichvar@redhat.com> wrote:
    On 2021-07-29, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    So a ps shows:

    gpsd 1483 1 0 Jul28 ? 00:00:52 /usr/sbin/gpsd -n -b -s9600 /dev/ttyS4 /dev/pps0

    Is that /dev/pps0 necessary? IIRC that is needed only when gpsd cannot
    create the PPS device on its own (similarly to ldattach). If it is
    needed, is gpsd started when it already exists?


    I do not know if it is "needed" and /dev/pps0 is indeed created by gpsd
    as it did not exist until the first time I started gpsd with the serial interface configuration.

    OK, I killed gpsd and /dev/pps0 went away.

    I commented pps0 out of the file, restarted gpsd and /dev/pps0 came
    back, so I guess it really isn't needed and does nothing.

    Still nothing but NTP0 from ntpshmmon.

    sudo ntpshmmon
    ntpshmmon: version 3.20
    # Name Seen@ Clock Real L Prc
    sample NTP0 1627572530.002686133 1627572530.002587625 1627572530.000031780 0 -20
    sample NTP0 1627572531.002298509 1627572531.002285618 1627572531.000030611 0 -20
    sample NTP0 1627572532.003058043 1627572532.002332397 1627572532.000029441 0 -20
    ^C

    sudo ppstest /dev/pps0
    trying PPS source "/dev/pps0"
    found PPS source "/dev/pps0"
    ok, found 1 source(s), now start fetching data...
    time_pps_fetch() error -1 (Connection timed out)
    time_pps_fetch() error -1 (Connection timed out)
    ^C

    sudo ppscheck /dev/ttyS4
    # Seconds nanoSecs Signals
    1627572707.885746295 TIOCM_CTS
    1627572707.985778695
    1627572708.885715568 TIOCM_CTS
    1627572708.985741009
    1627572709.885677623 TIOCM_CTS
    1627572709.985701097
    ^C

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to David Woolley on Thu Jul 29 17:38:21 2021
    On 07/29/21 12:47, David Woolley wrote:
    On 29/07/2021 00:03, chris wrote:

    I've used ex telco gps do for frequency standard work for years and they
    typically have a pps offset in the 10nS range

    Offset relative to what? Do you have an atomic clock that is traceable
    to UTC?

    For telco use, they do need the accuracy for gsm cell sync reasons and
    it is quite a tight spec. Have run a couple of HP types for years, the
    Z3815 and Z3816 and the HP utility that drives that reports nS
    offset from UTC. Perhaps the absolute time is not as important as the
    cell to cell sync accuracy, but don't have data on that. As I said,
    there's even a function in the utility to adjust delay in the coax
    line to the antenna, so they are trying to get well within any
    theoretical limits...


    The official GPS time transfer accuracy is <= 40ns, so whilst 10ns may
    be achievable most of the time, it isn't guaranteed.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Thu Jul 29 09:45:52 2021
    chris <chris-nospam@tridac.net> wrote:

    <snip old stuff>

    Depending on the chip id, some functions may be inhibited if the control lines are in the wrong state. So yes, chip hardware architecture does
    matter and not always something that can be abstracted away within the
    device driver. Devil is in the detail, as usual...

    Yeah, so?

    The card obviously works to specification, i.e. RS-232 and it does see CTS.

    If it did not work to specification, I would return the card to the
    vendor and buy a different one.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to Jim Pennino on Thu Jul 29 17:21:08 2021
    On 07/29/21 02:11, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/29/21 00:32, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:

    <snip old stuff>


    I've used ex telco gps do for frequency standard work for years and they >>>> typically have a pps offset in the 10nS range. You can even adjust the >>>> antenna cable length to compensate. Have a look at the time nuts
    mailing list for more info...


    I bought this thing because I was interested in the state of the art of
    affordable devices.

    I am well past the point in my life when I would haunt surplus stores
    looking for treasure. I might violate that if I find a good source of
    really cheap wave guide.



    Depends on the item, but have more or less equipped the lab here with
    older high end test gear, even some parts / repair. Trade time against
    money. Never get tired of just making stuff work...

    The inducement here is that while GPS disciplined oscillators are very
    old technology which used to live in 19" 5U rack mount boxes and cost
    tens of thousands of dollars, they now consist of some chip sets on a
    circuit board in a 4"X4"X2" high box and costs about $180 with shipping.





    Yes, they do, but they are unlikely to have the phase noise figures of
    a better quality unit, nor short term stability. In fact some gpsdo
    are using cheap dil vcxo's that that are not even ovenised and wander
    all over the place.

    Lower cost units should be good enough for ntp use, even if not good
    enough for a primary frequency standard...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Thu Jul 29 09:53:33 2021
    chris <chris-nospam@tridac.net> wrote:
    On 07/29/21 02:11, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/29/21 00:32, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:

    <snip old stuff>


    I've used ex telco gps do for frequency standard work for years and they >>>>> typically have a pps offset in the 10nS range. You can even adjust the >>>>> antenna cable length to compensate. Have a look at the time nuts
    mailing list for more info...


    I bought this thing because I was interested in the state of the art of >>>> affordable devices.

    I am well past the point in my life when I would haunt surplus stores
    looking for treasure. I might violate that if I find a good source of
    really cheap wave guide.



    Depends on the item, but have more or less equipped the lab here with
    older high end test gear, even some parts / repair. Trade time against
    money. Never get tired of just making stuff work...

    The inducement here is that while GPS disciplined oscillators are very
    old technology which used to live in 19" 5U rack mount boxes and cost
    tens of thousands of dollars, they now consist of some chip sets on a
    circuit board in a 4"X4"X2" high box and costs about $180 with shipping.





    Yes, they do, but they are unlikely to have the phase noise figures of
    a better quality unit, nor short term stability. In fact some gpsdo
    are using cheap dil vcxo's that that are not even ovenised and wander
    all over the place.

    Lower cost units should be good enough for ntp use, even if not good
    enough for a primary frequency standard...

    Noise figure of what, exactly?

    The box has specifications.

    If the box does not meet the specifications, the box will be returned to
    the vendor.

    The box is specified to be a GNSS disciplined OCXO with some very tight specifications for short and long term stability.

    None of this addresses the gpsd issue.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to Jim Pennino on Thu Jul 29 17:58:55 2021
    On 07/29/21 17:45, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:

    <snip old stuff>

    Depending on the chip id, some functions may be inhibited if the control
    lines are in the wrong state. So yes, chip hardware architecture does
    matter and not always something that can be abstracted away within the
    device driver. Devil is in the detail, as usual...

    Yeah, so?

    The card obviously works to specification, i.e. RS-232 and it does see CTS.

    If it did not work to specification, I would return the card to the
    vendor and buy a different one.



    This is hard work, obviously never designed any hardware, nor written
    code for it. While the card may very well meet spec, the spec can't
    cover all the myriad cases of operation or use.The spec is often
    generalised, to allow some slack in component selection and to take
    account of advances in the art, but it's the corner cases that can
    catch out the unwary...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Thu Jul 29 10:28:43 2021
    chris <chris-nospam@tridac.net> wrote:
    On 07/29/21 17:45, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:

    <snip old stuff>

    Depending on the chip id, some functions may be inhibited if the control >>> lines are in the wrong state. So yes, chip hardware architecture does
    matter and not always something that can be abstracted away within the
    device driver. Devil is in the detail, as usual...

    Yeah, so?

    The card obviously works to specification, i.e. RS-232 and it does see CTS. >>
    If it did not work to specification, I would return the card to the
    vendor and buy a different one.



    This is hard work, obviously never designed any hardware, nor written
    code for it. While the card may very well meet spec, the spec can't
    cover all the myriad cases of operation or use.The spec is often
    generalised, to allow some slack in component selection and to take
    account of advances in the art, but it's the corner cases that can
    catch out the unwary...

    Do you understand the difference between DIY and purchasing a commercial product sold to thousands upon thousands if not millions of purchasers?

    Do you understand that RS-232 is many decades old and is specified by
    TIA-232-F Interface Between Data Terminal Equipment and Data Circuit-Terminating Equipment Employing Serial Binary Data Interchange,
    issued in 1997?

    The box and the card are both RS-232.

    The card and box combination obviously works.

    None of this has ANYTHING to do with the issue of gpsd.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to Jim Pennino on Thu Jul 29 21:16:36 2021
    On 07/29/21 18:28, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/29/21 17:45, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:

    <snip old stuff>

    Depending on the chip id, some functions may be inhibited if the control >>>> lines are in the wrong state. So yes, chip hardware architecture does
    matter and not always something that can be abstracted away within the >>>> device driver. Devil is in the detail, as usual...

    Yeah, so?

    The card obviously works to specification, i.e. RS-232 and it does see CTS. >>>
    If it did not work to specification, I would return the card to the
    vendor and buy a different one.



    This is hard work, obviously never designed any hardware, nor written
    code for it. While the card may very well meet spec, the spec can't
    cover all the myriad cases of operation or use.The spec is often
    generalised, to allow some slack in component selection and to take
    account of advances in the art, but it's the corner cases that can
    catch out the unwary...

    Do you understand the difference between DIY and purchasing a commercial product sold to thousands upon thousands if not millions of purchasers?

    Do you understand that RS-232 is many decades old and is specified by TIA-232-F Interface Between Data Terminal Equipment and Data Circuit-Terminating Equipment Employing Serial Binary Data Interchange, issued in 1997?

    The box and the card are both RS-232.

    The card and box combination obviously works.

    None of this has ANYTHING to do with the issue of gpsd.



    That's just the spec for the signals on the wires, nothing to do
    with how that is implemented inside devices, or on your pc card,
    which may be implemented in many different ways, from bit banging
    to fully integrated devices with buffering and even some
    intelligence. It only affects your low cost gpsd if you can't
    make it work, and need to dig into why it doesn't work...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Jim Pennino on Thu Jul 29 23:08:26 2021
    On 2021-07-29, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    chris <chris-nospam@tridac.net> wrote:
    On 07/29/21 18:28, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/29/21 17:45, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:

    <snip old stuff>

    Depending on the chip id, some functions may be inhibited if the control >>>>>> lines are in the wrong state. So yes, chip hardware architecture does >>>>>> matter and not always something that can be abstracted away within the >>>>>> device driver. Devil is in the detail, as usual...

    Yeah, so?

    The card obviously works to specification, i.e. RS-232 and it does see CTS.

    If it did not work to specification, I would return the card to the
    vendor and buy a different one.



    This is hard work, obviously never designed any hardware, nor written
    code for it. While the card may very well meet spec, the spec can't
    cover all the myriad cases of operation or use.The spec is often
    generalised, to allow some slack in component selection and to take
    account of advances in the art, but it's the corner cases that can
    catch out the unwary...

    Do you understand the difference between DIY and purchasing a commercial >>> product sold to thousands upon thousands if not millions of purchasers?

    Do you understand that RS-232 is many decades old and is specified by
    TIA-232-F Interface Between Data Terminal Equipment and Data
    Circuit-Terminating Equipment Employing Serial Binary Data Interchange,
    issued in 1997?

    The box and the card are both RS-232.

    The card and box combination obviously works.

    None of this has ANYTHING to do with the issue of gpsd.



    That's just the spec for the signals on the wires, nothing to do
    with how that is implemented inside devices, or on your pc card,
    which may be implemented in many different ways, from bit banging
    to fully integrated devices with buffering and even some
    intelligence. It only affects your low cost gpsd if you can't
    make it work, and need to dig into why it doesn't work...

    1) I no more care how the manufacturer inplemented what is inside the
    box or on the PC card than I care what kind of steel was used to make
    the exhaust manifold on my car.

    2) The box is low cost compared to the tens of thousands of dollars such things used to cost.

    That is of course completely irrelevant. The same could be said of an aluminum spoon (cost mcuch more than a gold spoon), and yet it would still not be most people's first choice for
    tableware.

    Thank you for your suggestions. I always notice the host name part of the prompt string, which is different from each other for the test case discussed here, when I'm on different hosts.

    3) If the box doesn't work, it goes back for a refund. I have no
    interest in fixing things with a warrenty.

    But then as point 4 says, you do not know if it is the box or some misconfiguration (the wetware behind the keyboard) or a bug in gpsd.


    4) It is blazingly obvious to anyone paying the slightest bit of
    attention that the problem is in software, i.e. gpsd, and not the box.

    And yet, you also have been cogitating about the possibility that the
    serial port (either on the box or on the computer) does not satisfy the RS232 standards, which is hardware

    How about trying the direct use of ldattach, instead of using gpsd, to
    see if you can get that to work. If it does, and gpsd does not then your hypothesis that gpsd is at fault is born out. Then you can decide
    whether it is better to suffer the slings and arrows of debugging gpsd,
    or with one fell swoop use ldattach and have a working system.




    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Thu Jul 29 15:26:34 2021
    chris <chris-nospam@tridac.net> wrote:
    On 07/29/21 18:28, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/29/21 17:45, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:

    <snip old stuff>

    Depending on the chip id, some functions may be inhibited if the control >>>>> lines are in the wrong state. So yes, chip hardware architecture does >>>>> matter and not always something that can be abstracted away within the >>>>> device driver. Devil is in the detail, as usual...

    Yeah, so?

    The card obviously works to specification, i.e. RS-232 and it does see CTS.

    If it did not work to specification, I would return the card to the
    vendor and buy a different one.



    This is hard work, obviously never designed any hardware, nor written
    code for it. While the card may very well meet spec, the spec can't
    cover all the myriad cases of operation or use.The spec is often
    generalised, to allow some slack in component selection and to take
    account of advances in the art, but it's the corner cases that can
    catch out the unwary...

    Do you understand the difference between DIY and purchasing a commercial
    product sold to thousands upon thousands if not millions of purchasers?

    Do you understand that RS-232 is many decades old and is specified by
    TIA-232-F Interface Between Data Terminal Equipment and Data
    Circuit-Terminating Equipment Employing Serial Binary Data Interchange,
    issued in 1997?

    The box and the card are both RS-232.

    The card and box combination obviously works.

    None of this has ANYTHING to do with the issue of gpsd.



    That's just the spec for the signals on the wires, nothing to do
    with how that is implemented inside devices, or on your pc card,
    which may be implemented in many different ways, from bit banging
    to fully integrated devices with buffering and even some
    intelligence. It only affects your low cost gpsd if you can't
    make it work, and need to dig into why it doesn't work...

    1) I no more care how the manufacturer inplemented what is inside the
    box or on the PC card than I care what kind of steel was used to make
    the exhaust manifold on my car.

    2) The box is low cost compared to the tens of thousands of dollars such
    things used to cost.

    3) If the box doesn't work, it goes back for a refund. I have no
    interest in fixing things with a warrenty.

    4) It is blazingly obvious to anyone paying the slightest bit of
    attention that the problem is in software, i.e. gpsd, and not the box.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to William Unruh on Thu Jul 29 17:33:44 2021
    William Unruh <unruh@invalid.ca> wrote:
    On 2021-07-29, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    chris <chris-nospam@tridac.net> wrote:
    On 07/29/21 18:28, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 07/29/21 17:45, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:

    <snip old stuff>

    Depending on the chip id, some functions may be inhibited if the control
    lines are in the wrong state. So yes, chip hardware architecture does >>>>>>> matter and not always something that can be abstracted away within the >>>>>>> device driver. Devil is in the detail, as usual...

    Yeah, so?

    The card obviously works to specification, i.e. RS-232 and it does see CTS.

    If it did not work to specification, I would return the card to the >>>>>> vendor and buy a different one.



    This is hard work, obviously never designed any hardware, nor written >>>>> code for it. While the card may very well meet spec, the spec can't
    cover all the myriad cases of operation or use.The spec is often
    generalised, to allow some slack in component selection and to take
    account of advances in the art, but it's the corner cases that can
    catch out the unwary...

    Do you understand the difference between DIY and purchasing a commercial >>>> product sold to thousands upon thousands if not millions of purchasers? >>>>
    Do you understand that RS-232 is many decades old and is specified by
    TIA-232-F Interface Between Data Terminal Equipment and Data
    Circuit-Terminating Equipment Employing Serial Binary Data Interchange, >>>> issued in 1997?

    The box and the card are both RS-232.

    The card and box combination obviously works.

    None of this has ANYTHING to do with the issue of gpsd.



    That's just the spec for the signals on the wires, nothing to do
    with how that is implemented inside devices, or on your pc card,
    which may be implemented in many different ways, from bit banging
    to fully integrated devices with buffering and even some
    intelligence. It only affects your low cost gpsd if you can't
    make it work, and need to dig into why it doesn't work...

    1) I no more care how the manufacturer inplemented what is inside the
    box or on the PC card than I care what kind of steel was used to make
    the exhaust manifold on my car.

    2) The box is low cost compared to the tens of thousands of dollars such
    things used to cost.

    That is of course completely irrelevant. The same could be said of an aluminum
    spoon (cost mcuch more than a gold spoon), and yet it would still not be most people's first choice for
    tableware.

    At one time the cost of aluminum was much higher than gold...


    Thank you for your suggestions. I always notice the host name part of the prompt string, which is different from each other for the test case discussed here, when I'm on different hosts.

    3) If the box doesn't work, it goes back for a refund. I have no
    interest in fixing things with a warrenty.

    But then as point 4 says, you do not know if it is the box or some misconfiguration (the wetware behind the keyboard) or a bug in gpsd.

    Point 4 says I DO know the problem is in gpsd.


    4) It is blazingly obvious to anyone paying the slightest bit of
    attention that the problem is in software, i.e. gpsd, and not the box.

    And yet, you also have been cogitating about the possibility that the
    serial port (either on the box or on the computer) does not satisfy the RS232 standards, which is hardware


    No, I have not, that is someone else fixating on that. That was settled
    as far as I am concerned before I made the first post.

    How about trying the direct use of ldattach, instead of using gpsd, to
    see if you can get that to work. If it does, and gpsd does not then your hypothesis that gpsd is at fault is born out. Then you can decide
    whether it is better to suffer the slings and arrows of debugging gpsd,
    or with one fell swoop use ldattach and have a working system.

    That gpsd has some sort of issue is well established at this point.

    Any further debugging of gpsd will be done with the gpsd support list.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Jim Pennino on Fri Jul 30 02:40:23 2021
    On 2021-07-30, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    William Unruh <unruh@invalid.ca> wrote:

    2) The box is low cost compared to the tens of thousands of dollars such >>> things used to cost.

    That is of course completely irrelevant. The same could be said of an aluminum
    spoon (cost mcuch more than a gold spoon), and yet it would still not be most people's first choice for
    tableware.

    At one time the cost of aluminum was much higher than gold...

    Yes. Precisely. You are the one claiming that because prices are cheaper
    now, it means something about the quality of the object for the purpose.

    But then as point 4 says, you do not know if it is the box or some
    misconfiguration (the wetware behind the keyboard) or a bug in gpsd.

    Point 4 says I DO know the problem is in gpsd.

    No.

    Why do you feel that you know that the problem is gpsd? You have tested
    the interrupt handling with other programs (lets say like ldattach)? Not
    that you have given any indication of. You simply say "it is obvious" Unfortunately I have seen far far to many instances in wich someone says
    "it is obvious" and they turned out to be entirely wrong.




    4) It is blazingly obvious to anyone paying the slightest bit of
    attention that the problem is in software, i.e. gpsd, and not the box.

    And yet, you also have been cogitating about the possibility that the
    serial port (either on the box or on the computer) does not satisfy the RS232 standards, which is hardware


    No, I have not, that is someone else fixating on that. That was settled
    as far as I am concerned before I made the first post.

    How about trying the direct use of ldattach, instead of using gpsd, to
    see if you can get that to work. If it does, and gpsd does not then your
    hypothesis that gpsd is at fault is born out. Then you can decide
    whether it is better to suffer the slings and arrows of debugging gpsd,
    or with one fell swoop use ldattach and have a working system.

    That gpsd has some sort of issue is well established at this point.

    Proof by blatant assertion is always a very poor argument.

    Since ldattach is a stadard part of linux, and since the use of it is
    trivial, your blind refusal to test is pretty suspicious.


    Any further debugging of gpsd will be done with the gpsd support list.

    And here I thought that the purpose was to get your time working, not to
    debug gpsd. Oh well, sorry.





    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to William Unruh on Thu Jul 29 20:03:29 2021
    William Unruh <unruh@invalid.ca> wrote:
    On 2021-07-30, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    William Unruh <unruh@invalid.ca> wrote:

    2) The box is low cost compared to the tens of thousands of dollars such >>>> things used to cost.

    That is of course completely irrelevant. The same could be said of an aluminum
    spoon (cost mcuch more than a gold spoon), and yet it would still not be most people's first choice for
    tableware.

    At one time the cost of aluminum was much higher than gold...

    Yes. Precisely. You are the one claiming that because prices are cheaper
    now, it means something about the quality of the object for the purpose.

    I have never said anything like that.

    What I did say was that I was interested in what such a device could do compared to the older stuff that cost two orders of magnitude more money
    new and still cost a magnitude more on the surplus market as well as
    taking up 5U in a 19 inch rack.


    But then as point 4 says, you do not know if it is the box or some
    misconfiguration (the wetware behind the keyboard) or a bug in gpsd.

    Point 4 says I DO know the problem is in gpsd.

    No.

    Why do you feel that you know that the problem is gpsd?

    If you actually read and understood what I wrote, you would know why.

    You have tested
    the interrupt handling with other programs (lets say like ldattach)? Not
    that you have given any indication of. You simply say "it is obvious" Unfortunately I have seen far far to many instances in wich someone says
    "it is obvious" and they turned out to be entirely wrong.

    It is obvious from what gpsd and related programs do that CTS gets
    through the plug and to the computer.

    What is not obvious is why gpsd does not forward PPS through the shared
    memory segment.

    4) It is blazingly obvious to anyone paying the slightest bit of
    attention that the problem is in software, i.e. gpsd, and not the box.

    And yet, you also have been cogitating about the possibility that the
    serial port (either on the box or on the computer) does not satisfy the RS232 standards, which is hardware


    No, I have not, that is someone else fixating on that. That was settled
    as far as I am concerned before I made the first post.

    How about trying the direct use of ldattach, instead of using gpsd, to
    see if you can get that to work. If it does, and gpsd does not then your >>> hypothesis that gpsd is at fault is born out. Then you can decide
    whether it is better to suffer the slings and arrows of debugging gpsd,
    or with one fell swoop use ldattach and have a working system.

    That gpsd has some sort of issue is well established at this point.

    Proof by blatant assertion is always a very poor argument.

    And also proved though discourse with people knowledgeable with gpsd.

    Since ldattach is a stadard part of linux, and since the use of it is trivial, your blind refusal to test is pretty suspicious.

    Since my major interest is in getting gpsd to work, it is irrelevant as
    gpsd takes care of such things.

    Any further debugging of gpsd will be done with the gpsd support list.

    And here I thought that the purpose was to get your time working, not to debug gpsd. Oh well, sorry.

    The original post was to attempt to find out why ntpd was not working.

    That evolved into discovering that ntpd doesn't work because gpsd has
    either a bug or a configuration issue.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to All on Sat Jul 31 07:16:42 2021
    Jim Pennino <jimp@gonzo.specsol.net> wrote:

    It turns out there is a kernel bug in Ubuntu 5.4.0-80-generic which
    breaks PPS processing.

    The net result is that an application that looks at /dev/ttySx will have
    no issues and will see CTS being asserted but anything that looks at
    /dev/ppsx will fail.

    According to Focal, a kernel update is imminent...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Jim Pennino on Sat Jul 31 16:47:10 2021
    Do you have a reference for this-- eg a URL?
    On 2021-07-31, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    Jim Pennino <jimp@gonzo.specsol.net> wrote:

    It turns out there is a kernel bug in Ubuntu 5.4.0-80-generic which
    breaks PPS processing.

    The net result is that an application that looks at /dev/ttySx will have
    no issues and will see CTS being asserted but anything that looks at /dev/ppsx will fail.

    According to Focal, a kernel update is imminent...



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to William Unruh on Sat Jul 31 12:41:16 2021
    William Unruh <unruh@invalid.ca> wrote:
    Do you have a reference for this-- eg a URL?

    A reference for the kernel bug?

    No, this was determined by downloading source for various GPS utility
    programs and running them under a debugger noting where the failure
    occured and seeing that it always happened in a ppsapi routine.

    And yes, the kernel says all the pps related modules are loaded.


    On 2021-07-31, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    Jim Pennino <jimp@gonzo.specsol.net> wrote:

    It turns out there is a kernel bug in Ubuntu 5.4.0-80-generic which
    breaks PPS processing.

    The net result is that an application that looks at /dev/ttySx will have
    no issues and will see CTS being asserted but anything that looks at
    /dev/ppsx will fail.

    According to Focal, a kernel update is imminent...



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Jim Pennino on Sat Jul 31 20:49:27 2021
    On 2021-07-31, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    William Unruh <unruh@invalid.ca> wrote:
    Do you have a reference for this-- eg a URL?

    A reference for the kernel bug?

    No, this was determined by downloading source for various GPS utility programs and running them under a debugger noting where the failure
    occured and seeing that it always happened in a ppsapi routine.

    So you reported the bug? What is the bug report then.
    What was the "failure"?
    Note that the pps driver is highly time sensative, and a debugger could
    upset that, and report bug which is due to the interaction with the
    debugger.


    And yes, the kernel says all the pps related modules are loaded.


    On 2021-07-31, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    Jim Pennino <jimp@gonzo.specsol.net> wrote:

    It turns out there is a kernel bug in Ubuntu 5.4.0-80-generic which
    breaks PPS processing.

    The net result is that an application that looks at /dev/ttySx will have >>> no issues and will see CTS being asserted but anything that looks at
    /dev/ppsx will fail.

    According to Focal, a kernel update is imminent...



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Jim Pennino on Sat Jul 31 21:58:20 2021
    On 2021-07-31, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    William Unruh <unruh@invalid.ca> wrote:
    On 2021-07-31, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    William Unruh <unruh@invalid.ca> wrote:
    Do you have a reference for this-- eg a URL?

    A reference for the kernel bug?

    No, this was determined by downloading source for various GPS utility
    programs and running them under a debugger noting where the failure
    occured and seeing that it always happened in a ppsapi routine.

    So you reported the bug? What is the bug report then.

    As there is an immenent kernel update, I didn't bother.

    Kernels are updated for many reasons, and there seems to be no reason
    why it would fix this particular bug if noone had ever reported it.

    And are you sure that the evidence for this bug is not there in many of
    the kernel versions? Ie, it could be a peculiarity of your own system
    rather than being generic.

    You were originally completely sure that this was a bug in gpsd. Now it
    is a kernel bug.

    If the update doesn't fix the issue, then I will consider a bug report
    for that kernel.

    What was the "failure"?
    Note that the pps driver is highly time sensative, and a debugger could
    upset that, and report bug which is due to the interaction with the
    debugger.

    I have been writiting and debugging software since mid 1970 and do have
    some idea of how it is done, but thank you for your comments.

    Quiz of the day: What does "RT" in RT-11 stand for?



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to William Unruh on Sat Jul 31 14:11:55 2021
    William Unruh <unruh@invalid.ca> wrote:
    On 2021-07-31, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    William Unruh <unruh@invalid.ca> wrote:
    Do you have a reference for this-- eg a URL?

    A reference for the kernel bug?

    No, this was determined by downloading source for various GPS utility
    programs and running them under a debugger noting where the failure
    occured and seeing that it always happened in a ppsapi routine.

    So you reported the bug? What is the bug report then.

    As there is an immenent kernel update, I didn't bother.

    If the update doesn't fix the issue, then I will consider a bug report
    for that kernel.

    What was the "failure"?
    Note that the pps driver is highly time sensative, and a debugger could
    upset that, and report bug which is due to the interaction with the
    debugger.

    I have been writiting and debugging software since mid 1970 and do have
    some idea of how it is done, but thank you for your comments.

    Quiz of the day: What does "RT" in RT-11 stand for?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to William Unruh on Sat Jul 31 15:18:34 2021
    William Unruh <unruh@invalid.ca> wrote:
    On 2021-07-31, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    William Unruh <unruh@invalid.ca> wrote:
    On 2021-07-31, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    William Unruh <unruh@invalid.ca> wrote:
    Do you have a reference for this-- eg a URL?

    A reference for the kernel bug?

    No, this was determined by downloading source for various GPS utility
    programs and running them under a debugger noting where the failure
    occured and seeing that it always happened in a ppsapi routine.

    So you reported the bug? What is the bug report then.

    As there is an immenent kernel update, I didn't bother.

    Kernels are updated for many reasons, and there seems to be no reason
    why it would fix this particular bug if noone had ever reported it.

    And as the update is immenent, I think it makes little to no difference
    if I wait until the release. And, no I did not search through the bugs
    data base. You may do so if you wish.

    And are you sure that the evidence for this bug is not there in many of
    the kernel versions? Ie, it could be a peculiarity of your own system
    rather than being generic.

    Does the id of the kernel, i.e. 5.4.0-80-generic, give you a clue?

    You were originally completely sure that this was a bug in gpsd. Now it
    is a kernel bug.

    No, I was originally sure the bug had something to do with gpsd, which
    does not necessarily mean IN gpsd. The real WTF moment came when I
    discovered ntpd does not work either for reasons that should be obvious
    now.

    And finally, to further beat this dead horse to ribbons, I have also
    found some issues with apparmor for both gpsd and ntpd.

    And before you even ask, put apparmor in complain for gpsd and ntpd to
    see if you are effected.


    If the update doesn't fix the issue, then I will consider a bug report
    for that kernel.

    What was the "failure"?
    Note that the pps driver is highly time sensative, and a debugger could
    upset that, and report bug which is due to the interaction with the
    debugger.

    I have been writiting and debugging software since mid 1970 and do have
    some idea of how it is done, 5.4.0-80-genericbut thank you for your comments.

    Quiz of the day: What does "RT" in RT-11 stand for?

    Question too tough for you?

    Here's another: What is the response if you type who on the terminal of
    a RT-11 machine?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to Jim Pennino on Sun Aug 1 00:52:15 2021
    On 07/31/21 22:11, Jim Pennino wrote:

    Quiz of the day: What does "RT" in RT-11 stand for?



    Real Time, RT11, an early operating system for dec pdp11. It
    was a single tasking / forground background os that was good
    for real time control and quite lightweight.

    Spent quite a few years programming macro under RT11 and RSX...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Miroslav Lichvar@21:1/5 to Jim Pennino on Mon Aug 2 10:23:22 2021
    On 2021-07-31, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    It turns out there is a kernel bug in Ubuntu 5.4.0-80-generic which
    breaks PPS processing.

    The net result is that an application that looks at /dev/ttySx will have
    no issues and will see CTS being asserted but anything that looks at /dev/ppsx will fail.

    I think that is expected if you have the PPS signal connected to CTS.
    AFAIK the kernel PPS serial driver works only with DCD.

    gpsd supports the kernel PPS and also (a much less precise) user-space
    PPS if the kernel PPS does not work.

    However, I'm not sure why it worked for you only when started directly
    from command line. It might help if we could compare the gpsd debug
    output or strace output in both cases.

    --
    Miroslav Lichvar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to Miroslav Lichvar on Mon Aug 2 13:28:47 2021
    On 08/02/21 11:23, Miroslav Lichvar wrote:
    On 2021-07-31, Jim Pennino<jimp@gonzo.specsol.net> wrote:
    It turns out there is a kernel bug in Ubuntu 5.4.0-80-generic which
    breaks PPS processing.

    The net result is that an application that looks at /dev/ttySx will have
    no issues and will see CTS being asserted but anything that looks at
    /dev/ppsx will fail.

    I think that is expected if you have the PPS signal connected to CTS.
    AFAIK the kernel PPS serial driver works only with DCD.

    gpsd supports the kernel PPS and also (a much less precise) user-space
    PPS if the kernel PPS does not work.

    However, I'm not sure why it worked for you only when started directly
    from command line. It might help if we could compare the gpsd debug
    output or strace output in both cases.


    The dcd line is what I used, as that is what was specified for
    ntpd under FreeBSD. It provides a local microsecond sync, as the
    following shows:


    root@ntp-host:~ # ntpq -pn
    remote refid st t when poll reach delay offset jitter ==================================================================== o127.127.22.0 .PPS. 0 l 5 8 377 0.000 0.002 0.001 +192.9.200.168 .GPS. 1 u 23 64 377 0.168 0.004 0.059 *192.9.200.169 .GPS. 1 u 34 64 377 0.365 -0.002 0.042

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to Miroslav Lichvar on Mon Aug 2 06:01:23 2021
    Miroslav Lichvar <mlichvar@redhat.com> wrote:
    On 2021-07-31, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    It turns out there is a kernel bug in Ubuntu 5.4.0-80-generic which
    breaks PPS processing.

    The net result is that an application that looks at /dev/ttySx will have
    no issues and will see CTS being asserted but anything that looks at
    /dev/ppsx will fail.

    I think that is expected if you have the PPS signal connected to CTS.
    AFAIK the kernel PPS serial driver works only with DCD.

    Then that is a bug because most real devices use CTS.

    gpsmon /dev/ttyS0 shows ---PPS---- in the data window.

    gpsd supports the kernel PPS and also (a much less precise) user-space
    PPS if the kernel PPS does not work.

    gpsd uses the pps_api.

    However, I'm not sure why it worked for you only when started directly
    from command line. It might help if we could compare the gpsd debug
    output or strace output in both cases.

    Calling any pps_api routine from anything fails.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Mon Aug 2 07:33:49 2021
    chris <chris-nospam@tridac.net> wrote:
    On 08/02/21 11:23, Miroslav Lichvar wrote:
    On 2021-07-31, Jim Pennino<jimp@gonzo.specsol.net> wrote:
    It turns out there is a kernel bug in Ubuntu 5.4.0-80-generic which
    breaks PPS processing.

    The net result is that an application that looks at /dev/ttySx will have >>> no issues and will see CTS being asserted but anything that looks at
    /dev/ppsx will fail.

    I think that is expected if you have the PPS signal connected to CTS.
    AFAIK the kernel PPS serial driver works only with DCD.

    gpsd supports the kernel PPS and also (a much less precise) user-space
    PPS if the kernel PPS does not work.

    However, I'm not sure why it worked for you only when started directly
    from command line. It might help if we could compare the gpsd debug
    output or strace output in both cases.


    The dcd line is what I used, as that is what was specified for
    ntpd under FreeBSD. It provides a local microsecond sync, as the
    following shows:


    root@ntp-host:~ # ntpq -pn
    remote refid st t when poll reach delay offset jitter ==================================================================== o127.127.22.0 .PPS. 0 l 5 8 377 0.000 0.002 0.001 +192.9.200.168 .GPS. 1 u 23 64 377 0.168 0.004 0.059 *192.9.200.169 .GPS. 1 u 34 64 377 0.365 -0.002 0.042

    "In NTP versions after 4.0.99k23 is NMEA driver atomized what means that
    for PPS processing we don't need neither ATOM driver nor PPS command in ntp.conf."

    http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm 6.2.4.3.3

    Which means, assuming your PPS device outputs NMEA sentences, all you
    need to get both data and PPS is:

    server 127.127.20.0 mode (for your device) minpoll 4 maxpoll 4
    fudge 127.127.20.0 flag1 1

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Taylor@21:1/5 to Jim Pennino on Mon Aug 2 15:39:15 2021
    On 02/08/2021 14:01, Jim Pennino wrote:
    I think that is expected if you have the PPS signal connected to CTS.
    AFAIK the kernel PPS serial driver works only with DCD.

    Then that is a bug because most real devices use CTS.

    All the real devices I've used on Windows and multiple variants of Linux use DCD.

    --
    Cheers,
    David
    Web: http://www.satsignal.eu

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Terje Mathisen@21:1/5 to David Taylor on Mon Aug 2 16:55:54 2021
    David Taylor wrote:
    On 02/08/2021 14:01, Jim Pennino wrote:
    I think that is expected if you have the PPS signal connected to CTS.
    AFAIK the kernel PPS serial driver works only with DCD.

    Then that is a bug because most real devices use CTS.

    All the real devices I've used on Windows and multiple variants of Linux
    use DCD.

    I have to agree with David here:

    I have been a member of the NTP Hackers team for more than 25 years, and
    I have yet to see a PPS device on RS232 which doesn't use DCD.

    I have soldered together several (Motorola, Garmin, Sure) GPS reference
    clocks, all of those used DCD.

    Terje

    --
    - <Terje.Mathisen at tmsw.no>
    "almost all programming can be viewed as an exercise in caching"

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to David Taylor on Mon Aug 2 08:41:33 2021
    David Taylor <david-taylor@blueyonder.co.uk.invalid> wrote:
    On 02/08/2021 14:01, Jim Pennino wrote:
    I think that is expected if you have the PPS signal connected to CTS.
    AFAIK the kernel PPS serial driver works only with DCD.

    Then that is a bug because most real devices use CTS.

    All the real devices I've used on Windows and multiple variants of Linux use DCD.

    The computer operating system has nothing to do with how some external, commercial device is built.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to Terje Mathisen on Mon Aug 2 08:39:42 2021
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    David Taylor wrote:
    On 02/08/2021 14:01, Jim Pennino wrote:
    I think that is expected if you have the PPS signal connected to CTS.
    AFAIK the kernel PPS serial driver works only with DCD.

    Then that is a bug because most real devices use CTS.

    All the real devices I've used on Windows and multiple variants of Linux
    use DCD.

    I have to agree with David here:

    I have been a member of the NTP Hackers team for more than 25 years, and
    I have yet to see a PPS device on RS232 which doesn't use DCD.

    It is now 2021 and there have been changes.

    I have soldered together several (Motorola, Garmin, Sure) GPS reference clocks, all of those used DCD.

    Terje

    I have a commercial GNSSDO, which contains an OCXO as the rubidium
    option was a bit too pricey for me, and both models use CTS.

    There is no soldering involved as this is, again, a commercial device
    with a DB-9 on the panel with pin 8, i.e. CTS on the DTE end, labeled
    1PPS.

    If one runs gpsmon against this device it shows PPS being asserted on the
    data display line, so whoever wrote gpsmon has seen GPS devices with PPS
    on CTS.

    If one runs ppstest against this device it shows PPS being asserted, so
    whoever wrote ppstest has seen GPS devices with PPS on CTS.

    FYI the OCXO model is about $180 and the rubidium model is about $800.

    Arent't advances in technology great?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to Jim Pennino on Mon Aug 2 17:19:52 2021
    On 08/02/21 15:33, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/02/21 11:23, Miroslav Lichvar wrote:
    On 2021-07-31, Jim Pennino<jimp@gonzo.specsol.net> wrote:
    It turns out there is a kernel bug in Ubuntu 5.4.0-80-generic which
    breaks PPS processing.

    The net result is that an application that looks at /dev/ttySx will have >>>> no issues and will see CTS being asserted but anything that looks at
    /dev/ppsx will fail.

    I think that is expected if you have the PPS signal connected to CTS.
    AFAIK the kernel PPS serial driver works only with DCD.

    gpsd supports the kernel PPS and also (a much less precise) user-space
    PPS if the kernel PPS does not work.

    However, I'm not sure why it worked for you only when started directly
    from command line. It might help if we could compare the gpsd debug
    output or strace output in both cases.


    The dcd line is what I used, as that is what was specified for
    ntpd under FreeBSD. It provides a local microsecond sync, as the
    following shows:


    root@ntp-host:~ # ntpq -pn
    remote refid st t when poll reach delay offset jitter
    ====================================================================
    o127.127.22.0 .PPS. 0 l 5 8 377 0.000 0.002 0.001
    +192.9.200.168 .GPS. 1 u 23 64 377 0.168 0.004 0.059
    *192.9.200.169 .GPS. 1 u 34 64 377 0.365 -0.002 0.042

    "In NTP versions after 4.0.99k23 is NMEA driver atomized what means that
    for PPS processing we don't need neither ATOM driver nor PPS command in ntp.conf."

    http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm 6.2.4.3.3

    Which means, assuming your PPS device outputs NMEA sentences, all you
    need to get both data and PPS is:

    server 127.127.20.0 mode (for your device) minpoll 4 maxpoll 4
    fudge 127.127.20.0 flag1 1


    The pps line has nothing to do with nmea sentances directly, but is
    a ttl level pulse that marks the beginning of each second,
    typically with microsecond accuracy. It's a sync pulse for the current
    second.

    The nmea sentences provide the overall time of day, month, year,
    but fine resolution within the second can only be provided by the
    subsecond accuracy of the pps pulse. Obvious really, in that
    differing times of flight of the nmea sentences and decoding
    can never provide the required accuracy alone...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Woolley@21:1/5 to chris on Mon Aug 2 18:05:38 2021
    On 02/08/2021 17:26, chris wrote:
    If it's working properly and has been running for a few hours,
    offset against UTC should be in the microsecond range, not

    ntpd doesn't provide that information. It only provides the offset
    between the timing source and the PC's internal clock.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to Jim Pennino on Mon Aug 2 17:26:13 2021
    On 08/02/21 16:39, Jim Pennino wrote:
    Terje Mathisen<terje.mathisen@tmsw.no> wrote:
    David Taylor wrote:
    On 02/08/2021 14:01, Jim Pennino wrote:
    I think that is expected if you have the PPS signal connected to CTS. >>>>> AFAIK the kernel PPS serial driver works only with DCD.

    Then that is a bug because most real devices use CTS.

    All the real devices I've used on Windows and multiple variants of Linux >>> use DCD.

    I have to agree with David here:

    I have been a member of the NTP Hackers team for more than 25 years, and
    I have yet to see a PPS device on RS232 which doesn't use DCD.

    It is now 2021 and there have been changes.

    I have soldered together several (Motorola, Garmin, Sure) GPS reference
    clocks, all of those used DCD.

    Terje

    I have a commercial GNSSDO, which contains an OCXO as the rubidium
    option was a bit too pricey for me, and both models use CTS.

    There is no soldering involved as this is, again, a commercial device
    with a DB-9 on the panel with pin 8, i.e. CTS on the DTE end, labeled
    1PPS.

    If one runs gpsmon against this device it shows PPS being asserted on the data display line, so whoever wrote gpsmon has seen GPS devices with PPS
    on CTS.

    If one runs ppstest against this device it shows PPS being asserted, so whoever wrote ppstest has seen GPS devices with PPS on CTS.

    FYI the OCXO model is about $180 and the rubidium model is about $800.

    Arent't advances in technology great?



    They are, but if it's all now working, what output do you get
    from the ntpq utility. or equivalent, in terms of accuracy ?.
    If it's working properly and has been running for a few hours,
    offset against UTC should be in the microsecond range, not
    milliseconds, 3 orders of magnitude error...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Terje Mathisen@21:1/5 to Jim Pennino on Mon Aug 2 19:40:42 2021
    Jim Pennino wrote:
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    David Taylor wrote:
    On 02/08/2021 14:01, Jim Pennino wrote:
    I think that is expected if you have the PPS signal connected to CTS. >>>>> AFAIK the kernel PPS serial driver works only with DCD.

    Then that is a bug because most real devices use CTS.

    The above is simply wrong.


    All the real devices I've used on Windows and multiple variants of Linux >>> use DCD.

    I have to agree with David here:

    I have been a member of the NTP Hackers team for more than 25 years, and
    I have yet to see a PPS device on RS232 which doesn't use DCD.

    It is now 2021 and there have been changes.

    Not really.

    I have soldered together several (Motorola, Garmin, Sure) GPS reference
    clocks, all of those used DCD.

    Terje

    I have a commercial GNSSDO, which contains an OCXO as the rubidium
    option was a bit too pricey for me, and both models use CTS.

    Jim, I did not state that CTS was invalid, just that all I've personally
    seen have used DCD!

    In reality you can have a PPS signal on any bit line which have
    interrupt capability, this includes using a classic "Centronics"
    parallel port along with the serial port for NMEA or some other protocol
    to number the seconds.

    There is no soldering involved as this is, again, a commercial device
    with a DB-9 on the panel with pin 8, i.e. CTS on the DTE end, labeled
    1PPS.

    If one runs gpsmon against this device it shows PPS being asserted on the data display line, so whoever wrote gpsmon has seen GPS devices with PPS
    on CTS.

    If one runs ppstest against this device it shows PPS being asserted, so whoever wrote ppstest has seen GPS devices with PPS on CTS.

    FYI the OCXO model is about $180 and the rubidium model is about $800.

    Arent't advances in technology great?

    Oh, absolutely! :-)

    I wrote the software for Meinberg's super NTP server, i.e. a custom ntpd version which can run on all cores and share the processing load across
    them. This 1U rack server have either a TCXO or Rb internal frequency
    standard which provides excellent stability, much better than the
    short-term GPS stability.

    Terje

    --
    - <Terje.Mathisen at tmsw.no>
    "almost all programming can be viewed as an exercise in caching"

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Mon Aug 2 10:31:13 2021
    chris <chris-nospam@tridac.net> wrote:
    On 08/02/21 15:33, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/02/21 11:23, Miroslav Lichvar wrote:
    On 2021-07-31, Jim Pennino<jimp@gonzo.specsol.net> wrote:
    It turns out there is a kernel bug in Ubuntu 5.4.0-80-generic which
    breaks PPS processing.

    The net result is that an application that looks at /dev/ttySx will have >>>>> no issues and will see CTS being asserted but anything that looks at >>>>> /dev/ppsx will fail.

    I think that is expected if you have the PPS signal connected to CTS.
    AFAIK the kernel PPS serial driver works only with DCD.

    gpsd supports the kernel PPS and also (a much less precise) user-space >>>> PPS if the kernel PPS does not work.

    However, I'm not sure why it worked for you only when started directly >>>> from command line. It might help if we could compare the gpsd debug
    output or strace output in both cases.


    The dcd line is what I used, as that is what was specified for
    ntpd under FreeBSD. It provides a local microsecond sync, as the
    following shows:


    root@ntp-host:~ # ntpq -pn
    remote refid st t when poll reach delay offset jitter
    ====================================================================
    o127.127.22.0 .PPS. 0 l 5 8 377 0.000 0.002 0.001
    +192.9.200.168 .GPS. 1 u 23 64 377 0.168 0.004 0.059
    *192.9.200.169 .GPS. 1 u 34 64 377 0.365 -0.002 0.042

    "In NTP versions after 4.0.99k23 is NMEA driver atomized what means that
    for PPS processing we don't need neither ATOM driver nor PPS command in
    ntp.conf."

    http://www.ntp.org/ntpfaq/NTP-s-config-adv.htm 6.2.4.3.3

    Which means, assuming your PPS device outputs NMEA sentences, all you
    need to get both data and PPS is:

    server 127.127.20.0 mode (for your device) minpoll 4 maxpoll 4
    fudge 127.127.20.0 flag1 1


    The pps line has nothing to do with nmea sentances directly, but is
    a ttl level pulse that marks the beginning of each second,
    typically with microsecond accuracy. It's a sync pulse for the current second.

    The nmea sentences provide the overall time of day, month, year,
    but fine resolution within the second can only be provided by the
    subsecond accuracy of the pps pulse. Obvious really, in that
    differing times of flight of the nmea sentences and decoding
    can never provide the required accuracy alone...

    Yes, I know what PPS and NMEA mean and what they do, but thank you for
    your gratuitous reminder.

    As for "can never provide the required accuracy alone", that depends on
    what your required accuracy is. I have 3 USB GPS ntp machines that are
    all CONSISTENTLY accurate to about 2 milliseconds, which is better than
    you will ever get with network sources.

    An analysis of the loopstats file for one of these machines shows:

    loopstats
    Count:3926

    Avg offset: 0.00253469 milliseconds
    Std dev: 1.18121 milliseconds

    Avg error: 0.981876 milliseconds
    Std dev: 0.302864 milliseconds

    The point of my post, which you apparently totally missed judging by
    your knee jerk response, was that for current releases of ntpd, you do
    NOT need to use the type 22 driver to process PPS information for such
    has been added to the type 20 driver and is activated by flag 1.

    Of course, this OBVIOUSLY means the device must deliver both NMEA and
    PPS as I already said.

    This what ntpq -pn produces on such a system:

    remote refid st t when poll reach delay offset jitter ============================================================================== o127.127.20.0 .GPS. 0 l 12 16 377 0.000 0.004 0.002

    Notice the 'o' at the start of the line and that the driver is type 20
    and not type 22. This indicates that ntpd is processing PPS data.

    An analysis of the loopstats file for that machine shows:

    loopstats
    Count:3923

    Avg offset: 0.0643678 microseconds
    Std dev: 8.36833 microseconds

    Avg error: 1.98298 microseconds
    Std dev: 0.100354 microseconds

    Also notice that you do not need other network sources of time if you
    have a real reference clock with PPS as it is at least 3 orders of
    magnitude better than anything you will get over a network.

    If you are concerned about GPS going away, put your device on a UPS.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to David Woolley on Mon Aug 2 10:52:51 2021
    David Woolley <david@ex.djwhome.demon.invalid> wrote:
    On 02/08/2021 17:26, chris wrote:
    If it's working properly and has been running for a few hours,
    offset against UTC should be in the microsecond range, not

    ntpd doesn't provide that information. It only provides the offset
    between the timing source and the PC's internal clock.

    And to state the blazingly obvious, the whole point of running ntpd at
    all is to, hopefully, correct the system internal clock.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Mon Aug 2 10:43:01 2021
    chris <chris-nospam@tridac.net> wrote:
    On 08/02/21 16:39, Jim Pennino wrote:
    Terje Mathisen<terje.mathisen@tmsw.no> wrote:
    David Taylor wrote:
    On 02/08/2021 14:01, Jim Pennino wrote:
    I think that is expected if you have the PPS signal connected to CTS. >>>>>> AFAIK the kernel PPS serial driver works only with DCD.

    Then that is a bug because most real devices use CTS.

    All the real devices I've used on Windows and multiple variants of Linux >>>> use DCD.

    I have to agree with David here:

    I have been a member of the NTP Hackers team for more than 25 years, and >>> I have yet to see a PPS device on RS232 which doesn't use DCD.

    It is now 2021 and there have been changes.

    I have soldered together several (Motorola, Garmin, Sure) GPS reference
    clocks, all of those used DCD.

    Terje

    I have a commercial GNSSDO, which contains an OCXO as the rubidium
    option was a bit too pricey for me, and both models use CTS.

    There is no soldering involved as this is, again, a commercial device
    with a DB-9 on the panel with pin 8, i.e. CTS on the DTE end, labeled
    1PPS.

    If one runs gpsmon against this device it shows PPS being asserted on the
    data display line, so whoever wrote gpsmon has seen GPS devices with PPS
    on CTS.

    If one runs ppstest against this device it shows PPS being asserted, so
    whoever wrote ppstest has seen GPS devices with PPS on CTS.

    FYI the OCXO model is about $180 and the rubidium model is about $800.

    Arent't advances in technology great?



    They are, but if it's all now working, what output do you get
    from the ntpq utility. or equivalent, in terms of accuracy ?.
    If it's working properly and has been running for a few hours,
    offset against UTC should be in the microsecond range, not
    milliseconds, 3 orders of magnitude error...

    I never said that machine is "all now working".

    What part of the kernel PPS routines in the OS on that machine are broken
    and do NOT process PPS did you fail to understand?

    I expect the ntpq output for this device, when PPS is working, to be in
    the low nanoseconds range as that is what the manufactures specifications
    say. Right now the offset and and error are already in the microsecond
    range.

    You need to look at both the offset and estimated error fields of
    loopstats and calculate the standard deviation to get any real idea of
    the accuracy of ntpd.

    You do do numerical analysis and graphing of loopstats, don't you?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Jim Pennino on Mon Aug 2 18:24:52 2021
    On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:

    What part of the kernel PPS routines in the OS on that machine are broken
    and do NOT process PPS did you fail to understand?

    I expect the ntpq output for this device, when PPS is working, to be in
    the low nanoseconds range as that is what the manufactures specifications say. Right now the offset and and error are already in the microsecond
    range.

    Well, no. The interrupt handling routines in Linux and even the line
    from the gps to the machine are much slower than
    "low nanoseconds"

    You need to look at both the offset and estimated error fields of
    loopstats and calculate the standard deviation to get any real idea of
    the accuracy of ntpd.
    That may give you the random errors, not the systematic (eg from the
    interrupt time, signal propagation time, etc)


    You do do numerical analysis and graphing of loopstats, don't you?



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Jim Pennino on Mon Aug 2 18:20:17 2021
    On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    ....

    As for "can never provide the required accuracy alone", that depends on
    what your required accuracy is. I have 3 USB GPS ntp machines that are
    all CONSISTENTLY accurate to about 2 milliseconds, which is better than
    you will ever get with network sources.

    Uh, depends on your network sources. If it is nearby (eg in your
    building) then you can certainly get sub-ms accuracy from a network
    source (ie better than NMEA). If it is half way around the world, then
    you may well be right.
    ....
    ....
    ....
    ....

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Woolley@21:1/5 to Jim Pennino on Mon Aug 2 19:31:48 2021
    On 02/08/2021 18:52, Jim Pennino wrote:
    And to state the blazingly obvious, the whole point of running ntpd at
    all is to, hopefully, correct the system internal clock.

    But not against UTC, but rather against various secondary standards, and
    also not on the basis that the secondary standard is always right (in
    which case offset would always be exactly zero, immediately after a poll).

    People treat offset as too much of a holy grail when it is actually
    measured against something which is wrong, and doesn't have a stable
    error. Jitter is probably a better measure of the quality of the source

    (Incidentally, it is impossible to achieve zero offset from UTC in real
    time, as UTC isn't known until days, or maybe weeks, later.)

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to Terje Mathisen on Mon Aug 2 11:34:48 2021
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    Jim Pennino wrote:
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    David Taylor wrote:
    On 02/08/2021 14:01, Jim Pennino wrote:
    I think that is expected if you have the PPS signal connected to CTS. >>>>>> AFAIK the kernel PPS serial driver works only with DCD.

    Then that is a bug because most real devices use CTS.

    The above is simply wrong.

    OK, let me restate that.

    Most current, commercial devices not intended for the experimenter or
    hobbist market use CTS.

    FWIW, I did some research of such devices with a DB-9 connector on them.

    All the real devices I've used on Windows and multiple variants of Linux >>>> use DCD.

    I have to agree with David here:

    I have been a member of the NTP Hackers team for more than 25 years, and >>> I have yet to see a PPS device on RS232 which doesn't use DCD.

    It is now 2021 and there have been changes.

    Not really.

    Yes, really, e.g. GNSS and relatively cheap rubidium oscillators.

    With GNSS and a $15 USB GPS, one can obtain consistent time accuracy in
    the single digit milliseconds these days.

    I have soldered together several (Motorola, Garmin, Sure) GPS reference
    clocks, all of those used DCD.

    Terje

    I have a commercial GNSSDO, which contains an OCXO as the rubidium
    option was a bit too pricey for me, and both models use CTS.

    Jim, I did not state that CTS was invalid, just that all I've personally
    seen have used DCD!

    Then I guess you have learned something new today. Count that as a plus.


    In reality you can have a PPS signal on any bit line which have
    interrupt capability, this includes using a classic "Centronics"
    parallel port along with the serial port for NMEA or some other protocol
    to number the seconds.

    Sure all kinds of things are possible.

    However, one of my goals was off the shelf plug and play, not DYI of cables, interfaces, software, etc.

    There is no soldering involved as this is, again, a commercial device
    with a DB-9 on the panel with pin 8, i.e. CTS on the DTE end, labeled
    1PPS.

    If one runs gpsmon against this device it shows PPS being asserted on the
    data display line, so whoever wrote gpsmon has seen GPS devices with PPS
    on CTS.

    If one runs ppstest against this device it shows PPS being asserted, so
    whoever wrote ppstest has seen GPS devices with PPS on CTS.

    FYI the OCXO model is about $180 and the rubidium model is about $800.

    Arent't advances in technology great?

    Oh, absolutely! :-)

    I wrote the software for Meinberg's super NTP server, i.e. a custom ntpd version which can run on all cores and share the processing load across
    them. This 1U rack server have either a TCXO or Rb internal frequency standard which provides excellent stability, much better than the
    short-term GPS stability.

    Terje

    The box I have is 4WX4DX2H inches, provides a DB-9 connector for NMEA
    data and PPS and has outputs for 10 MHZ +/- 0.0002 Hz and 1PPS rated for
    jitter in the low nanoseconds. Though PPS for ntpd is not working yet, I
    have been able to recalibrate my frequency counter.

    I was concidering hanging it off a Rasberry Pi, which would make for a
    nice, neat system.

    However there is no neat and clean RS-232 interface that has CTS for the
    Pi.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to William Unruh on Mon Aug 2 11:49:41 2021
    William Unruh <unruh@invalid.ca> wrote:
    On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    ....

    As for "can never provide the required accuracy alone", that depends on
    what your required accuracy is. I have 3 USB GPS ntp machines that are
    all CONSISTENTLY accurate to about 2 milliseconds, which is better than
    you will ever get with network sources.

    Uh, depends on your network sources. If it is nearby (eg in your
    building) then you can certainly get sub-ms accuracy from a network
    source (ie better than NMEA). If it is half way around the world, then
    you may well be right.


    If it is only in the next city, I am right.

    FYI for personal reasons I am doing a survey of current GPS devices and
    do statistical analysis and graphing of ntpd performance on 5 machines of various configurations.

    The graphing clearly shows that network sources, and even the ISP
    sources only a few hops away, are VERY subject to random perturbations.

    If the case is limited to servers on your own network, then the random perturbations are very minimal, if any, on a 1G network.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to David Woolley on Mon Aug 2 12:15:42 2021
    David Woolley <david@ex.djwhome.demon.invalid> wrote:
    On 02/08/2021 18:52, Jim Pennino wrote:
    And to state the blazingly obvious, the whole point of running ntpd at
    all is to, hopefully, correct the system internal clock.

    But not against UTC, but rather against various secondary standards, and
    also not on the basis that the secondary standard is always right (in
    which case offset would always be exactly zero, immediately after a poll).

    Assuming such a standard existed, which it doesn't.

    People treat offset as too much of a holy grail when it is actually
    measured against something which is wrong, and doesn't have a stable
    error. Jitter is probably a better measure of the quality of the source

    Which is why I analyze and graph MUCH more than just offset.

    (Incidentally, it is impossible to achieve zero offset from UTC in real
    time, as UTC isn't known until days, or maybe weeks, later.)

    The people that run GPS claim the GPS offset from USNO UTC to be less
    than 40 nanoseconds worst case. That is good enough for me.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to William Unruh on Mon Aug 2 12:10:02 2021
    William Unruh <unruh@invalid.ca> wrote:
    On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:

    What part of the kernel PPS routines in the OS on that machine are broken
    and do NOT process PPS did you fail to understand?

    I expect the ntpq output for this device, when PPS is working, to be in
    the low nanoseconds range as that is what the manufactures specifications
    say. Right now the offset and and error are already in the microsecond
    range.

    Well, no. The interrupt handling routines in Linux and even the line
    from the gps to the machine are much slower than
    "low nanoseconds"

    We shall see...

    However, the absolute speed of everything is far less important than
    the consistency of PPS processing.

    That is, if one has an absolutely accurate PPS signal that is exactly
    1Hz, it doesn't matter how long, within reason, it takes to process the
    PPS signal. What matters is how much jitter the hardware and software
    has in processing the signal. Since the jitter in modern digital
    electronic is in the picosecond, that is not a factor. That means the determining factor will be the jitter in the interrupt handling.

    Which with 1 Ghz+ multiple core CPUs is hopefully in the low
    nanoseconds.


    You need to look at both the offset and estimated error fields of
    loopstats and calculate the standard deviation to get any real idea of
    the accuracy of ntpd.
    That may give you the random errors, not the systematic (eg from the interrupt time, signal propagation time, etc)

    Such will show up in the graphing of the various ntpd statistics files,
    and if it doesn't, that means the people that wrote the documentation
    for the ntpd statistics files were lying, which I highly doubt.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Jim Pennino on Mon Aug 2 20:44:55 2021
    On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    Jim Pennino wrote:
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    David Taylor wrote:
    On 02/08/2021 14:01, Jim Pennino wrote:
    I think that is expected if you have the PPS signal connected to CTS. >>>>>>> AFAIK the kernel PPS serial driver works only with DCD.

    Then that is a bug because most real devices use CTS.

    The above is simply wrong.

    OK, let me restate that.

    Most current, commercial devices not intended for the experimenter or
    hobbist market use CTS.

    FWIW, I did some research of such devices with a DB-9 connector on them.

    All the real devices I've used on Windows and multiple variants of Linux >>>>> use DCD.

    I have to agree with David here:

    I have been a member of the NTP Hackers team for more than 25 years, and >>>> I have yet to see a PPS device on RS232 which doesn't use DCD.

    It is now 2021 and there have been changes.

    Not really.

    Yes, really, e.g. GNSS and relatively cheap rubidium oscillators.

    With GNSS and a $15 USB GPS, one can obtain consistent time accuracy in
    the single digit milliseconds these days.

    With PPS. Without PPS, even the length of the nmea sentences vary more
    than that.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Jim Pennino on Mon Aug 2 20:41:08 2021
    On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    David Woolley <david@ex.djwhome.demon.invalid> wrote:
    On 02/08/2021 18:52, Jim Pennino wrote:
    And to state the blazingly obvious, the whole point of running ntpd at
    all is to, hopefully, correct the system internal clock.

    But not against UTC, but rather against various secondary standards, and
    also not on the basis that the secondary standard is always right (in
    which case offset would always be exactly zero, immediately after a poll).

    Assuming such a standard existed, which it doesn't.

    People treat offset as too much of a holy grail when it is actually
    measured against something which is wrong, and doesn't have a stable
    error. Jitter is probably a better measure of the quality of the source

    Which is why I analyze and graph MUCH more than just offset.

    (Incidentally, it is impossible to achieve zero offset from UTC in real
    time, as UTC isn't known until days, or maybe weeks, later.)

    The people that run GPS claim the GPS offset from USNO UTC to be less
    than 40 nanoseconds worst case. That is good enough for me.


    And apparently usually a sawtooth error. But the fact that the leading
    edge of the pulse is within 40ns does not mean that the system time is
    within 40ns. As I said, the computer receives the signal. At some point
    in the rise time of the pulse (smeared out by propagation delays and
    impedance mismatches in the cable connecting the gps to the computer) it triggers and interrupt. The computer has to stop what it is doing,
    branch out to the interrupt handler (assuming that some non-maskable
    interrupt is not running which delays that) start running the interrupt
    handler program, send out a command to another subroutine in the kernel
    to read the system clock and translate that into time, and deliver that
    time back to the interrupt handler. All of that take time. As I said, my measurements gave something like 1 microsecond in best case (2 or 3 or
    even 10 in worst cases) in delay. There is nothing that ntp can do to to
    know what that delay is. You can, with diffuculty, measure it, and you
    could tell ntpd to subtract that from the time, but it is not
    necessarily consistant, and will depend on the state of use of the cpus.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Jim Pennino on Mon Aug 2 20:30:47 2021
    On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    William Unruh <unruh@invalid.ca> wrote:
    On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:

    What part of the kernel PPS routines in the OS on that machine are broken >>> and do NOT process PPS did you fail to understand?

    I expect the ntpq output for this device, when PPS is working, to be in
    the low nanoseconds range as that is what the manufactures specifications >>> say. Right now the offset and and error are already in the microsecond
    range.

    Well, no. The interrupt handling routines in Linux and even the line
    from the gps to the machine are much slower than
    "low nanoseconds"

    We shall see...

    However, the absolute speed of everything is far less important than
    the consistency of PPS processing.

    That is, if one has an absolutely accurate PPS signal that is exactly
    1Hz, it doesn't matter how long, within reason, it takes to process the
    PPS signal. What matters is how much jitter the hardware and software
    has in processing the signal. Since the jitter in modern digital
    electronic is in the picosecond, that is not a factor. That means the determining factor will be the jitter in the interrupt handling.

    That may be true for your purposes. However, accuracy is Computer time -
    UTC. So clearly if to 1 ns the difference is always 3 days, one would
    not call that accurate. The interrupt handling/propagation delays are
    one way. They always make the computer time later than UTC. My
    measurements a few years ago showed that the interrupt delay was about 1 microsecond.

    Which with 1 Ghz+ multiple core CPUs is hopefully in the low
    nanoseconds.

    There is no way that the interrupt processing is that fast. Even the
    reading of the local clock is not that fast.



    You need to look at both the offset and estimated error fields of
    loopstats and calculate the standard deviation to get any real idea of
    the accuracy of ntpd.
    That may give you the random errors, not the systematic (eg from the
    interrupt time, signal propagation time, etc)

    Such will show up in the graphing of the various ntpd statistics files,
    and if it doesn't, that means the people that wrote the documentation
    for the ntpd statistics files were lying, which I highly doubt.

    There is no way that ntpd can measure the delay. It has no idea what UTC actually is. All it has is reading of the computer system time when the interrupt comes in-- which takes a while to process.
    You could get a measure if, as soon as the interrupt process measured
    the system time, it toggled some output port up, and then you attached a oscilliscope to that port, and the gps input and looked at the delay
    between the two.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Woolley@21:1/5 to Jim Pennino on Mon Aug 2 22:24:15 2021
    On 02/08/2021 20:15, Jim Pennino wrote:
    But not against UTC, but rather against various secondary standards, and
    also not on the basis that the secondary standard is always right (in
    which case offset would always be exactly zero, immediately after a poll).

    Assuming such a standard existed, which it doesn't.


    I was describing an algorithm that would do this, not a source. Such an algorithm wouldn't normally be a good one.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to William Unruh on Mon Aug 2 14:33:28 2021
    William Unruh <unruh@invalid.ca> wrote:
    On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    Jim Pennino wrote:
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    David Taylor wrote:
    On 02/08/2021 14:01, Jim Pennino wrote:
    I think that is expected if you have the PPS signal connected to CTS. >>>>>>>> AFAIK the kernel PPS serial driver works only with DCD.

    Then that is a bug because most real devices use CTS.

    The above is simply wrong.

    OK, let me restate that.

    Most current, commercial devices not intended for the experimenter or
    hobbist market use CTS.

    FWIW, I did some research of such devices with a DB-9 connector on them.

    All the real devices I've used on Windows and multiple variants of Linux >>>>>> use DCD.

    I have to agree with David here:

    I have been a member of the NTP Hackers team for more than 25 years, and >>>>> I have yet to see a PPS device on RS232 which doesn't use DCD.

    It is now 2021 and there have been changes.

    Not really.

    Yes, really, e.g. GNSS and relatively cheap rubidium oscillators.

    With GNSS and a $15 USB GPS, one can obtain consistent time accuracy in
    the single digit milliseconds these days.

    With PPS. Without PPS, even the length of the nmea sentences vary more
    than that.

    No, without PPS.

    How much the NMEA sentences vary depends on the speed of the electronics
    in the receiver and how many satellites the receiver can process.

    Some old USB GPS pucks have jitter at the hundred millisecond level and
    a very few at the tens of millisecond level, and what you said used to
    be true.

    Modern USB GNSS pucks have jitter at the millsecond level and a standard deviation of about 1 millisecond.

    So, in summary, CURRENT, MODERN GNSS receivers have better sensitity,
    can see and process more satellites, and have faster electronics inside
    them.

    How do I know this you say?

    As I have said many times before, I am doing a study of CURRENT, MODERN
    GNSS devices and how well they work with ntpd.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to William Unruh on Mon Aug 2 14:17:30 2021
    William Unruh <unruh@invalid.ca> wrote:
    On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    William Unruh <unruh@invalid.ca> wrote:
    On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:

    What part of the kernel PPS routines in the OS on that machine are broken >>>> and do NOT process PPS did you fail to understand?

    I expect the ntpq output for this device, when PPS is working, to be in >>>> the low nanoseconds range as that is what the manufactures specifications >>>> say. Right now the offset and and error are already in the microsecond >>>> range.

    Well, no. The interrupt handling routines in Linux and even the line
    from the gps to the machine are much slower than
    "low nanoseconds"

    We shall see...

    However, the absolute speed of everything is far less important than
    the consistency of PPS processing.

    That is, if one has an absolutely accurate PPS signal that is exactly
    1Hz, it doesn't matter how long, within reason, it takes to process the
    PPS signal. What matters is how much jitter the hardware and software
    has in processing the signal. Since the jitter in modern digital
    electronic is in the picosecond, that is not a factor. That means the
    determining factor will be the jitter in the interrupt handling.

    That may be true for your purposes. However, accuracy is Computer time -
    UTC. So clearly if to 1 ns the difference is always 3 days, one would
    not call that accurate. The interrupt handling/propagation delays are
    one way. They always make the computer time later than UTC. My
    measurements a few years ago showed that the interrupt delay was about 1 microsecond.

    Whop dee fucking do.

    Have you tried your measurements with a rubidium standard?


    Which with 1 Ghz+ multiple core CPUs is hopefully in the low
    nanoseconds.

    There is no way that the interrupt processing is that fast. Even the
    reading of the local clock is not that fast.

    We shall see what happens.

    BTW, bumble bees can't fly, the Earth is flat, and disease is caused by
    bad vapors.


    You need to look at both the offset and estimated error fields of
    loopstats and calculate the standard deviation to get any real idea of >>>> the accuracy of ntpd.
    That may give you the random errors, not the systematic (eg from the
    interrupt time, signal propagation time, etc)

    Such will show up in the graphing of the various ntpd statistics files,
    and if it doesn't, that means the people that wrote the documentation
    for the ntpd statistics files were lying, which I highly doubt.

    There is no way that ntpd can measure the delay. It has no idea what UTC actually is. All it has is reading of the computer system time when the interrupt comes in-- which takes a while to process.
    You could get a measure if, as soon as the interrupt process measured
    the system time, it toggled some output port up, and then you attached a oscilliscope to that port, and the gps input and looked at the delay
    between the two.

    So what you are saying is that rubidium clocks are a hoax?

    With an attached GPS, the computer knows what UTC actually is within some number of milliseconds which varies with the quality of the GPS and it's jitter.

    With a MODERN GNSS receiver, that number of milliseconds is less than 10
    after the settling time.

    With an attached MODERN GNSS receiver and PPS with a decent oscillator,
    the computer knows what UTC actually is within some number of nanoseconds
    less than 1,000.

    What that number of nanoseconds will be is determined by the jitter in
    the PPS signal and how quickly the computer can process interrupts.

    While the first GPS receive used vacuum tubes, stood six feet tall, and
    had two seats for operator(s), things have changed a bit.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to William Unruh on Mon Aug 2 14:02:52 2021
    William Unruh <unruh@invalid.ca> wrote:
    On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    David Woolley <david@ex.djwhome.demon.invalid> wrote:
    On 02/08/2021 18:52, Jim Pennino wrote:
    And to state the blazingly obvious, the whole point of running ntpd at >>>> all is to, hopefully, correct the system internal clock.

    But not against UTC, but rather against various secondary standards, and >>> also not on the basis that the secondary standard is always right (in
    which case offset would always be exactly zero, immediately after a poll). >>
    Assuming such a standard existed, which it doesn't.

    People treat offset as too much of a holy grail when it is actually
    measured against something which is wrong, and doesn't have a stable
    error. Jitter is probably a better measure of the quality of the source

    Which is why I analyze and graph MUCH more than just offset.

    (Incidentally, it is impossible to achieve zero offset from UTC in real
    time, as UTC isn't known until days, or maybe weeks, later.)

    The people that run GPS claim the GPS offset from USNO UTC to be less
    than 40 nanoseconds worst case. That is good enough for me.


    And apparently usually a sawtooth error. But the fact that the leading
    edge of the pulse is within 40ns does not mean that the system time is
    within 40ns. As I said, the computer receives the signal. At some point
    in the rise time of the pulse (smeared out by propagation delays and impedance mismatches in the cable connecting the gps to the computer) it triggers and interrupt. The computer has to stop what it is doing,
    branch out to the interrupt handler (assuming that some non-maskable interrupt is not running which delays that) start running the interrupt handler program, send out a command to another subroutine in the kernel
    to read the system clock and translate that into time, and deliver that
    time back to the interrupt handler. All of that take time. As I said, my measurements gave something like 1 microsecond in best case (2 or 3 or
    even 10 in worst cases) in delay. There is nothing that ntp can do to to
    know what that delay is. You can, with diffuculty, measure it, and you
    could tell ntpd to subtract that from the time, but it is not
    necessarily consistant, and will depend on the state of use of the cpus.

    Absolute and consistent delay is irrelevaent.

    The processes of reading the PPS edge and getting the system time are independent processes.

    If things were as you say, rubidium clocks would not work.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Jim Pennino on Mon Aug 2 22:04:24 2021
    On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    William Unruh <unruh@invalid.ca> wrote:
    On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    David Woolley <david@ex.djwhome.demon.invalid> wrote:
    On 02/08/2021 18:52, Jim Pennino wrote:
    And to state the blazingly obvious, the whole point of running ntpd at >>>>> all is to, hopefully, correct the system internal clock.

    But not against UTC, but rather against various secondary standards, and >>>> also not on the basis that the secondary standard is always right (in
    which case offset would always be exactly zero, immediately after a poll). >>>
    Assuming such a standard existed, which it doesn't.

    People treat offset as too much of a holy grail when it is actually
    measured against something which is wrong, and doesn't have a stable
    error. Jitter is probably a better measure of the quality of the source >>>
    Which is why I analyze and graph MUCH more than just offset.

    (Incidentally, it is impossible to achieve zero offset from UTC in real >>>> time, as UTC isn't known until days, or maybe weeks, later.)

    The people that run GPS claim the GPS offset from USNO UTC to be less
    than 40 nanoseconds worst case. That is good enough for me.


    And apparently usually a sawtooth error. But the fact that the leading
    edge of the pulse is within 40ns does not mean that the system time is
    within 40ns. As I said, the computer receives the signal. At some point
    in the rise time of the pulse (smeared out by propagation delays and
    impedance mismatches in the cable connecting the gps to the computer) it
    triggers and interrupt. The computer has to stop what it is doing,
    branch out to the interrupt handler (assuming that some non-maskable
    interrupt is not running which delays that) start running the interrupt
    handler program, send out a command to another subroutine in the kernel
    to read the system clock and translate that into time, and deliver that
    time back to the interrupt handler. All of that take time. As I said, my
    measurements gave something like 1 microsecond in best case (2 or 3 or
    even 10 in worst cases) in delay. There is nothing that ntp can do to to
    know what that delay is. You can, with diffuculty, measure it, and you
    could tell ntpd to subtract that from the time, but it is not
    necessarily consistant, and will depend on the state of use of the cpus.

    Absolute and consistent delay is irrelevaent.

    The processes of reading the PPS edge and getting the system time are independent processes.

    If things were as you say, rubidium clocks would not work.

    Rubidium clocks are not general purpose computers. Their electronics are
    all specially built to reduce the errors as much as possible.
    Absolute and consistant delay is NOT irrelevant. It is part of the error
    budget that determines the accuracy of the clock. Or would you not care
    if your clock was 3 days out in its time? If not, that is fine, but most
    people would not call it accurate.




    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Jim Pennino on Mon Aug 2 22:07:42 2021
    On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    William Unruh <unruh@invalid.ca> wrote:
    On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    Jim Pennino wrote:
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    David Taylor wrote:
    On 02/08/2021 14:01, Jim Pennino wrote:
    I think that is expected if you have the PPS signal connected to CTS. >>>>>>>>> AFAIK the kernel PPS serial driver works only with DCD.

    Then that is a bug because most real devices use CTS.

    The above is simply wrong.

    OK, let me restate that.

    Most current, commercial devices not intended for the experimenter or
    hobbist market use CTS.

    FWIW, I did some research of such devices with a DB-9 connector on them. >>>
    All the real devices I've used on Windows and multiple variants of Linux
    use DCD.

    I have to agree with David here:

    I have been a member of the NTP Hackers team for more than 25 years, and >>>>>> I have yet to see a PPS device on RS232 which doesn't use DCD.

    It is now 2021 and there have been changes.

    Not really.

    Yes, really, e.g. GNSS and relatively cheap rubidium oscillators.

    With GNSS and a $15 USB GPS, one can obtain consistent time accuracy in
    the single digit milliseconds these days.

    With PPS. Without PPS, even the length of the nmea sentences vary more
    than that.

    No, without PPS.

    How much the NMEA sentences vary depends on the speed of the electronics
    in the receiver and how many satellites the receiver can process.

    No. The NMEA sentences themselves are variable length. And the RS22
    standard means that the data goes up the line not very fast. Each
    character takes milliseconds to be transmitted.

    Some old USB GPS pucks have jitter at the hundred millisecond level and
    a very few at the tens of millisecond level, and what you said used to
    be true.
    It is RS232 that is the problem.


    Modern USB GNSS pucks have jitter at the millsecond level and a standard deviation of about 1 millisecond.

    So, in summary, CURRENT, MODERN GNSS receivers have better sensitity,
    can see and process more satellites, and have faster electronics inside
    them.

    Of course.


    How do I know this you say?

    As I have said many times before, I am doing a study of CURRENT, MODERN
    GNSS devices and how well they work with ntpd.



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to chris on Mon Aug 2 22:45:35 2021
    On 2021-08-02, chris <chris-nospam@tridac.net> wrote:
    On 08/02/21 18:05, David Woolley wrote:
    On 02/08/2021 17:26, chris wrote:
    If it's working properly and has been running for a few hours,
    offset against UTC should be in the microsecond range, not

    ntpd doesn't provide that information. It only provides the offset
    between the timing source and the PC's internal clock.

    Correct me if i'm wrong, but pps is traceable to UTC, so that would be
    used within ntpd to set the system clock. In the case of several

    If one wants sub-microsecond accuracy, then how it is used within ntpd
    becomes important. Lets assume that the gps module itself is good. The
    hardware inside the receiver delivers a pps pulse at the UTC second (it
    does not, it fluctuates a few 10s of nanoseconds from that). That pulse
    then travels down the cable to the computer. If the impedance matching
    between the receiver and the computer is not good, then that pulse gets
    smeared out over many travel times down the cable. At a certain voltage
    level, a trigger in the driver flips, and that raises and interrupt
    voltage. The hardware watches for that flip, and tells the cpu to stop (controllably) what it is doing, caches the currently running program,
    loads the interrupt driver program, and branches to that program. If
    that program is well written, it then calls a kernel subroutine, loading
    it into memory if need be, and calls a program to convert the counter,
    which is the system clock, reads out the count, and converts that count
    to a time. It then returns that time to the interrupt driver routine.
    All of that takes time. All of that takes a variable amount of time. For example, if another interrupt service routine is running ( eg due to
    disk reads) this one will wait for it to finish (in the sense of
    signalling that it is OK for it to be interrupted )


    ntp server sources, ntpd will weed out the outliers, keep the best and
    use that to set local system time. ntpq then provides a list showing
    what it thinks are the timing relationships between them, with pps utc
    as the primary reference ?...

    No. The PPS timing is simply one amongst the lot. It may well be the
    chosen one, and its low stratum will mean that ntpd will be more likely
    to choose it. But not necessarily.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to David Woolley on Mon Aug 2 23:25:59 2021
    On 08/02/21 18:05, David Woolley wrote:
    On 02/08/2021 17:26, chris wrote:
    If it's working properly and has been running for a few hours,
    offset against UTC should be in the microsecond range, not

    ntpd doesn't provide that information. It only provides the offset
    between the timing source and the PC's internal clock.

    Correct me if i'm wrong, but pps is traceable to UTC, so that would be
    used within ntpd to set the system clock. In the case of several
    ntp server sources, ntpd will weed out the outliers, keep the best and
    use that to set local system time. ntpq then provides a list showing
    what it thinks are the timing relationships between them, with pps utc
    as the primary reference ?...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to William Unruh on Mon Aug 2 15:59:03 2021
    William Unruh <unruh@invalid.ca> wrote:
    On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:

    <snip old crap>

    Absolute and consistent delay is irrelevaent.

    The processes of reading the PPS edge and getting the system time are
    independent processes.

    If things were as you say, rubidium clocks would not work.

    Rubidium clocks are not general purpose computers. Their electronics are
    all specially built to reduce the errors as much as possible.
    Absolute and consistant delay is NOT irrelevant. It is part of the error budget that determines the accuracy of the clock. Or would you not care
    if your clock was 3 days out in its time? If not, that is fine, but most people would not call it accurate.

    Rubidium clocks are NOT clocks and do not tell time.

    A modern rubidium clock is a box containing a rubidium oscillator that is disciplined by an included GNSS receiver. The electronics is off the shelf chips.

    And there are no vacuum tubes in there either.

    The GNSS receiver provides the GNSS data output and the precision
    rubidium oscillator provides the PPS signal.

    A rubidium clock has PPS jitter of around 1 nanosecond and to a computer
    looks like an extremely low jitter GNSS receiver.

    Most also provide an output as a frequency standard.

    You keep arm waving about "3 days", why?

    Why would you say something as blazingly obvious as "Rubidium clocks are
    not general purpose computers"?

    Are you purposely trying to be condescending?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Mon Aug 2 16:37:57 2021
    chris <chris-nospam@tridac.net> wrote:
    On 08/02/21 18:05, David Woolley wrote:
    On 02/08/2021 17:26, chris wrote:
    If it's working properly and has been running for a few hours,
    offset against UTC should be in the microsecond range, not

    ntpd doesn't provide that information. It only provides the offset
    between the timing source and the PC's internal clock.

    Correct me if i'm wrong, but pps is traceable to UTC, so that would be
    used within ntpd to set the system clock. In the case of several
    ntp server sources, ntpd will weed out the outliers, keep the best and
    use that to set local system time. ntpq then provides a list showing
    what it thinks are the timing relationships between them, with pps utc
    as the primary reference ?...

    PPS has no information. The purpose of PPS is to provide a reference
    that is as close to 1 Hz, i.e. an elapsed time of 1 second, as possible.

    It is the NMEA sentences that contain the date and time along with stuff irrelevant to time, e.g. altitude, speed, etc.

    When the NMEA sentences appear is not specified by anything and their appearance times have a LOT of jitter in them.

    To VASTLY simplify, what ntpd does is look at the GPS time, which is in nanoseconds, and the computer system clock time when the PPS occurs
    and correlate them. ntpd either slows or speeds up the computer system
    clock until the computer system clock is in sync with the GPS time at
    the time of the PPS to the best accuacy it can achieve with the given
    hardware.

    A receiver does not get data from one, satellite, it gets data from all
    the satellites it can see to the limit of how many channels the receiver
    was designed to see at once and provides a NMEA sentence type as the
    best average from all the data it gets.

    A recent, modern receiver is not just GPS, but GNSS which means it can
    see more systems, e.g. GLONASS, has more channels than old receivers,
    has better receiver sensitivity and faster electronics.

    The net result is a modern GNSS receiver has better data as it is the
    average of more satellites and less jitter because data is processed
    faster.

    It also seems the ntpd algorithms fall apart if you have multiple high
    accuracy reference clocks attached. I doubt any of the designers ever envisioned the day would come when someone could afford more than one as
    at that time such things would set you back many tens of thousands of
    dollars.

    Now they cost less than $50.

    This is irrelevant as if you have a high accuracy reference clock, you
    only need one and ntpd will sort itself out just fine.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to William Unruh on Tue Aug 3 00:31:12 2021
    On 08/02/21 23:45, William Unruh wrote:
    On 2021-08-02, chris<chris-nospam@tridac.net> wrote:
    On 08/02/21 18:05, David Woolley wrote:
    On 02/08/2021 17:26, chris wrote:
    If it's working properly and has been running for a few hours,
    offset against UTC should be in the microsecond range, not

    ntpd doesn't provide that information. It only provides the offset
    between the timing source and the PC's internal clock.

    Correct me if i'm wrong, but pps is traceable to UTC, so that would be
    used within ntpd to set the system clock. In the case of several

    If one wants sub-microsecond accuracy, then how it is used within ntpd becomes important. Lets assume that the gps module itself is good. The hardware inside the receiver delivers a pps pulse at the UTC second (it
    does not, it fluctuates a few 10s of nanoseconds from that). That pulse
    then travels down the cable to the computer. If the impedance matching between the receiver and the computer is not good, then that pulse gets smeared out over many travel times down the cable. At a certain voltage level, a trigger in the driver flips, and that raises and interrupt
    voltage. The hardware watches for that flip, and tells the cpu to stop (controllably) what it is doing, caches the currently running program,
    loads the interrupt driver program, and branches to that program. If
    that program is well written, it then calls a kernel subroutine, loading
    it into memory if need be, and calls a program to convert the counter,
    which is the system clock, reads out the count, and converts that count
    to a time. It then returns that time to the interrupt driver routine.
    All of that takes time. All of that takes a variable amount of time. For example, if another interrupt service routine is running ( eg due to
    disk reads) this one will wait for it to finish (in the sense of
    signalling that it is OK for it to be interrupted )



    Thanks for that detailed description. I do real time embedded
    hw and sw work here and am familiar with interrupt processing
    and priorities. Even with all the processing and assuming a
    stripped down and lightly loaded, dedicated intermediate host
    running ntpd, I would expect the processing delays to be in
    the order of a handfull of microseconds on a say an i3 or core
    2 level platform. Yes, there will be jitter, but still within
    a small margin related to that. This is born out by the
    consistent reports from the ntpq utility, once the sytem has
    settled down for a few hours.


    ntp server sources, ntpd will weed out the outliers, keep the best and
    use that to set local system time. ntpq then provides a list showing
    what it thinks are the timing relationships between them, with pps utc
    as the primary reference ?...

    No. The PPS timing is simply one amongst the lot. It may well be the
    chosen one, and its low stratum will mean that ntpd will be more likely
    to choose it. But not necessarily.


    From the results here, the pps always seesm to be the primary
    reference, once the system has settled down. That would make
    sense, since it will always be the most accurate measure
    against UTC, if it is a local source...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to Jim Pennino on Tue Aug 3 00:42:28 2021
    On 08/02/21 23:59, Jim Pennino wrote:
    William Unruh<unruh@invalid.ca> wrote:
    On 2021-08-02, Jim Pennino<jimp@gonzo.specsol.net> wrote:

    <snip old crap>

    Absolute and consistent delay is irrelevaent.

    The processes of reading the PPS edge and getting the system time are
    independent processes.

    If things were as you say, rubidium clocks would not work.

    Rubidium clocks are not general purpose computers. Their electronics are
    all specially built to reduce the errors as much as possible.
    Absolute and consistant delay is NOT irrelevant. It is part of the error
    budget that determines the accuracy of the clock. Or would you not care
    if your clock was 3 days out in its time? If not, that is fine, but most
    people would not call it accurate.

    Rubidium clocks are NOT clocks and do not tell time.

    A modern rubidium clock is a box containing a rubidium oscillator that is disciplined by an included GNSS receiver. The electronics is off the shelf chips.

    And there are no vacuum tubes in there either.

    The GNSS receiver provides the GNSS data output and the precision
    rubidium oscillator provides the PPS signal.

    Not really the full story. The rb source or vcxo is locked to
    gps 1pps, also providing the external pps signal to ntpd. The
    rb is typically used as a low phase noise frequency standard
    for external equipment such as signal generators, counters etc.
    They are not separate entities, but are intimately connected.
    Suggest swot up on gps disciplined oscillators, for more
    background on how the systems work...


    A rubidium clock has PPS jitter of around 1 nanosecond and to a computer looks like an extremely low jitter GNSS receiver.

    Most also provide an output as a frequency standard.

    You keep arm waving about "3 days", why?

    Why would you say something as blazingly obvious as "Rubidium clocks are
    not general purpose computers"?

    Are you purposely trying to be condescending?






    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Jim Pennino on Mon Aug 2 23:28:11 2021
    On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    William Unruh <unruh@invalid.ca> wrote:
    On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:

    <snip old crap>

    Absolute and consistent delay is irrelevaent.

    The processes of reading the PPS edge and getting the system time are
    independent processes.

    If things were as you say, rubidium clocks would not work.

    Rubidium clocks are not general purpose computers. Their electronics are
    all specially built to reduce the errors as much as possible.
    Absolute and consistant delay is NOT irrelevant. It is part of the error
    budget that determines the accuracy of the clock. Or would you not care
    if your clock was 3 days out in its time? If not, that is fine, but most
    people would not call it accurate.

    Rubidium clocks are NOT clocks and do not tell time.

    Neither is your computer. It also just has a crystal and a counter. You computer converts that counting to a time after calibrating that counter
    (ticks per second).


    A modern rubidium clock is a box containing a rubidium oscillator that is disciplined by an included GNSS receiver. The electronics is off the shelf chips.

    And there are no vacuum tubes in there either.

    The GNSS receiver provides the GNSS data output and the precision
    rubidium oscillator provides the PPS signal.

    A rubidium clock has PPS jitter of around 1 nanosecond and to a computer looks like an extremely low jitter GNSS receiver.

    Most also provide an output as a frequency standard.

    You keep arm waving about "3 days", why?

    As an obviously huge error which noone would regard as accurate, even if
    that offset has vary small fluctuation.


    Why would you say something as blazingly obvious as "Rubidium clocks are
    not general purpose computers"?

    Because you compared a Rubidium clock to a general purpose computer.

    Are you purposely trying to be condescending?

    Obvious perhaps, condescending no.



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to William Unruh on Mon Aug 2 16:49:15 2021
    William Unruh <unruh@invalid.ca> wrote:
    On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    William Unruh <unruh@invalid.ca> wrote:
    On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    Jim Pennino wrote:
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    David Taylor wrote:
    On 02/08/2021 14:01, Jim Pennino wrote:
    I think that is expected if you have the PPS signal connected to CTS.
    AFAIK the kernel PPS serial driver works only with DCD.

    Then that is a bug because most real devices use CTS.

    The above is simply wrong.

    OK, let me restate that.

    Most current, commercial devices not intended for the experimenter or
    hobbist market use CTS.

    FWIW, I did some research of such devices with a DB-9 connector on them. >>>>
    All the real devices I've used on Windows and multiple variants of Linux
    use DCD.

    I have to agree with David here:

    I have been a member of the NTP Hackers team for more than 25 years, and
    I have yet to see a PPS device on RS232 which doesn't use DCD.

    It is now 2021 and there have been changes.

    Not really.

    Yes, really, e.g. GNSS and relatively cheap rubidium oscillators.

    With GNSS and a $15 USB GPS, one can obtain consistent time accuracy in >>>> the single digit milliseconds these days.

    With PPS. Without PPS, even the length of the nmea sentences vary more
    than that.

    No, without PPS.

    How much the NMEA sentences vary depends on the speed of the electronics
    in the receiver and how many satellites the receiver can process.

    No. The NMEA sentences themselves are variable length. And the RS22
    standard means that the data goes up the line not very fast. Each
    character takes milliseconds to be transmitted.

    Yes, NMEA sentences themselves are variable length.

    I never said they were not.

    The jitter in NMEA sentences is the sum of the jitter due to sentence variability and the speed at which the receiver electronics can process
    all the data to create all the NMEA sentences.

    Many people have tested RS-232 speeds and have documented that speeds
    faster than 9600 baud do little to nothing for jitter. If you doubt
    that, spend some time on ntp.org and read the documentation.


    Some old USB GPS pucks have jitter at the hundred millisecond level and
    a very few at the tens of millisecond level, and what you said used to
    be true.
    It is RS232 that is the problem.

    Nope.

    RS-232 has nothing to do with USB and USB is MUCH faster than 9600 baud.


    Modern USB GNSS pucks have jitter at the millsecond level and a standard
    deviation of about 1 millisecond.

    So, in summary, CURRENT, MODERN GNSS receivers have better sensitity,
    can see and process more satellites, and have faster electronics inside
    them.

    Of course.


    How do I know this you say?

    As I have said many times before, I am doing a study of CURRENT, MODERN
    GNSS devices and how well they work with ntpd.



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to William Unruh on Mon Aug 2 17:01:46 2021
    William Unruh <unruh@invalid.ca> wrote:
    On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    William Unruh <unruh@invalid.ca> wrote:
    On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:

    <snip old crap>

    Absolute and consistent delay is irrelevaent.

    The processes of reading the PPS edge and getting the system time are
    independent processes.

    If things were as you say, rubidium clocks would not work.

    Rubidium clocks are not general purpose computers. Their electronics are >>> all specially built to reduce the errors as much as possible.
    Absolute and consistant delay is NOT irrelevant. It is part of the error >>> budget that determines the accuracy of the clock. Or would you not care
    if your clock was 3 days out in its time? If not, that is fine, but most >>> people would not call it accurate.

    Rubidium clocks are NOT clocks and do not tell time.

    Neither is your computer. It also just has a crystal and a counter. You computer converts that counting to a time after calibrating that counter (ticks per second).

    WTF???

    My computer tells time better than my wrist watch, but so what?

    A modern rubidium clock is a box containing a rubidium oscillator that is
    disciplined by an included GNSS receiver. The electronics is off the shelf >> chips.

    Didn't even bother to read this part before your WTF, knee jerk reply,
    did you?


    And there are no vacuum tubes in there either.

    The GNSS receiver provides the GNSS data output and the precision
    rubidium oscillator provides the PPS signal.

    A rubidium clock has PPS jitter of around 1 nanosecond and to a computer
    looks like an extremely low jitter GNSS receiver.

    Most also provide an output as a frequency standard.

    You keep arm waving about "3 days", why?

    As an obviously huge error which noone would regard as accurate, even if
    that offset has vary small fluctuation.

    And obviously just arm waving.


    Why would you say something as blazingly obvious as "Rubidium clocks are
    not general purpose computers"?

    Because you compared a Rubidium clock to a general purpose computer.

    No, I did not.

    That would be blazingly asinine and I utterly fail to see how you could
    ever come to such a conclusion.


    Are you purposely trying to be condescending?

    Obvious perhaps, condescending no.


    More like oblivious to whatever I say.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Mon Aug 2 17:13:38 2021
    chris <chris-nospam@tridac.net> wrote:
    On 08/02/21 23:59, Jim Pennino wrote:
    William Unruh<unruh@invalid.ca> wrote:
    On 2021-08-02, Jim Pennino<jimp@gonzo.specsol.net> wrote:

    <snip old crap>

    Absolute and consistent delay is irrelevaent.

    The processes of reading the PPS edge and getting the system time are
    independent processes.

    If things were as you say, rubidium clocks would not work.

    Rubidium clocks are not general purpose computers. Their electronics are >>> all specially built to reduce the errors as much as possible.
    Absolute and consistant delay is NOT irrelevant. It is part of the error >>> budget that determines the accuracy of the clock. Or would you not care
    if your clock was 3 days out in its time? If not, that is fine, but most >>> people would not call it accurate.

    Rubidium clocks are NOT clocks and do not tell time.

    A modern rubidium clock is a box containing a rubidium oscillator that is
    disciplined by an included GNSS receiver. The electronics is off the shelf >> chips.

    And there are no vacuum tubes in there either.

    The GNSS receiver provides the GNSS data output and the precision
    rubidium oscillator provides the PPS signal.

    Not really the full story. The rb source or vcxo is locked to
    gps 1pps, also providing the external pps signal to ntpd. The
    rb is typically used as a low phase noise frequency standard
    for external equipment such as signal generators, counters etc.
    They are not separate entities, but are intimately connected.
    Suggest swot up on gps disciplined oscillators, for more
    background on how the systems work...

    Sigh, you are just sort of parroting the definition of a disciplined clock which these days go by the name GNSSDO with a qualifier of either OCXO
    or rubidium.

    Also, VCXO means voltage controlled crystal oscillator, and rubidium
    clocks are neither voltage controlled these days or crystals.

    In a modern GNSSDO, there is a GNSS receiver consisting of a chip set,
    a rubidium oscillator and some off the shelf chips to discipline the
    oscillator and provide I/O for the system.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Miroslav Lichvar@21:1/5 to Jim Pennino on Tue Aug 3 07:52:13 2021
    On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    That is, if one has an absolutely accurate PPS signal that is exactly
    1Hz, it doesn't matter how long, within reason, it takes to process the
    PPS signal. What matters is how much jitter the hardware and software
    has in processing the signal. Since the jitter in modern digital
    electronic is in the picosecond, that is not a factor. That means the determining factor will be the jitter in the interrupt handling.

    Which with 1 Ghz+ multiple core CPUs is hopefully in the low
    nanoseconds.

    No, a typical jitter of the interrupt-based PPS timestamping on a
    computer serial port is around 1 microsecond and there is a delay of at
    least few microseconds. If you didn't disable the CPU power-saving
    features, the delay can easily get to tens of microseconds and a large
    offset can be observed when the CPU is loaded on and off.

    It does not matter if your PPS signal is stable to 1 or 50 nanoseconds.
    It makes no difference in that noise. A $10 GPS from ebay would likely
    perform the same as long as it can get a good signal.

    If you were serious about accuracy and stability, you wouldn't be
    connecting PPS to a serial port. You need something that has hardware timestamping, like a networking card (e.g. the I210). That would get you
    to the low nanosecond range, at least for the hardware clock.

    Synchronization of the system clock to the hardware clock is the weakest
    link of the chain. It is typically accurate only to few hundreds of nanoseconds. The problem is large and asymmetric latency of the PCIe
    bus, which cannot be easily measured and compensated. Still, that's at
    least an order of magnitude better that the serial port.

    A new feature that some NICs have is PTM, which is basically a hardware implementation of NTP on PCIe. It should improve the accuracy
    significantly. I have not had a chance to play with it yet.

    --
    Miroslav Lichvar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Woolley@21:1/5 to Jim Pennino on Tue Aug 3 11:24:47 2021
    On 03/08/2021 00:37, Jim Pennino wrote:
    PPS has no information. The purpose of PPS is to provide a reference
    that is as close to 1 Hz, i.e. an elapsed time of 1 second, as possible.


    PPS provides information on where within the cycle the true UTC second transition most probably lies. You pretty much acknowledge that later
    in your description.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Woolley@21:1/5 to chris on Tue Aug 3 11:49:59 2021
    On 02/08/2021 23:25, chris wrote:

    Correct me if i'm wrong, but pps is traceable to UTC

    Pedantically, only with hindsight, as UTC is determined by
    retrospectively comparing many clocks, and the corrections are only
    published monthly.

    It is also subject to being obtained from a source which is itself
    traceable, typically a satellite navigation receiver which has a clear
    view of the whole sky, working with a built in antenna, and not subject
    to a jamming or spoofing attack. Having atmospheric conditions that
    match the the model use also helps.

    ntpd will lock onto a 1pps signal from a free running clock.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Woolley@21:1/5 to Jim Pennino on Tue Aug 3 11:58:39 2021
    On 03/08/2021 01:13, Jim Pennino wrote:

    And there are no vacuum tubes in there either.

    I'm sure the reference to vacuum tubes was rhetorical, as I don't think
    GPS was started until well into the solid state age.

    However, some quick research on how rubidium clocks work suggests that a
    vacuum tube would be a good description of the rubidium containing part
    of the system, as they are low pressure discharge lamps. They have to
    be low pressure to prevent atoms interacting with each other.

    Also rubidium oscillator is something of a misnomer, as they are really rubidium controlled crystal oscillators.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to David Woolley on Tue Aug 3 07:15:28 2021
    David Woolley <david@ex.djwhome.demon.invalid> wrote:
    On 03/08/2021 00:37, Jim Pennino wrote:
    PPS has no information. The purpose of PPS is to provide a reference
    that is as close to 1 Hz, i.e. an elapsed time of 1 second, as possible.


    PPS provides information on where within the cycle the true UTC second transition most probably lies. You pretty much acknowledge that later
    in your description.

    Nope.

    In fact if one were to build a highly stable oscillator totally
    independent of GPS, it would still work as a PPS signal.

    If you think otherwise, please provide the GPS specification.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to David Woolley on Tue Aug 3 07:08:27 2021
    David Woolley <david@ex.djwhome.demon.invalid> wrote:
    On 03/08/2021 01:13, Jim Pennino wrote:

    And there are no vacuum tubes in there either.

    I'm sure the reference to vacuum tubes was rhetorical, as I don't think
    GPS was started until well into the solid state age.

    The first GPS receiver was built in 1977 and vacuum tube equipment was
    still quite common.

    It sat on the roof of the Rockwell Collins building waiting for the
    first GPS satellite to be turned on and was manned by Rockwell
    engineers.

    It was in a 6 foot tall rack with 2 seats for operator(s).

    They did not build it from component parts unless there was some part
    that did not exist, ergo any module such as a RF receiver, RF amplfier,
    signal amplifier, etc. was likely full of tubes of some sort.

    However, some quick research on how rubidium clocks work suggests that a vacuum tube would be a good description of the rubidium containing part
    of the system, as they are low pressure discharge lamps. They have to
    be low pressure to prevent atoms interacting with each other.

    So do incandescent light bulbs.

    Also rubidium oscillator is something of a misnomer, as they are really rubidium controlled crystal oscillators.

    Sing it to the heavens above and see how it plays.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to Miroslav Lichvar on Tue Aug 3 07:22:45 2021
    Miroslav Lichvar <mlichvar@redhat.com> wrote:
    On 2021-08-02, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    That is, if one has an absolutely accurate PPS signal that is exactly
    1Hz, it doesn't matter how long, within reason, it takes to process the
    PPS signal. What matters is how much jitter the hardware and software
    has in processing the signal. Since the jitter in modern digital
    electronic is in the picosecond, that is not a factor. That means the
    determining factor will be the jitter in the interrupt handling.

    Which with 1 Ghz+ multiple core CPUs is hopefully in the low
    nanoseconds.

    No, a typical jitter of the interrupt-based PPS timestamping on a
    computer serial port is around 1 microsecond and there is a delay of at
    least few microseconds. If you didn't disable the CPU power-saving
    features, the delay can easily get to tens of microseconds and a large
    offset can be observed when the CPU is loaded on and off.

    That has not been my experience.

    It does not matter if your PPS signal is stable to 1 or 50 nanoseconds.
    It makes no difference in that noise. A $10 GPS from ebay would likely perform the same as long as it can get a good signal.

    The cheapest, current, commercial GPS with a serial connector and PPS
    that I can find is over $100.

    If you were serious about accuracy and stability, you wouldn't be
    connecting PPS to a serial port. You need something that has hardware timestamping, like a networking card (e.g. the I210). That would get you
    to the low nanosecond range, at least for the hardware clock.

    I never said anything about being serious.

    I said I was researching the utility of cheap devices to drive ntpd.

    Synchronization of the system clock to the hardware clock is the weakest
    link of the chain. It is typically accurate only to few hundreds of nanoseconds. The problem is large and asymmetric latency of the PCIe
    bus, which cannot be easily measured and compensated. Still, that's at
    least an order of magnitude better that the serial port.

    A new feature that some NICs have is PTM, which is basically a hardware implementation of NTP on PCIe. It should improve the accuracy
    significantly. I have not had a chance to play with it yet.

    We shall see...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to Jim Pennino on Tue Aug 3 16:11:04 2021
    On 08/03/21 15:22, Jim Pennino wrote:


    The cheapest, current, commercial GPS with a serial connector and PPS
    that I can find is over $100.


    Then you are not looking very hard. Bare board gps modules,
    with pps and serial are on Ebay in droves at around the
    < $10 upwards. Of course, if you are not happy doing a bit
    of simple soldering and interfacing, then you are at the
    mercy of those that can...

    Usb is the last thing anyone would use if accuracy is the goal.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Tue Aug 3 08:28:11 2021
    chris <chris-nospam@tridac.net> wrote:
    On 08/03/21 15:22, Jim Pennino wrote:


    The cheapest, current, commercial GPS with a serial connector and PPS
    that I can find is over $100.


    Then you are not looking very hard. Bare board gps modules,
    with pps and serial are on Ebay in droves at around the
    < $10 upwards. Of course, if you are not happy doing a bit
    of simple soldering and interfacing, then you are at the
    mercy of those that can...

    What part of the words "commercial" and "serial connector" is it that
    you did not understand?

    FYI I have been soldering since about 1963.

    Usb is the last thing anyone would use if accuracy is the goal.

    That depends on the accuracy required.

    As I said, there are thousands of people who have no serial or parallel
    port that have a required accuracy of about 100 milliseconds.

    For them, USB would be the FIRST thing they would use as it is the
    cheapest and simplest solution and easily meets the requirement.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to Jim Pennino on Tue Aug 3 16:15:30 2021
    On 08/03/21 15:15, Jim Pennino wrote:
    David Woolley<david@ex.djwhome.demon.invalid> wrote:
    On 03/08/2021 00:37, Jim Pennino wrote:
    PPS has no information. The purpose of PPS is to provide a reference
    that is as close to 1 Hz, i.e. an elapsed time of 1 second, as possible. >>>

    PPS provides information on where within the cycle the true UTC second
    transition most probably lies. You pretty much acknowledge that later
    in your description.

    Nope.

    In fact if one were to build a highly stable oscillator totally
    independent of GPS, it would still work as a PPS signal.

    If you think otherwise, please provide the GPS specification.


    It may generate a pps signal if divided down, but it would not
    be synchronised to UTC or anything else. Only a gps 1 pps
    can provide that signal, or another clock locked to UTC.

    I should stop digging mate, ever more ridiculous...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Tue Aug 3 08:22:22 2021
    chris <chris-nospam@tridac.net> wrote:
    On 08/03/21 15:15, Jim Pennino wrote:
    David Woolley<david@ex.djwhome.demon.invalid> wrote:
    On 03/08/2021 00:37, Jim Pennino wrote:
    PPS has no information. The purpose of PPS is to provide a reference
    that is as close to 1 Hz, i.e. an elapsed time of 1 second, as possible. >>>>

    PPS provides information on where within the cycle the true UTC second
    transition most probably lies. You pretty much acknowledge that later
    in your description.

    Nope.

    In fact if one were to build a highly stable oscillator totally
    independent of GPS, it would still work as a PPS signal.

    If you think otherwise, please provide the GPS specification.


    It may generate a pps signal if divided down, but it would not
    be synchronised to UTC or anything else. Only a gps 1 pps
    can provide that signal, or another clock locked to UTC.

    I should stop digging mate, ever more ridiculous...

    Please provide the GPS specification that defines the PPS sync to UTC.

    If you can not, you are just pulling this from your butt.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to Jim Pennino on Tue Aug 3 16:52:13 2021
    On 08/03/21 16:28, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 15:22, Jim Pennino wrote:


    The cheapest, current, commercial GPS with a serial connector and PPS
    that I can find is over $100.


    Then you are not looking very hard. Bare board gps modules,
    with pps and serial are on Ebay in droves at around the
    < $10 upwards. Of course, if you are not happy doing a bit
    of simple soldering and interfacing, then you are at the
    mercy of those that can...

    What part of the words "commercial" and "serial connector" is it that
    you did not understand?

    FYI I have been soldering since about 1963.

    Then you should have no problem taking a $10- gps module, soldering a
    few wires to it and a 9 pin D and you are good to go.


    Usb is the last thing anyone would use if accuracy is the goal.

    That depends on the accuracy required.

    As I said, there are thousands of people who have no serial or parallel
    port that have a required accuracy of about 100 milliseconds.

    They do ?, who are these thousands of people ?...


    For them, USB would be the FIRST thing they would use as it is the
    cheapest and simplest solution and easily meets the requirement.








    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to Jim Pennino on Tue Aug 3 17:09:26 2021
    On 08/03/21 16:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 15:15, Jim Pennino wrote:
    David Woolley<david@ex.djwhome.demon.invalid> wrote:
    On 03/08/2021 00:37, Jim Pennino wrote:
    PPS has no information. The purpose of PPS is to provide a reference >>>>> that is as close to 1 Hz, i.e. an elapsed time of 1 second, as possible. >>>>>

    PPS provides information on where within the cycle the true UTC second >>>> transition most probably lies. You pretty much acknowledge that later >>>> in your description.

    Nope.

    In fact if one were to build a highly stable oscillator totally
    independent of GPS, it would still work as a PPS signal.

    If you think otherwise, please provide the GPS specification.


    It may generate a pps signal if divided down, but it would not
    be synchronised to UTC or anything else. Only a gps 1 pps
    can provide that signal, or another clock locked to UTC.

    I should stop digging mate, ever more ridiculous...

    Please provide the GPS specification that defines the PPS sync to UTC.

    Typical gps modules will claim a few 10's of ns offset limits
    for local pps in relation to UTC, which is the final arbiter.
    GPS have clocks traceable to national standards and UTC. They
    are the primary reference, to which any local clocks or
    oscillators, vcxo or rb, etc will be locked in sync with.

    If you need any more info, download the data sheet for a
    typical sub $10 gps module, which should have all the info
    you need...


    If you can not, you are just pulling this from your butt.



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Tue Aug 3 09:18:34 2021
    chris <chris-nospam@tridac.net> wrote:
    On 08/03/21 16:28, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 15:22, Jim Pennino wrote:


    The cheapest, current, commercial GPS with a serial connector and PPS
    that I can find is over $100.


    Then you are not looking very hard. Bare board gps modules,
    with pps and serial are on Ebay in droves at around the
    < $10 upwards. Of course, if you are not happy doing a bit
    of simple soldering and interfacing, then you are at the
    mercy of those that can...

    What part of the words "commercial" and "serial connector" is it that
    you did not understand?

    FYI I have been soldering since about 1963.

    Then you should have no problem taking a $10- gps module, soldering a
    few wires to it and a 9 pin D and you are good to go.

    There are no $10 modules with RS-232 outputs.

    Do you understand the difference between serial output and RS-232?

    Usb is the last thing anyone would use if accuracy is the goal.

    That depends on the accuracy required.

    As I said, there are thousands of people who have no serial or parallel
    port that have a required accuracy of about 100 milliseconds.

    They do ?, who are these thousands of people ?...

    Probably the biggest group is amateur radio operators running any of the
    modern modes such as FST4, FST4W, FT4, FT8, JT4, JT9, JT65, Q65, MSK144,
    and WSPR, which is the majority of the about 3 million world wide.

    They also have the issue of operating from a remote location with no
    internet or cell access.

    This is typically done with a Windows laptop that has no device I/O other
    than USB.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Tue Aug 3 09:34:00 2021
    chris <chris-nospam@tridac.net> wrote:
    On 08/03/21 16:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 15:15, Jim Pennino wrote:
    David Woolley<david@ex.djwhome.demon.invalid> wrote:
    On 03/08/2021 00:37, Jim Pennino wrote:
    PPS has no information. The purpose of PPS is to provide a reference >>>>>> that is as close to 1 Hz, i.e. an elapsed time of 1 second, as possible. >>>>>>

    PPS provides information on where within the cycle the true UTC second >>>>> transition most probably lies. You pretty much acknowledge that later >>>>> in your description.

    Nope.

    In fact if one were to build a highly stable oscillator totally
    independent of GPS, it would still work as a PPS signal.

    If you think otherwise, please provide the GPS specification.


    It may generate a pps signal if divided down, but it would not
    be synchronised to UTC or anything else. Only a gps 1 pps
    can provide that signal, or another clock locked to UTC.

    I should stop digging mate, ever more ridiculous...

    Please provide the GPS specification that defines the PPS sync to UTC.

    Typical gps modules will claim a few 10's of ns offset limits
    for local pps in relation to UTC, which is the final arbiter.
    GPS have clocks traceable to national standards and UTC. They
    are the primary reference, to which any local clocks or
    oscillators, vcxo or rb, etc will be locked in sync with.

    If you need any more info, download the data sheet for a
    typical sub $10 gps module, which should have all the info
    you need...

    I did not ask for spec sheets for GPS modules.

    Please provide the GPS specification that defines the PPS sync to UTC.

    You claim PPS is synced to UTC.

    Prove it.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to Jim Pennino on Tue Aug 3 17:55:03 2021
    On 08/03/21 17:18, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 16:28, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 15:22, Jim Pennino wrote:


    The cheapest, current, commercial GPS with a serial connector and PPS >>>>> that I can find is over $100.


    Then you are not looking very hard. Bare board gps modules,
    with pps and serial are on Ebay in droves at around the
    < $10 upwards. Of course, if you are not happy doing a bit
    of simple soldering and interfacing, then you are at the
    mercy of those that can...

    What part of the words "commercial" and "serial connector" is it that
    you did not understand?

    FYI I have been soldering since about 1963.

    Then you should have no problem taking a $10- gps module, soldering a
    few wires to it and a 9 pin D and you are good to go.

    There are no $10 modules with RS-232 outputs.

    Do you understand the difference between serial output and RS-232?

    We already had that discussion, where you seemed unaware of the
    need or not for level conversion. Sure, the gps module will have
    serial output and pps at ttl levels. 2400 or 4800 baud ascii
    format being typical.


    Usb is the last thing anyone would use if accuracy is the goal.

    That depends on the accuracy required.

    As I said, there are thousands of people who have no serial or parallel
    port that have a required accuracy of about 100 milliseconds.

    They do ?, who are these thousands of people ?...

    Probably the biggest group is amateur radio operators running any of the modern modes such as FST4, FST4W, FT4, FT8, JT4, JT9, JT65, Q65, MSK144,
    and WSPR, which is the majority of the about 3 million world wide.

    They also have the issue of operating from a remote location with no
    internet or cell access.

    This is typically done with a Windows laptop that has no device I/O other than USB.

    Fair comment, but I would try to find a more accurate solution than
    using a usb interface. Bluetooth gps engines are quite popular now
    fwics, and not expensive either...





    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to Jim Pennino on Tue Aug 3 18:09:37 2021
    On 08/03/21 17:34, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 16:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 15:15, Jim Pennino wrote:
    David Woolley<david@ex.djwhome.demon.invalid> wrote:
    On 03/08/2021 00:37, Jim Pennino wrote:
    PPS has no information. The purpose of PPS is to provide a reference >>>>>>> that is as close to 1 Hz, i.e. an elapsed time of 1 second, as possible.


    PPS provides information on where within the cycle the true UTC second >>>>>> transition most probably lies. You pretty much acknowledge that later >>>>>> in your description.

    Nope.

    In fact if one were to build a highly stable oscillator totally
    independent of GPS, it would still work as a PPS signal.

    If you think otherwise, please provide the GPS specification.


    It may generate a pps signal if divided down, but it would not
    be synchronised to UTC or anything else. Only a gps 1 pps
    can provide that signal, or another clock locked to UTC.

    I should stop digging mate, ever more ridiculous...

    Please provide the GPS specification that defines the PPS sync to UTC.

    Typical gps modules will claim a few 10's of ns offset limits
    for local pps in relation to UTC, which is the final arbiter.
    GPS have clocks traceable to national standards and UTC. They
    are the primary reference, to which any local clocks or
    oscillators, vcxo or rb, etc will be locked in sync with.

    If you need any more info, download the data sheet for a
    typical sub $10 gps module, which should have all the info
    you need...

    I did not ask for spec sheets for GPS modules.

    Please provide the GPS specification that defines the PPS sync to UTC.

    You claim PPS is synced to UTC.

    Prove it.


    Millions of people depend on it every day, so we know it works. PPS
    sync is directly traceable to the satellite master clocks and thence
    to utc maintenance at the national standards labs worldwide. Yes Jim,
    it's major worldwide collaboration, with everything from GSM mobile, broadcasting, industry,. medicine and more depending on it. ...and you
    have doubts ?.

    Not a specialist in the subject, so you'll have to do your own
    homework on that one. It's all in the public domain as well, so no
    excuses, right :-)...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Tue Aug 3 10:22:14 2021
    chris <chris-nospam@tridac.net> wrote:
    On 08/03/21 17:34, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 16:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 15:15, Jim Pennino wrote:
    David Woolley<david@ex.djwhome.demon.invalid> wrote:
    On 03/08/2021 00:37, Jim Pennino wrote:
    PPS has no information. The purpose of PPS is to provide a reference >>>>>>>> that is as close to 1 Hz, i.e. an elapsed time of 1 second, as possible.


    PPS provides information on where within the cycle the true UTC second >>>>>>> transition most probably lies. You pretty much acknowledge that later >>>>>>> in your description.

    Nope.

    In fact if one were to build a highly stable oscillator totally
    independent of GPS, it would still work as a PPS signal.

    If you think otherwise, please provide the GPS specification.


    It may generate a pps signal if divided down, but it would not
    be synchronised to UTC or anything else. Only a gps 1 pps
    can provide that signal, or another clock locked to UTC.

    I should stop digging mate, ever more ridiculous...

    Please provide the GPS specification that defines the PPS sync to UTC.

    Typical gps modules will claim a few 10's of ns offset limits
    for local pps in relation to UTC, which is the final arbiter.
    GPS have clocks traceable to national standards and UTC. They
    are the primary reference, to which any local clocks or
    oscillators, vcxo or rb, etc will be locked in sync with.

    If you need any more info, download the data sheet for a
    typical sub $10 gps module, which should have all the info
    you need...

    I did not ask for spec sheets for GPS modules.

    Please provide the GPS specification that defines the PPS sync to UTC.

    You claim PPS is synced to UTC.

    Prove it.


    Millions of people depend on it every day, so we know it works. PPS
    sync is directly traceable to the satellite master clocks and thence
    to utc maintenance at the national standards labs worldwide. Yes Jim,
    it's major worldwide collaboration, with everything from GSM mobile, broadcasting, industry,. medicine and more depending on it. ...and you
    have doubts ?.

    You claim the PPS pulse is synced to UTC.

    I say it is not.

    Prove your statement with a link to a GPS specification, not arm waving.

    Not a specialist in the subject,

    To say the least...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Woolley@21:1/5 to Jim Pennino on Tue Aug 3 18:38:01 2021
    On 03/08/2021 17:34, Jim Pennino wrote:
    Please provide the GPS specification that defines the PPS sync to UTC.


    I can't think of any good reason why the GPS specification should even
    mention PPS.

    Although there may be specialist equipment that only provides a 1Hz
    frequency standard (although I'd think 10MHz more likely), I think we
    would have seen lots of people reporting problems if real world PPS
    outputs weren't aligned with GPS seconds.

    As for a typical product specification, the Garmin 18x LVC series has
    this specification:

    "The highly accurate one-pulse-per-second (PPS) output is provided for applications requiring precise timing measurements. After the initial
    position fix has been calculated, the PPS signal is generated and
    continues until the unit is powered down. The rising edge of the signal
    is aligned to the start of each GPS second within 1 μs for all
    conditions in which the receiver has reported a valid and accurate
    position for at least the previous 4 seconds."

    <https://static.garmin.com/pumac/GPS_18x_Tech_Specs.pdf>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to Jim Pennino on Tue Aug 3 18:41:25 2021
    On 08/03/21 18:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 17:34, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 16:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 15:15, Jim Pennino wrote:
    David Woolley<david@ex.djwhome.demon.invalid> wrote:
    On 03/08/2021 00:37, Jim Pennino wrote:
    PPS has no information. The purpose of PPS is to provide a reference >>>>>>>>> that is as close to 1 Hz, i.e. an elapsed time of 1 second, as possible.


    PPS provides information on where within the cycle the true UTC second >>>>>>>> transition most probably lies. You pretty much acknowledge that later >>>>>>>> in your description.

    Nope.

    In fact if one were to build a highly stable oscillator totally
    independent of GPS, it would still work as a PPS signal.

    If you think otherwise, please provide the GPS specification.


    It may generate a pps signal if divided down, but it would not
    be synchronised to UTC or anything else. Only a gps 1 pps
    can provide that signal, or another clock locked to UTC.

    I should stop digging mate, ever more ridiculous...

    Please provide the GPS specification that defines the PPS sync to UTC. >>>>
    Typical gps modules will claim a few 10's of ns offset limits
    for local pps in relation to UTC, which is the final arbiter.
    GPS have clocks traceable to national standards and UTC. They
    are the primary reference, to which any local clocks or
    oscillators, vcxo or rb, etc will be locked in sync with.

    If you need any more info, download the data sheet for a
    typical sub $10 gps module, which should have all the info
    you need...

    I did not ask for spec sheets for GPS modules.

    Please provide the GPS specification that defines the PPS sync to UTC.

    You claim PPS is synced to UTC.

    Prove it.


    Millions of people depend on it every day, so we know it works. PPS
    sync is directly traceable to the satellite master clocks and thence
    to utc maintenance at the national standards labs worldwide. Yes Jim,
    it's major worldwide collaboration, with everything from GSM mobile,
    broadcasting, industry,. medicine and more depending on it. ...and you
    have doubts ?.

    You claim the PPS pulse is synced to UTC.

    I say it is not.

    Prove your statement with a link to a GPS specification, not arm waving.

    Not a specialist in the subject,

    To say the least...



    You really are beyond help, but how do you think gsm cell handover, or
    high frequency stock trading works ?. Are you even curious about how
    things like that work and make some effort to find out ?.

    The thing about gps time and pps is that you can have a gps rx in London
    and one on NY and both pps will be in sync to within 10's
    of nS typically. How amazing is that ?. nS accuracy just about
    anywhere on the planet where you can see satellites.

    Do your own homework and stop being so lazy :-)...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Tue Aug 3 10:34:30 2021
    chris <chris-nospam@tridac.net> wrote:
    On 08/03/21 17:18, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 16:28, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 15:22, Jim Pennino wrote:


    The cheapest, current, commercial GPS with a serial connector and PPS >>>>>> that I can find is over $100.


    Then you are not looking very hard. Bare board gps modules,
    with pps and serial are on Ebay in droves at around the
    < $10 upwards. Of course, if you are not happy doing a bit
    of simple soldering and interfacing, then you are at the
    mercy of those that can...

    What part of the words "commercial" and "serial connector" is it that
    you did not understand?

    FYI I have been soldering since about 1963.

    Then you should have no problem taking a $10- gps module, soldering a
    few wires to it and a 9 pin D and you are good to go.

    There are no $10 modules with RS-232 outputs.

    Do you understand the difference between serial output and RS-232?

    We already had that discussion, where you seemed unaware of the
    need or not for level conversion. Sure, the gps module will have
    serial output and pps at ttl levels. 2400 or 4800 baud ascii
    format being typical.

    Sigh.

    I was NEVER unaware of the need or not for level conversion for anything.

    Some GPS modules have TTL output, but most have CMOS levels these days.

    4800 and 9600 are the most common bauds.

    GNSS modules are all at least 9600 because a GNSS receiver has more NMEA sentences and they will not fit into one second window at 4800 baud.


    Usb is the last thing anyone would use if accuracy is the goal.

    That depends on the accuracy required.

    As I said, there are thousands of people who have no serial or parallel >>>> port that have a required accuracy of about 100 milliseconds.

    They do ?, who are these thousands of people ?...

    Probably the biggest group is amateur radio operators running any of the
    modern modes such as FST4, FST4W, FT4, FT8, JT4, JT9, JT65, Q65, MSK144,
    and WSPR, which is the majority of the about 3 million world wide.

    They also have the issue of operating from a remote location with no
    internet or cell access.

    This is typically done with a Windows laptop that has no device I/O other
    than USB.

    Fair comment, but I would try to find a more accurate solution than
    using a usb interface. Bluetooth gps engines are quite popular now
    fwics, and not expensive either...

    Sigh.

    Bluetooth has no quality that would make it more accurate than USB for timekeeping applications.

    COMMERCIAL bluetooth GPS receivers are more expensive than USB.

    Why do you continually babble about DIY projects when I have repeatedly
    said I have no interest in them?

    Why would you "try to find a more accurate solution" when the solution
    offered is two orders of magnitude better than the requirement?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Tue Aug 3 10:57:24 2021
    chris <chris-nospam@tridac.net> wrote:
    On 08/03/21 18:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 17:34, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 16:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 15:15, Jim Pennino wrote:
    David Woolley<david@ex.djwhome.demon.invalid> wrote:
    On 03/08/2021 00:37, Jim Pennino wrote:
    PPS has no information. The purpose of PPS is to provide a reference >>>>>>>>>> that is as close to 1 Hz, i.e. an elapsed time of 1 second, as possible.


    PPS provides information on where within the cycle the true UTC second
    transition most probably lies. You pretty much acknowledge that later
    in your description.

    Nope.

    In fact if one were to build a highly stable oscillator totally >>>>>>>> independent of GPS, it would still work as a PPS signal.

    If you think otherwise, please provide the GPS specification.


    It may generate a pps signal if divided down, but it would not
    be synchronised to UTC or anything else. Only a gps 1 pps
    can provide that signal, or another clock locked to UTC.

    I should stop digging mate, ever more ridiculous...

    Please provide the GPS specification that defines the PPS sync to UTC. >>>>>
    Typical gps modules will claim a few 10's of ns offset limits
    for local pps in relation to UTC, which is the final arbiter.
    GPS have clocks traceable to national standards and UTC. They
    are the primary reference, to which any local clocks or
    oscillators, vcxo or rb, etc will be locked in sync with.

    If you need any more info, download the data sheet for a
    typical sub $10 gps module, which should have all the info
    you need...

    I did not ask for spec sheets for GPS modules.

    Please provide the GPS specification that defines the PPS sync to UTC. >>>>
    You claim PPS is synced to UTC.

    Prove it.


    Millions of people depend on it every day, so we know it works. PPS
    sync is directly traceable to the satellite master clocks and thence
    to utc maintenance at the national standards labs worldwide. Yes Jim,
    it's major worldwide collaboration, with everything from GSM mobile,
    broadcasting, industry,. medicine and more depending on it. ...and you
    have doubts ?.

    You claim the PPS pulse is synced to UTC.

    I say it is not.

    Prove your statement with a link to a GPS specification, not arm waving.

    Not a specialist in the subject,

    To say the least...



    You really are beyond help, but how do you think gsm cell handover, or
    high frequency stock trading works ?. Are you even curious about how
    things like that work and make some effort to find out ?.

    The thing about gps time and pps is that you can have a gps rx in London
    and one on NY and both pps will be in sync to within 10's
    of nS typically. How amazing is that ?. nS accuracy just about
    anywhere on the planet where you can see satellites.

    Do your own homework and stop being so lazy :-)...

    Yet again, nothing but arm waving.

    You have claimed the GPS PPS pulse is synced to UTC.

    I say it is not and the GPS PPS pulse is only specified as an interval.

    Prove your statement with a link to a GPS specification, not arm waving.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to Jim Pennino on Tue Aug 3 19:00:21 2021
    On 08/03/21 18:34, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 17:18, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 16:28, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 15:22, Jim Pennino wrote:


    The cheapest, current, commercial GPS with a serial connector and PPS >>>>>>> that I can find is over $100.


    Then you are not looking very hard. Bare board gps modules,
    with pps and serial are on Ebay in droves at around the
    < $10 upwards. Of course, if you are not happy doing a bit
    of simple soldering and interfacing, then you are at the
    mercy of those that can...

    What part of the words "commercial" and "serial connector" is it that >>>>> you did not understand?

    FYI I have been soldering since about 1963.

    Then you should have no problem taking a $10- gps module, soldering a
    few wires to it and a 9 pin D and you are good to go.

    There are no $10 modules with RS-232 outputs.

    Do you understand the difference between serial output and RS-232?

    We already had that discussion, where you seemed unaware of the
    need or not for level conversion. Sure, the gps module will have
    serial output and pps at ttl levels. 2400 or 4800 baud ascii
    format being typical.

    Sigh.

    I was NEVER unaware of the need or not for level conversion for anything.

    Some GPS modules have TTL output, but most have CMOS levels these days.

    4800 and 9600 are the most common bauds.

    GNSS modules are all at least 9600 because a GNSS receiver has more NMEA sentences and they will not fit into one second window at 4800 baud.


    Usb is the last thing anyone would use if accuracy is the goal.

    That depends on the accuracy required.

    As I said, there are thousands of people who have no serial or parallel >>>>> port that have a required accuracy of about 100 milliseconds.

    They do ?, who are these thousands of people ?...

    Probably the biggest group is amateur radio operators running any of the >>> modern modes such as FST4, FST4W, FT4, FT8, JT4, JT9, JT65, Q65, MSK144, >>> and WSPR, which is the majority of the about 3 million world wide.

    They also have the issue of operating from a remote location with no
    internet or cell access.

    This is typically done with a Windows laptop that has no device I/O other >>> than USB.

    Fair comment, but I would try to find a more accurate solution than
    using a usb interface. Bluetooth gps engines are quite popular now
    fwics, and not expensive either...

    Sigh.

    Bluetooth has no quality that would make it more accurate than USB for timekeeping applications.

    COMMERCIAL bluetooth GPS receivers are more expensive than USB.

    Why do you continually babble about DIY projects when I have repeatedly
    said I have no interest in them?

    Why would you "try to find a more accurate solution" when the solution offered is two orders of magnitude better than the requirement?



    Which beg the question, why are you here if you already have
    all the answers ?. T learn perhaps, as you seem to have no understanding
    of the relationship between utc and pps, even to
    the point of denying there is one ?...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to Jim Pennino on Tue Aug 3 19:08:42 2021
    On 08/03/21 18:57, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 18:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 17:34, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 16:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 15:15, Jim Pennino wrote:
    David Woolley<david@ex.djwhome.demon.invalid> wrote:
    On 03/08/2021 00:37, Jim Pennino wrote:
    PPS has no information. The purpose of PPS is to provide a reference
    that is as close to 1 Hz, i.e. an elapsed time of 1 second, as possible.


    PPS provides information on where within the cycle the true UTC second
    transition most probably lies. You pretty much acknowledge that later
    in your description.

    Nope.

    In fact if one were to build a highly stable oscillator totally >>>>>>>>> independent of GPS, it would still work as a PPS signal.

    If you think otherwise, please provide the GPS specification. >>>>>>>>>

    It may generate a pps signal if divided down, but it would not >>>>>>>> be synchronised to UTC or anything else. Only a gps 1 pps
    can provide that signal, or another clock locked to UTC.

    I should stop digging mate, ever more ridiculous...

    Please provide the GPS specification that defines the PPS sync to UTC. >>>>>>
    Typical gps modules will claim a few 10's of ns offset limits
    for local pps in relation to UTC, which is the final arbiter.
    GPS have clocks traceable to national standards and UTC. They
    are the primary reference, to which any local clocks or
    oscillators, vcxo or rb, etc will be locked in sync with.

    If you need any more info, download the data sheet for a
    typical sub $10 gps module, which should have all the info
    you need...

    I did not ask for spec sheets for GPS modules.

    Please provide the GPS specification that defines the PPS sync to UTC. >>>>>
    You claim PPS is synced to UTC.

    Prove it.


    Millions of people depend on it every day, so we know it works. PPS
    sync is directly traceable to the satellite master clocks and thence
    to utc maintenance at the national standards labs worldwide. Yes Jim,
    it's major worldwide collaboration, with everything from GSM mobile,
    broadcasting, industry,. medicine and more depending on it. ...and you >>>> have doubts ?.

    You claim the PPS pulse is synced to UTC.

    I say it is not.

    Prove your statement with a link to a GPS specification, not arm waving. >>>
    Not a specialist in the subject,

    To say the least...



    You really are beyond help, but how do you think gsm cell handover, or
    high frequency stock trading works ?. Are you even curious about how
    things like that work and make some effort to find out ?.

    The thing about gps time and pps is that you can have a gps rx in London
    and one on NY and both pps will be in sync to within 10's
    of nS typically. How amazing is that ?. nS accuracy just about
    anywhere on the planet where you can see satellites.

    Do your own homework and stop being so lazy :-)...

    Yet again, nothing but arm waving.

    You have claimed the GPS PPS pulse is synced to UTC.

    I say it is not and the GPS PPS pulse is only specified as an interval.

    Prove your statement with a link to a GPS specification, not arm waving.


    Rofl, i'm quite happy to accept that pps is deterministically
    related to UTC, nS offset and all, but you believe what you like.
    Millions of users worldwide would disagree with you, but hey,
    perhaps you are the only man in step ?...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to chris on Tue Aug 3 19:16:12 2021
    On 08/03/21 19:08, chris wrote:
    On 08/03/21 18:57, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 18:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 17:34, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 16:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 15:15, Jim Pennino wrote:
    David Woolley<david@ex.djwhome.demon.invalid> wrote:
    On 03/08/2021 00:37, Jim Pennino wrote:
    PPS has no information. The purpose of PPS is to provide a >>>>>>>>>>>> reference
    that is as close to 1 Hz, i.e. an elapsed time of 1 second, >>>>>>>>>>>> as possible.


    PPS provides information on where within the cycle the true >>>>>>>>>>> UTC second
    transition most probably lies. You pretty much acknowledge >>>>>>>>>>> that later
    in your description.

    Nope.

    In fact if one were to build a highly stable oscillator totally >>>>>>>>>> independent of GPS, it would still work as a PPS signal.

    If you think otherwise, please provide the GPS specification. >>>>>>>>>>

    It may generate a pps signal if divided down, but it would not >>>>>>>>> be synchronised to UTC or anything else. Only a gps 1 pps
    can provide that signal, or another clock locked to UTC.

    I should stop digging mate, ever more ridiculous...

    Please provide the GPS specification that defines the PPS sync >>>>>>>> to UTC.

    Typical gps modules will claim a few 10's of ns offset limits
    for local pps in relation to UTC, which is the final arbiter.
    GPS have clocks traceable to national standards and UTC. They
    are the primary reference, to which any local clocks or
    oscillators, vcxo or rb, etc will be locked in sync with.

    If you need any more info, download the data sheet for a
    typical sub $10 gps module, which should have all the info
    you need...

    I did not ask for spec sheets for GPS modules.

    Please provide the GPS specification that defines the PPS sync to
    UTC.

    You claim PPS is synced to UTC.

    Prove it.


    Millions of people depend on it every day, so we know it works. PPS
    sync is directly traceable to the satellite master clocks and thence >>>>> to utc maintenance at the national standards labs worldwide. Yes Jim, >>>>> it's major worldwide collaboration, with everything from GSM mobile, >>>>> broadcasting, industry,. medicine and more depending on it. ...and you >>>>> have doubts ?.

    You claim the PPS pulse is synced to UTC.

    I say it is not.

    Prove your statement with a link to a GPS specification, not arm
    waving.

    Not a specialist in the subject,

    To say the least...



    You really are beyond help, but how do you think gsm cell handover, or
    high frequency stock trading works ?. Are you even curious about how
    things like that work and make some effort to find out ?.

    The thing about gps time and pps is that you can have a gps rx in London >>> and one on NY and both pps will be in sync to within 10's
    of nS typically. How amazing is that ?. nS accuracy just about
    anywhere on the planet where you can see satellites.

    Do your own homework and stop being so lazy :-)...

    Yet again, nothing but arm waving.

    You have claimed the GPS PPS pulse is synced to UTC.

    I say it is not and the GPS PPS pulse is only specified as an interval.

    Prove your statement with a link to a GPS specification, not arm waving.


    Rofl, i'm quite happy to accept that pps is deterministically
    related to UTC, nS offset and all, but you believe what you like.
    Millions of users worldwide would disagree with you, but hey,
    perhaps you are the only man in step ?...



    Just as a final question, how do you think UTC is generated and
    maintained these days ?. Clue: What source is used as a reference ?...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to David Woolley on Tue Aug 3 11:04:03 2021
    David Woolley <david@ex.djwhome.demon.invalid> wrote:
    On 03/08/2021 17:34, Jim Pennino wrote:
    Please provide the GPS specification that defines the PPS sync to UTC.


    I can't think of any good reason why the GPS specification should even mention PPS.

    Because it is there so there must be a specification that says to do it
    and how to do it. Government contractors can't include features on
    whims.

    Although there may be specialist equipment that only provides a 1Hz
    frequency standard (although I'd think 10MHz more likely), I think we
    would have seen lots of people reporting problems if real world PPS
    outputs weren't aligned with GPS seconds.

    Actually most current equipment provides both.

    Again, my position is that the GPS PPS signal is only specified as a
    time interval.

    If you have a document that says otherwise, produce it.

    As for a typical product specification, the Garmin 18x LVC series has
    this specification:

    "The highly accurate one-pulse-per-second (PPS) output is provided for applications requiring precise timing measurements. After the initial position fix has been calculated, the PPS signal is generated and
    continues until the unit is powered down. The rising edge of the signal
    is aligned to the start of each GPS second within 1 μs for all
    conditions in which the receiver has reported a valid and accurate
    position for at least the previous 4 seconds."

    <https://static.garmin.com/pumac/GPS_18x_Tech_Specs.pdf>

    Which says nothing about alignment of the GPS PPS signal with anything.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Tue Aug 3 11:19:21 2021
    chris <chris-nospam@tridac.net> wrote:

    <snip old stuff>

    Which beg the question, why are you here if you already have
    all the answers ?. T learn perhaps, as you seem to have no understanding
    of the relationship between utc and pps, even to
    the point of denying there is one ?...

    The answer to that question is in the title of the post.

    To recap, I was having issues with gpsd, which is a computer program to simplify interfacing GPS devices to the ntpd program.

    As it turned out, the issue was actually in the kernel pps_api.

    You keep claiming that the GPS PPS signal is synced to UTC yet every
    time I ask you for a reference to that, all you provide is arm waving.

    It is still my position, and will be until someone comes up with a GPS specification that says otherwise, that the only specification for the
    GPS PPS signal is interval accuracy, i.e. that it is 1 Hz +/- some specification.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Tue Aug 3 11:40:51 2021
    chris <chris-nospam@tridac.net> wrote:

    <snip old crap>

    Just as a final question, how do you think UTC is generated and
    maintained these days ?. Clue: What source is used as a reference ?...

    With regards to GPS, as it says in one of the links I gave you, USNO as
    GPS is a US government owned system.

    If you had actually read any of the links I gave you, you would not post
    such a naif question.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Tue Aug 3 11:33:40 2021
    chris <chris-nospam@tridac.net> wrote:
    On 08/03/21 18:57, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 18:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 17:34, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 16:22, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/03/21 15:15, Jim Pennino wrote:
    David Woolley<david@ex.djwhome.demon.invalid> wrote: >>>>>>>>>>> On 03/08/2021 00:37, Jim Pennino wrote:
    PPS has no information. The purpose of PPS is to provide a reference
    that is as close to 1 Hz, i.e. an elapsed time of 1 second, as possible.


    PPS provides information on where within the cycle the true UTC second
    transition most probably lies. You pretty much acknowledge that later
    in your description.

    Nope.

    In fact if one were to build a highly stable oscillator totally >>>>>>>>>> independent of GPS, it would still work as a PPS signal.

    If you think otherwise, please provide the GPS specification. >>>>>>>>>>

    It may generate a pps signal if divided down, but it would not >>>>>>>>> be synchronised to UTC or anything else. Only a gps 1 pps
    can provide that signal, or another clock locked to UTC.

    I should stop digging mate, ever more ridiculous...

    Please provide the GPS specification that defines the PPS sync to UTC. >>>>>>>
    Typical gps modules will claim a few 10's of ns offset limits
    for local pps in relation to UTC, which is the final arbiter.
    GPS have clocks traceable to national standards and UTC. They
    are the primary reference, to which any local clocks or
    oscillators, vcxo or rb, etc will be locked in sync with.

    If you need any more info, download the data sheet for a
    typical sub $10 gps module, which should have all the info
    you need...

    I did not ask for spec sheets for GPS modules.

    Please provide the GPS specification that defines the PPS sync to UTC. >>>>>>
    You claim PPS is synced to UTC.

    Prove it.


    Millions of people depend on it every day, so we know it works. PPS
    sync is directly traceable to the satellite master clocks and thence >>>>> to utc maintenance at the national standards labs worldwide. Yes Jim, >>>>> it's major worldwide collaboration, with everything from GSM mobile, >>>>> broadcasting, industry,. medicine and more depending on it. ...and you >>>>> have doubts ?.

    You claim the PPS pulse is synced to UTC.

    I say it is not.

    Prove your statement with a link to a GPS specification, not arm waving. >>>>
    Not a specialist in the subject,

    To say the least...



    You really are beyond help, but how do you think gsm cell handover, or
    high frequency stock trading works ?. Are you even curious about how
    things like that work and make some effort to find out ?.

    The thing about gps time and pps is that you can have a gps rx in London >>> and one on NY and both pps will be in sync to within 10's
    of nS typically. How amazing is that ?. nS accuracy just about
    anywhere on the planet where you can see satellites.

    Do your own homework and stop being so lazy :-)...

    Yet again, nothing but arm waving.

    You have claimed the GPS PPS pulse is synced to UTC.

    I say it is not and the GPS PPS pulse is only specified as an interval.

    Prove your statement with a link to a GPS specification, not arm waving.


    Rofl, i'm quite happy to accept that pps is deterministically
    related to UTC, nS offset and all, but you believe what you like.
    Millions of users worldwide would disagree with you, but hey,
    perhaps you are the only man in step ?...

    Does the work 'evidence' mean anything to you?

    As far as I am concerned, you are making a wild claim much like the
    "einsein was wrong" kooks and YOU are the one that needs to provide
    evidence for your claim.

    I also doubt that there are more than a few hundreds of people world
    wide that know how GPS actually works to the details of PPS signal specifications, so again, your arm waving is meaningless.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Miroslav Lichvar@21:1/5 to Jim Pennino on Tue Aug 3 18:46:41 2021
    On 2021-08-03, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    It is still my position, and will be until someone comes up with a GPS specification that says otherwise, that the only specification for the
    GPS PPS signal is interval accuracy, i.e. that it is 1 Hz +/- some specification.

    Maybe this will help https://www.usno.navy.mil/USNO/time/gps/gps-info

    GPS SYSTEM TIME
    GPS system time is given by its Composite Clock (CC). The CC or "paper"
    clock consists of all operational Monitor Station and satellite
    frequency standards. GPS system time, in turn, is referenced to the
    Master Clock (MC) at the USNO and steered to UTC(USNO) from which system
    time will not deviate by more than one microsecond. The exact difference
    is contained in the navigation message in the form of two constants, A0
    and A1, giving the time difference and rate of system time against UTC(USNO,MC). UTC(USNO) itself is kept very close to the international benchmark UTC as maintained by the BIPM, and the exact difference, USNO
    vs. BIPM is available in near real time.

    --
    Miroslav Lichvar

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Terje Mathisen@21:1/5 to Jim Pennino on Tue Aug 3 20:48:54 2021
    Jim Pennino wrote:
    It also seems the ntpd algorithms fall apart if you have multiple high accuracy reference clocks attached. I doubt any of the designers ever envisioned the day would come when someone could afford more than one as
    at that time such things would set you back many tens of thousands of dollars.

    Rather the opposite, this is how we compare various PPS devices, i.e. by setting 'prefer' on one of them and comparing how the others behave
    relative to this, then optionally swtich the prefer around and retry.

    Good refclocks, like the original Oncore UT+ allow you to both offset
    the PPS signal from the top of the second (to avoid any extra interrupt
    latency due to multiple events firing at the same time), and to
    determine the sawtooth error, which is the +/-50 ns you get when the PPS
    signal is generated from the 10 MHz reference: The serial protocol
    includes information about how far off the current pulse is/will be.

    Now they cost less than $50.

    This is irrelevant as if you have a high accuracy reference clock, you
    only need one and ntpd will sort itself out just fine.

    ntpd is designed to handle _many_ sources and (with the pool)
    automatically settle on a near-optimal set of up to 10 sources.

    Terje

    --
    - <Terje.Mathisen at tmsw.no>
    "almost all programming can be viewed as an exercise in caching"

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Terje Mathisen@21:1/5 to chris on Tue Aug 3 20:56:01 2021
    chris wrote:
    On 08/03/21 15:15, Jim Pennino wrote:
    David Woolley<david@ex.djwhome.demon.invalid>  wrote:
    On 03/08/2021 00:37, Jim Pennino wrote:
    PPS has no information. The purpose of PPS is to provide a reference
    that is as close to 1 Hz, i.e. an elapsed time of 1 second, as
    possible.


    PPS provides information on where within the cycle the true UTC second
    transition most probably lies.  You pretty much acknowledge that later
    in your description.

    Nope.

    In fact if one were to build a highly stable oscillator totally
    independent of GPS, it would still work as a PPS signal.

    If you think otherwise, please provide the GPS specification.


    It may generate a pps signal if divided down, but it would not
    be synchronised to UTC or anything else. Only a gps 1 pps
    can provide that signal, or another clock locked to UTC.

    I should stop digging mate, ever more ridiculous...

    A PPS signal without some additional signal (serial or otherwise) which names/numbers the seconds will be dropped very quickly by ntpd.

    I.e. even if those pulses are delivered by an HP atomic clock, they are worthless without the secondary info.

    Terje

    --
    - <Terje.Mathisen at tmsw.no>
    "almost all programming can be viewed as an exercise in caching"

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to Terje Mathisen on Tue Aug 3 12:34:15 2021
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    chris wrote:
    On 08/03/21 15:15, Jim Pennino wrote:
    David Woolley<david@ex.djwhome.demon.invalid>  wrote:
    On 03/08/2021 00:37, Jim Pennino wrote:
    PPS has no information. The purpose of PPS is to provide a reference >>>>> that is as close to 1 Hz, i.e. an elapsed time of 1 second, as
    possible.


    PPS provides information on where within the cycle the true UTC second >>>> transition most probably lies.  You pretty much acknowledge that later >>>> in your description.

    Nope.

    In fact if one were to build a highly stable oscillator totally
    independent of GPS, it would still work as a PPS signal.

    If you think otherwise, please provide the GPS specification.


    It may generate a pps signal if divided down, but it would not
    be synchronised to UTC or anything else. Only a gps 1 pps
    can provide that signal, or another clock locked to UTC.

    I should stop digging mate, ever more ridiculous...

    A PPS signal without some additional signal (serial or otherwise) which names/numbers the seconds will be dropped very quickly by ntpd.

    I.e. even if those pulses are delivered by an HP atomic clock, they are worthless without the secondary info.

    Terje

    That is the basis for gpsd, i.e. simplifying ntpd setup and getting it
    right.

    With gpsd the newbie user is relieved from having to select which clock
    driver to use, whether their version of ntpd is new enough such that the
    .20 is atomized or not, knowing the difference between .20 and .22, etc.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to Miroslav Lichvar on Tue Aug 3 12:59:45 2021
    Miroslav Lichvar <mlichvar@redhat.com> wrote:
    On 2021-08-03, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    It is still my position, and will be until someone comes up with a GPS
    specification that says otherwise, that the only specification for the
    GPS PPS signal is interval accuracy, i.e. that it is 1 Hz +/- some
    specification.

    Maybe this will help https://www.usno.navy.mil/USNO/time/gps/gps-info

    GPS SYSTEM TIME
    GPS system time is given by its Composite Clock (CC). The CC or "paper"
    clock consists of all operational Monitor Station and satellite
    frequency standards. GPS system time, in turn, is referenced to the
    Master Clock (MC) at the USNO and steered to UTC(USNO) from which system
    time will not deviate by more than one microsecond. The exact difference
    is contained in the navigation message in the form of two constants, A0
    and A1, giving the time difference and rate of system time against UTC(USNO,MC). UTC(USNO) itself is kept very close to the international benchmark UTC as maintained by the BIPM, and the exact difference, USNO
    vs. BIPM is available in near real time.

    Well, actually no, as it says nothing about how the PPS signal is
    generated.

    I thought the current standard for system time was less than or equal to
    40 nanoseconds from USNO to a 95% probability.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to Terje Mathisen on Tue Aug 3 12:54:00 2021
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    Jim Pennino wrote:
    It also seems the ntpd algorithms fall apart if you have multiple high
    accuracy reference clocks attached. I doubt any of the designers ever
    envisioned the day would come when someone could afford more than one as
    at that time such things would set you back many tens of thousands of
    dollars.

    Rather the opposite, this is how we compare various PPS devices, i.e. by setting 'prefer' on one of them and comparing how the others behave
    relative to this, then optionally swtich the prefer around and retry.

    Try it with two identical sources and I think you will find that without
    a prefer, ntpd gets rather confused rather quickly.

    Which means if you actually do this, you MUST use prefer for it to work properly. AFAIK, that is not documented.

    Good refclocks, like the original Oncore UT+ allow you to both offset
    the PPS signal from the top of the second (to avoid any extra interrupt latency due to multiple events firing at the same time), and to
    determine the sawtooth error, which is the +/-50 ns you get when the PPS signal is generated from the 10 MHz reference: The serial protocol
    includes information about how far off the current pulse is/will be.

    Now they cost less than $50.

    This is irrelevant as if you have a high accuracy reference clock, you
    only need one and ntpd will sort itself out just fine.

    ntpd is designed to handle _many_ sources and (with the pool)
    automatically settle on a near-optimal set of up to 10 sources.

    True, but if you do have a high accuracy reference clock, you do not
    need any other sources other than if in the unlikely failure of your
    device there would be serious consequences.



    Terje


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Terje Mathisen@21:1/5 to Jim Pennino on Wed Aug 4 12:35:16 2021
    Jim Pennino wrote:
    chris <chris-nospam@tridac.net> wrote:
    You really are beyond help, but how do you think gsm cell handover, or
    high frequency stock trading works ?. Are you even curious about how
    things like that work and make some effort to find out ?.

    The thing about gps time and pps is that you can have a gps rx in London
    and one on NY and both pps will be in sync to within 10's
    of nS typically. How amazing is that ?. nS accuracy just about
    anywhere on the planet where you can see satellites.

    Do your own homework and stop being so lazy :-)...

    Yet again, nothing but arm waving.

    You have claimed the GPS PPS pulse is synced to UTC.

    I say it is not and the GPS PPS pulse is only specified as an interval.

    Jim, now you are just being a troll:

    Yes, we all know that UTC is a paper clock, determined a month behind
    after collecting data from the (order of magnitude) 100+ atomic clocks
    in many national laboratories.

    This means that nobody can claim to know "This is the exact PPS
    instant", only that statistical data for their local reference clocks
    (like USNO whoch provides the baseline for GPS) show that they have been consistently within single-digit ns of the consensus/paper calculated value.

    However, for our purposes, USNO used to have an original goal of being
    within (afair) 25 ns of the UTC paper clock, and to keep each GPS sat
    within another 25 (or so) ns of UTC(USNO), with a total max offset of
    ~45 ns.

    In reality they are doing far better these days, so we can safely claim
    GPS time to be within 10 ns of UTC, simply because they have
    consistently been so for a decade or two.

    In order to provide 3m positional accuracy, we get a relative timing
    accuracy of better than 10 ns, i.e. all the visible sats needs to agree
    what TAI(GPS) is within a ns or two.

    Similarly, starting with the timing GPS receiver: Since it knows where
    it is (either statically or due to long-term averaging) with sub-meter precision, it will only introduce time errors in the same ballpark, i.e.
    a couple of ns.

    The end of all this is that we can all safely claim that a working
    GPS-based PPS source will be in the 5-50 ns (RMS) range of true TAI/UTC.

    If you need beter than this then you need your own atomic clock and
    long-term comparisons with your friendly neigborhood national lab.

    Terje


    --
    - <Terje.Mathisen at tmsw.no>
    "almost all programming can be viewed as an exercise in caching"

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to Terje Mathisen on Wed Aug 4 08:07:28 2021
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    Jim Pennino wrote:
    chris <chris-nospam@tridac.net> wrote:
    You really are beyond help, but how do you think gsm cell handover, or
    high frequency stock trading works ?. Are you even curious about how
    things like that work and make some effort to find out ?.

    The thing about gps time and pps is that you can have a gps rx in London >>> and one on NY and both pps will be in sync to within 10's
    of nS typically. How amazing is that ?. nS accuracy just about
    anywhere on the planet where you can see satellites.

    Do your own homework and stop being so lazy :-)...

    Yet again, nothing but arm waving.

    You have claimed the GPS PPS pulse is synced to UTC.

    I say it is not and the GPS PPS pulse is only specified as an interval.

    Jim, now you are just being a troll:

    Yes, we all know that UTC is a paper clock, determined a month behind
    after collecting data from the (order of magnitude) 100+ atomic clocks
    in many national laboratories.

    This means that nobody can claim to know "This is the exact PPS
    instant", only that statistical data for their local reference clocks
    (like USNO whoch provides the baseline for GPS) show that they have been consistently within single-digit ns of the consensus/paper calculated value.

    However, for our purposes, USNO used to have an original goal of being
    within (afair) 25 ns of the UTC paper clock, and to keep each GPS sat
    within another 25 (or so) ns of UTC(USNO), with a total max offset of
    ~45 ns.

    In reality they are doing far better these days, so we can safely claim
    GPS time to be within 10 ns of UTC, simply because they have
    consistently been so for a decade or two.

    In order to provide 3m positional accuracy, we get a relative timing
    accuracy of better than 10 ns, i.e. all the visible sats needs to agree
    what TAI(GPS) is within a ns or two.

    Similarly, starting with the timing GPS receiver: Since it knows where
    it is (either statically or due to long-term averaging) with sub-meter precision, it will only introduce time errors in the same ballpark, i.e.
    a couple of ns.

    The end of all this is that we can all safely claim that a working
    GPS-based PPS source will be in the 5-50 ns (RMS) range of true TAI/UTC.

    If you need beter than this then you need your own atomic clock and
    long-term comparisons with your friendly neigborhood national lab.

    Terje

    Yeah, I know all that, but nowhere do you address the actual issue.

    Addressing the actual issue would require citing the GPS specification
    that says how PPS is generated and it's specified accuracy.

    Quoting observed things is interesting but not a specification.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Terje Mathisen@21:1/5 to Jim Pennino on Wed Aug 4 18:59:26 2021
    Jim Pennino wrote:
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    [big snip]
    Similarly, starting with the timing GPS receiver: Since it knows where
    it is (either statically or due to long-term averaging) with sub-meter
    precision, it will only introduce time errors in the same ballpark, i.e.
    a couple of ns.

    The end of all this is that we can all safely claim that a working
    GPS-based PPS source will be in the 5-50 ns (RMS) range of true TAI/UTC.

    If you need beter than this then you need your own atomic clock and
    long-term comparisons with your friendly neigborhood national lab.

    Terje

    Yeah, I know all that, but nowhere do you address the actual issue.

    Addressing the actual issue would require citing the GPS specification
    that says how PPS is generated and it's specified accuracy.

    Quoting observed things is interesting but not a specification.

    GPS never talks about PPS, that is simply not a part of what a
    position/timing constellation needs to care about.

    A PPS signal is always locally generated, for most (all?) those I have
    read the specifications, this PPS signal is generated by the GPS
    receiver chipset using a local 10 MHz oscillator, so that the PPS signal
    is a pulse that rises on the edge which it has calculated will be the
    closest to the true UTC/TAI second start.

    With this approach we automatically get a standard deviation of 25-50 ns
    from UTC(USNO), even if the average is perfectly centered around the
    true second tick.

    As you have alluded to multiple times, GPS time which is very close to UTC(USNO) introduces two more sources of jitter, i.e. the USNO to GPS
    sat time transfer and the UTC to UTC(USNO) delta, but in the current
    worl we are living in, UTC(GPS) is effectively the only real source for
    time sync in global use.

    Terje

    --
    - <Terje.Mathisen at tmsw.no>
    "almost all programming can be viewed as an exercise in caching"

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to Terje Mathisen on Wed Aug 4 10:39:48 2021
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    Jim Pennino wrote:
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    [big snip]
    Similarly, starting with the timing GPS receiver: Since it knows where
    it is (either statically or due to long-term averaging) with sub-meter
    precision, it will only introduce time errors in the same ballpark, i.e. >>> a couple of ns.

    The end of all this is that we can all safely claim that a working
    GPS-based PPS source will be in the 5-50 ns (RMS) range of true TAI/UTC. >>>
    If you need beter than this then you need your own atomic clock and
    long-term comparisons with your friendly neigborhood national lab.

    Terje

    Yeah, I know all that, but nowhere do you address the actual issue.

    Addressing the actual issue would require citing the GPS specification
    that says how PPS is generated and it's specified accuracy.

    Quoting observed things is interesting but not a specification.

    GPS never talks about PPS, that is simply not a part of what a position/timing constellation needs to care about.

    A PPS signal is always locally generated, for most (all?) those I have
    read the specifications, this PPS signal is generated by the GPS
    receiver chipset using a local 10 MHz oscillator, so that the PPS signal
    is a pulse that rises on the edge which it has calculated will be the
    closest to the true UTC/TAI second start.

    With this approach we automatically get a standard deviation of 25-50 ns
    from UTC(USNO), even if the average is perfectly centered around the
    true second tick.

    As you have alluded to multiple times, GPS time which is very close to UTC(USNO) introduces two more sources of jitter, i.e. the USNO to GPS
    sat time transfer and the UTC to UTC(USNO) delta, but in the current
    worl we are living in, UTC(GPS) is effectively the only real source for
    time sync in global use.

    Terje

    So you are saying every GPS receiver has a 10 MHz oscillator ergo the
    accuracy of the PPS output signal is totally dependent on the accuracy
    of the internal oscillator, ignoring what one MAY externally add?

    If so, you have validated my contention that GPS does NOT specify PPS syncronization to UTC, but rather it is totally up to whoever designed
    the receiver.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Woolley@21:1/5 to Terje Mathisen on Wed Aug 4 22:17:00 2021
    On 04/08/2021 17:59, Terje Mathisen wrote:

    using a local 10 MHz oscillator

    I can't see why a GPS receiver would need a 10MHz oscillator. The
    chipping rates are 1.023Mhz, and 10.023MHz, and I would expect a
    multiple of one of those

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to David Woolley on Wed Aug 4 14:56:39 2021
    David Woolley <david@ex.djwhome.demon.invalid> wrote:
    On 04/08/2021 17:59, Terje Mathisen wrote:

    using a local 10 MHz oscillator

    I can't see why a GPS receiver would need a 10MHz oscillator. The
    chipping rates are 1.023Mhz, and 10.023MHz, and I would expect a
    multiple of one of those

    Why?

    PLL tech is a bit better than it was in 1971 when I first used one.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to David Woolley on Wed Aug 4 22:47:19 2021
    On 08/04/21 22:17, David Woolley wrote:
    On 04/08/2021 17:59, Terje Mathisen wrote:

    using a local 10 MHz oscillator

    I can't see why a GPS receiver would need a 10MHz oscillator. The
    chipping rates are 1.023Mhz, and 10.023MHz, and I would expect a
    multiple of one of those

    A gps receiver may use a 10MHz oscillator, if it's primarily aimed at
    the gps do market, eg: a frequency standard application to drive
    test equipment, as 10MHz tends to be the industry standard these days
    for such applications. All the telco gps d0 boxes i've seen have both
    pps and 10MHz outputs, but also various timing signals to suit T1 and
    E1 telco framing specs. Many amateurs and professionals use a
    gps do as primary frequency standards, as their outputs are directly
    traceable to nationals standards and UTC. That is, almost caesium
    accuracy and stability at a small fraction of the cost. Have a caesium
    standard here, only gets powered ip occasionally, but the offset
    between that and a typical 10MHz gps do is almost unmeasureable.

    Have a look at the time-nuts mailing list for more info. Time and
    frequency are an interest area here, but not so obsessive as some on
    that list. Some good open source software there as well, for
    characterising standards...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Jim Pennino on Thu Aug 5 00:07:43 2021
    On 2021-08-04, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    Jim Pennino wrote:
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    [big snip]
    Similarly, starting with the timing GPS receiver: Since it knows where >>>> it is (either statically or due to long-term averaging) with sub-meter >>>> precision, it will only introduce time errors in the same ballpark, i.e. >>>> a couple of ns.

    The end of all this is that we can all safely claim that a working
    GPS-based PPS source will be in the 5-50 ns (RMS) range of true TAI/UTC. >>>>
    If you need beter than this then you need your own atomic clock and
    long-term comparisons with your friendly neigborhood national lab.

    Terje

    Yeah, I know all that, but nowhere do you address the actual issue.

    Addressing the actual issue would require citing the GPS specification
    that says how PPS is generated and it's specified accuracy.

    Quoting observed things is interesting but not a specification.

    GPS never talks about PPS, that is simply not a part of what a
    position/timing constellation needs to care about.

    A PPS signal is always locally generated, for most (all?) those I have
    read the specifications, this PPS signal is generated by the GPS
    receiver chipset using a local 10 MHz oscillator, so that the PPS signal
    is a pulse that rises on the edge which it has calculated will be the
    closest to the true UTC/TAI second start.

    With this approach we automatically get a standard deviation of 25-50 ns
    from UTC(USNO), even if the average is perfectly centered around the
    true second tick.

    As you have alluded to multiple times, GPS time which is very close to
    UTC(USNO) introduces two more sources of jitter, i.e. the USNO to GPS
    sat time transfer and the UTC to UTC(USNO) delta, but in the current
    worl we are living in, UTC(GPS) is effectively the only real source for
    time sync in global use.

    Terje

    So you are saying every GPS receiver has a 10 MHz oscillator ergo the accuracy of the PPS output signal is totally dependent on the accuracy
    of the internal oscillator, ignoring what one MAY externally add?

    No. He is saying that the gps picks the edge of 10MHz signal that is
    closest to GPS time. That does not depend on the accuracy of the 10MHz. Sometime the gps signal may pick the edge that is 997 cycles away from
    the lastone, sometimes the 998, sometimes the 1001 -- whichever is
    closest. The GPS sattelites send down a time signal. The PPS tends to
    ramp up in a sawtooth.and when it gets to 50 flips to the next one. A
    good timing gps will figure out what its 10MHz is with respect to GPS
    time and send down a correction so you can, after the fact correct for
    the sawtooth offset.

    If so, you have validated my contention that GPS does NOT specify PPS syncronization to UTC, but rather it is totally up to whoever designed
    the receiver.

    You did not read what he said.



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to William Unruh on Wed Aug 4 17:57:39 2021
    William Unruh <unruh@invalid.ca> wrote:
    On 2021-08-04, Jim Pennino <jimp@gonzo.specsol.net> wrote:
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    Jim Pennino wrote:
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    [big snip]
    Similarly, starting with the timing GPS receiver: Since it knows where >>>>> it is (either statically or due to long-term averaging) with sub-meter >>>>> precision, it will only introduce time errors in the same ballpark, i.e. >>>>> a couple of ns.

    The end of all this is that we can all safely claim that a working
    GPS-based PPS source will be in the 5-50 ns (RMS) range of true TAI/UTC. >>>>>
    If you need beter than this then you need your own atomic clock and
    long-term comparisons with your friendly neigborhood national lab.

    Terje

    Yeah, I know all that, but nowhere do you address the actual issue.

    Addressing the actual issue would require citing the GPS specification >>>> that says how PPS is generated and it's specified accuracy.

    Quoting observed things is interesting but not a specification.

    GPS never talks about PPS, that is simply not a part of what a
    position/timing constellation needs to care about.

    A PPS signal is always locally generated, for most (all?) those I have
    read the specifications, this PPS signal is generated by the GPS
    receiver chipset using a local 10 MHz oscillator, so that the PPS signal >>> is a pulse that rises on the edge which it has calculated will be the
    closest to the true UTC/TAI second start.

    With this approach we automatically get a standard deviation of 25-50 ns >>> from UTC(USNO), even if the average is perfectly centered around the
    true second tick.

    As you have alluded to multiple times, GPS time which is very close to
    UTC(USNO) introduces two more sources of jitter, i.e. the USNO to GPS
    sat time transfer and the UTC to UTC(USNO) delta, but in the current
    worl we are living in, UTC(GPS) is effectively the only real source for
    time sync in global use.

    Terje

    So you are saying every GPS receiver has a 10 MHz oscillator ergo the
    accuracy of the PPS output signal is totally dependent on the accuracy
    of the internal oscillator, ignoring what one MAY externally add?

    No. He is saying that the gps picks the edge of 10MHz signal that is
    closest to GPS time. That does not depend on the accuracy of the 10MHz. Sometime the gps signal may pick the edge that is 997 cycles away from
    the lastone, sometimes the 998, sometimes the 1001 -- whichever is
    closest. The GPS sattelites send down a time signal. The PPS tends to
    ramp up in a sawtooth.and when it gets to 50 flips to the next one. A
    good timing gps will figure out what its 10MHz is with respect to GPS
    time and send down a correction so you can, after the fact correct for
    the sawtooth offset.

    If so, you have validated my contention that GPS does NOT specify PPS
    syncronization to UTC, but rather it is totally up to whoever designed
    the receiver.

    You did not read what he said.

    Yes, I read it but apparently you did not.

    "this PPS signal is generated by the GPS receiver chipset" is what he
    said.

    I presume where you wrote "A good timing gps will" you meant to say
    "timing GPS receiver" but have problems with what you meant by "and
    send down a correction" other than maybe "and output a correction".

    The line "The PPS tends to ramp up in a sawtooth" is baffling as PPS is
    a digital signal and is either low or high.

    Perhaps you meant something like "The PPS dectector or generator ramps".

    In regards to the line "Sometime the gps signal may pick the edge",
    please explain how a signal can pick anything.

    Perhaps you meant something like "Sometimes the GPS receiver time
    processing circuitry may pick".

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to David Woolley on Thu Aug 5 11:45:28 2021
    On 08/04/21 22:17, David Woolley wrote:
    On 04/08/2021 17:59, Terje Mathisen wrote:

    using a local 10 MHz oscillator

    I can't see why a GPS receiver would need a 10MHz oscillator. The
    chipping rates are 1.023Mhz, and 10.023MHz, and I would expect a
    multiple of one of those

    Just to disambiguate the comments about 10MHz. While the gps receiver
    module will have an internal oscillator to suit the design, that
    oscillator is not normally available external to the module. What the
    gps receiver does provide, is a 1pps signal traceable to UTC and it is
    to that, that an external high stability 10 MHz or other frequency
    oscillator may be phase locked to.

    There all kinds of applications for gps capabilities, with navigation
    being just one...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Woolley@21:1/5 to Jim Pennino on Thu Aug 5 12:00:09 2021
    On 04/08/2021 22:56, Jim Pennino wrote:
    I can't see why a GPS receiver would need a 10MHz oscillator. The
    chipping rates are 1.023Mhz, and 10.023MHz, and I would expect a
    multiple of one of those
    Why?

    PLL tech is a bit better than it was in 1971 when I first used one.



    Do you mean frequency synthesizer tech?

    It does seem that the internal crystal frequency is somewhat arbitrary,
    because the real working frequencies are generated by synthesizers. I
    found products using 26MHz, as well as 10MHz for their primary oscillators.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Terje Mathisen@21:1/5 to Jim Pennino on Thu Aug 5 17:50:16 2021
    Jim Pennino wrote:
    David Woolley <david@ex.djwhome.demon.invalid> wrote:
    So, in what today we call a gps, there are at least three separate
    devices, a radio receiver to obtain the the GPS data, a device to
    generate PPS, and a device to convert GPS data to NMEA sentences.

    Except that in a modern chipset as used in a cell phone, all of those functions, plus wifi and possibly even more, is a single chip.

    BTW, NMEA stands for National Marine Electronics Association. Guess why commercial GPS devices output data in a marine standard format.

    In circa 1996 those three devices would likely be in three 19 inch rack
    mount boxes containing mostly discrete components.

    Your timing is off by a substantial number of years: Garmin sold
    (portable) GPSs for $105M already in 1995, I have track logs which are
    older than this.

    https://en.wikipedia.org/wiki/Garmin#Handheld_GPS

    Today everything is fabricated on chip sets.

    In regards to PPS alignment with UTC, since it is up to the equiment
    maker, it will be whatever the equipment maker decides it will be.

    Yes, and when the time nuts compare the PPS signal from those cheap
    boards, against proper atomic reference clocks, like the sub-80 dollar
    SURE which was popular about 8-10 years ago, they found about 25 ns RMS
    offset.

    Terje


    --
    - <Terje.Mathisen at tmsw.no>
    "almost all programming can be viewed as an exercise in caching"

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Thu Aug 5 08:06:37 2021
    chris <chris-nospam@tridac.net> wrote:
    On 08/04/21 22:17, David Woolley wrote:
    On 04/08/2021 17:59, Terje Mathisen wrote:

    using a local 10 MHz oscillator

    I can't see why a GPS receiver would need a 10MHz oscillator. The
    chipping rates are 1.023Mhz, and 10.023MHz, and I would expect a
    multiple of one of those

    Just to disambiguate the comments about 10MHz. While the gps receiver
    module will have an internal oscillator to suit the design, that
    oscillator is not normally available external to the module. What the
    gps receiver does provide, is a 1pps signal traceable to UTC and it is
    to that, that an external high stability 10 MHz or other frequency
    oscillator may be phase locked to.

    No, the receiver does not provide a PPS signal unless you are calling
    the entire gps device a receiver, which contains three separate devices,
    i.e a radio receiver, a time standard (PPS) generator, and a NMEA
    sentence generator.

    There all kinds of applications for gps capabilities, with navigation
    being just one...

    No shit, Captain Obvious?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to David Woolley on Thu Aug 5 08:02:01 2021
    David Woolley <david@ex.djwhome.demon.invalid> wrote:
    On 04/08/2021 22:56, Jim Pennino wrote:
    I can't see why a GPS receiver would need a 10MHz oscillator. The
    chipping rates are 1.023Mhz, and 10.023MHz, and I would expect a
    multiple of one of those
    Why?

    PLL tech is a bit better than it was in 1971 when I first used one.



    Do you mean frequency synthesizer tech?

    If you want to be very general about it, but few if any frequency
    synthesizers, as opposed to waveform generators, use anything other
    than PLL tecnology.

    That does not mean they use NE565 analog IC technology from 1970, but
    rather they implement the PLL equations in hardware in some manner, such
    as the use of fractional-N and computational based PLL devices.

    It does seem that the internal crystal frequency is somewhat arbitrary, because the real working frequencies are generated by synthesizers. I
    found products using 26MHz, as well as 10MHz for their primary oscillators.

    Why would it be other than arbitrary?

    GPS receivers are not part of the GPS specifications, as ONE other
    person has noted.

    The GPS system specifications are for the ground segment, i.e. command and control, and the space segment, i.e. the satellites, and that is it.

    The specifications define the radio signals from the satellites, i.e.
    the carrier frequency(s), the modulation method(s) used, and the data
    streams therein.

    Everything else is up to the end user to design equipment to utilize
    those radio signals in a manner totally up to the equipment designer.

    Nowhere in the GPS specifications is PPS mentioned.

    Along with the specifications is a set of what amounts to white papers describing various things that can be done using the GPS system.

    Among those papers is one directed at metrologists who have interest in
    time and frequency measurement.

    The latest revision I can find is from 1996, so it is sometimes a
    somewhat quaint read in 2021, but goes into a lot of detail about doing
    such things as generating precise frequency standards traceable to GPS accuracies. Most of that detail is in the form of equations with some generalized algorithms.

    Again, it is up to the equipment designer how to implement those things.

    As a 1 Hz signal, i.e. PPS, is something commonly used by metrologists,
    it is in there that generating a PPS is discussed along with generating
    other common frequencies used in metrology.

    So, in what today we call a gps, there are at least three separate
    devices, a radio receiver to obtain the the GPS data, a device to
    generate PPS, and a device to convert GPS data to NMEA sentences.

    BTW, NMEA stands for National Marine Electronics Association. Guess why commercial GPS devices output data in a marine standard format.

    In circa 1996 those three devices would likely be in three 19 inch rack
    mount boxes containing mostly discrete components.

    Today everything is fabricated on chip sets.

    In regards to PPS alignment with UTC, since it is up to the equiment
    maker, it will be whatever the equipment maker decides it will be.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to Jim Pennino on Thu Aug 5 17:34:38 2021
    On 08/05/21 16:06, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/04/21 22:17, David Woolley wrote:
    On 04/08/2021 17:59, Terje Mathisen wrote:

    using a local 10 MHz oscillator

    I can't see why a GPS receiver would need a 10MHz oscillator. The
    chipping rates are 1.023Mhz, and 10.023MHz, and I would expect a
    multiple of one of those

    Just to disambiguate the comments about 10MHz. While the gps receiver
    module will have an internal oscillator to suit the design, that
    oscillator is not normally available external to the module. What the
    gps receiver does provide, is a 1pps signal traceable to UTC and it is
    to that, that an external high stability 10 MHz or other frequency
    oscillator may be phase locked to.

    No, the receiver does not provide a PPS signal unless you are calling
    the entire gps device a receiver, which contains three separate devices,
    i.e a radio receiver, a time standard (PPS) generator, and a NMEA
    sentence generator.

    I said gps receiver module, which most familiar with the technology
    would take to mean the sort of thing you can buy for a few $ on Ebay,
    but I guess with have to make allowances. So, enlighten us, just
    how do the pps and nmea sentances appear on output pins ?. Some
    sort of black magic perhaps ?...


    There all kinds of applications for gps capabilities, with navigation
    being just one...

    No shit, Captain Obvious?


    Nurse !!!. Has Doreen not not been taking her meds today ?.



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Thu Aug 5 10:00:05 2021
    chris <chris-nospam@tridac.net> wrote:
    On 08/05/21 16:06, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/04/21 22:17, David Woolley wrote:
    On 04/08/2021 17:59, Terje Mathisen wrote:

    using a local 10 MHz oscillator

    I can't see why a GPS receiver would need a 10MHz oscillator. The
    chipping rates are 1.023Mhz, and 10.023MHz, and I would expect a
    multiple of one of those

    Just to disambiguate the comments about 10MHz. While the gps receiver
    module will have an internal oscillator to suit the design, that
    oscillator is not normally available external to the module. What the
    gps receiver does provide, is a 1pps signal traceable to UTC and it is
    to that, that an external high stability 10 MHz or other frequency
    oscillator may be phase locked to.

    No, the receiver does not provide a PPS signal unless you are calling
    the entire gps device a receiver, which contains three separate devices,
    i.e a radio receiver, a time standard (PPS) generator, and a NMEA
    sentence generator.

    I said gps receiver module, which most familiar with the technology
    would take to mean the sort of thing you can buy for a few $ on Ebay,
    but I guess with have to make allowances. So, enlighten us, just
    how do the pps and nmea sentances appear on output pins ?. Some
    sort of black magic perhaps ?...

    Your question is answered at some length in another post.

    I am not going to repost it just for you.

    This is a technical discussion group, not a marketing group, and as such precision in language and the lack of arm waving matters.

    The phrase "gps receiver module" is ambiguous in a discussion of GPS
    technology in 2021 absent a definition of what you mean.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to Terje Mathisen on Thu Aug 5 09:51:48 2021
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    Jim Pennino wrote:
    David Woolley <david@ex.djwhome.demon.invalid> wrote:
    So, in what today we call a gps, there are at least three separate
    devices, a radio receiver to obtain the the GPS data, a device to
    generate PPS, and a device to convert GPS data to NMEA sentences.

    Except that in a modern chipset as used in a cell phone, all of those functions, plus wifi and possibly even more, is a single chip.

    I believe I said something like that in the next to last sentence which
    you quoted below.

    BTW, NMEA stands for National Marine Electronics Association. Guess why
    commercial GPS devices output data in a marine standard format.

    In circa 1996 those three devices would likely be in three 19 inch rack
    mount boxes containing mostly discrete components.

    Your timing is off by a substantial number of years: Garmin sold
    (portable) GPSs for $105M already in 1995, I have track logs which are
    older than this.

    https://en.wikipedia.org/wiki/Garmin#Handheld_GPS

    Yes, but without PPS.

    As for portabale, while in the Army I worked on a "portable" system who's command and control part alone was mounted on 5 truck pulled trailers.

    The first GPS chipsets were circa 2004 so anything GPS related HAD to be
    built with discrete components, e.g. PLL IC's with associate components.

    Today everything is fabricated on chip sets.

    In regards to PPS alignment with UTC, since it is up to the equiment
    maker, it will be whatever the equipment maker decides it will be.

    Yes, and when the time nuts compare the PPS signal from those cheap
    boards, against proper atomic reference clocks, like the sub-80 dollar
    SURE which was popular about 8-10 years ago, they found about 25 ns RMS offset.

    Terje

    Which is not as good as can be theoretically obtained.

    The reality is that "time nuts" are an insignificant market for GPS
    chipset makers and are inconsequential to them. They make chip sets
    for a mass market and not to make David L. Mills happy.

    Mximizing market share and profit margin are important so makers will
    make things with that in mind, e.g. will optimize things and add
    features, such as WAAS, that will do so.

    As an example, most of the GNSS chipsets (I don't think anyone is actually making GPS chipsets anymore) I have seen output their data via an I2C bus because given the VAST number of types of I2C chipsets that exist, it
    becomes trivial for the end maker to integrate GNSS chipsets with end
    product, be it an aviation navigator, cell phone, or whatever.

    If increasing the accuracy of PPS will increase their profit margin, it
    will happen, but right now it appears that the PPS accuracy is a function
    of what the fabrication technology happens to do rather than a design specification.

    Which means PPS accuracy will improve automatically as fabrication
    technology improves.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to Jim Pennino on Thu Aug 5 18:10:27 2021
    On 08/05/21 18:00, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/05/21 16:06, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/04/21 22:17, David Woolley wrote:
    On 04/08/2021 17:59, Terje Mathisen wrote:

    using a local 10 MHz oscillator

    I can't see why a GPS receiver would need a 10MHz oscillator. The
    chipping rates are 1.023Mhz, and 10.023MHz, and I would expect a
    multiple of one of those

    Just to disambiguate the comments about 10MHz. While the gps receiver
    module will have an internal oscillator to suit the design, that
    oscillator is not normally available external to the module. What the
    gps receiver does provide, is a 1pps signal traceable to UTC and it is >>>> to that, that an external high stability 10 MHz or other frequency
    oscillator may be phase locked to.

    No, the receiver does not provide a PPS signal unless you are calling
    the entire gps device a receiver, which contains three separate devices, >>> i.e a radio receiver, a time standard (PPS) generator, and a NMEA
    sentence generator.

    I said gps receiver module, which most familiar with the technology
    would take to mean the sort of thing you can buy for a few $ on Ebay,
    but I guess with have to make allowances. So, enlighten us, just
    how do the pps and nmea sentances appear on output pins ?. Some
    sort of black magic perhaps ?...

    Your question is answered at some length in another post.

    I am not going to repost it just for you.

    This is a technical discussion group, not a marketing group, and as such precision in language and the lack of arm waving matters.

    The phrase "gps receiver module" is ambiguous in a discussion of GPS technology in 2021 absent a definition of what you mean.


    You talk about arm waving, but the fact is, you don't know, don't
    understand and are too lazy to make the effort to find out...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to chris on Thu Aug 5 10:25:32 2021
    chris <chris-nospam@tridac.net> wrote:
    On 08/05/21 18:00, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/05/21 16:06, Jim Pennino wrote:
    chris<chris-nospam@tridac.net> wrote:
    On 08/04/21 22:17, David Woolley wrote:
    On 04/08/2021 17:59, Terje Mathisen wrote:

    using a local 10 MHz oscillator

    I can't see why a GPS receiver would need a 10MHz oscillator. The
    chipping rates are 1.023Mhz, and 10.023MHz, and I would expect a
    multiple of one of those

    Just to disambiguate the comments about 10MHz. While the gps receiver >>>>> module will have an internal oscillator to suit the design, that
    oscillator is not normally available external to the module. What the >>>>> gps receiver does provide, is a 1pps signal traceable to UTC and it is >>>>> to that, that an external high stability 10 MHz or other frequency
    oscillator may be phase locked to.

    No, the receiver does not provide a PPS signal unless you are calling
    the entire gps device a receiver, which contains three separate devices, >>>> i.e a radio receiver, a time standard (PPS) generator, and a NMEA
    sentence generator.

    I said gps receiver module, which most familiar with the technology
    would take to mean the sort of thing you can buy for a few $ on Ebay,
    but I guess with have to make allowances. So, enlighten us, just
    how do the pps and nmea sentances appear on output pins ?. Some
    sort of black magic perhaps ?...

    Your question is answered at some length in another post.

    I am not going to repost it just for you.

    This is a technical discussion group, not a marketing group, and as such
    precision in language and the lack of arm waving matters.

    The phrase "gps receiver module" is ambiguous in a discussion of GPS
    technology in 2021 absent a definition of what you mean.


    You talk about arm waving, but the fact is, you don't know, don't
    understand and are too lazy to make the effort to find out...

    Your questions are answered at some length in another post.

    Go look it up.

    I am not going to repost it just for you nor is it my job to alleviate
    your abysmal ignorance or tutor you in technical writting.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Ted Heise@21:1/5 to Terje Mathisen on Thu Aug 5 17:17:52 2021
    On Thu, 5 Aug 2021 17:50:16 +0200,
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    Jim Pennino wrote:
    David Woolley <david@ex.djwhome.demon.invalid> wrote: So, in
    what today we call a gps, there are at least three separate
    devices, a radio receiver to obtain the the GPS data, a device
    to generate PPS, and a device to convert GPS data to NMEA
    sentences.

    Except that in a modern chipset as used in a cell phone, all of
    those functions, plus wifi and possibly even more, is a single
    chip.

    BTW, NMEA stands for National Marine Electronics Association.
    Guess why commercial GPS devices output data in a marine
    standard format.

    In circa 1996 those three devices would likely be in three 19
    inch rack mount boxes containing mostly discrete components.

    Your timing is off by a substantial number of years: Garmin
    sold (portable) GPSs for $105M already in 1995, I have track
    logs which are older than this.

    https://en.wikipedia.org/wiki/Garmin#Handheld_GPS

    I for one have been fascinated by this discussion. I ran my own
    linux server (Slackware) for the better part of two decades, and
    spent quite a lot of time getting ntp up and running to my
    satisfaction.

    The Garmin page reminds me I have an old etrex Vista HCx sitting
    in a closet at home. I don't suppose there's any way to hack it
    into use as a GPS clock? Guessing it may not even generate a PPS
    signal, let alone have any way to get it out of the unit.

    It was a terrific device for its time. It rode on the handlebars
    of my bike for tracking speed, mileage, and routes.

    --
    Ted Heise <theise@panix.com> West Lafayette, IN, USA

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Terje Mathisen@21:1/5 to Jim Pennino on Thu Aug 5 20:37:37 2021
    Jim Pennino wrote:
    Ted Heise <theise@panix.com> wrote:
    On Thu, 5 Aug 2021 17:50:16 +0200,
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    Jim Pennino wrote:
    David Woolley <david@ex.djwhome.demon.invalid> wrote: So, in
    what today we call a gps, there are at least three separate
    devices, a radio receiver to obtain the the GPS data, a device
    to generate PPS, and a device to convert GPS data to NMEA
    sentences.

    Except that in a modern chipset as used in a cell phone, all of
    those functions, plus wifi and possibly even more, is a single
    chip.

    BTW, NMEA stands for National Marine Electronics Association.
    Guess why commercial GPS devices output data in a marine
    standard format.

    In circa 1996 those three devices would likely be in three 19
    inch rack mount boxes containing mostly discrete components.

    Your timing is off by a substantial number of years: Garmin
    sold (portable) GPSs for $105M already in 1995, I have track
    logs which are older than this.

    https://en.wikipedia.org/wiki/Garmin#Handheld_GPS

    I for one have been fascinated by this discussion. I ran my own
    linux server (Slackware) for the better part of two decades, and
    spent quite a lot of time getting ntp up and running to my
    satisfaction.

    The Garmin page reminds me I have an old etrex Vista HCx sitting
    in a closet at home. I don't suppose there's any way to hack it
    into use as a GPS clock? Guessing it may not even generate a PPS
    signal, let alone have any way to get it out of the unit.

    It was a terrific device for its time. It rode on the handlebars
    of my bike for tracking speed, mileage, and routes.

    I doubt it even has a PPS signal anywhere as a general purpose
    navigation device would have no need for it. If it outputs serial NMEA sentences, which I would doubt, you could use it without PPS assuming
    that an NTP accuracy in the millseconds is good enough for you.

    The etrex was a late relative to the Garmin GPS II, II+, III etc, the
    very first devices Garmin made used a two -channel receiver which they
    had to multiplex across the tracked channels, but then they very early
    made their own 12-channel chipset which was used all over the their many offerings.

    One of those was the model 18 (afair), a puck antenna/receiver which had
    a serial interface, and which included a PPS signal (although at TTL
    levels, but that usually worked as is, otherwise the needed RS232
    buffering chip was dirt cheap to add.

    I used both this and the Motorola Oncore UT+ as the sole internal
    reference for a multi-national corporation with 70-80K employees and
    offices and/or factories in 130 countries.


    Assuming you want to use something Linux PC based, then your options
    are for minimal investment:

    Finding something old on ebay or in a surplus store.

    A DYI project using inexpensive board sets. This will cost in the $50
    range and requires soldering, building cables, etc.

    Right, except it is in fact easy to get even lower these days.

    A Commercial Off The Shelf device you can just plug in. The cheapest
    COTS devices I have found that provide both NMEA sentences and PPS are
    about $180 new on ebay. They also contain a disciplined oven crystal

    Almost certainly not: OCXOs were almost completely replaced by TCXOs due
    to both faster startup times and much lower power usage, while getting
    more or less exactly the same performance.

    Have this changed back over the last 5+ years?

    oscillator with both 10 MHz and 1 PPS singnals on BNC connectors. These
    are handy if you also do RF or test equipment stuff.

    There does not seem to be any current market for simple GPS receiver
    devices with a serial output and PPS. There is a huge market for USB
    GPS, actually GNSS, devices and if NTP accuracy in the millseconds is
    good enough for you, they cost about $15 on amazon. Look for the VK-162 G-Mouse available from several vendors.

    If you have a SBC such as a Arduino or Raspberry Pi, you have LOTS of
    cheap options for building a NTP server.

    And finally, if you have more money than common sense and want to be the
    envy of your geek friends, you can get a new rubidium standard box on ebay for about $800 complete with NMEA and PPS on a DB-9 connector and 10 MHz
    and PPS on BNC's.

    What's funny is that you can in fact do far better even using USB, if
    you use the same type of protocol as some of the early (non-GPS)
    reference clocks did, i.e. a two-way protocol where the computer would
    tell the reference clock what it thought the current time was, while the receiver measured the round-trip delay, and then sent back a timestamp
    adjusted to be as close as possible when the computer read it.

    On RS232 this allowed sub-ms, with USB3 speeds you should be able to get
    into the low microseconds range.

    Terje

    --
    - <Terje.Mathisen at tmsw.no>
    "almost all programming can be viewed as an exercise in caching"

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to Ted Heise on Thu Aug 5 11:05:08 2021
    Ted Heise <theise@panix.com> wrote:
    On Thu, 5 Aug 2021 17:50:16 +0200,
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    Jim Pennino wrote:
    David Woolley <david@ex.djwhome.demon.invalid> wrote: So, in
    what today we call a gps, there are at least three separate
    devices, a radio receiver to obtain the the GPS data, a device
    to generate PPS, and a device to convert GPS data to NMEA
    sentences.

    Except that in a modern chipset as used in a cell phone, all of
    those functions, plus wifi and possibly even more, is a single
    chip.

    BTW, NMEA stands for National Marine Electronics Association.
    Guess why commercial GPS devices output data in a marine
    standard format.

    In circa 1996 those three devices would likely be in three 19
    inch rack mount boxes containing mostly discrete components.

    Your timing is off by a substantial number of years: Garmin
    sold (portable) GPSs for $105M already in 1995, I have track
    logs which are older than this.

    https://en.wikipedia.org/wiki/Garmin#Handheld_GPS

    I for one have been fascinated by this discussion. I ran my own
    linux server (Slackware) for the better part of two decades, and
    spent quite a lot of time getting ntp up and running to my
    satisfaction.

    The Garmin page reminds me I have an old etrex Vista HCx sitting
    in a closet at home. I don't suppose there's any way to hack it
    into use as a GPS clock? Guessing it may not even generate a PPS
    signal, let alone have any way to get it out of the unit.

    It was a terrific device for its time. It rode on the handlebars
    of my bike for tracking speed, mileage, and routes.

    I doubt it even has a PPS signal anywhere as a general purpose
    navigation device would have no need for it. If it outputs serial NMEA sentences, which I would doubt, you could use it without PPS assuming
    that an NTP accuracy in the millseconds is good enough for you.

    Assuming you want to use something Linux PC based, then your options
    are for minimal investment:

    Finding something old on ebay or in a surplus store.

    A DYI project using inexpensive board sets. This will cost in the $50
    range and requires soldering, building cables, etc.

    A Commercial Off The Shelf device you can just plug in. The cheapest
    COTS devices I have found that provide both NMEA sentences and PPS are
    about $180 new on ebay. They also contain a disciplined oven crystal
    oscillator with both 10 MHz and 1 PPS singnals on BNC connectors. These
    are handy if you also do RF or test equipment stuff.

    There does not seem to be any current market for simple GPS receiver
    devices with a serial output and PPS. There is a huge market for USB
    GPS, actually GNSS, devices and if NTP accuracy in the millseconds is
    good enough for you, they cost about $15 on amazon. Look for the VK-162
    G-Mouse available from several vendors.

    If you have a SBC such as a Arduino or Raspberry Pi, you have LOTS of
    cheap options for building a NTP server.

    And finally, if you have more money than common sense and want to be the
    envy of your geek friends, you can get a new rubidium standard box on ebay
    for about $800 complete with NMEA and PPS on a DB-9 connector and 10 MHz
    and PPS on BNC's.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jim Pennino@21:1/5 to Terje Mathisen on Thu Aug 5 12:22:33 2021
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    Jim Pennino wrote:
    Ted Heise <theise@panix.com> wrote:
    On Thu, 5 Aug 2021 17:50:16 +0200,
    Terje Mathisen <terje.mathisen@tmsw.no> wrote:
    Jim Pennino wrote:
    David Woolley <david@ex.djwhome.demon.invalid> wrote: So, in
    what today we call a gps, there are at least three separate
    devices, a radio receiver to obtain the the GPS data, a device
    to generate PPS, and a device to convert GPS data to NMEA
    sentences.

    Except that in a modern chipset as used in a cell phone, all of
    those functions, plus wifi and possibly even more, is a single
    chip.

    BTW, NMEA stands for National Marine Electronics Association.
    Guess why commercial GPS devices output data in a marine
    standard format.

    In circa 1996 those three devices would likely be in three 19
    inch rack mount boxes containing mostly discrete components.

    Your timing is off by a substantial number of years: Garmin
    sold (portable) GPSs for $105M already in 1995, I have track
    logs which are older than this.

    https://en.wikipedia.org/wiki/Garmin#Handheld_GPS

    I for one have been fascinated by this discussion. I ran my own
    linux server (Slackware) for the better part of two decades, and
    spent quite a lot of time getting ntp up and running to my
    satisfaction.

    The Garmin page reminds me I have an old etrex Vista HCx sitting
    in a closet at home. I don't suppose there's any way to hack it
    into use as a GPS clock? Guessing it may not even generate a PPS
    signal, let alone have any way to get it out of the unit.

    It was a terrific device for its time. It rode on the handlebars
    of my bike for tracking speed, mileage, and routes.

    I doubt it even has a PPS signal anywhere as a general purpose
    navigation device would have no need for it. If it outputs serial NMEA
    sentences, which I would doubt, you could use it without PPS assuming
    that an NTP accuracy in the millseconds is good enough for you.

    The etrex was a late relative to the Garmin GPS II, II+, III etc, the
    very first devices Garmin made used a two -channel receiver which they
    had to multiplex across the tracked channels, but then they very early
    made their own 12-channel chipset which was used all over the their many offerings.

    One of those was the model 18 (afair), a puck antenna/receiver which had
    a serial interface, and which included a PPS signal (although at TTL
    levels, but that usually worked as is, otherwise the needed RS232
    buffering chip was dirt cheap to add.

    I used both this and the Motorola Oncore UT+ as the sole internal
    reference for a multi-national corporation with 70-80K employees and
    offices and/or factories in 130 countries.

    The 18 series is still alive, updated, and targeted for mostly niche
    markets, such as aviation.

    Assuming you want to use something Linux PC based, then your options
    are for minimal investment:

    Finding something old on ebay or in a surplus store.

    A DYI project using inexpensive board sets. This will cost in the $50
    range and requires soldering, building cables, etc.

    Right, except it is in fact easy to get even lower these days.

    That depends on how good a shopper you are and how big your junk box of miscellaneous stuff is as just a DB-9 connector costs about $10 on
    mouser. Given the size of my junk box I could probably do it for about
    $10, but not everyone has decades of stuffed stached in their garage.


    A Commercial Off The Shelf device you can just plug in. The cheapest
    COTS devices I have found that provide both NMEA sentences and PPS are
    about $180 new on ebay. They also contain a disciplined oven crystal

    Almost certainly not: OCXOs were almost completely replaced by TCXOs due
    to both faster startup times and much lower power usage, while getting
    more or less exactly the same performance.

    Have this changed back over the last 5+ years?

    You bet it has.

    Go on ebay and search for GNSSDO GNSS Disciplined Oscillator.

    Do that search again and add rubidium to the search.

    It appears someone is making a general purpose circuit board where the
    final assembler adds their oscillator module of choice and boxes the
    whole thing up. It all may be one company, but who knows?

    BTW, the price I quoted includes the shipping costs from China to the
    USA and the specified settling time is 24 hours for full accuracy, which
    is not an issue for something you will run 24/7.


    oscillator with both 10 MHz and 1 PPS singnals on BNC connectors. These
    are handy if you also do RF or test equipment stuff.

    There does not seem to be any current market for simple GPS receiver
    devices with a serial output and PPS. There is a huge market for USB
    GPS, actually GNSS, devices and if NTP accuracy in the millseconds is
    good enough for you, they cost about $15 on amazon. Look for the VK-162
    G-Mouse available from several vendors.

    If you have a SBC such as a Arduino or Raspberry Pi, you have LOTS of
    cheap options for building a NTP server.

    And finally, if you have more money than common sense and want to be the
    envy of your geek friends, you can get a new rubidium standard box on ebay >> for about $800 complete with NMEA and PPS on a DB-9 connector and 10 MHz
    and PPS on BNC's.

    What's funny is that you can in fact do far better even using USB, if
    you use the same type of protocol as some of the early (non-GPS)
    reference clocks did, i.e. a two-way protocol where the computer would
    tell the reference clock what it thought the current time was, while the receiver measured the round-trip delay, and then sent back a timestamp adjusted to be as close as possible when the computer read it.

    The only problem with that is that there is no such USB device that I
    know of.

    On RS232 this allowed sub-ms, with USB3 speeds you should be able to get
    into the low microseconds range.

    The only problem with that is that there are currently no USB 3 GPS devices
    at all that I know of.

    Since USB 3 has more than a 4 wire interface, it should be possible to
    have a USB 3 GNSS device with a real PPS, but again, no such device yet.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)