[evla-sw-discuss] nonstandard monitor points & other considerations

[Bill Sahr]

This note is just a short sketch of a few ideas that
have been put forward for "monitor points" that might
be useful in the system.

Steve Durand has put forward an idea taken from the 
VLBA M&C system.  Stated briefly, and no doubt with
some mangling on my part, Steve's idea is to use
some of the memory available on the D formatter card
to capture small amounts of raw data from the antennas
(say .1 second worth) that could then be exported
via the MIB for analysis by the engineers.  The
underlying idea is to capture data on a per channel
(or "color", or IF) basis before it is intermixed in
the correlator to allow for analysis and troubleshooting
of the channels.  More specifically, FFTs could be
done (perhaps in Excel or by a utility program) on a 
per IF per antenna basis to allow examination
of the characteristics of each IF.  

Implementation of this scheme would require early 
cooperation with the designer of the the D formatter 
(Zach Barnes ?) and a scheme for downloading this data 
from the D formatter to the external world, probably via 
a MIB.

For information purposes, the D formatter is the "interface"
to the correlator.  Its position in the system is immediately
before the correlator station boards.

In a similar vein, Barry has speculated on the possible 
usefulness of a "monitor point" for a baseline - i.e., capture
of data on a per baseline basis, after correlation and before
the FFT is performed, to be displayed as a data quality check.  
The data capture would be done in the correlator backend, with 
the exporting of the data probably performed by a CMIB.

In the same conversation with Steve Durand, he put forth a
few other ideas.  Steve spoke of the VLBA "readblock"
function.  Again, I may have the details of the readblock
function wrong, but the basic idea is to implement the
capability of specifying a rate and duration for a particular
monitor point, capture that data, and make it available for
export to an engineer's workstation for further, perhaps
special purpose, analysis.  Steve expanded on this idea -
for special purpose, high sample rate monitor data, it may 
be undesirable to archive the data.  An engineer may need 
to capture this data for study, but often the data is not 
otherwise useful or may even be "bogus" in the sense that 
the engineer is simply making initial explorations and may 
not even know, at first, exactly which monitor point is of 
interest to him/her.

So, what I really want to capture here is first, a general
sense of the flexibility we may need in the MIBs - antenna
MIBS (AMIBs ?) and CMIBs, next, that the software engineers 
can benefit by getting into detailed conversation with the 
module designers rather than leaving all the liaison work to 
George & Wayne, and finally, that the specific idea of special 
purpose MIB-assisted data capture and export might be a useful 
capability to consider.