| 6 |
|
to meet stringent quality requirements. Few important problems have been spotted and |
| 7 |
|
solved.\\ |
| 8 |
|
During the TIB/TID integration all the operations have been monitored step by step by a chain of tests |
| 9 |
< |
aimed at a final control of the components just after the installation described here and at a verification of the |
| 10 |
< |
shell overall quality and functionality (~\ref{burnin}). The step by step tests are of particular importance |
| 9 |
> |
aimed at a final control of the components just after the installation described here. |
| 10 |
> |
A verification of the |
| 11 |
> |
shell overall quality and functionality in conditions similar to the final ones |
| 12 |
> |
has been later performed during the so-called burn-in tests~\cite{ref:burnin}. |
| 13 |
> |
The step by step tests are of particular importance |
| 14 |
|
because in most cases it is very difficult and in some cases even dangerous |
| 15 |
|
to replace a single faulty component when it is embedded in a fully equipped shell. |
| 16 |
|
|
| 45 |
|
\end{figure} |
| 46 |
|
|
| 47 |
|
\begin{description} |
| 48 |
< |
\item[TSC] The Trigger Sequencer Card or TSC~\cite{bib:specs:tsc} generate the |
| 48 |
> |
\item[TSC] The Trigger Sequencer Card or TSC~\cite{ref:tsc} generate the |
| 49 |
|
40~MHz clock for the entire system and triggers as well, either |
| 50 |
|
internally via software or by accepting external inputs. It has up to four |
| 51 |
< |
electrical clock/trigger outputs, enough to drive the FEDs, and an optical clock/trigger |
| 52 |
< |
output for the FEC. |
| 53 |
< |
The TSC may also generate the RESET and CALIBRATION signal that are |
| 51 |
> |
electrical clock/trigger outputs, enough to drive the FEDs used during the |
| 52 |
> |
integration, and an optical clock/trigger output for the FEC. |
| 53 |
> |
The TSC may also generate the reset and calibration signal that are |
| 54 |
|
also encoded on the clock/trigger line.\\ |
| 55 |
< |
\item[FED] The analog-to-digital conversion is done by special PCI FEDs~\cite{bib:fedpci}, |
| 55 |
> |
\item[FED] The analog-to-digital conversion is done by special PCI FEDs, |
| 56 |
> |
%~\cite{bib:fedpci}, |
| 57 |
|
with electrical differential analog input, mounted on |
| 58 |
|
PCI carrier boards and installed in an industrial PC. |
| 59 |
< |
The opto-electrical conversion of the analog signals is done externally by a 24-channel unit. |
| 59 |
> |
The opto-electrical conversion of the analog signals coming from the module under test |
| 60 |
> |
is done externally by a 24-channel unit. |
| 61 |
|
A setup containing 3 FEDs, with the electro-opical converter, is able |
| 62 |
< |
to readout 48 APV; this is equivalent to 12 single sided modules |
| 62 |
> |
to readout 48 APV25; this is equivalent to 12 single sided modules |
| 63 |
|
%(four complete strings) |
| 64 |
|
or four double sided modules assemblies. |
| 65 |
|
%(one string plus one module). |
| 66 |
|
These figures are |
| 67 |
|
pefectly suited for the tests during the integration.\\ |
| 68 |
< |
For obvious reason the readout of the data from the APVs is not |
| 69 |
< |
synchronous with the L1 trigger. A crucial capability of the FED is the |
| 68 |
> |
Since the readout of the data from the APV25s is not |
| 69 |
> |
synchronous with the L1 trigger, a crucial capability of the FED is the |
| 70 |
|
\textit{header finding}, i.e. the automatical tagging of the |
| 71 |
< |
analog data stream from APV pairs with respect to the idle |
| 72 |
< |
signals at its inputs. This is possible since the APVs embeds the |
| 71 |
> |
analog data stream from APV25 pairs with respect to the idle |
| 72 |
> |
signals at its inputs. This is possible since the APV25s embeds the |
| 73 |
|
analogue data stream within a {\em digital frame} made up of a leading |
| 74 |
< |
digital header and a trailing tick-mark. The peculiarity of the PCI FED |
| 75 |
< |
with respect to the VME FED that will be used in the experiment, other than having electrical inputs |
| 76 |
< |
instead of optical ones, is the timing system: the VME FED is able to |
| 77 |
< |
perform the header finding on each input channel independently; the PCI FED has |
| 78 |
< |
this capability only on the first channel of the eight available |
| 79 |
< |
and assumes that the all input signals are synchronised. |
| 80 |
< |
This makes the PLL-based time alignment procedure of crucial |
| 81 |
< |
importance in a setup with PCI FEDs. Furthermore, PCI FEDs are not |
| 82 |
< |
able to insert a programmable delay on their inputs and thus |
| 83 |
< |
it is important that the clock/trigger connections from the TSC to |
| 84 |
< |
FEDs have all the same delay. Last, PCI FEDs cannot perform an online |
| 85 |
< |
pedestal subtraction and zero suppression (they cannot run in |
| 86 |
< |
Processed Raw data nor in Zero Suppression mode). |
| 74 |
> |
digital header and a trailing tick-mark. |
| 75 |
> |
%The peculiarity of the PCI FED |
| 76 |
> |
%with respect to the VME FED that will be used in the experiment, other than having electrical inputs |
| 77 |
> |
%instead of optical ones, is the timing system: the VME FED is able to |
| 78 |
> |
%perform the header finding on each input channel independently; the PCI FED has |
| 79 |
> |
%this capability only on the first channel of the eight available |
| 80 |
> |
%and assumes that the all input signals are synchronised. |
| 81 |
> |
%This makes the PLL-based time alignment procedure of crucial |
| 82 |
> |
%importance in a setup with PCI FEDs. Furthermore, PCI FEDs are not |
| 83 |
> |
%able to insert a programmable delay on their inputs and thus |
| 84 |
> |
%it is important that the clock/trigger connections from the TSC to |
| 85 |
> |
%FEDs have all the same delay. Last, PCI FEDs cannot perform an online |
| 86 |
> |
%pedestal subtraction and zero suppression (they cannot run in |
| 87 |
> |
%Processed Raw data nor in Zero Suppression mode). |
| 88 |
|
\item[FEC] The special FEC used during the integration is the {\em FEC |
| 89 |
|
mezzanine} also installed into a PC on a PCI carrier. It supports |
| 90 |
|
the optical trigger/clock provided by the TSC and features an |
| 93 |
|
|
| 94 |
|
|
| 95 |
|
\subsubsection{Software} |
| 96 |
< |
The software used to carry out integration tests is {\em TrackerOnline}, the CMS |
| 97 |
< |
tracker implementation of a more general software, named |
| 98 |
< |
xDAQ~\cite{ref:xdaq}, which is the official CMS DAQ framework. |
| 96 |
> |
The software used to carry out integration tests is |
| 97 |
> |
based on the CMS general data acquisition framework |
| 98 |
> |
%{\em TrackerOnline}, the CMS |
| 99 |
> |
%tracker implementation of a more general software, |
| 100 |
> |
named xDAQ~\cite{ref:xdaq}. |
| 101 |
> |
% which is the official CMS DAQ framework. |
| 102 |
|
In place of a database as in the |
| 103 |
|
experiment version, the integration version of TrackerOnline uses a set of |
| 104 |
< |
xml files for all the configurations needed to perform a test run. |
| 104 |
> |
xml files for all the configurations needed to perform a test run. |
| 105 |
> |
A description of the xml configuration files follows. |
| 106 |
|
%, i.e. all the parameters needed by the devices and the |
| 107 |
|
%software involved in the test run, |
| 108 |
|
%\begin{figure}[bth!] |
| 112 |
|
%Part of the data is not shown for simplicity.} |
| 113 |
|
%\label{fig:fecmodulexml} |
| 114 |
|
%\end{figure} |
| 115 |
< |
\begin{description} |
| 116 |
< |
\item[Configuration of the DAQ hardware and software, daq.xml] The hardware |
| 117 |
< |
and software configuration of the DAQ is written in a single xml file, which |
| 118 |
< |
reflect the setup used for the test and has to be rarely changed |
| 119 |
< |
during the integration procedures. |
| 120 |
< |
\item[Configuration of the control system, fec.xml] The most important |
| 121 |
< |
part of this configuration section is the settings the FEC must |
| 122 |
< |
upload to the modules and AOHs and in general any configurable |
| 123 |
< |
$I^2C$ device, before starting the data |
| 124 |
< |
taking. Altough these settings are not specifically |
| 125 |
< |
related to the control system, it is duty of the control system to |
| 126 |
< |
write them to the devices' $I^2C$ registers and read them back for verification. |
| 127 |
< |
\item[Configuration of the readout, module.xml] All other information needed by the DAQ to |
| 128 |
< |
rearrange data coming from the FEDs is in module.xml that allows each |
| 129 |
< |
FEDs input channel to be mapped to an APV pair of a specific module as |
| 130 |
< |
identified by ring, CCU and $I^2C$ addresses (i.e. the correspondance |
| 131 |
< |
between readout coordinates and Control System coordinates); |
| 115 |
> |
The hardware and software configuration of the DAQ is written into the file |
| 116 |
> |
named daq.xml. It reflects the setup used for the test and has to be rarely changed |
| 117 |
> |
during the integration procedures. The system settings uploaded, and |
| 118 |
> |
read back for verification, by the FEC are contained into fec.xml. |
| 119 |
> |
The data decoding map (i.e., information needed to map each FED input to an |
| 120 |
> |
APV25 pair of a specific module) is written into module.xml. |
| 121 |
> |
|
| 122 |
> |
%\begin{description} |
| 123 |
> |
%\item[Configuration of the DAQ hardware and software, daq.xml] The hardware |
| 124 |
> |
% and software configuration of the DAQ is written in a single xml file, which |
| 125 |
> |
% reflect the setup used for the test and has to be rarely changed |
| 126 |
> |
% during the integration procedures. |
| 127 |
> |
%\item[Configuration of the control system, fec.xml] The most important |
| 128 |
> |
% part of this configuration section is the settings the FEC must |
| 129 |
> |
% upload to the modules and AOHs and in general any configurable |
| 130 |
> |
% $I^2C$ device, before starting the data |
| 131 |
> |
%taking. Altough these settings are not specifically |
| 132 |
> |
% related to the control system, it is duty of the control system to |
| 133 |
> |
% write them to the devices' $I^2C$ registers and read them back for verification. |
| 134 |
> |
%\item[Configuration of the readout, module.xml] All other information needed by the DAQ to |
| 135 |
> |
%rearrange data coming from the FEDs is in module.xml that allows each |
| 136 |
> |
%FEDs input channel to be mapped to an APV pair of a specific module as |
| 137 |
> |
%identified by ring, CCU and $I^2C$ addresses (i.e. the correspondance |
| 138 |
> |
%between readout coordinates and Control System coordinates); |
| 139 |
|
%Each row corresponds to an APV |
| 140 |
|
%pair, an AOH laser, an optical fibre and a FED input.\\ |
| 141 |
|
%The second table of module.xml reassembles the information on a module basis. |
| 142 |
|
%Here all the active modules are listed, with a row for every module. |
| 143 |
|
%The Control System coordinates are repeated both in module.xml and fec.xml, |
| 144 |
|
%so that they can be used as a pivot between the 3 tables.\\ |
| 145 |
< |
\end{description} |
| 145 |
> |
%\end{description} |
| 146 |
|
|
| 147 |
|
The tasks performed by the integration software are the following: |
| 148 |
|
execution of the commissioning runs needed to optimal adjust of the |
| 150 |
|
of the test runs with complete and automated logging; fast analysis |
| 151 |
|
for immediate feedback; archival of xml configuration files to log the |
| 152 |
|
test conditions; archival of the raw data. |
| 136 |
– |
|
| 137 |
– |
|
| 153 |
|
%\begin{figure} |
| 154 |
|
%\centering |
| 155 |
|
%\includegraphics[width=.9\textwidth]{Figs/integration_package.pdf} |
| 160 |
|
%\textit{Sheet}: a file.} |
| 161 |
|
%\label{fig:integration_package} |
| 162 |
|
%\end{figure} |
| 148 |
– |
|
| 163 |
|
%Figure~\ref{fig:integration_package} shows a scheme of the relations between all the software |
| 164 |
|
%components that will be described, the local files and the remote database. |
| 165 |
< |
|
| 166 |
< |
This is achieved by using a specific set of components of TrackerOnline. |
| 165 |
> |
This is achieved by using a specific set of components of integration |
| 166 |
> |
data acquisition software as summarized in the following. |
| 167 |
|
\begin{description} |
| 168 |
|
\item[FecTool.] |
| 169 |
|
FecTool is GUI based front-end to two standalone |
| 170 |
< |
applications deployed with TrackerOnline, FecProfiler |
| 170 |
> |
applications: FecProfiler |
| 171 |
|
and ProgramTest, aimed to ease the creation of the device |
| 172 |
|
description. |
| 173 |
|
FecProfiler is able to detect |
| 174 |
|
the devices connected to the CCUs and builds the fec.xml file needed by |
| 175 |
|
TrackerOnline. FecTool takes care of checking that thedetected devices |
| 176 |
< |
corresponds to expected ones, i.e., per module, 4 or 6 APVs, one |
| 176 |
> |
corresponds to expected ones, i.e., per module, 4 or 6 APV25s, one |
| 177 |
|
PLL, one AOH, and so on. ProgramTest allows the ring functionalities, |
| 178 |
|
i.e. the redundancy, to be deeply tested. |
| 179 |
|
|
| 188 |
|
%Hence tests proceed with the data |
| 189 |
|
%readout from modules, which rely on . |
| 190 |
|
\item[The Integration Package.] |
| 191 |
< |
TrackerOnline as any xDAQ implementation requires an expert user as |
| 192 |
< |
many run-specific parameters must be set and there is no input |
| 193 |
< |
validation. |
| 191 |
> |
%TrackerOnline as any xDAQ implementation requires an expert user as |
| 192 |
> |
%many run-specific parameters must be set and there is no input |
| 193 |
> |
%validation. |
| 194 |
|
%\begin{figure} |
| 195 |
|
%\centering |
| 196 |
|
%\includegraphics[width=0.35\textwidth]{Figs/FedGuiMain.png} |
| 197 |
|
%\caption{Main GUI window.} |
| 198 |
|
%\label{fig:fedgui} |
| 199 |
|
%\end{figure} |
| 200 |
< |
The integration setup is mode more user-friendly by a special {\em |
| 200 |
> |
The integration setup is made more user-friendly by a special {\em |
| 201 |
|
Integration Package}, a GUI based front end that interacts with |
| 202 |
< |
TrackerOnline to automatically set all relevant parameters and to harvest all data at the end |
| 202 |
> |
the data aquisition program to automatically set all relevant parameters |
| 203 |
> |
and to harvest all data at the end |
| 204 |
|
of a run. The package is organized as a finite state machine by which |
| 205 |
|
the user can cycle between the various states, i.e. the following integration test steps: |
| 206 |
|
\begin{enumerate} |
| 207 |
< |
\item TrackerOnline initialisation (only once); |
| 207 |
> |
\item Daq initialisation (only once); |
| 208 |
|
\item choice of the the desired run; |
| 209 |
< |
\item execution of the run via TrackerOnline; |
| 209 |
> |
\item execution of the run via Daq program; |
| 210 |
|
\item on run completion (i.e. after a given number of events), stop |
| 211 |
|
data taking and execution of the fast data analysis; |
| 212 |
|
\item presentation of the run outcome on summary GUIs; |
| 239 |
|
\item[Find connections.] This commissioning run is used associate each |
| 240 |
|
FED input channel to a module. The procedure, repeated in sequence |
| 241 |
|
for all AOHs laser drivers, consists of switching on only a given |
| 242 |
< |
AOH laser driver while checking the signal on all the FED inputs. If |
| 242 |
> |
AOH laser driver at a time while checking the signal on all the FED inputs. If |
| 243 |
|
the difference of the signal seen on a FED channel is above |
| 244 |
|
a given threshold, the connection between that laser and input channel is tagged and stored |
| 245 |
|
in module.xml. |
| 248 |
|
in the PLLs delay registers. |
| 249 |
|
Doing so the different delays in the control and |
| 250 |
|
readout chain are compensated, the clock arrives to the modules |
| 251 |
< |
synchronously, with a skew of the order of a few ns, and the APVs |
| 251 |
> |
synchronously, with a skew of the order of a few ns, and the APV25s |
| 252 |
|
signal are properly sampled by the FEDs. This requires also the clock |
| 253 |
|
to all the FEDs to be synchronous, but this is guaranteed |
| 254 |
|
by using cables equal in length between the TSC and the FEDs.\\ |
| 255 |
< |
The time alignment run uses of the periodic tick mark signal issued by |
| 256 |
< |
the idle APVs every 70 clock cycles. The APV signals are sampled by FEDs in |
| 255 |
> |
The time alignment run uses the periodic tick mark signal issued by |
| 256 |
> |
the idle APV25s every 70 clock cycles. The APV25 signals are sampled by FEDs in |
| 257 |
|
scope mode, i.e. without waiting for an header but continously, |
| 258 |
< |
sampling the inputs at the full clock frequency as with a 40~MSample |
| 258 |
> |
sampling the inputs at the full clock frequency as with a 40~MSample/s |
| 259 |
|
scope. The measurement is repeated after all the PLL delays are |
| 260 |
< |
icreased by the minimum delay step, 25/24~ns. After 24 such cycles the |
| 261 |
< |
idle APV output and thus the tick mark signal also are measured with |
| 262 |
< |
an effective 960~MSample scope. |
| 260 |
> |
increased by the minimum delay step, 25/24~ns. After 24 such cycles the |
| 261 |
> |
idle APV25 output and thus the tick mark signal also are measured with |
| 262 |
> |
an effective 960~MSample/s scope. |
| 263 |
|
\begin{figure} |
| 264 |
|
\centering |
| 265 |
|
\includegraphics[width=.6\textwidth]{Figs/tickmark.pdf} |
| 268 |
|
during the time alignment an interval of $1\,\mu\mathrm{s}$ is scanned.} |
| 269 |
|
\label{fig:tick} |
| 270 |
|
\end{figure} |
| 271 |
< |
The time differences between the variuos APV tick marks are a |
| 271 |
> |
The time differences between the variuos APV25 tick marks are a |
| 272 |
|
measurement of the relative delays introduced by the connections and |
| 273 |
|
can be used to compute the optimal delay to be set on each PLL for compensation. |
| 274 |
|
The tick mark raising edge $t_R$ time is measured by taking the time corresponding to the highest |
| 283 |
|
fec.xml. If the setup is correctly aligned in time, a further time |
| 284 |
|
alignment procedure should not propose delay corrections greater than |
| 285 |
|
$\sim 2$ns. |
| 286 |
< |
It is worth noticing that by the time alignment procedure all APVs are |
| 287 |
< |
made sampling synchronously, since in the integration setup AOH fibres |
| 288 |
< |
and ribbons are all equal in length. This is not important during |
| 289 |
< |
integration quality checks, as no external signal is ever measured, |
| 290 |
< |
but it would be so in trying to detect ionising particles. |
| 286 |
> |
%It is worth noticing that by the time alignment procedure all APVs are |
| 287 |
> |
%made sampling synchronously, since in the integration setup AOH fibres |
| 288 |
> |
%and ribbons are all equal in length. This is not important during |
| 289 |
> |
%integration quality checks, as no external signal is ever measured, |
| 290 |
> |
%but it would be so in trying to detect ionising particles. |
| 291 |
|
\item[Laser Scan.] By this commissioning run a scan of any bias and |
| 292 |
|
gain value pair is done to determine the optimal working point for |
| 293 |
|
each AOH. |
| 307 |
|
\label{fig:gainscan_range} |
| 308 |
|
\includegraphics[width=.45\textwidth]{Figs/gainscan_range.pdf} |
| 309 |
|
} |
| 310 |
< |
\subfigure[A pictorial representation of a tick mark as produced by the APVs (dotted) |
| 310 |
> |
\subfigure[A pictorial representation of a tick mark as produced by the APV25s (dotted) |
| 311 |
|
and as transmitted by the lasers (solid) when the laser driver's bias is too |
| 312 |
|
low (left), correct (centre) or too high (right), with the subsequent signal saturation.] |
| 313 |
|
{ |
| 318 |
|
\end{center} |
| 319 |
|
\end{figure} |
| 320 |
|
% |
| 321 |
< |
For each trigger sent to FEDs, the is sampled twice and all other samplings fall |
| 321 |
> |
For each trigger sent to FEDs, the tick mark is sampled twice and all other samplings fall |
| 322 |
|
on the baseline. The tick mark's top samples are used to estimate the higher limit of the signal |
| 323 |
|
for a given gain/bias setting pair and the baseline samples provide an estimate of the lower limit. |
| 324 |
|
For each gain setting the tick mark top samples and the baseline samples are measured as a |
| 337 |
|
on the fibre and are investigated. |
| 338 |
|
\item[VPSP Scan.] |
| 339 |
|
This commissioning run is devoted to optimise the pedestal of |
| 340 |
< |
the APV, i.e. the average output level in absence of any signal, with |
| 340 |
> |
the APV25, i.e. the average output level in absence of any signal, with |
| 341 |
|
respect to the dynamical range of the FEDs. This level is managed by a |
| 342 |
< |
specific APV register, know as {\em VPSP}, which controls a voltage |
| 342 |
> |
specific APV25 register, know as {\em VPSP}, which controls a voltage |
| 343 |
|
setting within the deconvolution circuitry. The procedure consists of |
| 344 |
|
a scan of VPSP values while acquiring data frames from modules in the |
| 345 |
< |
standard way, i.e. trigger sent to the modules and FEDs in |
| 346 |
< |
``header finding'' mode. |
| 347 |
< |
The optimal VPSP setting correspond to a pedestal baseline placed |
| 348 |
< |
around 1/3 of the available dynamic range, a good compromise to keep |
| 345 |
> |
standard way. |
| 346 |
> |
%%, i.e. trigger sent to the modules and FEDs in |
| 347 |
> |
%%``header finding'' mode. |
| 348 |
> |
In the final tracker operation the optimal VPSP setting correspond to a pedestal baseline placed |
| 349 |
> |
around 1/3 of the available dynamic range. This is a good compromise to keep |
| 350 |
|
the baseline not too close the lower saturation value while leaving a good |
| 351 |
|
range for particle signals, corresponding to $\sim 6$ MIP. |
| 352 |
+ |
During the integration tests the only important point is to keep the baseline |
| 353 |
+ |
away from the saturation levels; in such a way the module noise measurements will |
| 354 |
+ |
not be affected by the wrong common mode subtractions which are present in case |
| 355 |
+ |
of events with baseline saturation. |
| 356 |
|
At the end of the run a set of values are proposed to the user for |
| 357 |
< |
approval andin case written in the relevant xml file. |
| 357 |
> |
approval and in case written in the relevant xml file. |
| 358 |
|
\begin{figure} |
| 359 |
|
\begin{center} |
| 360 |
< |
\subfigure[Strip pedestals of a module in ADC counts vs.\ strip number.] |
| 360 |
> |
%\subfigure[Strip pedestals of a module in ADC counts vs.\ strip number.] |
| 361 |
> |
\subfigure[] |
| 362 |
|
{ |
| 363 |
|
\label{fig:saturationpedestal} |
| 364 |
|
\includegraphics[width=.45\textwidth]{Figs/saturation_pedestal.pdf} |
| 365 |
|
} |
| 366 |
|
\hspace{5mm} |
| 367 |
< |
\subfigure[Strip noise of a module in ADC counts vs.\ strip number.] |
| 367 |
> |
%\subfigure[Strip noise of a module in ADC counts vs.\ strip number.] |
| 368 |
> |
\subfigure[] |
| 369 |
|
{ |
| 370 |
|
\label{fig:saturationnoise} |
| 371 |
|
\includegraphics[width=.45\textwidth]{Figs/saturation_noise.pdf} |
| 372 |
|
} |
| 373 |
< |
\caption{The pedestal of strips after \#{}640 is low, approaching to the bottom of the |
| 374 |
< |
dynamic range, and their noise is therefore lower.} |
| 373 |
> |
\caption{Pedestal (left) and noise (right) vs. strip number for a 6 APV25 module. |
| 374 |
> |
The pedestals of strips after strip \#{}640 are low, approaching to the bottom of the |
| 375 |
> |
dynamic range. Their noise is therefore altered with respect to the not saturated |
| 376 |
> |
channels.} |
| 377 |
|
\label{fig:saturation} |
| 378 |
|
\end{center} |
| 379 |
|
\end{figure} |
| 380 |
|
The VPSP scan is not sistematically performed during the integration, |
| 381 |
|
since the default VPSP setting is adequate in most of the |
| 382 |
|
cases. Nevertheless, VPSP optimal values change considerably within |
| 383 |
< |
the APV population and are strongly temperature dependent and is |
| 384 |
< |
tather common to have a stuation in which the pedestal of few readout |
| 383 |
> |
the APV25 population and are strongly temperature dependent and is |
| 384 |
> |
rather common to have a stuation in which the pedestal of few readout |
| 385 |
|
channels approaches to the lower edge of dynamic range |
| 386 |
|
(Fig.~\ref{fig:saturationpedestal}) resulting in a lower RMS (see |
| 387 |
|
Fig.~\ref{fig:saturationnoise}). The VPSP scan allows for this issue to be |
| 393 |
|
Triggers are sent to the modules and FEDs work in ``header finding'' mode. |
| 394 |
|
All the analogue frames from the modules are collected two analyses |
| 395 |
|
are performed on these data: online, by the TrackerOnline |
| 396 |
< |
software; offline, in a way very similar to the final experiment by |
| 397 |
< |
using algorythms of the ORCA package~\cite{bib:orca}, the CMS |
| 398 |
< |
reconstruction package at that time, now replaced by CMSSW. |
| 396 |
> |
software; offline, in a way very similar to the final experiment algorythms. |
| 397 |
> |
%by using algorythms of the ORCA package~\cite{bib:orca}, the CMS |
| 398 |
> |
%reconstruction package at that time, now replaced by CMSSW. |
| 399 |
|
The average value of the signal read on each strip is an estimate of |
| 400 |
|
its pedestal, while the RMS is a good estimate of its noise, provided that the noise itself |
| 401 |
|
is Gaussian, which is true to a first approximation. This value is often referred to as |
| 402 |
|
\textit{raw noise}, as opposed to the \textit{common-mode subtracted |
| 403 |
|
noise} (or CMN). The latter is the RMS computed after having |
| 404 |
|
subtracted the {\em common noise}, i.e. the correlated noise-like fluctuation |
| 405 |
< |
common to a given group of channels (tipically an entire APV). |
| 406 |
< |
The common mode noise subtraction method implemented in ORCA and |
| 405 |
> |
common to a given group of channels (tipically an entire APV25). |
| 406 |
> |
The common mode noise subtraction method implemented in |
| 407 |
|
TrackerOnline is similar to that performed by the final FEDs.\\ |
| 408 |
< |
Noise comparison between different APV pairs requires a |
| 409 |
< |
renormalization, because of the difference in gain between the various |
| 410 |
< |
optical links. The normalization procedure relies on the digital |
| 411 |
< |
headers whose amplitude, being the same on each APV, is used to |
| 408 |
> |
Because of the difference in gain between the various |
| 409 |
> |
optical links, noise comparison between different APV25 pairs requires a |
| 410 |
> |
normalization. This procedure relies on the digital |
| 411 |
> |
headers whose amplitude, being the same on each APV25, is used to |
| 412 |
|
estimate of the relative gain of optical links so to apply an |
| 413 |
|
appropriate correction. In such a way noise and gain are |
| 414 |
|
simultaneously measured provided that the signal is not saturation both on low and high values. |
| 415 |
|
The normalisation factor is chosen so as to bring the normalised |
| 416 |
|
header height to 220 ADC counts, as measured in quality controls |
| 417 |
|
during the module production. This allowed the scaled measurements to be easily |
| 418 |
< |
compared with those done during module production tests.\\ |
| 419 |
< |
At the end of the run, pedestal ando noise profiles and distributions |
| 418 |
> |
compared with those done during module production tests~\cite{ref:modtest}.\\ |
| 419 |
> |
At the end of the run, pedestal and noise profiles and distributions |
| 420 |
|
are shown to the user. |
| 421 |
|
\begin{figure}[t!] |
| 422 |
|
\centering |
| 429 |
|
Figure~\ref{fig:noiseprofile} shows an example of the noise output: |
| 430 |
|
the normalised raw noise and CMN and the uncalibrated CMN |
| 431 |
|
for each strip are plotted against the strip index. The first 256 strips belong to the |
| 432 |
< |
first APV pair and are multiplexed to a single optical line and the strips from 257 to 512 |
| 433 |
< |
belong to the second APV pair. It can be noted here that the |
| 434 |
< |
raw noise without normalisation suffers from a different gain of |
| 435 |
< |
optical links, corrected by the normalisation procedure.\\ |
| 432 |
> |
first APV25 pair and are multiplexed to a single optical line and the strips from 257 to 512 |
| 433 |
> |
belong to the second APV25 pair. It can be noted here that the |
| 434 |
> |
raw noise without normalisation reflecs the different gain of |
| 435 |
> |
optical links, this is corrected by the normalisation procedure.\\ |
| 436 |
|
If validated by the user, data are packed along with |
| 437 |
|
possible comments and sent to the central archive system, where they are processed |
| 438 |
|
again and made available on a web page. |
| 458 |
|
is very important to perform the test of as soon as possible. In |
| 459 |
|
fact, a safe removal and replacement of either an AOH or the MC is a |
| 460 |
|
difficult intervention possibly requiring the dismounting of many |
| 461 |
< |
modules already put in place. |
| 462 |
< |
safe removal of a MC from the shell \\ Since After the |
| 461 |
> |
modules already put in place. \\ |
| 462 |
> |
Since the |
| 463 |
|
I$^2$C test FecTool checks the identity of the components with respect |
| 464 |
< |
to the construction database. The results of the tests can then be |
| 464 |
> |
to the construction database an alarm issued in case of mismatch. |
| 465 |
> |
The results of the tests can then be |
| 466 |
|
monitored through a web page. |
| 467 |
|
\item[String] |
| 468 |
|
When the third and last module or double sided assembly is mounted on |
| 469 |
|
a string, all the commissioning runs described above are performed |
| 470 |
|
just after the I$^2$C communication tests. The ``Find |
| 471 |
< |
connections'' run allows for the full functionality to be checked. |
| 471 |
> |
connections'' run allows for the devices accessibility to be checked. |
| 472 |
|
Afterwards a ``Time Alignement'' run, a ``Laser scan'' run and |
| 473 |
< |
finally a ``Pedestal and Noise'' run with HV bias are performed. The |
| 473 |
> |
finally a ``Pedestal and Noise'' run with bias voltage at 400V are performed. The |
| 474 |
|
``Laser scan'' run is done limiting the laser gain to the lower value |
| 475 |
|
which is found to be enough for the integration setup needs. |
| 476 |
|
\item[Control Ring and Redundancy.] |
| 522 |
|
Even in the most stressing condition and after a few minutes of settling, |
| 523 |
|
the highest measured temperature on the lasers was $\sim 40^\circ \mathrm{C}$ |
| 524 |
|
(while it was $48^\circ \mathrm{C}$ on the hybrid). |
| 525 |
< |
These are safe temperatures |
| 525 |
> |
These are safe temperatures~\cite{ref:lasertemp} |
| 526 |
|
thus the integration tests could be performed without problems. |
