• Main INDEX
  • Monthly INDEX
  • PREV
  • NEXT

    User name paschke

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

    Entry number 126102

    keyword=WATCH bpm12

    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.

    FIGURE 1