manual

manual/manual-client/Eiger_short.tex

@@ -18,11 +18,22 @@
 \tableofcontents
 
 \section{Usage}
+\subsection{Short description}
+Figure ~\ref{boards} show the readout board basic components on an Eiger half module. An half module can read up to 4 readout chips.  
+\begin{figure}[t]
+\begin{center}
+\includegraphics[width=1\textwidth]{Boards}
+\end{center}
+\caption{Picture with most relevant components of the EIGER readout system. The readout system starts with the Front End Boards (FEB) which performs data descrambling (also converts the packets from 12 $\to$ 16 bits) and rate correction. The BackEndBoard (BEB) has 2x2GB DDR2 memories and can perform data buffering (storing images on board) and data summation (16 bit $\to$ 32 bits). The controls to the detector are passed through the 1Gb, while in most installations, the data are sent out through the 10GB ethernet connection.} 
+\label{boards}
+\end{figure}
+
+
 
 \subsection{Mandatory setup - Hardware}
 An EIGER single module (500~kpixels) needs:
 \begin{itemize}
-\item A chilled (water+alcohol) at 21~$^{\circ}$C for a single module (500k pixels), which needs to dissipate 85~W (every module, i.e. for two half boards). For the 9M, 1.5M, a special cooling liquid is required: 2/3 deionized water and 1/3 ESA Type 48. This is important as the high temperature generated by the boards accelerate the corrosion due to Cu/Al reaction and the blockage of the small channels where the liquid flows, in particular near the face of the detector and if it is a parallel flow and not a single loop. The (M and 1.5M run at 19~$^{\circ}$C.  
+\item A chilled (water+alcohol) at 21~$^{\circ}$C for a single module (500k pixels), which needs to dissipate 85~W (every module, i.e. for two half boards). For the 9M, 1.5M, a special cooling liquid is required: 2/3 deionized water and 1/3 ESA Type 48. This is important as the high temperature generated by the boards accelerate the corrosion due to Cu/Al reaction and the blockage of the small channels where the liquid flows, in particular near the face of the detector and if it is a parallel flow and not a single loop. The 9M and 1.5M run at 19~$^{\circ}$C.  
 \item A power supply (12~V, 8~A). For the 9~M, a special cpu is give to remotely switch on and off the detector: see section~\ref{bchip100}. 
 \item 2$\times$1~Gb/s Ethernet connectors to control the detector and, optionally, receive data at low rate. A DHCP server that gives IPs to the 1~Gb/s connectors of the detector is needed. Note that flow control has to be enabled on the switch you are using, if you plan to read the data out from there. If not, you need to implement delays in the sending out of the data.
 \item 2$\times$10~Gb/s transceivers to optionally, receive data at high rate. The 10Gb/s transceiver need to match the wavelength (long/short range) of the fibers chosen by the beamline infrastructure.
@@ -388,7 +399,6 @@ where the 'minimum time between frames' and the minimum period will be discussed
 \hline
 16 & 2 & nonparallel & 504 & 1.8  & 555 & infinite\\
 \hline
-\hline
 %32 & 2 & parallel &  11 & 2&  & &\\
 %\hline
 %32 & 2 & nonparallel & 504 & $<2$&  & &\\
@@ -440,7 +450,7 @@ A similar situation happens in 16 bit mode, where this is more complicated becau
 \item While in 4 and 8 bit mode it makes no sense to run in {\tt{nonparallel}} mode as the exptime/dead time ratio would be not advantageous, in 16 bit mode, one can choose how to run more freely.
 \end{enumerate}
 
-If we are in parallel mode, the dead time between frames, is also here described by equation~\ref{dtparallel}. If we are in {\tt{nonparallel}} mode, the dead time between frames is defined by \ref{dtnonparallel} ONLY for {\tt{clkdivider}} 1 and 2. So the maximum frame rate has to be $1/(\textrm{chip readout time})$ in this case. Only for {\tt{clkdivider}} 0 we hit some limitation in the badwidth of The FEB $\to$ BEB connection. In thsi case, the maximum frame rate is lowered compared to what expected.
+If we are in parallel mode, the dead time between frames, is also here described by equation~\ref{dtparallel}. If we are in {\tt{nonparallel}} mode, the dead time between frames is defined by \ref{dtnonparallel} ONLY for {\tt{clkdivider}} 1 and 2. So the maximum frame rate has to be $1/(\textrm{chip readout time})$ in this case. Only for {\tt{clkdivider}} 0 we hit some limitation in the bandwidth of The FEB $\to$ BEB connection. In this case, the maximum frame rate is lowered compared to what expected.
 
 \subsubsection{32 bit mode}
 The autosumming mode of Eiger is the intended for long exposure times (frame rate of order of 100Hz, PILATUS like). A single acquisition is broken down into many smaller 12-bit acquisitions, each of a {\tt{subexptime}} of 2.621440~ms by default. Normally, this is a good default value to sustain an intensity of $10^6$ photons/pixel/s with no saturation. To change the value of {\tt{subexptime}} see section~\ref{advanced}. 
@@ -467,10 +477,10 @@ The time between 12-bit subframes are listed in table~\ref{t32bitframe}.
 \textbf{The exposure time brokend up rounding up to the full next complete subframe that can be started.}
 The number of subframes composing a single 32bit acquisition can be calculated as:
 \begin{equation}
-\textrm{\# subframes}= (int) (\frac{\textrm{exptime (s)}}{\textrm{subtextime (s) + difference between frames (s)}}+0.5)
+\textrm{\# subframes}= (int) (\frac{\textrm{exptime (s)}}{\textrm{subexptime (s) + difference between frames (s)}}+0.5)
 %\label{esubframes}
 \end{equation}
-This also means that {\tt{exptime}}$<${\tt{subtextime}} will be rounded to{\tt{subtextime}}. If you want shorter acqisitions, switch two 16-bit mode (you can always sum offline if needed).   
+This also means that {\tt{exptime}}$<${\tt{subexptime}} will be rounded to{\tt{subexptime}}. If you want shorter acquisitions, either reduce the {\tt{subexptime}} or switch two 16-bit mode (you can always sum offline if needed).   
 
 The UDP header will contain, after you receive the data, the effective number of subframe per image (see section~\ref{UDP}) as  "SubFrame Num or Exp Time", i.e. the number of subframes recorded  (32 bit eiger).
 The effective time the detector has recorded data can be computed as:
@@ -479,6 +489,8 @@ The effective time the detector has recorded data can be computed as:
 %\label{esubframes}
 \end{equation}
 
+In the future release, a configurable extra time difference between subframes will be introduced for the parallel mode, so that some noise appearing in detectors at low threshold can be removed. This will enlarge the time difference between frames form the default 12~$\mu$s to something configurable, expected to be 15-40~$\mu$s (for the 9M it is currently 200~$\mu$s due to a noisier module).
+
 \section{External triggering options}\label{triggering}
 The detector can be setup such to receive external triggers. Connect a LEMO signal to the TRIGGER IN connector in the Power Distribution Board (see Fig.). The logic 0 for the board is passed by low level 0$-$0.7~V, the logic 1 is passed to the board with a signal between 1.2$-$5~V. Eiger is 50~$\Omega$ terminated. By default the positive polarity is used (negative should not be passed to the board).
 
@@ -582,7 +594,7 @@ Here is a list of parameters that should be reset:
 \subsection{Checking the 1Gb/s, 10Gb/s physical links}\label{led}
 LEDs on the backpanel board at the back of each half module signal:
 \begin{itemize}
-\item  the 1Gb/s physical link is signaled by the most external LED (should be green). For top half modules isat the extreme left. For bottom half modules is at the extreme right.  
+\item  the 1Gb/s physical link is signaled by the most external LED (should be green). For top half modules is at the extreme left. For bottom half modules is at the extreme right.  
 \item the 10Gb/s physical link is signaled by the second most external LED next to the 1Gb/s one (should be green). 
 \end{itemize}
 
@@ -1204,7 +1216,7 @@ where  {\tt{number}} is a string that should be interpreted as an int for 0/1 me
 
 \section{Complete data out rate tables}
 
-In table~\ref{tframescomplete} is a list of all the readout times in the different configurations:
+In table~\ref{tframescomplete} is a list of all the readout times in the different configurations.
 \begin{tiny}
 \begin{table}
 \begin{flushleft}
@@ -1262,6 +1274,14 @@ In table~\ref{tframescomplete} is a list of all the readout times in the differe
 \end{table}
 \end{tiny}
 
+Table~\ref{tx} shows the bandwidth of data trasnferring between the FEB and BEB and of the DDR2 memory access. the GTX lanes are only capable of 25.6~Gbit/s. This limits the 12/16 bit frame rate. The 2$\times$DDR2 memories have a bandwidth or 2$\cdot$25.6~Gb/s=51.2~Gb/s. Due to this memory access bandwidth, the 32 bit autosumming mode can only run in {\tt{clkdivider}} 2.   
+\begin{figure}[t]
+\begin{center}
+\includegraphics[width=1.\textwidth]{TansmissionRates}
+\end{center}
+\caption{Transmission bandwidth for the FEB $\to$BEB transfer (second column) and the DDR2 memories (fourth column). }
+\label{tx}
+\end{figure}
 
 \end{document}