manual

manual/manual-client/Eiger_short.tex

@@ -25,7 +25,7 @@ An EIGER single module (500~kpixels) needs:
 \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 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 wavelengh (long/short range) of the fibers chosen by the beamline infrastructure.
+\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.
 \end{itemize}
 The equipment scales linearly with the number of modules.
 Figure~\ref{fig:1} shows the relationship between the \textbf{Client} (which sits on a beamline control PC), the \textbf{Receiver} (which can run in multiple instances on one or more PCs which receive data from the detector. The receiver(s) does not necessary have to be running on the same PC as the client.) The username under which the receiver runs is the owner of the data files, if using our implementation. It is important that the receiver is closely connected to the detector (they have to be on the same network). Note that if you implement the 1Gb/s readout only: client, receiver and detector have to be all three in the same network. If you implement the 10Gb/s readout, then client, the 1~GbE of the detector and the receiver have to stay on the 1GbE. But the receiver data receiving device and the 10GbE detector can be on their private network, minimizing the missing packets.  
@@ -254,9 +254,14 @@ You can poll the detector status using:
 \begin{verbatim}
 sls_detector_get 0-status 
 \end{verbatim}
-When the detector is {\tt{idle}}, then you need to stop the receiver doing:
+When the detector is {\tt{idle}}, then the acquisition is done but the receiver could still be receiving data. If you want, you can check if the receiver is finished receiving as many frames as you were expecting (this is optional but required for many many frames acquisition or when using some delays to send data at very high frame rate.
 \begin{enumerate}
 \setcounter{enumi}{3}
+\item {\tt{sls\_detector\_get framescaught}} 
+\end{enumerate}
+Then you can stop the receiver as well now:
+\begin{enumerate}
+\setcounter{enumi}{4}
 \item {\tt{sls\_detector\_put 0-receiver stop}} 
 \end{enumerate}
 
@@ -318,7 +323,7 @@ The maximum frame rate achievable with 10~GbE, {\tt{dr 16}}, {\tt{flags continuo
 We need to leave enough time between an exposure and the following. This time is a combination of the time required by the chip, by the readout boards and eventually extra time to reduce some appearance of cross talk noise between the digital and analog parts of the chip. 
  
 \subsubsection{4 and 8 bit mode}
-In {\tt{parallel}} mode, the minimum time between frames is due to the time required to lach the values of the counter with capacitors. Thsi valkues are detectrmined in firware and they can be extimated as:
+In {\tt{parallel}} mode, the minimum time between frames is due to the time required to latch the values of the counter with capacitors. These values are determined in firmware and they can be estimated as:
 
 \begin{equation} \label{dtparallel}
 \textrm{time between frames, parallel} = 4 \mu s \cdot (clkdivider+1)
@@ -329,13 +334,13 @@ This time is independent on the {\tt{dr}}.
 In {\tt{nonparallel}} mode, it is easily possible to calculate the required asic readout time. 
 
 
-Indeed a block of (8*256) pixels are readout, the bits pixel are the {\tt{dr}} and the spead of readout is 5ns/bit *({\tt{clkdivider}}+1) : 
+Indeed a block of (8*256) pixels are readout, the bits pixel are the {\tt{dr}} and the speed of readout is 5ns/bit *({\tt{clkdivider}}+1) : 
 
 \begin{equation}\label{dtnonparallel}
 \textrm{asics readout time} = 5ns/bit \cdot 2^{(clkdivider+1)} \cdot dr \cdot (8*256) + 4 \mu s \cdot (clkdivider+1)
 \end{equation}
 
-While we expose the next frame, we still need to readout the previous frame, so we need to guarantee that the period is large enough at least to readout the frame. So the maximum frame rate has to be $1/(\textrm{asic redout time})$. The minimum period has to be equal to the asic readout time. 
+While we expose the next frame, we still need to readout the previous frame, so we need to guarantee that the period is large enough at least to readout the frame. So the maximum frame rate has to be $1/(\textrm{asic readout time})$. The minimum period has to be equal to the asic readout time. 
 
 \subsubsection{16 bit mode}
 
@@ -343,11 +348,11 @@ A similar situation happens in 16 bit mode, where this is more complicated becau
 \begin{enumerate}
 \item The chip actual {\tt{dr}} is 12 bit
 \item The chip is readout as 12-bit/pixel, but the FEB inflates the pixel values to 16-bits when it passes to the BEB. This means that effectively the FEB to BEB connection limits the data throughput in the same way as if the {\tt{dr}} of the chip would really be 16 bits.
-\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 advantageus, in 16 bit mode, one can choose how to run more freely.
+\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 \ref{dtparallel}. If we are in  {\tt{nonparallel}} mode, the dead time between frames is defined by \ref{dtnonparallel}. 
-So the maximum frame rate has to be $1/(\textrm{board redout time+chip readout time})$. 
+So the maximum frame rate has to be $1/(\textrm{board readout time+chip readout time})$. 
 
 \subsubsection{32 bit mode}
  
@@ -408,17 +413,17 @@ In table~\ref{tframes} is a list of all the readout times in the different confi
 8 & 2 & parallel & 11.2 &  2.9 &  342 & infinite\\
 \hline
 \hline
-16 & 0 & parallel & 3.4 & 6 & 168 & 8k/12k\\
+16 & 0 & parallel & 3.4 & 6.1 & (126+38)* =164 & 8k/12k\\
 \hline
-16 & 0 & nonparallel &  126 & 3.4 & 295 & 8k/23k\\
+16 & 0 & nonparallel &  126 & 5.6 & (126+52)*= 179 & 8k/23k\\
 \hline
-16 & 1 & parallel &  6.1 & 2.9&  345 & 8k/28k\\
+16 & 1 & parallel &  6.1 & 3.9 &  257 & 8k/28k\\
 \hline
-16 & 1 & nonparallel & 255 & 1.7& 588 & infinite\\
+16 & 1 & nonparallel & 255 & 3.3 &  303 & infinite\\
 \hline
-16 & 2 & parallel &  11 & 1.5&  666 & infinite \\
+16 & 2 & parallel &  11 & 1.9 & 526 & infinite \\
 \hline
-16 & 2 & nonparallel & 504 & 0.85  & 1176 & infinite\\
+16 & 2 & nonparallel & 504 & 1.8  & 555 & infinite\\
 \hline
 \hline
 %32 & 2 & parallel &  11 & 2&  & &\\
@@ -426,13 +431,13 @@ In table~\ref{tframes} is a list of all the readout times in the different confi
 %32 & 2 & nonparallel & 504 & $<2$&  & &\\
 %\hline
 \end{tabular}
-\caption{Readout settings. The {\tiny{min exptime}} possible is 5$-$10~$\mu$s. This is due to the time to pass the pixel enable signal in the whole chip.}
+\caption{Readout settings. The {\tiny{min exptime}} possible is 5$-$10~$\mu$s. This is due to the time to pass the pixel enable signal in the whole chip. The time between frames has been measured with the oscilloscope and the maximum frames rate has been tested with an external gating from a pulse generator at known frequence. The minimum period is obtained as 1/$\textrm{max frame rate}$.}
 \label{tframes}
 \end{flushleft}
 \end{table}
 \end{tiny}
 \textbf{As if you run too fast, the detector could become noisier, it is important to match the detector settings to your frame rate. This can be done having more parameters files and load the one suitable with your experiment.} We experienced that {\tt{highgain}} settings could not be used at 6~kHz.
-\textbf{We recommend to use the detector in 32 bit mode with {\tt{clkdivider 2}}, {\tt{flags parallel}}. We recommend to use the detector in 16 bit mode with {\tt{clkdivider 1}}, {\tt{flags parallel}}}. In general, choose first the desired dead time: this will tell you if you want to run in parallel or non parallel mode, although most likely it is parallel mode. Then, choose the maximum frame rate you want to aim, not exceeding what you aim for not to increase the noise. In 4 and 8 bit modes it makes no sense to run nonparallel as the exposure time is too small compared to the readout time. If the detcetor is noisy (particularly at lower theshold energies), then contact us. But ideally one would have to leave some extra time to the detector to settle. This is obtained either lowering the frame rate if possible or, if the frame rate is required to be high, then lowering the exposure time.    
+\textbf{We recommend to use the detector in 32 bit mode with {\tt{clkdivider 2}}, {\tt{flags parallel}}. We recommend to use the detector in 16 bit mode with {\tt{clkdivider 1}}, {\tt{flags parallel}}}. In general, choose first the desired dead time: this will tell you if you want to run in parallel or non parallel mode, although most likely it is parallel mode. Then, choose the maximum frame rate you want to aim, not exceeding what you aim for not to increase the noise. In 4 and 8 bit modes it makes no sense to run nonparallel as the exposure time is too small compared to the readout time. If the detector is noisy (particularly at lower threshold energies), then contact us. But ideally one would have to leave some extra time to the detector to settle. This is obtained either lowering the frame rate if possible or, if the frame rate is required to be high, then lowering the exposure time.    
 
  
 
@@ -485,7 +490,7 @@ In the EIGER on board server, this look-up table is generated assuming that the
 n_d= n_i \cdot exp(-n_i \cdot \tau),
 \label{rate}
 \end{equation}
-where $\tau$ represents an effective parameter for the dead time and the loss in efficiency. The look-up table is necessary as we are interested to obtain $c_i(c_d)$ and equation~\ref{rate} is not invertible. One needs to notice that the paralizable counter model to create a look-up tables applies only if photons arrive with a continuous pattern (like at the SLS). If photons are structured in fewer but intenser bunches, deviations may arise. This is the case for some operation modes at the ESRF. For those cases we are studying how to correct, probably from a simulated correction tables if an analytical curve cannot be found.  
+where $\tau$ represents an effective parameter for the dead time and the loss in efficiency. The look-up table is necessary as we are interested to obtain $c_i(c_d)$ and equation~\ref{rate} is not invertible. One needs to notice that the paralyzable counter model to create a look-up tables applies only if photons arrive with a continuous pattern (like at the SLS). If photons are structured in fewer but intenser bunches, deviations may arise. This is the case for some operation modes at the ESRF. For those cases we are studying how to correct, probably from a simulated correction tables if an analytical curve cannot be found.  
 \textbf{In the new calibration scheme, $\tau$ is given as a function of the energy. It is loaded from the trimbit files and interpolation between two trimbit files are performed.} One needs to make sure the appropriate $\tau$ value is written in the trimbit files, then need to load the appropriate {\tt{settings}} and {\tt{vthreshold}} before.
 
 Online rate corrections can be activated for {\tt{dr=32}}. They are particularly useful in the autosumming mode as  every single subframe is corrected before summing it. To correct for rate, the subframe duration has to be known to the correction algorithm. Rate corrections for {\tt{dr=16}} will be activated as well in the next firmware release.     
@@ -522,7 +527,7 @@ Here is a list of limits that should be checked:
 If \textbf{dr} is 32 and \textbf{clkdivider} is not 2, whatever the detector gets out is wrong (the boards cannot properly keep up) 
 \item If the variable \textbf{frames} is greater than what the memory can store (table~\ref{timgs}) and the frame rate exceed the continuos streaming (table~\ref{tcont}), limits on the maximum number of images need to be implemented if the period is lower than the one listed in table~\ref{tcont}. Check table~\ref{tframes} to see the different cases.
 \item Running at a speed that does not support the frame rate you are asking: see table~\ref{tframes} to check if the frame rate (\textbf{period}) you are asking is compatible with the \textbf{clkdivider} you are asking.
-\item Running at a redout time that does not support the frame rate you are asking. Check table~\ref{tframes} to check if the frame rate (\textbf{period}) you are asking is compatible with the \textbf{flags} you are asking.
+\item Running at a readout time that does not support the frame rate you are asking. Check table~\ref{tframes} to check if the frame rate (\textbf{period}) you are asking is compatible with the \textbf{flags} you are asking.
 \item The minimum allowed value for \textbf{exptime} should be 10~$\mu$s. 
 \item By default the {\textbf{subexptime}} is set to 2.621440~ms. Values smaller than 500~$\mu$s do not make sense. The maximum value is 5.2~s. This limits should be checked.
 \end{enumerate}
@@ -540,10 +545,21 @@ 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) 
-\item the 10Gb/s physical link is signaled by the second most external LED next to the 1Gb/s one (should be green) 
+\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 10Gb/s physical link is signaled by the second most external LED next to the 1Gb/s one (should be green). 
 \end{itemize}
 
+\begin{figure}[t]
+\begin{center}
+\includegraphics[width=.7\textwidth]{LEDSim}
+\end{center}
+\caption{1 and 10GB LEDs position.}
+\label{fLEDs}
+\end{figure}
+
+
+
+
 \subsection{Delays in sending for 1Gb/s, 10Gb/s, 10Gb flow control, receiver fifo}
 
 Extremely advanced options allow to:
@@ -770,7 +786,7 @@ Start the server again:
 \begin{verbatim}
 ./eigerDetectorServer &
 \end{verbatim}
-\textbf{Note that the server appropiate for the software version used is located inside the package: {\tt{slsDetectorsPackage/serverBin/eigerDetectorServerxx.yy.}}}.
+\textbf{Note that the server appropriate for the software version used is located inside the package: {\tt{slsDetectorsPackage/serverBin/eigerDetectorServerxx.yy.}}}.
 
 To copy the detector server on many boards, a script can be implemented on the lines of:
 \begin{verbatim}
@@ -792,7 +808,7 @@ cd executables
 ./boot_recovery 
  \end{verbatim} 
 \end{enumerate}
-In both case, after booting, only the central one should be on green and red alternating. 
+In both case, after booting, only the central LED should be on green and red alternating. 
 
 From a terminal, do:
 \begin{verbatim}
@@ -853,22 +869,9 @@ To load the special noise file look at {\tt{settingsdir/eiger/standard/eigernois
 sls_detector_put trimbits ../settingsdir/eiger/standard/eigernoise
 \end{verbatim}
 
-\section{Running the (9M at cSAXS. For now)}
-
-\underline{In the case of cSAXS, the detector software is installed on:}\\
-\underline{/sls/X12SA/data/x12saop/EigerPackage/slsDetectorsPackage}
-
-
-\begin{itemize}
-\item login as {\tt{x12saop@xbl-daq-27}}
-\item {\tt{setup\_eiger}} \#loads environmental variables and brings you to the right directory to execute commands
-\item slsReceiverScript3 1991 36 \# from one shell.. opens 36 receivers
-\item p config ../../eiger\_9m\_10gb\_xbl-daq-27\_withbottom.config
-\end{itemize}
-
 \section{Troubleshooting}
 \subsection{Cannot successfully finish an acquisition}
-\subsubsection{only master module return from acquisition}
+\subsubsection{Only master module return from acquisition}
 When no packets are received AND detector states in 'running status'. Widest list of causes. 
 Query the status of each half module till the maximum number {\tt{N}},  {\tt{for i in \$(seq\ 0\ N); do sls\_detector\_get \$i:status; done}}, to check if there are half modules that are still running.
 
@@ -879,7 +882,7 @@ If only the master modules return but ALL the other half modules do not:
 \item It can be that the synchronization cable is not connected or the termination board at the synchronization does not work. Check.
 \end{itemize}
 
-\subsubsection{a few modules do not return from acquisition}
+\subsubsection{A few modules do not return from acquisition}
 If only a few modules are still running but the others return, it is a real problem with a backend board or a synchronization bug.
 If you can, ssh into the board, kill and start the eigerDetectorServer again (see Section~\ref{server} for how to do this). Keep the terminal with the output from the  eigerDetectorServer and repeat the acquisition. 
 \begin{itemize}
@@ -889,11 +892,33 @@ If you can, ssh into the board, kill and start the eigerDetectorServer again (se
 
 \subsection{No packets (or very little) are received} 
 In both cases running \textbf{wireshark} set to receive UDP packets on the ethernet interface of the receiver (filter the UDPport$>=$xxxx, where xxxx is written in the configuration file) can help you understanding if NO packets are seen or some packets are seen. You have to set the buffer size of the receiving device in wireshark to 100Mbyte minimum. If no packets are received, check that your receiving interface and detector UDPIPs are correct (if in 10Gb). Most of the time in this case it is a basic configuration problem.
-If some packets are received, but not all, then it is an optimization problem:
+It can help looking at the receiver output, shown in an example here:
+\begin{verbatim}
+Missing Packets         : 224064
+Complete Frames         : 3499
+Last Frame Caught       : 3499
+\end{verbatim}
+
+The {\tt{Last Frame Caught}}, meaning the packet from the last frame that was sent out by the detector, can help in understanding the problem: 
+\begin{enumerate}
+\item If some packets are received, but not all, it could be a network optimization problem. In this case, the {\tt{Last Frame Caught}} will be a value close to the expected number of frames with missing frames distributed over the whole frame range. In this case: 
  \begin{itemize}
 \item For receiving data over 1Gb, the switch must have FLOW CONTROL enabled 
 \item If using 10GbE, check that the 10Gb link is active on the backpanel board. Then refer to Section~\ref{10g} to see how to configure the 10Gb ports on the receiving machine correctly. 
 \end{itemize}
+\item If the {\tt{Last Frame Caught}} value is much lower than the expected frames and you are missing a bunch of frames from a point onwards, and you are using {\tt{receiver start, status start}}: then it can be that you are stopping the receiver too early. In particular when you are using {\tt{delay}} it might be that there is some time between when the detector is already done and in {\tt{idle}} state but the receiver is still receiving data. Check with {\tt{./sls\_detector\_get framescaught}} if the receiver is already done before doing {\tt{./sls\_detector\_put receiver stop}}.   
+\item If the {\tt{Last Frame Caught}} value is much lower than the expected frames and you are missing a bunch of frames from a point onwards and you are running at a higher frame rate than the continuous framerate (see table~\ref{tcont}) with more images than the size of the memory (see table~\ref{timgs}). It might be that you are running out of memory to store images. There is no protection for this. see point~\ref{outmemory}
+ \end{enumerate}
+
+\subsection{'Got Frame Number Zero from Firmware'}\label{outmemory}
+In this case, you have run out of memory size (see table~\ref{timgs} for the size) on the boards so you are trying to store on the DDR2 memories more images that they can contain and the network is not fast enough to send everything out from the 10GbE.
+So if you see:
+\begin{verbatim}
+Got Frame Number Zero from Firmware. Discarding Packet
+\end{verbatim}
+it means that you run out of memory at the previous acquisition. The  cure is taking 2 or 3 SINGLE images in a raw to clear out the memories.
+ 
+
 
 \subsection{The module seems dead, no lights on BEBs, no IP addresses}
 \begin{itemize}
@@ -909,7 +934,7 @@ If the 1G LED (see Section~\ref{led}) on the backpanel board is not green:
 \item The IP address is assigned only at booting up of the boards. Try to reboot in case the board booted before it could have an IP address. 
 \item Check that you did not run out of IP addresses 
 \end{itemize}
- Check that the board is not in recovery mode (i.e. the central LED on the back is stable green). In this case reboot the board with the soft reset or power cycle it.
+ Check that the board is not in recovery mode (i.e. the central LED on the back is stable green, see Fig~\ref{fLEDs}). In this case reboot the board with the soft reset or power cycle it.
 
 If the 1Gb LED on the backpanel board is green (see Section~\ref{led}):
 \begin{itemize}
@@ -946,7 +971,7 @@ For every system:
 \item Hardware-wise (opening the detector) measure value of HV on C14 on the power distribution board. Check also that the small HV connector cable is really connected. 
  \end{itemize}
 
-The 2M system at ESRF has a HV enable signal that needs to be shortcut in order to owerwirite vacuum protections (when not in vacuum). 
+The 2M system at ESRF has a HV enable signal that needs to be shortcut in order to overwrite vacuum protections (when not in vacuum). 
 The 1.5M for OMNY has a relay system that enables HV only when the vacuum is good. 
 For both systems, it makes sense not to set the HV while running the configuration file but set it at a later stage when sure about the vacuum. 
 
@@ -991,6 +1016,15 @@ The detector server could not be running: either the detector was powered off, o
 
 If the powering and the temperature are OK, instead, it can be that the firmware version is incompatible to the server version and/or the client software version. So check the consistency of firmware/software/server versions.
 
+\subsection{'Acquire has already started' error message}
+If you see the client returning the following error message:\\ 
+``Acquire has already started. If previous acquisition terminated unexpectedly, reset busy flag to restart.(sls\_detector\_put busy 0)''\\
+ You need to run the command:
+\begin{verbatim}
+./sls_detector_put busy 0
+\end{verbatim}
+
+
 \section{Client checks - command line}
 
 Guide on returned strings:
@@ -1137,52 +1171,52 @@ In table~\ref{tframescomplete} is a list of all the readout times in the differe
 \begin{tiny}
 \begin{table}
 \begin{flushleft}
-\begin{tabular}{|c|c|c|c|c|c|c|c|}
+\begin{tabular}{|c|c|c|c|c|c|c|}
 \hline
-\tiny{dr} & \tiny{clkdivider} & \tiny{flags} & \tiny{readout t($\mu$s)} & \tiny{max frame rate (kHz)} & \tiny{max exptime ($\mu$s)} & \tiny{min period ($\mu$s)} & \tiny{max imgs (nominal/our network)}\\
+\tiny{dr} & \tiny{clkdivider} & \tiny{flags} & \tiny{readout t($\mu$s)} & \tiny{max frame rate (kHz)} & \tiny{min period ($\mu$s)} & \tiny{max imgs (nominal/our network)}\\
 \hline
-4 & 0 & parallel & 3.4 & 22 &  40 & 44 & 30k/50k\\
+4 & 0 & parallel & 3.4 & 22 &  44 & 30k/50k\\
 \hline
-4 & 0 & nonparallel & 44 & 21 &  3 & 49 & 30k/50k\\
+4 & 0 & nonparallel & 44 & 21 & 49 & 30k/50k\\
 \hline
-4 & 1 & parallel & 6 & 10.5 &  85 & 92 & 30k/100k\\
+4 & 1 & parallel & 6 & 10.5 &  92 & 30k/100k\\
 \hline
-4 & 1 & nonparallel & 88.7 & 10.5 & 3 & 93 & 30k/100k\\
+4 & 1 & nonparallel & 88.7 & 10.5 & 93 & 30k/100k\\
 \hline
-4 & 2 & parallel & 11.2 & 5.4 &  185 & 197 & infinite\\
+4 & 2 & parallel & 11.2 & 5.4 & 197 & infinite\\
 \hline
-4 & 2 & nonparallel & 176.5 & 5.4 &  3 & 180 & infinite\\
+4 & 2 & nonparallel & 176.5 & 5.4 & 180 & infinite\\
 \hline
 \hline
-8 & 0 & parallel & 3.4 & 11.1 &  85 & 89 & 15k/24k\\
+8 & 0 & parallel & 3.4 & 11.1 & 89 & 15k/24k\\
 \hline
-8 & 0 & nonparallel & 85.7 & 11.1 & 3 & 91 & 15k/24k\\
+8 & 0 & nonparallel & 85.7 & 11.1 & 91 & 15k/24k\\
 \hline
-8 & 1 & parallel & 6.1 & 5.7 &  174 & 181 & 15k/52k\\
+8 & 1 & parallel & 6.1 & 5.7 & 181 & 15k/52k\\
 \hline
-8 & 1 & nonparallel & 170.5 & 5.7 &  3 & 175 & 15k/52k\\
+8 & 1 & nonparallel & 170.5 & 5.7 & 175 & 15k/52k\\
 \hline
-8 & 2 & parallel & 11.2 &  2.9 &  330 & 342 & infinite\\
+8 & 2 & parallel & 11.2 &  2.9 &  342 & infinite\\
 \hline
-8 & 2 & nonparallel & 340.3 &  2.9 &  3 & 344 & infinite\\
+8 & 2 & nonparallel & 340.3 &  2.9 &  344 & infinite\\
 \hline
 \hline
-16 & 0 & parallel & 3.4 & 6 & 164 & 168 & 8k/12k\\
+16 & 0 & parallel & 3.4 & 6.1 & 164 & 8k/12k\\
 \hline
-16 & 0 & nonparallel &  126 & 3.4& 164 & 295 & 8k/23k\\
+16 & 0 & nonparallel &  126 & 5.6& 179 & 8k/23k\\
 \hline
-16 & 1 & parallel &  6.1 & 2.9&  339 & 346 & 8k/28k\\
+16 & 1 & parallel &  6.1 & 3.9&  257 & 8k/28k\\
 \hline
-16 & 1 & nonparallel & 255 & 1.7&  339 & 592 & infinite\\
+16 & 1 & nonparallel & 255 & 3.3&  303 & infinite\\
 \hline
-16 & 2 & parallel &  11 & 1.5& 66 & 78 & infinite \\
+16 & 2 & parallel &  11 & 1.9  & 526 &infinite \\
 \hline
-16 & 2 & nonparallel & 504 & 0.85 & 7 & 512 & infinite\\
+16 & 2 & nonparallel & 504 & 1.8 & 555 & infinite\\
 \hline
 \hline
-32 & 2 & parallel &  11 & 2&  & &\\
+32 & 2 & parallel &  11 & 2  & &\\
 \hline
-32 & 2 & nonparallel & 504 & $<2$&  & &\\
+32 & 2 & nonparallel & 504 & $<2$  & &\\
 \hline
 \end{tabular}
 \caption{Readout settings. The {\tiny{min exptime}} possible is 5$-$10~$\mu$s. This is due to the time to pass the pixel enable signal in the whole chip.}