NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Software > IFManagerWorkOverview

Changes | Index | Contents | Search | Statistics | Go

What is the IFManager?

The IFManager is a simulation program which accepts electronic component settings from control software throughout the telescope and cable connections from a file to generate the rudimentary RF characteristics all along the signal's path from the feed to the backend. The resultant signal characteristics are made available to the user through user-interface feedback in near real-time and through a FITS file for each scan. Originally conceived as an aide and verification tool for the user, the information it generates has become critical for data analysis.

Possible effects which change the RF signal characteristics were divided into three categories, those which required an engineer to build something (new devices or at least the use of a soldering iron), call them infrastructure changes; those which are the result of a maintenace day activities (changing cabling between devices), call them configuration changes; and those which are the result of the end user using the telescope through the control software, call them just use. Infrastructures changes are compiled into the IFManager, configuration changes are specified in a text file, and use changes are handled automatically by the control system.

Work to be done

The suggestions below describe "fixes" to the current code. The comments at the end of the page suggests the need a new approach. The estimates assume each task is done independently, if tackled together then the whole would be significantly less than the sum of the parts.

The list of paths may be incomplete when using beam switching

The IF FITS file is written such that each row of its binary table represents a unique path from feed to backend port. When the sig/ref signal is used to modify the RF signal path, e.g., alternates the signal between two feeds, the FITS file represents the paths during sig phase of the switching signal. When both paths terminate on backend ports, then the paths for both phases are fully characterized. However, if the user is not interested in a symmetrical use of the telescope, i.e., only one path terminates at a backend, then the IF FITS file does not contain information on the signal path used during the ref phase. See Project Office request 974.

A solution that could handle all cases would be to add simulation of the switching signals to the simulation of the RF signals. Then the FITS file would contain a row for each full path from feed to active backend port for each switching signal phase thus convering all possibilities. The IFManager was originally designed with this solution in mind, but was abandoned due to schedule pressures. It is easily a month's effort.

A more pragmatic approach would be to identify switches that can be under sig/ref control and treat them as hybrids are currently treated, i.e., assume the switch (or hybrid) exists just after the feed and report both feeds as being in the RF path. Could be done in a week or two.

No way to specify temporary backends

