This section covers the scheduling of wide bandwidth observations. With the older tape and MARK5A systems, that means 512 or 1024 Mbps using or using a large number of "tracks" on disk. With the digital backends (RDBE and DBBC) and newer recording systems (MARK5C for now, maybe X cube or MARK6 later), completely new systems are involved. The first couple of paragraphs below are about the old systems. Then the section goes into more detail about the new digital systems.
OLD SYSTEMS:
With the Mark5A recording system, the maximum bit rate that can normally be recorded is 1024 Mbps on a Mark IV system and 512 Mbps on a VLBA system. These rates are recorded on a single module, unlike in the tape era when 2 drives or 2 heads were required.
SCHED can make schedules for the 512 Mbps and 1Gbps modes. See the examples eg512.key for a VLBA only case and eg2head.key for a PCFS (MarkIV) case. Since the advent of disk recordings, for the user, these modes are not much different from other modes. The VLBA telescope schedules indicate use of the wide band mode simply through the specification of track numbers above 64. Note that the two examples do either only VLBA or only Mark IV, but it is ok to mix them.
NEW SYSTEMS:
New digital backends and a new recording system are under test and are just starting to be used for science for a few projects as of this January 2012 writing. These will increase the available bit rate to significantly higher values. The RDBE/Mark5C system developed at Haystack and NRAO will initially record 2048 Mbps which will increase to 4096 Mbps eventually, assuming funds can be found. The DBBC system, developed in Italy and also using the Mark5C recording system, is being deployed on a similar time scale and will have similar bandwidths. Other, even wider bandwidth, recording systems are under development but will not be discussed here yet.
The RDBE (Roach Digital Backend, where ROACH is the core board containing a large FPGA) is a module that takes in 2 analog IF signals, applies an anti-alias filter that passes 512 to 1024 MHz, sets the power levels, samples the signals at a 1024 MHz sample rate (8 bit samples at this stage), digitally filters the data to the final basebands, resamples the data to 2 bits, and formats it for recording. It takes the place of the IF distributers, baseband converters, samplers, and formatter (including pulse cal detectors) in the old VLBA system.
Control of the RDBE and Mark5C recorders is handled by a new VLBA control system running on a standard Linux computer. The new system software is based on the EVLA Executor. Schedule information is given to this computer by way of the VEX file, which is converted by operations to a Python script that is read by the Executor. All new hardware installed at the VLBA for the next few years will use this control system and, probably slowly, the old hardware will be switched over to it. In the meantime, both crd files and VEX files are needed to control the VLBA sites. The in-progress installation of the new 4-8 GHz receiver on the VLBA includes a new RF switch controller that affects all observing bands, so antennas with the full installation require a VEX file and use of the new control system, in addition to the old system (which points the antennas) for all observations. The VEX file is also used by field system stations (EVN and others) for antenna control.
TERMINOLOGY:
Note that the terminology for the various signals has become rather confused. For backward compatibility in SCHED , we call the final analog signal sent to the sampler at 512-1024 MHz the ``IF''. That is broken into narrower bandwidths called ``subbands'' by a polyphase filter regardless of RDBE personality. There is no flexibility to move those subbands around in frequency. The final signal that is resampled to, usually, 2 bits and recorded is called the ``baseband channel'' for purposes of SCHED. The baseband channel might be a subband (PFB personality) or might be further frequency shifted and filtered from within a subband (DDC personality). This terminology differs somewhat from EVLA practice where a baseband is the final analog signal and the final filtered signal is a subband.
RDBE PFB PERSONALITY:
The FPGA in the RDBE supports multiple personalities that can be swapped as needed. The first developed, and only one available in early 2012, is the PFB personality that uses a polyphase filter to break each of the two 512 MHz IFs into 16 basebands of 32 MHz each, all lower sideband. Exactly 16 channels must be recorded, selected from the total of 32 provided from both inputs. This personality is selected setting the DBE parameter to RDBE_PFB in the setup file. Of the 16 subbands of the polyphase filter from each IF, 15 provide good data. The other is really 16 MHz from each end of the 512 MHz, is probably not useful. It is made available for selection in cases where it is desired to have all 16 required channels in one polarization. More typically, 8 channels, constituting polarization pairs, will be selected from each IF input. This personality can only provide 32 MHz basebands at fixed frequencies within the IF for a total of 2 Gbps. Other than selecting the desired subbands, there is no tuning flexibility. Note that eventually there will be 2 RDBE modules at each station to support 4 IFs.
RDBE DDC PERSONALITY (not yet available):
The second personality that will be available eventually is the DDC (Digital Down Converter). It is selected using the DBE parameter set to RDBE_DDC in the setup file. This personality will provide a few (maybe 4 or 8) filters per RDBE that can provide arbitrary offset frequencies and can provide any bandwidth at the factor of 2 steps between 0.125 and 64 MHz. There is a complication forced by the use of a polyphase filter first step of filtration to get the clock rate down to values the FPGA can support. Such filters do not have flexible frequency ranges. This one splits the band into 3 segments, 512 to 640 MHz, 640 to 896 MHz, and 896 to 1024 MHz. Each baseband must be confined to one of those ranges. The ``crossover'' frequencies at the filter edges have a range of something like 4-10 MHz (to be determined) that is not really usable. SCHED will issue a warning if an attempt is made to have a baseband cross one of these boundaries.
The frequencies for the band edges in the DDC personality can be set
to any multiple of
MHz = 
Hz in principle.
But values that are not integer Hz would cause problems elsewhere -
mainly with returning to phase after changes. The smallest allowed
value that qualifies is 15.625 kHz. One way to look at the allowed
values is that they are N*125 kHz plus 0, 15.625, 31.250, 46.875,
62.500, 78.125, 93.750, or 109.375 kHz. For the moment, it is best to
stick to multiples of 10 kHz (the step in the BBCs of the old system)
until we determine that there is adequate precision everywhere. The
only way to do the is with multiples of 250 kHz.
VLBA TUNING RESTRICTIONS:
The overall LO/IF/RDBE system on the VLBA will have some significant tuning flexibility issues. The RDBE is an addon to the older system where the baseband converters, which could take only a small portion of the 500 MHz IF, provided the necessary flexibility. The LO/IF system that creates those IFs is based on synthesizers that have set points at N*500+-100 MHz. Now, with the ability to take all of an IF, that restricted tuning ability will become an issue, especially in conjunction with the lack of tuning ability for the PFB personality and the crossover points for the DDC. Essentially all frequencies can be reached using more than one LO setting, so no cases have been identified where a particular spectral line cannot be observed. But full tuning flexibility that might be desired is not there. Eventually we hope to upgrade the front end synthesizers to designs with more tuning options, and in fact design and prototyping of such a system has started, although deployment is not yet funded (Feb 2012).
Note that, for the initial /schedb implementation in place (versions 9.4, through at least 10.1) the code to provide default channel frequencies based on the band has not yet been written. It is necessary to give the frequencies in the setup file. See the simple examples. The defaulting capability will be added eventually. But for now, the upper-edge baseband frequencies with PFB personality must be from the following list: 1040.0, 1008.0, 976.0, 944.0, 912.0, 880.0, 848.0, 816.0, 784.0, 752.0, 720.0, 688.0, 656.0, 624.0, 592.0, 560.0. These can either be selected directly using the BBSYNTH setup file parameter, or values of FREQREF and FREQOFF can be selected so that the difference between the desired baseband frequency and the signed sum of all other LOs is one of these values.
EXAMPLES:
Example SCHED input (.key) files for observations using the new systems are:
egrdbe2.key which is a reasonably simple case.
egrdbe.key which demonstrates more fully specified setups and demonstrates scheduling of piggyback Mark5A and Mark5C observations.
eg3mm_rdbe.key which shows how to use the piggyback scheme to do maser reference pointing while recording on the RDBE/MARK5C system with the PFB personality.
egddc.key which uses the DDC personality of the RDBE (do not consider this complete yet).
REFERENCE POINTING WITH THE RDBE:
As of Feb 2012, one weakness of the available system is that reference pointing on masers requiring doppler setting cannot be mixed with PFB personality observations. The use of the DDC, or high overheads for personality changes, may be required. For now (early 2012), the best way to handle such observations is to schedule the project as as a piggy-back project with a separate non-recording Mark5A schedule that does the pointing using the old system. The example eg3mm_rdbe.key shows how this is done for a 3mm observation while more extensive information about setting up piggyback observations is contained in the example egrdbe.key
DBBC:
The DBBC being developed for the EVN is also a system that samples at 1024 MHz and digitally filters the signals to the desired bandwidths. But it has a different design where, like with the old BBCs, the frequency can be set flexibly anywhere in the IF band without concern about crossover frequencies etc. The DBBC design has a module for each output baseband, so they are more directly comparable to BBCs. More information is needed about the system to flesh out this discussion.
OTHER DIGITAL BACKENDS:
There is a varient on the RDBE being developed at Haystack for mm VLBI that has 4 input IFs and does not attempt any filtration. It simply samples and formats the data and sends it to the recorders. It can put out 8 Gbps. This device is not yet supported by SCHED.
When the DAR is the RDBE, the output channels and all the input channel information given to SCHED are written to the VEX file. But the crd files that control the old VLBA hardware also has to be told something. SCHED does not have a separate set of variables for all those configuration parameters, so it just does something reasonable. It sets the number of channels to the maximum of the number requested and 8. It sets the frequencies to cover the middle of the RDBE basebands and the sidebands to match the RDBE basebands. It sets the sample rate to the maximum of that requested and 32 Ms/s. It sets the channel bandwidth to the lesser of the request and 16 MHz. It only writes the first 4 pcal extraction requests (avoiding going into channel numbers that are too high). Recording on the Mark5A system is not requested.
PARALLEL MARK5A and MARK5C RECORDINGS:
Normally when scheduling a project that uses the RDBE/MARK5C system, SCHED creates control files for the old system (.crd files) that drive the telescope and other systems, but do not cause MARK5A recordings to be made. Since SCHED does not have adequate bookkeeping to allow independent specification of frequencies for both systems in one pass, a reasonable choice of frequencies and bandwidths for the old system is made based on the capabilities of that system and the settings for the new system.
During testing of the RDBE/MARK5C system, it is useful to have a parallel Mark5A recording. If the default choices of frequencies and bandwidths for the old system is adequate, SCHED can be told to make MARK5A recordings using parameter switch /htmlrefDOMKAMP:DOMKA. The only way to check what those settings are is to look at the output .crd files. Because of the limited bookkeeping, that information does not appear in the .sum file.
If the user does not want to take the Mark5A setups provided by SCHED with DOMKA, then the run can be set up as a piggyback with separate setups for each system. The scheme for doing was mentioned above, and is described and demonstrated in example egrdbe.key.