March 30 2011

Notes of Data Trigger analysis.


1. Why delay for helicity not 8 but 6 in analyzer?
   It was noted during analysis of FADC data that first helicity trigger actualy has collected data
   from two helicity windows.  Pic.1 Run #1518,   Pic.2 Run #2387 
   It means that FADC has missed first helicity trigger and second
   one counts as first, but helicity state latched from the first trigger.
   That gives helicity window delay in 7 instead of 8. 
   To calculate asymmetry FADC analyzer uses helicity state latched by module QDC V792.
   It records helicity state not for current but for next window (from "TLoop.C"):
   [March,  2010 : BDS] MPS vs. HEL transition timing changed on us.
       *        - The v792 ADC is gated _after_ the Helicity signal has changed
       *          state during the MPS (this was confirmed on the 'scope).  So
       *          it records the helicity state of the upcoming helicity
       *          window.
       *        - So:
       *          - helicity_state is correct for the scaler data that are
       *            reported in this HEL trigger.
       *          - helicity_state_a is the helicity for the data that come next
       *          - helicity_state_a_last should match this helicity_state

   So, that means that correct helicity state from QDC V792 is shifted by -1 and we have offset for
   helicity state equals to 6.


2. Related to Data Trigger analyzer warning:

   -!-> (Event 4786757, Data trig) WARNING  Helicity readback inconsistency: HEL_fadc_v792(1) HEL_fadc_Dt(2)

   There is 10 bits counter of helicity windows in data triggers stream (0x3ff0000 & B.fadc.sidechan[0]).
   Helicity state bit for data trigger stored in word (0x8 & B.fadc.sidechan[0]).
   Some times during run the states of helicity window and helicity counter are lost synchronization.
   Another words, helicity counter has been incremented by one for next helicity window (with opposite sign, for example),
   but helicity state bit is still unchanged for few next data triggers.  Pic.3 Run #2387, 
   It gives wrong helicity state for that windows. Number of data triggers with wrong helicity state for
   one window is changed during run in range from 0-50% of all triggers per window. 
   For 1000Hz helicity flipping rate it is more frequently situation than for 30Hz.
   It means that data trigger helicity state should be checked with helicity state that recorded by module QDC V792.

3. Missed block of data (20 data triggers).
   FADC has  12 bits counter of data triggers. It stored in word (0x0000fff0 & B.fadc.sidechan[0]).
   For helicity flipping rate 1000Hz there are a lot of missed data triggers in block by 20.
   (from "TLoop.C"):
    // FIXME: I think the only time this happens now is when I drop
        //        a DATA block that arrives simultaneously with a HEL data in
        //        the crl.  (This was done because it greatly simplified the
        //        decoding routine.)

   For analysis of data triggers it means that we have for these cases next combinations:
   - shorter helicity window in counts of data triggers for helcity window with missed data block;
   - shorter helicity window in counts of data triggers for previous helicity window and next window if
     missed block is overlapping of two helicity windows.
   These helicity windows should be rejected from analysis.    


4. "Empty" Data Triggers.
   There are many data triggers without signals that have produced these triggers in the root file.
   I have looked into coda raw "dat" file and do not see this problem. 
   It seems that there is some bug in "replay_test"  that produced root file.
   This problem/bug still under investigation.
  

5. Some notes for analysis of data trigger.
   FADC has two counter of helicity window. One is used for counting of helicity trigger
   and another one is used to counting helicity windows in data triggers. 
   The main idea to correct helicity states for data triggers (reffered early in  2.)
   is to synchronize helicity window number for data trigger with helicity trigger number for scalers
   by using match values from these counters.
   Then one can compare values from scalers for selected helicity window and number of data triggers(by type) for that window.
   For 30Hz helicity flipping rate, number of data triggers per helicity window are always less than from scalers  Pic.4 Run #1518. 
   It is OK since data trigger has dead time ~150ns and also it not counts double events per integrated window 20*4ns.
   For  helicity flipping rate 1000Hz these comparison gives some times very big difference in counts between scaler 
   values and data trigger counts (up to +/-30%)  Pic.5 Run #2387.
   There is no explanation now for that cases.

6. The code for analysis of FADC data triggers still under development.



April 08 2016

Updates

1  Threshold parameters "FA_SUM_THRESH_CR/L 8500"  changed only apperture sectra peak position. There is no any effect on calorimeter spectra. 
   The apperture spectra peak is shifted down about by 500 adc channels when threshold is reduced by 1000.
   Calorimeter(LG) spectra at top of picture. Apperture detector spectra at bottom:
   Pic.6 Run #3114, FA_SUM_THRESH_CR/L=8500   
   Pic.7 Run #3113, FA_SUM_THRESH_CR/L=7500   
   Pic.8 Run #3116, FA_SUM_THRESH_CR/L=9000   
2  When rate of apperture detectors is increased (say, from ~0.5MHz(Run #3391) to ~0.9Mhz (Run #3405)) the apperture spectra peak is 
   shifted down by ~1000 adc channels. This effect is due to DC offset in apperture PMTs or output of amplifier x10 or both.
   Apperture detector spectra at bottom of picture:
   Pic.9  Run #3392, FA_SUM_THRESH_CR/L=8500, App.detector rate ~ 0.5 MHz (from old DAQ)   
   Pic.10 Run #3405, FA_SUM_THRESH_CR/L=8500, App.detector rate ~ 0.9 Mhz (from old DAQ)   


To resolve these issues one have to:
    - tune HV for apperture detector to set apperture peak in ~3000 channel of adc;
    - set thresholds FA_SUM_THRESH_CR/L to 7500 - 8000