[evlatests] EVLA Tests July 12

Mark Claussen mclausse at nrao.edu
Wed Jul 13 12:37:25 EDT 2005


I wrote a summary of observing and then decided it was too
long for anyone to want to read, so I give this executive summary
before the gory details (maybe the summary is short enough to
read):
-----------------------------------------------------------------------------
Summary of EVLA tests July 12, 2005

1.  Problems with getting antennas to listen to script
2.  T304 problems on An 16, leading to abandoning 16 for 
     X band delays
3.  Modcomp delays program confused for An 14 at X, 
     used AIPS for display of narrow band/spectral line, to
     estimate delays by eye; changed 14A and 14C by 20ns
     at X.
4.  Switch to L, peak up delays on both antennas:  
     14A +20ns, 14C 0ns, 16A -80ns, 16C -150ns.  Fringe 
     amplitude down by x10 on 16 compared to 14 / VLA.  
     Phase jumps by +100d on 16 every 30 - 60s, after stable 
     phases for that long.
5.  Test L band file (to check phase stability at several 
      frequencies) did not have VLA and EVLA at same 
      frequencies at same time --- probably user error of some 
      sort; thus no fringes between VLA and EVLA, but fringes 
       among VLA or EVLA.
6.   After aborting evla script, antennas continued to get acu
      commands from script, unable to stow antennas until 
      executor killed; An 16 had some limits problem going to
      proper az after manual commands sent; was left at az 380.

Mark
--------------------------------------------------------------------------------------
Gory details follow

The plan for about 3.5 hours today (July 12) was to try to
track down the delay for An 16, adjust delays on 14, and
perhaps take some data to learn something about the phase
stability problem at L band.  But since Vivek and I are relative
novices at running EVLA antennas, this was perhaps a much
bigger bite than we would be able to chew.

Rob was at the VLA at the  beginning of these tests (about 1630
MDT); he cleared An 14 for testing, as the electricians had been
working on this antenna both Monday and today.  When we
fired up the ACU on both antennas, neither would take commands
to move.  An 16 actually just moved away on it's own and went 
into some limits. (Rob told us later that this behaviour had been 
seen before).  In any case, Rob went to both antennas; he reset
the acu mib on 14, and manually drove 16 out of the limits.  At
some time after this, with several attempts to have the antennas
listen to my script, they magically began tracking the source.

We had set up for X band in order to check delays.  We first turned 
our attention to setting the output attenuators in the T304
for An 16, since the sd in the T5 appeared to be low (the tp was low
as well).  Unfortunately the t304-a mib could not be contacted, and 
Rob had by that time left the site (we learned later from him that the
only way to fix this problem was to reset the power).   Changing the
t304-c attenuator seemed to have little effect on the total power or
the sd from the T5.   At this point, we decided to abandon An 16 for
the X-band tests.

We decided to try to peak up the delays on An 14 at X band.  The
modcomp delays program seemed to be pretty confused no matter
what we did (using different bandwidths).   Finally we decided to use
real-time FILLM in AIPS so we could plot the bandpasses and try
to estimate the delay changes by eye.  This worked pretty well but of
course is not an optimum method.  We peaked up the delays for An 14
by changing both IFs by +20ns.  Does the curvature (buttonhook) 
confuse the delays program ?  I wouldn't have thought so.

At this point we decided to switch to L band, check the delays, and 
move on to perhaps obtain some data at different frequencies to help
understand the phase stability problem.  There was roughly an hour
left.   An 14C was working pretty well, but 14A was clearly off in delay.
An 16 at L was fringing with fringe amplitudes down by a factor of 10.
But we could watch the phases on baselines to 16, and found they were
phase stable for about 30 - 60s and then would jump by ~100d.  We used
the same method as for X to tweak the delays.  We changed 14A by
+40ns, 14C by 0ns, 16A by -80ns and 16C by -150ns (although we couldn't
really change the 16 delays by these numbers as the delays wouldn't
fit into the syslif format, and we didn't bother with trying to change syspathf,
which Barry had used last Thursday).

Finally I modified my test L band file (which stepped through several 
frequencies in PA mode, at 12.5 MHz, but stayed on each for about 
3 minutes) and created a new evla script.   At this point I had about 20
minutes left, so I was in a bit of a hurry.  When I executed the obs and evla
files I found I no longer had fringes from the VLA to the EVLA though I 
had fringes among VLA antennas and fringes from 14 to 16.  I think I 
tracked this down to somehow not having the EVLA and VLA files observe
the same frequencies at the same time, so this was probably user error
somehow.  I never recovered from this.

After my time ended, I was bit by the "script not aborting even when it
was killed" feature; I couldn't send the antennas to a stow position as 
the acus were still getting commands from my script.  I had to call
Rich who killed the executor.  After that I was able to send the antennas
to a stow position, except that An 16 had a curious (probably a limit)
behaviour around 0 degrees azimuth;  it would get to 360 degrees on the
way to 260, and then change to 0 and go the other way; when it got to
about 30 degrees it would decide to head back.  We left it at az 380.

All in all, more heat than light, as they say.

Mark



More information about the evlatests mailing list