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

    User name R. Michaels

    Log entry time 15:12:13 on July 08, 2010

    Entry number 330820

    This entry is a followup to: 330812

    Followups:

    keyword=re: fEvtHdr.fEvtType vs D.evtypebits

    Sorry, this little problem Ole re-discovered is a time bomb, but
    not a real problem.
    
    The trigger supervisor is programmed to give the "CODA event type".
    It turns out that if a trigger N arrives early (and survives prescaling)
    then the event type is N, but if any triggers arrive within 10 nsec --
    which is likely since we aligned them -- the event type is somewhat
    arbitrarily fEvtHdr.fEvtType == 5.  Otherwise you'd need to program a 
    matrix for what all the overlap possibilities mean, which is experiment
    specific and fraught with error.  There is some history to this :
    event 5 was, for years, the coincidence trigger and I figured this
    choice reduced the chance of mistakes -- like ignoring them.  Even if
    you could argue we should fix the TS programming, it has a hardware
    time window of 10 nsec which is arbitrary and again experiment-specific.
    
    Solution:  don't use fEvtHdr.fEvtType !
    
    Instead, use D.evtypebits.  It's a bit pattern formed from TDC inputs from the
    trigger supervisor.  The input to the TDC are the N triggers *after* prescaling.
    
    There are also TDC inputs without prescaling, if you like.
    
    This is also documented on my trigger web page.
    
    Some examples:
    
    1. Want trigger 4 and don't care if others co-exist
    (D.evtypebits&0x10)==0x10
    
    2. Want trigger 4 and demand that NO others co-exist (i.e. survive
    prescaling) 
    D.evtypebits==0x10
    
    3. Want trigger 6 and don't care if others co-exist
    (D.evtypebits&0x40)==0x40
    
    -------------
    
    Now all this depends on some cuts on TDC (to define the bits) being
    correct in THaNormAna, but I think Alexandre checked this for APEX.
    It should be re-checked in post-run analysis.
    
    
    


    A copy of this log entry has been emailed to: ole