Changeset 5638 for trunk/MagicSoft/TDAS-Extractor/Performance.tex

Timestamp:

12/20/04 15:11:16 (20 years ago)

Author:

gaug

Message:

*** empty log message ***

File:

• trunk/MagicSoft/TDAS-Extractor/Performance.tex (modified) (2 diffs)

trunk/MagicSoft/TDAS-Extractor/Performance.tex

@@ -152 +152 @@
 then the digital filter.
 \par
+In the low-gain, there is one extractor discarding a too high amount of events which is the 
+MExtractFixedWindowPeakSearch. The reason becomes clear when one keeps in mind that this extractor 
+defines its extraction window by searching for the highest signal found in a sliding peak search window
+ looping only over {\textit non-saturating pixels}. In the case of an intense calibration pulse, only 
+the dead pixels match this requirement and define thus an alleatory window fluctuating like the noise 
+does in these channels. It is clear that one cannot use this extractor for the intense calibration pulses. 
+\par
+It seems also that the spline algorithm extracting the amplitude of the signal produces an over-proportional
+number of excluded pixels in the low-gain. The same, however in a less significant manner, holds for 
+the digital filter with high-low-gain inverted weights. The limit of stability with respect to 
+changes  in the pulse form seems to be reached, there.
+\par
 Concerning the numbers of outliers, one can conclude that in general, the numbers are very low never exceeding
 0.25\%. There seems to be the opposite trend of larger windows producing less 
@@ -299 +311 @@
 photo-electrons from outer to inner pixels correctly for the green and blue pulses. 
 \par
-The extractor MExtractTimeAndChargeDigitalFilter seems to be veryu stable against modifications in the 
-exact form of the weights since all applied weights yield about the same number of photo-electrons and the 
-same ratio of outer vs. inner pixels. The last is also true for the extractor MExtractTimeAndChargeSpline, 
-although the number of photo-electrons depends on the extraction window for green and blue pulses,  
-(as with the other extractors).
+The extractor MExtractTimeAndChargeDigitalFilter seems to be stable against modifications in the 
+exact form of the weights in the high-gain readout channel since all applied weights yield about 
+the same number of photo-electrons and the same ratio of outer vs. inner pixels. This statement does not 
+hold any more for the low-gain, as can be seen in figure~\ref{fig:phe:23ledsblue}. There, the application 
+of high-gain weights to the low-gain signal (extractors \#30--31) produces a too low number of photo-electrons
+and also a too low ratio of outer per inner pixels.
+\par
+All sliding window and spline algorithms yield a stable ratio of outer vs. inner pixels in the low-gain, 
+however the effect of raising the number of photo-electrons with the extraction window is very pronounced. 
+Note that in figure~\ref{fig:phe:23ledsblue}, the number of photo-electrons raises by about a factor 1.4, 
+which is slightly higher than in the case of the high-gain channel (figure~\ref{fig:phe:2ledsgreen}). 
+\par
+Concluding, there is now fixed window extractor yielding the correct number of photo-electrons 
+for the low-gain, except for the largest extraction window of 10 low-gain slices. 
+Either the number of photo-electrons itself is wrong or the ratio of outer vs. inner pixels is 
+not correct. All sliding window algorithms seem to reproduce the correct numbers if one takes into 
+account the after-pulse behaviour of the light pulser itself. The digital filter seems to be not 
+stable against exchanging the pulse form to match the slimmer high-gain pulses, though.
+
 
 \subsubsection{Linearity tests}