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.
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. |
" "
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 |
Keywords dependent on the receiver choice | |||||||
---|---|---|---|---|---|---|---|
Keyword | Receiver(s) | Default | possible values | ||||
Polarization |
|
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' |
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.
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.
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.
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.
Mapping between Switching mode and the setting of Scan Coordinator phase table is described in the following table:
Switching Mode | Phase Table | Blanking time | |||||||||||||||
tp (i.e., total power with cal)
[except for Spectral Processor case below] |
|
0.002 sec | |||||||||||||||
tp (if using Spectral Processor and Velocity frame not Local) |
|
0.040 sec | |||||||||||||||
tp_nocal |
|
0.0 sec | |||||||||||||||
sp_nocal |
|
0.002 sec, or 0.04 if using the Spectral Processor for frequency switching. | |||||||||||||||
sp (switched power with cal) |
|
0.002 sec, or 0.04 if using the Spectral Processor for frequency switching. |
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.
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.
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:
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:
Determine the center frequency and total bandwidth:
How these quantities are used:
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.
Now we can determine the appropriate frequency settings for the LO2 synthesizers:
(where IF3 comes from Table 4 and depends on the chosen back end.)
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.