[evlatests] OTF Modes -- Strange Startup Behavior

[Rick Perley]

     I have a question for the OTF people about how a scan starts. 
Something is not right here (at least in my opinion) ...

     I ran another test yesterday afternoon where I did four cuts 
through the primary beam.  Two cuts along RA, and two along Dec. Each of 
these pairs was a 'back and forth' -- the first was W to E, the next was 
E to W, with the same start and stop points. Similarly, for the second 
pair, the first went from North to South, the second from South to 
North, these two using the same endpoints.

     For the Declination cut, I went from half power to half power. (The 
RA cuts went from first null to first null).  For all four scans, I used 
a 10 second delay/phase stepping cadence, and dumped data at a 10 Hz 
rate (i.e., DeltaT = 0.1 second).  I used 3C147 as the target, giving 
heaps of SNR, even within 0.1 second integration.  The test was done at 
L-band.

     To summarize, the test did the following:

     1) Scanned in RA from first null to first null, going from west to 
east.
     2) Scanned in RA as above, going from east to west.
     3) Scanned in Dec from half power to half power, going from north 
to south
     4) Scanned in Dec, as above, going from south to north.

     The scan listings (and the data) show that between the four steps, 
there is a 20 second gap ( equal to two delay/phase steps). I had 
thought the idea was that this time was used to allow the antennas to 
move to the new start point, then 'back up' a little, to allow the 
antennas to be moving at the right speed, and to be in the correction 
position, when the next scan begins.  This is not what is happening.

     Attached is a plot of the antenna power from ea14 and ea15, at the 
beginning of scan #3.  (The beginning of scan #4 is identical). These 
are in dB, and are calibrated, so that the center of the beam = 0.  ea14 
(new ACU) is different than ea15 (old ACU) -- all other antennas (except 
ea21, which was out of the array during this test) are identical to ea15.

     What is clearly happening is that, at the beginning of the scan, 
the antennas are not at the correct position (which would be about -4dB 
-- a little bit past the half power for this frequency), but at a place 
a bit further beyond.  The antennas then do a 'cold start' -- easily 
visible as a very rapid change in power.  For ea15 (old ACU) there is 
considerable overshoot, as the antenna power is fairly flat for a few 
seconds, before taking up the expected smooth travel (from 23:13:58 
onwards).  This is 4 seconds into the scan.  For ea14 (new ACU), the 
situation is better -- there is essentially no overshoot, and smooth 
motion begins about 3 seconds earlier than the 'old' antennas.

     I had thought that the 10 seconds prior to this first scan was 
supposed to be used to execute a 'running start', so that by the time 
the scan actually begins, the antennas would be moving smoothly, and be 
in the appropriate position.  The evidence is that this is not happening.

     Another question:  Presuming the intention is to do a 'running 
start', how is this computed?  The attached plots show that, for the old 
ACUs, about 5 seconds is needed.  So does the executor add a fixed time 
at the beginning of each scan, back the antennas up an appropriate 
amount, and start the motion?  Or is this startup time equal to one 
delay/phase stepping interval?  (Which is what I recall Bryan telling 
me).  If the latter, it is nowhere near enough time for fast tracking 
(which might require stepping times as short as 1 second, or less).


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OTF-Start.eps
Type: application/postscript
Size: 29213 bytes
Desc: not available
URL: <http://listmgr.nrao.edu/pipermail/evlatests/attachments/20150305/bff91f7d/attachment-0001.eps>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OTF-Start.png
Type: image/png
Size: 30186 bytes
Desc: not available
URL: <http://listmgr.nrao.edu/pipermail/evlatests/attachments/20150305/bff91f7d/attachment-0001.png>