The GBT monitor and control system (Ygor) manages many devices consisting of both hardware and software. The system is designed to be general and flexible such that the observer can configure the system in ways which might not have been realized by the observatory staff. The GBT observer interface (GO) should provide an interface specifically tailored for the observer. GO should employ a layered design. Currently, to configure the GBT using Ygor requires many parameters to be set. GO should be designed such that at the top layer these parameters are set with only a limited number of observer input parameters. Sensible defaults for many of the Ygor parameters will have to be defined. This approach requires that a standard set of observing modes be defined which should accommodate over 90% of the observing proposals. However, GO should allow for complete access to the underlying system, Ygor.
GO should have an interactive GUI with both monitor and control panels. There should be a layered approach where the most important parameters are at the top level. GO should also be able to run in batch mode by executing an observing file or table (GO table). There should be software available to aid the observer in generating an observing schedule. For example, given a list of sources, times, and procedures the software would calculate a complete schedule. In principle, a GO table could be generated. The observer should have easy access to various calibrator lists from within GO.
There should be a well defined and tested process to setup and configure the GBT before the actual observing starts. This process should occur in phases. The first phase would be to initialize the GBT. That is, there should be a default configuration for each GBT device and a mechanism to initialize the system from GO. Second, a limited number of GO parameters (keywords) should be specified which will configure the GBT for the current observations. 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. Third, there should be a testing and tweaking phase where the user has the opportunity to test the system. Additional keywords will probably have to be set. Also, the observer might want to inject a test tone at the front end to check the IF system configuration. Lastly, the observer starts the observing program.
There are several ways to define an observation. That is, how to organize the scheduling and data collection process. Observing procedures should be the standard mechanism to begin an observation. That is, an observation should be defined by an observing procedure. An observing procedure is a function which specifies how to move the telescope and collect data. An observing procedure should consist of one or more scans where a scan is a contiguous period of data collection predefined by a set of Ygor parameters. For example, consider a procedure which consists of a five point map typically used to determine local pointing corrections. The procedure might perform five scans, one centered on the expected location of a pointing source and four at cardinal direction around the center location. Therefore the five point procedure would instruct the telescope to move to these locations and collect data for some specified time. A observing file or GO table may consist of many observations. There should be a number of standard observing procedures available to the user. Moreover, it should be fairly straightforward for the observers to write their own procedures. Also, the parameters which are used by the procedure should be easily accessible in the data reduction package. The observer should be able to configure the system for the next observation while the current one is being executed.
GO should be compact enough such that only one monitor screen can display the relevant information without having to open and close many windows. Multiple instances of GO must be fully synchronized. That is, the remote observer and the operator will necessarily be running GO simultaneously. Actions taken by one user should be reflected by the other. This should include not only the Ygor parameters by GO user-specific parameters as well. The observer should be able to control the telescope remotely.1