Computing the x-talk

Description and definitions

The x-talk is defined as the amount of signal from one channel (the signal channel ) spreading into another channel (the x-talk channel ). The purpose of a FIR (Finite Impulse Response) filter is to inverse the x-talk effect.

The VeloXTalkComputer is designed to compute the x-talk on test-pulses or beam non-zero suppressed data . It does not inverse these x-talk values to compute the FIR coefficients as this is done by the VeloTELL1CableFIRFilter algorithm.

Cuts can be applied (and are applied by default) to ensure considering 'only' one strip clusters and positive pulses and/or a specific test-pulse pattern. In a near (sic!) future, such a tool will write automatically the FIR coef. into a condition database through PVSS in order to have a working TELL1 recipe.

Concretely, the x-talk value is computed as the mean noise divided by the mean signal. This x-talk expression is not the most precise but as shown to be the most robust and, as no one will check 400k floating value (which is the minimal number of different x-talk on a per-cable full Velo) robustness is here preferred to precision.

Algorithms sequence for a VeloXTalkComputer instance

VeloXTalkComputer is designed to run on pedestal or common mode suppressed data. Thus you have to use an InputDataLoc like
VeloXTalkComputer.InputDataLoc="Raw/Velo/ADCCMSuppressed";
or like
VeloXTalkComputer.InputDataLoc="Raw/Velo/SubtractedPedADCs";
Yet, as this algorithm does not transform the data it reads, you can put is anywhere in your GaudiSequencers (e.g. TopAlg.Members +={ "VeloXTalkComputer" }; ).

The pedestal needs a certain amount of event to converge. In the emulation, this number is set by the VeloTELL1EmulatorInit.ConvergenceLimit=4000; property. VeloXTalkComputer needs to have the same property sets to the same value (or higer if you like) VeloXTalkComputer.ConvergenceLimit=4000; . Do not set this limit below 3000, even for test-pulse data.

tempnote: (One drawback in the current Vetra v3r3 version, VeloTELL1LCMS from VeloTELL1Algorithms v1r3 is that the LCMS runs only if it was running during the data taking. As this is not the case in ACDC2 and 3, you have to hack the source code to comment the 'isEnable()' test in the execute methode, this should change soon...)

Generic options

Define the input data location:
xtalk.InputDataLoc = "Raw/Velo/ADCCMSuppressed";
this is the default, you can consider using your own location or look at $VELOTELL1EVENTROOT/Event/VeloTELL1Data.h to see other typical values.

Use AcceptedTell1s = {x,y,z}; or RejectedTell1s={x,y,z}; to define a specific list of TELL1s to look at. If none of these property is defined, all the TELL1 are analyzed.

The CableXTalk , Tell1XTalk , PhiSensorXTalk and StripXTalk options:

The current implementation of VeloXTalkComputer allows to compute different kind of x-talks, they can be cumulate in one run :

• StripXTalk=n will compute for every TELL1 and every chip channel 2*n x-talk values going from chip channel neighbor -n to +n. The default, n=0, disables this mode.
• CableXTalk=n computes the 2*n x-talks (-n chip chan. to +n chip chan.) pre analog cable (default value is n=2). If this mode is used, one can defined the OutputOptionFilename property which will create an ASCII file. This later contains x-talk values in a format that can be cut and pasted for the VeloTELL1CableFIRFilter algorithm.
• Tell1XTalk=n computes the 2*n x-talks (-n chip chan. to +n chip chan.) pre Tell1. If this mode is used (and CableXTalk is not used), one can defined the OutputOptionFilename property which will create an ASCII file. This later contains x-talk values in a format that can be cut and pasted for the VeloTELL1CableFIRFilter algorithm.
• PhiSensorXTalk test combination like "neighbor strip, non-neighboring chip channels" or exotic things like that. The names at the end of a run are supposed to be self-explanatory.

Signal and noise cut options

The only 'important' properties here are SignalMin , SignalMax and NoiseMax . The rest have default values which are fine in most cases. Use SignalMin , SignalMax and NoiseMax to define a signal window on beam data.
The x-talk from channel N into channel N+y will only be computed if:

• channel N as an amplitude between SignalMin and SignalMax . This window is modified by DiscardNegativeSignal (true by default) and DiscardPositiveSignal (false by default). This is mainly used for test-pulses.
• channel N+y as an absolute amplitude below NoiseMax .
• Depending on AvoidCableDoubleHit and AvoidSensorDoubleHit (both true by default) the algorithm will ensure that the absolute amplitude of the cable (respectively the strip) neighbors are lower than NoiseMax (if a testpulse pattern is defined, these two properties are ignored).
• Settings the ShiftThresholdsToMeanStripValue to true will slow down the algorithm, but it will then computes its own pedestal on every strips. The ADC values are not modified but all the threshold defined above are shifted by the current pedestal value. This property allows to work on non pedestal corrected data although the x-talk values may have no sens at all then.

The SkipFirstCableChannel is set to false by default. If true, it will reject combination where (channel N+y)%32 = 0. This actually discards the header x-talk.

Working with test-pulse data

A test-pulses pattern can be defined the following way:
xtalk.TestPulses = {1,5,34,123};
xtalk.TestPulsesAreModulo=128;
which allows to work with test-pulses in the given chip channel on a Beetle base. The default value for TestPulsesAreModulo is 32 which is the usual analog cable base. If a test-pulse pattern is defined, no signal and/or noise cut are applied. The DiscardNegativeSignal and DiscardPositiveSignal are still considered though.

Misc and debug options:

• MinXTalkPoints = n; sets the minimum number of points for one x-talk value be reliable (default is 50), values with less points than that are set to 0.
• DebugMode = true/false enables debug mode, print at the beginning of the job all the possible x-talk combination that will be tested and produces plots of all the x-talk distribution. Beware that using this options together with XTalkType="StripXTalk"; on a full Velo will produces something like 5 millions of plots... Coupling this options with OutputLevel=2; prints some info every time a valid x-talk pair is found.
• UniqueCable = x; considers only one analog cable x.
• UniqueOffset = n; considers only one specific chip channel neighbor.
• OutputOptionFilename = "filename"; as mentioned before, in combination with XTalkType="CableXTalk"; produces an ASCII files (overwrites it without warning) that can be cut and pasted into the options of a VeloTELL1CableFIRFilter algorithm.
• GnuplotFile = "scriptFileName"; produces two files (scriptFileName and scriptFileName.dat) the fomer can be executed with gnuplot (in a shell, type gnuplot and then "load 'scriptFileName'"). It produces a plot of all the cable x-talks versus the neighbor offset.