Log entry time 18:03:36 on August25,2009

Entry number 285965

It appears that the rampdelay on R-HRS is important to get the
busy logic right.  This is because of the propogation delay through
the trigger supervisor and via the RS485 cable.

If ovs=0 and integ=13200, want rampdelay=0.
Actually want (integ+rampdelay)<=13200.  
If ovs=1 a rampdelay of 200 or 400 on R-HRS (and zero on CH) 
seems to be important to avoid large deadtimes. 

Using the RightHap DAQ config.

Runs to check 

ovs=0 ... run 11621 ... baseline check.  rampdelays=0.  integ=13200.

Run 11622 ... ovs=1,  R-HRS rampdelay=200, integ=6000
(i.e. oversample-by-2)

In the following, R-HRS rampdelay=200 and CH rampdelay=0.

Run 11623 ... ovs=3 ... integ = 300.  
(i.e. oversample-by-4)
DAQ is very stable at 120 Hz.
Raw data dumps look good.  

Run 11624 ... ovs=9 ... integ = 1100 (reminder, R-HRS rampdelay=200)
(i.e. oversample-by-10)
DAQ runs stable at 300 Hz.
Raw data dumps look good.

I've added some diagnostics :
If you get deadtime-logic errors (no data, or busy timeout)
there is a clear "logMsg" at vxWorks.  Absence of these means
all is well.  
Also, in the datastream the "bad" data inserted is -999 which
is hopefully clearer than +9999.

CRL for R-HRS is happex_test.crl.

17:56
Oops, just realized I had thrown out a data word fa18b0b1.
I put it back in.  Will do 4 quick runs with updated CRL.

Run 11625 .... ovs=9 ... oversample by 10.

Run 11626 .... ovs=3 ... i.e. by 4

Run 11627 .... ovs=0.  Check baseline.