DRS4 Forum
  DRS4 Discussion Forum, Page 39 of 45  Not logged in ELOG logo
New entries since:Thu Jan 1 01:00:00 1970
ID Date Authorup Subject
  857   Sat Jan 15 10:50:47 2022 Stefan RittI want to know about the readout
student_riku wrote:

Am I right in thinking that inputting 1 to DMODE (Bit0) in the configuration register will connect the 1024th cell to the 1st cell?

Yes, as desceribed in the manual .

student_riku wrote:

Also, let's assume that after sampling 1024 cells on channel 0, 200 cells are sampled in the second week.
Does the readout of 1024 cells start from cell 0?
Or does it start from the 200th cell?

I don't understand what you mean by "second week". 

Normally, you run the chip continously (DMODE=1) until you receive a trigger. Then, you typically read out the chip from the stop position by using a RSRLOAD pulse (as described unter "REGION-OF-INTEREST READOUT MODE".

Stefan

  859   Tue Jan 25 14:34:42 2022 Stefan RittRegarding measuring for a set time

drsosc is a graphical application contiously acquiring data from the board, and drscl is a command line tool for debugging, as written in the manual.

The drsosc application runs indefinitely, but I guess you refer to saving data (by hitting the "Save" button in the drsosc application). Yes the save functionality has a number of events, since you cannot store data indefinitely, since your harddisk does not have indefinite space!

I kind of sense that you want to convert the "number of event to save" into "number of seconds or hours to save". This is not build into the drsosc application. It's all open source, so feel free to change the code. Alternatively, you can use the drs_exam.cpp program coming with the distribution, wich is a simpel C++ program reading the board. It has a for loop over 10 events, but you can change the code easily to run for a predetermined amount of time.

Stefan

Thomas M. wrote:

Am I correct in assuming that drsosc and drscl are functionally equivalent regarding collecting data? We want to run the DRS4-EB for a predefined amount of time. However, the DRS4 scope application seems only to run for a predefined set of measurements. Have I got that right? Is there some reason to avoid running the DRS4-EB for a predefined amount of time that I should be aware of?

  864   Tue Feb 15 12:02:29 2022 Stefan RittCannot trigger on pulses, have to trigger on undershoot

The trigger comparator is a ADCMP601 unit which requires a minimum pulse width of 3-4 ns. I see that your pulses are only 1-2 ns wide. You have to make your pulses wider in order to trigger on them.

Stefan

  868   Thu Mar 3 13:47:26 2022 Stefan RittHow to convert samples to volt?

The 'drscl' tool is more for experts, normal users are advised to use the DRSOsc oscilloscope.

The board has to be calibrated for a given sampling speed before calibrated data can be read out. Do that with the "calib" command, specifying 5 for the sampling rate, 0 for the range (which is the middle between -0.5 and +0.5) and 1 for 1024 mode. If you then do "start", "stop", "read 0 1" you get calibrated data in mV.

Stefan

Matias Senger wrote:

I am using the `drscl` app. My prior experience is practically zero, sorry if this is a very naive question. When I read using `read 0 1` (channel 0, with calibration) I get this:

```
Calibration not valid for board #2946
  10    3    7    4   10    8   14    5    5    9    3    4    9    8    9    4
   3    3   12    5    5   13    3    8    1    5    0    4    8    6    6    3
...etc...
```

Why does it says that the calibration is not valid? How am I supposed to go from integers to volts?

If I run the `info` command I get this:

```
==============================
Mezz. Board index:    0
DRS type:             DRS4
Board type:           9
Serial number:        2946
Firmware revision:    30000
Temperature:          43.4 C
Input range:          -0.5V...0.5V
Calibrated range:     -0.5V...0.5V
Calibrated frequency: 0.000 GHz
Status reg.:          0000009A
Control reg.:         00000000
  DMODE circular
Trigger bus:          00000000
Frequency:            1.007 GHz
```

 

  869   Thu Mar 3 16:14:16 2022 Stefan RittScaler issue to evaluate live time

The scalers are read out 10x per seconds, so they have an accuracy of 10 Hz. I tried a 50 Hz pulser, and measured 40 Hz, I tried 52 Hz and measured 50 Hz. This is about what you can expect.

The scaler rate is measured after the discriminator of the trigger, so the trigger level also affects the scaler reading. If you have a 100 mV pulse and your threshold is 200 mV, your scaler rate drops to zero. That can be seen best with the DRSOsc and sliding the trigger value. If you have a 50 Hz pulse with narrow (< us) pulses, things are fine. But if you use a 50 Hz square wave, then you get distorted signals due to the AC coupling which can also be confusing. See for example here: https://www.daqarta.com/dw_gg0o.htm

Keita Mizukoshi wrote:

Hi. I'm trying to evaluate livetime of the evaluation board with the hardware scaler. I'm facing a strange issue.

I took the rate with the function, DRS->GetScaler(int channel).
I guess that channels 0--3 mean the rate for the channel, and channel 4 means the counter of the trigger.
I took the 1,000 pulses generated by a pulse generator with 50 Hz.
The scaler values are ~ 39.83, not 50.
The timestamp difference between the initial event and the final event is 19.98 seconds.
1000/19.98 ~ 50, thus, the evaluation board took the pulses with enough livetime.

Can we believe the scaler value for the livetime evaluation?

 

  872   Mon Mar 7 08:45:32 2022 Stefan RittWhy does not trigger at higher sampling frequencies?

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

  874   Mon Mar 7 16:37:54 2022 Stefan RittScaler issue to evaluate live time

I tried your measurement with the DRSOscilloscope app (see below), and I measure a constant difference of 10 Hz among the whole range of 100 Hz to 3 kHz.

So I don't know what's wrong on your side. Did you try with the oscilloscope app as well? Have you checked your pulse generator? The evaluation board time reference is a quartz with an accuracy of 10^-5, so no way one can get there a difference you see.

Stefan

Keita Mizukoshi wrote:

Thank you very much for your explanation.

 

I would like to show you a pulse example ('black line is the threshold).

Still, pulse generator rate and DRS4 rate are a bit different more than 10 Hz.

 

Stefan Ritt wrote:

The scalers are read out 10x per seconds, so they have an accuracy of 10 Hz. I tried a 50 Hz pulser, and measured 40 Hz, I tried 52 Hz and measured 50 Hz. This is about what you can expect.

The scaler rate is measured after the discriminator of the trigger, so the trigger level also affects the scaler reading. If you have a 100 mV pulse and your threshold is 200 mV, your scaler rate drops to zero. That can be seen best with the DRSOsc and sliding the trigger value. If you have a 50 Hz pulse with narrow (< us) pulses, things are fine. But if you use a 50 Hz square wave, then you get distorted signals due to the AC coupling which can also be confusing. See for example here: https://www.daqarta.com/dw_gg0o.htm

Keita Mizukoshi wrote:

Hi. I'm trying to evaluate livetime of the evaluation board with the hardware scaler. I'm facing a strange issue.

I took the rate with the function, DRS->GetScaler(int channel).
I guess that channels 0--3 mean the rate for the channel, and channel 4 means the counter of the trigger.
I took the 1,000 pulses generated by a pulse generator with 50 Hz.
The scaler values are ~ 39.83, not 50.
The timestamp difference between the initial event and the final event is 19.98 seconds.
1000/19.98 ~ 50, thus, the evaluation board took the pulses with enough livetime.

Can we believe the scaler value for the livetime evaluation?

 

 

 

Attachment 1: Screenshot_2022-03-07_at_16.37.32_.png
Screenshot_2022-03-07_at_16.37.32_.png
Attachment 2: Screenshot_2022-03-07_at_16.35.44_.png
Screenshot_2022-03-07_at_16.35.44_.png
  878   Sat Mar 12 10:13:24 2022 Stefan RittTime calibration and the C++ API

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

 

 

 

Matias Senger wrote:

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!

 

  880   Mon Mar 14 08:59:51 2022 Stefan RittTime calibration and the C++ API

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

 

  883   Tue Apr 12 10:49:27 2022 Stefan Ritt 

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

LynseyShun wrote:

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

 

  887   Fri Jul 29 14:09:35 2022 Stefan RittIncrease event rate, use ROI mode, and install sw from source in Mac

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

Jingyu Zhang wrote:

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

 

  888   Fri Jul 29 17:23:43 2022 Stefan RittSpikes/noise sensitive to clock settings?

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

  891   Tue Sep 27 10:37:11 2022 Stefan RittRequired Firmware for DRS4 Evaluation Board Version 2.0

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

 

Kunal Shinde wrote:

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

 

  893   Tue Sep 27 15:20:55 2022 Stefan RittRequired Firmware for DRS4 Evaluation Board Version 2.0

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

Kunal Shinde wrote:

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

Regards,

Kunal

Stefan Ritt wrote:

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

 

Kunal Shinde wrote:

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

 

 

 

  896   Mon Oct 24 12:50:24 2022 Stefan RittChannel Cascading Option in the 2048-bin

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

Phan Van Chuan wrote:

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.

 

  897   Mon Feb 6 13:28:28 2023 Stefan RittDRS4 installation via tar in ubuntu not working

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

Sebastian Infante wrote:

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
 

 

 

 

  899   Mon Jun 12 14:22:04 2023 Stefan RittDifferent sampling rates in multi-board configuration

No, that's unfortunately not possible.

Stefan

Javier Caravaca wrote:

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.

 

  902   Wed Sep 13 13:18:45 2023 Stefan RittInput range switch added in Version 2.1.3

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

  904   Wed Oct 25 19:47:23 2023 Stefan RittWaveDREAM Design

No. This is a proprietary design.

Best,
Stefan

  907   Thu Feb 22 10:37:03 2024 Stefan RittSimulation 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:

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

 

 

 

ELOG V3.1.5-fe60aaf