Does anyone know if the bc637 PCI card (from Symmetricom/Datum/Bancomm) can be
used as a reference clock?

I am trying to use a bc637PCI-U GPS timing card as an NTP reference clock for a
local isolated network, but this version of the bc635 card is not listed in the
list of available clock drivers.

The card is installed in a Linux server (FC1/2.4 kernel) and accessed via a
standard device driver provided by the vendor.

http://www.symmttm.com/products_blt_bc637PCI-U.asp

Thanks,
Greg

-- 

Command and Control Technologies Corporation
1425 Chaffee Drive, Suite 1
Titusville, Florida 32780
TEL     321.264.1193 x108
FAX     321.383.5096
URL     www.cctcorp.com

Note that I am specifically looking for a refclock solution to support this
Symmetricom GPS PCI timing card on Linux (i.e. I already read the postings to
the 'Serial Port' thread from 4/15/2005).

Thanks,
Greg

Greg wrote:

>Does anyone know if the bc637 PCI card (from Symmetricom/Datum/Bancomm) can be
>used as a reference clock?
>
>I am trying to use a bc637PCI-U GPS timing card as an NTP reference clock for a
>local isolated network, but this version of the bc635 card is not listed in the
>list of available clock drivers.
>
>The card is installed in a Linux server (FC1/2.4 kernel) and accessed via a
>standard device driver provided by the vendor.
>
>http://www.symmttm.com/products_blt_bc637PCI-U.asp
>
>Thanks,
>Greg
>
>  
>
AFAIK it is not supported.  Another person, Ramanathan Palaniappan 
<ram@cs.wisc.edu>, has been trying to get one to work without success.  
As of the last time he posted here, his problems seemed as much due to 
cluelessness as to the lack of built in support for the device.  Try 
searching at http://www.groups.google.com using Ramanthan's name and 
comp.protocols.time.ntp as the group to search and you should be able to 
get the history on this.

The BC637PCI should make a fine reference clock if somebody writes an 
ntpd refclock driver for it.   Since TrueTime (now Symmetricomm) no 
longer makes or sells the device and availability is limited, I'm not 
sure it's worth doing.  If I had such a device and the Solaris software 
developers kit for it, I might be tempted.  I don't feel I can afford to 
buy one!

"Richard B. Gilbert" <rgilbert88@comcast.net> writes:

> Greg wrote:
> 
> >Does anyone know if the bc637 PCI card (from Symmetricom/Datum/Bancomm) can be
> >used as a reference clock?
> >
> >I am trying to use a bc637PCI-U GPS timing card as an NTP reference clock for a
> >local isolated network, but this version of the bc635 card is not listed in the
> >list of available clock drivers.
> >
> >The card is installed in a Linux server (FC1/2.4 kernel) and accessed via a
> >standard device driver provided by the vendor.
> >
> >http://www.symmttm.com/products_blt_bc637PCI-U.asp
> >
> >Thanks,
> >Greg
> >
> >
> AFAIK it is not supported.
> 
> The BC637PCI should make a fine reference clock if somebody writes an
> ntpd refclock driver for it.   Since TrueTime (now Symmetricomm) no
> longer makes or sells the device and availability is limited, 

I think the BC-line is Datum/Bancomm legacy. But 

        http://www.symmttm.com/products_bus_level_timing.asp

does indicate that the mentioned product is made/sold&available.

Anyway, lacking a dedicated driver. The card might be able to output
say PPS and be used with ATOM. Another alternativ since there is IRIG
output, that could be feed to the IRIG-audio driver.

--
        Bj�rn

Thanks, I did find quite a few 'related' postings, but it does seem that you are
correct and this particular PCI card is just not supported.

Note that the bc635/637PCI-U cards are 'new' Symmetricom versions of the legacy
Datum/Bancomm timing cards, while the GPS-PCI/PCI-SG are replacements for the
legacy TrueTime 560 cards. Although the old tt560 had refclock support at one
time, it is not clear if this also supported the old Datum/Bancomm PCI cards.

We do like the card, so unless someone else already did it (hello Symmetricom),
we'll probably go ahead and develop a Linux ntpd refclock driver for it. The
vendor sells a Linux SDK that seems to provide everything necessary to access
the device. They also seem to be actively marketing this new universal-PCI
version of the card so hopefully it will be around for awhile.

