Log entry time 19:04:48 on June17,2004

Entry number 126102

BPM12x was flakey at the start of Run 2226.  The ADC was saturating
for all channels for the first 6000 events.

Here's my theory: bpm12 is in the feedback crate.  The FFB system 
"locks" the stripline gains on request; as I understand it, this is
part of the process of FFB starting up and initializing itself.  My
theory is that the FFB locked its gain while the beam was off 
(I think that it is usually actually prompted to do so by an operator.
Possibly this process was started just after the beam tripped off
at the end of run 2225).   So, in this theory, bpm12 locked its gain
at max, and saturated when beam came back.  

Hey, its possible.  You got a better theory?

We have seen this sort of thing before.  Usually the ops 
figure it out and clear up the problem, I think because FFB doesn't 
work in this state.  (I think.  this is all pretty speculative).

Anyway, we do need to keep an eye on bpm12x (which is critical for
our data quality) to make sure its good.  And we need a way of cutting
data with this problem.  Can we add analysis cuts for critical 
channels saturating (like curmon, bpm12, 4b, 4a, detectors)?

Figure 1: First events from Run 2226.