GBT Configuration: Requirements and Algorithms

by F. Ghigo and R. Maddalena,
April 4, 2003

1.0 Introduction

Configuring the GBT system can be a bewildering task. Setting many switches, filters, frequencies, and other options must be done correctly for successful astronomical observations. The purpose of this document is to present a set of astronomer-friendly keywords, and to specify how they are used to configure the system.

A distinction is made between configuring and observing. In general the configuration remains fixed during a series of observation scans. Observing procedures direct the antenna to move in various ways, running procedures such as 'track', 'peak', 'onoff', etc. From one scan to the next, certain parameters may change, such as the antenna tracking position, velocity, and receiver tuning frequency. Most other parameters, such as number of spectral windows, filter settings, and backend bandwidth, will stay the same. This document will only discuss configuring, not balancing or observing processes.

Keywords

We first list the primary and secondary keywords required to completely configure the GBT, listing default values. Table 1 lists the primary keywords (or meta-parameters) that are required and have no defaults. Table 2 lists primary keywords for which reasonable default values exist. Note that in many cases, possible values of a keyword can depend on the type of backend or observing type. Following that are secondary keywords (Section 3) that specify options that are specific to particular receivers or back ends.

Implementation

Following the tables is a discussion of how each keyword value is to be implemented (Section 4). A dependency diagram (Section 5.0: Figure 1) shows how values of keywords may depend on the choices of more basic keywords. Instructions for calculating the LO1, LO2, and RF or IF bandwidth are given in Section 6.0 on frequency calculation.    Wiring the system, i.e., connecting the signal paths from receiver to back end, is discussed in Section 7.0.

The cabling file will be consulted by the implementation software to trace connections through the system. We propose to introduce a module quality file which indicates which modules are substandard or out of service.

The Appendix gives details for implementation from the point of view of the YGOR manager parameters.

Configuration vs Tweaking

Previous discussions have distinguished between configuration and "tweaking" phases of experiment setups. The best implementation of these phases is to provide a library of functions or commands, perhaps one command per M&C device, which sets the parameters for that device. Tweaking would be accomplished by using a few of these commands to change parameters in certain devices. These commands would use the keywords as described in this document but also there would be commands for setting any YGOR parameter in any manager. The configuration process would build on these lower level commands, and all would be available to the user.

What about the antenna?

The configuration software should not try to set any antenna parameters. The policy is that the antenna configuration will be done by the telescope operator. This includes putting the correct receiver at the focus and selecting the right pointing and focus tracking models.


2.0 Primary Keywords (no defaults!!)

Table 1. Primary Keywords (See Section 4 for discussion of each keyword.)
Keyword Description Possible values
Receiver Name of GBT Receiver Rcvr_342 Rcvr_450 Rcvr_600 Rcvr_800 Rcvr1_2 Rcvr2_3 Rcvr4_6 Rcvr8_10 Rcvr12_18 Rcvr18_22 Rcvr22_26 Rcvr18_26 Rcvr40_52
Obstype Observing Type Continuum, Spectroscopy, Pulsar, Radar, VLBI
Backend Name of Data Acquisition System SpectralProcessor, Spectrometer, VLBA_DAR, S2, Radar, BCPM, BCPM/SP, GBPP, DCR_IF, DCR_AF
Restfreq Rest Frequency to be observed, in MHz. If more than one spectral window, this becomes a list of frequencies. Refer to Section 6.0. any frequency.
(Note that the LO1 system can only track one frequency. The first frequency list will be tracked.)
Bandwidth Band width per backend input, in MHz. The possible values depend on the Backend. See Section 4.5.

" "

Table 2. Primary Keywords (with defaults)

