Make New Entry,
Make Followup Entry
User name R. Michaels
Log entry time 12:43:47 on August25,2009
Entry number 285884
keyword=Oversampling - working, sorta
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.