ELOG DRS4 Forum

Dear DRS4 team,

I'm trying to troubleshoot some odd spike behavior. If I run the ADC and SR CLK at 16 MHz (behavior also seen at 33 MHz) we get very noisy data (post-calibration) with periodic spikes.

In the below plot

CH0 & CH1 are muon pulses from a scintillator + SiPM detector
CH8 is a 25 MHz sinewave (in phase with all generated board clocks)
Transparent mode = ON
ROI = OFF, "full readout mode", first sample = cell 0
DRS REFCLK = 1 MHz (2 GS/s)
ADC & SR CLK = 16 MHz, 0 deg. offset

After I modify some clock settings, things seem to improve dramatically, and the spike behavior changes

ADC and SR CLK = 15 MHz, 0 deg. offset
Transparent mode = ON
ROI = ON (just for testing purposes)
Add 1.064 ns skew to DRS REF CLK
NOTE: Unfortunately due to a design mishap, the ADC and FPGA clock use a phase-locked output pair on our clock synthesis chip, so we cannot fine-tune the skew for it.

Observed differences

Spike polarity seems inverted
Spikes limited to smaller number of cells now?
Spike amplitude reduced
Overall baseline variance seems better
New large positive spike artifact on CH0 that seems inverted on CH1
CH8 seems unaffected by large spikes?

Artifacts seem related to clock configuration, but I am sort of in the dark on what might be happening from a first-principles point of view. Any tips?

Warm regards,

Sean

825

Fri Apr 9 21:38:59 2021

elog:824

Sean Quinn wrote:

Dear DRS4 team,

I'm trying to troubleshoot some odd spike behavior. If I run the ADC and SR CLK at 16 MHz (behavior also seen at 33 MHz) we get very noisy data (post-calibration) with periodic spikes.

In the below plot

CH0 & CH1 are muon pulses from a scintillator + SiPM detector
CH8 is a 25 MHz sinewave (in phase with all generated board clocks)
Transparent mode = ON
ROI = OFF, "full readout mode", first sample = cell 0
DRS REFCLK = 1 MHz (2 GS/s)
ADC & SR CLK = 16 MHz, 0 deg. offset

After I modify some clock settings, things seem to improve dramatically, and the spike behavior changes

ADC and SR CLK = 15 MHz, 0 deg. offset
Transparent mode = ON
ROI = ON (just for testing purposes)
Add 1.064 ns skew to DRS REF CLK
NOTE: Unfortunately due to a design mishap, the ADC and FPGA clock use a phase-locked output pair on our clock synthesis chip, so we cannot fine-tune the skew for it.

Observed differences

Spike polarity seems inverted
Spikes limited to smaller number of cells now?
Spike amplitude reduced
Overall baseline variance seems better
New large positive spike artifact on CH0 that seems inverted on CH1
CH8 seems unaffected by large spikes?

Artifacts seem related to clock configuration, but I am sort of in the dark on what might be happening from a first-principles point of view. Any tips?

Warm regards,

Sean

885

Fri Jun 24 09:57:36 2022

LynseyShun

Hello, I now have periodic spikes in CH0 and CH1 output. How can I eliminate these spikes? I'm sorry I didn't understand your elimination method. Please explain the method in detail. Thank you very much

Stefan Ritt wrote:

elog:824

Sean Quinn wrote:

Dear DRS4 team,

I'm trying to troubleshoot some odd spike behavior. If I run the ADC and SR CLK at 16 MHz (behavior also seen at 33 MHz) we get very noisy data (post-calibration) with periodic spikes.

In the below plot

CH0 & CH1 are muon pulses from a scintillator + SiPM detector
CH8 is a 25 MHz sinewave (in phase with all generated board clocks)
Transparent mode = ON
ROI = OFF, "full readout mode", first sample = cell 0
DRS REFCLK = 1 MHz (2 GS/s)
ADC & SR CLK = 16 MHz, 0 deg. offset

After I modify some clock settings, things seem to improve dramatically, and the spike behavior changes

ADC and SR CLK = 15 MHz, 0 deg. offset
Transparent mode = ON
ROI = ON (just for testing purposes)
Add 1.064 ns skew to DRS REF CLK
NOTE: Unfortunately due to a design mishap, the ADC and FPGA clock use a phase-locked output pair on our clock synthesis chip, so we cannot fine-tune the skew for it.

