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.

$FREQ;
*
def 8411.49MHz8x4MHz;
     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
enddef;

$BITSTREAMS;
*
def MK5B.8Ch2bit;
     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;
enddef;

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.

$BITSTREAMS block

Parameters in this table are:
Parameter Field Description Type Allowed values Units Comments
stream_def 1 'Chan_ID': Logical channel name &link      
  2 Sign or magnitude bitstream char sign ¦ mag    
  (3) Input bitstream number int 0-31   Designates input pin on VSI-H connector (see note 1)
  4 On-disk bitstream number int 0-31   Designates bitstream number in the recording
  (5) Recorder number int >= 1   Recorder unit number

Notes:
  1. 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.
  2. 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.

-- MarkKettenis - 2009-11-19
Topic revision: r4 - 2011-05-13, MarkKettenis
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