Modifying the GBT Observing System to support dual pulsar backend operation.
This page describes the requirements for, and capabilities of the GBT observing system (primarily Astrid and the config_tool) for dual pulsar backend operation. As noted above, this version is a draft for discussion.
. The intent is for the science group to specify what would be desirable, and the software and electronics groups to comment on what is possible, with very rough estimates of effort, or suggestions for alternative, simpler, ways of doing things. Once the discussion is complete, draft status will be removed.
This specific requirement for dual band operation is to allow GUPPI to be run in parallel with VEGAS in pulsar mode (henceforth VPM, to emphasise we are not
talking about VEGAS spectral line operation), in order to confirm the correct operation of VPM, and transfer timing solutions. We do not
intend to develop a general case solution for dual backend operation. We anticipate that this mode of operation might be used for ~ six months to one year. We would like the solution to be as "integrated" as possible, but GUPPI can always be configured by stand-alone python routines, so we can trade off completeness for ease of implementation, if necessary,
GUPPI only has one "bank". So, multi-bank operation of GUPPI is not relevant. VEGAS has eight banks, and will be used in pulsar mode in this fashion (e.g. to cover high frequency receivers). But there is no need to support VEGAS in multibank mode simultaneously with GUPPI.
The basic operational steps are therefore:
- Configure an appropriate IF path from the selected receiver to both GUPPI and VEGAS
- Both GUPPI and VEGAS are connected to the Converter Rack, but use different input frequencies. VEGAS is a baseband sampled system, and GUPPI is bandpass sampled. So different converter modules will be needed for each.
- Configure a "spectral window" (bandwidth, number of channels) in each backend.
- VPM is specified to provide modes with the same bandwidth and number of channels as the existing GUPPI modes. Some bandwidths (100, 200...) are currently not legal, but these will be added to the VEGAS Mode Table as they are developed for Pulsar observing. The VEGAS Manager will need to have a mapping of observing mode to legal bandwidths in that mode.
- Balance each backend:
- Converter Rack attenuator settings.
- VPM will have internal "requantization" gains, as the spectral line modes do, and are essentially the equivalent of the guppi.scale parameter.
- We will not try to automate setting of the guppi.scale parameters. The appropriate settings could be read from a lookup table, keyed by mode/bandiwdth/channels, but this is orthogonal to dual-backend operation.
- Configure the observation parameters:
- swmode (e.g. "tp_nocal")
- swtype (e.g. "none")
- swper (e.g. 0.04)
- swfreq (e.g. 0.0, 0.0)
- tint (e.g. 6eE-06)
- swper and tint are flipped compared to spectral line backends. This is what lets GUPPI have an integration time of 64us, but have the receiver switching the cal diode at 25Hz.
- This means VPM modes will have a different configuration check than Spectral Line modes.
- set any backend specific keywords (e.g. guppi.datadisk).
- Start an observation, specifying the scan length
- Monitor the observations
GUPPI has three observing modes (specified by the guppi.obsmode keyword): search, fold, or cal. Cal is a special case of fold-mode data, where the cal diode (controlled by the ss as the switching signal master) is switched at nominally 25Hz, and the data is folded with the appropriate frequency. VPM should support the same modes. As a consequence:
- We propose that for this mode, VEGAS should be the switching signal master, so that it can operate independently of the DCR.
- Since both backends will see the same switching signals, and they use the swper parameter to set the folding period, their switching periods (swper) must be the same.
VPM will not have "subbands". Hence the vegas.subband parameter is irrelevant, and should be ignored.
- Changes must be backwardly compatible for GUPPI-only observing (i.e. existing GUPPI scheduling blocks should be able to execute unchanged).
- In dual-backend operation, only one VEGAS bank will be used (no need to support dual backend operation with GUPPI looking at a portion of the total VEGAS band).
- The requirement is to support simultaneous operation of VEGAS (in pulsar mode only), and GUPPI. No other backend combinations need be supported. This mode will be designated in the configuration by:
config = """
obstype = "Pulsar"
backend = "VEGAS/GUPPI"
(no spaces between the backend names and the "/"). The order of the backends is required to be VEGAS/GUPPI.
- The config_tool must route the appropriate IF paths to both VEGAS and GUPPI
- Only the basic VEGAS configuration keywords may be specified. This implies
- One restfreq, which will be used for both VEGAS and GUPPI
- One dopplertrackfreq, which will be used for both VEGAS and GUPPI
- One bandwidth, which will be used for both VEGAS and GUPPI.
- this will limit the max bandwidth for VEGAS to be 800MHz when used in conjunction with GUPPI
- One nchan, to be used for both VEGAS and GUPPI
- The restfreq dictionary form may be supported, depending upon ease of implementation.
- vegas.subband is irrelevant, and will be ignored.
The following keywords will apply to both GUPPI and VEGAS
It would be desirable, but not essential for tint to be the same for both backends. If this is not possible (e.g. because the FPGA clock frequencies are different in the two backends for example), then this is not essential. In that case, a new guppi.tint
keyword will be required.
One option would be for VEGAS and GUPPI to be independently balanced, using the optional backend argument to the Balance() directive, i.e.
- Note, since directives with this parameter do not balance the receiver or IF, the above approach might also require (in advance):
Alternatively, and preferrably, the default could be to balance both backends in the "VEGAS/GUPPI" configuration. In that case, a simple:
Directive could be issued.
Options will be chosen based on the ease of implementation.
Parameters in the observing directives, in particular the scanLength, will be passed to both backends, via the Scan Coordinator
Other device parameters
If necessary, guppi.xxx and vegas.xxx parameters may be used to configure each backend respectively. If necessary, device.xxx keywords could be used to over-ride the device independent keywords.
- GUPPI, and in future VPM will need to obtain real-time information (e.g. sky frequency for de-dispersion mode) from the gbtstatus.
- Since both machines will be configured to have the same center frequency / bandwidth, we do not anticipate the need for any changes to gbtstatus, but this should be investigated.
- VEGAS will be configured exactly as if it were the only backend.
- GUPPI will also be configured as if it were the only backend
- Complete IF paths from the requested receiver to GUPPI will be fully specified and configured
- "real-time" status information (e.g. sky frequency) will be obtained from the gbtstatus database,
- GUPPI and VEGAS observations will start on the same second, synchronized by the current ! ScanCoordinator / 1PPS mechanism.
- The GO FITS file is not used by any standard pulsar data analysis software. Does Dual-Backend operation have any implications for this?
- Anything else we need to consider?