Below is an illustration of the $BITSTREAMS block that we have come up with at JIVE to support native Mark5B
playback at the EVN correlator. For reference, I've include the relevant $FREQ block. This is slightly different from the proposal I mailed out to a small group of people around May 2008.
sample_rate = 8.000 Ms/sec; * (2bits/sample)
chan_def = : 8411.49 MHz : L : 4.000 MHz : &CH01 : &BBC01 : &L_Cal; *Rcp
chan_def = : 8411.49 MHz : L : 4.000 MHz : &CH02 : &BBC02 : &L_Cal; *Lcp
chan_def = : 8411.49 MHz : U : 4.000 MHz : &CH03 : &BBC01 : &L_Cal; *Rcp
chan_def = : 8411.49 MHz : U : 4.000 MHz : &CH04 : &BBC02 : &L_Cal; *Lcp
chan_def = : 8419.49 MHz : L : 4.000 MHz : &CH05 : &BBC03 : &L_Cal; *Rcp
chan_def = : 8419.49 MHz : L : 4.000 MHz : &CH06 : &BBC04 : &L_Cal; *Lcp
chan_def = : 8419.49 MHz : U : 4.000 MHz : &CH07 : &BBC03 : &L_Cal; *Rcp
chan_def = : 8419.49 MHz : U : 4.000 MHz : &CH08 : &BBC04 : &L_Cal; *Lcp
stream_def = &CH01 : sign : 16 : 8;
stream_def = &CH01 : mag : 17 : 9;
stream_def = &CH02 : sign : 18 : 10;
stream_def = &CH02 : mag : 19 : 11;
stream_def = &CH03 : sign : 0 : 0;
stream_def = &CH03 : mag : 1 : 1;
stream_def = &CH04 : sign : 2 : 2;
stream_def = &CH04 : mag : 3 : 3;
stream_def = &CH05 : sign : 20 : 12;
stream_def = &CH05 : mag : 21 : 13;
stream_def = &CH06 : sign : 22 : 14;
stream_def = &CH06 : mag : 23 : 15;
stream_def = &CH07 : sign : 4 : 4;
stream_def = &CH07 : mag : 5 : 5;
stream_def = &CH08 : sign : 6 : 6;
stream_def = &CH08 : mag : 7 : 7;
Each stream_def line refers to a single bitstream. The first field is a reference that connects the stream to the relevant chan_def in the $FREQ block. The meaning of the second field is fairly obvious I'd say ;). The third field refers to the bitstream on the VSI-H input of the Mark5 (the signals referred to as BS0--BS31 in the VSI-H specification). The fourth field refers to the bitstream number that's recorded on disk. While this block was designed for Mark5B
, it may very well be suitable for other systems that are VSI-H compatible.
At first sight it seems somewhat redundant to have both numbers available, since in principle the fourth column is just a "compressed" version of the third column. However, listing both numbers helps avoiding some ambiguity. It also makes it possible to comment out bitstreams without losing information.
We have implemented this block in a test version of our correlator control software, and it seems to work for us. However, we still have to evaluate how this will work with real operations. For now our plan is to have our local correlation job preparation tool append a default $BITSTREAMS block to the VEX file and edit that when appropriate (because a station screwed up, or uses some weird wiring).
Since I believe we should try to keep our VEX files compatible I think we should see whether this $BITSTREAMS block is acceptable to the rest of the community. It's certainly not set in stone yet and if the community comes up with something better, I think we'll be able to change our local software without too much trouble.
Note that this $BITSTREAMS block doesn't address Mark5C
/VDIF in any way. VDIF involves a lot of complexity that this proposed $BITSTREAMS block simply cannot express. And I'm not sure trying to propose something for VDIF without actually having at least a working prototype of a VDIF capable recoding system and correlator will be a good idea.
Parameters in this table are:
|| Allowed values
|| 'Chan_ID': Logical channel name
|| Sign or magnitude bitstream
|| Input bitstream number
|| Designates input pin on VSI-H connector (see note 1)
|| On-disk bitstream number
|| Designates bitstream number in the recording
|| Recorder number
|| >= 1
|| Recorder unit number
- The input bitstream number is necessary to calculate the bitstream mask that determines which bitstreams are to be recorded, as used with the Mark5B mode command.
- The VSI-H interface doesn't really allow a single Mark5B to be connected to multiple backeds/formatters. Therefore having just the recorder number (to support multiple Mark5B's connected to, for example a DBBC) should be sufficient.