Date: 10 May, 2016
Known FADC issues
1. Why delay for helicity not 8 but 6 in analyzer?
It was noted during analysis of FADC data that first helicity trigger actually
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. "Empty" Data Triggers (related to previous issue)
There are many data triggers without signals that have produced these triggers
in the root file.
This problem/bug still under investigation.
4. FADC has two 40-bit free running counters at 250MHz that stored trigger time
comming for data trigger.
Some times during measurements 'mollmon' program reports of FADC error:
ERROR:(20) fadc trigger time chip#1 does not equals to the trigger time chip#2
timer1= DBF7 F4A0AB timer2= DBF7 F4A0AC
ERROR:(20) fadc trigger time chip#1 does not equals to the trigger time chip#2
timer1= DBFA 39657B timer2= DBFA 39657C
ERROR:(20) fadc trigger time chip#1 does not equals to the trigger time chip#2
timer1= DBFB 4D8522 timer2= DBFB 4D8523
ERROR:(20) fadc trigger time chip#1 does not equals to the trigger time chip#2
timer1= DBFC 7A37E6 timer2= DBFC 7A37E7
Hard reboot of FADC resolves this error some time, but some time not.
This error is produced every time after high current beam ( >10 uA).
Probably, it is some radiation damage in FADC cells.
5. 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
FADC firmware upgrading
1. We considering the possibility to have more counters array and programable logic
unit (PLU) on the board of FADC to programming a single channel coincidence
and counting it on the scalers.
For example:
sumLS.and.CL2.and.CR2,
sumLS.and.CL2.and.sumCR, ... and so on.
The module type of LeCroy-2365 can be used as prototype for this PLU.
Preliminary PLU parameters:
16 inputs by 16 outputs, with possibility to provide the connection
of any inputs to any output through the logic function of
(OR), (AND) for inputs and function (NOT) for outputs.
The programmable registers(read/write):
16 registers ( 16bit) for AND function (every bit is corresponded to one input,
the register number is corresponded to the output number),
16 registers ( 16bit) for OR function (every bit is corresponded to one input,
the register number is corresponded to the output number)
one (16bit) register for NOT function of output (every bit is corresponded to one output).
Scalers array:
16 channel of 32bit counters connected to the corresponded outputs of the PLU.
2. Add the possibility to disable generation of "Data trigger" at all and
enable only trigger from helicity.
