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

    User name R. Michaels

    Log entry time 12:50:23 on December 05, 2010

    Entry number 342897

    This entry is a followup to: 342819

    Followups:

    keyword=re: timing shifts

    It's a little hard for me to tell what's going on from home, but a
    trigger-related timing shift can result if the L1A has become late.
    
    What was done prior to the experiment (by Hisham and Charles):
    All correlated triggers were lined up at the TS input to within 10 nsec.
    The RT signal arranged to come 30 to 60 nsec after the L1A.  This is
    a somewhat delicate nanosecond-scale setup, so if "blind" changes are
    made to the trigger and nobody checks the timing ...
    
    If the RT is too late or absent, one may get "forced retiming" 
    characterized by a massive shift in VDC time spectra of order 250 nsec.
    You have to look on a broad scale (don't artificially chop it out with
    narrow histogram limits) and check if the VDCs have a shadow distribution
    that is massively shifted for some events.  I suppose that is NOT the
    case here, although I have not seen this spectrum lately.
    
    If the RT edge (transition) is too early (or equivalently L1A too late)
    but the RT logic-true level still overlaps with L1A, then the frontend
    gates will follow the trigger timing and if there is a timing split
    between triggers, you can get shifts like what is observed.  The splits
    shown in halog are on the order 40 nsec, so I guess that's what is
    happening.
    
    I don't know what changes have been made with the trigger lately, but 
    if there are delays introduced without checking these timings, then
    this sort of timing shift can occur.  Whether its a problem or not
    I don't know.  It might not be a disaster but just require some new
    timing calibrations.  Or it might start chopping into ADCs with wrong
    gate timing.  Hard to tell.