Keyword Description Possible values Default
Swmode Switching mode to be used. tp(total power with cal), tp_nocal, sp(switched power with cal), sp_nocal tp
Swtype For switching modes sp and sp_nocal, this is the type of switching. This parameter is not used for tp and tp_nocal modes. none, fsw(frequency switching), bsw(beam switching), psw(polarization switching), tsw(tertiary switching) Depends on Swmode. See Section 4.7.
Swper Switching cycle period. A time in seconds. Depends on Obstype. See Section 4.8.
Swfreq Frequency offsets used for frequency switching. A pair of frequencies in MHz. ( -0.25*Bandwidth, +0.25*Bandwidth)
Tint Back end integration time. A time in seconds. Depends on the Backend. See section 4.10.
Beam Beam selection: applies to multi-beam receivers. B1, B2, B3, B4, B12(both beams 1&2), B34, B1234(all 4 beams) B1
Nwin Number of frequency windows any integer from 1 to 8. See Section 4.11. 1
Deltafreq Table of sky frequency offsets for each spectral window. Refer to Section 6.0. List of Nwin frequencies, in MHz. zero (i.e., no offsets)
Vlow, Vhigh Velocity range A pair of velocities, in km/sec 0, 0
Vframe Velocity reference frame. topo bary lsrk lsrd galac cmb topo
Vdef Velocity definition. optical radio relativistic radio


3.0 Secondary Keywords

Table 3. Secondary Keywords
Keywords dependent on the receiver choice
Keyword Receiver(s) Default possible values
Polarization
Prime Focus, Rcvr1_2, Rcvr2_3, Rcvr4_6 default is circular for BCPM, VLBI, or Radar back ends, otherwise linear.
Rcvr8_10, Rcvr12_18, Rcvr18_26, Rcvr40_52 Only circular possible.
lin or XY(linear), circ or LR(circular)
Noisecal All receivers default is 'lo-ext', except for BCPM and Radar it's 'off' 'off', 'on-mcb', 'on-ext', 'lo-mcb', 'hi-mcb', 'lo-ext', 'hi-ext'
(hi/lo option not available for Rcvr12_18 and higher.)
Notchfilter Rcvr1_2 'In' 'In' or 'Out'
Beamswitch Rcvr12_18, Rcvr18_26, Rcvr40_52 If Swtype is 'bsw', then 'ext', otherwise 'thru' 'ext', 'thru', or 'cross'
Polswitch Rcvr1_2, Rcvr2_3 If Swtype is 'psw', then 'ext', otherwise 'thru' 'ext', 'thru', or 'cross'

Secondary keywords Dependent on the Back End

Some characteristics of the back end are not determined by any of the previous keywords. These are summarized here. Details are given in the Appendix.

4.0 Notes on implementation of configuration process

4.1 Receiver

Receiver names, as listed in the table, are standard throughout the system.

The receiver name is sent to the Scan Coordinator, who in turn sends it to the IF Rack manager and LO1 manager. The IF Rack manager sets its input switches to select the receiver inputs. The LO1 manager sets its routing switches to send the LO1 signal to the receiver.

4.2 Obstype

The observing type gives the category of observing: continuum, pulsar, spectroscopy, radar, or vlbi. In some cases, this type is synonymous with the Backend selection (only one radar backend, for example). But we allow the possibility of more than one backend per observation type.

The present situation is summarized as follows:
Table 4.2. Backends available for each Obstype
Obstype Backends
Continuum DCR_IF; DCR_AF
Spectroscopy Spectrometer; SpectralProcessor
Pulsar Spectrometer; SpectralProcessor; BCPM; BCPM/SP; GBPP
Radar Radar
VLBI VLBA_DAR; S2

4.3 Backend

The name of the backend is the YGOR manager name, as listed in the table, for backends that have managers.

The DCR has inputs from three sources: a) the IF Rack, b) the analog filter rack, and c) the prime focus receivers. We make the simplification that the direct inputs from the prime focus receiver will not be used in normal setups. Thus we have two flavors of DCR, to be designated DCR_IF and DCR_AF. 'DCR' with no suffix will mean DCR_IF.

If the DCR is not given as the principal back end, it will normally always be configured as DCR_IF for the selected receiver and beams, to be ready for Tsys measurements and pointing scans during any type of observing. The DCR phase table should be set up exactly like that in the Scan Coordinator even when the DCR is not the selected backend.

The backend selection determines which of the converter rack outputs are to be selected. For the Spectrometer (or ACS), the bandwidth parameter is also needed. The type of backend and bandwidth determines also the nominal IF3 frequency, i.e., the center frequency desired by the back end, which, along with the specified rest frequency and table of frequencies and offsets for the spectral windows, determines how the LO2 synthesizers are to be set (refer to Section 6.0 on frequency calculations.)

More details on specific backends are given in the Appendix.

What about multiple backends?

We will not address multiple back-ends, but designers should leave open the possiblity. The DCR should always be configured so that pointing checks can be done between other types of observations.

