[evlatests] Consequence of IAT clock error

[Jim Jackson]

In the current setup, we are essentially relying on two pieces of 
hardware (the EVLA L350 and the VLA IAT clock) that 1) must be 
manually synchronized with each other and/or the GPS clock and 2) 
don't do a good job monitoring that they are actually synchronized.

An updated L350 Central Reference Generator module is being worked on 
that will replace the L350 that has been in the EVLA system for at 
least three years.  This new module will receive as it's references 
5MHz from the MASER, 1PPS from the GPS receiver and Time from the NTP 
time server. It will provide the timing for the VLA correlator that 
is currently provided by the IAT clock in the MODCOMP rack. The MIB 
in the new L350 will also issue an alarm if it senses that the timing 
logic in the module has lost sync with the GPS 1PPS.  This should 
eliminate the situation that occurred over the weekend. I hope this 
will be in place sometime in the next couple of months.

I am also thinking that it may be wise to add a MIB somewhere in the 
system, that directly reads time and 1PPS from a separate, stand 
alone GPS receiver, compares it to what it believes is time from the 
NTP server and 1PPS from the L350, then complains very LOUDLY if 
either doesn't agree to within some close tolerance - maybe a couple 
of milliseconds. This would be fairly inexpensive and simple to do, 
requiring only a MIB and one of the existing stand alone GPS 
receivers.  It could potentially save quite a bit of observing time 
if something like this goes undetected again.

Jim

At 09:43 AM 1/8/2008, Claire Chandler wrote:
>Are there tests that should be done during start up that could check for
>this in the future?
>
>Claire
>
>On Tue, 8 Jan 2008, Rick Perley wrote:
>
> >    The clock error which was found and corrected yesterday appears to
> > have resulted in the following:
> >
> >    a) A loss of ~ 25% in sensitivity on EVLA to VLA baselines
> >    b) Closure errors of up to 100% on EVLA to EVLA baselines.
> >
> >    Hence, data taken from the time the clock error began (probably
> > Thursday during maintenance time -- but this has yet to be established)
> > until its correction (during software time yesterday) are severely
> > compromised.  Users should flag their EVLA to EVLA baselines.  EVLA to
> > VLA baselines do not show any closure problems, but are reduced in
> > sensitivity.  VLA to VLA baselines are unaffected.
> >
> >    I believe that the new 'L350 1PPS' device, soon to be implemented,
> > should eliminate this kind of mis-timing.  Testers should note that by
> > far the easiest way to detect this problem is to set the closure report
> > level (within CALIB) at 50% or so.  (I had discontinued looking at
> > closure myself because of the large number of moderate level (10 -- 20%)
> > errors from the bandpass mismatch problem was cluttering up the screens).
> > _______________________________________________
> > evlatests mailing list
> > evlatests at listmgr.cv.nrao.edu
> > http://listmgr.cv.nrao.edu/mailman/listinfo/evlatests
> >
>_______________________________________________
>evlatests mailing list
>evlatests at listmgr.cv.nrao.edu
>http://listmgr.cv.nrao.edu/mailman/listinfo/evlatests