Summary response to 2021 January 11 to February 12 comment period

First we want to thank everyone who sent comments and suggestions. One helpful benefit of the comments was that it helped focus our thoughts on a couple of the topics. We have made changes for some of the suggestions. For the others, while we agree with many of the them and would like to include them, we are unable to do so at this time because either there aren’t enough resources or the area is not mature enough to set something into the standard. Rather than delay the standard further by trying to incorporate more features, we are making a practical decision to only make minor adjustments. Further changes can be considered later.

A summary of the suggestions and our responses follow. The responses are grouped in rough order of the sections of the VEX2 defining document, The numbered lines contain summaries of the comments that were received. Our responses are indented below them.


1. Make a more formal mechanism for tracking “Known Software Limitations.”

In the best of all possible worlds we would like to see this implemented, but it is beyond the VEX standard itself. For now we are trying to provide some assistance to users by collecting the limitations that we are aware of. Since this is not part of the standard, we have moved this to a separate page: This will allow it to be updated/expanded/replaced as needed without modifying the standard itself.


1. Add acceleration for the antenna_motion parameter

We have added an (optional) fourth field for acceleration and clarified the description of the constant (previously called settling time) field.


1. Provide a more virtual description of a data stream than VDIF and VSI

This would be desirable. The sentiment to move away specific systems was motivated by a desire to reduce the detail provided for those that do not need it. Practically speaking, VSI and VDIF are deeply entrenched in the data processing and that will continue for some time. We expect VSI to fade away eventually. While not completely generic, the $DATASTREAMS block describes the data in a fairly general way. This issue should be addressed when the community sees a need for a new data format standard.


1. Establish a central registry of “extensions” for the $EXTENSIONS block.

The $EXTENSION block is seen an area for experimentation and to deal with ad hoc issues within an organization. Its use is discouraged. Other mechanisms within VEX should be used when possible. There are useful options for some issues in the $DAS block. We have added the text to the $EXTENSION block section to point these issues out.

The extensions are keyed by organization, which should be responsible for the extensions. In the future, if it becomes necessary, we will add a registry of organizations, but we do not expect any significant conflicts.


1. Don’t remove the $PROCEDURES block

It is only deprecated at this time. However, this block is specific to one system and in the more the 20 years of VEX has yet to be used by that system. When this information starts to be used, we recommend encoding it in equip_set parameters in the $DAS section. The description of equip parameter has been expanded slightly to make clearer that it (and the other equip related parameters) can be used for software.


1. The $SCHED block should not be in the VEX parameter tables.

Although it contains some parameters, the $SCHED block is not a VEX primitive block. To make this distinction clearer, we have moved the description of the $SCHED block to be a section after the “High Level block" section. This section describes the role and form of the $SCHED block and its parameters.

2. The distinction between source keyword and source names in the $SCHED and $SOURCE blocks should be eliminated.

This is fundamental to the structure of VEX and cannot be eliminated. Additionally, there are users that would like to exploit this distinction. Unfortunately, some initial implementers (including ourselves) of VEX did not adhere to this distinction properly. Note 6 (formerly Note 5) in the $SOURCE block provides a roadmap to minimize the risk of confusion, but also allows those who need to use the distinction to do so.

3. Add support for multi-beam systems with changes to the $SCHED and $SOURCE block.

We agree that support for multi-beam systems is important. This is largely met by treating each beam as a station, much as phased arrays are. A note was added the $STATION block to highlight this point. Additionally, we have expanded the source parameter in the $SCHED block to include a possible list of stations for which it applies. This should cover some important cases that exist or are coming soon. Further refinements are deferred for now, with the expectation that we will solicit input from operators of multi-beam systems when what is currently available is no longer sufficient.


1. Remove: FIXME: remove source_type options earth_satellite and ephemeris as these are not well enough defined at this moment.

These parameters are being retained for now in case anyone is using them, but it is expected that bsp files will eventually supplant them.

Note that support for bsp files will need to be implemented at the stations and correlators before it can be used in schedules.

2. Clarify for source type “earth_satellite” whether the “longitude of the ascending node” is longitude from Greenwich or Right Ascension.

We are reluctant to clarify this at this time. We don’t think anyone is using this source type and would like to get input from actual users when it is used. As noted above, we expect use of Earth satellites in the future will more likely use the bsp source type.

3. Will satellites of other planets be describable as sources in VEX?

We expect bsp files will be used for this eventually.

4. Add a parameter for parallax

For practical reasons, we can only support catalog positions in RA and Dec at this time. For sources where annual parallax is significant, the position of the source at the observation epoch, reduced to the mean epoch, can be used. The $EXTENSION block could used for experimentation with a parameter for parallax. Depending on its use, it might be incorporated more directly into the standard.

5. Add a parameter to specify the time coordinate for source type ephemeris, retarded and non-retarded.

For now, we have made explicit that the time coordinate is UTC.

6. Drop B1950 coordinates

Some users may still need them. The option to use it should not bother those who do not.


1. Some combination of $STATION, $SITE, and $ANTENNA blocks are redundant. $SITE should be eliminated, merging it into $ANTENNA or $STATION.

The function of the $STATION block is quite different from that of the other two blocks and the others cannot be merged into it. The separation of parameters between $SITE and $ANTENNA is appropriate for their function. Additionally, merging $SITE and $ANTENNA at this time would significantly complicate maintaining backward compatibility with VEX1.

2 . Add parameters to $STATION for phased array position information.

The $STATION block does not contain parameters, only references. For a phased array, the position information in the $SITE block is the position of the phased array, not of the individual antennas that make up the array. A note was added the $STATION block to clarify this point.

Topic revision: r5 - 2021-08-01, EdHimwich
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback