Re: Datum (Bancomm) GPS glitches

[Dirk Zimoch <dirk.zimoch@psi.ch>]

Hi Bill and Jeff,

if you don't have such a controller bit, you must do the following:
* read the slow register
* read the fast register
* read the slow register again
* repeat if slow register has changed

Dirk


Jeff Hill wrote:
> Bill,
>
> One possibility is a register synchronization glitch. If there are two registers
> that contain the time, one which is fast changing, and one that increments once
> each time the fast changing register rolls over, then if you read the fast
> register just before the rollover and the slow register just after rollover then
> you might see a discontinuity in time. The solution is usually to set a bit in
> the control register before reading the time that prevents register updates
> while you are reading them. Your manual for the board will probably have the
> details.
>
> Are you using a driver that plugs into drvTS.c so that the timestamps in the
> EPICS records are based on the Datum bc635VME?
>
> Jeff
>
>
> > -----Original Message-----
> > From: Bill Cruise [mailto:cruise@cfht.hawaii.edu]
> > Sent: Monday, July 28, 2003 7:07 PM
> > To: tech-talk@aps.anl.gov
> > Subject: Datum (Bancomm) GPS glitches
> >
> > Hi,
> >
> > We are using a Datum TymServ(tm) 2100 Network Time Server with GPS
> > receiver option to provide our observatory with stratum one NTP.
> >
> > In our IOC we have a Datum bc635VME Time and Frequency Processor.  This
> > is basically the same board which some other observatories use, only
> > most have GPS receiver options and ours gets the time from the 2100
> > by means of an IRIG connection.
> >
> > We use the receiver to directly read time from the internal registers
> > via the VME buss, using direct calls.  This is done from inside a
> > genSub record, and is the basic timing for our whole system.  We do not
> > use any "real" drivers, and do not use the timing capabilities of the
> > board.  We just read the time -- NOW.
> >
> > The problem is that we have seen some timing glitches of 1 second and
> > 10 seconds.  Last night there were four 1 second glitches.  The time
> > seems to be 1 second fast on one read, and then OK 0.050 seconds later.
> > This happens very rarely, and so far hasn't caused any real problems,
> > but the capability seems to be there.
> >
> > Has anyone else encountered any such glitches in reading time from a
> > Datum GPS?  If so, have you developed a solution?
> >
> > Thanks for any help,
> >
> > Bill
> >
> > --
> >
> > William L. Cruise                             cruise@cfht.hawaii.edu
> > Electronics System Supervisor                   FAX:    808 885-7288
> > Canada-France-Hawaii Telescope                  Voice:  808 885-3121
> > 65-1238 Mamalahoa Highway         http://www.cfht.hawaii.edu/~cruise
> > Kamuela, HI   96743


--
Dr. Dirk Zimoch
Swiss Light Source
Paul Scherrer Institut
Computing and Controls
phone +41 56 310 5182
fax   +41 56 310 4413