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.
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. |
" "
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 |
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-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' |
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.
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 |
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'.
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:
4.3 Backend
The name of the backend is the YGOR manager name, as listed in the
table, for backends that have managers.
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).
Table 4.5. Possible Bandwidths | |||||||||
---|---|---|---|---|---|---|---|---|---|
Backend | Bandwidth choices | ||||||||
DCR_IF |
|
||||||||
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 |
The details of setting switching phase tables is given in the Appendix, in the section on the Scan Coordinator.
The defaults for Swtype depend on the switching mode and the receiver.
Reasonable defaults depend on the observing type:
Some backends have restrictions on the possible range of Tint,
as detailed in the following table:
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.
Let Fk = Restfreq, and dF = Deltafreq.
For N spectral windows, our configuration keywords will specify
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.)
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.
4.7 Swtype: switching type
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.
4.9 Swfreq: switching frequency table.
In the case of frequency switching, these frequency offset parameters
are sent to the LO1 manager.
Table 4.10.1. Defaults for Tint
Obstype
Tint
Continuum
Swper
Spectroscopy
10 sec
Others
30 sec
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
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.
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:
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)
Fk[i] and dF[i], the list of rest frequencies and offsets,
for each i = 1,N.
(where BW is the backend bandwidth keyword value.)
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.