VLBI observations require the transmission of raw data samples over very long distances. Progress is being made toward an ultimate goal of doing this in real time over fiber networks. But EVLBI, as such a system is called, is still only used for a small portion of VLBI observing and that is not likely to change in some regions until more affordable access to high bandwidth networks can be obtained.
Most VLBI relies on recording the raw data on magnetic media, and then shipping that media to a correlator where it is processed days to months after the observations are made. Managing those recordings, and the specification of the data streams to be recorded, is a major part of scheduling with SCHED. This section provides background on the various recording systems in use.
Please be aware that recording systems are a technology under rapid development. It is entirely possible that some of the sections here are not entirely up to date.
SCHED was originally written in about 1979 as the scheduling program for global VLBI observations using the Mark II recording system. That was a system capable of recording 4 Mbps on video tape recorders. It was in use in some parts of the world much longer than expected (at least to 2003), but is now gone as far as we know. SCHED version 9.4 and later does not support Mark II.
The wide band recording system in use for VLBI for many years was the Mark III system. SCHED was never a general purpose scheduling program for Mark III observations. Programs SKED and PC-SCHED served that role. However, SCHED was capable of scheduling Mark III observations on systems that used the VLBA control files (VLBA, VLA, and Green Bank). In fact, the output of SKED and PC-SCHED was normally processed through SCHED to produce the telescope control files for these antennas for all except geodetic projects. Mark III is also obsolete, although one Mark III schedule is still in the SCHED test suite. I am not aware of any Mark III systems remaining in use.
The Mark III system was replaced by several other systems with greater capabilities. These include the VLBA, VLBA4, Mark IV, S2, and K4 tape systems. There were correlators associated with each system, and there was a considerable amount of cross compatibility, either directly or through the use of translation machines. The Mark III, VLBA, VLBA4, and Mark IV systems all used the same tape transport, although with different electronics. In their native modes, they used different data formats, but the VLBA and Mark IV systems were capable of reading and writing Mark III data. More importantly, the VLBA and Mark IV systems have a wide range of compatible recording modes that could be correlated together on the VLBA, JIVE, and other correlators.
By 2007, the tape systems were replaced by disk based recording systems nearly everywhere. The early disk systems were plug compatible replacements for the tape drives so most of the data configuration remained unchanged.
The Mark5A system was the most widespread early disk system. It was developed by Haystack Observatory and the Conduant Corporation. As a plug replacement for the tape drives, the Mark5A system still has the concept of tracks.
The Mark5B system is an enhancement that uses the VSI standard interface to record the data channels without all the formatting baggage left over from the tape systems. The Mark5A+ system allows Mark5B recordings to be played on Mark5A playback units, but a minor glitch that nobody is in a position to fix is preventing its use on the VLBA. The Mark5B+ system uses a faster interface and can handle up to 2 Gbps.
The Mark5C system was being deployed in 2011 and is meant to record up to 4 Gbps, although it the initial configuration can be used at a maximum of 2 Gbps. The Mark5C- system is a scheme for allowing lesser Mark5 hardware to pretend to be a Mark5C system for system development.
As of early 2013, the VLBA winding down use of the Mark5A system and is moving most projects over to the Mark5C system. Some other observatories are also moving to Mark5C, but usually with different electronics.
There are other recording systems in use. The Japanese have a K5 system. The Australians are using a variant on the PCEVN system. Also a variety of groups are testing real time VLBI over the fiber networks. This can involve real time correlation, or recording at sites remote from the telescope.
Meanwhile, other potential future recording systems are being investigated.
The profusion of recording systems described in the last section is further complicated by the the possibility of mixing elements of the different systems. There are three elements of each system that must be specified in order to make proper schedules. These are specified in the SCHED station catalog with the parameters CONTROL, DAR, RECORDER and DISK. The first element is the control system — what software (and hardware) is used to control the recording system. The options that SCHED can handle for wide band VLBI observations are VLBA and VEX. Formally, these actually refer to the control file type, although each type currently implies a specific computer and software system. Note that the CONTROL variable has other options, but they imply one of the above two, plus some specific other telescope control files.
The original VLBA control system runs on VME computers using software mainly written for the VLBA. A few other sites (VLA, Green Bank, and one of the systems at Effelsberg) have such systems to control their VLBI hardware. Systems controlled by the VLBA software always consist of VLBA data acquisition racks (DAR — BBCs, formatter etc) and Mark5 disks. During 2010, new Digital Backends (RDBE) and Mark5C recorders began to be introduced on the VLBA. These major changes are being used as an opportunity to upgrade the telescope control systems. The new system is based on the EVLA Executor control system and runs on a standard Linux computer. Information is passed to this system from SCHED via the VEX file. SCHED now writes VEX files for all observations as a result. The new control system will initially just control the new data acquisition system and recorder. A new C-band (6cm) receiver is under construction and it, along with all of the LO/IF switching will be placed under control of the new computer. Over the course of the next few years, all VLBA systems will be moved to the new control. In the meantime, both crd files for the old system and VEX files for the new system will be required.
The VEX option for CONTROL causes SCHED to generate a schedule file in the VEX format, as does the DOVEX main schedule input parameter (now the default). This is the schedule distribution file format developed mainly for the PC Field System (PCFS) and the Mark IV correlators. It is now used by the DiFX software correlator in use at the VLBA and other places, so it is now needed by most if not all projects. It also is needed to control all new hardware being installed on the VLBA.
The PCFS, running on Linux PCs, is used to control VLBA, VLBA4, Mark IV, S2, and MARK5 VLBI hardware at many non-VLBA stations including all of the EVN. It is the descendant of, and replacement for, the control system for Mark III systems. Sometimes this system is referred to as FS9, for “Field System 9”, referring to the earliest version that could handle VEX input.
Systems controlled by the PCFS can consist of a VLBA, VLBA4 or Mark IV DAR connected to a VLBA4, VLBA, Mark IV, S2, or Mark5 recorder. Each combination has slightly different capabilities and requirements. SCHED understands a considerable amount about what these capabilities and requirements are and attempts to insure that the requested observations are possible. However, when doing a large observation with many diverse telescopes, it is best to stick to standard, well tested, observing modes and use the frequencies selected using the setup file parameter BAND.
During the transitions between recording systems, it may not be obvious when the schedules are made which system a station will have. Or stations may have both and want to run observations on one or the other depending on the supply of media. Because of this situation, a separate input, called DISK can be specified in addition to RECORDER in the station catalog. It tells SCHED that the station has a disk system and schedules can be made for it. There is another new parameter, MEDIADEF, which can be TAPE or DISK, that can be used to set the default medium for the station while both are available. The MEDIA parameter in the TAPEINI section can be used to override the default. ┐From this description, it is clear that this scheme was designed for the transition from tape to disk which was finished a few years ago. As new varieties of disk or real-time systems are implemented, changes are likely.
The Mark5 disk-based system has replaced the various tape based VLBI recording systems. This system is a major advance on many fronts including scheduling. To a much greater degree than with previous tape systems, schedulers can ignore the recording system other than making sure that they are not scheduling to record more data than can fit on the disk space that they have been allocated.
SCHED supports Mark5 on the VLBA by including the required commands in the telescope control files (the crd files). For systems controlled by the Field System (PCFS), SCHED writes a .vex file in VEX format with the necessary commands to control Mark5. The Mark5A system is meant as a plug replacement for MarkIV or VLBA tape recorders. It still records the same tracks that would be recorded on a tape system so SCHED must still be aware of management of such issues. Such concerns will be less, or at least different, for more advanced versions of the disk based recording systems.
There are a few controls needed to schedule Mark5 natively. First, the station catalog must show that the station has a disk system. That is done with the DISK keyword. This is separate from the RECORDER keyword to allow a station entry to cover both tape and disk systems during the transition period. There is a station catalog keyword MEDIADEF that sets the default medium to use at each station. SCHED will use that default in the absence of an overriding MEDIA command in the TAPEINI section. Schedulers for most VLBA observations should probably ignore the problem and let operations deal with getting the recording system right by rerunning SCHED just before the observations. For EVN and Global sessions, it should be clear before the session which system will be used.
The examples egmk5vlba.key and egmk5vex.key show how to set up Mark5 observations. Now that the conversion to disk is complete all other examples have been, or will soon be, switched to disk.
SCHED supports VLBI over networks. This can involve real time correlation in which case the data are routed directly to the Network. An alternative might be called ftp VLBI. In this case, the data are recorded at the station, then read back through the Network, or alternatively, sent over the Network and recorded at the correlator, or both. There are a few parameters meant to help control eVLBI observation DATAPATH, GRABTO, GRABTIME, GRABGAP. This documentation needs to be updated more on how eVLBI is actually controlled. eVLBI is in regular use in Europe, but not on the VLBA, mainly because of differences in the availability of affordable network connections of adequate bandwidth.
SCHED is the primary program for scheduling observations on the VLBA and other systems that use the VLBA control system. Not much will be said in this section about the VLBA systems because they are the “native” systems for SCHED and are discussed extensively elsewhere.
SCHED supports Mark IV observations on Mark IV (and VLBA4) antennas equipped with the Field System (PCFS). This is done by creating a *.vex file in the VEX format. The VEX file is a global and self-contained description of the experiment that is scheduled. The *.vex file can be read by the control system (PCFS) and translated (by a program called Drudg) into a list of commands for the telescope, data acquisition system and recorder.
SCHED produces VEX files with “adaptive” recorder control that enables continuous recording on PCFS controlled telescopes, but can only be correctly interpreted by FS9.3.11 (and higher). This aided the VLBA hardware correlator in synchronizing playback, but is no longer of much interest as the sync time with Mark5 disk systems and current correlators, including the DiFX software correlator on the VLBA, do not take more than a second to sync.
SCHED now writes VEX files by default. It can be prevented using the input parameter DOVEX.
Mark IV (MkIV) telescopes are characterized by DAR = MKIV in the station catalog and can only be requested to record in any of the MkIV FORMATs. Most MkIV telescopes only support specific BBC’s (called Video Converters) to be connected to certain IF distribution boxes. SCHED supports “astronomical patching” or a version of geodetic patching — see M4PATCH. The astronomical patching requires odd BBC’s to be connected to either IFCHAN = 1N (normal input, usually LCP) or IFCHAN = 1A (alternate, usually RCP). Even BBC’s have to be connected to IFCHAN = 2N (usually RCP) or IFCHAN = 2A for LCP. Also, you must use at least one of IFCHAN = 1N or IFCHAN = 2N (i.e. a schedule that uses both IFCHAN = 1A and IFCHAN = 2A is not permitted). This can be controlled by explicitly setting BBC. See the details about M4PATCH for the setup implied by the geodetic patching.
In December 2000 the capability to record 512 Mb/s was introduced. This is achieved by recording 64 tracks simultaneously on the tapes or Mark5A. It requires NHEADS = 2 in the station catalogue. All MkIV stations now record using the Mark5 disk-based system. MkIV Stations equipped with Mk5 systems can record data at up to 1 Gbps. This requires DISK = MARK5A in the station catalogue.
Several features are not yet available or supported for MkIV (and MarkIV based Mark5 systems). Some as of late 2004 (some updates in early 2008) are:
Continuous recording has been used widely, however the ability to acquire the information needed to flag data which is recorded during slewing is not universal (though is standard for EVN stations). The SCHED output .flg file can be used by the AIPS task UVFLG if telescope flagging data are not available. In addition users need to insert gaps during continuous recording whenever they want calibration data.
Phase Cal detection at the telescopes is not implemented. This will likely become available with the new digital backends. Also, DiFX is acquiring the ability to detect phase cal tones.
For MkIV (VLBA4) telescopes there is flexibility for controlling when Tsys measurements will be made. Tsys measurements will typically be made at the beginning of a scan if there is a gap in the recording. When scheduling long scans or continuous recording, one may need to insert gaps in order to obtain Tsys data.
In addition to requiring use of tested modes, SCHED will not allow speedup factor changes during mixed VLBA and Mark IV mode observations. This is because of track bit rate dependent delays that are different in the two formats. The correlator would require different clocks for different modes, which is not yet available. Fairly soon, this restriction will be relaxed. Again, MODETEST will turn off the test.
SCHED supports observations on telescopes that have VLBA recorders but are controlled through PCFS. This is also done by creating a *.vex file in the VEX format (see section on MkIV).
The telescopes are characterized by DAR = VLBA and RECORDER = VLBA, but CONTROL = VEX. They can have a flexible number of BBCs, and usually have only 2 IF channels: A & C. The telescopes can only be requested to record in any of the VLBA FORMATs.
In addition DAR = VLBA4 and RECORDER = VLBA4 systems have been introduced. These use the flexible VLBA data acquisition rack, but (DAR = VLBA4) have a Mark IV formatter mounted for recording up to 1Gb/s. Note that these systems write Mark IV formatted data and have been created to resemble Mark IV systems. In this sense their name is misleading. These systems required a RECORDER = VLBA4 in the tape era in order to accommodate 2 recording heads (optional), but now all Mark5A systems can record the requisite number of tracks.
Most of the VLBA racks controlled by the field system have what is known as the “geodetic wiring”. This means that not all of the BBCs can see all IFs. Also, there are not enough sampler inputs do use 2 bit samples from more than the first 8 BBCs. In fact, switching between lots of BBCs at one bit and 8 BBCs at 2 bits requires moving connectors that really weren’t designed to be moved often. This is an invitation for trouble. The IF restrictions are such that BBCs 1-8 can see IFs A and C while BBCs 1, 2, and 9-14 can see B and D. SCHED understands these restrictions in it’s automatic BBC assignment section. Note that, in some cases, the stations will put the same signals on IFs A and B and on C and D. This can be dealt with in the frequency catalog by giving B as the ALTIFN for A and D as the ALTIFN for C (or visa versa). Or, or course, you can specify IFCHAN explicitly in the setup file.