[evla-sw-discuss] VLA antennas and the EVLA parameters database

[Ken Sowinski]

On Wed, 28 Jun 2006, Ken Sowinski wrote:
> On Wed, 28 Jun 2006, Barry Clark wrote:
>
>> How should we store delays in the database?  I'm thinking a pad delay,
>> an antenna delay, and four delays per band per antenna for the IFs.
>> (Gets a little confusing because pad delays are very different for VLA
>> and EVLA.)
>
> Yes pad delays will be a little confusing.  Perhaps two of them;
> a WG delay and a fiber delay to add even more confusion.  When
> the DTS resyncs we get a delay jump of a few nanoseconds.  I have
> wondered if we wanted an IF based delay which is applied to all
> bands to account for this with less fuss.  The danger, again,
> is that all these free parameters will just let us confuse ourselves.

I will start in on delays this afternoon.  Here is what
I propose.

For each pad:
WGDELAY      From the BASELINE file and is the small residual
              delay which accounts for the difference between
              the estimated delay for VLA antennas and the
              actual delay.
FIBERDELAY   From SYSPATHF and is the measured delay necessary
              to align an EVLA antenna in the traditional VLA
              delay space.  This is a large number: about one
              microsecond larger than the measured OTDR path
              length is usually a good initial guess.  This
              value has only been entered for pads already used
              with VLA antennas.
Alternatively, I can calculate the full WG delay as the Modcomp
does and supply that instead.  This does not appear to attractive
since you  already have this calculation in the executor .

For each antenna:
PECDELA      Peculiar delay for each IF for each band.
PECDELB
PECDELC
PECDELD
In addition we might want a value for PECDEL for each antenna
with no band qualifier to adjust for the delay jumps when the
antenna or the DTS system resyncs.  The value in this field,
if present, would be added to the peculiar delay specified for
each band.