The 192 can take up to 16 scans of data (profiles)
     per channel per cycle.  A cycle is defined to be the period
     between successive "Clear" events.  The source for these
     events may be either from the TEV clock, an external pulse
     input, or a CAMAC command (setup parameter defines which
     one).  The scans are taken on a "trigger" event which also
     may be from the TEV clock, an external pulse input, or a
     CAMAC command.

            Tevatron clock events are sent to the module in the
     same way as the 191 module.  One define up to 256 "Clear"
     events with the module responding in the same way to each
     one.  Similarly one can define up to 256 "Trigger" events
     with the module triggering on each one.  Furthermore, for
     "Trigger" events one can define a delay from the event
     before the module actually takes the data.

            If set in prepulse mode then the 1st scan taken in
     the cycle is the prepulse.  One can have the module subtract
     the prepulse from the data of each successive scan, leave
     the data alone but only subtract the prepulse when doing the
     mean and sigma calculations, or do nothing at all with the
     prepulse.

            As far a negative data is concerned nothing other
     than prepulse subtraction is ever done to the data read
     back.  However, the mean and sigma calculation algorithm
     does not work very well with a mixture of negative and
     positive data.  The following steps are taken to try and
     correct this problem.  
      1.  If the sum of the data in a scan is negative then the
     data used in the calculation (as opposed to that read back)
     is negated.
      2.  An offset is then added to the data used in the
     calculation so that no values are negative.  This offset
     is reported in the data structure read back.

     This procedure along with the entire algorithm may have to
     be modified somewhat when I see how the 192 responds to real
     data.  As far as "correcting" the data read back I am at the
     moment opposed to that because I don' really know if the
     above procedure will work in the general case.  Also in
     order to assure data integrity it would have to be done at
     interupt level as the data is collected thereby increasing
     the time in which the module is dead.  Before I consider
     doing this I would have to be convinced that it is a
     necessity--ie not because somebody plugged the thing in the
     wrong way.

            All downloaded data is accessible via CAMAC commands.
     However many fields are sometimes packed into 1 word.  Glass
     is writting a special driver for the module in which I
     believe all setup parameters (or most) are in 1 buffer
     accessed by one DI.  As such it needs a  The parameters stay
     and the module keeps working until the parameter are changed
     by the host or a reboot or power up is done.  There are some
     defaults so that the module doesn't die.  No module by
     module defaults are envisioned (you would have to a
     different PROM for each module).  Downloading parameters
     from the host is considered perfectly reasonalbe.

            As far as an SA display--you would have to do what
     Glenn is doing in the SA.