Log entry time 12:43:47 on August25,2009

Entry number 285884

Followups:

• 285890 08/25/09 14:03 rsholmes pan errors
• 285891 08/25/09 14:04 rsholmes pan errors

Diagnosis of oversampling on R-HRS.

First of all, the electronics is working because if we run
with oversampling and look at monitor-out WITHOUT running CODA,
we see the expected ramping signals, N of them if oversampling
by N.  All 5 ADCs are working !  Timing board is good.

The problem is with the busy logic.  I made some changes in a
CRL happex_test.crl (used only by "RightHap" config at the moment)
which cured this, but I'm not 100% sure about its correctness.
However, from raw data dumps, the data looks ok.  Each event is
different, the data fluctates a bit, etc.  Unfortunately, I cannot 
analyze the data with pan -- see below.

Test runs with RightHap:
Run 11600 .... oversample by 4 (ovs=3 in GreenMonster)
Run 11601 .... no oversampling
Run 11602 .... oversample by 10

The R-HRS deadtime on scope looks good: ~300 usec readout DT.
The raw data dumps look ok.
With Pan I see
Run 11601 lots of complaints about pair synch.
Run 11600 and 11602 lots of complaints about ADC18, unexpected
data type and unexpected channel type.  As far as I can tell by
dumping raw data, this is a false alarm, but ... who knows.
(There were also complaints about ADC18 in L-HRS but that was
easy to fix -- throw them out since they don't exist in this config)

Ideally we'd spend more time on the test crate before attempting
oversampling.  My impression is that some bugs / misunderstandings
have crept into the busy logic of happex*.crl, and that Pan or
the its enviroment are not ready for prime time.  I'm sure it can
be fixed but ... question is whether we will make productive use
of 1-pass beam tonight or should we do the pass-change.