• Main INDEX
  • Monthly INDEX
  • PREV
  • NEXT

    User name R. Michaels

    Log entry time 21:49:33 on March 02, 2006

    Entry number 164924

    This entry is a followup to: 164742

    keyword=helicity scaler fixes

    I spent some time today analyzing the "ring buffer" data, which is the
    30 Hz data from a subset of scaler channels (charge, triggers, L1A, and
    helicity/QRT bits). Those data look good, even for the runs which had
    large "time loss". Combining this with Richard's analysis, I'd say the
    helicity info is mostly ok (maybe ~1 glitches per hour ?).

    The LNE signal which loads the scaler was narrow (100 nsec). So I took
    a fatter copy of this. I worry it would not be in spec for this signal.
    Also, one source of "time loss" is that the helicity gated scaler and
    the non-helicity-gated scaler don't start at exactly the same time. I
    had trouble doing this, for lack of logic modules and the fact that the
    scalers are not in the trig. super. crate. At the moment I have this
    time slewing down to <= 2 sec. It's the best I can do for now, and
    probably good enough.

    Last thing I did was to modify the online packaging so that it wouldn't
    reject data, it continues to use the predicted helicity after that is
    loaded at start of run. I now keep track of the errors silently in
    the datastream and will check offline to see what's going on (not
    obvious). I am pretty sure the ring buffer is ok, and that's the real
    data anyway. The online packaging is only a convenience to serve various
    clients like xscaler and halog end-run summary, etc.

    Ready to run ...


    A copy of this log entry has been emailed to: rsholmes@jlab.org,paschke@jlab.org,jones@jlab.org