mirror of
https://github.com/slsdetectorgroup/slsDetectorPackage.git
synced 2025-04-24 23:30:03 +02:00
manual
This commit is contained in:
Gemma Tinti
parent
a7551cca4e
commit
aa25d86310
@ -22,13 +22,13 @@
|
||||
\subsection{Mandatory setup - Hardware}
|
||||
An EIGER single module (500~kpixels) needs:
|
||||
\begin{itemize}
|
||||
\item A chilled (water+alcohol) at approximately 21~$^{\circ}$C, which needs to dissipate 85~W. For the 9M, a special cooling liquid is required: 2/3 deionized water and 1/3 ESA Type 48.
|
||||
\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.
|
||||
\item 2$\times$10~Gb/s transceivers to optionally, receive data at high rate.
|
||||
\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.
|
||||
\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.) 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.
|
||||
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.
|
||||
|
||||
\begin{figure}[t]
|
||||
\begin{center}
|
||||
@ -41,7 +41,7 @@ Figure~\ref{fig:1} shows the relationship between the \textbf{Client} (which sit
|
||||
The Client talks to control over 1~Gb Ethernet connection using TCP/IP to the detector and to the receiver. The detector sends data in UDP packets to the receiver. This data sending can be done over 1~Gb/s or 10~Gb/s.
|
||||
|
||||
\begin{itemize}
|
||||
\item \textbf{Switch on the detector only after having started the chiller: the 500k single module and the 1.5M at cSAXS have a hardware temperature sensor, which will power off the boards if the temperature is too high. Note that the detector will be power on again as soon as the temperature has been lowered. The 9M will not boot up without the correct waterflow and temperature has it has an integrated flowmeter.}
|
||||
\item \textbf{Switch on the detector only after having started the chiller: the 500k single module and the 1.5M at cSAXS/OMNY have a hardware temperature sensor, which will power off the boards if the temperature is too high. Note that the detector will be power on again as soon as the temperature has been lowered. The 9M will not boot up without the correct waterflow and temperature has it has an integrated flowmeter.}
|
||||
\item \textbf{Switch on the detector only after having connected all the cables and network. EIGER is unable to get IP address after it has been switched on without a proper network set up. In that case switch off and on the detector again.}
|
||||
\end{itemize}
|
||||
|
||||
@ -73,13 +73,13 @@ You can also Check temperatures and water flow in a browser (from the same subne
|
||||
|
||||
\subsection{Mandatory setup - Receiver}
|
||||
|
||||
The receiver is a process run on a PC closely connected to the detector. Open one receiver for every half module board (remember, a module has two receivers!!!) . Go to {\tt{slsDetectorsPackage/bin/}}, \textbf{slsReceiver} should be started on the machine expected to receive the data from the detector.
|
||||
The receiver is a process run on a PC closely connected to the detector. Open one receiver for every half module board (remember, a module has two receivers!!!) . Go to {\tt{slsDetectorsPackage/build/bin/}}, \textbf{slsReceiver} should be started on the machine expected to receive the data from the detector.
|
||||
|
||||
\begin{itemize}
|
||||
\item {\tt{./slsReceiver --rx\_tcpport xxxx}}
|
||||
\item {\tt{./slsReceiver --rx\_tcpport yyyy}}
|
||||
\end{itemize}
|
||||
where xxxx, yyyy are the tcp port numbers. Use 1955 and 1956 for example. Note that in older version of the software {\tt{--mode 1}} was used only for the ``bottom'' half module. Now, the receiver for the bottom is open without arguments anymore, but still in the configuration file one needs to write {\tt{n:flippeddatax 1}}, where {\tt{n}} indicated the half module number, 1 if it is a module.
|
||||
where xxxx, yyyy are the tcp port numbers. Use 1955 and 1956 for example. The receiver for the bottom is open without arguments but still in the configuration file one needs to write {\tt{n:flippeddatax 1}}, where {\tt{2n+1}} indicated the half module number, 1 if it is a module.
|
||||
\\ Open as many receiver as half module boards. A single module has two half module boards.
|
||||
|
||||
From the software version 3.0.1, one can decide weather start a zmq callback from the receiver to the client (for example to visualize data in the slsDetectorGui or another gui). If the zmq steam is not required (cased of the command line for example, one can switch off the streaming with {\tt{./sls\_detector\_put rx\_datastream 0}}, enable it with {\tt{./sls\_detector\_put rx\_datastream 1}}. In the case of inizialising the stream to use the slsDetectorGui, nothing needs to be taken care of by the user. If instead you want to stream the streaming on different channels, the zmq port of the client can be set stealing from the slsDetectorGui stream having {\tt{./sls\_detector\_put zmqport 300y}}. Note that if this is done globally (not for every half module n independently, then the client automatically takes into account that for every half module, there are 2 zmq stream. The receiver stream {\tt{./sls\_detector\_put rx\_zmqport 300y}} has to match such that the GUI can work.
|
||||
@ -87,14 +87,8 @@ If one desires to set the zmqport manually, he offset has to be taken into accou
|
||||
|
||||
There is an example code that can be compiled in {\tt{manual/manual-api/mainReceiver.cpp}} and gives the executable {\tt{./detReceiver}}, use it with two or more receivers to open all receivers in one single terminal: {\tt{./detReceiver startTCPPort numReceivers withCallback}}, where startTCPPort assumes the other ports are consecutively increased.
|
||||
|
||||
|
||||
|
||||
|
||||
\subsection{Mandatory setup - Client}
|
||||
|
||||
\underline{In the case of cSAXS, the detector software is installed on:}\\
|
||||
\underline{/sls/X12SA/data/x12saop/EigerPackage/slsDetectorsPackage}
|
||||
|
||||
The command line interface consists in these main functions:
|
||||
\begin{description}
|
||||
\item[sls\_detector\_acquire] to acquire data from the detector
|
||||
@ -166,9 +160,9 @@ Other important settings that are configured in the {\tt{setup.det}} file are:
|
||||
\begin{itemize}
|
||||
\item {\tt{tengiga 0/1}}, which sets whether the detector is enabled to send data through the 1~or the 10~Gb Ethernet.
|
||||
\item {\tt{flags parallel/nonparallel}}, which sets whether the detector is set in parallel acquisition and readout or in sequential mode. This changes the readout time of the chip and affects the frame rate capability (faster is {\tt{parallel}}, with higher noise but needed when the frame rate is $>2$~kHz.
|
||||
\item {\tt{dr 32/16}} sets the detector in autosumming mode (32 bit counter or not autosumming, 12 bit out of the chip). This is strictly connected to what is required for the readout clock of chip. See next point.
|
||||
\item {\tt{dr 32/16/8/4}} sets the detector in autosumming mode (32 bit counter or not autosumming, 12 bit out of the chip). This is strictly connected to what is required for the readout clock of chip. See next point.
|
||||
\item {\tt{clkdivider 0/1/2}}. Changes the readout clock: 200, 100, 50~MHz (also referred to as full, half, quarter speed). Note that autosumming mode ({\tt{dr 32}} only works at {clkdivider 2}=quarter speed). By selecting Refer to readout timing specifications in~section\ref{timing} for how to set the detector.
|
||||
\item {\tt{flags continuous/storeinram}}. Allows to take frame continuously or storing them on memory. Normally {\tt{continuous}} should be used. Enabling the {\tt{stroreinram}} mode allows you to obtain the maximum frame rate, but at the expenses to have to receive the data all at the end of the acquisition. Refer to readout timing specifications in section~\ref{timing} for how to set the detector.
|
||||
\item {\tt{flags continuous/storeinram}}. Allows to take frame continuously or storing them on memory. Users should use the {\tt{continuous}} flags. Enabling the {\tt{stroreinram}} flag makes the data to be sent out all at the end of the acquisition. Refer to readout timing specifications in section~\ref{timing} for how to set the detector. Examples will be given in section~\ref{}.
|
||||
\end{itemize}
|
||||
|
||||
One should notice that, by default, by choosing the option {\tt{dr 32}}, then the software automatically sets the detector to {\tt{clkdivider 2}}. By choosing the option {\tt{dr 16}}, the software automatically sets the detector to {\tt{clkdivider 1}}. One needs to choose {\tt{clkdivider 0}} after setting the {\tt{dr 16}} option to have the fastest frame rate.
|
||||
@ -194,12 +188,18 @@ Killing and starting the server on the boards allows you to check the firmware v
|
||||
\section{Setting up the threshold}
|
||||
\begin{verbatim}
|
||||
sls_detector_put 0-trimen N xxxx yyyy zzzz
|
||||
sls_detector_put 0-settings standard #[veryhighgain/highgain/lowgain/verylowgain] also possible
|
||||
sls_detector_put 0-threshold energy_in_eV
|
||||
sls_detector_put 0-settings standard
|
||||
sls_detector_put 0-threshold energy_in_eV standard
|
||||
\end{verbatim}
|
||||
The first line requires to specify how many ({\tt{N}}) and at which energies in eV {\{tt{xxxx}}, {\tt{yyyy}}, {\tt{zzzz}} and so on) trimmed files were generated (to allow for an interpolation). This line should normally be included into the {\tt{mydetector.config}} file and should be set for you by one of the detector group.
|
||||
NORMALLY, in this new calibration scheme, only {\tt{settings standard}} will be provided to you, unless specific cases to be discussed.
|
||||
The threshold at 6000 eV , for example would be set as:{\tt{sls\_detector\_put 0-threshold 6000}}.
|
||||
The threshold at 6000 eV , for example would be set as:{\tt{sls\_detector\_put 0-threshold 6000 standard}}.
|
||||
|
||||
For \E, at the moment normally only {\tt{standard}} settings are possible.
|
||||
{\tt{lowgain}}, {\tt{verylowgain}}, {\tt{veryhighgain}} and {\tt{highgain}} are theoretically possible, but we never calibrate like this. They could be implemented later if needed.
|
||||
|
||||
Notice that setting the threshold actually loads the trimbit files (and interpolate them between the closest calibration energies) so it is time consuming.
|
||||
The threshold is expressed in (eV) as the proper threshold setting, i.e. normally is set to 50\% of the beam energy.
|
||||
|
||||
We have added a special command, {\tt{thresholdnotb}}, which allows to scan the threshold energy without reloading the trimbits at every stage. One can either keep the trimbits at a specific value (es.32 if the range of energies to scan is large) or use the trimbits from a specific energy (like a central energy).
|
||||
\begin{verbatim}
|
||||
@ -216,13 +216,7 @@ sls_detector_put 0-period 0[time_is_s]
|
||||
\end{verbatim}
|
||||
In this acquisition 10 consecutive 1~s frames will be acquired. Note that {\tt{period}} defines the sum of the acquisition time and the desired dead time before the next frame. If {\tt{period}} is set to 0, then the next frame will start as soon as the detector is ready to take another acquisition. \\
|
||||
|
||||
For \E, at the moment normally only {\tt{standard}} settings are possible.
|
||||
{\tt{lowgain}}, {\tt{verylowgain}}, {\tt{veryhighgain}} and {\tt{highgain}} are theoretically possible, but we never calibrate like this. Thei could be implemented later if needed.\\
|
||||
Notice that the option {\tt{settings standard/highgain/lowgain/veryhighgain/verylowgain}} actually loads the trimbit files so it is time consuming. Only setting the {\tt{threshold}} does not load trimbit files.
|
||||
|
||||
The threshold is expressed in (eV) as the proper threshold setting, i.e. normally is set to 50\% of the beam energy.
|
||||
|
||||
\underline{At cSAXS, the {\tt{settingsdir}} and {\tt{caldir}} are in}\\\underline{/sls/X12SA/data/x12saop/EigerPackage/calibrations/}\\
|
||||
%\underline{At cSAXS, the {\tt{settingsdir}} and {\tt{caldir}} are in}\\\underline{/sls/X12SA/data/x12saop/EigerPackage/calibrations/}\\
|
||||
|
||||
You need to setup where the files will be written to
|
||||
\begin{verbatim}
|
||||
@ -248,23 +242,23 @@ sls_detector_get receiver
|
||||
\end{verbatim}
|
||||
|
||||
There is a more complex way of performing an acquisition, that is useful for debugging and in case one wants a non blocking behavior:
|
||||
\begin{itemize}
|
||||
|
||||
You can then reset to zero the number of frames caught, then start the receiver and the detector:
|
||||
\begin{enumerate}
|
||||
\item {\tt{sls\_detector\_put 0-resetframescaught 0}}
|
||||
\item {\tt{sls\_detector\_put 0-receiver start}}
|
||||
\item {\tt{sls\_detector\_put 0-status start}}
|
||||
\end{itemize}
|
||||
\end{enumerate}
|
||||
|
||||
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:
|
||||
\begin{itemize}
|
||||
\begin{enumerate}
|
||||
\setcounter{enumi}{3}
|
||||
\item {\tt{sls\_detector\_put 0-receiver stop}}
|
||||
\end{itemize}
|
||||
You can then reset to zero the number of frames caught, if you desire:
|
||||
\begin{itemize}
|
||||
\item {\tt{sls\_detector\_put 0-resetframescaught 0}}
|
||||
\end{itemize}
|
||||
\end{enumerate}
|
||||
|
||||
The detector will not accept other commands while acquiring. If an acquisition wishes to be properly aborted, then:
|
||||
\begin{itemize}
|
||||
@ -295,10 +289,9 @@ GbE & dynamic range & continuos maximum frame rate(Hz) & minimum period ($\mu$s)
|
||||
10 & 4 & \textbf{10240} & 98\\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\caption{Frame rate limits for the CONTINUOS streaming out of images.}
|
||||
\caption{Frame rate limits for the CONTINUOS streaming out of images, i.e. the data rate out is just below 1Gb/s or 10Gb/s.}
|
||||
\label{tcont}\end{table}
|
||||
Note that in the {\tt{continuous}} flag mode, some buffering is still done on the memories, so a higher frame rate than the proper real continuous one can be achieved. Still, this extra buffering is possible till the memories are not saturated.
|
||||
The number of images that can be stored on memories are listed in table~\ref{timgs}:
|
||||
Note that in the {\tt{continuous}} flag mode, some buffering is still done on the memories, so a higher frame rate than the proper real continuous one can be achieved. Still, this extra buffering is possible till the memories are not saturated. The number of images that can be stored on memories are listed in table~\ref{timgs}.
|
||||
\begin{table}
|
||||
\begin{tabular}{|c|c|}
|
||||
\hline
|
||||
@ -318,6 +311,52 @@ dynamic range & images\\
|
||||
The maximum frame rate achievable with 10~GbE, {\tt{dr 16}}, {\tt{flags continuous}}, {\tt{flags parallel}},{\tt{clkdivider 0}}, \textbf{6.1~kHz}. This is currently limited by the connection between the Front End Board and the Backend board. We expect the 32 bit mode limit to be \textbf{2~kHz} ({\tt{clkdivider 2}}).
|
||||
In dynamic range {\tt{dr 8}} the frame rate is \textbf{11~kHz} and for{\tt{dr 4}} is \textbf{22~kHz}. For 4 and 8 bit mode the frame rate are directly limited by the speed of the detector chip and not by the readout boards.
|
||||
|
||||
|
||||
\subsection{Minimum between frames}
|
||||
|
||||
|
||||
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:
|
||||
|
||||
\begin{equation} \label{dtparallel}
|
||||
\textrm{time between frames, parallel} = 4 \mu s \cdot (clkdivider+1)
|
||||
\end{equation}
|
||||
|
||||
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) :
|
||||
|
||||
\begin{equation}\label{dtnonparallel}
|
||||
\textrm{asics readout time} = 5ns/bit \cdot (clkdivider+1) \cdot dr \cdot (8*256) + 4 \mu s \cdot (clkdivider+1)
|
||||
\end{equation}
|
||||
This returns roughly 45~$\mu$s for 4 bit mode, 90 ~$\mu$s for 8 bit mode, both with {\tt{clkdivider}} 0.
|
||||
|
||||
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.
|
||||
|
||||
\subsubsection{16 bit mode}
|
||||
|
||||
A similar situation happens in 16 bit mode, where this is more complicvated because of three things:
|
||||
\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.
|
||||
\end{enumerate}
|
||||
|
||||
If we are in parallel mode, the dead time between frames, is also here descroibed 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/()$. The minimum period has to be equal to
|
||||
|
||||
\subsubsection{32 bit mode}
|
||||
|
||||
|
||||
\subsection{Maximum frame rate}
|
||||
|
||||
|
||||
In table~\ref{tframes} is a list of all the readout times in the different configurations:
|
||||
\begin{tiny}
|
||||
\begin{table}
|
||||
@ -328,29 +367,17 @@ In table~\ref{tframes} is a list of all the readout times in the different confi
|
||||
\hline
|
||||
4 & 0 & parallel & 3.4 & 22 & 40 & 44 & 30k/50k\\
|
||||
\hline
|
||||
4 & 0 & nonparallel & 44 & 21 & 3 & 49 & 30k/50k\\
|
||||
\hline
|
||||
4 & 1 & parallel & 6 & 10.5 & 85 & 92 & 30k/100k\\
|
||||
\hline
|
||||
4 & 1 & nonparallel & 88.7 & 10.5 & 3 & 93 & 30k/100k\\
|
||||
\hline
|
||||
4 & 2 & parallel & 11.2 & 5.4 & 185 & 197 & infinite\\
|
||||
\hline
|
||||
4 & 2 & nonparallel & 176.5 & 5.4 & 3 & 180 & infinite\\
|
||||
\hline
|
||||
\hline
|
||||
8 & 0 & parallel & 3.4 & 11.1 & 85 & 89 & 15k/24k\\
|
||||
\hline
|
||||
8 & 0 & nonparallel & 85.7 & 11.1 & 3 & 91 & 15k/24k\\
|
||||
\hline
|
||||
8 & 1 & parallel & 6.1 & 5.7 & 174 & 181 & 15k/52k\\
|
||||
\hline
|
||||
8 & 1 & nonparallel & 170.5 & 5.7 & 3 & 175 & 15k/52k\\
|
||||
\hline
|
||||
8 & 2 & parallel & 11.2 & 2.9 & 330 & 342 & infinite\\
|
||||
\hline
|
||||
8 & 2 & nonparallel & 340.3 & 2.9 & 3 & 344 & infinite\\
|
||||
\hline
|
||||
\hline
|
||||
16 & 0 & parallel & 3.4 & 6 & 164 & 168 & 8k/12k\\
|
||||
\hline
|
||||
@ -376,7 +403,9 @@ In table~\ref{tframes} is a list of all the readout times in the different confi
|
||||
\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. Then, choose the maximum frame rate you want to aim, not exceeding what you aim for not to increase the noise.
|
||||
\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.
|
||||
|
||||
|
||||
|
||||
|
||||
\section{External triggering options}\label{triggering}
|
||||
@ -796,6 +825,11 @@ 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
|
||||
@ -1068,6 +1102,65 @@ where {\tt{number}} is a string that should be interpreted as an int for 0/1 me
|
||||
|
||||
\end{enumerate}
|
||||
|
||||
\section{Complete data out rate tables}
|
||||
|
||||
In table~\ref{tframescomplete} is a list of all the readout times in the different configurations:
|
||||
\begin{tiny}
|
||||
\begin{table}
|
||||
\begin{flushleft}
|
||||
\begin{tabular}{|c|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)}\\
|
||||
\hline
|
||||
4 & 0 & parallel & 3.4 & 22 & 40 & 44 & 30k/50k\\
|
||||
\hline
|
||||
4 & 0 & nonparallel & 44 & 21 & 3 & 49 & 30k/50k\\
|
||||
\hline
|
||||
4 & 1 & parallel & 6 & 10.5 & 85 & 92 & 30k/100k\\
|
||||
\hline
|
||||
4 & 1 & nonparallel & 88.7 & 10.5 & 3 & 93 & 30k/100k\\
|
||||
\hline
|
||||
4 & 2 & parallel & 11.2 & 5.4 & 185 & 197 & infinite\\
|
||||
\hline
|
||||
4 & 2 & nonparallel & 176.5 & 5.4 & 3 & 180 & infinite\\
|
||||
\hline
|
||||
\hline
|
||||
8 & 0 & parallel & 3.4 & 11.1 & 85 & 89 & 15k/24k\\
|
||||
\hline
|
||||
8 & 0 & nonparallel & 85.7 & 11.1 & 3 & 91 & 15k/24k\\
|
||||
\hline
|
||||
8 & 1 & parallel & 6.1 & 5.7 & 174 & 181 & 15k/52k\\
|
||||
\hline
|
||||
8 & 1 & nonparallel & 170.5 & 5.7 & 3 & 175 & 15k/52k\\
|
||||
\hline
|
||||
8 & 2 & parallel & 11.2 & 2.9 & 330 & 342 & infinite\\
|
||||
\hline
|
||||
8 & 2 & nonparallel & 340.3 & 2.9 & 3 & 344 & infinite\\
|
||||
\hline
|
||||
\hline
|
||||
16 & 0 & parallel & 3.4 & 6 & 164 & 168 & 8k/12k\\
|
||||
\hline
|
||||
16 & 0 & nonparallel & 126 & 3.4& 164 & 295 & 8k/23k\\
|
||||
\hline
|
||||
16 & 1 & parallel & 6.1 & 2.9& 339 & 346 & 8k/28k\\
|
||||
\hline
|
||||
16 & 1 & nonparallel & 255 & 1.7& 339 & 592 & infinite\\
|
||||
\hline
|
||||
16 & 2 & parallel & 11 & 1.5& 66 & 78 & infinite \\
|
||||
\hline
|
||||
16 & 2 & nonparallel & 504 & 0.85 & 7 & 512 & infinite\\
|
||||
\hline
|
||||
\hline
|
||||
32 & 2 & parallel & 11 & 2& & &\\
|
||||
\hline
|
||||
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.}
|
||||
\label{tframescomplete}
|
||||
\end{flushleft}
|
||||
\end{table}
|
||||
\end{tiny}
|
||||
|
||||
|
||||
\end{document}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user