• Main INDEX
  • Monthly INDEX
  • PREV
  • NEXT
    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.