• Main INDEX
  • Monthly INDEX
  • PREV
  • NEXT
    Make New Entry, Make Followup Entry

    User name R. Michaels

    Log entry time 22:10:42 on February19,2011

    Entry number 347726

    Followups:

    keyword=helicity checks of hardware (II)

    Upon access I checked the helicity-related signals. On infinite
    persistence I could see some "extra" pulses on some signals (pattern
    synch), so I decided to try another fanout. I moved all the signals
    and improved the timing, but things don't change qualitatively.

    The fraction of events which don't miss the pattern were measured
    with higher stats with another new check code, "CheckAlot(n)".
    The result was 7 bad events in 2e5. I could not solve this problem
    and unfortunately must go home now.

    The other problem (probably related) is that almost immediately
    after loading the 30-bit seed, the helicity prediction disagrees
    with measurement. It is really "as if" the helicity board is not
    working, but Qweak says it is. So, I'm guessing the seed isn't
    loaded right (bogus data due to the noise). Note, this part of
    the VME check task worked from Sept - Dec 2010, so it's not simply
    a bug. I don't know what is wrong. We need more offline analysis to
    find the pattern of failure. Probably the data are all recoverable,
    we certainly have a lot of redundant info (clocks, multiple inputs
    to the DAQ, etc), but without good offline analysis we cannot say
    for sure. The recovery will probably require more intelligence
    in the algorithm exploiting the rigid patterns that are expected.