Observed differences

Spike polarity seems inverted
Spikes limited to smaller number of cells now?
Spike amplitude reduced
Overall baseline variance seems better
New large positive spike artifact on CH0 that seems inverted on CH1
CH8 seems unaffected by large spikes?

Artifacts seem related to clock configuration, but I am sort of in the dark on what might be happening from a first-principles point of view. Any tips?

Warm regards,

Sean

888

Fri Jul 29 17:23:43 2022

Spikes in DRS4 data on custom baord.

Look at the DRS4 data sheet, Figure 12. You see there the rising SRCLK pulse which outputs the next analog value. You also see tSAMP which describes the sampling piont (strobe or clock sent to your ADC). The value of tSAMP must be such that the values is sampled at the point where it flattens out, just 2-3 ns BEFORE the next analog sample is clocked out, as written in the text. So you have to phase shift your clock going to SRCLK and the one going to your ADC against each other. This needs adjustment at the ns level, so you need a PLL with fine-valued taps, so you can shift it in fractions of a ns. What you see is that you sample at the BEGINNING of a new value to be output to the chip. Please also note that most ADCs have an internal delay of their clock (usually called 'aperture') which has to be taken into account. So if your SRCLK and your ADC clock come at the same time (not phase shifted), it might happen that the ADC internal aperture delay caues it to sample the analog signal at the BEGINNING of the new value.

Hope this is clearer now.

Best regards,
Stefan

348

Tue May 27 13:46:18 2014

Dominik Neise

We see quite some spikes in our DRS4 sampled data in FACT. We see different types of spikes:

single cell spikes, usually showing a large amplitude of 200mV
double cell spikes, usually only in the order of 20mV.
Even triple and quadro cell spikes are rarely seen.

The double cell spikes often occur as symmetrical double cell spikes mirrored at cell 512. quadro cell spikes seem to be nothing else, than connected symmetrical double cell spikes. For the triple cell spikes we have no idea.
Currently we use simple filters to get rid of these spikes, this workes rather well for the large single cell spikes, but with the occurance of tripples and quadros we started to worry about higher multiples and revived our DRS4 spike investigations.

Now I was told, that you Stefan know already where these spikes come from and even a paper exisits. Unfortunately so far I was unable to find it.
I wonder if it is possible to predict the occurance of these spikes, so one does not have to search for them anymore and can get rid of the filters.

Best regards

Dominik

349

Tue May 27 16:07:17 2014

Spikes in DRS4 data on custom baord.

Dominik Neise wrote:

We see quite some spikes in our DRS4 sampled data in FACT. We see different types of spikes:

single cell spikes, usually showing a large amplitude of 200mV
double cell spikes, usually only in the order of 20mV.
Even triple and quadro cell spikes are rarely seen.

Best regards

Dominik

All I know is that the "20mV" spikes are always symmetrical around cell #512, that they are typically 17.4 mV in height, and that they occur always in all 9 channels simultaneously. They cannot occur in all locations, but there only like 32 possible locations where they can occur. With this information it should be easy to fix them by filtering.

200 mV spikes are new to me. I do not see them in our boards, so it must be related to the board readout and not to the chip.

Best regards,
Stefan

289

Wed Aug 28 13:07:51 2013

Andrey Kuznetsov

For http://www.psi.ch/drs/DocumentationEN/manual_rev20.pdf:

0 0x02 15..8 board_type 5 for DRS4 USB Evaluation Board 1.1 ---> should instead say Evaluation Board 2.0 ?

I've been reviewing DRS.cpp v4.0.1

1) if(i==100) should be if(i==1000) in function int DRSBoard::SetFrequency(double demand, bool wait)

