DRS4 Forum
  DRS4 Discussion Forum, Page 12 of 45  Not logged in ELOG logo
New entries since:Thu Jan 1 01:00:00 1970
ID Datedown Author Subject
  683   Wed May 2 10:44:17 2018 Alessio BertiPeak at 0 mV in traces

Hi,

we modified drs_exam.cpp to read all 4 channels from the DRS4 and apply directly the spike removal (taken from Osci.cpp) during the acquisition phase. For test purposes, we don't save the data showing spikes and we focus on the data not having spikes (even if at the end we end up having triple and quadro spikes which are not removed by the spike removal routine, but they are rare). With this modified program we wanted to characterize the noise of the DRS4, so we took 30000 events at 5GSPS, triggering on channel 1 with a 10 MHz sine wave with 100 mV_pp (trigger level set at 10 mV), while channels 2,3 and 4 were left open without any input.

We then took a look at the data and plotted the noise histograms for channels 2,3 and 4, which you can find attached (without offset correction, named zero_peak_after_spike_removal_ch*.png). For completeness, we also attached the plot from ch1 (the sine wave). The selections in time and amplitude we applied had the goal to remove the high oscillations in amplitude occurring in the first and last samples and to discard the quadro spikes we had in the data.

We see that there is a peak at 0 mV in all histograms from all channels and scanning through the data, we saw that indeed the value 0 mV is stored many times for each event, thus originating the peak we see in the histograms. We also applied an offset correction to the data (taking the average of the first three most occuring amplitudes) of channels 2 (as an example) and the problem seems to be only partially removed.

We also noticed that this peak at 0 mV is present also when we acquired the data from the DRS4 with DRSosc saving the data in binary format.

So we had the following questions:

- why is the DRS4 saving so many times the value 0 mV (exactly 0 mV)?

- is there any way (in our case through software, preferably at acquisition time) to solve this problem?

Thank you for the help and best regards,

Alessio & Davide

 

  682   Wed May 2 09:24:53 2018 Stefan RittDRS4 using drs_exam.cpp to save as binary files

You have to write the C/C++ code yourself to write data in binary or any other format. All information is present after the waveform readout in drs_exam.cpp, so it's just a matter of proper write() functions. Please consult any C/C++ handbook on how to write to files.

Hyunseong Kim wrote:

Hi, 

I would like to save the waveform in a .dat binary file using drs_exam.cpp.

I know the distributed software allows us to save as binary files with the save button, but I currently need to save multiple runs using a script.

I've seen that drs_exam.cpp can save the waveform as .txt files.

Is there any .cpp file or function that allows us to save the waveforms in binary format (.dat)?

Thank you for your help. 

 

  681   Tue May 1 02:00:40 2018 Hyunseong KimDRS4 using drs_exam.cpp to save as binary files

Hi, 

I would like to save the waveform in a .dat binary file using drs_exam.cpp.

I know the distributed software allows us to save as binary files with the save button, but I currently need to save multiple runs using a script.

I've seen that drs_exam.cpp can save the waveform as .txt files.

Is there any .cpp file or function that allows us to save the waveforms in binary format (.dat)?

Thank you for your help. 

  680   Tue Apr 17 13:28:23 2018 Stefan RittDRS4 read_binary.cpp

On the software download page at https://www.psi.ch/drs/software-download you find a link to all versions of the DRS software, which is located at: https://www.dropbox.com/sh/clqo7ekr0ysbrip/AACoWJzrQAbf3WiBJHG89bGGa?dl=0

Earch .tar.gz file has a date, which should help you find the correct version.

Sobimpe Eniola wrote:

Hello everyone, 

The new read_binary.cpp code 

I will be very glad if anyone can help with the old version of read_binary.cpp code. The latest version I saw online was updated on June 30th, 2014, but I need the old version of the code to compare what changes were made in the latest version. This will help me to modify it and be able to read my data successfully. Thanks

 

  679   Mon Apr 16 21:21:29 2018 Sobimpe EniolaDRS4 read_binary.cpp

Hello everyone, 

The new read_binary.cpp code 

I will be very glad if anyone can help with the old version of read_binary.cpp code. The latest version I saw online was updated on June 30th, 2014, but I need the old version of the code to compare what changes were made in the latest version. This will help me to modify it and be able to read my data successfully. Thanks

  678   Fri Apr 13 18:14:07 2018 Alessio BertiVoltage and Timing Calibration in drs_exam.cpp

Hi,