Greg wrote:
> Thanks, I did find quite a few 'related' postings, but it does seem
that you are
> correct and this particular PCI card is just not supported.
>
> Note that the bc635/637PCI-U cards are 'new' Symmetricom versions of
the legacy
> Datum/Bancomm timing cards, while the GPS-PCI/PCI-SG are replacements
for the
> legacy TrueTime 560 cards. Although the old tt560 had refclock
support at one
> time, it is not clear if this also supported the old Datum/Bancomm
PCI cards.
>
> We do like the card, so unless someone else already did it (hello
Symmetricom),
> we'll probably go ahead and develop a Linux ntpd refclock driver for
it. The
> vendor sells a Linux SDK that seems to provide everything necessary
to access
> the device. They also seem to be actively marketing this new
universal-PCI
> version of the card so hopefully it will be around for awhile.

I have this card feeding a lightly hacked refclock_bancomm.c, under
FreeBSD, and it seems to be doing a good job. I imagine it would be
simple to make it go under Linux. The refclock driver is probably not
in service; it won't compile as shipped.

I spent some time wandering thru refclock source, looking to see which
one might support that card, and came up empty. Being lazy, I decided
to modify the bancomm driver. The register format from the card is a
little different, but otherwise it was trivial.

If a lightly-hacked refclock_bancomm will work, please submit patches
that will use, say, an unused flags bit to say that the attached refclock is
either the bancomm or the bc637.

H

Thanks for the info. Based on your experience, it sounds like some simple mods
to refclock_bancomm.c will allow it to work with Symmetricom's standard Linux
device driver. I assumed it would be possible to adapt one of the existing
refclocks but have not looked into the details yet.

I agree that there seems to be enough interest in this card to put together some
patches and get them submitted somewhere. One would think Symmetricom would be
interested in tackling this effort.

Note that if the refclock_bancomm changes are not platform generic (i.e. across
Linux, FreeBSD, etc.) and/or cannot be identified by reading a register on the
card, then appropriate autoconf/automake options should be added to the build
(i.e. to at least specify the runtime configuration).


<hundoj@comcast.net> wrote in message
news:1114557819.086460.13520@z14g2000cwz.googlegroups.com...

>
> I have this card feeding a lightly hacked refclock_bancomm.c, under
> FreeBSD, and it seems to be doing a good job. I imagine it would be
> simple to make it go under Linux. The refclock driver is probably not
> in service; it won't compile as shipped.
>
> I spent some time wandering thru refclock source, looking to see which
> one might support that card, and came up empty. Being lazy, I decided
> to modify the bancomm driver. The register format from the card is a
> little different, but otherwise it was trivial.
>

I think I can do that.

I'll come up with something and get back to you someday soonish or so.
I'll see what I can do to keep the automake/conf stuff unchanged.

diffs or BitKeeper? I've seen both mentioned in various support pages,
not clear which is preferred.

> I think I can do that.

Great, thanks!

> I'll come up with something and get back to you someday soonish or so.
> I'll see what I can do to keep the automake/conf stuff unchanged.

Lemme know if I can help.

> diffs or BitKeeper? I've seen both mentioned in various support pages,
> not clear which is preferred.

YOur choice.  If your changes are limited to one file it won;t matter much
to either of us.

Thanks...

H

Harlan Stenn wrote:
> > I think I can do that.
>
> Great, thanks!
>
> > I'll come up with something and get back to you someday soonish or
so.
> > I'll see what I can do to keep the automake/conf stuff unchanged.
>
> Lemme know if I can help.
>
> > diffs or BitKeeper? I've seen both mentioned in various support
pages,
> > not clear which is preferred.
>
> YOur choice.  If your changes are limited to one file it won;t matter
much
> to either of us.
>
> Thanks...
>
> H
Hello Harlan,

Bug 421 opened in bugzilla, with the bk patch attached. I thrashed
about on the bk stuff some, but I think I got the file uploaded to the
ntp bk/ntp-dev repository as well.

Thanks a bunch Rob!

We need a maintainer for that refclock, as I recall.

H

Harlan Stenn wrote:
> Thanks a bunch Rob!
>
> We need a maintainer for that refclock, as I recall.
> 
> H

I can do that, sign me up.
Rob

Guys,

Can you make the case that the new driver is significantly different 
than the existing TT560 driver and that they cannot be combined as are 
the Spectracom and TrueTime family drivers?

Dave

Rob wrote:
> Harlan Stenn wrote:
> 
>>Thanks a bunch Rob!
>>
>>We need a maintainer for that refclock, as I recall.
>>
>>H
> 
> 
> I can do that, sign me up.
> Rob
> 