Otherwise if PLL did not lock, i = 1000, and the if statement is evaluating it against 100, not 1000 so it never gets triggered and the error goes unnoticed.

      if (wait) {

         StartDomino();

         for (i=0 ; i<1000 ; i++)

         if (GetStatusReg() & BIT_PLL_LOCKED0)

            break;

         SoftTrigger();

         if (i==100) {

            printf("PLL did not lock for frequency %lf\n", demand);

            return 0;

2) int DRSBoard::RegulateFrequency(double demand) does not seem to work at all, the frequency does not lock for either 2 or 5 GHz, tested using DRS4 v2.0 eval board with DRS v4.0.1 and v2.0.1 software's drscl tool.

3) In int DRSBoard::SetTriggerDelayPercent(int delay) and int DRSBoard::SetTriggerDelayNs(int delay), what is the purpose of Read and setting of "reg" if it's not being used or exported anywhere else outside of that function? Seems like Read and reg are called for nothing.

      Read(T_CTRL, &reg, REG_TRG_DELAY, 2);

      reg = (reg & 0xFF00) | ticks;

      Write(T_CTRL, REG_TRG_DELAY, &ticks, 2);

Also, I don't understand why in int DRSBoard::SetSyncDelay(int ticks), the code changes to       Read(T_CTRL, &reg, REG_TRG_DELAY, 2);
      reg = (reg & 0xFF) | (ticks << 8);
      Write(T_CTRL, REG_TRG_DELAY, &reg, 2);
In particular, reg = (reg & 0xFF00) | ticks; and reg = (reg & 0xFF) | (ticks << 8);  I'm not really sure but doesn't Read() with size 2 return a value that has a maximum value of 0xFF, or 8bits? But ticks << 8, since ticks == 255 max, makes 255 << 8 => 65280, which is now a 16bit value and size 4. No? I might be wrong here, and if I am then I don't understand what's going on. Can you please explain? In v2.0.1 the ticks were a maximum of 511 or 9bits, why did it change to 8bits?

4) A function is being called incorrectly in GetWave() in DRS.cpp

int DRSBoard::GetWave(unsigned int chipIndex, unsigned char channel, float *waveform)
{
   return GetWave(chipIndex, channel, waveform, true, fStopCell[chipIndex], false, 0, true);
}

The return is calling the following overloaded function:
int DRSBoard::GetWave(unsigned int chipIndex, unsigned char channel, float *waveform, bool responseCalib, int triggerCell, int wsr, bool adjustToClock, float threshold, bool offsetCalib)
the problem is that int wsr is not passed to the function and it thus causes implicit conversions where false is being cast into int, 0 into bool, and true into float.

I'll post more if I have any questions or spot any more bugs.

290

Thu Sep 5 10:01:00 2013

Andrey Kuznetsov

#11 0x080589de in DRSBoard::GetWave (this=0xb7456008, chipIndex=0, channel=0 '\000', waveform=0x40f24000, responseCalib=true, triggerCell=207, wsr=0, adjustToClock=false, threshold=1, offsetCalib=true) at src/DRS.cpp:3380

This is calling:

int GetWave(unsigned int chipIndex, unsigned char channel, float *waveform, bool responseCalib, int triggerCell = -1, int wsr = -1, bool adjustToClock = false, float threshold = 0, bool offsetCalib = true);

from DRS.cpp:
return GetWave(chipIndex, channel, waveform, true, fStopCell[chipIndex], false, 0, true);

false=0
true=1

As you can see offsetCalib ends up being defined by default, threshold set to 1 because of true, adjustToClock is false set by 0, wsr is 0 set by false, however threshold is never used with DRS4 eval board. So although it doesn't affect data retrieval, it's just dumb luck the function ends up being called with parameters that matter being exactly what they were meant to be.

291

Mon Sep 9 06:49:36 2013

Andrey Kuznetsov

The DRSCallback *pcb is missing an if statement in the code when DRS Oscilloscope software isn't used when calibrating in function: int DRSBoard::CalibrateTiming(DRSCallback *pcb)

I had to add if (pcb != NULL) before each pcb call, like other functions are using so that the program doesn't segfault when the function is called like b->CalibrateTiming(NULL);

That's the only function that's missing this if statement for DRSCallback *pcb call, and there are 2 calls in this function to pcb that need fixing.

325

Wed Jan 15 16:15:00 2014

For http://www.psi.ch/drs/DocumentationEN/manual_rev20.pdf:

Andrey Kuznetsov wrote:

0 0x02 15..8 board_type 5 for DRS4 USB Evaluation Board 1.1 ---> should instead say Evaluation Board 2.0 ?