Pulsar observers often use both the BCPM and Spectral Processor simultaneously. For this, we use the backend keyword 'BCPM/SP'.

4.4 Rest Frequency

If there is more than one spectral window, this parameter is a list of rest frequencies. The first frequency in the list is used as the LO1 tracking frequency. Nwin, the number of spectral windows, is the length of the list. This list of rest frequencies and the Deltafreq list are used to determine the RF and IF bandpasses and the LO2 frequencies, as described in Section 6.0 on frequency calculations.

4.5 Bandwidth

This is the backend bandwidth, and determines the spectral line mode for the Spectrometer and Spectral Processor. For cases of multiple beams and multiple spectral windows, each window has this bandwidth. The RF filters (in the receivers that have them) and IF bandpass filters in receivers and in the IF Rack, are set to encompass the range of frequencies spanned by all the specified spectral windows
(see Section 6.0).

Although the Spectrometer allows its banks to have different bandwidths, we do not consider that possibility in this version of configurating, since it is likely to be used very rarely.

The possible choices for the bandwidth depend on the back end (and sometime the receiver), as listed in the following table:
Table 4.5. Possible Bandwidths
Backend Bandwidth choices
DCR_IF
Receiver Bandwidths
Prime Focus 20, 40, 80, 240 MHz
Rcvr1_2, Rcvr4_6, Rcvr8_10, Rcvr12_15 20, 80, 320, 1280 MHz
Other receivers 80, 320, 1280 MHz
Spectrometer and DCR_AF 12.5, 50.0, 200, and 800 MHz
Spectral Processor 40, 20, 10, 5, 2.5, 1.25, 0.625, 0.3125, 0.15625, 0.078125 MHz
BCPM 192 MHz
Radar 20 MHz
VLBA_DAR or S2 any multiple of 4 MHz up to 500 MHz

4.6 Switching Mode

The switching mode determines the number of phases and selection of cal and sig/ref that is sent to the scan coordinator. The mode also determines the blanking time (in general the blanking time is 2 ms, except for some SpectralProcessor modes, when it it 40 ms.)

The details of setting switching phase tables is given in the Appendix, in the section on the Scan Coordinator.

4.7 Swtype: switching type

  • none : If mode is 'tp' or 'tp_nocal', the switching type is ignored.
  • fsw : Frequency switching: the Swfreq table is sent to the LO1 manager.
  • bsw : Beam switching: the receiver beam transfer switch is set to external.
  • psw : Polarization switching: the receiver polarization transfer switch is set to external.

    The defaults for Swtype depend on the switching mode and the receiver.

  • If Swmode is 'tp' or 'tp_nocal', then Swtype is 'none'
  • If Swmode is 'sp' or 'sp_nocal', and the receiver has multiple beams, then Swtype is 'bsw'.
  • otherwise, Swtype is 'fsw'

    4.8 Swper: switching cycle period.

    The switching period is passed directly to the corresponding parameter in the Scan Coordinator, which in turn passes it to all selected back ends.

    Reasonable defaults depend on the observing type:

    4.9 Swfreq: switching frequency table.

    In the case of frequency switching, these frequency offset parameters are sent to the LO1 manager.

    4.10 Tint: backend integration time.

    Most data acquisition backends have an integration or dump time. Samples are written out at this interval. Tint must be an integral number of switching cycle periods. Most backends have limitations on the allowable integration time, due to their internal clock cycles. The user's entry for this parameter will be adjusted upwards to accomodate these restrictions.
    Table 4.10.1. Defaults for Tint
    Obstype Tint
    Continuum Swper
    Spectroscopy 10 sec
    Others 30 sec

    Some backends have restrictions on the possible range of Tint, as detailed in the following table:
    Table 4.10.2. Ranges of Tint
    Backend Range of Tint
    Spectrometer/ 1 quadrant 0.5 to 40 sec
    Spectrometer/ 2 quadrants 0.7 to 40 sec
    Spectrometer/ 3 quadrants 1.0 to 40 sec
    Spectrometer/ 4 quadrants 1.2 to 40 sec
    SpectralProcessor 1.5 to
    DCR 0.01 to 60 sec
    Other backends no restrictions

    4.11 Nwin: number of spectral windows

    The number of spectral windows, along with the beam selection, determines how many paths need to exist between the receiver and backend. Using the cabling file and the module quality file, the selection of converter modules and analog filter modules can be determined, as discussed in Section 7.0l

    The system will always be set up for dual polarization, so there will always be at least two signals per spectral window per beam. A signal from each beam of each receiver is split 4 ways to go to 4 pairs of converter modules. Each polarization pair can be mixed with a different LO2 to provide 4 spectral windows. The possibility of 8 spectral windows is provided by splitting the signals from the receiver to go to both converter racks A and B. This splitting is done for Rcvr8_10 and lower frequencies. Eight spectral windows means 16 signals going to the back end. The only back ends that can acquire 16 signals are the DCR_AF and Spectrometer, when using 12.5 or 50 MHz bandwidths.

    The possibilities for Nwin are detailed in the following table: The maximum number of windows listed in the table is for one beam. If using more than one beam, divide by the number of beams, except for the DCR_IF case.
    Table 4.11. Maximum Nwin
    Backend(s) Receiver Max Nwin
    Spectrometer, 12.5 or 50MHz BW
    or DCR_AF, 12.5 or 50MHz BW
    < 10 GHz 8
    Spectrometer, 12.5 or 50MHz BW
    or DCR_AF, 12.5 or 50MHz BW
    > 10 GHz 4
    Spectrometer, 200 or 800 MHz BW
    or DCR_AF, 200 or 800 MHz BW
    Any 4
    SpectralProcessor Any 4
    DCR_IF Any 1 (all beams)
    BCPM Any 2
    Radar Any 1
    VLBI < 10 GHz 2
    VLBI > 10 GHz 1

    4.12 Deltafreq: list of frequency offsets.

    Each IF3 band (arriving at the back end) is centered at a rest frequency which is the sum of the rest frequency (Restfreq) and offset (Deltafreq in the topo frame) for each spectral window. See Section 6.0 for details.

    4.13 Vlow, Vhigh, Vframe, Vdef.

    The range of velocities is used to estimate the range of local frequencies that will be observed. In connection with the Restfreq and Deltafreq arrays, it is used to estimate the total range of frequencies in the local frame that will be required, and to set the RF and IF filters and IF1 parameter accordingly.

    The estimated range of frequencies is not meant to be exact. We propose to simply convert velocity to frequency offset using only the velocity definition, but not using the reference frame. For barycentric and LSR reference frames we are making an error of 30 km/sec or so, which corresponds to a frequency of less than a few MHz for receivers up to Q-band. For the galactic frame, we may make an error of a few hundred km/sec, which can amount to several 10s of MHz. Note that the error of ignoring the rest frame is always the same percentage of the sky frequency. Refer to the Section 6.0 for frequency calculation details.

    Keyword values for Vframe and Vdef are sent to the LO1 manager, after translation to the values used by LO1.


    5.0 Keyword Dependencies

    In Figure 1, we show a diagram indicating how the various keywords depend on others. This is useful to help figure how to set default values. This should also be helpful in implementing this process because possible choices of keyword values often depend on previous choices.


    6.0 Frequency Calculations.

    Let V1 and V2 be the given range of velocity, with V1 > V2.
    The conversion to the local frame uses the appropriate formula for the selected velocity definition:
  • Flocal = fvdef( V, Frest )

    Table 6.1. Formulas for conversion to local frame
    Vdef Formula
    Radio fvdef(V, Frest) = Frest( 1 - V/c)
    Optical fvdef(V, Frest) = Frest( 1+V/c) -1
    Relativistic fvdef(V, Frest) = Frest { 1 - (V/c)2}1/2/(1+V/c)

    Let Fk = Restfreq, and dF = Deltafreq. For N spectral windows, our configuration keywords will specify
    Fk[i] and dF[i], the list of rest frequencies and offsets, for each i = 1,N.

    Convert the Fk frequencies to the local frame, and add the offsets:

  • F1[i] = fvdef( V1, Fk[i]) + dF[i]
  • F2[i] = fvdef( V2, Fk(i]) + dF[i]

    Determine the center frequency and total bandwidth:

  • Fcent = 0.5*(MAX(F2[i]) + MIN(F1[i]))
  • BWtot = MAX(F2[i]) - MIN(F1[i]) + BW
    (where BW is the backend bandwidth keyword value.)

    How these quantities are used:

  • The receiver tuning frequency is set to Fcent.
  • The receiver RF filter (if any) is set to include a range from Fcent-0.5*BWtot to Fcent+0.5*BWtot.
  • IF filters in the receiver and IF Rack are set to the narrowest value that includes BWtot.

    Given that the primary rest frequency, Fk[1], will not in general be at the center of the IF band, we need to modify the IF1 frequency in the LO1 manager so that the IF band represented by (Fcent, BWtot) is centered.

  • Let the nominal IF1 frequency be IF1nom, which has values of 1080 MHz for prime focus receivers, and either 3000 or 6000 MHz for Gregorian receivers. Then set the IF1 parameter in the LO1 manager to
  • IF1 = Fcent - Flocal[1] + IF1nom [for Rcvr8_10 and lower frequency]
  • IF1 = Flocal[1] - Fcent + IF1nom [for Rcvr12_18 and higher frequency]
  • Where Flocal[1] = fvdef( 0.5*(V1+V2), Fk[1]) + dF[i]

    Now we can determine the appropriate frequency settings for the LO2 synthesizers:

  • Define Flocal[i] = fvdef( 0.5*(V1+V2), Fk[i] ) + dF[i]
  • LO2[i] = Flocal[i] - Fcenter + IF1 + 10.50 - IF3

    (where IF3 comes from Table 4 and depends on the chosen back end.)
    Table 6.2.
    Nominal Center Frequencies (IF3)
    Back End Frequency (MHz)
    ACS-12.5MHz 468.75
    ACS-50MHz 425
    ACS-200MHz 900
    ACS-800MHz 1200
    Spectral Processor 250
    VLBI 750
    BCPM 400
    Radar 720


    7.0 Wiring: pathfinding through the IF system.

    The key to finding the paths through the IF system is the cabling file. We also propose a module quality file which allows flagging of devices that are substandard or out of service. The actual form of the quality file and the implementation of pathfinding through the system is best left to the next phase of this project and consultation with software developers. We outline a procedure, in general terms, which we hope will convey the requirements.

    The possible paths through the system can be regarded as a tree structure. This structure is defined by the cabling file and knowledge of the internal structure of the IFRack, Converter Racks, and Analog Filter Rack.

    The first step is connecting the Receiver beam(s) to the IFRack. This is already implemented in the IFRack manager software, so the only action required is to send the receiver name to the IFRack manager, and its inputs will be set correctly. The user will have specified the Receiver and Beam keywords, so the desired input ports of the IFrack will be known.

    Some of the receivers (Rcvr8_10 and lower frequency) have their signals split to go to two pairs of IFRack inputs. In this case the tree has two branches. Any IFRack input can be connected to one of two optical fiber drivers, depending on the IFRack transfer switch. Here are two more branches. The optical receiver outputs split to four converter modules: a four-fold branching.

    Each converter module can select between four outputs, but these are determined by the Backend and Bandwidth, so there is no branching here. If using the Spectrometer or DCR_AF, the Analog Filter Rack needs to be considered. The choice of AFR input is determined by which converter modules were chosen, and the filter settings in the AFR are determined by the Bandwidth, so there is again no branching. Each AFR module connects to a particular sampler in the Spectrometer, so there is, again, no choice.

    Thus for any beam of the selected receiver, there are at most 2x2x4 or 16 possible paths to a backend port.

    The software should consider all possible paths and consult the quality file to eliminate paths that contain a substandard module. If there is no path with all good modules, an error message will be issued. We leave as an open question at this point exactly how to rate modules and how each path is to be ranked based on the quality file. For paths that have equal quality the choice will be to select the lowest numbered modules first, for example, choose converter modules 1&5 first, then 2&6, and so on.

    The procedure would be to start with the first beam of the first spectral window, search the tree and decide on the path. Then go to the second beam, if any, and continue through however many beams are required. Next, repeat the process for each remaining spectral window. In this way, all paths are found for the specified observing.

    The keywords that drive the pathfinding process are: Receiver, Backend, Bandwidth, Beam, and Nwin.

    This process of pathfinding is the first step the configurator must go through. It determines how the IFRack transfer switches are to be set, and how the input switches of the converter modules and analog filter modules are set. It identifies which converter modules go with which spectral windows, and thus which LO2 synthesizers are set to which frequency.