ID |
Date |
Author |
Subject |
575
|
Wed Nov 30 10:45:29 2016 |
Stefan Ritt | Long timing between two channels | You cannot measure times longer than 1024/sampling rate.
Stefan
Randall Gladen wrote: |
I don't believe I fully understand how the timing works between multiple channels on DRS4 board, even after reading the manual, but I am hoping to measure a time difference between two channels longer than 1024/sampling rate. So far, I have written a program in Matlab to extract timing and voltage information from the binary file to find the time difference between two channels that are set with the AND trigger logic and appear within approximately 80 ns of each other at a sampling rate of 1 GSPS. This works as intended, but I would now like to try to measure time differences of anywhere between 50 ns and several ms within a single spectrum. Since this is out of the range of only 1024 channels above 1GSPS, is it possible for the board to keep track of the time between two trigger pulses that occur at time differences longer than 1024/sampling rate?
Thank you very much for your help, and if I am severely misunderstanding how the board works, please forgive my ignorance and feel free to correct me,
~Randall
Edit: I forgot to mention that I am collecting the data using the provided DRS4 Oscilloscope software.
|
|
395
|
Fri Jan 16 13:29:05 2015 |
Rainer Hentges | Mac OSX Yosemite 10.10 | Hello,
I can compile version 5.0.3 of DRS4sc on Mac OSX 10.0 without errors but when I want to execute the program I get the following error:
[home]$ ./DRSOsc
DRSOsc(48068,0x7fff7ac5e300) malloc: *** error for object 0x7f88d9434a80: incorrect checksum for freed object - object was probably
modified after being freed.
*** set a breakpoint in malloc_error_break to debug
Is this a known error? Will it be fixed in the next release? |
396
|
Fri Jan 16 14:12:19 2015 |
Stefan Ritt | Mac OSX Yosemite 10.10 | > Hello,
>
> I can compile version 5.0.3 of DRS4sc on Mac OSX 10.0 without errors but when I want to execute the program I get the following error:
>
> [home]$ ./DRSOsc
> DRSOsc(48068,0x7fff7ac5e300) malloc: *** error for object 0x7f88d9434a80: incorrect checksum for freed object - object was probably
> modified after being freed.
> *** set a breakpoint in malloc_error_break to debug
>
> Is this a known error? Will it be fixed in the next release?
When I compile on OSX 10.10.1 with XCode 6.1.1 I get no error. I'm using wxWidgets 3.0.0. Same when I compile with the command line
tools (which you first have to install from Apple) via "make", "make app", "open ./DRSOsc.app". You cannot start a graphical program
directly from the command line like under Linux, you have to make an app and the do "open <app>".
Best regards,
Stefan |
693
|
Tue May 8 23:58:35 2018 |
Sean Quinn | Manual Rev5.1 Figure 1, optional components | Dear All,
I'm troubleshooting a board which uses the DRS4 and adopts an analog front end very similar to the evaluation board. As a result, we rely on the eval board as a reference. In doing so we've encountered an issue in the manual:
The high resolution photo in Figure 1. is useful, but it seems to correspond to an older version of the board. For instance, the RF switch can't correspond to the schematics of Rev5.1 in the appendix.
Request: Could the manual be updated with a high resolution image of Rev5.1. Also, could a high resolution of the bottom side of the board be included in the manual? This is desirable since it has the version number and contact information, so it will remove any ambiguity about what board you're looking at and what schematics you should refer to.
A second question, which might be overly broad: what is the impact of installing the optional components (marked * in the schematics) on the analog front end? Why are a lot of these left uninstalled on the eval board?
Thanks,
Sean |
694
|
Wed May 9 09:03:52 2018 |
Stefan Ritt | Manual Rev5.1 Figure 1, optional components | I updated the picture in the manual with a current picture of a Rev5.1 board, and also added a picture of the bottom side. If you need a picture without the blue labels, have a look at https://www.psi.ch/drs/old-evaluation-boards at the bottom.
Here is the explanation of the optional components:
- R1, C2, R6, R29, R30 and same components for other channels: Normally the board is AC-coupled. You can make the board DC-coupled by briding C1, C9, C13, removing R6, C2, adding R1, adding R29, removing R30. The CAL signal then enters before the THS4508. We found that DC coupling gives slightly higher noise and is prone to high input DC levels, so we ship the board usually AC-coupled.
- R84 & Co. defines the hysteresis of the trigger comparators as described in the schematics
- R99-R106, R143: If soldered, the board is configured in cascading mode with 4 channels @ 2048 bins. R143 tells the FPGA that we are in this mode, so the firmware can correctly configure the DRS4
- R118 & Co. defines the MCX output level to be either 3.3V or 5V (default)
- R146-R149 connect JTAG to the uC. We planned at one point to make firmware upgrades through USB, but we never implemented that, so these resistors are not soldered.
I hope I covered everything. If I overlooked any optional component please tell me.
Cheers,
Stefan
Sean Quinn wrote: |
Dear All,
I'm troubleshooting a board which uses the DRS4 and adopts an analog front end very similar to the evaluation board. As a result, we rely on the eval board as a reference. In doing so we've encountered an issue in the manual:
The high resolution photo in Figure 1. is useful, but it seems to correspond to an older version of the board. For instance, the RF switch can't correspond to the schematics of Rev5.1 in the appendix.
Request: Could the manual be updated with a high resolution image of Rev5.1. Also, could a high resolution of the bottom side of the board be included in the manual? This is desirable since it has the version number and contact information, so it will remove any ambiguity about what board you're looking at and what schematics you should refer to.
A second question, which might be overly broad: what is the impact of installing the optional components (marked * in the schematics) on the analog front end? Why are a lot of these left uninstalled on the eval board?
Thanks,
Sean
|
|
700
|
Wed Jun 13 13:23:17 2018 |
Julian Kemp | Maximum analog input voltage | Dear all,
I have been wondering what the maximum analog input voltage for the DRS4 V5 evaluation board is. It came with a sticker indicating that it is "2.5V pk Max". On the other hand, when checking the manual (https://www.psi.ch/drs/DocumentationEN/manual_rev50.pdf), it says maximum allowed is 10V DC or even 30V for short pulses. I foresee an application where I cannot make sure that pulses stay below 2.5V, so the correct value will be quite important for me.
Best,
Julian |
701
|
Wed Jun 13 13:42:47 2018 |
Stefan Ritt | Maximum analog input voltage | In principle the numbers in the manual are correct. But they relate to pulses of a certain length, because the input protection only works for DC voltage and for pulses which are not too long. Since we could not write this all on the label of the board, we decided to put there 100% safe value as a "warning" to people, meaning that if pulses are above 2.5V, they should look into the manual and read the details.
Stefan
Julian Kemp wrote: |
Dear all,
I have been wondering what the maximum analog input voltage for the DRS4 V5 evaluation board is. It came with a sticker indicating that it is "2.5V pk Max". On the other hand, when checking the manual (https://www.psi.ch/drs/DocumentationEN/manual_rev50.pdf), it says maximum allowed is 10V DC or even 30V for short pulses. I foresee an application where I cannot make sure that pulses stay below 2.5V, so the correct value will be quite important for me.
Best,
Julian
|
|
702
|
Wed Jun 13 16:34:28 2018 |
Julian Kemp | Maximum analog input voltage | Thank you! That solves my problem.
Stefan Ritt wrote: |
In principle the numbers in the manual are correct. But they relate to pulses of a certain length, because the input protection only works for DC voltage and for pulses which are not too long. Since we could not write this all on the label of the board, we decided to put there 100% safe value as a "warning" to people, meaning that if pulses are above 2.5V, they should look into the manual and read the details.
Stefan
Julian Kemp wrote: |
Dear all,
I have been wondering what the maximum analog input voltage for the DRS4 V5 evaluation board is. It came with a sticker indicating that it is "2.5V pk Max". On the other hand, when checking the manual (https://www.psi.ch/drs/DocumentationEN/manual_rev50.pdf), it says maximum allowed is 10V DC or even 30V for short pulses. I foresee an application where I cannot make sure that pulses stay below 2.5V, so the correct value will be quite important for me.
Best,
Julian
|
|
|
441
|
Mon Jul 20 09:25:38 2015 |
Chenfei Yang | Measure the time between different samples | Hi,
I have a question using a data acquisition card base on DRS4 chip. How can I measure the time between several samples of one channel,with the accuracy of like nanoseconds , for I am using the internal trigger. Is there any complete work about this problem?
One conceivable way is using an global counter in FPGA, but I'm wondering how to synch the counter with the DRS4 sampling.
Thanks.
Chenfei Yang |
442
|
Thu Jul 23 13:46:12 2015 |
Stefan Ritt | Measure the time between different samples | > Hi,
> I have a question using a data acquisition card base on DRS4 chip. How can I measure the time between several samples of one channel,with the accuracy of like nanoseconds , for I am using the internal trigger. Is there any complete work about this problem?
> One conceivable way is using an global counter in FPGA, but I'm wondering how to synch the counter with the DRS4 sampling.
> Thanks.
> Chenfei Yang
I do not know exactly what you do, so it's hard to give an advice. All I can say that the DRS4 Evaluation Board from PSI allows time measurements between two channels in the order of a few pico seconds. You can download the software for this board from the DRS4 web site and
have a look how things are done.
The trigger position is not a good time reference, since the trigger position jitters by a few samples. So if you want to measure the time of a signal versus a trigger, you have to put this trigger in a free channel of the DRS4 and use that as a time reference.
Best regards,
Stefan |
553
|
Fri Nov 4 17:41:03 2016 |
Christian Farina | Missing Header | Hello everybody,
I am completely new to this, so please bear with me.
I am trying to install the applications on my laptop. I downloaded and untar-ed the drivers and applications for Linux as described in the evaluation board manual. However, when I do the make, I get the following error:
drs-4.0.0$ make
g++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -DOS_LINUX -DHAVE_LIBUSB -DUSE_DRS_MUTEX -c src/musbstd.c
In file included from src/musbstd.c:14:0:
include/musbstd.h:17:17: fatal error: usb.h: No such file or directory
#include <usb.h>
Can anybody help me please?
Thanks. |
554
|
Tue Nov 8 10:20:52 2016 |
Stefan Ritt | Missing Header | The web page from where you downloaded the software contains a sentence "requires libusb-1.0 package". Please install it. This package brings the "usb.h" header file.
Stefan
Christian Farina wrote: |
Hello everybody,
I am completely new to this, so please bear with me.
I am trying to install the applications on my laptop. I downloaded and untar-ed the drivers and applications for Linux as described in the evaluation board manual. However, when I do the make, I get the following error:
drs-4.0.0$ make
g++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -DOS_LINUX -DHAVE_LIBUSB -DUSE_DRS_MUTEX -c src/musbstd.c
In file included from src/musbstd.c:14:0:
include/musbstd.h:17:17: fatal error: usb.h: No such file or directory
#include <usb.h>
Can anybody help me please?
Thanks.
|
|
555
|
Wed Nov 9 17:19:48 2016 |
Christian Farina | Missing Header | Thank you Stefan, that was just what I needed.
Also, I have another question, if I am allowed to ask on this forum. I am trying to study how the time calibration of the DRS is done. Can you point me to the script in which this is done?
Thank you,
Christian
Stefan Ritt wrote: |
The web page from where you downloaded the software contains a sentence "requires libusb-1.0 package". Please install it. This package brings the "usb.h" header file.
Stefan
Christian Farina wrote: |
Hello everybody,
I am completely new to this, so please bear with me.
I am trying to install the applications on my laptop. I downloaded and untar-ed the drivers and applications for Linux as described in the evaluation board manual. However, when I do the make, I get the following error:
drs-4.0.0$ make
g++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -DOS_LINUX -DHAVE_LIBUSB -DUSE_DRS_MUTEX -c src/musbstd.c
In file included from src/musbstd.c:14:0:
include/musbstd.h:17:17: fatal error: usb.h: No such file or directory
#include <usb.h>
Can anybody help me please?
Thanks.
|
|
|
556
|
Wed Nov 9 19:49:07 2016 |
Stefan Ritt | Missing Header | Best is to read this paper: https://arxiv.org/abs/1405.4975
The source code for that is in DRS.cpp in the DRS software distribution in the function DRSBoard::CalibrateTiming()
Stefan
Christian Farina wrote: |
Thank you Stefan, that was just what I needed.
Also, I have another question, if I am allowed to ask on this forum. I am trying to study how the time calibration of the DRS is done. Can you point me to the script in which this is done?
Thank you,
Christian
Stefan Ritt wrote: |
The web page from where you downloaded the software contains a sentence "requires libusb-1.0 package". Please install it. This package brings the "usb.h" header file.
Stefan
Christian Farina wrote: |
Hello everybody,
I am completely new to this, so please bear with me.
I am trying to install the applications on my laptop. I downloaded and untar-ed the drivers and applications for Linux as described in the evaluation board manual. However, when I do the make, I get the following error:
drs-4.0.0$ make
g++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -DOS_LINUX -DHAVE_LIBUSB -DUSE_DRS_MUTEX -c src/musbstd.c
In file included from src/musbstd.c:14:0:
include/musbstd.h:17:17: fatal error: usb.h: No such file or directory
#include <usb.h>
Can anybody help me please?
Thanks.
|
|
|
|
561
|
Thu Nov 10 20:54:45 2016 |
Christian Farina | Missing Header | Hi Stefan,
I have already read the paper. I was just unsure where the calibration code was located. Thank you so much for all your help.
Christian
Stefan Ritt wrote: |
Best is to read this paper: https://arxiv.org/abs/1405.4975
The source code for that is in DRS.cpp in the DRS software distribution in the function DRSBoard::CalibrateTiming()
Stefan
Christian Farina wrote: |
Thank you Stefan, that was just what I needed.
Also, I have another question, if I am allowed to ask on this forum. I am trying to study how the time calibration of the DRS is done. Can you point me to the script in which this is done?
Thank you,
Christian
Stefan Ritt wrote: |
The web page from where you downloaded the software contains a sentence "requires libusb-1.0 package". Please install it. This package brings the "usb.h" header file.
Stefan
Christian Farina wrote: |
Hello everybody,
I am completely new to this, so please bear with me.
I am trying to install the applications on my laptop. I downloaded and untar-ed the drivers and applications for Linux as described in the evaluation board manual. However, when I do the make, I get the following error:
drs-4.0.0$ make
g++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -DOS_LINUX -DHAVE_LIBUSB -DUSE_DRS_MUTEX -c src/musbstd.c
In file included from src/musbstd.c:14:0:
include/musbstd.h:17:17: fatal error: usb.h: No such file or directory
#include <usb.h>
Can anybody help me please?
Thanks.
|
|
|
|
|
269
|
Fri Jul 5 12:46:45 2013 |
Hermann-Josef Mathes | Missing methods in drs-4.0.1.tar.gz | Hi,
while trying to create python bindings for the DRS stuff using SWIG 2.0.4, two undefined methods prevent the python interpreter from loading the generated shared library. These methods are:
- int DRSBoard::SetADCActive(unsigned char)
- bool ResponseCalibration::Calibrate(unsigned int,unsigned int,float *,float *,float,bool)
Can we safely removed those methods from the DRS header files or (what I have actually done) is it better to fake some empty implementation in the input file to SWIG?
Another minor issue is that the python interpreter always terminates with a SegFault after script termination. I had not yet time to track that down...
Thanks & regards
Hermann-Josef
|
270
|
Sat Jul 6 06:10:38 2013 |
Stefan Ritt | Missing methods in drs-4.0.1.tar.gz |
Hermann-Josef Mathes wrote: |
Hi,
while trying to create python bindings for the DRS stuff using SWIG 2.0.4, two undefined methods prevent the python interpreter from loading the generated shared library. These methods are:
- int DRSBoard::SetADCActive(unsigned char)
- bool ResponseCalibration::Calibrate(unsigned int,unsigned int,float *,float *,float,bool)
Can we safely removed those methods from the DRS header files or (what I have actually done) is it better to fake some empty implementation in the input file to SWIG?
Another minor issue is that the python interpreter always terminates with a SegFault after script termination. I had not yet time to track that down...
Thanks & regards
Hermann-Josef
|
Thanks for pointing that out. My C++ compiler does not complain about such errors. You can safely remove these functions. I did so as well, so future versions will not contain that any more.
/Stefan |
706
|
Thu Jun 28 19:55:45 2018 |
Woon-Seng Choong | Negative Bin Width | I am using a DRS4 Evaluation Board v5 and running the drsosc.exe version 5.06 on a Window 7 machine. I have performed the voltage and timing calibration.
With test pulses on channel 1 and 2, I collected binary data file with all 4 channels active sampling at 5GSPS.
Attached is a distribution of the bin_width vs. cell # for all the 4 channels. Note that there are few cells with bin_width < 10 ps.
Channel 1: bin_width[498] = -0.000348, bin_width[1010]= -0.000348
Channel 2: bin_width[498] = 0.007363
Channel 3: bin_width[498] = 0.007843
Channel 4: bin_width[498] = 0.005948
Is this normal? How can you get negative bin_width? What does negative bin_width means?
I have attached the binary data file for your verification.
|
Attachment 1: bin_width_5gsps.jpg
|
|
Attachment 2: test5gsps.dat
|
707
|
Fri Jun 29 07:51:33 2018 |
Stefan Ritt | Negative Bin Width | Yes that's normal. A negative cell bin width means that the next cell N+1 samples the input signal before cell N. This can happen due to the signal routing on the DRS4 chip.
Stefan
Woon-Seng Choong wrote: |
I am using a DRS4 Evaluation Board v5 and running the drsosc.exe version 5.06 on a Window 7 machine. I have performed the voltage and timing calibration.
With test pulses on channel 1 and 2, I collected binary data file with all 4 channels active sampling at 5GSPS.
Attached is a distribution of the bin_width vs. cell # for all the 4 channels. Note that there are few cells with bin_width < 10 ps.
Channel 1: bin_width[498] = -0.000348, bin_width[1010]= -0.000348
Channel 2: bin_width[498] = 0.007363
Channel 3: bin_width[498] = 0.007843
Channel 4: bin_width[498] = 0.005948
Is this normal? How can you get negative bin_width? What does negative bin_width means?
I have attached the binary data file for your verification.
|
|
509
|
Thu Apr 21 22:16:43 2016 |
Kyle Weinfurther | Negative fCellDT values from GetTimeCalibration() | Hello Stefan,
I am using four DRS4 v5 eval boards to digitize 16 channels of data. I have recently changed from saving the timing information of the waveform using GetTime() to GetTimeCalibration(). When changing over, I noticed that some values for fCellDT for cell 498 are negative. Over the 16 channels used, 4 of them have negative time bin widths for cell 498 while the other 12 channels are very close to 0 (in the ~10 ps range). One of the eval boards has no negative fCellDT whereas the other three boards have one or two channels with negative values.
Upon further inspection, I checked the time between samples of GetTime() and found the same results in cell 498. After finding this, I did a timing calibration again with CalibrateTiming() even though in a different post on the discussion forum you said it was valid for a wide range of temperatures and a long time (years). This still allowed the negative fCellDT values to persist.
Is this a common occurance? If so, is there a method to fix this issue? Is there a reason for cell 498 to have a small value for fCellDT? I searched the discussion forum and did not find anything relating to this issue.
Attached are a couple waveform traces using GetTime() zoomed in on cell 498.
Thanks,
Kyle Weinfurther |
Attachment 1: ch5.png
|
|
Attachment 2: ch7.png
|
|
Attachment 3: ch9.png
|
|
|