Type 5 is both for board V1.1 and V2. I consider V1.1 obsolete (nobody uses it). I added code 8 for V4 and 9 for V5

Andrey Kuznetsov wrote:

1) if(i==100) should be if(i==1000) in function int DRSBoard::SetFrequency(double demand, bool wait)

Otherwise if PLL did not lock, i = 1000, and the if statement is evaluating it against 100, not 1000 so it never gets triggered and the error goes unnoticed.

      if (wait) {

         StartDomino();

         for (i=0 ; i<1000 ; i++)

         if (GetStatusReg() & BIT_PLL_LOCKED0)

            break;

         SoftTrigger();

         if (i==100) {

            printf("PLL did not lock for frequency %lf\n", demand);

            return 0;

Absolutely correct, I changed it in the current software.

Andrey Kuznetsov wrote:

This function is for the old DRS2 chip back in 2003 or so. That chip did not have an on-chip PLL for frequency regulation, so this was done in the FPGA. Just don't us it (who told you to???).

Andrey Kuznetsov wrote:

      Read(T_CTRL, &reg, REG_TRG_DELAY, 2);

      reg = (reg & 0xFF00) | ticks;

      Write(T_CTRL, REG_TRG_DELAY, &ticks, 2);

Also, I don't understand why in int DRSBoard::SetSyncDelay(int ticks), the code changes to       Read(T_CTRL, &reg, REG_TRG_DELAY, 2);
                  reg = (reg & 0xFF) | (ticks << 8);
                  Write(T_CTRL, REG_TRG_DELAY, &reg, 2);

In particular, reg = (reg & 0xFF00) | ticks; and reg = (reg & 0xFF) | (ticks << 8);  I'm not really sure but doesn't Read() with size 2 return a value that has a maximum value of 0xFF, or 8bits?   But ticks << 8, since ticks == 255 max, makes 255 << 8 => 65280, which is now a 16bit value and size 4. No? I might be wrong here, and if I am then I don't understand what's going on.   Can you please explain? In v2.0.1 the ticks were a maximum of 511 or 9bits, why did it change to 8bits?

The register REG_TRG_DELAY contains two 8-bit values, one for the trigger delay, one for the sync delay (which is currently not used). So to set one half of the register containing 16 bits, the register is read (16 bits are read with size 2, since these are two bytes), and the upper or lower 8 bits are replaced with the new value. Then the 16 bits are written back. The firmware in the FPGA does not allow to access only 8 bits of a 16-bit register.

Andrey Kuznetsov wrote:

4) A function is being called incorrectly in GetWave() in DRS.cpp

int DRSBoard::GetWave(unsigned int chipIndex, unsigned char channel, float *waveform)
            {
               return GetWave(chipIndex, channel, waveform, true, fStopCell[chipIndex], false, 0, true);
            }

The return is calling the following overloaded function:
int DRSBoard::GetWave(unsigned int chipIndex, unsigned char channel, float *waveform, bool responseCalib, int triggerCell, int wsr, bool adjustToClock, float threshold, bool offsetCalib)
            the problem is that int wsr is not passed to the function and it thus causes implicit conversions where false is being cast into int, 0 into bool, and true into float.

That's correct. Fortunately the wrong values for the wsr does not have any influence for "normal" users. It is only used for channel cascading which is not used in the evaluation board. I will fix it in the code anyhow.

326

Wed Jan 15 17:02:58 2014

Andrey Kuznetsov wrote:

So although it doesn't affect data retrieval, it's just dumb luck the function ends up being called with parameters that matter being exactly what they were meant to be.

Exactly. If I would not have had that dumb luck, I would have seen the problem and fixed it. So it was more like bad luck.

327

Wed Jan 15 17:11:14 2014

Software drs-5.0.0 fails to compile (drsosc)

Andrey Kuznetsov wrote:

The DRSCallback *pcb is missing an if statement in the code when DRS Oscilloscope software isn't used when calibrating in function: int DRSBoard::CalibrateTiming(DRSCallback *pcb)

I had to add if (pcb != NULL) before each pcb call, like other functions are using so that the program doesn't segfault when the function is called like b->CalibrateTiming(NULL);

That's the only function that's missing this if statement for DRSCallback *pcb call, and there are 2 calls in this function to pcb that need fixing.

Acknowledged. Added it to the code.

332

Wed Mar 5 21:54:13 2014

Hermann-Josef Mathes

Hi,

the latest software drs-5.0.0.tar.gz fails to compile on my freshly installed SuSE 13.1 whereas the previous 4.0.1 is compiling out-of-the-box.

My system has the wxWidgets 2.8.12 which is probably together with gcc 4.8.1 the reason of the problem. I applied a number of corrections, mainly some sort of proper (?) typecasts, a patch file is attached.

Maybe you could consider to take them into account for the next patch release?

Thanks and best regards

Hermann-Josef

Attachment 1: drs-5.patch

diff --git a/src/DOScreen.cpp b/src/DOScreen.cpp
index 0147c29..3f6b665 100644
--- a/src/DOScreen.cpp
+++ b/src/DOScreen.cpp
@@ -110,7 +110,7 @@ void DOScreen::OnPaint(wxPaintEvent& event)
    
    // Change "Save" button
    if (!m_frame->GetWFfd() && !m_frame->GetWFFile())
-      m_frame->SetSaveBtn("Save", "Save waveforms");
+      m_frame->SetSaveBtn(wxT("Save"), wxT("Save waveforms"));
 }
 
 /*------------------------------------------------------------------*/
