ID |
Date |
Author |
Subject |
740
|
Wed Feb 20 12:56:56 2019 |
Stefan Ritt | meg? | No idea. Maye some access problem. Have you tried to start your program under an admin account?
Stefan
Lev Pavlov wrote: |
Great, drs_exam compiles without problems. Now when you run the compiled file drs_exam writes board not found, but drsosc and drscl work without problems. What could possibly be the matter?
thanks for your patience
Lev
Stefan Ritt wrote: |
You have to change the path to libusb-1.0.lib to the one where you installed it.
Stefan
Lev Pavlov wrote: |
Hey. Strange problem. Why does the compiler refer there at all? Library installed drsosc works
LINK : fatal error LNK1104: cannot open file "C:\meg\online\drivers\drs\libusb-1.0\libusb-1.0.lib"
|
|
|
|
739
|
Wed Feb 20 12:13:44 2019 |
Lev Pavlov | meg? | Great, drs_exam compiles without problems. Now when you run the compiled file drs_exam writes board not found, but drsosc and drscl work without problems. What could possibly be the matter?
thanks for your patience
Lev
Stefan Ritt wrote: |
You have to change the path to libusb-1.0.lib to the one where you installed it.
Stefan
Lev Pavlov wrote: |
Hey. Strange problem. Why does the compiler refer there at all? Library installed drsosc works
LINK : fatal error LNK1104: cannot open file "C:\meg\online\drivers\drs\libusb-1.0\libusb-1.0.lib"
|
|
|
738
|
Wed Feb 20 08:08:42 2019 |
Stefan Ritt | meg? | You have to change the path to libusb-1.0.lib to the one where you installed it.
Stefan
Lev Pavlov wrote: |
Hey. Strange problem. Why does the compiler refer there at all? Library installed drsosc works
LINK : fatal error LNK1104: cannot open file "C:\meg\online\drivers\drs\libusb-1.0\libusb-1.0.lib"
|
|
737
|
Wed Feb 20 08:03:04 2019 |
Lev Pavlov | meg? | Hey. Strange problem. Why does the compiler refer there at all? Library installed drsosc works
LINK : fatal error LNK1104: cannot open file "C:\meg\online\drivers\drs\libusb-1.0\libusb-1.0.lib" |
736
|
Mon Feb 4 18:18:22 2019 |
Stefan Ritt | Different Distances between the sampling points | elog:361
Hans Steiger wrote: |
Sorry.... but is there a solution or a Root Macro, that reads the waveforms into a Root-Tree? I simply can not work anymore with the data.
Can you tell me, which software was in use in early 2017?
All the best,
Hans
Stefan Ritt wrote: |
The sampling points are NOT equidestant, they have varying bin widths of 150ps to 250ps at 5GS/s. That's due the way the DRS4 chip works. You might have neglected that fact in the past, but that would have led to poor timing resolutions (typically 1-2ns resolution only). To get bins with the same width, you have to treat your waveform as a real X/Y points (or better U/T), and the re-sample that cure, maybe spline-interpolated, at 200ps bins.
Stefan
Hans Steiger wrote: |
Dear All,
with the older software for my V5 Board i did not have the problem, that the distance between the sampling points (in time) is not the same (e.g. a sampling point all 200ps for 5GS/s).
How can i fix this?
Can someone provide me the software for the board which is old enough to not have this problem. All my Root interpreters produce problems with this new data format. Which version would be old enough?
All the best and thanks a lot,
Hans
|
|
|
|
735
|
Mon Feb 4 17:36:49 2019 |
Hans Steiger | Different Distances between the sampling points | Sorry.... but is there a solution or a Root Macro, that reads the waveforms into a Root-Tree? I simply can not work anymore with the data.
Can you tell me, which software was in use in early 2017?
All the best,
Hans
Stefan Ritt wrote: |
The sampling points are NOT equidestant, they have varying bin widths of 150ps to 250ps at 5GS/s. That's due the way the DRS4 chip works. You might have neglected that fact in the past, but that would have led to poor timing resolutions (typically 1-2ns resolution only). To get bins with the same width, you have to treat your waveform as a real X/Y points (or better U/T), and the re-sample that cure, maybe spline-interpolated, at 200ps bins.
Stefan
Hans Steiger wrote: |
Dear All,
with the older software for my V5 Board i did not have the problem, that the distance between the sampling points (in time) is not the same (e.g. a sampling point all 200ps for 5GS/s).
How can i fix this?
Can someone provide me the software for the board which is old enough to not have this problem. All my Root interpreters produce problems with this new data format. Which version would be old enough?
All the best and thanks a lot,
Hans
|
|
|
734
|
Mon Feb 4 16:46:04 2019 |
Stefan Ritt | Different Distances between the sampling points | The sampling points are NOT equidestant, they have varying bin widths of 150ps to 250ps at 5GS/s. That's due the way the DRS4 chip works. You might have neglected that fact in the past, but that would have led to poor timing resolutions (typically 1-2ns resolution only). To get bins with the same width, you have to treat your waveform as a real X/Y points (or better U/T), and the re-sample that cure, maybe spline-interpolated, at 200ps bins.
Stefan
Hans Steiger wrote: |
Dear All,
with the older software for my V5 Board i did not have the problem, that the distance between the sampling points (in time) is not the same (e.g. a sampling point all 200ps for 5GS/s).
How can i fix this?
Can someone provide me the software for the board which is old enough to not have this problem. All my Root interpreters produce problems with this new data format. Which version would be old enough?
All the best and thanks a lot,
Hans
|
|
733
|
Mon Feb 4 16:42:08 2019 |
Hans Steiger | Different Distances between the sampling points | Dear All,
with the older software for my V5 Board i did not have the problem, that the distance between the sampling points (in time) is not the same (e.g. a sampling point all 200ps for 5GS/s).
How can i fix this?
Can someone provide me the software for the board which is old enough to not have this problem. All my Root interpreters produce problems with this new data format. Which version would be old enough?
All the best and thanks a lot,
Hans |
732
|
Sat Feb 2 10:10:22 2019 |
Stefan Ritt | Saving Rate (only 15Acq/s) | The reduction of rate is because you save in XML format, which is an ASCII format, so human readable, but takes long to write. If you switch to binary format and write on a decent fast hard disk, you should get back to 450 Acq/s.
Stefan
Hans Steiger wrote: |
Dear All,
when I use my Evaluation Board with some PMTs I can digitize 450 Acq/s or so. But when I want to save the waveforms the rate goes down. The Acqu. rate with saving is in the range of 14Hz up to 24 Hz.
I normally use the .txt file. I try to use the 5GS/s but also with much lower sampling rate the saving rate is not getting much better.
Is this a problem of my McBook connected to the Evaluation Board?
All the best,
Hans
|
|
731
|
Sat Feb 2 00:13:12 2019 |
Hans Steiger | Saving Rate (only 15Acq/s) | Dear All,
when I use my Evaluation Board with some PMTs I can digitize 450 Acq/s or so. But when I want to save the waveforms the rate goes down. The Acqu. rate with saving is in the range of 14Hz up to 24 Hz.
I normally use the .txt file. I try to use the 5GS/s but also with much lower sampling rate the saving rate is not getting much better.
Is this a problem of my McBook connected to the Evaluation Board?
All the best,
Hans |
730
|
Wed Jan 30 17:08:58 2019 |
Stefan Ritt | ROOT Macro for data acquired with the newest software | This one elog:361 should still work.
Stefan
Abaz Kryemadhi wrote: |
Hello,
Is there a root macro for decoding binary data acquired with the newest software for single board or multi-boards daisy chained?
Cheers,
Abaz
|
|
729
|
Wed Jan 30 08:02:25 2019 |
Stefan Ritt | DRS4 domino wave stability study | The Domino wave is most stable at 5 GSPS, slowly degrades down to 3-2 GSPS, and at 1GSPS gets some significant jitter. This is for internal reasons in the chip and cannot be compensated by the loop filter. It is therefore important to run it as fast as possible if you want to achieve best timing resolution. As a rule of thumb, the jitter at 5 GSPS is about 20-25 ps, and at 1 GSPS it is maybe 150 ps. If you require good timing resolution, you can use the 9th channel to sample a stable reference clock (100 MHz for example) and measure timing relative to that clock. This way you can bring down the resolution to a few ps at 5GSPS and to maybe 40 ps at 1 GSPS.
Stefan
Saurabh Neema wrote: |
We have been using DRS4 IC in our design for quite some time and it is giving good performance.
Till now we were using Domino wave frequency as 1 GSPS by use of reference clock to DRS4 and internal PLL of DRS4. Recently we tried to use 4GSPS by modifying the reference clock.
What I have found that DRS4 domino wave is more stable at 4 GSPS as compared to 1 GSPS by doing the timing jitter analysis. I am not sure if it is the property of DRS4 IC to be having more stable domino wave at higher frequency (by design) or it is due to some external effects like PLL loop filter or any other on board parasitic effects.
Please share if anyone has done any study of DRS4 Domino wave stability at different sampling frequencies.
Thanks,
|
|
728
|
Wed Jan 30 06:51:37 2019 |
Saurabh Neema | DRS4 domino wave stability study | We have been using DRS4 IC in our design for quite some time and it is giving good performance.
Till now we were using Domino wave frequency as 1 GSPS by use of reference clock to DRS4 and internal PLL of DRS4. Recently we tried to use 4GSPS by modifying the reference clock.
What I have found that DRS4 domino wave is more stable at 4 GSPS as compared to 1 GSPS by doing the timing jitter analysis. I am not sure if it is the property of DRS4 IC to be having more stable domino wave at higher frequency (by design) or it is due to some external effects like PLL loop filter or any other on board parasitic effects.
Please share if anyone has done any study of DRS4 Domino wave stability at different sampling frequencies.
Thanks,
|
727
|
Tue Jan 29 14:43:44 2019 |
Abaz Kryemadhi | ROOT Macro for data acquired with the newest software | Hello,
Is there a root macro for decoding binary data acquired with the newest software for single board or multi-boards daisy chained?
Cheers,
Abaz |
726
|
Thu Nov 8 12:02:34 2018 |
Davide Depaoli | Timing Issue | Thanks a lot for the quick response.
We will do as you suggest.
Best regards
Davide and Alessio
> That's not a bug, but a feature of the DRS4 chip. The time bins have different values by the properties of the chip. They are generated by a chain of inverters, which all have different
propagation times. This delay is measured by the time calibration and then applied. If you want equidistant bins,
> you have to interpolate your data points (linearly or by splines) and resample the signal. You can find more details in the DRS4 data sheet.
>
> Best,
> Stefan
>
>
> > Hi,
> >
> > We are using the DRS4 Evaluation Board as a digitizer in our laboratory.
> > We found a strange behavior in the saved files, more specifically the time difference between two consecutive points is not constant, also after the Timing Calibration.
> > As an example, I paste a piece of a xml file saved using the drsosc program, acquiring CH1 (open):
> >
> > ---------------------------
> > ---[ START XML EXAMPLE ]---
> > ---------------------------
> >
> > <?xml version="1.0" encoding="ISO-8859-1"?>
> > <!-- created by MXML on Thu Nov 8 11:13:27 2018 -->
> > <DRSOSC>
> > <Event>
> > <Serial>1</Serial>
> > <Time>2018/11/08 11:13:27.163</Time>
> > <HUnit>ns</HUnit>
> > <VUnit>mV</VUnit>
> > <Board_2796>
> > <Trigger_Cell>216</Trigger_Cell>
> > <Scaler0>0</Scaler0>
> > <CHN1>
> > <Data>0.000,-1.0</Data>
> > <Data>1.083,-1.0</Data>
> > <Data>2.143,-1.0</Data>
> > <Data>2.926,-1.0</Data>
> > <Data>4.249,-0.1</Data>
> > <Data>4.929,-0.6</Data>
> > <Data>6.075,-0.4</Data>
> > <Data>7.042,0.0</Data>
> > <Data>8.299,0.2</Data>
> >
> > [...]
> >
> > -------------------------
> > ---[ END XML EXAMPLE ]---
> > -------------------------
> >
> > We found the same behavior saving events in the binary format, and then reading them with the read_binary.cpp
> >
> > Is there a way to fix our issue?
> >
> > Thanks a lot
> >
> > Davide and Alessio |
725
|
Thu Nov 8 11:54:33 2018 |
Stefan Ritt | Timing Issue | That's not a bug, but a feature of the DRS4 chip. The time bins have different values by the properties of the chip. They are generated by a chain of inverters, which all have different propagation times. This delay is measured by the time calibration and then applied. If you want equidistant bins,
you have to interpolate your data points (linearly or by splines) and resample the signal. You can find more details in the DRS4 data sheet.
Best,
Stefan
> Hi,
>
> We are using the DRS4 Evaluation Board as a digitizer in our laboratory.
> We found a strange behavior in the saved files, more specifically the time difference between two consecutive points is not constant, also after the Timing Calibration.
> As an example, I paste a piece of a xml file saved using the drsosc program, acquiring CH1 (open):
>
> ---------------------------
> ---[ START XML EXAMPLE ]---
> ---------------------------
>
> <?xml version="1.0" encoding="ISO-8859-1"?>
> <!-- created by MXML on Thu Nov 8 11:13:27 2018 -->
> <DRSOSC>
> <Event>
> <Serial>1</Serial>
> <Time>2018/11/08 11:13:27.163</Time>
> <HUnit>ns</HUnit>
> <VUnit>mV</VUnit>
> <Board_2796>
> <Trigger_Cell>216</Trigger_Cell>
> <Scaler0>0</Scaler0>
> <CHN1>
> <Data>0.000,-1.0</Data>
> <Data>1.083,-1.0</Data>
> <Data>2.143,-1.0</Data>
> <Data>2.926,-1.0</Data>
> <Data>4.249,-0.1</Data>
> <Data>4.929,-0.6</Data>
> <Data>6.075,-0.4</Data>
> <Data>7.042,0.0</Data>
> <Data>8.299,0.2</Data>
>
> [...]
>
> -------------------------
> ---[ END XML EXAMPLE ]---
> -------------------------
>
> We found the same behavior saving events in the binary format, and then reading them with the read_binary.cpp
>
> Is there a way to fix our issue?
>
> Thanks a lot
>
> Davide and Alessio |
724
|
Thu Nov 8 11:44:35 2018 |
Davide Depaoli | Timing Issue | Hi,
We are using the DRS4 Evaluation Board as a digitizer in our laboratory.
We found a strange behavior in the saved files, more specifically the time difference between two consecutive points is not constant, also after the Timing Calibration.
As an example, I paste a piece of a xml file saved using the drsosc program, acquiring CH1 (open):
---------------------------
---[ START XML EXAMPLE ]---
---------------------------
<?xml version="1.0" encoding="ISO-8859-1"?>
<!-- created by MXML on Thu Nov 8 11:13:27 2018 -->
<DRSOSC>
<Event>
<Serial>1</Serial>
<Time>2018/11/08 11:13:27.163</Time>
<HUnit>ns</HUnit>
<VUnit>mV</VUnit>
<Board_2796>
<Trigger_Cell>216</Trigger_Cell>
<Scaler0>0</Scaler0>
<CHN1>
<Data>0.000,-1.0</Data>
<Data>1.083,-1.0</Data>
<Data>2.143,-1.0</Data>
<Data>2.926,-1.0</Data>
<Data>4.249,-0.1</Data>
<Data>4.929,-0.6</Data>
<Data>6.075,-0.4</Data>
<Data>7.042,0.0</Data>
<Data>8.299,0.2</Data>
[...]
-------------------------
---[ END XML EXAMPLE ]---
-------------------------
We found the same behavior saving events in the binary format, and then reading them with the read_binary.cpp
Is there a way to fix our issue?
Thanks a lot
Davide and Alessio |
723
|
Thu Nov 8 09:57:26 2018 |
Stefan Ritt | Pi attenuator on eval board inputs? | The attenuator compensates for the gain of the buffer which is slightly above one. In addition, it serves as a "placeholder" in case one wants larger input signals. One can easily convert the attenuator to -6db, -12db, etc. by chaning the resistors.
Stefan
Sean Quinn wrote: |
Dear DRS4 team,
I am curious about this part of the circuit:

What is the purpose of this?
|
|
722
|
Mon Nov 5 17:17:08 2018 |
Sean Quinn | Pi attenuator on eval board inputs? | Dear DRS4 team,
I am curious about this part of the circuit:

What is the purpose of this? |
721
|
Wed Sep 26 19:21:03 2018 |
Stefan Ritt | Trigger OUT pulse width variable from 100 us up to 100 ms | In meantime I even updated the manual.
Stefan
Gerard Arino-Estrada wrote: |
Thank you very much for the answer, I really appreciate your help.
Thanks!
Gerard
|
|
|