we were trying to implement an automatic way to calibrate our DRS4 both in voltage and in time (we have the V5 Evaluation Board). We started from drs_exam.cpp and tried with the following lines:

/* set input range to -0.5V ... +0.5V */

b->SetInputRange(0);

b->CalibrateVolt(NULL);
b->CalibrateTiming(NULL);

While the timing calibration seems to work (we checked with drsosc executable), the voltage calibration in our test program seems not to do the same as in drsosc when pressing the button "Execute Voltage Calibration". Specifically we think that no primary calibration, secondary calibration or spike removal is applied when calling CalibrateVolt(). It seems that the methods to perform those tasks are implemented in Osci.ccp/Osci.h, but drs_exam.cpp uses objects of the class DRS (i.e. defined in DRS.cpp and DRS.h).

Is there a way to execute the voltage calibration in drs_exam.cpp in the same way performed within drsosc?

Cheers,

Alessio

  677   Fri Mar 23 09:39:55 2018 Stefan RittRead the CalibrateWaveform

You don't have to read and calibrate the waveforms in your user code, but can rely on the DRS.cpp library to do that. Just look at the drs_exam.cpp program coming with the distribution. It uses the function b->GetWave() to retrieve the calibrated waveform. If you like, you can look into that function to learn how to apply the calibration, but I can tell you that it's a bit complicated. Since each event starts at an arbitrary stop cell in the DRS4, you have to "rotate" the calibration array. Then you do actually four calibrations in a row (cell, readout, gain and range).

Stefan

Phan Van Chuan wrote:

Helo
I'm building an application for reading waveforms from the DRS4 board to PC. However, I am having problems reading calibration data from EEPROM on DRS4 board. The calibration data is read through the function reference:
void DRSBoard :: ReadCalibration (void)
...
      ReadEEPROM (1, buf, 1024 * 32);
      for (i = 0; i <8; i ++)
         for (j = 0; j <1024; j ++) {
            fCellOffset [i] [j] = buf [(i * 1024 + j) * 2];
            fCellGain [i] [j] = buf [(i * 1024 + j) * 2 + 1] / 65535.0*0.4+0.7;
         }
      
      ReadEEPROM (2, buf, 1024 * 32);
      for (i = 0; i <8; i ++)
         for (j = 0; j <1024; j ++)
            fCellOffset2 [i] [j] = buf [(i * 1024 + j) * 2];