@@ -347,7 +347,7 @@ void DOScreen::DrawScopeBottom(wxDC& dc, int board, int x1, int y1, int width, b
    }
    x_start = x_start - 15 - w;
    if (m_frame->GetNSaved()) {
-      wxst.Printf("%d saved", m_frame->GetNSaved());
+      wxst.Printf(wxT("%d saved"), m_frame->GetNSaved());
       dc.GetTextExtent(wxst, &w, &h);
       dc.DrawRoundedRectangle(x_start-20-w, y1+3, w+10, 15, 2);
       dc.DrawText(wxst, x_start-15-w, y1+3);
diff --git a/src/TriggerDialog.cpp b/src/TriggerDialog.cpp
index 7aeb33e..32b41fa 100644
--- a/src/TriggerDialog.cpp
+++ b/src/TriggerDialog.cpp
@@ -26,13 +26,13 @@ TriggerDialog_fb( parent )
    m_cbANDEXT->SetValue((tc & (1<<12))>0);
    
    wxString s;
-   s.Printf("%1.3lf", m_frame->GetTrgLevel(0));
+   s.Printf(wxT("%1.3lf"), m_frame->GetTrgLevel(0));
    m_tbLevel1->SetValue(s);
-   s.Printf("%1.3lf", m_frame->GetTrgLevel(1));
+   s.Printf(wxT("%1.3lf"), m_frame->GetTrgLevel(1));
    m_tbLevel2->SetValue(s);
-   s.Printf("%1.3lf", m_frame->GetTrgLevel(2));
+   s.Printf(wxT("%1.3lf"), m_frame->GetTrgLevel(2));
    m_tbLevel3->SetValue(s);
-   s.Printf("%1.3lf", m_frame->GetTrgLevel(3));
+   s.Printf(wxT("%1.3lf"), m_frame->GetTrgLevel(3));
    m_tbLevel4->SetValue(s);
 }
 
