[evla-sw-discuss] The T303 converter

[David Harland]

What follows is not an answer to the questions posed, but a reminder of 
the model of the EVLA antenna electronics used by the OPT, in case it 
may be of any use here. In November of last year, and again this past 
April, i solicited feedback on the accuracy of that model by exposing a 
test program (here 
<http://www.aoc.nrao.edu/%7Edharland/evlaTest/evlaAntElec.jnlp>) that 
uses a GUI to configure the electronics and present to the user the 
calculated output signals. The goal was to see if we had the electronics 
constructed correctly. Once we had learned that, the plan was to write 
the "intelligent" methods -- those that knew how to take only a given 
receiver band(s) and a set of desired output signals and then auto-tune 
the LOs and set the switches appropriately. We received a little 
feedback from the November release and none from the April one. The 
smart methods have not been coded, but will be before the end of the year.


Plan for the OPT
----------------

We're supporting first the expert users (mainly because it's easier to 
do so), then the typical astronomer. We'd like to protect the typical 
astronomer from the internal electronics as much as possible. We expect 
them to say what frequency regions are of interest, and then have the 
software set things up automatically. In order for the OPT to know, 
though, whether what they've requested is supportable, we felt it wise 
to model the electronics in a detailed way. This also dovetailed nicely 
w/ the needs of experts who might wish more manual control over the 
setup. (A prototype of the expert interface is currently available in 
the instrument configuration portion of the OPT, but only if you select 
WIDAR as the backend.)

All this is to say that by the time the user is done configuring an 
observation in the OPT, we should already know the LO tunings and the 
positions of the various switches. It would be nice to be able to 
communicate these directly to the objects used by the executor.


SSS EVLA Antenna Electronics
----------------------------

If anyone thinks it would be worthwhile, i'd be willing to create a 
presentation and hold a mtg on the antenna electronics code we've 
written. In brief, a Lego-block approach was used. The basic bricks are 
LOs, switches, filters, multipliers, and mixers. These are snapped 
together to form the T301, T302, etc, components. These are connected in 
turn to form the full electronics. The code contains no real internal 
rules; signal just flows from the front ends through the components and 
out the outputs. Default rules, though, can be provided externally, per 
receiver band, via "tuning plans". These just give initial settings to 
the LOs and switch positions; once those things are set, signal flows 
through the chosen pathways mixed with the chosen LO frequencies.

To look at some of these things on your own, here are some links:

* The overall philosophy is given in the class comments of the
AntennaElectronics 
<http://www.aoc.nrao.edu/asg-internal/maven/m2-sites/shared/data-models/apidocs/edu/nrao/sss/model/resource/AntennaElectronics.html> 
interface class.

* The AntennaElectronicsConfiguration 
<http://www.aoc.nrao.edu/asg-internal/maven/m2-sites/shared/data-models/apidocs/edu/nrao/sss/model/resource/AntennaElectronicsConfiguration.html> 
class is a brainless class that is
suitable for transferring settings from one place to another -- perhaps
from OPT land to Excecutor land? It can express itself as XML and can
be produced from, and read into, AntennaElectronics.

* The EVLA specific classes are in the package model.resource.evla 
<http://www.aoc.nrao.edu/asg-internal/maven/m2-sites/shared/data-models/apidocs/edu/nrao/sss/model/resource/evla/package-summary.html>.


Barry Clark wrote:
> I am in the process of rewriting the LoIfSetup class.  Although there
> were a few hooks, the support for the three bit samplers was essentially
> nonexistent.  The code in this class is so opaque and messy that it 
> is very difficult to modify.  Therefore I am rewriting ab initio.
> The existing version has a VLA correlator orientation, with Widar as
> an afterthought.  The new version will have a strong Widar orientation,
> with a very few VLA correlator afterthoughts.
>
> One of the things that makes the current code so very obscure is the 
> possibility of changing the frequency of an object after it has been
> constructed.  I plan to eliminate that capability.  (But I will still
> retain the capability of trading off between the L301 and L302 settings
> to get to the frequency with which the object was constructed.)
>
> At the lower bands what I want to do is straightforward.  Running the
> T303 UX converter is rather less so.
>
> The existing version primarily uses the T303 on the "straight through" 
> path, which is fine if all the bandwidth wanted lies within a single 
> 4 GHz block.  Ken has modified the class to allow one to directly specify 
> the path desired in the constructor.  This is a reasonable path to 
> follow, but it has the undesirable effect of unnecessarily exposing
> the equipment's internal structure to higher level software.  (This
> exposure is still needed for testing - we will likely want to see if
> different paths yield equivalent results as we go along, so it will
> at least always be an optional parameter to the constructor.)
>
> An alternative approach is to have a default choice of path be made
> by the software if it is not explicitly specified.  For those who care,
> the rules for making the choice are given at the end of this message.
>
> This approach has a serious flaw, in that the net sideband of the BBs
> is determined by this choice.  So if we continue the approach of 
> specifying signed sum LO to the class, higher level software has to be
> aware of what the choice is, because astronomers are likely to give 
> the frequency they want at the center of the band, not at band edge.
> So at least the algorithm for choice would have to be incorporated in 
> the higher level software.  This could be eliminated by providing 
> constructors that operate in band centers, rather than SSLO.  (This
> would be sampler band centers, so definitely a Widar concept, not a 
> VLA correlator concept.  The original choice of specifying SSLO was
> driven by not wanting the LO system to have to know about the filters
> in the VLA backend.)
>
> I am willing (for a while, anyway) to listen to advice on how to proceed.
>
>
> Appendix:  Suggested rules for selecting path through the T303 (chosen 
> for compatibility with existing practice).
>
> For Q and Ka bands:
> If all the requested bandwidth is within a 4 GHz block
>    select the straight through path for both IFs, giving both IFs in USB
> Else if the AC band is at higher freqency than BD
>    AC uses straight through in USB, BD converts by L301-2 giving LSB
> Else 
>    Both use conversion path, both LSB
>
> For K band
> If all the requested bandwidth is within a 4 GHz block
>    select the straight through path for both IFs, giving both IFs in USB
> Else if the AC band is at higher freqency than BD
>    AC uses straight through giving USB, BD converts by L301-2 giving LSB
> Else
>    Error - cannot be tuned
>
> For Ku band
> If all the requested bandwidth is within a 4 GHz block
>    Both IFs are converted using L301-1; LSB on both
> Else
>    AC uses conversion by L303-1, BD by L301-2; both LSB
> _______________________________________________
> evla-sw-discuss mailing list
> evla-sw-discuss at listmgr.cv.nrao.edu
> http://listmgr.cv.nrao.edu/mailman/listinfo/evla-sw-discuss
>