CAEN digitizer: Difference between revisions
(199 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
= Model = | {{Notice | This page is for the 1st generation digitizer, [[FSU SOLARIS DAQ | '''Here''']] for 2nd generation digitizer.}} | ||
This page is for the 1st generation of CAEN digitizer and the '''FSUDAQ'''. It covers many aspects of the usage of the digitizers. '''FSUDAQ''' is a versatile multi-threaded light-weight data acquisition software featuring graphical user interface. It utilizes the comprehensive functionalities of first-generation CAEN x725, x730, and x740 series digitizers equipped with various Digital Pulse Processing (DPP) firmwares, including Pulse-Height Analyzer (PHA), Pulse-Shape Discrimination (PSD), and Charge-Digital Converter (QDC). The program is designed for user friendly, stability, scalability, high throughput, and low latency. | |||
'''FSU DAQ''' comes with an online waveform scope, scalar panel, and online single spectrum for each input channel. Additionally, it provides an online event builder and analyzer capable of generating 1D and 2D histograms and apply graphical cuts. Users have the flexibility to create and integrate custom online analyzers into '''FSUDAQ''' to meet specific experimental requirements. '''FSUDAQ''' tested with the [[ENCORE]], [[ANASEN]], and [https://www.anl.gov/phy/argonne-inflight-radioactive-ion-separator-raisor RAISOR at ATLAS, ANL]. It will be tested at [[Split-Pole Spectrograph | Super-Enge Split-Pole Spectrograph]] in near future. In terms of performance, '''FSUDAQ''' is capable to handle a maximum of 5 million triggers without waveform or approximate 65 MB/s data rate per optical fiber in with or without waveform recording. | |||
= Current Model FSU have = | |||
{| class='wikitable' | {| class='wikitable' | ||
! Model !! Energy resolution !! Sampling rate | ! Model !! Energy resolution !! Sampling rate !! No. of Channel | ||
|- | |- | ||
|V1725 || 14-bit || 250MS/s | |V1725 || 14-bit || 250MS/s = 4 ns|| 16 | ||
|- | |- | ||
|V1730 || 14-bit || 500MS/s | |V1730 || 14-bit || 500MS/s = 2 ns|| 16 | ||
|- | |- | ||
|V1740 || 12-bit || 62.5 MS/s | |V1740 || 12-bit || 62.5 MS/s = 16 ns|| 64 | ||
|} | |} | ||
Line 17: | Line 23: | ||
From the programming point of view, the channel registers ( < 0x1XXX ) are very different for the two firmware, but the board registers (0x8000 to 0xFFFF) are almost identical. | From the programming point of view, the channel registers ( < 0x1XXX ) are very different for the two firmware, but the board registers (0x8000 to 0xFFFF) are almost identical. | ||
= | = Required CAEN libraries = | ||
On Linux (Ubuntu | On Linux (Ubuntu 22.04+), two CAEN libraries are required to run the digitizers. | ||
* CAENVMELib | * CAENVMELib | ||
Line 26: | Line 32: | ||
that would be enough for running the CAEN CoMPASS. | that would be enough for running the CAEN CoMPASS. | ||
For | {|class='wikitable' | ||
! Optional Library !! Function | |||
|- | |||
| CAENDigitizer || C-program API for controlling digitizer | |||
|- | |||
| CAEN A3818 Driver || For A3818 optical-PCIe card | |||
|- | |||
| CAEN A4818 Driver || For A4818 optical-USB adaptor | |||
|- | |||
| CAEN A5818 Driver || For A5818 optical-PCIe card | |||
|- | |||
| CAEN USB Driver || for USB connection | |||
|} | |||
= PLL (Phase-Locked-Loop) firmware = | = PLL (Phase-Locked-Loop) firmware = | ||
Line 52: | Line 68: | ||
for a master that connect to a slave, it must be 62_5. | for a master that connect to a slave, it must be 62_5. | ||
for a slave, that connect to an other slave, it must be 62_5 | for a slave, that connect to an other slave, it must be 62_5 | ||
= Synchronization of multiple digitizers = | = Synchronization of multiple digitizers = | ||
Line 83: | Line 98: | ||
An external gate generator is needed to send an ACQ start signal to the master S-IN to start the data acquisition. | An external gate generator is needed to send an ACQ start signal to the master S-IN to start the data acquisition. | ||
== Run Delay == | |||
It is possible to set Run Delay, that subtracting the time-stamp by half of the Run Delay. | |||
For example, I have 2 digitizers and they are time zeroing by TRG-OUT --> S-IN. The timestamp of the two digitizer is almost the same (with-in 1 to 2 ticks). If the Digitizer 2 has Run Delay of 800 ns. the timestamp of the digitizer 2 will be ~ 400 ns earlier than that of digitizer 1. | |||
== Start Sequence in FSUDAQ == | |||
FSUDAQ will start the digitizer from the last board to the first board. When the digitizers are set to wait for the S-IN signal or TRG-IN signal to start ACQ, setting the digitizers in "StartACQ" status means "Arming" the digitizers. I.e. the FSUDAQ will arm the digitizer from the last board to the first. | |||
In a TRG-OUT -> S-IN daisy chain setup, the first board usually be the one using SW-controlled. I.e. the ACQ will start using software signal and the time zeroing happens when the digitizer is armed. By arming the digitizer from last to the first, it ensure the when the TRG-OU signal from digi-n arrived to S-IN to digi-(n+1), the digi-(n+1) is already in the armed state and can time zeroing immediately. | |||
If the arming of the digitizer do it from first to last, there will be program delay, that caused by the for loop in the FSUDAQ. This delay could be up to few 100 ms. | |||
= Triggering = | = Triggering = | ||
Line 88: | Line 117: | ||
Below is the Trigger Logic, the register is for DPP-PHA firmware. | Below is the Trigger Logic, the register is for DPP-PHA firmware. | ||
[[File:DPP-PHA Trigger Logic.png|1000px|none]] | [[File:DPP-PHA Trigger Logic.png|1000px|none]] | ||
[[File:Another View of PHA Trigger.png|1000px|none]] | |||
== Registers related to Trigger == | == Registers related to Trigger == | ||
Line 93: | Line 124: | ||
=== Channel or Coupled Channel === | === Channel or Coupled Channel === | ||
{|class="wikitable" | {|class="wikitable" | ||
! PHA !! | ! PHA !! PSD !! QDC !! Bit !! Description | ||
|- | |- | ||
| rowspan="2" | 0x1n80 ||rowspan="2" | 0x1n80 || 19:18 || DPP Algorithm Control, Trigger Mode. | | rowspan="2" | 0x1n80 ||rowspan="2" | 0x1n80 || rowspan="2" | 0x1n40 || 19:18 || DPP Algorithm Control, Trigger Mode. | ||
|- | |- | ||
| 24 || DPP Algorithm Control, Disable self trigger | | 24 || DPP Algorithm Control, Disable self trigger | ||
|- | |- | ||
| 0x1n84 || 0x1n70 || | | 0x1n84 || 0x1n70 || 0x1n78 || || PHA/PSD : Shaped Trigger Width <br> QDC : Trigger Out Width | ||
|- | |- | ||
|rowspan="3" | 0x1nA0 ||rowspan="3"| 0x1084 || 2:0 || DPP Algorithm Control 2, Local Shaped Trigger Mode | |rowspan="3" | 0x1nA0 ||rowspan="3"| 0x1084 || rowspan="3"| N/A || 2:0 || DPP Algorithm Control 2, Local Shaped Trigger Mode | ||
|- | |- | ||
| 6:4 || DPP Algorithm Control 2, Local Trigger Validation Mode | | 6:4 || DPP Algorithm Control 2, Local Trigger Validation Mode | ||
Line 107: | Line 138: | ||
| 15:14 || DPP Algorithm Control 2, Source of veto | | 15:14 || DPP Algorithm Control 2, Source of veto | ||
|- | |- | ||
| 0x1nDA || 0x1nD4 || | | 0x1nDA || 0x1nD4 || N/A || || Veto Width | ||
|- | |- | ||
| 0x8180 + 4n || 0x810 + 4n || | | 0x8180 + 4n || 0x810 + 4n || N/A || || Trigger Validation Mask | ||
|- | |- | ||
| | | N/A || 0x106C || N/A || || Trigger Latency | ||
|} | |} | ||
Line 126: | Line 157: | ||
| 11 || TRG-IN to Mezzanines (Channel FPGA) | | 11 || TRG-IN to Mezzanines (Channel FPGA) | ||
|} | |} | ||
== Effect of Local Trigger Validation == | |||
Signals: | |||
100 Hz A-signal sent to ch-0 & ch-1 & ch-2 | |||
200 Hz B-signal sent to ch-1 & ch-2 | |||
A-signal is common to both channels | |||
Normal Trigger Settings: | |||
ch-0: 100 Hz trigger rate, 100 Hz accepted rate | |||
ch-1: 300 Hz trigger rate, 300 Hz accepted rate | |||
ch-2: 300 Hz trigger rate, 300 Hz accepted rate | |||
ch-3: 0 Hz Trigger rate, 0 Hz accepted rate | |||
=== Local Trigger Validation Set to "Both from TRG_VAL" === | |||
The TRG_VAL is from the Trigger Mask, and the Trigger Mask depends on the Local Shaped Trigger or Ext. Trigger or Global Trigger. I think it is quite easy to understand. | |||
=== Normal Trigger === | |||
==== Local Trigger Validation Set to "OR" ==== | |||
In this scenario: | |||
ch-0: Trigger Rate: 400 Hz, Accepted Rate: 200 Hz | |||
ch-1: Trigger Rate: 500 Hz, Accepted Rate: 0 Hz | |||
ch-2: Trigger Rate: 600 Hz, Accepted Rate: 0 Hz | |||
ch-3: Trigger Rate: 300 Hz, Accepted Rate: 300 Hz | |||
Explanation: | |||
Local Trigger (Validation) rate : 300 Hz | |||
The Local Trigger is delayed by a very short time than the self-trigger. | |||
ch-0: | |||
Self-Trigger: Triggers 100 times per second due to its own signal. | |||
Triggered by ch-1: Triggers an additional 300 times per second due to the B-signal on ch-1. | |||
Pile-up: The A-signal, which is common to both channels, is triggered twice in rapid succession, leading to pile-up and reducing the effective accepted rate to 200 Hz. | |||
ch-1: | |||
Trigger should be 600 Hz = self-trigger + Local Trigger rate. For some reason it is not but only 500 Hz. | |||
And since all self-trigger is followed by the local trigger in a very short time. All event are considered to be pile-up. | |||
ch-2: | |||
same as ch-1 | |||
ch-3: | |||
no self-trigger and triggered by local trigger of 300 Hz. | |||
==== Local Trigger Validation Set to "AND" ==== | |||
In this scenario: | |||
ch-0: Trigger Rate: 200 Hz, Accepted Rate: 0 Hz | |||
ch-1: Trigger Rate: 400 Hz, Accepted Rate: 200 Hz | |||
ch-2: Trigger Rate: 300 Hz, Accepted Rate: 300 Hz | |||
ch-3: Trigger Rate: 0 Hz, Accepted Rate: 0 Hz | |||
Explanation: | |||
Local Trigger rate : 100 Hz (ch-0 & ch-1), 0 Hz (ch-2, ch-3) | |||
ch-0: | |||
The self-trigger followed by the Local trigger, so all events considered as pile-up. | |||
ch-1: | |||
All A-signal is followed by the local trigger, so only B-signal is accepted (non-pile-up) | |||
ch-2 and ch-3: | |||
The local trigger is 0 Hz, so, only self-trigger. | |||
=== Coincident Trigger === | |||
==== Local Trigger Validation Set to "OR" ==== | |||
In this scenario: | |||
ch-0: Trigger Rate: 100 Hz, Accepted Rate: 100 Hz | |||
ch-1: Trigger Rate: 300 Hz, Accepted Rate: 300 Hz | |||
ch-2: Trigger Rate: 300 Hz, Accepted Rate: 300 Hz | |||
ch-3: Trigger Rate: 0 Hz, Accepted Rate: 0 Hz | |||
Explanation: | |||
Local Shaped Trigger rate : 300 Hz for all channels | |||
Since the trigger is coincident, the self-trigger can make coincident with the local shaped trigger, so no pile-up and every channel is same as self-trigger. | |||
==== Local Trigger Validation Set to "AND" ==== | |||
In this scenario: | |||
ch-0: Trigger Rate: 100 Hz, Accepted Rate: 100 Hz | |||
ch-1: Trigger Rate: 100 Hz, Accepted Rate: 100 Hz | |||
ch-2: Trigger Rate: 0 Hz, Accepted Rate: 0 Hz | |||
ch-3: Trigger Rate: 0 Hz, Accepted Rate: 0 Hz | |||
Explanation: | |||
Local Shaped Trigger rate : 100 Hz for ch-0 and ch-1, 0 Hz for ch-2, ch-3 | |||
So, the result is pretty obvious. | |||
== Single board == | == Single board == | ||
=== Scenario 0 | === Scenario 0 : No coincident, or self trigger=== | ||
No coincident, or self trigger | |||
0x1n80 0x00000 0xC0000 // set Trigger mode to '''Normal mode''' or '''Independent mode''' at DPP Algorithm Control. | 0x1n80 0x00000 0xC0000 // set Trigger mode to '''Normal mode''' or '''Independent mode''' at DPP Algorithm Control. | ||
=== Scenario 1 | === Scenario 1: Ch-(2n+1) is triggered from Ch-(2n) === | ||
Ch-1 is triggered from Ch- | |||
Cannot do. It is because the Ch-0 and Ch-1 are coupled channels. | |||
=== Scenario | === Scenario 2 : Coincident of a coupled channel === | ||
Coincident of ch-0 and ch-1 when both channels are within 1000 ns or 125 ticks. | Coincident of ch-0 and ch-1 when both channels are within 1000 ns or 125 ticks. | ||
Line 152: | Line 279: | ||
0x10A0 0x00 0x7 // Enable local Shaped Trigger, AND mode | 0x10A0 0x00 0x7 // Enable local Shaped Trigger, AND mode | ||
=== Scenario | === Scenario 3 : Ch-k is coincident with ch-j === | ||
For ch-k and ch-j are not in the same coupled channel. For example: | |||
ch-0 is self-trigger | |||
ch-7 is coincident with ch-0 | |||
Register Setting for DPP-PHA in the free | Register Setting for DPP-PHA in the free write file: | ||
//boardID address value mask | //boardID address value mask | ||
Line 169: | Line 299: | ||
* Set the ch-0, Local Shaped trig. [G] to be '''The even Channel''' | * Set the ch-0, Local Shaped trig. [G] to be '''The even Channel''' | ||
[[File:Setting of channel-0.png]] | |||
* Set the ch-7, Trig Mode to be '''Coincident''', Local Trig. Valid. [G] to be ''' | * Set the ch-7, Trig Mode to be '''Coincident''', Local Trig. Valid. [G] to be '''Both from REG_VAL''' | ||
[[File:Setting of channel-7.png]] | |||
* In the board setting, go to the Trigger Mask tap, and set row 6-7, column 0-1. | * In the board setting, go to the Trigger Mask tap, and set row 6-7, column 0-1. | ||
[[File:Setting of Trigger map.png]] | |||
* If needed, adjust the shaped trigger widths of ch-0 and ch-7. | |||
<span style="color:red"> Notice that the ch-6 will be triggered. To have independent self trigger, need to use other channel. </span> | |||
== Multiple boards == | |||
The idea is very similar to the case of a single board. The only differences are in using TRG-IN and TRG-OUT. The Individual Trigger (ITRG) is included in the TRG-IN, we can send a TRG-OUT signal (controlled by 0x8110) to the TRG-IN of the other boards for the trigger. | |||
To have External trigger to be coincident with any channels. I have a 10 Hz TTL to TRG-IN. The same 10 Hz put into ch-2. This signal is combined with a 100 Hz signal to ch-4, so ch-4 has 110 Hz signal. | |||
The trigger setting should be coincident, and the Local Trigger Validation should be from Mother Board. In fact, this is not really means from Mother Board, but from the Trigger Mask. | |||
[[File:Trigger Setting For external Trigger.png|500px]] | |||
Depends on the case, the TRG-IN Mode would be '''Whole duration of the TRG-IN'''. Otherwise, the "Edge of TRG-IN" would be a delta signal, and it can only make coincident if the signal is arrived earlier. | |||
[[File:Ext Trigger setting 2.png|500px]] | |||
The Trigger mask should include Ext. Trigger. | |||
[[File:Ext Trigger setting 3.png|500px]] | |||
=== checking TRG-IN and Channel Coincident Time === | |||
Using the TRG-OUT Mask and set the TRG-OUT to be TRG-OUT Mask, once can check the coincident of the timing. | |||
[[File:TRG-OUT Mask.png|500px]] | |||
The following is the TRG-OUT from oscilloscope (yellow, and a copy of the input signal of ch-4 (blue). The first peak is from the TRG-IN and the 2nd peak is from the ch-4. | |||
[[File:Oscilloscope screenshot of the TRG-OUT.png|500px]] | |||
== TRIG-OUT Generated by Channels == | |||
The Local Shaped Trigger should be OR. | |||
[[File:Local Shaped Trigger OR.png|500px]] | |||
And the TRG-OUT Mask should be | |||
[[File:TRG OUT MASK.png|500px]] | |||
= Reading the bin file from CAEN CoMPASS = | = Reading the bin file from CAEN CoMPASS = | ||
The CoMPASS can output *.bin data. The beginning of the file is a 2 bytes header. It must be in the form of 0xCAEx, where x indicate the energy format and waveform existence. After that, | [[File:CAEN Binary format.png|thumb|right]] | ||
The CoMPASS can output *.bin data. The beginning of the file is a 2 bytes header. It must be in the form of 0xCAEx, where x indicate the energy format and waveform existence. | |||
{|class='wikitable' | |||
! last 4 bit of the header !! meaning | |||
|- | |||
| b0001 = 0x1 || Energy in Channel, 16 bit | |||
|- | |||
| b0010 = 0x2|| Energy in MeV or KeV, 64 bit double | |||
|- | |||
| b0011 = 0x3 || Energy in Channel (16-bit) + Energy in MeV or KeV (64 bit double) | |||
|- | |||
| b0100 = 0x4 || Energy is Channel, 16 bit | |||
|- | |||
| b1000 = 0x8 || Waveform is recorded | |||
|} | |||
If x < 8, there is no waveform. | |||
After that, | |||
{|class='wikitable' | {|class='wikitable' | ||
Line 200: | Line 388: | ||
| trace ... || 2 * (number of samples) | | trace ... || 2 * (number of samples) | ||
|} | |} | ||
A BinReader class can be found in [https://fsunuc.physics.fsu.edu/git/rtang/CoMPASS_BinReader.git here]. | A BinReader class can be found in [https://fsunuc.physics.fsu.edu/git/rtang/CoMPASS_BinReader.git here]. | ||
Line 207: | Line 393: | ||
= Data structure, Read-out, and buffer size= | = Data structure, Read-out, and buffer size= | ||
In the CAENDigitizer.h, the CAEN_DGTZ_READDATA() will read the buffer of the digitizer. For a single call of the function, | The data and the readout are controlled by the following registers | ||
{|class="wikitable" | |||
! Register PHA or PSD !! Register QDC !! Symbol !! Max !!Name !! Function | |||
|- | |||
|0x800C || 0x800C || <math>N_b</math> || 0xA || Agg. Organization || divide the memory of a channel by <math>2^{N_b}</math> parts | |||
|- | |||
|0x1n34 || 0x8020 || <math>N_e</math> || 511 || Event/Agg || number of event in a agg. and the number of event in a memory division | |||
|- | |||
|0xEF1C || 0xEF1C || <math>N_a</math> || 1023 || Max Agg/Read || max number of Agg. pre readout call | |||
|- | |||
|0x1n20 || 0x8024* || <math>N_s</math> || 12 bit || Record Length || in QDC, the register 0x8024 is only for write, reading use register 0x1024. | |||
|- | |||
|0x8000 || 0x8000 || <math>E_x</math> || 1 bit || DPP Algorithm (bit 17) || Enable Extra | |||
|} | |||
In the CAENDigitizer.h, the CAEN_DGTZ_READDATA() will read the buffer of the digitizer. For a single call of the function, <math>N_a</math> block aggregate of data is read from the buffer and clear. The data structure started with 4 words header( 1 word = 32 bits). It follows with dual (or group) channel aggregate. In PHA or PSD firmware, up to <span style="color:red"> 8? </span> channel aggregates in a block aggregate. In each channel aggregate, it must have <math>N_e</math> events. The digitizer buffer ONLY be ready for ready out when <math>N_e</math> events in one memory division. When <math>N_e</math> set to zero, the digitizer (mysteriously) auto-set the value. | |||
== General Idea on the Settings == | |||
For low input trigger rate, set the <math>N_e</math> to be small, so the data can be ready for read out fast. While the <math>N_e</math> is small, set the <math>N_b</math> large so that most of the memory is being used and reduce the death time. | |||
The only caution is <math>N_b</math> should not set too large, so that the memory of each division is small. See the [[CAEN_digitizer#Memory_Overflow | Memory Overflow]]. | |||
It is almost no harm to set <math>N_a</math> to be high, as this is the maximum number of block to be read. | |||
== Group (or Dual) Channel Block == | |||
[[File:Dual Channels Aggregation.png|500px|thumb|right|Dual(paired) Channels Aggregation]] | |||
The number of hits for a Dual-channel block is controlled by the register 0x1n34 for PHA. The block can only be read when the block is fully filled except for forced flushing via register 0x1n3C (write-only). For example, if <math>N_e = 100</math>, when the trigger rate is only 10 Hz, a dual-channel block can be read every 10 sec. | |||
In x725 or x730 PHA or PSD, channel 2i and 2i+1 are paired or grouped, so it is called Dual Channel Block. In x740, channel 8i to 8i+7 are grouped, so it called Group Channel Block. In general, Channel Block for short. | |||
Each channel Aggregation has 2 words of header. after that is <math>N_e</math> events (0x1n34) for paired channels. | |||
In each measurement, there is 1 word of header, Sample/2 words for waveform, 1 word for Extra (if any), and 1 word for Energy, so total = (2 + Sample/2 + Extra), where Sample size is the Record Length = (0x1n20) * 8 ch = <math>8 N_s</math>. Extra is controlled by bit[17] of (0x8000), denote as (0x8000:17) | |||
== Board Aggregation == | |||
[[File:Board Aggregate Data format.png|500px|thumb|right|Board Aggregation. The digitizer data format, from CAEN manual.]] | |||
The Register 0xEF1C controls the maximum number of Aggregations per read. One aggregation could have many dual-channel blocks. <span style="color:red"> what is the maximum number? 8? </span> | |||
== Buffer Size calculation == | |||
The data stored in the digitizer can be retrieved using | |||
CAEN_DGTZ_ReadData(int handle, CAEN_DGTZ_ReadMode_t mode, char *buffer, uint32_t *bufferSize); | |||
typedef enum { | |||
CAEN_DGTZ_SLAVE_TERMINATED_READOUT_MBLT = 0, | |||
CAEN_DGTZ_SLAVE_TERMINATED_READOUT_2eVME = 1, | |||
CAEN_DGTZ_SLAVE_TERMINATED_READOUT_2eSST = 2, | |||
CAEN_DGTZ_POLLING_MBLT = 3, | |||
CAEN_DGTZ_POLLING_2eVME = 4, | |||
CAEN_DGTZ_POLLING_2eSST = 5, | |||
} CAEN_DGTZ_ReadMode_t; | |||
The data format of the buffer contains two parts: A whole chuck of the buffer can contain multiple board aggregation (depending on <math>N_a</math>). Inside a board aggregation, there could be at most <span style="color:red">8? </span> Channels Aggregation, depending on the channel mask. Each Channels Aggregation can contain at most <math>N_e</math> measurements. | |||
Each board aggregate has 4 words of header. 1 words = 4 bytes = 32 bits, followed by <math>N_a</math> channel aggregate. Each channel block has <math>N_e (2 + E_x + 4N_s)</math> words. | |||
In Each readout, there can be more than 1 Board Aggregation (0xEF1C). The total buffer size (byte) needed is | |||
<math> B = N_a \left(4 + \sum_{i=0}^{7} \left( 2 + N_e(i) C_{on}(i) (2 + 4 N_s(i) + E_x ) \right) \right) \times 4 \textrm{Byte} </math> | |||
where | |||
<math> C_{on}(n) = </math> Channel enabled mask of the paired channel n. | |||
This formula is verified by reading data and decoding the buffer, showing that <math> N_a </math> is the board Agg and <math> N_e </math> is the number of Event in a dual-channel agg. | |||
However, this calculation is about factor 2 smaller than the CAEN's calculation in | |||
CAEN_DGTZ_MallocReadoutBuffer(int handle, char **buffer, uint32_t *size); | |||
The CAEN's formula for the buffer size is almost 2 times more. | |||
<math> B_c = 2B + 16(1-N_a) = \left( 4 + N_a \left(4 + 2 \times \sum_{i=0}^{7} \left( 2 + N_e(i) C_{on}(i) (2 + 4 N_s(i) + E_{2} ) \right) \right) \right) \times 4 \textrm{Byte}</math> | |||
The | The CAEN's formula is verified at 2024, March 6 for PHA firmware. | ||
The data | == Data Rate == | ||
{{Notice | assumes no pile-up }} | |||
{{Notice | Always increase the Even/agg first }} | |||
For example, Event/Agg = 511, Max-Agg/read = 10, read rate is 400 Hz. The data rate for 1 channel only (has extra2 and no trace) is ((511*3 + 2)*10 + 4)*4*400 = 23.4 MB/s. This setting is suitable for ~2 MHz Trigger rate, given that the read rate can be 400 Hz and that depends on the machines. | |||
The data rate for no trace + extra2 is | |||
<math> ((3 N_e + 2 ) + 4) N_a f_R \times 4~\textrm{Byte/s} \leq 80 ~\textrm{MB/s} </math> | |||
where | |||
<math> f_R </math> is the read/sec | |||
<math> (3 N_e + 6 ) N_a \approx 3 N_e N_a \leq \frac{20}{f_R} ~\textrm{M} \cdot \textrm{word} </math> | |||
For <math> f_R = 100 </math> read/sec, the product <math> N_e N_a \approx 67 </math> kilo-word. | |||
And the trigger rate is <math> N_e N_a f_R </math>. | |||
For 100 kHz trigger rate for every 16 channels (1600 kHz for the whole board), if the machines can read 100 times for each sec, thus, for every read, it needs to take 16k hits. To get 16k Hit for each read, we set Event/agg = 511 for each channel, thus we need Agg/read = 32. the data rate would be ((511*3 + 2)*32 + 4)*100*4 = 18.7 MB/s. so, the maximum trigger rate for the whole board is ~ 6.5 MHz. | |||
If we put 2 MHz for 3 channels, no trace + extra2. We set Event/Agg = 511, Agg/read = 128, so we have 65.4 k Event/read. and | |||
if 100 reads/sec, we can have 6.5 MHz. The data rate would be 74.95 MB/s or 4.4 GB/min. When the read/sec is 300, we can set Agg/read = 40. | |||
When traces are also recorded, say, we take 625 samples (= 1.25 us for 730 series), which takes 313 words. That is ~100 times more data compared with the 3 words for only extra2 and no trace. | |||
Say, we have 1 kHz trigger rate for every 16 channels. read 100 times for a second, in every read, we take 10 hits or 160 hits for the whole board for one read call. we can take Event/agg = 160, and Agg/read = 1. The data rate is (160 *(3 + 313) + 2) *4 * 100 = 19.3 MB/s. Therefore, the maximum total trigger rate for 625 sample traces is 64 kHz/board. | |||
Thus, when in Scope mode, it is better to set Agg/read = 1. | |||
The maximum trace length is 131064 samples. | |||
The following table assumes with Extra2 and 100 read/sec | |||
{|class="wikitable" | |||
! Trace sample !! Max trigger rate (whole board) !! recommend Event/Agg (Agg/read) | |||
|- | |||
| 0 || 6.5 MHz || 511 (128) | |||
|- | |||
| 500 || 77 kHz || 511 (2) | |||
|- | |||
| 800 || 51 kHz || 511 (1) | |||
|- | |||
| 1000 || 40 kHz || 400 (1) | |||
|- | |||
| 2000 || 20 kHz || 200 (1) | |||
|- | |||
| 5000 || 8 kHz || 80 (1) | |||
|- | |||
| 10000 || 4 kHz || 40 (1) | |||
|- | |||
| 131064 || 300 Hz || 3 (1) | |||
|} | |||
== Memory Overflow == | |||
Digitizer has internal memory. | |||
{|class="wikitable" | |||
! Model !! Memory / channel !! SRAM Chip | |||
|- | |||
| V1740A/B || 1.5 MSample/ch | |||
|- | |||
| V1740/C/D || 192 kSample/ch || GS880Z36CGT-250 x 16 = 9 Mbit x 16 = 288 kByte / ch (for 64ch) | |||
|- | |||
| V1730/C/S, VX1730/C/S || 640 kSample/ch | |||
|- | |||
| V1725/C/D, VX1725/C/D || 640 kSample/ch | |||
|- | |||
| DT5730/S || 640 kSample/ch | |||
|- | |||
| DT5730B/SB || 5.12 MSample/ch | |||
|} | |||
The memory can be divided using the register 0x800C (for both PHA, PSD, QDC) named as Aggregate Organization. When the bit value of 0x800C is <math>N_b</math>, the memory is divided into <math>2^{N_b}</math>. In each division, the number of event is set by the register Number of Events per Aggregate <math>N_e </math> (0x8020 for QDC, 0x1n34 for PSD and PHA). According the the CAEN manual UM4874, the data will store in a division up to <math>N_e</math> events, when a division has <math>N_e </math> events, it is ready to be read, and data will store in the next division. | |||
Memory Overflow happens when the number of event over size a division capacity. When this happens, the BUSY led on the front will on and the digitizer would be unable to respond for certain commands (e.g. readout request will be no respond). The capacity of each division is Memory / channel <math> M </math> divided by the number of division <math> 2^{N_b} </math>. The size of an event <math> S </math> [in sample] depends on the record length <math> N_s </math> [in sample] and if the extra word is enabled, <math> S \approx 12 + 2 E_x + N_s </math>, where <math> E_x</math> indicate the extra word, the block header takes 4 words = 8 samples, Agg. header takes 2 words = 4 samples. The total size needed for an aggregate is <math> \sum S = N_e(12 + 2 E_x + N_s) </math>. When <math> \sum S > M / 2^{N_b} </math>, memory overflow. | |||
In order to prevent memory overflow, the condition <math> \sum S < M / 2^{N_b} </math> must be meet. This is very important for V1740/C/D digitizer due to their small memory size. In FSUDAQ, the Digitizer::SetOptimialAggOrg() safe-guard the <math>N_b</math> setting to avoid memory overflow. | |||
= FSUDAQ = | = FSUDAQ = | ||
[[File:Main Window of the FSUDAQ.png|500px|thumb|right|Main window of the FSUDAQ (Qt6)]] | [[File:Main Window of the FSUDAQ.png|500px|thumb|right|Main window of the FSUDAQ (Qt6)]] | ||
[[File:Board Control of FSUDAQ.png|500px|thumb|right|Board Control of the FSUDAQ (Qt6)]] | [[File:Board Control of FSUDAQ.png|500px|thumb|right|Board Control of the FSUDAQ (Qt6)]] | ||
The (idea of the) FSU DAQ is based on the [https://www.sciencedirect.com/science/article/pii/S0168900222001954 BoxScore]([https://github.com/goluckyryan/BoxScore code] of BoxScore). The core is the digitizer class that directly controls and reads out the CAEN digitizer. The GUI of the DAQ uses CERN ROOT GUI elements. | The (idea of the) FSU DAQ is based on the [https://www.sciencedirect.com/science/article/pii/S0168900222001954 BoxScore]([https://github.com/goluckyryan/BoxScore code] of BoxScore). The core is the digitizer class that directly controls and reads out the CAEN digitizer. The GUI of the DAQ uses CERN ROOT GUI elements. | ||
Line 223: | Line 564: | ||
The Goals for the DAQ are: | The Goals for the DAQ are: | ||
* support V1725, V1730, V1740 digitizers | * support V1725, V1730, V1740 digitizers | ||
* multi-thread readout and real-time time sorting | * multi-thread readout and real-time time sorting | ||
* extendable to other digitizers and functionalities | * extendable to other digitizers and functionalities | ||
* user-friendly (full GUI, limited terminal output) | * user-friendly (full GUI, limited terminal output) | ||
* easy to maintain (avoid abstract coding and entirely objective programming) | * easy to maintain (avoid abstract coding and entirely objective programming) | ||
* for Ubuntu 22.04 or equivalent | * for Ubuntu 22.04 or equivalent | ||
The | The DAQ can be downloaded at | ||
*https://fsunuc.physics.fsu.edu/git/rtang/FSUDAQ_Qt6 (development) | |||
*https://github.com/goluckyryan/FSUDAQ (stable, kind of) | |||
https://fsunuc.physics.fsu.edu/git/rtang/FSUDAQ_Qt6 | |||
== The Digitizer Class == | == The Digitizer Class == | ||
Line 249: | Line 584: | ||
* Table of Register Address | * Table of Register Address | ||
* Load (Save) register setting from (to) a binary file | * Load (Save) register setting from (to) a binary file | ||
== Register Address and Setting Binary File== | == Register Address and Setting Binary File== | ||
Line 256: | Line 589: | ||
The registers < 0x8000 are channel settings. For example, 0x1nXX is for channel-n, or 0x80XX is for writing to all channels. The registers >= 0x8000 are board settings. | The registers < 0x8000 are channel settings. For example, 0x1nXX is for channel-n, or 0x80XX is for writing to all channels. The registers >= 0x8000 are board settings. | ||
For | For most types of digitizers, the register > 0x8000 registers are the same and have the same meaning. | ||
Because the | Because the channels are either paired or grouped. There are some registers also grouped. for example, the pre-trigger length is the same for any grouped channels, once the pre-trigger length is set for any one of the grouped channels, the pre-trigger length of the other channel is also set. | ||
A Setting uses 4 bytes (unsigned int) to store 32 bits of each register value. Using an array of size 2048 can store all register settings, which is only 8192 bytes. The following table shows the conversion. | A Setting uses 4 bytes (unsigned int) to store 32 bits of each register value. Using an array of size 2048 can store all register settings, which is only 8192 bytes. The following table shows the conversion. | ||
Line 279: | Line 612: | ||
[[File:Methods for settings.png|600px|frameless]] | [[File:Methods for settings.png|600px|frameless]] | ||
== | == Tested Data Rate == | ||
[[File: | [[File:Trigger Rate for V1725.png|frame|right|Trigger rate tested for 600 kHz to 10 channels]] | ||
[[File: | |||
A single V1725 digitizer with DPP-PHA firmware was used. The performance of '''FSUDAQ''' was tested using a Ubuntu 22.04 machine on Intel~Core~i7-7700 CPU with 3.6 GHz and 8 cores, 64 GB RAM, and 1 TB NVMe SSD hard-disk. | |||
Execution of '''FSUDAQ'''~used approx. 90 MB memory without any digitizer connected, approximately \mbox{200 MB} of additional memory was used when digitizer connected. | |||
Input signals were generated by CAEN DT5810B signal emulator. The raise time and decay time of each pulse was 100 ns and 500 ns respectively. The amplitude of the pulse was 1 voltage. The pulse was fed to a linear fan-in-fan-out to split into 10 channels, each channel was connected to the digitizer. | |||
The sample size for the digitizer was set to 496 samples or 1984 ns. The input raise time was 96 ns, trigger hold-off and peak hold-off were 0 ns. The threshold was 1000 least-significant-bit. The trapezoid settings for the digitizer are 96 ns for the rise time, 96 ns for the flat-top, 500 ns for the pole-zero, 0 ns for the peaking time. Under this trapezoid setting, the theoretical maximum pile-up free trigger rate is 3.47 MHz. In addition, the database output was enabled. In order to maximum the data readout, the number of events per aggregation was 1023 (register 0x1034), the maximum number of aggregation per readout was 511 (register 0xEF1C), and the aggregation organization was 511 (register 0x800C). | |||
Without saving the waveform, a 600 kHz signal was sent to 10 channels. The data transfer rate was 65 MB/s. After converting the data into root file. The trigger rate against all input channels is shown on Figure on the right. The onboard memory of the digitizer are shared by 2i and 2(i+1) channels. The channel 0, 5, and 12 own the entire memory so that they can have 600 kHz, but the other channels, due to memory sharing, the performance was reduced to approximately 500 kHz/channel. With trace saving of 496 samples, the digitizer was able to accept 70 kHz/channel. The data transfer rate was also limited at 65 MB/s. | |||
== Timing order of the data == | |||
One thing is for sure, the time is sorted in a grouped channel, as the channels are sharing the same buffer. When pulling data from the digitizer, the buffers are grouped in block aggregation, and the block aggregation is not time sorted. | |||
The FSUDAQ pulls the buffer as frequently as possible using reading threads. In principle, the digitizer buffer outputs data in a first-in-first-out fashion. However, since the data is grouped in aggregation, it is possible that the timings between different channels can be very different, i.e. the time stamp of a high trigger rate channel could be way ahead of a low trigger rate channel. It is checked that the time is sorted (or in order) for each channel alone. Therefore, when scanning the aggregation and saving the hit following the file position order, the timing is not sorted in general. i.e. the timestamp could jump around for different channels but the timestamp for each channel is sorted. | |||
== FSUDAQ run on Raspberry Pi 5 + v4818 optical-USB adaptor == | |||
Since CAEN provides libraries with ARM support, I obtained a raspberry pi 5 with 8 GB RAM, and tried to run the FSUDAQ with A4818 optical-USB adaptor. It works without problems. I put 6 ch with 160 Hz each, no problem on the scope, and the data taking is OK. | |||
The elog cannot be installed by apt, and the qt6-chart-dev is used instead of libqt6chart in Ubuntu 22.04. | |||
== FSUDAQ with V5818 PCI gen 3 optical-fiber adaptor == | |||
Simply use the CAENVMELib 4.0+ and install the a5818 driver. | |||
=== Slow write cycle === | |||
The CAENVEMLib 4.0+ has a slightly slower write cycle compared with older version. It could take up to 300 usec for a write cycle. | |||
== FSUDAQ with DT5730B == | |||
The FSUDAQ was tested with DT5730B via USB connection. The CAENUSBdrv library must be installed. DT5730B via optical fiber is also tested and working. | |||
= Event Builder = | |||
An event builder comes with FSUDAQ. | |||
The EventBuilder will read K (batch size) measurements (or hits), sorted and saved as a vector A, it also read the next K hits, sorted and saved as vector B. By compare the timestamp of the last hit of A and the first hit of B, a smaller set of hit will be sorted. And event building is started on vector A. After vector A exhausted, it will be replaced by vector B, and the next K hits will be read, sorted, and saved as a new vector B. And compare the timestamp of vector A and B started again. | |||
{|class="wikitable" | |||
! Step !! Process | |||
|- | |||
| 0 || read K hits, sort, and saved as vector A | |||
|- | |||
| 1 || read next K hit, sort, and saved as vector B | |||
|- | |||
| 2 || compared the last timestamp of A, tA1, and the first timestamp of B, tB0 | |||
|- | |||
| 3 || if tA1 < tB0, go to step 5, else step 4 | |||
|- | |||
| 4 || tA1 > tB0, take the hit in A where the timestamp is >= tB0, take the hit in B where time timestamp is <= tA1. Sort them, and put them back to vector A. | |||
|- | |||
| 5 || event building using vector A | |||
|- | |||
| 6 || after vector A exhausted, replace it with vector B. read the next K event, sort, and saved as B. Go back to step 5. | |||
|- | |||
| 7 || repeat 2 | |||
|} | |||
when multiple file is used, the above process is done on each file, and there will be many vector A. Event building will be done among the many vector A. | |||
== Usage == | |||
[commit [https://github.com/goluckyryan/FSUDAQ/commit/9ea67c4554357e353d64fa3d06b93c09d2c6397d 9ea67c4] will automatically determine the batch size] | |||
./EventBuilder [timeWindow] [withTrace][inFile1] [inFile2] .... | |||
timeWindow : in ns, -1 = no event building | |||
withTrace : 0 for no trace, 1 for trace | |||
Output file name is constructed from inFile1 | |||
= FSU2CAEN = | |||
[[File:FSUDAQ data convertor.png|thumb|right]] | |||
In the git repository, under the Aux folder, there is '''FSU2CAEN''', which can convert fsu file to CoMPASS binary. This allows users to use existing analysis routine. | |||
= DPP Firmware = | |||
== PHA == | |||
The Pulse Height Analyzer is basically Trapezoid Filter. | |||
=== Trapezoid Filter === | |||
Please see the following webpages : [https://nukephysik101.wordpress.com/2020/03/20/trapezoid-filter/ Trapezoid Filter] and [https://nukephysik101.wordpress.com/2022/05/11/trapezoid-filter-revisit/ Trapezoid Filter Revisit]. | |||
[[File:Trapezoid Filter.png|700px]] | |||
=== Some settings and its meaning === | |||
[[File:Signal Scheme for PHA.png|800px|Signal Scheme for PHA, Taken and edited from CAEN Manual UM5960]] | |||
=== Channel Registers === | |||
There are 23 registers to control each (or coupled) channel for PHA firmware. Settings with [G] mean '''grouped''', i.e. the setting are shared within a coupled channel. Settings with [W] means write-only. | |||
{| class="wikitable" | |||
! Number !! Name!! Address !! Description | |||
|- | |||
| 1 || Record Length [G] || 0x1029 || total time of a trace | |||
|- | |||
| 2 || PreTrigger || 0x1038 || time before trigger | |||
|- | |||
| 3 || Input Dynamic Range || 0x1028 || Vpp to be 0.5V or 2.0V | |||
|- | |||
| 4 || Input Rise Time || 0x1058 || time constant for the RC-CR2 | |||
|- | |||
| 5 || DC Offset || 0x1098 || See [[#DC_offset_0x1n98| DC offset]] | |||
|- | |||
| colspan="4" | '''Trigger Settings''' | |||
|- | |||
| 9 || RC-CR2 Smoothing Factor || 0x1054 || moving average of the RC-CR2 (2nd derivative) signal | |||
|- | |||
| 6 || Trigger Threshold || 0x106c || When the RC-CR2 signal is over the threshold | |||
|- | |||
| 7 || Rise Time Validation Window || 0x1070 || If no trigger occurs in the window -> pileup/rej | |||
|- | |||
| 8 || Trigger Hold-off Width || 0x1074 || Within this width, trigger disabled | |||
|- | |||
| 10 || Shaped Trigger Width || 0x1084 || The width of the square pulse to go to trigger logic | |||
|- | |||
| 11 || DPP Algorithm Control 2 [G] || 0x10A0 || see table '''DPP Algorithm Control 2''' | |||
|- | |||
| colspan="4" | '''Trapezoid Settings''' | |||
|- | |||
| 12 || Trapezoid Rise Time || 0x105C || | |||
|- | |||
| 13 || Trapezoid Flat Top || 0x1060 || | |||
|- | |||
| 14 || Peaking Time || 0x1064 || The time from trigger for energy calculation | |||
|- | |||
| 15 || Decay Time || 0x1068 || The input signal decay time. This control the pole-zero correction. | |||
|- | |||
| 16 || Peak Hold-off || 0x1078 || This related to pile-up detection. | |||
|- | |||
| 17 || DPP Algorithm Control || 0x1080 || see table '''DPP Algorithm Control''' | |||
|- | |||
| colspan="4" | '''Other Settings''' | |||
|- | |||
| 18 || Fine Gain || 0x10C4 || see [[#fine_gain_0x1nC4|fine gate]] | |||
|- | |||
| 19 || Events/Agg [G] || 0x1034 || Number of Events in a memory partition / aggregation | |||
|- | |||
| 20 || Veto Width || 0x10D4 || | |||
|- | |||
| 21 || Data Flush [W] || 0x103C || | |||
|- | |||
| 22 || Channel Stop Acquisition || 0x1040 || | |||
|- | |||
| 23 || Individual Channel Software Trigger [W] || 0x10C0 || | |||
|} | |||
{| class="wikitable" | |||
|+ DPP Algorithm Control | |||
! Bit Range !! Name !!Description | |||
|- | |||
| [5:0] || Trapezoid Scaling || see [[#Trapezoid_Rescaling]] | |||
|- | |||
| [9:8] || Decimation || Average of the input signal. This applies to energy filter only. | |||
|- | |||
| [11:10] || Decimation Gain || | |||
|- | |||
| [13:12] || Peak Mean || Average window of the trapezoid peak | |||
|- | |||
| [16] || Input Polarity || | |||
|- | |||
| [19:18] || Trigger Mode || Normal / Coincident / Anti-Coincident | |||
|- | |||
| [22:20] || Base Line Moving Average || | |||
|- | |||
| [24] || Disable Self-trigger || | |||
|- | |||
| [26] || Enable Roll-Over Flag || | |||
|- | |||
| [27] || Enable Pile-Up Flag || | |||
|} | |||
{| class="wikitable" | |||
|+ DPP Algorithm Control 2 | |||
! Bit Range !! Name !! Description | |||
|- | |||
| [2:0] || Local Shaped Trigger Mode || | |||
|- | |||
| [6:4] || Local Trigger Validation Mode || | |||
|- | |||
| [10:8] || Extras 2 Word Option || | |||
|- | |||
| [15:14] || Source of Veto || | |||
|- | |||
| [17:16] || Step for Trigger Count Rate || | |||
|- | |||
| [18] || Active Baseline calculation || calculate baseline even ACQ not running | |||
|- | |||
| [19] || Tag correlated events || | |||
|- | |||
| [23:20] || Set Channel Probe Type || Need TRIG-OUT to be Channel Probe | |||
|- | |||
| [29] || Baseline Restore || | |||
|} | |||
=== Some Special Settings === | |||
Most of the register settings are trivial and east to understand, here is the list of special registers. | |||
==== Trapezoid Rescaling ==== | |||
The | The register 0x1n80 (DPP Algorithm Control) bit [5:0] is the Trapezoid rescaling factor (SHF). It is calculated using the formula | ||
<math> | |||
\textrm{SHF} = \lfloor \log_2( k * M) \rfloor | |||
</math> | |||
<math> k = </math> trapezoid rise time in the register | |||
<math> M = </math> input decay time in the register | |||
<math> | For example, if the rise time is 4000 ns ( = 250), decay time is 50 us ( = 3125 ), then then SHF = <math> \lfloor \log_2( 250 * 3125) \rfloor = 19 = \textrm{0x13} </math>. This is the standard scaling, meaning the internal trapezoid waveform (48 bits) is right-bit-shifted by 19 (i.e. >> 19 ) to a 15-bit value. | ||
==== fine gain 0x1nC4 ==== | |||
<math> | fine gain = <math> f </math> is a 16-bit value (0 - 65535 = 0xFFFF ) calculated by | ||
<math> | <math> f = \textrm{0xFFFF} \times \frac{2^{\textrm{SHF}}}{k M} \times \alpha </math> | ||
<math> | <math> \alpha = </math> the desired physical fine gate, range 0 to <math> k M / 2^{\textrm{SHF}} </math> | ||
<math> | For example, the rise time and decay are the same as above, <math> 2^{\textrm{SHF}} / k / M = 0.671 </math>, so that the maximum desired fine gate <math> \alpha = 1.49 </math> | ||
The FSUDAQ always set <math> \alpha = 1 </math> | |||
==== DC offset 0x1n98 ==== | |||
The | This is a 16-bit register. The percentage DC offset <math> \beta </math> to register value is <math> \textrm{0xFFFF} \times ( 1 - \beta ) </math> | ||
<math> | For example, a 40% DC offset, the register value is <math> \textrm{0xFFFF} \times 0.6 = 0x9999 </math> | ||
== | === Pile-up decision === | ||
[[File:Pile-up scenario for PHA.png|600px|Pile-up scenario for PHA. Taken From CAEN Manual UM5960.]] | |||
== PSD == | |||
to be filled | |||
== QDC == | |||
to be filled | |||
= Contact = | = Contact = | ||
Tsz Leung (Ryan) Tang mailto:rtang@fsu.edu | Tsz Leung (Ryan) Tang mailto:rtang@fsu.edu |
Latest revision as of 13:42, 2 November 2024
Notice : | This page is for the 1st generation digitizer, Here for 2nd generation digitizer. |
This page is for the 1st generation of CAEN digitizer and the FSUDAQ. It covers many aspects of the usage of the digitizers. FSUDAQ is a versatile multi-threaded light-weight data acquisition software featuring graphical user interface. It utilizes the comprehensive functionalities of first-generation CAEN x725, x730, and x740 series digitizers equipped with various Digital Pulse Processing (DPP) firmwares, including Pulse-Height Analyzer (PHA), Pulse-Shape Discrimination (PSD), and Charge-Digital Converter (QDC). The program is designed for user friendly, stability, scalability, high throughput, and low latency.
FSU DAQ comes with an online waveform scope, scalar panel, and online single spectrum for each input channel. Additionally, it provides an online event builder and analyzer capable of generating 1D and 2D histograms and apply graphical cuts. Users have the flexibility to create and integrate custom online analyzers into FSUDAQ to meet specific experimental requirements. FSUDAQ tested with the ENCORE, ANASEN, and RAISOR at ATLAS, ANL. It will be tested at Super-Enge Split-Pole Spectrograph in near future. In terms of performance, FSUDAQ is capable to handle a maximum of 5 million triggers without waveform or approximate 65 MB/s data rate per optical fiber in with or without waveform recording.
Current Model FSU have
Model | Energy resolution | Sampling rate | No. of Channel |
---|---|---|---|
V1725 | 14-bit | 250MS/s = 4 ns | 16 |
V1730 | 14-bit | 500MS/s = 2 ns | 16 |
V1740 | 12-bit | 62.5 MS/s = 16 ns | 64 |
DPP firmware
Both V1725 and V1730 can be equipped with the PHA (pulse-height analysis) or PSD (pulse-shape decimation) firmware.
From the programming point of view, the channel registers ( < 0x1XXX ) are very different for the two firmware, but the board registers (0x8000 to 0xFFFF) are almost identical.
Required CAEN libraries
On Linux (Ubuntu 22.04+), two CAEN libraries are required to run the digitizers.
- CAENVMELib
- CAENComm
that would be enough for running the CAEN CoMPASS.
Optional Library | Function |
---|---|
CAENDigitizer | C-program API for controlling digitizer |
CAEN A3818 Driver | For A3818 optical-PCIe card |
CAEN A4818 Driver | For A4818 optical-USB adaptor |
CAEN A5818 Driver | For A5818 optical-PCIe card |
CAEN USB Driver | for USB connection |
PLL (Phase-Locked-Loop) firmware
A digitizer need a proper PLL firmware to run.
If the PLL firmware is wrong (i.e. The PLL lock led is off ), you need to refresh the PLL firmware using the CAENUpgrader
The PLL file has the format of
V17XX_vcxo500_refYY_pll_outZZ.rbf
where
XX is the model type,
for example 25, 25S, 30, 40
YY is the ref clock,
for the master or stand alone digitizer, 50 (= 50 MHz ) is ok. for a slave, it must be 62_5.
ZZ is the clock output,
for master or stand alone digitizer, 0 or 62_5 (= 62.5) are OK. for a master that connect to a slave, it must be 62_5. for a slave, that connect to an other slave, it must be 62_5
Synchronization of multiple digitizers
This is important when multiple digitizers are used. A digitizer using its internal clock (controlled by a switch on the board) is a designated Master. Synchronization means:
- Same source of clock
- Same phase (or constant difference in phase, it can be corrected by the Run delay (0x8170))
- Same starting time for ACQ
Notice that a Timer Reset can be done by writing the Software Clear register (0xEF28), but it does not guarantee all timers are clear at the same time. The Software clear is done whenever ACQ starts.
Master and Slaves Method
The CLK-out of the Master connects to the CLK-in of the slave in the daisy chain. And all slaves should use an external clock. The PLL firmware must be changed properly in order for the clocks of the master and the slaves to be locked and sync.
External Clock unit, everyone is slave Method
testing clocks
The TRG-OUT can be set with register 0x811C to be CLKOUT or CLK Phase. so that the synchronization can be checked.
TRG-IN/TRG-OUT daisy chain
Connect the TRG-IN (Master) to TRG-OUT (Slave). All slaves are set the ACQ start/stop on the TRG-IN (0x8100:[1:0]). The Master is set the ACQ star/stop to SW trigger, and the TRI-OUT is RUN (0x811C::[19:16]).
Once the master ACQ is started by SW, its TRG-OUT will send RUN signal and propagate to the slave TRG-IN that the slaves will be start/stop accordingly.
using S-IN with external TTL/NIM pulse
All master and slaves are set the ACQ start/stop to be S-IN, and TRG-OUT are S-IN (copy of S-IN). Master and slaves are connected TRG-OUT/S-IN daisy chain.
An external gate generator is needed to send an ACQ start signal to the master S-IN to start the data acquisition.
Run Delay
It is possible to set Run Delay, that subtracting the time-stamp by half of the Run Delay.
For example, I have 2 digitizers and they are time zeroing by TRG-OUT --> S-IN. The timestamp of the two digitizer is almost the same (with-in 1 to 2 ticks). If the Digitizer 2 has Run Delay of 800 ns. the timestamp of the digitizer 2 will be ~ 400 ns earlier than that of digitizer 1.
Start Sequence in FSUDAQ
FSUDAQ will start the digitizer from the last board to the first board. When the digitizers are set to wait for the S-IN signal or TRG-IN signal to start ACQ, setting the digitizers in "StartACQ" status means "Arming" the digitizers. I.e. the FSUDAQ will arm the digitizer from the last board to the first.
In a TRG-OUT -> S-IN daisy chain setup, the first board usually be the one using SW-controlled. I.e. the ACQ will start using software signal and the time zeroing happens when the digitizer is armed. By arming the digitizer from last to the first, it ensure the when the TRG-OU signal from digi-n arrived to S-IN to digi-(n+1), the digi-(n+1) is already in the armed state and can time zeroing immediately.
If the arming of the digitizer do it from first to last, there will be program delay, that caused by the for loop in the FSUDAQ. This delay could be up to few 100 ms.
Triggering
Below is the Trigger Logic, the register is for DPP-PHA firmware.
Channel or Coupled Channel
PHA | PSD | QDC | Bit | Description |
---|---|---|---|---|
0x1n80 | 0x1n80 | 0x1n40 | 19:18 | DPP Algorithm Control, Trigger Mode. |
24 | DPP Algorithm Control, Disable self trigger | |||
0x1n84 | 0x1n70 | 0x1n78 | PHA/PSD : Shaped Trigger Width QDC : Trigger Out Width | |
0x1nA0 | 0x1084 | N/A | 2:0 | DPP Algorithm Control 2, Local Shaped Trigger Mode |
6:4 | DPP Algorithm Control 2, Local Trigger Validation Mode | |||
15:14 | DPP Algorithm Control 2, Source of veto | |||
0x1nDA | 0x1nD4 | N/A | Veto Width | |
0x8180 + 4n | 0x810 + 4n | N/A | Trigger Validation Mask | |
N/A | 0x106C | N/A | Trigger Latency |
Board
Register | ! Bit | Description |
---|---|---|
0x810C | Global Trigger Mask or Logic | |
0x8110 | Front Panel TRG-OUT Logic | |
0x811C | 10 | TRG-IN control |
11 | TRG-IN to Mezzanines (Channel FPGA) |
Effect of Local Trigger Validation
Signals:
100 Hz A-signal sent to ch-0 & ch-1 & ch-2 200 Hz B-signal sent to ch-1 & ch-2 A-signal is common to both channels
Normal Trigger Settings:
ch-0: 100 Hz trigger rate, 100 Hz accepted rate ch-1: 300 Hz trigger rate, 300 Hz accepted rate ch-2: 300 Hz trigger rate, 300 Hz accepted rate ch-3: 0 Hz Trigger rate, 0 Hz accepted rate
Local Trigger Validation Set to "Both from TRG_VAL"
The TRG_VAL is from the Trigger Mask, and the Trigger Mask depends on the Local Shaped Trigger or Ext. Trigger or Global Trigger. I think it is quite easy to understand.
Normal Trigger
Local Trigger Validation Set to "OR"
In this scenario:
ch-0: Trigger Rate: 400 Hz, Accepted Rate: 200 Hz ch-1: Trigger Rate: 500 Hz, Accepted Rate: 0 Hz ch-2: Trigger Rate: 600 Hz, Accepted Rate: 0 Hz ch-3: Trigger Rate: 300 Hz, Accepted Rate: 300 Hz
Explanation:
Local Trigger (Validation) rate : 300 Hz The Local Trigger is delayed by a very short time than the self-trigger.
ch-0:
Self-Trigger: Triggers 100 times per second due to its own signal. Triggered by ch-1: Triggers an additional 300 times per second due to the B-signal on ch-1. Pile-up: The A-signal, which is common to both channels, is triggered twice in rapid succession, leading to pile-up and reducing the effective accepted rate to 200 Hz.
ch-1:
Trigger should be 600 Hz = self-trigger + Local Trigger rate. For some reason it is not but only 500 Hz. And since all self-trigger is followed by the local trigger in a very short time. All event are considered to be pile-up.
ch-2:
same as ch-1
ch-3:
no self-trigger and triggered by local trigger of 300 Hz.
Local Trigger Validation Set to "AND"
In this scenario:
ch-0: Trigger Rate: 200 Hz, Accepted Rate: 0 Hz ch-1: Trigger Rate: 400 Hz, Accepted Rate: 200 Hz ch-2: Trigger Rate: 300 Hz, Accepted Rate: 300 Hz ch-3: Trigger Rate: 0 Hz, Accepted Rate: 0 Hz
Explanation:
Local Trigger rate : 100 Hz (ch-0 & ch-1), 0 Hz (ch-2, ch-3)
ch-0:
The self-trigger followed by the Local trigger, so all events considered as pile-up.
ch-1:
All A-signal is followed by the local trigger, so only B-signal is accepted (non-pile-up)
ch-2 and ch-3:
The local trigger is 0 Hz, so, only self-trigger.
Coincident Trigger
Local Trigger Validation Set to "OR"
In this scenario:
ch-0: Trigger Rate: 100 Hz, Accepted Rate: 100 Hz ch-1: Trigger Rate: 300 Hz, Accepted Rate: 300 Hz ch-2: Trigger Rate: 300 Hz, Accepted Rate: 300 Hz ch-3: Trigger Rate: 0 Hz, Accepted Rate: 0 Hz
Explanation:
Local Shaped Trigger rate : 300 Hz for all channels
Since the trigger is coincident, the self-trigger can make coincident with the local shaped trigger, so no pile-up and every channel is same as self-trigger.
Local Trigger Validation Set to "AND"
In this scenario:
ch-0: Trigger Rate: 100 Hz, Accepted Rate: 100 Hz ch-1: Trigger Rate: 100 Hz, Accepted Rate: 100 Hz ch-2: Trigger Rate: 0 Hz, Accepted Rate: 0 Hz ch-3: Trigger Rate: 0 Hz, Accepted Rate: 0 Hz
Explanation:
Local Shaped Trigger rate : 100 Hz for ch-0 and ch-1, 0 Hz for ch-2, ch-3
So, the result is pretty obvious.
Single board
Scenario 0 : No coincident, or self trigger
0x1n80 0x00000 0xC0000 // set Trigger mode to Normal mode or Independent mode at DPP Algorithm Control.
Scenario 1: Ch-(2n+1) is triggered from Ch-(2n)
Cannot do. It is because the Ch-0 and Ch-1 are coupled channels.
Scenario 2 : Coincident of a coupled channel
Coincident of ch-0 and ch-1 when both channels are within 1000 ns or 125 ticks.
Register Setting for DPP-PHA is:
0x1084 0x7D // set the shaped trigger width is 1000 ns for channel 0 0x1184 0x7D // set the shaped trigger width is 1000 ns for channel 1 0x1080 0x40000 0xC0000 // set channel-0 to be coindient mode 0x1180 0x40000 0xC0000 // set channel-0 to be coindient mode 0x10A0 0x00 0x7 // Enable local Shaped Trigger, AND mode
Scenario 3 : Ch-k is coincident with ch-j
For ch-k and ch-j are not in the same coupled channel. For example:
ch-0 is self-trigger ch-7 is coincident with ch-0
Register Setting for DPP-PHA in the free write file:
//boardID address value mask 0-14-177 0x10A0 0x5 0x7 //DPP Algorithm Control 2 for channel-0, bit[2:0] = 101. Enable local Shaped Trigger, Mode is even channel of the coupled channel ONLY. 0-14-177 0x1780 0x40000 0xC0000 //DPP Algorithm Control for channel-7, bit[19:18] = 01. Trigger mode = Coincidence Mode 0-14-177 0x1784 0xFF 0x3FF //Shaped Trigger Width for channel-7, bit[9:0] = 00 1111 1111. Generate Shaped trigger of 255 * 16 ns. 0-14-177 0x16A0 0x50 0x70 //DPP Algorithm Control 2 for channel-6, bit[6:4] = 101. Enable local Trigger Validation, Mode is val0 = val1 = signal from mother board mask. 0-14-177 0x818C 0x1 0xFF //Trigger Validation Mask for the 3rd (4*3 = C) coupled channels (ch-6-7). bit[7:0] = 0000 0001. Set trigger of coupled channel 3 from coupled channel 0.
In FSUDAQ, in the Digitizer Settings Panel,
- Set the ch-0, Local Shaped trig. [G] to be The even Channel
- Set the ch-7, Trig Mode to be Coincident, Local Trig. Valid. [G] to be Both from REG_VAL
- In the board setting, go to the Trigger Mask tap, and set row 6-7, column 0-1.
- If needed, adjust the shaped trigger widths of ch-0 and ch-7.
Notice that the ch-6 will be triggered. To have independent self trigger, need to use other channel.
Multiple boards
The idea is very similar to the case of a single board. The only differences are in using TRG-IN and TRG-OUT. The Individual Trigger (ITRG) is included in the TRG-IN, we can send a TRG-OUT signal (controlled by 0x8110) to the TRG-IN of the other boards for the trigger.
To have External trigger to be coincident with any channels. I have a 10 Hz TTL to TRG-IN. The same 10 Hz put into ch-2. This signal is combined with a 100 Hz signal to ch-4, so ch-4 has 110 Hz signal.
The trigger setting should be coincident, and the Local Trigger Validation should be from Mother Board. In fact, this is not really means from Mother Board, but from the Trigger Mask.
Depends on the case, the TRG-IN Mode would be Whole duration of the TRG-IN. Otherwise, the "Edge of TRG-IN" would be a delta signal, and it can only make coincident if the signal is arrived earlier.
The Trigger mask should include Ext. Trigger.
checking TRG-IN and Channel Coincident Time
Using the TRG-OUT Mask and set the TRG-OUT to be TRG-OUT Mask, once can check the coincident of the timing.
The following is the TRG-OUT from oscilloscope (yellow, and a copy of the input signal of ch-4 (blue). The first peak is from the TRG-IN and the 2nd peak is from the ch-4.
TRIG-OUT Generated by Channels
The Local Shaped Trigger should be OR.
And the TRG-OUT Mask should be
Reading the bin file from CAEN CoMPASS
The CoMPASS can output *.bin data. The beginning of the file is a 2 bytes header. It must be in the form of 0xCAEx, where x indicate the energy format and waveform existence.
last 4 bit of the header | meaning |
---|---|
b0001 = 0x1 | Energy in Channel, 16 bit |
b0010 = 0x2 | Energy in MeV or KeV, 64 bit double |
b0011 = 0x3 | Energy in Channel (16-bit) + Energy in MeV or KeV (64 bit double) |
b0100 = 0x4 | Energy is Channel, 16 bit |
b1000 = 0x8 | Waveform is recorded |
If x < 8, there is no waveform.
After that,
block | bytes |
---|---|
Board | 2 |
Channel | 2 |
Timestamp | 8 |
Energy | [x == 1, 2], [x == 2, 8], [x == 3, 10], [x == 4, 2] |
Flags | 4 |
Waveform code | 1 |
number of samples | 4 |
trace ... | 2 * (number of samples) |
A BinReader class can be found in here.
Data structure, Read-out, and buffer size
The data and the readout are controlled by the following registers
Register PHA or PSD | Register QDC | Symbol | Max | Name | Function |
---|---|---|---|---|---|
0x800C | 0x800C | 0xA | Agg. Organization | divide the memory of a channel by parts | |
0x1n34 | 0x8020 | 511 | Event/Agg | number of event in a agg. and the number of event in a memory division | |
0xEF1C | 0xEF1C | 1023 | Max Agg/Read | max number of Agg. pre readout call | |
0x1n20 | 0x8024* | 12 bit | Record Length | in QDC, the register 0x8024 is only for write, reading use register 0x1024. | |
0x8000 | 0x8000 | 1 bit | DPP Algorithm (bit 17) | Enable Extra |
In the CAENDigitizer.h, the CAEN_DGTZ_READDATA() will read the buffer of the digitizer. For a single call of the function, block aggregate of data is read from the buffer and clear. The data structure started with 4 words header( 1 word = 32 bits). It follows with dual (or group) channel aggregate. In PHA or PSD firmware, up to 8? channel aggregates in a block aggregate. In each channel aggregate, it must have events. The digitizer buffer ONLY be ready for ready out when events in one memory division. When set to zero, the digitizer (mysteriously) auto-set the value.
General Idea on the Settings
For low input trigger rate, set the to be small, so the data can be ready for read out fast. While the is small, set the large so that most of the memory is being used and reduce the death time.
The only caution is should not set too large, so that the memory of each division is small. See the Memory Overflow.
It is almost no harm to set to be high, as this is the maximum number of block to be read.
Group (or Dual) Channel Block
The number of hits for a Dual-channel block is controlled by the register 0x1n34 for PHA. The block can only be read when the block is fully filled except for forced flushing via register 0x1n3C (write-only). For example, if , when the trigger rate is only 10 Hz, a dual-channel block can be read every 10 sec.
In x725 or x730 PHA or PSD, channel 2i and 2i+1 are paired or grouped, so it is called Dual Channel Block. In x740, channel 8i to 8i+7 are grouped, so it called Group Channel Block. In general, Channel Block for short.
Each channel Aggregation has 2 words of header. after that is events (0x1n34) for paired channels. In each measurement, there is 1 word of header, Sample/2 words for waveform, 1 word for Extra (if any), and 1 word for Energy, so total = (2 + Sample/2 + Extra), where Sample size is the Record Length = (0x1n20) * 8 ch = . Extra is controlled by bit[17] of (0x8000), denote as (0x8000:17)
Board Aggregation
The Register 0xEF1C controls the maximum number of Aggregations per read. One aggregation could have many dual-channel blocks. what is the maximum number? 8?
Buffer Size calculation
The data stored in the digitizer can be retrieved using
CAEN_DGTZ_ReadData(int handle, CAEN_DGTZ_ReadMode_t mode, char *buffer, uint32_t *bufferSize); typedef enum { CAEN_DGTZ_SLAVE_TERMINATED_READOUT_MBLT = 0, CAEN_DGTZ_SLAVE_TERMINATED_READOUT_2eVME = 1, CAEN_DGTZ_SLAVE_TERMINATED_READOUT_2eSST = 2, CAEN_DGTZ_POLLING_MBLT = 3, CAEN_DGTZ_POLLING_2eVME = 4, CAEN_DGTZ_POLLING_2eSST = 5, } CAEN_DGTZ_ReadMode_t;
The data format of the buffer contains two parts: A whole chuck of the buffer can contain multiple board aggregation (depending on ). Inside a board aggregation, there could be at most 8? Channels Aggregation, depending on the channel mask. Each Channels Aggregation can contain at most measurements.
Each board aggregate has 4 words of header. 1 words = 4 bytes = 32 bits, followed by channel aggregate. Each channel block has words.
In Each readout, there can be more than 1 Board Aggregation (0xEF1C). The total buffer size (byte) needed is
where
Channel enabled mask of the paired channel n.
This formula is verified by reading data and decoding the buffer, showing that is the board Agg and is the number of Event in a dual-channel agg.
However, this calculation is about factor 2 smaller than the CAEN's calculation in
CAEN_DGTZ_MallocReadoutBuffer(int handle, char **buffer, uint32_t *size);
The CAEN's formula for the buffer size is almost 2 times more.
The CAEN's formula is verified at 2024, March 6 for PHA firmware.
Data Rate
Notice : | assumes no pile-up |
Notice : | Always increase the Even/agg first |
For example, Event/Agg = 511, Max-Agg/read = 10, read rate is 400 Hz. The data rate for 1 channel only (has extra2 and no trace) is ((511*3 + 2)*10 + 4)*4*400 = 23.4 MB/s. This setting is suitable for ~2 MHz Trigger rate, given that the read rate can be 400 Hz and that depends on the machines.
The data rate for no trace + extra2 is
where
is the read/sec
For read/sec, the product kilo-word.
And the trigger rate is .
For 100 kHz trigger rate for every 16 channels (1600 kHz for the whole board), if the machines can read 100 times for each sec, thus, for every read, it needs to take 16k hits. To get 16k Hit for each read, we set Event/agg = 511 for each channel, thus we need Agg/read = 32. the data rate would be ((511*3 + 2)*32 + 4)*100*4 = 18.7 MB/s. so, the maximum trigger rate for the whole board is ~ 6.5 MHz.
If we put 2 MHz for 3 channels, no trace + extra2. We set Event/Agg = 511, Agg/read = 128, so we have 65.4 k Event/read. and if 100 reads/sec, we can have 6.5 MHz. The data rate would be 74.95 MB/s or 4.4 GB/min. When the read/sec is 300, we can set Agg/read = 40.
When traces are also recorded, say, we take 625 samples (= 1.25 us for 730 series), which takes 313 words. That is ~100 times more data compared with the 3 words for only extra2 and no trace.
Say, we have 1 kHz trigger rate for every 16 channels. read 100 times for a second, in every read, we take 10 hits or 160 hits for the whole board for one read call. we can take Event/agg = 160, and Agg/read = 1. The data rate is (160 *(3 + 313) + 2) *4 * 100 = 19.3 MB/s. Therefore, the maximum total trigger rate for 625 sample traces is 64 kHz/board.
Thus, when in Scope mode, it is better to set Agg/read = 1.
The maximum trace length is 131064 samples.
The following table assumes with Extra2 and 100 read/sec
Trace sample | Max trigger rate (whole board) | recommend Event/Agg (Agg/read) |
---|---|---|
0 | 6.5 MHz | 511 (128) |
500 | 77 kHz | 511 (2) |
800 | 51 kHz | 511 (1) |
1000 | 40 kHz | 400 (1) |
2000 | 20 kHz | 200 (1) |
5000 | 8 kHz | 80 (1) |
10000 | 4 kHz | 40 (1) |
131064 | 300 Hz | 3 (1) |
Memory Overflow
Digitizer has internal memory.
Model | Memory / channel | SRAM Chip |
---|---|---|
V1740A/B | 1.5 MSample/ch | |
V1740/C/D | 192 kSample/ch | GS880Z36CGT-250 x 16 = 9 Mbit x 16 = 288 kByte / ch (for 64ch) |
V1730/C/S, VX1730/C/S | 640 kSample/ch | |
V1725/C/D, VX1725/C/D | 640 kSample/ch | |
DT5730/S | 640 kSample/ch | |
DT5730B/SB | 5.12 MSample/ch |
The memory can be divided using the register 0x800C (for both PHA, PSD, QDC) named as Aggregate Organization. When the bit value of 0x800C is , the memory is divided into . In each division, the number of event is set by the register Number of Events per Aggregate (0x8020 for QDC, 0x1n34 for PSD and PHA). According the the CAEN manual UM4874, the data will store in a division up to events, when a division has events, it is ready to be read, and data will store in the next division.
Memory Overflow happens when the number of event over size a division capacity. When this happens, the BUSY led on the front will on and the digitizer would be unable to respond for certain commands (e.g. readout request will be no respond). The capacity of each division is Memory / channel divided by the number of division . The size of an event [in sample] depends on the record length [in sample] and if the extra word is enabled, , where indicate the extra word, the block header takes 4 words = 8 samples, Agg. header takes 2 words = 4 samples. The total size needed for an aggregate is . When , memory overflow.
In order to prevent memory overflow, the condition must be meet. This is very important for V1740/C/D digitizer due to their small memory size. In FSUDAQ, the Digitizer::SetOptimialAggOrg() safe-guard the setting to avoid memory overflow.
FSUDAQ
The (idea of the) FSU DAQ is based on the BoxScore(code of BoxScore). The core is the digitizer class that directly controls and reads out the CAEN digitizer. The GUI of the DAQ uses CERN ROOT GUI elements.
The Goals for the DAQ are:
- support V1725, V1730, V1740 digitizers
- multi-thread readout and real-time time sorting
- extendable to other digitizers and functionalities
- user-friendly (full GUI, limited terminal output)
- easy to maintain (avoid abstract coding and entirely objective programming)
- for Ubuntu 22.04 or equivalent
The DAQ can be downloaded at
- https://fsunuc.physics.fsu.edu/git/rtang/FSUDAQ_Qt6 (development)
- https://github.com/goluckyryan/FSUDAQ (stable, kind of)
The Digitizer Class
The Digitizer class is ClassDigitizer.h/C. The class controls the digitizer by manipulating the register. And various types of digitizers are different by the registers. Thus, the class can control different types of digitizers without modification. The digitizer classes store the connection, board information, and a copy of the register. It provides an interface to better control the digitizer, for example, manipulate the bits for the control bit.
The digitizer classes directly write/read the registers in the digitizer. The advantage is complete control of the hardware and a simplified program that only 3 pieces are needed:
- WriteRegister()
- ReadRegister()
- Table of Register Address
- Load (Save) register setting from (to) a binary file
Register Address and Setting Binary File
The registers < 0x8000 are channel settings. For example, 0x1nXX is for channel-n, or 0x80XX is for writing to all channels. The registers >= 0x8000 are board settings.
For most types of digitizers, the register > 0x8000 registers are the same and have the same meaning.
Because the channels are either paired or grouped. There are some registers also grouped. for example, the pre-trigger length is the same for any grouped channels, once the pre-trigger length is set for any one of the grouped channels, the pre-trigger length of the other channel is also set.
A Setting uses 4 bytes (unsigned int) to store 32 bits of each register value. Using an array of size 2048 can store all register settings, which is only 8192 bytes. The following table shows the conversion.
Address Range | Comment | Setting Index | Example |
---|---|---|---|
0x1000 - 0x1FFF | Channel Setting | 0x1XXX / 4 | 0x1020 -> 1032 |
0x8000 - 0x81FF | Board Setting | 0x8XXX & 0x0FFF | 0x8080 -> 32 |
0xEF00 - 0xEFFF | Other Board Setting | 0xEXXX & 0x0FFF | 0xEF04 -> 961 |
0xF000 - 0xFFFF | Read only board configuration | (0xFXXX & 0x0FFF) + 0x0200 | 0xF008 -> 520 |
The digitizer class provides a method to convert the setting binary to a text file. The following diagram illustrates the methods between board setting, setting in memory, and setting file
Tested Data Rate
A single V1725 digitizer with DPP-PHA firmware was used. The performance of FSUDAQ was tested using a Ubuntu 22.04 machine on Intel~Core~i7-7700 CPU with 3.6 GHz and 8 cores, 64 GB RAM, and 1 TB NVMe SSD hard-disk. Execution of FSUDAQ~used approx. 90 MB memory without any digitizer connected, approximately \mbox{200 MB} of additional memory was used when digitizer connected.
Input signals were generated by CAEN DT5810B signal emulator. The raise time and decay time of each pulse was 100 ns and 500 ns respectively. The amplitude of the pulse was 1 voltage. The pulse was fed to a linear fan-in-fan-out to split into 10 channels, each channel was connected to the digitizer.
The sample size for the digitizer was set to 496 samples or 1984 ns. The input raise time was 96 ns, trigger hold-off and peak hold-off were 0 ns. The threshold was 1000 least-significant-bit. The trapezoid settings for the digitizer are 96 ns for the rise time, 96 ns for the flat-top, 500 ns for the pole-zero, 0 ns for the peaking time. Under this trapezoid setting, the theoretical maximum pile-up free trigger rate is 3.47 MHz. In addition, the database output was enabled. In order to maximum the data readout, the number of events per aggregation was 1023 (register 0x1034), the maximum number of aggregation per readout was 511 (register 0xEF1C), and the aggregation organization was 511 (register 0x800C).
Without saving the waveform, a 600 kHz signal was sent to 10 channels. The data transfer rate was 65 MB/s. After converting the data into root file. The trigger rate against all input channels is shown on Figure on the right. The onboard memory of the digitizer are shared by 2i and 2(i+1) channels. The channel 0, 5, and 12 own the entire memory so that they can have 600 kHz, but the other channels, due to memory sharing, the performance was reduced to approximately 500 kHz/channel. With trace saving of 496 samples, the digitizer was able to accept 70 kHz/channel. The data transfer rate was also limited at 65 MB/s.
Timing order of the data
One thing is for sure, the time is sorted in a grouped channel, as the channels are sharing the same buffer. When pulling data from the digitizer, the buffers are grouped in block aggregation, and the block aggregation is not time sorted.
The FSUDAQ pulls the buffer as frequently as possible using reading threads. In principle, the digitizer buffer outputs data in a first-in-first-out fashion. However, since the data is grouped in aggregation, it is possible that the timings between different channels can be very different, i.e. the time stamp of a high trigger rate channel could be way ahead of a low trigger rate channel. It is checked that the time is sorted (or in order) for each channel alone. Therefore, when scanning the aggregation and saving the hit following the file position order, the timing is not sorted in general. i.e. the timestamp could jump around for different channels but the timestamp for each channel is sorted.
FSUDAQ run on Raspberry Pi 5 + v4818 optical-USB adaptor
Since CAEN provides libraries with ARM support, I obtained a raspberry pi 5 with 8 GB RAM, and tried to run the FSUDAQ with A4818 optical-USB adaptor. It works without problems. I put 6 ch with 160 Hz each, no problem on the scope, and the data taking is OK.
The elog cannot be installed by apt, and the qt6-chart-dev is used instead of libqt6chart in Ubuntu 22.04.
FSUDAQ with V5818 PCI gen 3 optical-fiber adaptor
Simply use the CAENVMELib 4.0+ and install the a5818 driver.
Slow write cycle
The CAENVEMLib 4.0+ has a slightly slower write cycle compared with older version. It could take up to 300 usec for a write cycle.
FSUDAQ with DT5730B
The FSUDAQ was tested with DT5730B via USB connection. The CAENUSBdrv library must be installed. DT5730B via optical fiber is also tested and working.
Event Builder
An event builder comes with FSUDAQ.
The EventBuilder will read K (batch size) measurements (or hits), sorted and saved as a vector A, it also read the next K hits, sorted and saved as vector B. By compare the timestamp of the last hit of A and the first hit of B, a smaller set of hit will be sorted. And event building is started on vector A. After vector A exhausted, it will be replaced by vector B, and the next K hits will be read, sorted, and saved as a new vector B. And compare the timestamp of vector A and B started again.
Step | Process |
---|---|
0 | read K hits, sort, and saved as vector A |
1 | read next K hit, sort, and saved as vector B |
2 | compared the last timestamp of A, tA1, and the first timestamp of B, tB0 |
3 | if tA1 < tB0, go to step 5, else step 4 |
4 | tA1 > tB0, take the hit in A where the timestamp is >= tB0, take the hit in B where time timestamp is <= tA1. Sort them, and put them back to vector A. |
5 | event building using vector A |
6 | after vector A exhausted, replace it with vector B. read the next K event, sort, and saved as B. Go back to step 5. |
7 | repeat 2 |
when multiple file is used, the above process is done on each file, and there will be many vector A. Event building will be done among the many vector A.
Usage
[commit 9ea67c4 will automatically determine the batch size]
./EventBuilder [timeWindow] [withTrace][inFile1] [inFile2] .... timeWindow : in ns, -1 = no event building withTrace : 0 for no trace, 1 for trace Output file name is constructed from inFile1
FSU2CAEN
In the git repository, under the Aux folder, there is FSU2CAEN, which can convert fsu file to CoMPASS binary. This allows users to use existing analysis routine.
DPP Firmware
PHA
The Pulse Height Analyzer is basically Trapezoid Filter.
Trapezoid Filter
Please see the following webpages : Trapezoid Filter and Trapezoid Filter Revisit.
Some settings and its meaning
Channel Registers
There are 23 registers to control each (or coupled) channel for PHA firmware. Settings with [G] mean grouped, i.e. the setting are shared within a coupled channel. Settings with [W] means write-only.
Number | Name | Address | Description |
---|---|---|---|
1 | Record Length [G] | 0x1029 | total time of a trace |
2 | PreTrigger | 0x1038 | time before trigger |
3 | Input Dynamic Range | 0x1028 | Vpp to be 0.5V or 2.0V |
4 | Input Rise Time | 0x1058 | time constant for the RC-CR2 |
5 | DC Offset | 0x1098 | See DC offset |
Trigger Settings | |||
9 | RC-CR2 Smoothing Factor | 0x1054 | moving average of the RC-CR2 (2nd derivative) signal |
6 | Trigger Threshold | 0x106c | When the RC-CR2 signal is over the threshold |
7 | Rise Time Validation Window | 0x1070 | If no trigger occurs in the window -> pileup/rej |
8 | Trigger Hold-off Width | 0x1074 | Within this width, trigger disabled |
10 | Shaped Trigger Width | 0x1084 | The width of the square pulse to go to trigger logic |
11 | DPP Algorithm Control 2 [G] | 0x10A0 | see table DPP Algorithm Control 2 |
Trapezoid Settings | |||
12 | Trapezoid Rise Time | 0x105C | |
13 | Trapezoid Flat Top | 0x1060 | |
14 | Peaking Time | 0x1064 | The time from trigger for energy calculation |
15 | Decay Time | 0x1068 | The input signal decay time. This control the pole-zero correction. |
16 | Peak Hold-off | 0x1078 | This related to pile-up detection. |
17 | DPP Algorithm Control | 0x1080 | see table DPP Algorithm Control |
Other Settings | |||
18 | Fine Gain | 0x10C4 | see fine gate |
19 | Events/Agg [G] | 0x1034 | Number of Events in a memory partition / aggregation |
20 | Veto Width | 0x10D4 | |
21 | Data Flush [W] | 0x103C | |
22 | Channel Stop Acquisition | 0x1040 | |
23 | Individual Channel Software Trigger [W] | 0x10C0 |
Bit Range | Name | Description |
---|---|---|
[5:0] | Trapezoid Scaling | see #Trapezoid_Rescaling |
[9:8] | Decimation | Average of the input signal. This applies to energy filter only. |
[11:10] | Decimation Gain | |
[13:12] | Peak Mean | Average window of the trapezoid peak |
[16] | Input Polarity | |
[19:18] | Trigger Mode | Normal / Coincident / Anti-Coincident |
[22:20] | Base Line Moving Average | |
[24] | Disable Self-trigger | |
[26] | Enable Roll-Over Flag | |
[27] | Enable Pile-Up Flag |
Bit Range | Name | Description |
---|---|---|
[2:0] | Local Shaped Trigger Mode | |
[6:4] | Local Trigger Validation Mode | |
[10:8] | Extras 2 Word Option | |
[15:14] | Source of Veto | |
[17:16] | Step for Trigger Count Rate | |
[18] | Active Baseline calculation | calculate baseline even ACQ not running |
[19] | Tag correlated events | |
[23:20] | Set Channel Probe Type | Need TRIG-OUT to be Channel Probe |
[29] | Baseline Restore |
Some Special Settings
Most of the register settings are trivial and east to understand, here is the list of special registers.
Trapezoid Rescaling
The register 0x1n80 (DPP Algorithm Control) bit [5:0] is the Trapezoid rescaling factor (SHF). It is calculated using the formula
trapezoid rise time in the register
input decay time in the register
For example, if the rise time is 4000 ns ( = 250), decay time is 50 us ( = 3125 ), then then SHF = . This is the standard scaling, meaning the internal trapezoid waveform (48 bits) is right-bit-shifted by 19 (i.e. >> 19 ) to a 15-bit value.
fine gain 0x1nC4
fine gain = is a 16-bit value (0 - 65535 = 0xFFFF ) calculated by
the desired physical fine gate, range 0 to
For example, the rise time and decay are the same as above, , so that the maximum desired fine gate
The FSUDAQ always set
DC offset 0x1n98
This is a 16-bit register. The percentage DC offset to register value is
For example, a 40% DC offset, the register value is
Pile-up decision
PSD
to be filled
QDC
to be filled
Contact
Tsz Leung (Ryan) Tang mailto:rtang@fsu.edu