Comments on expanded VSI proposal from Japanese group
Date 1999/6/19 9:08


Dear Alan, Wayne, and Kondo-san:

I have had a look at the expanded VSI proposal from the Japanese group.
Some comments:

1. It was not evident to me from the document what the IRIG-B code format
   is.  I understand that it is a low bit rate TTL signal that contains the
   pps UTC timestamp and I understand that it is generally useful to have
   this code since this spec will also presumably work for real-time LBI.
   However, I'd like to know what the code format is so I can have an
   appreciation of the hardware that will be necessary to decode it.

2. I like the idea of a minimum standard set of software commands/responses
   that any equipment meeting the VSI standard must support.  I would add
   some more commands to this standard set though:

   a) "Hardware Type" command.  This command simply allows another
      piece of equipment (such as a correlator) to determine what piece
      of equipment it is connected to (such as a playback unit).  The
      response simply says what the equipment is (e.g. MKIV, S3, VLBA, MKV
      etc.).  At this point, the (for example) correlator will then be
      able to execute the expanded command set for that piece of equipment
      to determine channelization etc. etc. etc.
      This will allow virtually unlimited flexibility in what (for example)
      playback units can be connected to what correlators -- provided the
      correlator has the s/w drivers for the equipment and meets the VSI
      standard.

   b) A standard playback speed control command that allows a data provider
      to speed up or slow down its output bit rate to allow locking to
      the correlator clock.  I think a standard software mechanism for this
      is a necessity (so that a hardware clock from the correlator is 
      optional).

   c) Enable/disable test vectors (see 7. below).

3. I would like to see an *additional* alternate connector to the one proposed
   in the document from the Japanese group.  This would be a single 'twin-ax'
   connector that supports all of the same signals contained in the spec...
   only in a single high-speed serial format.  Right now, only the connector
   and electrical levels need to be defined to allow bit rates up to 2Gbps.
   As recording technology improves and more data channels are added, it will
   be advantageous to be able to utilize a more compact connection mechanism...
   however, each connector will still carry 16 data lines etc. as defined in
   this spec.

4. I don't agree with the intent of appendix "A1-3. Correlator".  I think that
   each playback machine should be completely independent and should only have
   to synchronize to the correlator by the mechanism outlined in 2 b).  The
   correlator will do its own internal synchronization and wall clock 
   generation completely independent of any external PC or wall-clock provider.
   This simplifies the VSI specification since a wall-clock interface does
   not have to be defined and allows more flexibility in system design.
   If the correlator is connected in real-time, then it will know this 
   using the standard command from 2 a) (above), and will then synchronize
   itself to the data provider. 

5. Is the VSI clock at a constant data rate or at the bit rate?  I think a
   constant highest-rate clock is the best.  Frame synchronization could 
   easily be achieved as is currently done in the S2: the 1 PPS signal is
   asserted for exactly one sample period independent of what the highest
   rate clock is.  This mechanism also works for the high-speed serial
   format proposed in 3. above.   

6. Is the S/W command channel connector and electrical (Layer 1) interface
   defined yet?  If not, my vote is to make it something like RS232 or RS422
   (as a required interface), and something like 10 base-T Ethernet as
   an optional interface.  These are simple and well known.  Also, a simple
   Layer 2 and standard Layer 3 format should be defined.  We've found
   the Layer 2 protocol used in the S2-RCL to be extremely robust...but there
   may be a standard protocol that someone thinks would be better (like HDLC)
   that has silicon devices that completely handle the encoding and decoding.

7. I think that a standard test vector sequence at the sample rate locked to
   the 1 PPS signal should be defined.  When commanded, this sequence would
   be generated by the data provider and would allow BERT testing between
   the connected equipment.  The S2 provides this facility and we have found
   this to be an extremely valuable test that is performed regularly.

That's it...I hope these comments are useful.

Brent Carlson
National Research Council of Canada
Penticton, B.C.
Canada