...
The Calibrate Waveform is performed by:
int DRSBoard::CalibrateWaveform(unsigned int chipIndex, unsigned char channel, unsigned short *adcWaveform, short *waveform, bool responseCalib, int triggerCell, bool adjustToClock, float threshold, bool offsetCalib)
.....
         for (j = 0; j < n_bins; j++) {
            value = adcWaveform[j] - fCellOffset[channel+chipIndex*9][(j*skip + triggerCell) % kNumberOfBins];
            value = value / fCellGain[channel+chipIndex*9][(j*skip + triggerCell) % kNumberOfBins];
            if (offsetCalib && channel != 8)
               value = value - fCellOffset2[channel+chipIndex*9][j*skip] + 32768;
...
. Because the calibration data reads incorrectly, the Calibrate Waveform does not do it.
Can read calibration data from EEPROM by any command via Oscilloscope application or DRS Command Line Interface application?
Thank you for your help!!!!

 

  676   Thu Mar 22 14:36:01 2018 Phan Van ChuanRead the CalibrateWaveform

Helo
I'm building an application for reading waveforms from the DRS4 board to PC. However, I am having problems reading calibration data from EEPROM on DRS4 board. The calibration data is read through the function reference:
void DRSBoard :: ReadCalibration (void)
...
      ReadEEPROM (1, buf, 1024 * 32);
      for (i = 0; i <8; i ++)
         for (j = 0; j <1024; j ++) {
            fCellOffset [i] [j] = buf [(i * 1024 + j) * 2];
            fCellGain [i] [j] = buf [(i * 1024 + j) * 2 + 1] / 65535.0*0.4+0.7;
         }
      
      ReadEEPROM (2, buf, 1024 * 32);
      for (i = 0; i <8; i ++)
         for (j = 0; j <1024; j ++)
            fCellOffset2 [i] [j] = buf [(i * 1024 + j) * 2];
...
The Calibrate Waveform is performed by:
int DRSBoard::CalibrateWaveform(unsigned int chipIndex, unsigned char channel, unsigned short *adcWaveform, short *waveform, bool responseCalib, int triggerCell, bool adjustToClock, float threshold, bool offsetCalib)
.....
         for (j = 0; j < n_bins; j++) {
            value = adcWaveform[j] - fCellOffset[channel+chipIndex*9][(j*skip + triggerCell) % kNumberOfBins];
            value = value / fCellGain[channel+chipIndex*9][(j*skip + triggerCell) % kNumberOfBins];
            if (offsetCalib && channel != 8)
               value = value - fCellOffset2[channel+chipIndex*9][j*skip] + 32768;
...
. Because the calibration data reads incorrectly, the Calibrate Waveform does not do it.
Can read calibration data from EEPROM by any command via Oscilloscope application or DRS Command Line Interface application?
Thank you for your help!!!!

  675   Mon Mar 19 16:22:42 2018 Stefan RittROI

The DRS4 has an internal storage of 1024 capacitors. They work as a ring buffer, so at 5GSPS you can store 200ns wide signals. After 200ns, the first samples are overwritten by new samples, so you always have the last 200ns of samples stored. Once you trigger the DRS4, this buffer is frozen, and the readout of this buffer causes the dead time. No trigger, no dead time. Hope this answers your question.

Stefan

Steven Block wrote:

Great! That is very helpful. 

One more question. If no signals were detected in the 1024*200ps time frame in ROI mode, would the DRS4 go dead for 32us (or 30us depending on the supply)  for, or would it dump the earliest events in the buffer for the more recent ones until it detects a signal to readout? Or rather, does filling the buffer force a readout or can it dynamically shift out old data until it detects a signal to readout. 

Steven

Stefan Ritt wrote:

N'/N is correct. The 2 us "from the response you got from me" come from the fact that after readout, you have to start the DRS4 again. During this time, the power supply usually becomes slightly unstable, and it takes on the evaluation board about 2us to stabilize it again. Tha't why I add the 2 us. If you don't care about slight offset effect, or if you make a better power supply, you dead time would be 10*30ns = 300ns for 10 samples. Starting the DRS again will take one or two clock cycles from the FPGA, which might add another 30 ns or so, depending on how you program the FPGA. So the best you can achieve for 10 samples is maybe 330 ns, if you have a really good power supply (large capacitors).

You can achieve this functionality with the evaluation board, but you would have to make a special firmware for it.

Stefan

Steven Block wrote:

Hello,

I have a question about how ROI works. From what I have read, it will only save data that ocurs some time [ta] dictated by the user after an event is triggered as well as a small time [tb] before the event. The technical manual seems to indicated that the deadtime assciated with operating in ROI mode can be reduced by the following factor: 

\frac{t_a + t_b }{\frac{N}{Sample Speed}} .

Where N is the number of points in the time window (ex. 2048 or 1024). Is it ok to describe this as:

\frac{N'}{N}

Where N' is the number of samples in the ROI and N is the same as before.

For example, if I were running at 5Gsps (200ps between samples), only recording 1024 samples per event and I had an signal that lasted 2ns, that means the signal would last 10 samples. If I set the ROI to only save 20 samples around this signal, would my Deadtime go to:

\frac{10}{1024} * 30ns*1024 + 2\mu s = 2.3\mu s? (The second portion of this equation comes from a response I recieved earlier, but I just want to make sure I understand this concept properly)

I recognize that the caveat is that this would work only if the signal was detected during acquistion, which leads to my next question. If no signals were detected in the 1024*200ps time frame in ROI mode, would the DRS4 go dead for 32us (using the factor = 1 from above equation), or would it dump the earliest events in the buffer for the more recent ones until it detects a signal? 

Finally, I assume this functionality can only be utilized with custom electornics with the DRS4, not the evaulation/demo board, please let me know if this is the case. 

Best,

Steven

 

 

 

  674   Mon Mar 19 15:12:02 2018 Stefan RittRunning drs_example.cpp

The time channel is already calibrated in ns. So for 5 GSPS, the time scale goes from zero to 200. Concerning your other issues I will come back to you later.

Stefan

Rodrigo Trindade de Menezes wrote:

Another issue that we are having is with the data set stored on the .txt file looks incorrect.  The time channel stops at 200 (but we think it should go up to 1024). In addition, the voltage channel appears to hover around small values near zero (as if triggering on noise).  The output file appears this way even when we change the threshold to much higher values.  It suggests that the trigger threshold is not actually being set? There are events where the output voltage appears to oscillate through huge negative and positive values too.  So not sure what's going on. 

  673   Fri Mar 16 14:00:06 2018 Stefan Rittconfusion about the description in drs.cpp

The FPGA is very small, so it only has an address space of 256 bytes. Look at the definition in DRS.cpp

#define USB_CTRL_OFFSET                 0x00    /* all registers 32 bit */
#define USB_STATUS_OFFSET               0x40
#define USB_RAM_OFFSET                  0x80

The registers are 32 bits wide, but the addresses only run from 0 to 255, and thus a single byte is enough for addressing them.

chen wenjun wrote:

Hi,Stefan:

  recently,whtn I study the drs.cpp code ,I found that  the buffer[1] is char but the addr and the base_addr are all unsigned int,isn't there any problem that the addr may be cut off to 8 bits? Also ,I found that the data fpga recieved from the usb is 16 bits,so how can fpga get the true 32bits address from the PC.

 

  672   Thu Mar 15 08:44:26 2018 Stefan Rittsub-ms precision timestamps?

Putting sub-ms precision into the header does not make sense, since the USB transfer only happens in time-slots of about 2 ms. To get better timing, you would need a hardware time clock in the FPGA, which does not exist right now.

Best,
Stefan

Will Flanagan wrote:

Dear DRS4 community,

Is there a way to extract timestamps with sub-ms precision? The milliseconds of an event is clearly given when unpacking the header. I would like to determine how far apart events are when they are within the same millisecond.

Thanks,

Will

 

  671   Wed Mar 14 09:13:39 2018 chen wenjunconfusion about the description in drs.cpp

Hi,Stefan:

  recently,whtn I study the drs.cpp code ,I found that  the buffer[1] is char but the addr and the base_addr are all unsigned int,isn't there any problem that the addr may be cut off to 8 bits? Also ,I found that the data fpga recieved from the usb is 16 bits,so how can fpga get the true 32bits address from the PC.

  668   Wed Mar 14 00:38:15 2018 Will Flanagansub-ms precision timestamps?

Dear DRS4 community,

Is there a way to extract timestamps with sub-ms precision? The milliseconds of an event is clearly given when unpacking the header. I would like to determine how far apart events are when they are within the same millisecond.

Thanks,

Will

  667   Thu Mar 8 22:54:20 2018 Rodrigo Trindade de MenezesRunning drs_example.cpp

We found a way to solve the previous problem, but right now when we try to set the input range only -0.5 to 0.5 is working. When we set the function "SetInputRange(0.5)" for 0 to 1V the output is all zeros and with  "SetInputRange(0.45)" we just get all the outputs -49.9mV. What does that means? How to fix?

odrigo Trindade de Menezes wrote:

Hello,

We have been using the DRS4 evaluation board (S/N 2636) that works with the scope application. However we are trying to run the DRS4 evaluation board remotely by modifying the drs_exam.cpp to acquire and store data continuously.

We compiled the DRS_example.cpp without the wxWidgets but when we try to run the program, it appears to trigger on nonsense.  The program appears to not be sensitive to the trigger threshold (although for very large trigger threshold it gets stuck in a waiting mode).  Is there a way to ensure that the "normal" trigger mode is set?  We are worried that the auto mode is running.  Otherwise, not sure why the program is triggering on nonsense.  By the way, it does not work with the wxWidgets compiled either so we are worried that there is an additional flag that needs to be set. The routine does not appear to conduct a calibration -- is this not necessary?

Another issue that we are having is with the data set stored on the .txt file looks incorrect.  The time channel stops at 200 (but we think it should go up to 1024). In addition, the voltage channel appears to hover around small values near zero (as if triggering on noise).  The output file appears this way even when we change the threshold to much higher values.  It suggests that the trigger threshold is not actually being set? There are events where the output voltage appears to oscillate through huge negative and positive values too.  So not sure what's going on. 

Thanks!

Rodrigo

 

  666   Wed Mar 7 22:49:38 2018 Rodrigo Trindade de MenezesRunning drs_example.cpp

Hello,

We have been using the DRS4 evaluation board (S/N 2636) that works with the scope application. However we are trying to run the DRS4 evaluation board remotely by modifying the drs_exam.cpp to acquire and store data continuously.

We compiled the DRS_example.cpp without the wxWidgets but when we try to run the program, it appears to trigger on nonsense.  The program appears to not be sensitive to the trigger threshold (although for very large trigger threshold it gets stuck in a waiting mode).  Is there a way to ensure that the "normal" trigger mode is set?  We are worried that the auto mode is running.  Otherwise, not sure why the program is triggering on nonsense.  By the way, it does not work with the wxWidgets compiled either so we are worried that there is an additional flag that needs to be set. The routine does not appear to conduct a calibration -- is this not necessary?

Another issue that we are having is with the data set stored on the .txt file looks incorrect.  The time channel stops at 200 (but we think it should go up to 1024). In addition, the voltage channel appears to hover around small values near zero (as if triggering on noise).  The output file appears this way even when we change the threshold to much higher values.  It suggests that the trigger threshold is not actually being set? There are events where the output voltage appears to oscillate through huge negative and positive values too.  So not sure what's going on. 

Thanks!

Rodrigo

  665   Fri Mar 2 21:05:48 2018 Steven BlockROI

Great! That is very helpful. 

One more question. If no signals were detected in the 1024*200ps time frame in ROI mode, would the DRS4 go dead for 32us (or 30us depending on the supply)  for, or would it dump the earliest events in the buffer for the more recent ones until it detects a signal to readout? Or rather, does filling the buffer force a readout or can it dynamically shift out old data until it detects a signal to readout. 

Steven

Stefan Ritt wrote:

N'/N is correct. The 2 us "from the response you got from me" come from the fact that after readout, you have to start the DRS4 again. During this time, the power supply usually becomes slightly unstable, and it takes on the evaluation board about 2us to stabilize it again. Tha't why I add the 2 us. If you don't care about slight offset effect, or if you make a better power supply, you dead time would be 10*30ns = 300ns for 10 samples. Starting the DRS again will take one or two clock cycles from the FPGA, which might add another 30 ns or so, depending on how you program the FPGA. So the best you can achieve for 10 samples is maybe 330 ns, if you have a really good power supply (large capacitors).

You can achieve this functionality with the evaluation board, but you would have to make a special firmware for it.

Stefan

Steven Block wrote:

Hello,

I have a question about how ROI works. From what I have read, it will only save data that ocurs some time [ta] dictated by the user after an event is triggered as well as a small time [tb] before the event. The technical manual seems to indicated that the deadtime assciated with operating in ROI mode can be reduced by the following factor: 

\frac{t_a + t_b }{\frac{N}{Sample Speed}} .

Where N is the number of points in the time window (ex. 2048 or 1024). Is it ok to describe this as:

\frac{N'}{N}

Where N' is the number of samples in the ROI and N is the same as before.

For example, if I were running at 5Gsps (200ps between samples), only recording 1024 samples per event and I had an signal that lasted 2ns, that means the signal would last 10 samples. If I set the ROI to only save 20 samples around this signal, would my Deadtime go to:

\frac{10}{1024} * 30ns*1024 + 2\mu s = 2.3\mu s? (The second portion of this equation comes from a response I recieved earlier, but I just want to make sure I understand this concept properly)

I recognize that the caveat is that this would work only if the signal was detected during acquistion, which leads to my next question. If no signals were detected in the 1024*200ps time frame in ROI mode, would the DRS4 go dead for 32us (using the factor = 1 from above equation), or would it dump the earliest events in the buffer for the more recent ones until it detects a signal? 

Finally, I assume this functionality can only be utilized with custom electornics with the DRS4, not the evaulation/demo board, please let me know if this is the case. 

Best,

Steven

 

 

  664   Fri Mar 2 20:17:17 2018 Stefan RittROI

N'/N is correct. The 2 us "from the response you got from me" come from the fact that after readout, you have to start the DRS4 again. During this time, the power supply usually becomes slightly unstable, and it takes on the evaluation board about 2us to stabilize it again. Tha't why I add the 2 us. If you don't care about slight offset effect, or if you make a better power supply, you dead time would be 10*30ns = 300ns for 10 samples. Starting the DRS again will take one or two clock cycles from the FPGA, which might add another 30 ns or so, depending on how you program the FPGA. So the best you can achieve for 10 samples is maybe 330 ns, if you have a really good power supply (large capacitors).

You can achieve this functionality with the evaluation board, but you would have to make a special firmware for it.

Stefan

Steven Block wrote:

Hello,

I have a question about how ROI works. From what I have read, it will only save data that ocurs some time [ta] dictated by the user after an event is triggered as well as a small time [tb] before the event. The technical manual seems to indicated that the deadtime assciated with operating in ROI mode can be reduced by the following factor: 

\frac{t_a + t_b }{\frac{N}{Sample Speed}} .

Where N is the number of points in the time window (ex. 2048 or 1024). Is it ok to describe this as:

\frac{N'}{N}

Where N' is the number of samples in the ROI and N is the same as before.

For example, if I were running at 5Gsps (200ps between samples), only recording 1024 samples per event and I had an signal that lasted 2ns, that means the signal would last 10 samples. If I set the ROI to only save 20 samples around this signal, would my Deadtime go to:

\frac{10}{1024} * 30ns*1024 + 2\mu s = 2.3\mu s? (The second portion of this equation comes from a response I recieved earlier, but I just want to make sure I understand this concept properly)

I recognize that the caveat is that this would work only if the signal was detected during acquistion, which leads to my next question. If no signals were detected in the 1024*200ps time frame in ROI mode, would the DRS4 go dead for 32us (using the factor = 1 from above equation), or would it dump the earliest events in the buffer for the more recent ones until it detects a signal? 

Finally, I assume this functionality can only be utilized with custom electornics with the DRS4, not the evaulation/demo board, please let me know if this is the case. 

Best,

Steven

 

  663   Fri Mar 2 18:08:55 2018 Steven BlockROI

Hello,

I have a question about how ROI works. From what I have read, it will only save data that ocurs some time [ta] dictated by the user after an event is triggered as well as a small time [tb] before the event. The technical manual seems to indicated that the deadtime assciated with operating in ROI mode can be reduced by the following factor: 

\frac{t_a + t_b }{\frac{N}{Sample Speed}} .

Where N is the number of points in the time window (ex. 2048 or 1024). Is it ok to describe this as:

\frac{N'}{N} 

Where N' is the number of samples in the ROI and N is the same as before.

For example, if I were running at 5Gsps (200ps between samples), only recording 1024 samples per event and I had an signal that lasted 2ns, that means the signal would last 10 samples. If I set the ROI to only save 20 samples around this signal, would my Deadtime go to:

\frac{10}{1024} * 30ns*1024 + 2\mu s = 2.3\mu s? (The second portion of this equation comes from a response I recieved earlier, but I just want to make sure I understand this concept properly)

I recognize that the caveat is that this would work only if the signal was detected during acquistion, which leads to my next question. If no signals were detected in the 1024*200ps time frame in ROI mode, would the DRS4 go dead for 32us (using the factor = 1 from above equation), or would it dump the earliest events in the buffer for the more recent ones until it detects a signal? 

Finally, I assume this functionality can only be utilized with custom electornics with the DRS4, not the evaulation/demo board, please let me know if this is the case. 

Best,

Steven

  662   Tue Feb 27 18:12:32 2018 Stefan RittDRS4 Dead times

For applications which are critical on the dead time, one typically uses one ADC per DRS4 channel, and thus the dead time stays at 32us. If you multiplex two DRS4 channels into one ADC channel, then it goes to 32us.

Stefan

Steven Block wrote:

That is extremely helpful! Many thanks. One more question; If I were to take inputs from 2 channels at once, would that scale the dead time to 64us using your example? 

Steven

Stefan Ritt wrote:

XML is very slow to write, and you are probably limited by that. Switch to binary mode, which is much faster. You will see in the end a maximum rate of ~500 Hz, and thus a dead time of 2ms, independent of the sampling speed. Note that you have only an evaluation board, which is optimized for ease of use. If you develop your own electronics, and do optimized readout, you can bring the deadtime down to 30ns x number of samples + 2us, or 32us if you read 1024 values from one channel.

Stefan

Steven Block wrote:

Hello All,

I am currently trying to figure out how to properly characterize the dead time of the DRS4 board. My most recent experiment to try and answer this question involved using an external trigger that can range from 1Hz to 2MHz. I fed this trigger into the DRS4 and collected 1000 samples with no input to any channels. I repeated this across the range of my external trigger by a factor of ten [10Hz, 100Hz, 1kHz...etc]. After I had saved these runs in XML format, I looked at the difference between timestamps on the events. Attached are my findings. Can someone offer an explanation for the periodic peaks? I am new to the DRS4 and don't really understand how it works. My guess is that there is a buffer that has to be emptied every so often, but if so, the buffer emptying time varies with the frequency of the trigger. I would ideally like to be able to know the relation of the dead time to a particular setting I change on the DRS4 such as locking the sampling speed or changing external trigger frequency. 

Best,

Steven

 

 

 

ELOG V3.1.5-fe60aaf