PPS on Linux status? - NTP

This is a discussion on PPS on Linux status? - NTP ; My apologies if I am beating a dead horse, but I've spent several hours today searching for a definite answer to the subject line question. The PPS part of the ntp documentation at one point refers to the PPSkit for ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: PPS on Linux status?

  1. PPS on Linux status?

    My apologies if I am beating a dead horse, but I've spent several hours
    today searching for a definite answer to the subject line question.

    The PPS part of the ntp documentation at one point refers to the PPSkit
    for Linux and at another point says "The FreeBSD, Linux and Solaris
    implementations can be used with the stock kernels provided with those
    systems;" about the ntp PPS driver.

    I understand that a full-scale PPS "system" in the kernel (and the PPS
    api) may not be needed to get ntp working with PPS (e.g. that seems to
    be the case for Solaris), but at least some level of support is probably
    required from the kernel (in the serial driver)? Does the stock Linux
    kernel (e.g. any recent 2.6 variant) support PPS or do I have to use an
    extension such as PPSkit to use a PPS signal on Linux for ntpd?

    I have a setup (server 127.127.20.0 GPS/PPS) for which on a FreeBSD
    machine, ntptime shows the PPSSIGNAL status bit, but not on Linux.

    Any help would be greatly appreciated.

    Thanks,
    Martin

  2. Re: PPS on Linux status?

    Marten,

    The full functionality for precision kernel and PPS is in Solaris,
    FreeBSD and Alpha Tru64 (kernel option). FreeBSD works best for me using
    the pps driver (kernel option), since no level converter is required and
    the DCD is not an issue.

    The PPSKit is specific to Linux and an API for it is in no other system
    known to me. The full API for the systems mentioned above is defined in
    RFC-2783.

    Martin Karsten wrote:

    > My apologies if I am beating a dead horse, but I've spent several hours
    > today searching for a definite answer to the subject line question.
    >
    > The PPS part of the ntp documentation at one point refers to the PPSkit
    > for Linux and at another point says "The FreeBSD, Linux and Solaris
    > implementations can be used with the stock kernels provided with those
    > systems;" about the ntp PPS driver.
    >
    > I understand that a full-scale PPS "system" in the kernel (and the PPS
    > api) may not be needed to get ntp working with PPS (e.g. that seems to
    > be the case for Solaris), but at least some level of support is probably
    > required from the kernel (in the serial driver)? Does the stock Linux
    > kernel (e.g. any recent 2.6 variant) support PPS or do I have to use an
    > extension such as PPSkit to use a PPS signal on Linux for ntpd?
    >
    > I have a setup (server 127.127.20.0 GPS/PPS) for which on a FreeBSD
    > machine, ntptime shows the PPSSIGNAL status bit, but not on Linux.
    >
    > Any help would be greatly appreciated.
    >
    > Thanks,
    > Martin


  3. Re: PPS on Linux status?

    Martin Karsten wrote:
    > My apologies if I am beating a dead horse, but I've spent several hours
    > today searching for a definite answer to the subject line question.
    >
    > The PPS part of the ntp documentation at one point refers to the PPSkit
    > for Linux and at another point says "The FreeBSD, Linux and Solaris
    > implementations can be used with the stock kernels provided with those
    > systems;" about the ntp PPS driver.
    >
    > I understand that a full-scale PPS "system" in the kernel (and the PPS
    > api) may not be needed to get ntp working with PPS (e.g. that seems to
    > be the case for Solaris), but at least some level of support is probably
    > required from the kernel (in the serial driver)? Does the stock Linux
    > kernel (e.g. any recent 2.6 variant) support PPS or do I have to use an
    > extension such as PPSkit to use a PPS signal on Linux for ntpd?
    >
    > I have a setup (server 127.127.20.0 GPS/PPS) for which on a FreeBSD
    > machine, ntptime shows the PPSSIGNAL status bit, but not on Linux.
    >
    > Any help would be greatly appreciated.
    >
    > Thanks,
    > Martin


    You have a FreeBSD reference system, so this should be easy. If your
    Linux boxes keep time almost as well as does the FreeBSD system--but not
    quite--then you're done. Otherwise, you have some work to do.

    AFAIK, stock Linux kernels do not support PPS. Whatever you're using
    with the NMEA driver (127.127.20.0), an `ntpq -p` should give you what
    you want. Check the offsets and see if they're typical of your GPS with
    PPS or without PPS. For my GPS (a Garmin GPS 18 LVC), the offsets are
    typically +/- 3-4 ms without PPS and +/- 0.010 ms with PPS. The `ntpdc
    -c kerninfo` command is quite handy, too, and will break down the flags
    to show how well your PPS is or is not being recognized.

    My take on the NMEA driver doc is this: If the OS supports PPSAPI, then
    the driver will use the PPS; otherwise, the driver will act like the PPS
    is not there.

    You can get PPSkit for Linux 2.4 kernels, and it works great. You can
    get an alpha version of PPSkit for early 2.6 kernels, and it does the
    job but with not so much finesse. For 2.6 kernels in general, you can
    hunt down LinuxPPS, which is pretty good.

    The ppssignal flag seems to be related to whether the kernel is using
    hardpps, as if you had this in your ntp.conf...

    server 127.127.20.0 flag3 1

    ....but absence of the ppssignal flag is no big deal. Just make sure
    that the overall accuracy is to your liking.

    Michael

  4. Re: PPS on Linux status?

    David (and also Michael),

    thanks very much for you responses! Yes, FreeBSD works like a charm.
    ;-) Just a quick follow-up, since I'm rather a software than a hardware
    person:

    Does the need for a level converter depend on the hardware or software
    in use? I.e. will Linux/i386 (with the patch set) or Solaris on Sparc or
    i386 generally require a level converter or work with a GPS clock out of
    the box? This assumes that the GPS receiver is connected via serial
    input. Or do GPS clocks already include this conversion these days?

    My FreeBSD setup involves an old integrated gadget that someone built
    for me many years ago and I don't know the details of PPS level conversion.

    Thanks again,
    Martin

    David L. Mills wrote:
    > Marten,
    >
    > The full functionality for precision kernel and PPS is in Solaris,
    > FreeBSD and Alpha Tru64 (kernel option). FreeBSD works best for me using
    > the pps driver (kernel option), since no level converter is required and
    > the DCD is not an issue.
    >
    > The PPSKit is specific to Linux and an API for it is in no other system
    > known to me. The full API for the systems mentioned above is defined in
    > RFC-2783.
    >
    > Martin Karsten wrote:
    >
    >> My apologies if I am beating a dead horse, but I've spent several hours
    >> today searching for a definite answer to the subject line question.
    >>
    >> The PPS part of the ntp documentation at one point refers to the PPSkit
    >> for Linux and at another point says "The FreeBSD, Linux and Solaris
    >> implementations can be used with the stock kernels provided with those
    >> systems;" about the ntp PPS driver.
    >>
    >> I understand that a full-scale PPS "system" in the kernel (and the PPS
    >> api) may not be needed to get ntp working with PPS (e.g. that seems to
    >> be the case for Solaris), but at least some level of support is probably
    >> required from the kernel (in the serial driver)? Does the stock Linux
    >> kernel (e.g. any recent 2.6 variant) support PPS or do I have to use an
    >> extension such as PPSkit to use a PPS signal on Linux for ntpd?
    >>
    >> I have a setup (server 127.127.20.0 GPS/PPS) for which on a FreeBSD
    >> machine, ntptime shows the PPSSIGNAL status bit, but not on Linux.
    >>
    >> Any help would be greatly appreciated.
    >>
    >> Thanks,
    >> Martin


  5. Re: PPS on Linux status?

    Martin,

    Martin Karsten wrote:
    > Does the need for a level converter depend on the hardware or software
    > in use? I.e. will Linux/i386 (with the patch set) or Solaris on Sparc or
    > i386 generally require a level converter or work with a GPS clock out of
    > the box? This assumes that the GPS receiver is connected via serial
    > input. Or do GPS clocks already include this conversion these days?


    In most cases the PPS signal is fed via a serial port which expects RS232
    voltage levels, i.e -3..-12 V for a logical "high" and +3..+12V for a
    logical "low" level.

    The reason for this is mostly historical. On-board logic levels used to be
    close to 0V for logical "low" and close to +5V for logical "high" signals.
    Those on-board signals were converted to RS232 levels using inverting
    driver chips, so you have negative voltages for a logical RS232 "high"
    level on the wire.

    Normally a PC's serial port expects RS232 levels as inputs, so the PPS pulse
    which if normally fed to the Carrier Detect (DCD) pin should also be RS232
    level.

    However, in practice the RS23 chips built into standard PCs accept also
    voltage levels in the range of 0..+5V as input levels.

    Anyway you should take care that the signal supplied to the pin has the
    correct polarity as expected by the NTP daemon, e.g. if you used an
    inverting level converter the leading edge of the original PPS signal
    becomes the trailing edge of the inverted/converted signal.

    This would result in a time offset which corresponds to the length of the
    PPS pulse. However, you can configure in ntp.conf whether the rising slope
    or the falling slope of the PPS signal is the on-time slope, so you can
    easily correct this, if necessary.

    BTW, some converter chips from 0..+5V to RS232 levels have a limited rise
    time of the output signal which introduces delays of up to a couple of
    microseconds. Converter boxes which are based on a fast operational
    amplifier (or other conventional technique) don't have that delay, so they
    are normally better suited for PPS conversion.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  6. Re: PPS on Linux status?

    In article <38doh4-vi2.ln1@gateway.py.meinberg.de>,
    Martin Burnicki wrote:

    > The reason for this is mostly historical. On-board logic levels used to be
    > close to 0V for logical "low" and close to +5V for logical "high" signals.


    Whilst it certainly is historical, I have doubts about this interpretation.

    In particular, it doesn't explain why control signals use positive logic.

    > Those on-board signals were converted to RS232 levels using inverting
    > driver chips,


    That's definitely wrong, as the standard pre-dates that level of logic
    integration. When it was developed, logic would have been ECL or DTL.
    ECL uses very low voltage differentials and DTL doesn't naturally produce
    the TTL 5 volts power supplies. At the low level (probably zero,
    at that time) of integration for DTL logic, the distinction between
    positive and negative logic would really depend on whether you wanted
    a NOR or a NAND function.

    > so you have negative voltages for a logical RS232 "high"
    > level on the wire.


    The 12 volts bipolar probably comes from using polarised relays with a 12
    volt (13.8V) standard coil voltage (12, 24 and 48 volts are standard lead
    acid battery configurations, with 48 still used for telephone systems).
    I suspect that the use of negative logic, for the data (but not the
    control signals), came about as a result of not wanting teletype motors
    to run when the connection is broken. With current loop teletypes,
    the idle state is with current flow and is the marking state. When 7
    bit an 8 bit teletype codes were developed, they arbitrarily chose mark
    to be binary one.

    The start of a current loop character is signalled by breaking the loop,
    which means that a disconnected cable produces a continuous start signal
    and the teletype motor keeps running, wearing out the machine. I suspect
    it was decided that the default state for RS232 should be that the control
    signals should be false and the teletype be stopped. That requires a logic
    low on the control signals correspond to a marking state on the data, and
    therefore requires the opposite polarity to that which produces a one in
    the character codes.

    > Normally a PC's serial port expects RS232 levels as inputs, so the PPS pulse
    > which if normally fed to the Carrier Detect (DCD) pin should also be RS232
    > level.


    Note that, as a control signal, DCD uses positive logic.

    > However, in practice the RS23 chips built into standard PCs accept also
    > voltage levels in the range of 0..+5V as input levels.


    This is actually a very old characteristic of RS232. It ensures that
    disconnected (0 volts) is treated as negative, so a false control signal
    and a marking data signal, which is the correct fail safe configuration.


  7. Re: PPS on Linux status?

    David,

    The original 1964 RS-232 specification for the Bell System 103A modem
    specified bipolar levels at least +-6 V. This was also the case for the
    201A, 202A and others. However, the Bell System 113A modem used 0 V for
    logic 0 and +6 V or logic 1. There has been mass confusion ever since;
    sometimes TTL levels work, sometimes not. It's easy to wire a couple of
    transistors to match TTL levels to bipolar.

    Dave

    Dave

    David Woolley wrote:

    > In article <38doh4-vi2.ln1@gateway.py.meinberg.de>,
    > Martin Burnicki wrote:
    >
    >
    >>The reason for this is mostly historical. On-board logic levels used to be
    >>close to 0V for logical "low" and close to +5V for logical "high" signals.

    >
    >
    > Whilst it certainly is historical, I have doubts about this interpretation.
    >
    > In particular, it doesn't explain why control signals use positive logic.
    >
    >
    >>Those on-board signals were converted to RS232 levels using inverting
    >>driver chips,

    >
    >
    > That's definitely wrong, as the standard pre-dates that level of logic
    > integration. When it was developed, logic would have been ECL or DTL.
    > ECL uses very low voltage differentials and DTL doesn't naturally produce
    > the TTL 5 volts power supplies. At the low level (probably zero,
    > at that time) of integration for DTL logic, the distinction between
    > positive and negative logic would really depend on whether you wanted
    > a NOR or a NAND function.
    >
    >
    >> so you have negative voltages for a logical RS232 "high"
    >>level on the wire.

    >
    >
    > The 12 volts bipolar probably comes from using polarised relays with a 12
    > volt (13.8V) standard coil voltage (12, 24 and 48 volts are standard lead
    > acid battery configurations, with 48 still used for telephone systems).
    > I suspect that the use of negative logic, for the data (but not the
    > control signals), came about as a result of not wanting teletype motors
    > to run when the connection is broken. With current loop teletypes,
    > the idle state is with current flow and is the marking state. When 7
    > bit an 8 bit teletype codes were developed, they arbitrarily chose mark
    > to be binary one.
    >
    > The start of a current loop character is signalled by breaking the loop,
    > which means that a disconnected cable produces a continuous start signal
    > and the teletype motor keeps running, wearing out the machine. I suspect
    > it was decided that the default state for RS232 should be that the control
    > signals should be false and the teletype be stopped. That requires a logic
    > low on the control signals correspond to a marking state on the data, and
    > therefore requires the opposite polarity to that which produces a one in
    > the character codes.
    >
    >
    >>Normally a PC's serial port expects RS232 levels as inputs, so the PPS pulse
    >>which if normally fed to the Carrier Detect (DCD) pin should also be RS232
    >>level.

    >
    >
    > Note that, as a control signal, DCD uses positive logic.
    >
    >
    >>However, in practice the RS23 chips built into standard PCs accept also
    >>voltage levels in the range of 0..+5V as input levels.

    >
    >
    > This is actually a very old characteristic of RS232. It ensures that
    > disconnected (0 volts) is treated as negative, so a false control signal
    > and a marking data signal, which is the correct fail safe configuration.
    >


  8. Re: PPS on Linux status?

    David Woolley wrote:
    > In article <38doh4-vi2.ln1@gateway.py.meinberg.de>,
    > Martin Burnicki wrote:
    >
    >> The reason for this is mostly historical. On-board logic levels used to
    >> be close to 0V for logical "low" and close to +5V for logical "high"
    >> signals.

    >
    > Whilst it certainly is historical, I have doubts about this
    > interpretation.


    Huh?

    > In particular, it doesn't explain why control signals use positive logic.


    What in you opinion is "positive logic"? Do you refer to the status bits in
    the UART's registers, which are set to "high" or "1" if a condition is
    true, or the voltage levels of the UART output pins which commonly used to
    have TTL levels, or the RS232 levels on the wire?

    For the logic circuits used in PCs a logic "high" corresponds to a high
    voltage levels, close to the supply voltage of the circuit, and a logic
    "low" level corresponds to a voltage level close to 0V.

    BTW, I _know_ real TTL levels are roughly 0V~0.8V for "low", and 2V~5V for
    "high", and CMOS logic uses different voltage levels, but let's just use 0V
    and 5V for simplicity here.

    On a RS232 wire, however, a logical "high" level corresponds to a negative
    voltage while a logical "low" level corresponds to a positive voltage. If
    you use a current loop interface rather than RS232, you have to check for
    current/no current rather than positive/negative voltage.

    So a certain signal which has positive voltage in the TTL world has a
    negative voltage on the RS232 wire at the same time, and thus talking about
    "positive logic" or "negative logic" just due to the voltage levels is at
    least confusing.

    >> Those on-board signals were converted to RS232 levels using inverting
    >> driver chips,

    >
    > That's definitely wrong, as the standard pre-dates that level of logic
    > integration. When it was developed, logic would have been ECL or DTL.
    > ECL uses very low voltage differentials and DTL doesn't naturally produce
    > the TTL 5 volts power supplies. At the low level (probably zero,
    > at that time) of integration for DTL logic, the distinction between
    > positive and negative logic would really depend on whether you wanted
    > a NOR or a NAND function.


    I know that all, but I didn't want to go back to the roots of digital
    circuits because I think it's not relevant to PCs and similar computers.

    [...]
    > Note that, as a control signal, DCD uses positive logic.


    If you look at the TxD/RxD lines then a "0" bit is transmitted as a positive
    RS232 voltage but 0V TTL level, while a "1" bit is transmitted as a
    negative RS232 voltage but a +5V TTL level. Is that called positive or
    negative logic?

    On the other hand, the "carrier detect" status is "true" if the RS232 signal
    level is positive, and thus the TTL signal level is 0, which normally means
    "false". So compared to the data lines the logic of the control line is
    indeed reversed. But is this positive or negative logic?

    >> However, in practice the RS23 chips built into standard PCs accept also
    >> voltage levels in the range of 0..+5V as input levels.

    >
    > This is actually a very old characteristic of RS232. It ensures that
    > disconnected (0 volts) is treated as negative, so a false control signal
    > and a marking data signal, which is the correct fail safe configuration.


    Anyway, this feature allows to feed a TTL level PPS signal to a DCD input,
    resulting in a status change that can be determined by the drivers. Care
    must be taken that the correct slope of that PPS signal is evaluated by the
    software.

    Which the "correct" slope is depends on several conditions: active TTL high
    or low generated by the device, or active RS232 high or low generated by
    the device, inverting (standard), non-inverting, or no drivers at all used
    for level shifting.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  9. Re: PPS on Linux status?

    Martin Karsten writes:

    > My apologies if I am beating a dead horse, but I've spent several hours
    > today searching for a definite answer to the subject line question.
    >
    > The PPS part of the ntp documentation at one point refers to the PPSkit
    > for Linux and at another point says "The FreeBSD, Linux and Solaris
    > implementations can be used with the stock kernels provided with those
    > systems;" about the ntp PPS driver.


    Just add the date of that quote...

    >
    > I understand that a full-scale PPS "system" in the kernel (and the PPS
    > api) may not be needed to get ntp working with PPS (e.g. that seems to
    > be the case for Solaris), but at least some level of support is probably
    > required from the kernel (in the serial driver)? Does the stock Linux
    > kernel (e.g. any recent 2.6 variant) support PPS or do I have to use an
    > extension such as PPSkit to use a PPS signal on Linux for ntpd?


    No, because nobody wrote the code.

    >
    > I have a setup (server 127.127.20.0 GPS/PPS) for which on a FreeBSD
    > machine, ntptime shows the PPSSIGNAL status bit, but not on Linux.


    Just use the last PPSkit for Linux kernel 2.4.

    >
    > Any help would be greatly appreciated.
    >
    > Thanks,
    > Martin


+ Reply to Thread