The introduction of new backends has been handled as a infrastructure change, but with users bringing in their own backends, they may need to be treated as configuration changes, most logically as part of the cabling file. This is trivial (a day's work) unless a description if the signal path terminating at the backend is needed in the generated FITS file, then an accurate estimate is more problematic.

Components specified in the cabling file are not listed in the signal path

Besides containing a list of cable connections, the cabling file also handles other configuration changes such as placing splitters and filters between devices. These "temporary" devices are correctly simulated, but are not reflected in the list of devices for the signal path neither in the user feedback nor the FITS file. See project office request 867. Probably a couple of days effort.

-- MarkClark - 09 Feb 2004

New devices

Apart from the work described above, a number of new devices/specific upgrades will need to be added to the IF Manager. These include:

• Common mm converter. This will be added to the system in two stages; initially (April 2004?) as a hardwired addition to the IF system ( Coded, Lab tested, Telescope tested - 12 May 2004), and later (Fall 2004?) as a configurable device under M & C control. This may therefore need to be emulated in two stages?
• Caltech continuum backend - at least one by Fall 2004, and potentially a second one.
• 3mm receiver module 1 (currently on hold)
• 3mm receiver module 2 (not yet started)
• wideband analog spectrometer (potential)
• modifications to the X-band receiver (when?)
• additional devices (most likely but not necessarily backends) may also be proposed.

It is interesting that the above list spans the gamut from receiver, through "parts of the IF system", to backend.

The Penn Array Receiver (64 pixel bolometer array) will comprise "receiver and detector" in a single package. This should probably be kept entirely separate from the IF Manager, but this should perhaps be briefly discussed.

-- RichardPrestage - 11 Feb 2004

Work Completed

RcvrPF_1 simulation is incomplete

The simulation for RcvrPF_1's loHiCalSel circuit has not been added. See Project Office request 861. A day's effort.

Generates "no connection" false alarms

For those backends (SpectralProcessor?, Spectrometer and DCR) which report which of its input ports are active, i.e., expect a signal, the IFManager generates an alarm if it does not detect a complete path from the backend's port to a legitimate source. However, the IFManager currently has no informatin which backends are under control of the ScanCoordinator so that backends (that are not placed in Standby) not in use by the observer will be reported by the IFManager as being "signal deficient."

The IFManager needs to accept from the ScanCoordinator its list of currently selected devices called subsystemSelect. A mechanism for passing the ScanCoordinator's parameters to its children exist, but it requires a unique name for the parameter. Changing the name of the parameter from subsystemSelect to something unique (and actually more accurate such as systemSelect) will require updates to user-interface programs such as GO and CLEO. The IFManager could be modified to use this information in a few days.

Remove unused code

The IFManager contains a significant amount of functionality that is not being used, specifically, for each backend port it will calculate the associated IF frequency for any sky frequency and vice versa, and for any sky frequency it will compute the needed frequency for LO1. None of this functionality has been exposed by the available user-interfaces. If they are not needed they should be removed to simplify the code. A couple of days effort. ( Coded, Unit tested, Telescope tested - 29 Apr 2004)

The demise of LEDA

The IFManager's simulation is built on a library which provides functionality for operations on sets of nodes connected by arcs (graph library). The library chosen was the LEDA library which -- at the time -- was available to education and research institutes at no cost. Since that time it has become privatized (along with everything else) and costs a bundle. Moreover, the version obtained contained only compiled libraries. We dodged a bullet with the most recent Linux upgrade when JoeBrandt was able to hack a method for linking these libraries to the newer system libraries required by 2.9. We may not be so fortunate next time.

A straightforward replacement with a compatible graph theory library is a couple of weeks effort.

Many of the dependencies on the LEDA library can be removed using the standard template library and the others could be encapsulated in an interface class (GraphFacade). ( Coded, Unit tested, Telescope tested - 29 Apr 2004)

Using the interface class, an alternate implementation of the GraphFacade class using STL vector and stack templates was used to eliminate the LEDA library. ( Coded, Unit tested, Telescope tested - 10 Mar 2005)

LO Frequency Precisions

The text portion of the FITS file (TRANSFORMS) would benefit greatly if the LO frequencies were entered to the nearest tenth of a Hz. ( Coded, Unit tested, Telescope teste - 14 May 2004)

-- FrankGhigo - 16 Apr 2004

The LO frequency computations use floats which introduces errors at the KHz level for the sky frequency formula coeffcients, need to use doubles. ( Coded, Unit tested, Telescope tested - 14 May 2004)

-- MarkClark - 27 Apr 2004

New devices

Apart from the work described above, a number of new devices/specific upgrades will need to be added to the IF Manager. These include:

• The Ka-band receiver. This is definite, and required by April 2004. Requires connection to DCR and spectral line systems. ( Coded, Lab tested, Telescope tested - 29 Apr 2004)
• Temporary switches between the Ka receiver and the DCR. ( Coded, Lab tested - 29 Apr 2004)

Comments

I think it is clear that a lot of these items are strongly related. The code suffers from a fair amount of bloat that renders it inflexible and resistant to change, and I think that addressing the bloat first is the fastest route to adding new features. Specifically, there are three items that contribute to the bloat, and they should be addressed in the following order:

1. Unused features/functionality. Yank 'em. This should be the first priority. (20 hours pair-programming effort)
2. Yank LEDA. It's not just that I think a graph library is unnecessary for the IFManager, but that I think this is a case of bad re-use. Using LEDA where it is not necessary greatly complicates the code, and the few graph algorithms we do need can be implemented simply. This should be the second priority. (60 hours pair-programming effort)
3. Seek uniformity among infrastructure, configuration, and use cases. From some perspectives, these are useful distinctions, but from other perspectives they are artifical complications. Treating these uniformly should further reduce the inerta of the code base. (40 hours pair-programming effort)

Addressing these refactoring issues first will be the quickest way to implement/fix:

• incomplete paths when using beamswitching
• temporary backends
• cabling file components not being listed in paths

The two remaining issues (false alarms, PF1) are, however, more or less independent.

-- EricSessoms - 09 Feb 2004

I would like to see the IFManager retain some features that are not currently being used, but should be used by the config tool sometime in 2004. It is my goal to have the config tool check that valid paths exist to the appropriate backend ports after each configuration. My plan is to use the IFManager "pathexist" functionality. This might also include checking bandwidths, sky frequencies etc. at the used ports. I think this would help the user, but just as importantly, these sort of validation checks could be essential when we automate regression testing. -- MelindaMello - 20 Apr 2004

There are no plans to remove these features. -- MarkClark - 27 Apr 2004

-- MarkClark - 09 Mar 2005