 |
EVLA Antenna Electronics: Case Study |
 |
|
|
EVLA Antenna Electronics: Case Study |
|
This document takes a look at the role of the class EvlaAntennaElectronics in the SSS system and how that class was constructed. This case study may prove helpful to others who wish to build an implementation of the generic AntennaElectronics interface and have that implementation incorporated into the SSS applications.
The Observation Preparation Tool (OPT) that will be used for configuring observations on the EVLA must allow observers to tell the system which parts of the radio spectrum are to be examined. Whether or not the EVLA can support observers' requests is something we would like the software to determine. Two of the more complicated hardware devices that control what may and may not be observed are the correlator and the local oscillator / intermediate frequency (LO/IF) system. This document focuses on the LO/IF system and refers to it as "antenna electronics".
The goal of the antenna electronics system is to take sky signals feed to it by a receiver(s) and convert them to digital signals. In the case of the EVLA, these signals will then be fed to the WIDAR correlator.
One of the important goals for much of the SSS software is that it be telescope-neutral. That is, we do not want to build EVLA-specific code in certain portions of our software. To the extent we can succeed at this, the easier it will be for the software to support other telescopes, should that requirement arise. To this end, the first thing we did with respect to modeling the antenna electronics was to create a generic interface, AntennaElectronics. This interface is a contract between users of antenna electronics and creators of antenna electronics. The contract is fairly limited and consists of messages for configuring the electronics and executing it in order to get digital signals from it. The programmer documentation in the preceding link contains detailed instructions about the contract.
Once we settled on just what antenna electronics were and what they should do, we were faced with creating an EVLA implementation. The EVLA electronics are quite complex. We realized right away that representing all this complexity in a single class would lead to one ugly and hard to maintain class. We also knew that we did not need to build a complete model of the electronics. All we needed to model were those parts of the electronics that help turn sky signals into digitized signals. The devices that help do this work are local oscillators, mixers, multipliers, and filters.
Building Blocks
Once we knew what portion of the real electronics we wanted to model, we
concluded that a building-block approach would be best, so we developed a
package
of very basic electronics devices. A complete discussion on that package is
beyond the scope of this document, but it is basically so telescope-neutral
that we put it in our family of utility, as opposed to domain model, packages.
It consists of very basic devices, such as the LOs, mixers, multipliers, and
filters mentioned previously. Each device does one simple job and can be
combined via signal pipes to other devices. Signal can then be made to
flow thorough a chain, or tree, of devices.
Intermediate Devices
Rather than building the EvlaAntennaElectronics class directly from
the basic building blocks, we modeled the real world a little more closely
by creating classes for the T301, T302, etc., devices that comprise
the EVLA electronics. Each of these devices is a signal processor
that can be connected to other processors. The final EvlaAntennaElectronics
class is essentially a collection of these intermediate devices and
some basic devices (such as switches) that connect them all together.
Advantages to This Approach
One of the main advantages of this approach is its maintainability and extensibility.
If, for example, the electronics guys decide to change the ranges of some filters
or use new LOs with different tuning steps, we do not need to see where the smarts
of the system lie and then try to rework them for the new parameters. Instead,
we just mimic what the electronics guys did -- change the parameters of some
filters and use a new LO with different tuning steps.
Disadvantages to This Approach
If something goes wrong somewhere in the system, debugging is not yet as
easy as it should be. The programmer is presented with an ugly stack trace
of method calls, most of which are mindless pipes that are just passing
the signal through to another pipe or device.
We have implemented a way for the electronics to get some of their smarts externally via an XML file. For any given band NRAO can designate local oscillator settings that can act as default settings. This file is kept in our subversion source code control system at evlaTuningPlan.xml (user name and password required). The XML schema for the tuning plan is the tuningPlan element of the resource.xsd file (vers 0.2.1, index to other versions).
As of 2007-Nov-26 we can configure the EvlaAntennaElectronics for a given receiver band and have it use the externally set default LO settings to produce signals. The logic has not yet been tested by someone who knows what they are doing. The interesting logic to configure the electronics based on a desired set of output signals has not yet been coded (though we do have code that can select receivers based on desired frequency ranges).