Hi all

We're working on a new product using the DRS4 IC, and want to do a full readout from cell 0 (not just Region of Interest).  I have a couple of questions I hope you can help me with:

• We plan to do a full readout sequence, starting at cell 0.  Part of that sequence includes pulsing RSRLOAD and reading out the stop position as shown in v0.9 datasheet Figure 15.  What should the DRS4 address bits A3..0 be set to for reading out the stop position?  (I’m assuming it’s 1011 ‘Address Read Shift Register’)
• What is the output delay from the falling edge of SRCLK to valid data at SROUT?
• For channel readout, we pulse SRCLK to advance the read shift register.  The diagram shown in v0.9 datasheet Figure 12 appears to show that the analog output is updated on the rising edge of SRCLK. Is this correct or have I misread the diagram? (Other shift register transfers are clocked on the falling edge
• The DRS4 v0.9 datasheet Figure 7 shows that the Configuration register is clocked on the falling edge of SRCLK.  Just below that is the text “The new register content becomes immediately active at the eighth rising edge of the SRCLK signal.” Should that perhaps read ‘… the eighth falling edge of the SRCLK signal’?

The full readout mode is not really recommended since you have to pull out the stop position separately. Just do the ROI readout using the RSRLOAD signal, and then do 1024 samples, which also gives you the full waveform, but also the stop position in a single readout cyclce. The "full readout mode" is more there for "historical reasons", but nobody really uses it any more.

If you are interested in all details of the control signals, I propose you have a look at the VHDL code which comes with the software distribution. It's contained in the "firmware" subdirectoy and called drs4_eval5_app.vhd

Stefan

Hi all

We're building a product which will use two different operating modes; firstly a long capcture using channel daisy chaining (2048 samples) and secondly a segmented capture (2 separate captures of 1024 samples each). 

For the long capture, I'm looking to capture 2048 samples for 4 channels.  Therefore I configure the Write Shift Register to 0b01010101 and the Write Config Register to 0b11111111.  During capture with DWRITE=1 the Write Shift Register will update.  Am I correct that once the capture is done and DWRITE=0, I can set A3..0 to 0b1101 and simply read the value of WSROUT to tell the difference?

For the segmented capture, I'm looking to capture 1024 samples for 4 channels on a first tirgger pulse, followed by 1024 samples for 4 channels on a second pulse.  Therefore I configure the Write Shift Register to 0b11111111 and the Write Config Register to 0b01010101 and set DWRITE=0 to capture.  After the first trigger I set DWRITE=0 and need to update the Write Config Register.  Do I need to write in a whole 8 bits to the Write Config Register (i.e. 0b10101010), or can I just shift in a single new bit (value 0b0)?

This is correct. Setting A0-A3 to 0b1101 multiplexes the Shift Write Register to SROUT, so you will either a "0" or a "1" depending on which of the two channels was written last.

Your segmented capture does unfortunately not work. Due to a bug in the silicon, the first (e.g. even) written channel gets half overwritten when you start sampling the second (odd) channel. I should remove that from the documentation.

Furthermore, reading the chip while writing on the "other side" introduces quite some additional noise. The recommended way to do simultaneous reading and writing is therefore to use two separate DRS4 chips and split the input signals to both chips, then read from one chip while writing to the other chip. This keeps the crosstalk at a minimum and both chips run at full performance.

Stefan

Hi! i'm trying to compile drs_exam.cpp but it yields the following error lines:

I do have the "DRS.h" file on the same folder, which is clearly the file that's causing troubles. I also tried to run "DRS.cpp" but it yields a similar error lines. ('sin definir' means 'not defined').

Thanks a lot for the help!

$ g++ drs_exam.cpp  -o drs_exam
/usr/bin/ld: /tmp/ccroK16H.o: en la función `main':
drs_exam.cpp:(.text+0x48): referencia a `DRS::DRS()' sin definir
/usr/bin/ld: drs_exam.cpp:(.text+0x135): referencia a `DRSBoard::Init()' sin definir
/usr/bin/ld: drs_exam.cpp:(.text+0x155): referencia a `DRSBoard::SetFrequency(double, bool)' sin definir
/usr/bin/ld: drs_exam.cpp:(.text+0x169): referencia a `DRSBoard::SetTranspMode(int)' sin definir
/usr/bin/ld: drs_exam.cpp:(.text+0x184): referencia a `DRSBoard::SetInputRange(double)' sin definir
/usr/bin/ld: drs_exam.cpp:(.text+0x1b6): referencia a `DRSBoard::EnableTrigger(int, int)' sin definir
/usr/bin/ld: drs_exam.cpp:(.text+0x1ca): referencia a `DRSBoard::SetTriggerConfig(int)' sin definir
/usr/bin/ld: drs_exam.cpp:(.text+0x1fe): referencia a `DRSBoard::EnableTrigger(int, int)' sin definir
/usr/bin/ld: drs_exam.cpp:(.text+0x212): referencia a `DRSBoard::SetTriggerConfig(int)' sin definir
/usr/bin/ld: drs_exam.cpp:(.text+0x22d): referencia a `DRSBoard::SetTriggerLevel(double)' sin definir
/usr/bin/ld: drs_exam.cpp:(.text+0x241): referencia a `DRSBoard::SetTriggerPolarity(bool)' sin definir
/usr/bin/ld: drs_exam.cpp:(.text+0x255): referencia a `DRSBoard::SetTriggerDelayNs(int)' sin definir
/usr/bin/ld: drs_exam.cpp:(.text+0x2b6): referencia a `DRSBoard::StartDomino()' sin definir
/usr/bin/ld: drs_exam.cpp:(.text+0x2e9): referencia a `DRSBoard::IsBusy()' sin definir
/usr/bin/ld: drs_exam.cpp:(.text+0x30b): referencia a `DRSBoard::TransferWaves(int, int)' sin definir
/usr/bin/ld: drs_exam.cpp:(.text+0x326): referencia a `DRSBoard::GetTriggerCell(unsigned int)' sin definir
/usr/bin/ld: drs_exam.cpp:(.text+0x350): referencia a `DRSBoard::GetTime(unsigned int, int, int, float*, bool, bool)' sin definir
/usr/bin/ld: drs_exam.cpp:(.text+0x377): referencia a `DRSBoard::GetWave(unsigned int, unsigned char, float*)' sin definir
/usr/bin/ld: drs_exam.cpp:(.text+0x392): referencia a `DRSBoard::GetTriggerCell(unsigned int)' sin definir
/usr/bin/ld: drs_exam.cpp:(.text+0x3c3): referencia a `DRSBoard::GetTime(unsigned int, int, int, float*, bool, bool)' sin definir
/usr/bin/ld: drs_exam.cpp:(.text+0x3f1): referencia a `DRSBoard::GetWave(unsigned int, unsigned char, float*)' sin definir
/usr/bin/ld: drs_exam.cpp:(.text+0x52e): referencia a `DRS::~DRS()' sin definir
collect2: error: ld returned 1 exit status
 

You have to link against the DRS.cpp library, plus usblib, plus ... Note there is both a Makefile and a CMakeLists.txt for it. Google how to use "make" or "cmake".

Stefan

Thanks! I solved it by running ./drs_exam after execute Makefile (there was an inconsistency in the files directory).

Matías

Greetings, 

I have adapted the drs_exam.cpp to allow for a user input number of channels and trigger levels.

The program mostly works well, however there are counts which form a noise peak, imposed on the regular channel response.

To illustrate, I acquired 10,000 counts (measuring peak to peak) with the drsosc, and with my adapted script, with two channels and OR trigger logic.

Is there something missing in my code that could explain the cause of this noise peak? I have attached the .cpp file.

Many thanks,

Justin

Hello,

I need to write a script in C++ to take data using the DRS4 evaluation board v4. For that, I used the drs_exam.cpp example as a reference. This is my code (see attachement 2), which is very similar to the provided example, however the difference is that I need to trigger on CH1 OR CH2. In the next version I will need to trigger with an OR in all channels.

The problem is, my code gets stuck in waiting for trigger or only 1 event occurs (event 0). I read that event and it doesn't even go above 30mV, which was the threshold I set. There are some questions I have:

1. Why Transparent mode is activated for Hardware Trigger?
2. Why EnableTCal is activated? is the drs4_exam example based acquires the 100MHz reference just for the sake of the example? or is just a time calibration routine?
3. Can someone explain the function EnableTrigger(flag1,flag2) in boardType 8? it si not clear to me how the trigger is enabled.
4. To check that my input signals are correct, I run the drsosc application and I can see the signals with no problem (see attachement 1). However I noticed that I had to configure the trigger delay in the drsosc application, and I don't do that in my c++ code. I will try that later.
5. How do I perform voltage calibration and time calibration using the c++ functions?

Thank you so much for your help.

Hello, some updates:

     4. I was able to capture correct waveforms using c++ code. I needed to use the function SetTriggerDelayNs() to properly capture my waveforms.

     5. I noticed that the drsosc program source code uses the functions: CalibrateVolt() and CalibrateTiming() for performing calibration. For these to work, is it necessary to use EnableAcal() and EnableTcal() functions right? 

I'd appreciate if you can still give some insights about 1,2 and 3. Thank you!

1. Transparent mode is not needed for the hardware trigger, no idea why the code is there. You can probably remove it.

2. EnableTCal is only for the sake of having some waveforms at the input. Indeed you have to disable it to sample real signals.

3. EnableTrigger() is there to enable the hardware trigger. The flag2 is ther for historical reasons (used in older versions of the board).

4. You figured that out already yourself.

5. The functions CalibrateVolt() and CalibrateTiming() are the ones which get called if you click on volt and time calibration in the DRSOsc application. The calibration is store on the evaluation board, so you do not have to call them in your program.

Hello Stefan,

I am using the DRS4 board connected to a Raspberry PI and through the drsosc application. I am interested on using the "Trigger OUT" signal to do some extra data processing with NIM modules. According to the manual, for each hardware trigger a TTL pulse of 150 ns width should be send through the "trigger OUT". In my case I do see pulses with widths ranging from 100 microseconds up to hundreds of miliseconds. I am connecting the signal directly to an oscilloscope with 50 Ohm termination. I have tried two DRS4 boards in identical conditions and both show the same behavior.  Having such wide and variable pulses makes it complicated for me to do the extra post-processing. Have you any idea of what might be going wrong? Thank you very much.

Best regards,

Gerard

The "Trigger OUT" has changed recently. It goes high on a new trigger, but then STAYS high until the board has been read out by the PC and re-started. This allows better synchronization with some external trigger, which can be re-armed with the falling edge of the trigger out signal. The signal can be quite long, since readout of an event via USB typically takes 2 ms, but can be more if the PC is busy. If you need back your 150 ns pulse, send the trigger out to an external pulse shaper with fixed shaping width.

Stefan

Thank you very much for the answer, I really appreciate your help.

Thanks!

Gerard

In meantime I even updated the manual.

Stefan

Given this new scenario, what is the maximum rate of events that can be processed then (a rough estimation would be great, 1/2ms?)? is it mainly limited by the USB data transmission and the PC? How does the logic of the trigger and DRS4 data sampling works inside the FPGA in general terms? e.g: trigger activated -> dwrite ON -> ADC acquisition -> busy until data has been shipped off to the PC -> free to process new events. 

Is there a way to obtain some sort of timestamp for the trigger on each event? or is it better to use C++ time functions in the PC since the DRS4 is usually used in experiments with low rate of events so the long time it takes to the USB and PC is not a problem? (eg. particle physics).

Thanks for your help,

Matias H.

Hi, I'm a student trying to figure out the DRS4 board. I cloned the github repo, but when I run drsosc, I get an error: Gtk-Message: 10:06:38.376: Failed to load module "canberra-gtk-module". I'm not sure what that means. The oscilloscope window does open up for me though. Thanks for any help!

Salut !

Je vois que tu rencontres un petit problème avec ton installation. Le message "Gtk-Message: Failed to load module 'canberra-gtk-module'" indique que ton système essaie de charger un module GTK spécifique qui n'est pas installé. Heureusement, ce n'est pas un problème majeur et cela n'empêche pas le fonctionnement de l'application, comme tu as pu le constater.

Pour résoudre ce message d'erreur, tu peux installer le module manquant. Si tu es sur Ubuntu ou une distribution Debian-based, essaie cette commande dans ton terminal :

sudo apt-get install libcanberra-gtk-module libcanberra-gtk3-module

Après l'installation, relance drsosc pour voir si le message disparaît. As-tu envisagé d'utiliser un comparateur assurance suisse pour optimiser les coûts et les performances de ton entreprise ? Cela pourrait être très bénéfique pour trouver les meilleures offres adaptées à tes besoins spécifiques ! Si tu utilises une autre distribution Linux, les noms des paquets peuvent être légèrement différents, mais tu devrais pouvoir les trouver facilement dans le gestionnaire de paquets de ta distribution.

N'hésite pas à revenir si tu as d'autres questions ou problèmes ! Bon courage avec ton projet.

À bientôt !

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

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

Hello All,

Are there any design resources available for the WaveDREAM PCBA's?

Thanks In Advance,
John W.

No. This is a proprietary design.

Best,
Stefan

Stefan,

Oh, didn't realize that.

Thanks!
John

 A new software verison for the DRS4 Evaluation Board has been has been released. Version 2.1.3 adds a switch for the input range of the DRS4 board. Once can choose between -0.5V...0.5V and 0V...1V:

A board firmware update is not necessary for this. It was originally planned to have even a negative range -1V...0V, but this is not possible with the current board design. People who want to record negative pulses have to use an inverter to produce positive pulses. In a future version of the board it might be possible to include this functionality since this is determined by the analog front-end and not the DRS4 chip.

Hello,

It is not quite clear to me yet how the input range is only determined by the front end and not the DRS4 chip. According to the datasheet, the selection of ROFS determines whether the input differential range is -0.5V to 0.5V (ROFS=1.55V) or 0V to 1V (ROFS=1.05V) or -0.05V to 0.95V (ROFS=1.1V).

As far as I understand, the input differential voltage cannot go further below -0.55V since the maximum ROFS voltage is 1.6V according to the datasheet).

Also in the DRS4 evaluation board 5.1 design, the output of the differential amplifier is AC coupled to the DRS4 chip.

I'd appreciate a lot your help.

Regards,

Matias

To achieve an input range of -1V to 0V, you need an external buffer which can shift this range into the DRS4 range of -0.5V to +0.5V. This external buffer has then to operate with bipolar power supplies, like -2.5V to +2.5V, which are not present on the evaluation board.

Best regards,
Stefan

Hello,

Is it possible to have different sampling rates in multi-board configuration? I tried using the scope application but I am unable to change the sampling rate independently.

Best,

Javier.

No, that's unfortunately not possible.

Stefan

Hello i cant install any the last versions that i downloaded from the dropbox, i can untar the file called drs-5.0.6 and when i type "make" while inside the extracted folder that starts working properly till a point and i get an error, its worth mention that i installed wxWidgets and could make a simple hello world that worked properly in wxWidgets.

The error that i get is the next one:

inlined from ‘bool ResponseCalibration::ReadCalibrationV4(unsigned int)’ at src/DRS.cpp:7224:35:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:95:34: warning: ‘char* __builtin___strncpy_chk(char*, const char*, long unsigned int, long unsigned int)’ specified bound depends on the length of the source argument [-Wstringop-truncation]
   95 |   return __builtin___strncpy_chk (__dest, __src, __len,
      |          ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
   96 |                                   __glibc_objsize (__dest));
      |                                   ~~~~~~~~~~~~~~~~~~~~~~~~~
src/DRS.cpp: In member function ‘bool ResponseCalibration::ReadCalibrationV4(unsigned int)’:
src/DRS.cpp:4767:11: note: length computed here
 4767 |    strncpy(calibrationDirectoryPath, fCalibDirectory, strlen(fCalibDirectory));
      |    ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /usr/include/string.h:535,
                 from /usr/local/include/wx-3.3/wx/string.h:30,
                 from /usr/local/include/wx-3.3/wx/memory.h:15,
                 from /usr/local/include/wx-3.3/wx/object.h:19,
                 from /usr/local/include/wx-3.3/wx/wx.h:15,
                 from src/DRS.cpp:15:
In function ‘char* strncpy(char*, const char*, size_t)’,
    inlined from ‘void DRSBoard::GetCalibrationDirectory(char*)’ at src/DRS.cpp:4767:11,
    inlined from ‘bool ResponseCalibration::ReadCalibrationV3(unsigned int)’ at src/DRS.cpp:7066:35:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:95:34: warning: ‘char* __builtin___strncpy_chk(char*, const char*, long unsigned int, long unsigned int)’ specified bound depends on the length of the source argument [-Wstringop-truncation]
   95 |   return __builtin___strncpy_chk (__dest, __src, __len,
      |          ~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
   96 |                                   __glibc_objsize (__dest));
      |                                   ~~~~~~~~~~~~~~~~~~~~~~~~~
src/DRS.cpp: In member function ‘bool ResponseCalibration::ReadCalibrationV3(unsigned int)’:
src/DRS.cpp:4767:11: note: length computed here
 4767 |    strncpy(calibrationDirectoryPath, fCalibDirectory, strlen(fCalibDirectory));
      |    ~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
g++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -I/usr/local/include -DOS_LINUX -DHAVE_USB -DHAVE_LIBUSB10 -DUSE_DRS_MUTEX -I/usr/local/lib/wx/include/gtk3-unicode-3.3 -I/usr/local/include/wx-3.3 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -c src/averager.cpp
g++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -I/usr/local/include -DOS_LINUX -DHAVE_USB -DHAVE_LIBUSB10 -DUSE_DRS_MUTEX -I/usr/local/lib/wx/include/gtk3-unicode-3.3 -I/usr/local/include/wx-3.3 -D_FILE_OFFSET_BITS=64 -DWXUSINGDLL -D__WXGTK__ -pthread -c src/ConfigDialog.cpp
In file included from include/DRSOscInc.h:25,
                 from src/ConfigDialog.cpp:7:
include/DOFrame.h: In member function ‘bool DOFrame::GetRefclk()’:
include/DOFrame.h:111:46: error: ordered comparison of pointer with integer zero (‘bool*’ and ‘int’)
  111 |    bool GetRefclk()        { return m_refClk > 0; }
      |                                     ~~~~~~~~~^~~
make: *** [Makefile:81: ConfigDialog.o] Error 1
 

I fixed the described error. Can you try the new version from https://bitbucket.org/ritt/drs4eb/commits/80b3af753ed32eb365725f0f3244a4109347c01b

Dear Stefan,
We are using DRS4 evaluation board version 5.1 and firmware version 30000 (as the picture attached). Now, I am in need one channel with length 2048 bin. However, I can't find the resistors R99, ... ,R106 on the hardware of evaluation board; it seems my DRS4 evaluation board doesn't use 2048 bins per channel.
Our question is, can we repair this hardware to read 2048 bins/channel? if that is possible please let me know what to add on hardware/software of DRS4 evaluation.
Best regards.
Phan Van Chuan.

The board is delivered in one or the other mode and not meant to be changed by the user, since this requires very delicate soldering which is not easy. If you try anyhow, you loose the quarantee. You can send the board back to the manufacturer for the modification, but this costs quite some moeny.

Best regards,
Stefan

Hi, I am working on an old DRS4 board Version "2.0" with firmware revision "13191", I was unable to find this specific firmware source files ("VHDL source code"), please help me where could I find this or send me the required.

Regards,

Kunal

You find each software version at the usual download location at

https://www.dropbox.com/home/drs/drs4/distribution/Download/Linux

The one you need is probably drs-2.1.3.tar.gz which was the last version for the 2.0 board which is now more than 10 years old.

Best,
Stefan

I checked the link you provided but it seems that the link doesnt exist please send me valid one.

Regards,

Kunal

Sorry, got the wrong link. Here the right one: https://www.dropbox.com/sh/clqo7ekr0ysbrip/AACoWJzrQAbf3WiBJHG89bGGa?dl=0

If you untar the archive, you will find a "firmware" subdirectory with all VHDL code.

Stefan

What are the default register statuses after DRS4 gets reset?

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

elog:824

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

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

Dear experts, 

We are trying to increase the event rate of the DRS4. We looked into the ROI but couldn’t figure out how to run in ROI mode. We are wondering if there is pre-existing firmware for this? We also tried to download and build the software from source on MacOS 12.4 but we were not successful. Can you kindly help us with these?

Best regards, 

Jingyu

The firmware from the website always reads 1024 bins. You have to modify it to stop before that, like reading only 128 samples or so. For compiling under MacOSX, this should work, since I do it myself. 

Regards,
Stefan

Hello, I am Lynsey. now I set A3-A0 to 1001 in ROI mode, but only OUT0 has output, and the other seven channels(OUT1-OUT7) do not output corresponding waveforms.

In ROI mode, can OUT0-OUT7 output sampled waveforms at the same time?

thank you very much

A3-A0 = 1001 should be all you need to activate OUT0-OUT7. It works in our designs. Maybe double check the address lines with an oscilloscope.

Stefan

Thank you very much for your help!

I am using the V5 board at a fixed sampling frequency. With the `drsosc` app I have executed the time calibration at 5 GS/s (actually 5.12 GS/s). This is how my setup looks like in the app:

Now I want to replicate this using the C++ API (not the positive width measurement shown, the signal sampling only). I am seting the sampling frequency to 5 GS/s, as I do in the `drsosc` app. Then I get the time information using the `DRSBoard::GetTime(unsigned int chipIndex, int channelIndex, int tc, float *time)` function (which I don't find defined either in `DRS.h` or `DRS.cpp` but somehow it works). How can I know if these times that I get here are being corrected with the time calibration? If so, should I expect the time resolution to be < 3 ps? Are these 3 ps accumulative, such that in the end I end up having a contribution from the evaluation board of 3 ps × 5 Gs/s × 100 ns where 100 ns is the time difference between my two pulses? (This does not seem to be the case because if so I would expect the jitter to be ~ 1 ns, and we see that the "Pos Width" measurement is ~ 0.1 ns std.)

Why am I asking? I want to measure the jitter between the two falling edges. This cannot be done easily with the `drsosc` app I think, so I am acquiring the data and doing this offline. I have done this measurement in the past using a LeCroy WaveRunner oscilloscope with 20 GS/s and 4 GHz bandwidth (offline, same code) and I have seen it vary from ~5 ps → 30 ps when I vary a voltage that I can control. Now if I calculate this time fluctuation using the data acquired with the V5 evaluation board I get a value ~100 ps and independent of this voltage, which leads me to conclude that the limiting factor is being the evaluation board itself. So now I am wondering if I have reached its limit, or if there is some setting that can still improve this result.

Thanks!

DRSBoard::GetTime is declared in DRS.h line 720.

If you want to measure timing down to ps, you need some basic knowledge, especially about signal-to-noise and risetime. This cannot be taught in a few sentenses, needs a full lecture. As a starting point please read that papat:

https://arxiv.org/abs/1405.4975

then you will understand why you measure different resolutions with different peak heights (and different rise times).

Concerning the DRS4 measurement, please be aware that the sampling poings are not equidistant, like not every 200ps for GSPS. They vary bin by bin significantly, from 50ps to 300ps. So you alway have to analyse the X/Y points as an array, not just the Y values assuming deltaX of 200ps. Probably you forgot that. Then, you have to interpolate between bins to find the crossing over your threshold. Linear interpolation is already good, spline interpolation even better. Deep inside Measurement.cpp of the drsosc program you find in the source code:

t1 = (thr*(x1[i]-x1[i-1])+x1[i-1]*y1[i]-x1[i]*y1[i-1])/(y1[i]-y1[i-1]);

which is the linear interpolation (thr is the threshold). You have to use (and understand!) similar code.

Best,
Stefan

Dear Stefan,

For the time of each bin I am using the values returend by `GetTime` without any assumption by my side. I did not notice before that the sampling time is not uniform, but I see that this is already happening. This is an example plot from one of the signals I processed:

The bin at 65.5 ns and the next one are closer than their neighbors. So this seems to indicate that the time calibration is being taken into account when I acquire the time bins using `GetTime`, is this correct?

To obtain the final time resolution I am using the constant fraction discriminator method and the signals are linearly interpolated to obtain the time at each percentage value, as seen in the plot. I have already measured time resolutions in the 5-100 ps range with exactly the same setup but using the LeCroy oscilloscope, which I am using just for data acquisition, and my software for offline analysis as shown in the plot above. Now what I am trying to do is to replace the LeCroy by the DRS4 Evaluation Board basically, so I can use the oscilloscope in a different setup.

Best,
Matias.

Looks like you have the some time calibration, not sure if it's the correct one. Sample the sine wave from the calibration clock, once with and once without the timing calibration, then you will see if all points lie on a smooth line. Left: without timing calibration, right: with proper timing calibration:

If your points do not lie on a smooth line, you might habe a problem such as the wrong channel for calibration, an offset of 1 in the index of the time array or some other software bug. Measure the same signal with the DRSOsc application and then your code. If the results differ, you have a software problem on your side.

Stefan

Thanks for your help. If I look into the app the behavior for the 4 channels is exactly as you show:

Now, when I sample with my code something strange happens, two of the channels are fine and the other two are wrong:

This is a surprise to me because I acquire the 4 channels in the same way within a `for` loop. To get the time data I use `DRSBoard::GetTime` with the `tcalibrated` argument set to `true`. Is there any aditional step to use the calibration?

Best,
Matias.

I have connected 3 signals to the DRS4 Evaluation Board V5 which look like this in the drsosc app:

Note that here I am sampling at 5 GS/s. Using this app everything works perfect.

Now I want to repeat this using the C++ API (which I am actually wrapping to use within Python, see here if interested https://github.com/SengerM/pydrs ) but can only make this to work at lower sampling frequencies up to 3.9 GS/s. This is how I am configuring the board followint the `drs_exam.cpp` file:

```python
board.set_sampling_frequency(Hz=SAMPLING_FREQ)
board.set_transparent_mode('on')
board.set_input_range(center=0)
board.enable_trigger(True,False) # Don't know what this line does, it was in the example `drs_exam.cpp`.
board.set_trigger_source('ch4')
board.set_trigger_level(volts=-.1)
board.set_trigger_polarity(edge='falling')
board.set_trigger_delay(seconds=TRIGGER_DELAY)

```

The full code is here https://github.com/SengerM/pydrs/blob/master/tests/test_drs.py but anyway, my previous snippet can be considered as pseudo-code and if more details needed I can provide.

This is what I get as I increase the sampling frequency:

Up to 3.95 GS/s it works perfectly. At >= 4 GS/s it just never triggers. A few times I was able to make this work at 4 and 5 GS/s playing with the trigger delay, but this seemed to be some kind of random luck because I was not able to replicate it even with the same values.

Any help is appreciated.

Best,
Matías.

Unfortunately I have not idea what the problem could be. In principle the trigger should be independent of the sampling speed, since the trigger is only made with a discriminator and a flip-flop. The hardware must be ok since you see the trigger with the oscillocope app. All you can do is to go through the sorce code of the oscilloscope app, especially drsosc/Osic.cpp::ScanBoards(), SetTriggerLevel(), SetTriggerPolariy() etc. to make sure you do the same calls as the oscilloscope app.

Stefan

I have seen in the app that the trigger source buttons do something different than the "or" and "transparent trigger" buttons:

If I enable the setup from the right, i.e. OR in CH4 and "Enable Transparent Trigger" the app stops triggering. This is the configuration that seems to be applied in the `drs_exam.cpp` code if I am not mistaken. For some reason in that code it still triggers (I have modified the code to trigger on CH4 instead of CH1 and the trigger level, polarity, etc.).

What does the button in the left actually do? The circular checkbox with the "4" I mean. This is the trigger configuration I want to get in the C++ code.

I also don't know what the function `DRSBoard::EnableTrigger` does, what is the meaning of `flag1` and `flag2`? In my code there is a call to this function which I copied from the example.

Sorry for the spam. Just want to let you know that I was able to solve the problem, it was all due to a `float` being casted as `int` in the Python binding. Now it works like a charm.