Issues with ACCORD Reference Clock Driver - NTP

This is a discussion on Issues with ACCORD Reference Clock Driver - NTP ; Hi Harlan Stenn, As per your suggestion I would have used the existing NMEA reference clock driver for Accord GPS Clock. But there are certain issues as listed below. 1. Accord GPS Clock spits out NMEA at 9600 baudrate 2. ...

+ Reply to Thread
Results 1 to 19 of 19

Thread: Issues with ACCORD Reference Clock Driver

  1. Issues with ACCORD Reference Clock Driver

    Hi Harlan Stenn,

    As per your suggestion I would have used the existing NMEA
    reference clock driver
    for Accord GPS Clock. But there are certain issues as listed below.

    1. Accord GPS Clock spits out NMEA at 9600 baudrate
    2. It has custom NMEA format for GPS (and the driver is
    intended to use this )
    3. It also spits out time and status messages in a proprietary
    binary format
    (not yet tested...but wll do )

    So instead of changing the clean NMEA driver to support the above,
    I still think its better
    to write and maintain a separate driver.

    Comments plz...
    Venu.

  2. Re: Issues with ACCORD Reference Clock Driver

    > As per your suggestion I would have used the existing NMEA
    > reference clock driver
    > for Accord GPS Clock. But there are certain issues as listed below.
    >
    > 1. Accord GPS Clock spits out NMEA at 9600 baudrate
    > 2. It has custom NMEA format for GPS (and the driver is
    > intended to use this )
    > 3. It also spits out time and status messages in a proprietary
    > binary format (not yet tested...but wll do )
    >
    > So instead of changing the clean NMEA driver to support the above,
    > I still think its better to write and maintain a separate driver.
    >
    > Comments plz...


    #1 above would require changing only 1 line of code from the base NMEA
    driver. I've often wondered why you can't pass the baud rate via the conf
    file. It makes more sense to me to have the software adjust for the GPS,
    rather than having to change the GPS (if possible) to accommodate the
    software.

    #2 above, depending on the format, could require as little as only 1 or 2
    lines of code to be changed / added. At the very worst you might have to
    modify the small chunk of code that searches for the time code in the
    string, still a very minor modification.

    #3 above - Is there any advantage to using the binary format? Is there any
    information that NTP can use that would justify the additional code?

    I've never heard of Accord until you started posting asking questions about
    a driver. Excluding their website, there seems to be no other information on
    the Internet about them (or people using them). I wouldn't exactly call it a
    'high profile' product.

  3. Re: Issues with ACCORD Reference Clock Driver

    Venu,

    My opinion is, as before, that you should modify the stock NMEA driver.

    The NMEA driver uses 3 mode bits. I think more are available.

    The docs say that flag1 is unused for the NMEA driver.

    You could also see if the initial stock probes return valid data, and if not
    switch to the baud rate you need for your clock and try it that way instead
    (which would obviate the need for any flag bits).

    And now that we are rolling out the new config parser there is the
    possibility for a new config file format that will include the baud rate.

    H
    --
    http://ntpforum.isc.org - be a member!

  4. Re: Issues with ACCORD Reference Clock Driver

    Hi Jason,
    I agree with you to some extent(#1, #2).
    I am trying to accomodate the changes in the NMEA driver itself.

    Binary format was designed to send GPS time and position data to
    another PCI card.
    I cannot tell you the whole story but the binary format has GPS
    time, sync status and
    position. Unfortunately the time message doesnt contain sync
    status ! Hence both the
    messages need to be checked.

    Currently I'm out of station and busy. I shall post the details
    of the format very soon.

    Accord is the only Indian company manufacturing GPS Clocks. It may
    not be as popular
    as Garmin or TrueTime in the international market. But we are
    using them and they work
    fine too.

    Venu.


    On 12/2/07, Jason Rabel wrote:
    > > As per your suggestion I would have used the existing NMEA
    > > reference clock driver
    > > for Accord GPS Clock. But there are certain issues as listed below.
    > >
    > > 1. Accord GPS Clock spits out NMEA at 9600 baudrate
    > > 2. It has custom NMEA format for GPS (and the driver is
    > > intended to use this )
    > > 3. It also spits out time and status messages in a proprietary
    > > binary format (not yet tested...but wll do )
    > >
    > > So instead of changing the clean NMEA driver to support the above,
    > > I still think its better to write and maintain a separate driver.
    > >
    > > Comments plz...

    >
    > #1 above would require changing only 1 line of code from the base NMEA
    > driver. I've often wondered why you can't pass the baud rate via the conf
    > file. It makes more sense to me to have the software adjust for the GPS,
    > rather than having to change the GPS (if possible) to accommodate the
    > software.
    >
    > #2 above, depending on the format, could require as little as only 1 or 2
    > lines of code to be changed / added. At the very worst you might have to
    > modify the small chunk of code that searches for the time code in the
    > string, still a very minor modification.
    >
    > #3 above - Is there any advantage to using the binary format? Is there any
    > information that NTP can use that would justify the additional code?
    >
    > I've never heard of Accord until you started posting asking questions about
    > a driver. Excluding their website, there seems to be no other information on
    > the Internet about them (or people using them). I wouldn't exactly call it a
    > 'high profile' product.
    >
    >


  5. Re: Issues with ACCORD Reference Clock Driver

    >The NMEA driver uses 3 mode bits. I think more are available.
    >The docs say that flag1 is unused for the NMEA driver.


    It would be really nice if there was a clean way to specify the
    baud rate.

    Several of the NMEA units I'm familiar with allow you to set
    the baud rate they use. I expect there are times when it would
    be nice to run faster than 4800.


    >You could also see if the initial stock probes return valid data, and if not
    >switch to the baud rate you need for your clock and try it that way instead
    >(which would obviate the need for any flag bits).


    Do you want to maintain that sort of code? Let's not go there.


    >And now that we are rolling out the new config parser there is the
    >possibility for a new config file format that will include the baud rate.


    That would be great. Are there any examples of adding an option to
    the server line?

    --
    These are my opinions, not necessarily my employer's. I hate spam.


  6. Re: Issues with ACCORD Reference Clock Driver

    Hal Murray wrote:
    >> The NMEA driver uses 3 mode bits. I think more are available.
    >> The docs say that flag1 is unused for the NMEA driver.

    >
    > It would be really nice if there was a clean way to specify the
    > baud rate.


    This is a general issue -- there are other drivers (e.g. the HP 58503)
    that also assume a fixed baud rate and parity/stop bits. They cause a
    lot of problems when trying to use not-quite-identical hardware (as in
    using the Z3801A with the HP driver that assumes a different baud rate
    and parity). A way in the config file to cleanly specify comm
    parameters would be a real step forward.

    John

  7. Re: Issues with ACCORD Reference Clock Driver


    >> It would be really nice if there was a clean way to specify the
    >> baud rate.

    >
    >This is a general issue -- there are other drivers (e.g. the HP 58503)
    >that also assume a fixed baud rate and parity/stop bits. They cause a
    >lot of problems when trying to use not-quite-identical hardware (as in
    >using the Z3801A with the HP driver that assumes a different baud rate
    >and parity). A way in the config file to cleanly specify comm
    >parameters would be a real step forward.


    On the other hand, if there are only 2 variants (58503/3801)
    then I'd rather specify the variant and get all the line
    parameters together.

    The main problem with the NMEA driver is that the mode field
    is already in use.

    --
    These are my opinions, not necessarily my employer's. I hate spam.


  8. Re: Issues with ACCORD Reference Clock Driver

    Hal Murray wrote:
    >>> It would be really nice if there was a clean way to specify the
    >>> baud rate.

    >> This is a general issue -- there are other drivers (e.g. the HP 58503)
    >> that also assume a fixed baud rate and parity/stop bits. They cause a
    >> lot of problems when trying to use not-quite-identical hardware (as in
    >> using the Z3801A with the HP driver that assumes a different baud rate
    >> and parity). A way in the config file to cleanly specify comm
    >> parameters would be a real step forward.

    >
    > On the other hand, if there are only 2 variants (58503/3801)
    > then I'd rather specify the variant and get all the line
    > parameters together.
    >
    > The main problem with the NMEA driver is that the mode field
    > is already in use.
    >


    I don't know; it seems to me better for the refclock driver to specify a
    default set of comm parameters that will work for the "standard" device
    that refclock supports, but have a universal mechanism that would allow
    overriding those params from the config file and would work for any driver.

    John

  9. Re: Issues with ACCORD Reference Clock Driver

    Jason, et al,

    You might have noticed the mode subcommand in the refclock command. It
    uses the ttl member in the association data structure and is intended to
    pass stuff like bit rate, etc., to the base driver. If at all posible,
    it would be best if the driver could automatically select the baud rate
    based on unsolicited data from the radio. However, all radios known to
    me, except the NMEA radios, have selectable bit rates.

    Over the years and with some effort several drivers now support more
    than one device. All TrueTime models are supported by one driver; all
    Spectracom models by another and all telephone modem services by a
    third. With few exceptions, a NMEA radio is a NMEA radio and I strongly
    suspect many of those drivers could be combined in one driver.

    You don't appreciate how tedious the support process is when some
    important thing or other requires a minute change in the common
    interface (nanoseconds unstead of microseconds) and modifications to 46
    files. The urge for utmost KISS and fewest driver files in the public
    distribution is very strong. The problem is that the distribution build
    process is so intricate that few refclock builders, including me, can
    figure out how to incorporate a new driver in a private distribution
    other than as a cuckoo of a current one.

    Dave

    Jason Rabel wrote:
    >>As per your suggestion I would have used the existing NMEA
    >>reference clock driver
    >>for Accord GPS Clock. But there are certain issues as listed below.
    >>
    >> 1. Accord GPS Clock spits out NMEA at 9600 baudrate
    >> 2. It has custom NMEA format for GPS (and the driver is
    >>intended to use this )
    >> 3. It also spits out time and status messages in a proprietary
    >>binary format (not yet tested...but wll do )
    >>
    >> So instead of changing the clean NMEA driver to support the above,
    >> I still think its better to write and maintain a separate driver.
    >>
    >> Comments plz...

    >
    >
    > #1 above would require changing only 1 line of code from the base NMEA
    > driver. I've often wondered why you can't pass the baud rate via the conf
    > file. It makes more sense to me to have the software adjust for the GPS,
    > rather than having to change the GPS (if possible) to accommodate the
    > software.
    >
    > #2 above, depending on the format, could require as little as only 1 or 2
    > lines of code to be changed / added. At the very worst you might have to
    > modify the small chunk of code that searches for the time code in the
    > string, still a very minor modification.
    >
    > #3 above - Is there any advantage to using the binary format? Is there any
    > information that NTP can use that would justify the additional code?
    >
    > I've never heard of Accord until you started posting asking questions about
    > a driver. Excluding their website, there seems to be no other information on
    > the Internet about them (or people using them). I wouldn't exactly call it a
    > 'high profile' product.


  10. Re: Issues with ACCORD Reference Clock Driver

    Hal,

    You raise a frustrating issue. It would be easy to add all kinds of
    things to the server line; however, the mobilization routine has a fixed
    format consistent with the ntpdc association managment code. Presumably,
    the new ntpq can do many things using existing configuration file
    commands, so changing the format might not matter. However, attempts to
    withdraw ntpdc have met with nasty howls of pain for one reason or another.

    Perhaps the best way is to add a completely new command "refclock" and
    load it up with all kinds of options, including those now done by the
    fudge command. The command would not need the dotted quad, which could
    be replaced by the driver name already in a table. The syntax could in
    principle be different for each name, as determined by the parser. That
    could be a nice summer project.

    Dave

    Hal Murray wrote:

    >>The NMEA driver uses 3 mode bits. I think more are available.
    >>The docs say that flag1 is unused for the NMEA driver.

    >
    >
    > It would be really nice if there was a clean way to specify the
    > baud rate.
    >
    > Several of the NMEA units I'm familiar with allow you to set
    > the baud rate they use. I expect there are times when it would
    > be nice to run faster than 4800.
    >
    >
    >
    >>You could also see if the initial stock probes return valid data, and if not
    >>switch to the baud rate you need for your clock and try it that way instead
    >>(which would obviate the need for any flag bits).

    >
    >
    > Do you want to maintain that sort of code? Let's not go there.
    >
    >
    >
    >>And now that we are rolling out the new config parser there is the
    >>possibility for a new config file format that will include the baud rate.

    >
    >
    > That would be great. Are there any examples of adding an option to
    > the server line?
    >


  11. Re: Issues with ACCORD Reference Clock Driver

    >>> In article , "David L. Mills" writes:

    David> ... The urge for utmost KISS and fewest driver files in the
    David> public distribution is very strong. The problem is that the
    David> distribution build process is so intricate that few refclock
    David> builders, including me, can figure out how to incorporate a new
    David> driver in a private distribution other than as a cuckoo of a current
    David> one.

    Dave,

    Red herring.

    You are one of the very few people who I have heard say this.

    I have received a number of new drivers from people who have never before
    piped up who send me new drivers that include:

    - adding the small handful of (pretty obvious and often replicated) lines to
    configure.ac
    - adding the code table entries that you clearly know how to do
    - adding the module name to the obvious line in ntpd/Makefile.am

    Forgive me, but I'm having a problem seeing how anybody could construe this
    as intricate.

    And for anybody who just feels they have better things to do than to figure
    this out, I have volunteered publicly and often that I'm happy to either do
    it for them or work with anybody to do these things.

    H
    --
    http://ntpforum.isc.org - be a member!


  12. Re: Issues with ACCORD Reference Clock Driver

    Harlan,

    Sorry, this is not true. It used to be that refclock contributors need
    only provide a driver file together with a couple of modifided tables.
    Now the submissions must include modified build scripts of arcane
    structure. Maybe you don't rememeber the ancient days.

    Dave

    Harlan Stenn wrote:
    >>>>In article , "David L. Mills" writes:

    >
    >
    > David> ... The urge for utmost KISS and fewest driver files in the
    > David> public distribution is very strong. The problem is that the
    > David> distribution build process is so intricate that few refclock
    > David> builders, including me, can figure out how to incorporate a new
    > David> driver in a private distribution other than as a cuckoo of a current
    > David> one.
    >
    > Dave,
    >
    > Red herring.
    >
    > You are one of the very few people who I have heard say this.
    >
    > I have received a number of new drivers from people who have never before
    > piped up who send me new drivers that include:
    >
    > - adding the small handful of (pretty obvious and often replicated) lines to
    > configure.ac
    > - adding the code table entries that you clearly know how to do
    > - adding the module name to the obvious line in ntpd/Makefile.am
    >
    > Forgive me, but I'm having a problem seeing how anybody could construe this
    > as intricate.
    >
    > And for anybody who just feels they have better things to do than to figure
    > this out, I have volunteered publicly and often that I'm happy to either do
    > it for them or work with anybody to do these things.
    >
    > H


  13. Re: Issues with ACCORD Reference Clock Driver

    > 1. Accord GPS Clock spits out NMEA at 9600 baudrate

    The NMEA specs call for 4800. Is there some way to set
    the Accord box to run at 4800? That seems only sensible
    if they are in the NMEA market.


    > 2. It has custom NMEA format for GPS (and the driver is
    > intended to use this )


    What sort of custom format is this? Why is it better than
    the normal NMEA formats? Is it enoug better to be worth
    all the trouble of "fixing" a driver?


    > 3. It also spits out time and status messages in a proprietary
    > binary format
    > (not yet tested...but wll do )


    Lots of NMEA devices also have a binary mode. Who cares if the
    NMEA mode works well enough. What does the binary mode tell
    you that the NMEA mode doesn't?


    --
    These are my opinions, not necessarily my employer's. I hate spam.


  14. Re: Issues with ACCORD Reference Clock Driver

    I
    >I don't know; it seems to me better for the refclock driver to specify a
    >default set of comm parameters that will work for the "standard" device
    >that refclock supports, but have a universal mechanism that would allow
    >overriding those params from the config file and would work for any driver.


    We are probably having a violent agreement.

    I'd like to be able to say "Z3801A" rather than whatever line
    settings it actually uses.

    I'd also like to be able to specify the raw line details in
    case I find a box that is close enough but uses some strange
    line settings. (The Z3801A is a good example. That was the
    only change it took.)

    --
    These are my opinions, not necessarily my employer's. I hate spam.


  15. Re: Issues with ACCORD Reference Clock Driver


    >Over the years and with some effort several drivers now support more
    >than one device. All TrueTime models are supported by one driver; all
    >Spectracom models by another and all telephone modem services by a
    >third. With few exceptions, a NMEA radio is a NMEA radio and I strongly
    >suspect many of those drivers could be combined in one driver.


    The NMEA driver already handles many more types of gizmos than
    most other drivers. I have 4 or 5 (and 2 more untested) within
    arms reach.


    >You don't appreciate how tedious the support process is when some
    >important thing or other requires a minute change in the common
    >interface (nanoseconds unstead of microseconds) and modifications to 46
    >files. The urge for utmost KISS and fewest driver files in the public
    >distribution is very strong. The problem is that the distribution build
    >process is so intricate that few refclock builders, including me, can
    >figure out how to incorporate a new driver in a private distribution
    >other than as a cuckoo of a current one.


    It would be neat to solve this mess. I'm not sure I have any
    great suggestions.

    Maybe there should be two classes of drivers. Class 1 drivers
    come with the official distribution. Class 2 get supported by
    some other mechanism. That might make sense if somebody was
    willing to keep track of driver numbers, or somebody figures
    out a way to do the linking without driver numbers. (The changes
    to clockstats and peerstats would be "interesting". Maybe
    replace the IP address with . or something like that.

    Or maybe the boundary could be fuzzy. You fixup the drivers you
    like and the rest of them are disabled until somebody fixes them
    up too. I'd be willing to do that for any driver I'm interested
    in. If you want to make a big change, you just shoot all the drivers
    you don't like. They are no-go until somebody rescues them.

    That way the distribution mechanism carries the "best" copy of a
    driver even if it doesn't compile/build right now.

    --
    These are my opinions, not necessarily my employer's. I hate spam.


  16. Re: Issues with ACCORD Reference Clock Driver

    Hal Murray wrote:
    > I
    >> I don't know; it seems to me better for the refclock driver to specify a
    >> default set of comm parameters that will work for the "standard" device
    >> that refclock supports, but have a universal mechanism that would allow
    >> overriding those params from the config file and would work for any driver.

    >
    > We are probably having a violent agreement.
    >
    > I'd like to be able to say "Z3801A" rather than whatever line
    > settings it actually uses.
    >
    > I'd also like to be able to specify the raw line details in
    > case I find a box that is close enough but uses some strange
    > line settings. (The Z3801A is a good example. That was the
    > only change it took.)
    >


    Yup, we're on the same page.

    John

  17. Re: Issues with ACCORD Reference Clock Driver

    >Perhaps the best way is to add a completely new command "refclock" and
    >load it up with all kinds of options, including those now done by the
    >fudge command. The command would not need the dotted quad, which could
    >be replaced by the driver name already in a table. The syntax could in
    >principle be different for each name, as determined by the parser. That
    >could be a nice summer project.


    I like the idea of a refclock command.

    Here is a possibly crazy way to implement something like that...

    In addition to the procedures that are currently supplied
    in the linkage block from each refclock to the system,
    add a string that is the tokens that this driver knows
    about.

    The parser handles the merge of all possible options,
    collecting the info in a struct that gets passed to open.
    It also complains about options that this driver doesn't
    support. Open copies what it wants out of that struct,
    ignoring the fields it doesn't support.

    You might need a way to distinguish between 0 and unspecified.
    -1 for unspecified probably works. Use 0 and 1 for booleans.
    The open code would have to check for the unspecified
    case rather than just checking for non-zero.

    It might be possible to use the same mechanism for ntpdc.
    I don't know if the same set of options makes sense. If
    not, it just takes a second string to specify what is OK
    for ntpdc.

    --
    These are my opinions, not necessarily my employer's. I hate spam.


  18. Re: Issues with ACCORD Reference Clock Driver

    >>> In article , hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:

    Hal> I'd like to be able to say "Z3801A" rather than whatever line settings
    Hal> it actually uses.

    I agree and suggest:

    http://support.ntp.org/bin/view/Dev/NewNtpConfFormat

    as I did in a previous reply on the parent thread.

    Hal> I'd also like to be able to specify the raw line details in case I find
    Hal> a box that is close enough but uses some strange line settings. (The
    Hal> Z3801A is a good example. That was the only change it took.)

    I've wanted this for a long time too:

    http://support.ntp.org/bin/view/Dev/...efclockDrivers

    where I talk about a lightweight "refclock processing language".

    H
    --
    http://ntpforum.isc.org - be a member!

  19. Re: Issues with ACCORD Reference Clock Driver

    Harlan,

    This has come up several times over the years (I give you the parse
    clocks as one approach). Here has been my reply on these occastions.

    Almost all reference clock derivers can be designed as a state machine
    which has largely been implemented in the reference clock interface.
    There is a state machine for received messages and another for
    transmitted messages. For most drivers this is rather simple with only
    silly details of polling and timeout remaining to be resolved. That took
    a good deal of development over several versions with a serious goal to
    keep it simple.

    What you might have in mind is the timecode interpretation. Once upon a
    time this was done in vastly different ways with lots of icky code. The
    reason for this was Dennis Fergusson's desire to use the code in an
    embedded system with no Unix library. Now the Unix library is in a
    wristwatch computer.

    Believing in Occam's Razon, I submit the ASCII timecode state machine of
    choice is the scanf() routine. The state machine program is simply the
    format string. Simple, fast and not too intrusive. I've never found an
    ASCII timecode that couldn't be easily parsed and error-checked this
    way. With the interface and these routines there isn't much else and
    what else would be hard to handle with a common state machine.

    Most drivers I have written use the read line/chunk routines in the
    interface, check line length, call scanf(), tease out the quality and
    leap bits and pass the data structure to the interface. Drivers are
    written so that several machines can share the received data while one
    of them polls the clock.

    For these reasons and long experience in crafting the interface and
    writing drivers, I don't think more is better.

    Dave

    Dave

    Harlan Stenn wrote:

    >>>>In article , hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:

    >
    >
    > Hal> I'd like to be able to say "Z3801A" rather than whatever line settings
    > Hal> it actually uses.
    >
    > I agree and suggest:
    >
    > http://support.ntp.org/bin/view/Dev/NewNtpConfFormat
    >
    > as I did in a previous reply on the parent thread.
    >
    > Hal> I'd also like to be able to specify the raw line details in case I find
    > Hal> a box that is close enough but uses some strange line settings. (The
    > Hal> Z3801A is a good example. That was the only change it took.)
    >
    > I've wanted this for a long time too:
    >
    > http://support.ntp.org/bin/view/Dev/...efclockDrivers
    >
    > where I talk about a lightweight "refclock processing language".
    >
    > H


+ Reply to Thread