ID |
Date |
Author |
Subject |
488
|
Thu Mar 31 19:35:06 2016 |
Stefan Ritt | Trigger on the And of a positive and negative signal | No. You have to use an inverter for one of your signals.
Stefan
Abaz Kryemadhi wrote: |
I would like to be able to trigger in this fashon: channel 0 > 0.1 and. channel 1< -0.1, because I have a positive and a negative signal. Can DRS4 (5) Eval board do this kind of trigger?
Thanks!
Abaz
|
|
487
|
Thu Mar 31 19:30:26 2016 |
Abaz Kryemadhi | Trigger on the And of a positive and negative signal | I would like to be able to trigger in this fashon: channel 0 > 0.1 and. channel 1< -0.1, because I have a positive and a negative signal. Can DRS4 (5) Eval board do this kind of trigger?
Thanks!
Abaz |
486
|
Tue Mar 22 12:54:41 2016 |
Stefan Ritt | | Yes this is correct. But it is a sample-and-hold circuit. So the sampling cell follows the input for 3.2 ns, then samples and holds the current value at the end of the period.
Dominik Neise wrote: |
Hello Stefan,
I just stumbled again over a phrase in the DRS4 datasheet I never really understood, but didn't find the time to ask.
On page 8 it says: "An internal circuit ensures that the write signal is always 16 cells wide."
So when I look at a single channel, do I understand correctly, that at any given time during sampling, always 16 cells are open, i.e. 16 cells are connected to the analog inputs? So when the domino frequency is e.g. 5GHz then each cell sees the analog input not for 200ps but for 3.2ns correct?
|
|
485
|
Mon Mar 21 10:38:27 2016 |
Daniel Dribin | DRS Oscilloscope freezing after a long run | Dear Stefan Ritt,
I am using a DRS4 v5 to do timing measurements of Positron lifetime. I use the DRS Oscilloscope with triggering on 2 channels when I have a coincidence. Attached is a picture with all the setting that I use. When I use the DRS4 for a long measurements of 5 million events for a couple of hours, the DRS Oscilloscope stops showing any signal .After the first restart of the program I get a strange signal which is at the bottom of the scope range of voltage picture below(in the picture I changed the vertical positions of the channels for better viewing). Only after a couple of DRS Oscilloscope restarts and USB reconnections do I get the results again.
I currently am using another DRS4 v5 and the same situation occurs again although with lower frequency.
What can I do to solve this problem?
thank you very much,
Daniel
|
484
|
Fri Mar 11 19:50:18 2016 |
Dominik Neise | | Hello Stefan,
I just stumbled again over a phrase in the DRS4 datasheet I never really understood, but didn't find the time to ask.
On page 8 it says: "An internal circuit ensures that the write signal is always 16 cells wide."
So when I look at a single channel, do I understand correctly, that at any given time during sampling, always 16 cells are open, i.e. 16 cells are connected to the analog inputs? So when the domino frequency is e.g. 5GHz then each cell sees the analog input not for 200ps but for 3.2ns correct? |
483
|
Wed Mar 9 09:57:20 2016 |
Christian D | LabView | Hi,
I would like to use the DRS4 board with LabView for fast readout.
Do you know anyone who has written a VI for that?
Thanks,
Christian |
482
|
Mon Feb 29 14:09:21 2016 |
Stefan Ritt | two DRS4 boards configuration with 2048 samples each | The multi-board mode has never been tested with 2048 samples, so is very likely not to work. I don't know yet how much work this will be to fix, but I'm on a business trip the next three weeks and probably will only have time to look at it when I return.
Stefan
Dmitry Hits wrote: |
Dear Stefan,
I daisy-chained two boards (master sn#: 2514 - slave sn#: 2513) each with 2048 samples. However, when I use drsosc and put check mark in "configure multi-board daisy-chain" I see only 1024 samples. Namely, the first 1024 samples, the last part is missing. When I remove this check mark, I see all 2048 samples. Is there a simple software fix for this or is it a more involved firmware limitation?
Other parameters: software version: 5.0.4, firmware version 21305, configured for 0.7 GSPS, display at 500 ns/div
Thank you,
Dmitry Hits.
|
|
481
|
Mon Feb 29 13:33:06 2016 |
Dmitry Hits | two DRS4 boards configuration with 2048 samples each | Dear Stefan,
I daisy-chained two boards (master sn#: 2514 - slave sn#: 2513) each with 2048 samples. However, when I use drsosc and put check mark in "configure multi-board daisy-chain" I see only 1024 samples. Namely, the first 1024 samples, the last part is missing. When I remove this check mark, I see all 2048 samples. Is there a simple software fix for this or is it a more involved firmware limitation?
Other parameters: software version: 5.0.4, firmware version 21305, configured for 0.7 GSPS, display at 500 ns/div
Thank you,
Dmitry Hits. |
480
|
Mon Feb 29 13:09:29 2016 |
Stefan Ritt | baseline shift | The baseline shift comes from some instable power supply inside the evaluation board which cannot be controlled to the mV level. In a real measurement, you usually get an additional baseline shift due to some environmental electromagnetic interferences, such as a 50 Hz signal. People fix this shifting baseline by always aquiring a small portion (10-20 samples) of the baseline before any signal from a particle detector. The signal is then corrected event-by-event by subtracting the baseline from each waveform. By doing that, you fix not only the 50 Hz noise, but also the shifting baseline you mention.
Stefan
Dmitry Philippov wrote: |
Hello! My name is Dmitry. I am from SiPM Lab is NRNU MEPhI (Russia, Moscow). We bought DRS4 evaluation board V5 with firmware 21305. We use 5.0.4 build 21911 2015-11-23 software version (and before that we used 5.0.3 build 21508, 2014-10-15) with Windows 7 32bit.
We observe some strange behaviour. When we save waveforms (in xml or binary data) we see that some of them have the baseline shifted of about -5 mV.
The first picture (pic1) is 1000 waveforms which were glued in one. It is clearly see that baseline quite often has the shift.
The same effect can be seen without saving (writting): rarely when we use normal or auto trigger mode (pic3), and always in single trigger mode (pic2).
The images are attached.
Do you have any idea how it can be fixed?
Thanks, Dmitry.
|
|
479
|
Mon Feb 29 12:58:17 2016 |
Dmitry Philippov | baseline shift | Hello! My name is Dmitry. I am from SiPM Lab is NRNU MEPhI (Russia, Moscow). We bought DRS4 evaluation board V5 with firmware 21305. We use 5.0.4 build 21911 2015-11-23 software version (and before that we used 5.0.3 build 21508, 2014-10-15) with Windows 7 32bit.
We observe some strange behaviour. When we save waveforms (in xml or binary data) we see that some of them have the baseline shifted of about -5 mV.
The first picture (pic1) is 1000 waveforms which were glued in one. It is clearly see that baseline quite often has the shift.
The same effect can be seen without saving (writting): rarely when we use normal or auto trigger mode (pic3), and always in single trigger mode (pic2).
The images are attached.
Do you have any idea how it can be fixed?
Thanks, Dmitry.
|
478
|
Tue Feb 16 11:55:54 2016 |
Martin Petriska | Saving histogram data |
Robert Adams wrote: |
I would really love to be able to save histogram data, though I have not been able to do this. I could take a screenshot and extract the data from an image, but would prefer to avoid this if there is a simpler way... possibly I have overlooked something obvious? Thanks very much for any advice or tips.
|
You can use qtpals, there is posibility to save histograms (energy, time diference), only set trigger on channel which you use. https://sourceforge.net/projects/qtpals/files/?source=navbar |
477
|
Tue Feb 16 11:21:43 2016 |
Stefan Ritt | Saving histogram data | There is no histogram save functoinality in ther DRSOscilloscope program - on purpose. The board and the software are meant to evaluate the board, not to replace a full DAQ system. If we want to save histograms, you maybe also want to set the range, make cuts, do fits etc. So it would take lots of resources to add all that. Therefore we recommend to use the stand-alone C program drs_exam.cpp to read the board, the you can either do whatever you want in the C program, including saving of histograms. Alternatively, you can use ROOT to analyze binary stored DRS data and do whatever histogram manipulation you want there.
Stefan
Robert Adams wrote: |
I would really love to be able to save histogram data, though I have not been able to do this. I could take a screenshot and extract the data from an image, but would prefer to avoid this if there is a simpler way... possibly I have overlooked something obvious? Thanks very much for any advice or tips.
|
|
476
|
Fri Jan 15 08:09:00 2016 |
Stefan Ritt | Triggering of DRS4 in the fastest sampling mode | Hi Chris,
if you ever used an oscilloscope, you might be familar with the button controlling the riger in respect to "risign edge" vs. "falling edge". I copied the same for the DRS software. So just click on that button:

and you will get what you want. Also the AND/OR gets reversed this way. If you select rising edge (default), the AND will be made if both signals are ABOVE the threshold, that's why it does not work for you. If you select falling edge, the AND will be made if both signals are BELOW the threshold. For negative pulses you need falling edge.
Stefan
Chris Thompson wrote: |
I am attempting to use the DRS4 to measure the timing resolution of a pair of SensL silicon photomultipliers (SiPM). In order to do this I need to trigger the DRS4 only when there is a coincidence between the two input signals, and hopefully make histograms of the relative detection times of each detector.
There are two completely separate issues. (1) I think this may just be a labelling error. In the first image (OR_mode_selected) one can clearly see two pulses which are very similar. In this mode, both signals are present, and are always present. I think this should be the "AND", not "OR" of the two signals. Contrast this with the second image where I have selected "AND_mode". Clearly only one signal is present, and either signal trigges an event, so this should be "OR", not "AND"
The second issue is, for me, much more serious. I want to sample the leading edge of this event in order to determine its "time". The little "T" at the top of each image is, I believe the "trigger point" in the first two images. However, this is well after the part of the signal I am interested in. The first two images were at 2 GigaSamples/sec. The third is at 5 GigaSamples/sec. Clearly the event I am interested in processing is over by then. At the lower sampling rate, I can see well before the "T", but at the higher one I can only see after the "T". I had built an external "coincidence circuit" and the "external trigger mode" hoping to to circumvent this issue by using very long cables to delay the signals inut to the DRS4, But even then I have not been successful in getting the to work.
I am using version 5.0.3 on a PC as the version released after that did not work.
I hope some can help!
Chris Thompson
|
|
475
|
Thu Jan 14 21:49:37 2016 |
Chris Thompson | Triggering of DRS4 in the fastest sampling mode | I am attempting to use the DRS4 to measure the timing resolution of a pair of SensL silicon photomultipliers (SiPM). In order to do this I need to trigger the DRS4 only when there is a coincidence between the two input signals, and hopefully make histograms of the relative detection times of each detector.
There are two completely separate issues. (1) I think this may just be a labelling error. In the first image (OR_mode_selected) one can clearly see two pulses which are very similar. In this mode, both signals are present, and are always present. I think this should be the "AND", not "OR" of the two signals. Contrast this with the second image where I have selected "AND_mode". Clearly only one signal is present, and either signal trigges an event, so this should be "OR", not "AND"
The second issue is, for me, much more serious. I want to sample the leading edge of this event in order to determine its "time". The little "T" at the top of each image is, I believe the "trigger point" in the first two images. However, this is well after the part of the signal I am interested in. The first two images were at 2 GigaSamples/sec. The third is at 5 GigaSamples/sec. Clearly the event I am interested in processing is over by then. At the lower sampling rate, I can see well before the "T", but at the higher one I can only see after the "T". I had built an external "coincidence circuit" and the "external trigger mode" hoping to to circumvent this issue by using very long cables to delay the signals inut to the DRS4, But even then I have not been successful in getting the to work.
I am using version 5.0.3 on a PC as the version released after that did not work.
I hope some can help!
Chris Thompson |
474
|
Thu Jan 14 14:11:06 2016 |
Stefan Ritt | Dtap stops toggling after 40msec | Thanks for the update, I will add a note into the data sheet.
mony orbach wrote: |
surrey i forgot to update..
after carefully examining our VHDL we found out that there are brief times that we put A0-A3 in 1111
after making shore that a0-a3 never get 1111 value thae drs4 woks as expected.
The dtap toggols ok.
We can sample and read all the data channels.
So, putting A0-A3 value of 1111 even for very short period " confuse " the DRS and then it start to behave in a strange manner.
mony
Stefan Ritt wrote: |
While I can understand 1., I'm puzzeled by 2.
If you put the chip in standby mode, the internal current sources are switched off, which of course make the domino wave non-functional. This is clearly stated in the data sheet.
Concerning the DMODE bit, we operate all (!) our chips with DMODE=1. Actually this is the default value. After a reset, all register bits are "1", which enables the PLL and causes DTAP to oscillate. If DMODE=1, the DTAP signal should toggle only once (!) since the domino loop is not closed. So the scope traces you showed previously are consistent with the standby mode, but not possible with ANY setting of DMODE.
Stefan
mony orbach wrote: |
Hi
We have resolve the problem, the Dtap is now working correctly.
There were two problems:
- After configuration we put the all address bits to one (standby mode)
We are now setting the address bits to all zero. Failure
to do so result in Dtap stop toggling after several hundred milliseconds.
- The DMODE bit in contradiction to the data sheet should be set to 0
And not to 1.
Is this a known bug in the chip?
Only bay setting DMODE to zero we got the Dtap to work correctly.
The PLL locks after 1 milisec.
If we set it to one we get Dtap that stop toggling after several hundred milliseconds.
We have test it on two boards, they both worked in the same.
Never did we get a One shot Dtap.
Did you published a errata page to the drs4?
Thanks, Mony
|
|
|
|
473
|
Thu Jan 14 14:00:26 2016 |
mony orbach | Dtap stops toggling after 40msec | surrey i forgot to update..
after carefully examining our VHDL we found out that there are brief times that we put A0-A3 in 1111
after making shore that a0-a3 never get 1111 value thae drs4 woks as expected.
The dtap toggols ok.
We can sample and read all the data channels.
So, putting A0-A3 value of 1111 even for very short period " confuse " the DRS and then it start to behave in a strange manner.
mony
Stefan Ritt wrote: |
While I can understand 1., I'm puzzeled by 2.
If you put the chip in standby mode, the internal current sources are switched off, which of course make the domino wave non-functional. This is clearly stated in the data sheet.
Concerning the DMODE bit, we operate all (!) our chips with DMODE=1. Actually this is the default value. After a reset, all register bits are "1", which enables the PLL and causes DTAP to oscillate. If DMODE=1, the DTAP signal should toggle only once (!) since the domino loop is not closed. So the scope traces you showed previously are consistent with the standby mode, but not possible with ANY setting of DMODE.
Stefan
mony orbach wrote: |
Hi
We have resolve the problem, the Dtap is now working correctly.
There were two problems:
- After configuration we put the all address bits to one (standby mode)
We are now setting the address bits to all zero. Failure
to do so result in Dtap stop toggling after several hundred milliseconds.
- The DMODE bit in contradiction to the data sheet should be set to 0
And not to 1.
Is this a known bug in the chip?
Only bay setting DMODE to zero we got the Dtap to work correctly.
The PLL locks after 1 milisec.
If we set it to one we get Dtap that stop toggling after several hundred milliseconds.
We have test it on two boards, they both worked in the same.
Never did we get a One shot Dtap.
Did you published a errata page to the drs4?
Thanks, Mony
|
|
|
472
|
Tue Jan 12 21:02:31 2016 |
Stefan Ritt | Compiling DRS-exam | I guess you are compiling under MS Windows ??? You probably don't link correctly to the USB lib. Try to compile the examples coming with libusb-1.0 to make you everything is right there.
Jack Bargemann wrote: |
I am trying to compile drs-exam, but am getting an error message I do not understand:
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_open referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_close referenced in function _musb_close
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_get_descriptor referenced in function _musb_get_device
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_bulk_write referenced in function _musb_write
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_bulk_read referenced in function _musb_read
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_set_configuration referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_claim_interface referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_release_interface referenced in function _musb_close
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_set_altinterface referenced in function _musb_set_altinterface
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_reset referenced in function _musb_reset
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_init referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_set_debug referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_find_busses referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_find_devices referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_get_busses referenced in function _musb_open
I have tried redownloading a different version of libusb-1.0, but the problem was not solved. What might I be doing wrong?
|
|
471
|
Tue Jan 12 17:57:03 2016 |
Jack Bargemann | Compiling DRS-exam | I am trying to compile drs-exam, but am getting an error message I do not understand:
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_open referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_close referenced in function _musb_close
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_get_descriptor referenced in function _musb_get_device
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_bulk_write referenced in function _musb_write
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_bulk_read referenced in function _musb_read
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_set_configuration referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_claim_interface referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_release_interface referenced in function _musb_close
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_set_altinterface referenced in function _musb_set_altinterface
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_reset referenced in function _musb_reset
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_init referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_set_debug referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_find_busses referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_find_devices referenced in function _musb_open
1>musbstd.obj : error LNK2019: unresolved external symbol _usb_get_busses referenced in function _musb_open
I have tried redownloading a different version of libusb-1.0, but the problem was not solved. What might I be doing wrong? |
470
|
Tue Jan 12 16:06:07 2016 |
Stefan Ritt | Use of Channel Cascading in drs_exam.cpp | Hi Larry,
sorry my late reply, swamped with work here. You were right in the modifictions you did, congrats. The speed limitation of 500 events come from USB2, which simply is not fast enough. The 500 Hz are mentioned on the evaluation board web site, so you should have seen that before ordering. Some people build their own hardware around the chip, in which case they get higher rates. The "hard" limit is the DRS4 readout speed, which is 30ns per sample. So if you have 8 ADCs in parallel, and you only need 100 samples of your waveform, the readout time is 3 us, in which case you could go up to a few 10 kHz without much of a dead time.
Cheers,
Stefan
Larry Byars wrote: |
An update. I have been successful in making modifications to drs_exam.cpp so that I can get 2048 samples per channel.. The main changes were to the size of the time_array and wave_array and adding a call to Set ChannelConfig(0,8,4). It was also necessary to change the parameters to GetWave so that the Trigger Cell and WSR values were passed to get the channel combinations correct (2048 channel.ppt).
I've moved on to try to increase the speed of acquisition (I get only about 500 events/sec) and trying to understand the corrections.Working through the source code slowly...
Regards,
Larry Byars
Larry Byars wrote: |
Hello Stefan,
Here in Rockford, TN we just got a new DRS4 evaluation board (Serail # 2612, Board Type 9, Firmware 21305) which is labeled as combined 2048.
It looks like the drs_exam.cpp only works with 1024 samples per channel. We'd like to be able to get 2048 samples from each of the four channels but I am uncertain what code modifications are necessary support this.
Could you offer a suggestion? I've searched the forum for cascade and read several threads but they are pretty old. One even says it isn't supported in the evaluation board, but I think that is no longer the case.
Thanks for your help,
Larry Byars
|
|
|
469
|
Tue Jan 12 15:42:31 2016 |
Larry Byars | Use of Channel Cascading in drs_exam.cpp | An update. I have been successful in making modifications to drs_exam.cpp so that I can get 2048 samples per channel.. The main changes were to the size of the time_array and wave_array and adding a call to Set ChannelConfig(0,8,4). It was also necessary to change the parameters to GetWave so that the Trigger Cell and WSR values were passed to get the channel combinations correct (2048 channel.ppt).
I've moved on to try to increase the speed of acquisition (I get only about 500 events/sec) and trying to understand the corrections.Working through the source code slowly...
Regards,
Larry Byars
Larry Byars wrote: |
Hello Stefan,
Here in Rockford, TN we just got a new DRS4 evaluation board (Serail # 2612, Board Type 9, Firmware 21305) which is labeled as combined 2048.
It looks like the drs_exam.cpp only works with 1024 samples per channel. We'd like to be able to get 2048 samples from each of the four channels but I am uncertain what code modifications are necessary support this.
Could you offer a suggestion? I've searched the forum for cascade and read several threads but they are pretty old. One even says it isn't supported in the evaluation board, but I think that is no longer the case.
Thanks for your help,
Larry Byars
|
|
|