@@ -49,19 +49,19 @@ void TriggerDialog::OnButton( wxCommandEvent& event )
 void TriggerDialog::OnTriggerLevel( wxCommandEvent& event )
 {
    if (event.GetId() == ID_LEVEL1)
-      m_frame->SetTrgLevel(0, atof(m_tbLevel1->GetValue()));
+      m_frame->SetTrgLevel(0, atof(m_tbLevel1->GetValue().mb_str()));
    if (event.GetId() == ID_LEVEL2)
-      m_frame->SetTrgLevel(1, atof(m_tbLevel2->GetValue()));
+      m_frame->SetTrgLevel(1, atof(m_tbLevel2->GetValue().mb_str()));
    if (event.GetId() == ID_LEVEL3)
-      m_frame->SetTrgLevel(2, atof(m_tbLevel3->GetValue()));
+      m_frame->SetTrgLevel(2, atof(m_tbLevel3->GetValue().mb_str()));
    if (event.GetId() == ID_LEVEL4)
-      m_frame->SetTrgLevel(3, atof(m_tbLevel4->GetValue()));
+      m_frame->SetTrgLevel(3, atof(m_tbLevel4->GetValue().mb_str()));
 }
 
 void TriggerDialog::SetTriggerLevel(double level)
 {
    wxString s;
-   s.Printf("%1.3lf", level);
+   s.Printf(wxT("%1.3lf"), level);
    m_tbLevel1->SetValue(s);
    m_tbLevel2->SetValue(s);
    m_tbLevel3->SetValue(s);

333

Thu Mar 6 11:12:44 2014

Software drs-5.0.0 fails to compile (drsosc)

Hermann-Josef Mathes wrote:

Hi,

the latest software drs-5.0.0.tar.gz fails to compile on my freshly installed SuSE 13.1 whereas the previous 4.0.1 is compiling out-of-the-box.

Maybe you could consider to take them into account for the next patch release?

Thanks and best regards

Hermann-Josef

Thank you very much for the corrections. I know it in principle, but neither my Mac OSX nor the Windows compiler complains, so I usually don't see this errors. It's fixed now.

/Stefan

865

Wed Feb 16 14:06:45 2022

Dmitry Hits

Sliders missing in drsosc

Hi everyone,

Did anyone have a "missing sliders problem" in GUI (see attachment) accompanied by the following message in the terminal.

(drsosc:4611): Gtk-WARNING **: 14:05:11.249: Negative content width -4 (allocation 20, extents 12x12) while allocating gadget (node scale, owner GtkScale)

(drsosc:4611): Gtk-WARNING **: 14:05:11.249: Negative content width -2 (allocation 0, extents 1x1) while allocating gadget (node trough, owner GtkScale)

If yes, how did you solve it?

All ideas are appreciated!

Cheers,

Dmitry

Attachment 1: Screen_Shot_2022-02-14_at_14.17.30.png

906

Thu Feb 22 01:21:11 2024

Rod McInnis

Simulation of FPGA

Hello:

A bit of background: I am working on a project that is utilizing the DRS4 Evaluation board as a prototype platform for a dedicated, special use capture. We will only be utilizing one channel of the ADC capture, and the 1024 samples is more than enough.

What I will need to do, however, is do some preprocessing on the incoming ADC data, running some calculation on the fly, possibly some filtering and other transformations before putting the data into the FPGA block memory for transfer to the host via the Cypress USB interface. I will be modifying the "drs4_eval5" VHDL file and doing a new FPGA build.

It will be essential that I be able to simulate this, from the ADC input to the data flow to the Cypress chip. I have "eval board files" which includes the VHDL source files, Xilinxe ISE project files and some very basic simulation testbenches.

Unfortunately, the simulation testbenches call out a "drs4_eval1" module while the Xilinx project uses a "drs4_eval5" module, and the module ports are a little different. I think I can work around that, however. I have run the simulatilon "drs4_eval1_tb", which does a simple write to a Control Register. I need to expand this simulation so that it will initiate a full capture and then transfer the data from the RAM to the Cypress chip.

What I am most confused about is how the Cypress chip sucks out the data from the FPGA block ram. I would expect it to use a burst mode data transfer rather than the cumbersom CSR read/write, but I haven't found any documentation on how this interface works.

Q1: Is there a simulation testbench file available that does the 1024 sample data transfer?

Q2: Is there a waveform diagram that shows the protocol / signal handshake between the FPGA and Cypress chip for this data transfer?

Thank you

Rod McInnis

907

Thu Feb 22 10:37:03 2024

Simulation of FPGA

The Cypress has its own firmware, contained in the distribution under firmware/CY7C68013A/drs_eval.c. There you can see how the data is fetched. I kind of forgot how exactly it worked, since I wrote that code back in 2011. But most if the Cypress code is just the configuration of the USB, the communication with the FPGA is kind of straight forward in the Cypress implementation. But you have to read the manual of that chip to understand it.

Unfrtunately there is no full testbench for the firmware, since I didn't have a VHDL Model of the Cypress, so I implemente dit the "hard" way ;-)

Best,
Stefan

Rod McInnis wrote:

Hello:

Q1: Is there a simulation testbench file available that does the 1024 sample data transfer?

Q2: Is there a waveform diagram that shows the protocol / signal handshake between the FPGA and Cypress chip for this data transfer?

Thank you

Rod McInnis

Tue Apr 28 11:44:07 2009

Simple example application to read a DRS evaluation board

Several people asked for s simple application to guide them in writing their own application to read out a DRS board. Such an application has been added in software revions 2.1.1 and is attached to this message. This example program drs_exam.cpp written in C++ does the following necessary steps to access a DRS board:

Crate a "DRS" object and scan all USB devices
Display found DRS boards
Initialize the first found board and set the sampling frequency to 5 GSPS
Enable internal trigger on channel #1 with 250 mV threshold
Start acquisition and wait for a trigger
Read two waveforms (both time and amplitude)
Repeat this 10 times

I know that we are still missing a good documentation for the DRS API, but I have not yet found the time to do that. I hope the example program is enough for most people to start writing own programs. For Windows users (MS Visual C++ 8.0) there is a drs.sln project file, and for linux users there is a Makefile which can be used to compile this example program.

Attachment 1: drs_exam.cpp

/********************************************************************\

  Name:         drs_exam.cpp
  Created by:   Stefan Ritt

  Contents:     Simple example application to read out a DRS4
                evaluation board

  $Id: drs_exam.cpp 13344 2009-04-28 07:34:45Z ritt@PSI.CH $

\********************************************************************/

#include <math.h>

#ifdef _MSC_VER

#include <windows.h>

#elif defined(OS_LINUX)

#define O_BINARY 0

#include <unistd.h>
#include <ctype.h>
#include <sys/ioctl.h>
#include <errno.h>

#define DIR_SEPARATOR '/'

#endif

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

#include "strlcpy.h"
#include "DRS.h"

/*------------------------------------------------------------------*/

int main()
{
   int i, j, nBoards;
   DRS *drs;
   DRSBoard *b;
   float time_array[1024];
   float wave_array[8][1024];

   /* do initial scan */
   drs = new DRS();

   /* show any found board(s) */
   for (i=0 ; i<drs->GetNumberOfBoards() ; i++) {
      b = drs->GetBoard(i);
      printf("Found DRS4 evaluation board, serial #%d, firmware revision %d\n", 
         b->GetBoardSerialNumber(), b->GetFirmwareVersion());
   }

   /* exit if no board found */
   nBoards = drs->GetNumberOfBoards();
   if (nBoards == 0) {
      printf("No DRS4 evaluation board found\n");
      return 0;
   }

   /* continue working with first board only */
   b = drs->GetBoard(0);

   /* initialize board */
   b->Init();

   /* set sampling frequency */
   b->SetFrequency(5);

   /* enable transparent mode needed for analog trigger */
   b->SetTranspMode(1);

   /* use following line to disable hardware trigger */
   //b->EnableTrigger(0, 0);

   /* use following line to enable external hardware trigger (Lemo) */
   //b->EnableTrigger(1, 0);

   /* use following lines to enable hardware trigger on CH1 at 250 mV positive edge */
   b->EnableTrigger(0, 1);              // lemo off, analog trigger on
   b->SetTriggerSource(0);              // use CH1 as source
   b->SetTriggerLevel(0.25, false, 0);  // 0.25 V, positive edge, zero delay

   /* repeat ten times */
   for (j=0 ; j<10 ; j++) {

      /* start board (activate domino wave) */
      b->StartDomino();

      /* wait for trigger */
      printf("Waiting for trigger...");
      while (b->IsBusy());

      /* read all waveforms */
      b->TransferWaves(0, 8);

      /* read time (X) array in ns */
      b->GetTime(0, time_array);

      /* decode waveform (Y) array first channel in mV */
      b->GetWave(0, 0, wave_array[0]);

      /* decode waveform (Y) array second channel in mV*/
      b->GetWave(0, 1, wave_array[1]);

      /* process waveform: add here some code to display or save waveform X=time[i], Y=wave_array[n][i] */

      /* print some progress indication */
      printf("\rEvent #%d read successfully\n", j);
   }
   
   /* delete DRS object -> close USB connection */
   delete drs;
}

Wed Apr 29 07:57:33 2009