The data describing a scan can be of different types originating from different devices, e.g., digitally processed radio frequency signals from backends, servo system encoders, sensors in a weather station, or antenna drive motors. Most of this information is sampled from continuously changing quantities. To make sense of the data from these various sources, the data must be aligned based on when the samples were taken. For example, when scanning across the sky, a backend's integration periods have to be matched to their associated (or interpolated) antenna positions. Traditionally, this alignment or collating of data has been part of the telescope control system. But by assigning the integration responsibility to the control system, it becomes difficult to make the selection or configuration of data sources flexible. The system is less modular because the software must know about all the possible data sources and their formats. And being part of the control system, the collating code often acquires real-time constraints in order to keep pace with the various data-producing subsystems.
On the GBT, each data source is sampled at a rate sufficient to track its variability, then time-tagged and written independently to separate files in a common format (FITS binary tables). Each subsystem writes its own data file with no knowledge of other files or the timing constraints determined by other subsystems. The responsibility for collating and integrating data is that of the off-line analysis system AIPS++.[9] Admittedly, the problem for the analysis system becomes more difficult because it is not dealing with ``pre-packaged" scan data. However, the observer now has access to the ``raw" data as collected, and the design allows her/him to run multiple backends and to gather as many DAPs as s/he feels are needed to adequately describe the observation.