How should GO be used? Ultimately this should be left to the observer. However, because the GBT has many possible modes there should be software in place to aid the user based on general experience using this system. Because there are hundreds of Ygor parameters there should be some mechanism to set these parameters to some sensible default settings. For example, under most circumstances the observer will want to use refraction. There may be instances where this feature has been deactivated, e.g., during maintenance. Therefore there should be a way to set all parameters to some default (``normal'') setting. At the next stage, once the Ygor parameters are set to their default values, there are still device parameters which must change. This is a result of the variety of front-end receivers and back-ends which are available with the GBT. Therefore there should be software within GO which configures most of the system based on a limited number of keywords. Third, there should be a phase where various tweaking and testing can be done to verify that the system is ready for observations. Lastly, the observations begin. Below we discuss these stages in more detail.
There should be a default configuration for each GBT device which can be set from GO. This is necessary since during maintenance, for example, some Ygor parameters may be set to non-standard values. It should be possible to initialize the system from a GO table. This could be done by including a Glish script from within a GO table or by running a GO table itself. The observer should not have to learn Glish to configure the system and any initialization scripts written in Glish are expected to be written and maintained by the observatory staff. These default settings must be well documented. Also, it is desirable that they do not change often.
There should be a limited number (
) of GO keywords which act
like meta-parameters and will configure the system for an observing
run. That is, the router switches, the adjustable filters and local
oscillators, and the attenuators will be set by GO such that the
proper IF power is being sent from the front end to the back end. GO
will have to choose several default settings when the solutions are
degenerate. For example, if there are two paths that a particular IF
signal can get to the specified back-end GO should choose one as the
default. In practice more than one observing mode might be configured
before the observations begin. For example, the observing run might
consist of some pointing observations using the digital continuum
receiver and then a spectral line experiment using the correlator
spectrometer. Below is a list of the GO meta-keywords.
1. receiver: The front end receiver to be used. Only one receiver can be used at a time (Table 1). The keyword values are given in terms of wavelength. For example, to select the L band receiver sc.receiver = '21cm'.
| Band | Freq. Range (GHz) | Keyword Value |
| PF1 (1) | .290-.395 | 90cm |
| PF1 (2) | .385-.520 | 75cm |
| PF1 (3) | .510-.690 | 50cm |
| PF1 (4) | .680-.920 | 35cm |
| PF2 | .910-1.23 | 30cm |
| L band | 1.15-1.73 | 21cm |
| S band | 1.73-2.60 | 15cm |
| C band | 3.95-5.85 | 6cm |
| X band | 8.00-10.1 | 3cm |
| Ku band | 12.0-15.4 | 2cm |
| K band (L) | 18.0-22.4 | 15mm |
| K band (U) | 22.0-26.5 | 12mm |
| Q band | 40.0-50.0 | 7mm |
2. obs_mode: The observing mode which specifies the back end and type. Table 2 lists the different modes. Notice that only one back-end can be selected at a given instance. A mode could be included which used multiple back-ends, however. The possible back-ends are digital continuum receiver (DCR), correlator spectrometer (SPM), spectral processor (SP), Berkeley-Caltech pulsar machine (BCPM), and VLBA.
| Back End | Mode | Keyword Value |
| DCR | Continuum | dcr |
| SPM | Spectral Line | spm_line |
| SPM | Pulsar Timing | spm_pulsar_timing |
| SPM | Pulsar Search | spm_pulsar_search |
| SP | Spectral Line | sp_line |
| SP | Pular Timing | sp_pulsar_timing |
| SP | Pulsar Dedispersion | sp_dedispersion |
| BCPM | Pulsar Timing | bcpm_pulsar_timing |
| BCPM | Pulsar Search | bcpm_pulsar_search |
| BCPM | Pulsar Monitoring | bcpm_pulsar_mon |
| BCPM | Pulsar Voltage Monitoring | bcpm_pulsar_vol_mon |
| VLBA | VLBA | vlba |
3. switch_mode: During an integration or scan it is common for the state of several parameters to change on times scales which are small compared to the integration time or scan time. For example, calibration of the intensity scale is usually determined by injecting noise into the system ON and OFF. Also to remove instabilities in the system a reference spectrum is usually determined for spectroscopy. Any ``switching'' that employs the primary or secondary optics should be placed into separate scans. Of course this need not be the case and might not be feasible if the scan duration becomes small. This will probably not be the case with the primary since the overhead would be too large but may indeed be significant for the secondary. Experience with the system will be required.
The following modes discussed below should be defined: 'tp', 'tp_nocal', fsw_01', 'fsw_12', 'fsw_0102', 'psw_01', 'bsw_01', 'user'. The obs_mode keyword will decide what back-end will control the switching. In all cases except for total power it is assumed that the noise diode will be fired ON and OFF. If for some reason the user does not want one of the standard modes they need to explicitly define the switching mode with the option 'user'.
(i) Total Power (tp): In this mode there is no reference signal and the Sig/Ref state is always SIG (Table 3). When this mode is selected the user typically is employing total power position switching where separate integrations or scans are taken both ON and OFF the astronomical source.
(ii) Total Power without CAL (tp_nocal): This is the same as tp except that the cal is not fired (Table 4). This is necessary if the observer decides to fire the cal between scans.
(iii) Frequency Switching (fsw): The reference spectrum is determined by
switching between the desired frequency and one or two reference
frequencies. Three fsw modes should be specified and are shown in
Tables 6, 7, and 8. 
is the signal frequency offset
(typically zero), 
is the first reference frequency
offset, and 
is the second reference frequency offset.
The first fsw mode (fsw_01) is a simple frequency switching where
only one offset is used. The second mode (fsw_12) is a symmetric
switching which uses two reference offsets. The third mode
(fsw_0102) is similar to the first mode except two reference
frequency offsets are used, presumably to remove a first-order,
frequency dependent gain term in the front end passband. Typically
but this need not be the case.
(iii) Polarization Switching (psw): Switching between different orthogonal polarizations can help minimize instrumental effects such as receiver gain drift. A switch is used in the front end which toggles the orthogonal polarizations between a given IF output. In Figure 8 XL refers to either X-linear or LCP and YR to either Y-linear or RCP.
(iv) Beam Switching (bsw): For frequencies above 10GHz there are two or more beams continuously on the sky. Therefore switching between beams is possible by toggling an electronic switch between two states and no optics are involved. An example is given in Figure 9 where only two beams are considered (1 and 2). Note that the Q band system has four beams and additional bsw modes will have to be added.
There are many more possible switching modes which can be left up to the user to define explicitly. If one of these other modes becomes popular it can be added to the list of standard modes.
4. rest_freq: An array of rest frequencies specifying the rest frequency of the center of the band for each channel. For example, if the observer wants to observe 4 transitions centered at 8400, 8500, 8600, and 8700MHz each with a bandwidth of 50MHz then rest_freq = [8400, 8500, 8600, 8700]. Notice that the number of IF's is implicit in the rest_freq array size.
5. bandwidth: An array of the bandwidths specifying the desired bandwidth of each channel. In the example above bandwidth = [50, 50, 50, 50]. Table 10 lists the possible back-end bandwidths available.
Once the basic connectivity is established the observer may want to check that the system is indeed configured properly. Are the power levels reasonable? Are the frequency conversions correct? A testtone could be injected into the front-end receiver and detected with the back-end for analysis. The observer may wish to test the setup using an astronomical source. There should be some basic tools for such an analysis. This should be an interactive phase which could be performed by the observer or the operator. The observer may feel that the system is robust and the observing setup reliable enough that this phase can be skipped. As experience is gained with the telescope more automatic testing could be implemented.
Lastly, the observations are initiated. This might be via the GO GUI for a single observation or a GO table for one or more observations.
offset