David L. Mills wrote:
> Guys,
>
> Can you make the case that the new driver is significantly different
> than the existing TT560 driver and that they cannot be combined as
are
> the Spectracom and TrueTime family drivers?
>
> Dave
>
>
Hello Dr. Mills,

I submitted updates to existing driver #16, but it looked moribund to
me.

I don't see differences between #16 and #41, TT560, that are so great
that they could not be merged. The result might be a little twisty, but
I think it looks manageable.

I could try putting them together, if that would be a Good Thing.

Rob,

Actually, the TPRO driver (12), Bancomm (16) and TT560 (41) drivers are 
very similar, since all they do at each poll event is suck up some 
registers, reformat as necessary, and let the refclock interface do the 
rest. I may have the last TPRO interface in the world and all my SBus 
machines have died, so probably driver 12 should be retired. Driver 16 
is in active use at the UNSO sites now. I don't know how many TT560 
boards there are out there; I have one and I suspect TrueTime sold a 
bunch of them now probably on EBay.

I think it only makes sense to combine the drivers if the result did not 
need to be told which device is connected other than perhaps to 
configure the device name and/or link. For the combined Spectracom, 
Truetime and ACTS drivers, you don't need to do anything except install 
the link.

In any case, I'm not thrilled about patching one driver to create 
another. That's what the original USNO driver did and that created 
problems. None of the driver sources now require any other sources other 
than header files and the common interface. So, if you believe combining 
your driver with the Bancomm driver is not practical, please consider to 
implement yours as a standalone driver.

Dave

Rob wrote:
> David L. Mills wrote:
> 
>>Guys,
>>
>>Can you make the case that the new driver is significantly different
>>than the existing TT560 driver and that they cannot be combined as
> 
> are
> 
>>the Spectracom and TrueTime family drivers?
>>
>>Dave
>>
>>
> 
> Hello Dr. Mills,
> 
> I submitted updates to existing driver #16, but it looked moribund to
> me.
> 
> I don't see differences between #16 and #41, TT560, that are so great
> that they could not be merged. The result might be a little twisty, but
> I think it looks manageable.
> 
> I could try putting them together, if that would be a Good Thing.
> 

David L. Mills wrote:
> Rob,
>
> Actually, the TPRO driver (12), Bancomm (16) and TT560 (41) drivers
are
> very similar, since all they do at each poll event is suck up some
> registers, reformat as necessary, and let the refclock interface do
the
> rest. I may have the last TPRO interface in the world and all my SBus

> machines have died, so probably driver 12 should be retired. Driver
16
> is in active use at the UNSO sites now. I don't know how many TT560
> boards there are out there; I have one and I suspect TrueTime sold a
> bunch of them now probably on EBay.
>
> I think it only makes sense to combine the drivers if the result did
not
> need to be told which device is connected other than perhaps to
> configure the device name and/or link. For the combined Spectracom,
> Truetime and ACTS drivers, you don't need to do anything except
install
> the link.
>
> In any case, I'm not thrilled about patching one driver to create
> another. That's what the original USNO driver did and that created
> problems. None of the driver sources now require any other sources
other
> than header files and the common interface. So, if you believe
combining
> your driver with the Bancomm driver is not practical, please consider
to
> implement yours as a standalone driver.
>
> Dave
>
Hello Dr. Mills,

If any of my postings led you to believe that I thought that my code
would be better off in a standalone driver, then I was unclear.

Symmetricom's version of the 635/637, which is what I want to add
support for, is only slightly different from the Bancomm 635. I thought
it would be more obviously supported by patching an existing driver,
rather than creating a new standalone driver.

If patching a driver in this fashion causes you distress, then I will
be happy to try to implement this support in whatever manner you
prefer.

I interpreted your question about the TT560 as a request to consider
combining it with #16. Apparently I erred. Sorry.

None of the updates I submitted require source or headers outside of
what currently exists in the distribution. The closed-source vendor
device driver for the new 635/637 on Linux & Windows is accessed via
named function calls, instead of ioctl, so I was forced to use that
interface. I believe that it does not encumber the code, from a F/OSS
viewpoint, but am certainly not expert in such matters. If making use
of such interfaces disturbs you I will remove it.

I want you to be satisfied with the modifications I propose, and am
willing to rework any of my updates to suit you. Please advise.

Regards, 
Rob