[evlatests] [evla-sw-discuss] parameter simplification for the VHF receivers

[Barry Clark]

I believe the principal reason the question arises is to get the
proper Tcal associated with each subband.  The current machinery
will do that pretty well, whether the band is regarded as two
receivers or one.  It interpolates Tcal from a curve as a function
of frequency stored for each "receiver", where we can choose
"receiver" to mean front end or baseband, as we wish.  There is
a technical peculiarity of the current implementation that requires
the Tcals to be measured over the whole band in a single run, but
this can be faked if needed.

The other reason one might want to separate the receivers by name is
the one I mentioned previously, that it is possible that one might
like a different delay setting for the two receivers.  I suspect
we can get away without this, but we should think about it.

I have not been maintaining the online Tcal database for these
receivers, because the receivers do not identify themselves in
the monitor data (or at least didn't - is this still true?) and
in the current stage of development I do not trust people to not
swap receivers when I'm not watching.

David Harland wrote:
> I offer OPT / m2s preferences, below.
> 
> Michael Rupen wrote:
>> Hi Frazer --
>>
>>   
>>>    The situation is complicated. I would think the possibility of
>>> having two (or eventually three) receivers added together to produce one
>>> input band for the correlator probably never came up. The 4 and P-band
>>> part of Lowband have different power levels (although we are trying to
>>> get then to be close on the sky) and different  T_cals (~ 10X
>>> different). We probably will have one default observing set up which
>>> delivers both bands  in some number of subbands and channelization,
>>> e.g., one subband of 32 MHz with 1024 channels for 4-band and three
>>> subbands of 128 MHz with 512  channels. However, it seems clear that
>>> other choices would be made for some experiments.  So we can't just
>>> reserve certain subbands for 4 and others for P. Furthermore, since the
>>> T_cals are very different (as well as T_sys), more than one cal value
>>> seems necessary.  Furthermore the potential exist to add 2-band to the
>>> system (120-170 MHz) with a third set of parameters.  (see
>>> http://www.aoc.nrao.edu/~pharden/LBR/lbr.htm for more details)
>>>     
>> This can all be handled by the SDM without any problem.  The difficulty
>> lies in getting the information to MCAF, so that we can form the SDM
>> properly.
>>
>> Can we simply define the observing bands by the sky frequencies they
>> cover?  If so, MCAF could figure out what to do, based on the
>> frequency covered by a given spectral window (subband).
> 
> OPT / m2s would prefer to view low band as a single receiver (front 
> end). This is mainly because adding the ability to choose multiple 
> receivers doesn't exist & will not be easy to add (more on that, below).
> 
>> If not, things
>> get complicated, as we've tried to separate knowledge of subbands (formed
>> in the correlator) from knowledge of basebands (defined at the antenna).
>> But I should shut up and let those who know what they're doing talk about
>> this.
>>
>>   
>>>    It also probably makes sense in some circumstances to use one IF for
>>> 4band and the other for P-band. The possibility also exists, at least in
>>> theory, to observe with one IF for lowband and the other for one of the
>>> higher frequency, standard EVLA receivers. Jim Jackson and Chuck Kutz
>>> have written a memo about this. I am not sure this really makes sense
>>> but the NRL folks are very keen on doing this. See EVLA memo 155.
>>>     
>> Apart from the hardware, this would require some tweaks to the Executor.
>> Writing the data to the archive, with correct labeling, would not be
>> difficult.
> 
> OPT development started with the idea of supporting multiple 
> simultaneous receivers. We originally thought 4/P might be used w/ L, S, 
> or C. Some initial work was done to allow multiple receivers (for 
> example, each resource holds a list of receivers). However, at some 
> point we saw difficulties allowing more than one receiver at once and 
> the code is now littered w/ logic that explicitly picks the 1st receiver 
> in the list & ignores all others. My knowledge of the details is stale, 
> but i am pretty sure that we will have a lot of work (couple months?) to 
> implement the ability to deal w/ two or more receivers at once. Now, it 
> may be that making special cases for the things the VLA would actually 
> use would not be as hard as the general case of combining any two or 
> more receivers, but that will need more analysis to say for sure.
> _______________________________________________
> evla-sw-discuss mailing list
> evla-sw-discuss at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss