GBT Configuration

This describes the process of configuring the GBT. 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 are used if any of them are missing. Following that are secondary keywords that set up options that are specific to particular receivers or back ends. Note that in many cases, the appropriate defaults depend on the type of backend. For example, VLBI and Radar observing virtually always use circular polarization.

Following the tables is a discussion of how each keyword value is to be implemented. Instructions for frequency calculation are given, and finally there is the description of an approach to connecting the inputs from the receiver all the way to the back end.

Previous discussions have distinguished between configuration and "tweaking" phases of experiment setups. It has been thought that certain parameters would be "tweaking" parameters, distinct from configuration parameters. This approach leads inexorably toward madness. Configuration and tweaking should be regarded as two processes. Configuration sets all parameters of all Ygor managers required for the desired experiment. Tweaking is a process where a change is made to the configuration. Any parameters, whether meta-parameters, configuration keywords, or YGOR parameters may be tweaked. Tweaking is a process, not confined to any set of parameters.

Table 1. Primary Keywords (no defaults!!)

(Click on Keyword for discussion of how to implement.)
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 Rcvr40_52
Backend Name of Data Acquisition System DCR SpectralProcessor Spectrometer VLBI RADAR BCPM GBPP
[also alternate flavors of DCR: DCR_PF, DCR_IF, DCR_AF]
Restfreq Rest Frequency to be observed, in MHz. If tracking velocity, additional keywords (below) are required. If more than one spectral window, this becomes a list of frequencies. Refer to frequency calculation details. any frequency.
(Note that the LO1 system can only track one frequency. The first frequency in the Rest Frequency list will be the one that is tracked.)
Bandwidth Band width per backend input, in MHz. Value depends on the back end. If using the Spectral Processor it would be 40, 20, 10, etc, MHz; if using the Spectrometer, it would be 12.5, 50, 200, or 800 MHz. For the BCPM, it would usually be 192 MHz, for the radar backend 20 MHz. The VLBI backend can use any bandwidth from about 8 MHz to 500 MHz, depending on the experiment.

" "

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.
(Note if frequency switching, the frequency offsets must be specified.)
none, fsw(frequency switching), bsw(beam switching), psw(polarization switching), tsw(tertiary switching) none
Swper Switching cycle period. A time in seconds. one second for spectroscopy backends, 0.2 sec for DCR, 0.04 for BCPM.
Swfreq Frequency offsets used for frequency switching. A pair of frequencies in MHz. ( 0, 0)
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: if this number is greater than one, additional keywords are required (see below) any integer from 1 to 8. 1
Dfreq Table of frequency offsets for each spectral window.
For each window, a rest frequency and offset frequency can be specified. The offset is applied in the local rest frame. The sum of the frequency and offset will be the frequency that is placed at the center of each back end spectrum. Refer to frequency calculation details.
List of Nwin frequencies, in MHz. zero (i.e., no offsets)
Vlow, Vhigh Velocity range: Low and High ends of the intended velocities to be observed. These are used in conjunction with the table of spectral windows to figure out the required front end and IF filters. A pair of velocities, in km/sec 0, 0
Vref Velocity reference frame. topo bary lsrk lsrd galac topo
Vdef Velocity definition. optical radio relativistic radio

Table 3. Secondary Keywords

Keywords dependent on the receiver choice
Keyword Receiver(s) Default possible values
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', 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 frequencies.)
Notch Filter Rcvr1_2 'In' 'In' or 'Out'
Transfer switch. Rcvr12_18, Rcvr18_26, Rcvr40_52 If switching mode is 'bsw', then 'ext', otherwise 'thru' 'ext', 'thru', or 'cross'

Secondary keywords Dependent on the Back End

These are parameters that are not implied by any other keywords.

Notes on implementation of configuration process


Receiver names, as listed in the table, are standard throughout the system. Abbreviations may be accepted by the command-line interface.

The receiver name is sent to the Scan Coordinator, who in turn sends it to the IF Rack manager, who sets the IF Rack input switches to select the receiver. The selection of beams, a secondary keyword for multi-beam receivers, determines which and how many of the IF Rack inputs are to be used.

The receiver name is also sent to the LO1 manager, who sets the routing for the receiver.

Using the number of spectral windows (NIFs) along with the beam selection, the cabling file is consulted to determine which converter modules are to be used and how their inputs are set.

In addition to the cabling file, we will have a file indicating which modules are out of service or whose performace may be subnormal.

In general, knowledge of the receiver, NIFs, and beam selection, along with the cabling file and module quality file, allows the configurator to set up the IF Rack and converter racks. (Ignoring for now the LO2 frequency setups) For the spectral line backends, no further knowledge is needed to set up the converter rack inputs. The exception is for the VLBI, BCPM, and Radar back ends which connect only to certain specific converter module outputs.

