All right, thank you for the clarification.

Yes this is correct. Anyhow, even if it would be working, you would not be happy with it. After having designed ~10 boards with the DRS4 chip, I learned the hard way that any digital activity on the board during the sampling phase is strictly forbidden. You see crosstalk up to 100's of mV in some cases (with a preamplifier on the board, 10-20mV without preamp). So rule #1 is to keep the board as "quite" as possible when sampling the input. If you would readout the odd channels of the DRS4 during sampling of the even channels, you would probably get so much crosstalk that the samples are almost unusable. Even if you would do this with two DRS4 chips next to each other, you have to make sure to put proper grounding between the two chips, and operate them completely independent (like each one has it's onw contol lines going to the FPGA). Designing such boards is not so easy and takes lots of experience from the layouter.

Stefan

Hi Stefan

Just so I'm 100% clear; is there no reliable way to perform 2 segmented captures with a single DRS4 IC?

While not a showstopper, this is a bit disappointing.

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

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 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)?

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’?

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

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

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
 

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, 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!

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.

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.

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 !

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!

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:

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

Stefan,

Oh, didn't realize that.

Thanks!
John