ID![up up](up.png) |
Date |
Author |
Subject |
858
|
Tue Jan 25 14:15:00 2022 |
Thomas M. | Regarding measuring for a set time | Hello,
I'm working on a project wherein we're looking at photomultipliers. We've already acquired a DRS4 evaluation board with the intent of using it to gather our data.
I've looked at the source code for the software with the intent of maybe writing a patch to add additional functionality. I was hoping you could answer some quick questions in that regard.
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?
Appreciate any help you can provide. Thanks!
Kind regards,
Thomas
|
859
|
Tue Jan 25 14:34:42 2022 |
Stefan Ritt | Regarding 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?
|
|
860
|
Tue Jan 25 14:44:49 2022 |
Thomas M. | Regarding measuring for a set time | Yes, you've got it exactly right. Thank you, that helps a lot!
Thomas
Stefan Ritt wrote: |
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?
|
|
|
861
|
Wed Jan 26 06:44:11 2022 |
student_riku | I want to know about the readout | Dear Stefan
Thanks a lot.
I solved it.
Stefan Ritt wrote: |
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
|
|
862
|
Sat Feb 12 13:06:56 2022 |
Matias Senger | Cannot trigger on pulses, have to trigger on undershoot | I am using the DRS4 board trying to measure pulses produced by an LGAD. I have no prior experience with this board, have just installed the `drsosc` application and am exploring. I am experiencing some strange trigger behavior. Consider the following screenshot:
![](https://i.ibb.co/p1Fx37P/photo-2022-02-12-13-12-35.jpg)
Here nothing is strange, the board is triggering on the undershoot and it is working fine, I can trigger on rising/falling edge, different levels, etc.
Now, the strange thing is that if I pull the trigger up to trigger on the pulse itself it stops triggering:
![](https://i.ibb.co/L02mqQz/photo-2022-02-12-13-14-17.jpg)
I have tried many different setups for the trigger (rising, falling edge, different levels, etc) and nothing works. In the undershoot, everything works.
I have tried with the internal test signal and it works fine:
![](https://i.ibb.co/TmZnL3F/photo-2022-02-12-13-14-18.jpg)
What could be the problem?
I have run the voltage and time calibrations as suggested in the manual. |
863
|
Tue Feb 15 11:59:22 2022 |
Alex Myczko | apt install drs4eb | drs4b is now officially on these distributions:
https://repology.org/project/drs4eb/versions
enjoy |
864
|
Tue Feb 15 12:02:29 2022 |
Stefan Ritt | Cannot 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 |
865
|
Wed Feb 16 14:06:45 2022 |
Dmitry Hits | Sliders missing in drsosc | Hi everyone,
Did anyone have a "missing sliders problem" in GUI (see attachment) accompanied by the following message in the terminal.
(drsosc:4611): Gtk-WARNING **: 14:05:11.249: Negative content width -4 (allocation 20, extents 12x12) while allocating gadget (node scale, owner GtkScale)
(drsosc:4611): Gtk-WARNING **: 14:05:11.249: Negative content width -2 (allocation 0, extents 1x1) while allocating gadget (node trough, owner GtkScale)
If yes, how did you solve it?
All ideas are appreciated!
Cheers,
Dmitry
|
Attachment 1: Screen_Shot_2022-02-14_at_14.17.30.png
|
|
866
|
Tue Mar 1 19:03:37 2022 |
Keita Mizukoshi | Scaler issue to evaluate live time | 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? |
867
|
Wed Mar 2 17:25:10 2022 |
Matias Senger | How to convert samples to volt? | 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
``` |
868
|
Thu Mar 3 13:47:26 2022 |
Stefan Ritt | How 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 Ritt | Scaler 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?
|
|
870
|
Fri Mar 4 03:55:33 2022 |
Keita Mizukoshi | Scaler issue to evaluate live time | 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: pulse_example.png
|
|
Attachment 2: rate.png
|
|
871
|
Sun Mar 6 17:54:47 2022 |
Matias Senger | Why does not trigger at higher sampling frequencies? | I have connected 3 signals to the DRS4 Evaluation Board V5 which look like this in the drsosc app:
![](https://i.ibb.co/M7w5r1R/Screenshot-2022-03-06-17-45-38.png)
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:
![](https://i.ibb.co/nbbW5nx/Screenshot-2022-03-06-18-06-09.png)
![](https://i.ibb.co/B2pCW2j/Screenshot-2022-03-06-18-06-18.png)
![](https://i.ibb.co/1Qq4KXz/Screenshot-2022-03-06-18-06-26.png)
![](https://i.ibb.co/dD9ZXxJ/Screenshot-2022-03-06-18-06-37.png)
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. |
872
|
Mon Mar 7 08:45:32 2022 |
Stefan Ritt | Why 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 |
873
|
Mon Mar 7 13:38:03 2022 |
Radoslaw Marcinkowski | Problems with DRS4 Evaluation Board after Windows 10 upgrade - share of experiences | Dear DRS4 Users,
I would like to share my expireinces with using of DRS4 Evaluation Board software (oscilloscope) after upgrade of Windows 10.
I had Windows 10 (Enterprise) in version from ~2016. It was working fine with DRS4 Scope software. Due to the company policy, Windows was upgraded to the newer version (2019). Since this time the board was not recognized any more as DRS4 Evaluation Board, both by Windows and DRS4 Scope standard software. Changing USB sockets did not help at all. I installed once more time Zadig USB driver (suggested by https://www.psi.ch/en/drs/software-download), no Admistrator rights were needed. It took long time, about 10 minutes or more, it suggested restart in the meantime, and finally noticed that ... installation failed! Even that, DRS4 software started to recognize the board without the problem even without reboot. Let me notice that all users on this machine can use the DRS4 software even if installation was done by non-administrator user.
Regards,
Radek |
874
|
Mon Mar 7 16:37:54 2022 |
Stefan Ritt | Scaler 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
|
|
Attachment 2: Screenshot_2022-03-07_at_16.35.44_.png
|
|
875
|
Tue Mar 8 00:25:56 2022 |
Matias Senger | Why does not trigger at higher sampling frequencies? | I have seen in the app that the trigger source buttons do something different than the "or" and "transparent trigger" buttons:
![](https://i.ibb.co/QQPr39z/Screenshot-2022-03-08-00-25-05.png)
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.
Stefan Ritt wrote: |
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
|
|
876
|
Tue Mar 8 12:20:00 2022 |
Matias Senger | Why does not trigger at higher sampling frequencies? | 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.
Matias Senger wrote: |
I have seen in the app that the trigger source buttons do something different than the "or" and "transparent trigger" buttons:
![](https://i.ibb.co/QQPr39z/Screenshot-2022-03-08-00-25-05.png)
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.
Stefan Ritt wrote: |
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
|
|
|
877
|
Fri Mar 11 17:26:15 2022 |
Matias Senger | Time calibration and the C++ API | 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:
![](https://i.ibb.co/gdBLvLB/Screenshot-2022-03-11-17-49-55.png)
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! |
|