The choice of receiver will determine the target power levels for the IF Rack. These levels are normally 1 volt, except for Rcvr18_26, in which case they are 3-4 volts.


The name of the backend is the YGOR manager name, as listed in the table, for backends that have managers. Abbreviations of these names will be accepted by the command-line interface, such as sp for SpectralProcessor and spec or acs for the Spectrometer.

Refer to the backend keywords for a list of the secondary keywords that apply to specific back ends.

The DCR has inputs from three sources: a) the IF Rack, b) the analog filter rack, and c) the prime focus receivers. We regard these as three different flavors of DCR, to be designated DCR_IF, DCR_AF, and DCR_PF. 'DCR' with no suffix will mean DCR_IF.

The DCR is always configured, regardless of which back end is selected.

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.

For the BCPM, VLBI, and Radar backends, there is only one spectral window possible (although when BCPM2 is implemented there will be 2 windows for the BCPM), so the choice of converter modules and their outputs is determined.

For the spectral line backends, multiple IFs can be implemented. We should adopt a simple strategy, for example, spectral window no. 1 uses converter modules 1&5 (or 9&13 for rack B), window no. 2 uses 2&6, and so forth. The cabling file and module quality file will be consulted to avoid bad modules.

For the Spectral Processor, there is only one way the samplers can be chosen. There is more choice for the Spectrometer, allowing the possiblily of avoiding bad samplers.

Table 4.
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

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. This perhaps should be a separate back end choice, "BCPM/SP" for example.

Rest Frequency

At the moment, the LO system can track only one rest frequency, and this parameter is it. This parameter is simply passed to the LO1 manager. 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. The number of items in the list is the number of spectral windows. If any item in the list is zero, it will by default be set to the first frequency in the list.

Band Width

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.

To determine the front end bandwidth, it is also required to use the velocity range and velocity definition to predict the range of sky frequencies that will be required.

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 frequency switching when it it 40 ms.)

Mapping between Switching mode and the setting of Scan Coordinator phase table is described in the following table:

Table 5. Switching Modes and Phase Tables.
Switching Mode Phase Table Blanking time
tp (i.e., total power with cal)
[except for Spectral Processor case below]
phase Cal Sig/Ref
1 cal off Sig
2 cal on Sig
0.002 sec
tp (if using Spectral Processor and Velocity frame not Local)
phase Cal Sig/Ref
1 cal off Sig
2 cal on Ref
0.040 sec
phase Cal Sig/Ref
1 cal off Sig
0.0 sec
phase Cal Sig/Ref
1 cal off Sig
2 cal off Ref
0.002 sec, or 0.04 if using the Spectral Processor for frequency switching.
sp (switched power with cal)
phase Cal Sig/Ref
1 cal off Sig
2 cal on Sig
3 cal off Ref
4 cal on Ref
0.002 sec, or 0.04 if using the Spectral Processor for frequency switching.

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.

    Swper: switching cycle period.

    The switching period is passed directly to the corresponding parameter in the Scan Coordinator.
    Swfreq: switching frequency table. In the case of frequency switching, the frequency offset parameters are sent to the LO1 manager.

    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.

    We should adopt a simple strategy, for example, spectral window no. 1 uses converter modules 1&5 (or 9&13 for rack B), window no. 2 uses 2&6, and so forth. The cabling file and module quality file will be consulted to avoid bad modules.

    Dfreq: 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 (Rfreq) and offset (Dfreq) for each spectral window. Refer to the
    frequency calculation details.

    Velocity Range, etc.

    The range of velocities is used to estimate the range of local frequencies that will be observed. In connection with the frequency and offset table, 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 calculation details.

    Frequency Calculations.

    This summarizes the procedure:

    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 7. 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)

    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.)

    Wiring: selection and connection

    We outline an approach to connecting the receiver feeds through all the various modules to the desired back end sampler ports. The navigation of the system is done by reference to the cabling file (usually named "standard.cabling") which lists all the connections between devices.

    We will introduce a module quality file, which will be used to patch around bad or substandard modules. Each device will have a quality index ranging from zero (out of service) to 3 (working fine), with intermediate values of 1 (working badly) and 2 (usable but substandard).

    The user can specify what quality level to try for. After the configurator does its job, a message will tell the user which paths are substandard or out of service.

    The receiver and beam keywords tell which front end feeds are to be used. From each feed there will be 2 paths, one for each polarization. Start with the first feed and find the connections to the IF Rack. Use the lowest numbered IF Rack input ports that can be used. Then trace the path for the first spectral window to the converter racks, then onwards to the back end, at each stage choosing the lowest numbered connections that are available, and which are acceptable according to the quality file. For the spectrometer, choose the lowest numbered samplers that can be used.

    After the paths for beam 1, window 1 have been chosen, go through a similar process for beam 1, window 2, and so forth.