DRS4 Forum
  DRS4 Discussion Forum, Page 13 of 40  Not logged in ELOG logo
IDdown Date Author Subject
  552   Fri Oct 28 15:51:59 2016 Stefan RittProblems with DRS command line
No, I absolutely have no idea. Both DRSOsc and drscl use exaclty the same code to access USB.

Stefan


Simon Mendisch wrote:

that means, I am the second one experiencing this problem. To be more specific, the "No DRS Board found" problem is only present at one machine running Win7x64.
DRSOsc, of course not running simultaneously works just fine. Only drscl shows this behavior. Upgrading to a newer software version or a re-installation of the old one didn't solve the issue.
On other Win7x64 machines everything works fine, so I am pretty sure the problem is on this specific machine. Do you have any idea what could be the cause of this behavior?
  551   Fri Oct 28 15:02:18 2016 Simon MendischProblems with DRS command line

Stefan Ritt wrote:

You are the first one describing this problem (out of ~200 people), so I guess the problem must be on your side. Have you made sure to start the DRS oscilloscope and the Command Line Interface not at the same time? Only one program can access the board at a given time. Have you tried disconnecting and re-connecting the board?

Stefan





Hello,

that means, I am the second one experiencing this problem. To be more specific, the "No DRS Board found" problem is only present at one machine running Win7x64.
DRSOsc, of course not running simultaneously works just fine. Only drscl shows this behavior. Upgrading to a newer software version or a re-installation of the old one didn't solve the issue.
On other Win7x64 machines everything works fine, so I am pretty sure the problem is on this specific machine. Do you have any idea what could be the cause of this behavior?



Best Regards,

Simon
  550   Thu Oct 27 08:29:26 2016 Stefan RittProblems with DRS command line

Alexey Lubinets wrote:
Hello, everybody

I have installed the software for the DRS4 Evaluation Board.
When I run the DRS Oscilloscope, it works OK (at least, my computer "knows", that the board is connected). But when I run the DRS Command Line Interface, it writes "USB successfully scanned, but no boards found
No DRS boards found".
How can I manage with this problem? The drivers for the DRS Evaluation Board are installed.

Regards, Alexey Lubinets


You are the first one describing this problem (out of ~200 people), so I guess the problem must be on your side. Have you made sure to start the DRS oscilloscope and the Command Line Interface not at the same time? Only one program can access the board at a given time. Have you tried disconnecting and re-connecting the board?

Stefan
  549   Wed Oct 26 21:15:35 2016 Alexey LubinetsProblems with DRS command line
Hello, everybody

I have installed the software for the DRS4 Evaluation Board.
When I run the DRS Oscilloscope, it works OK (at least, my computer "knows", that the board is connected). But when I run the DRS Command Line Interface, it writes "USB successfully scanned, but no boards found
No DRS boards found".
How can I manage with this problem? The drivers for the DRS Evaluation Board are installed.

Regards, Alexey Lubinets
  548   Tue Oct 11 22:11:26 2016 Stefan Ritttime difference between 2 channels only ~30-35ps @ 5GSmples/s

Thank you very much! I will check it tomorrow!

-d

Concerning the offset, it looks to me like you moved the offset slider slider of channel 1 to a non-zero position. You see that from the marker at the very left side of the screen, where the yellow marker is at a different position as the others. Hint: a right-click on that slider sets it to zero. The little streak could be some kind of external noise.

Danny Petschke wrote:

Hello Stefan,

thanks for the paper. That makes sense. I thought about sth. like that but wasn`t sure. Couldn´t check higher frequencies (limit of my function generator).

What do think about the other picture I attached yesterday where Chn1 shows a totally different offset than Chn2-4. Moreover Chn4 shows some streaks (red circle) ?

Best regards

Danny

 

  547   Tue Oct 11 09:20:04 2016 Stefan Ritttime difference between 2 channels only ~30-35ps @ 5GSmples/s

Concerning the offset, it looks to me like you moved the offset slider slider of channel 1 to a non-zero position. You see that from the marker at the very left side of the screen, where the yellow marker is at a different position as the others. Hint: a right-click on that slider sets it to zero. The little streak could be some kind of external noise.

Danny Petschke wrote:

Hello Stefan,

thanks for the paper. That makes sense. I thought about sth. like that but wasn`t sure. Couldn´t check higher frequencies (limit of my function generator).

What do think about the other picture I attached yesterday where Chn1 shows a totally different offset than Chn2-4. Moreover Chn4 shows some streaks (red circle) ?

Best regards

Danny

 

  546   Tue Oct 11 09:04:33 2016 Danny Petschketime difference between 2 channels only ~30-35ps @ 5GSmples/s

Hello Stefan,

thanks for the paper. That makes sense. I thought about sth. like that but wasn`t sure. Couldn´t check higher frequencies (limit of my function generator).

What do think about the other picture I attached yesterday where Chn1 shows a totally different offset than Chn2-4. Moreover Chn4 shows some streaks (red circle) ?

Best regards

Danny

Stefan Ritt wrote:

Ok, I got it. The timing resolution is affected by the signal-to-noise ratio over the rise-time of your signal. You find the full formula herer:

https://arxiv.org/abs/1405.4975

Your sine wave input signal has a slow rise time, and therefore limits the time resolution. I reproduced your measurement with a 20 MHz sine wave and got the same result:

 

If I increase the frequency to 100 MHz and increase the amplitude, I get a better resolution:

 

This is 5 ps which is better than 37 ps, but still not 2.5 ps. This can only be reached by sending single pulses to the evaluation board which have a rise time of > 300 mV / ns, which can be seen here:

 

It is important to understand the relation timing - resolution vs. rise time / noise as explained in the quoted paper. If you have tiny pulses from your detector, you never will be able to measure excellent timing. This is physics, and not related to the specific electronics you are using.

Best regards,
Stefan

 

 

 

 

 

 

  545   Mon Oct 10 12:03:27 2016 Stefan Ritttime difference between 2 channels only ~30-35ps @ 5GSmples/s

Ok, I got it. The timing resolution is affected by the signal-to-noise ratio over the rise-time of your signal. You find the full formula herer:

https://arxiv.org/abs/1405.4975

Your sine wave input signal has a slow rise time, and therefore limits the time resolution. I reproduced your measurement with a 20 MHz sine wave and got the same result:

 

If I increase the frequency to 100 MHz and increase the amplitude, I get a better resolution:

 

This is 5 ps which is better than 37 ps, but still not 2.5 ps. This can only be reached by sending single pulses to the evaluation board which have a rise time of > 300 mV / ns, which can be seen here:

 

It is important to understand the relation timing - resolution vs. rise time / noise as explained in the quoted paper. If you have tiny pulses from your detector, you never will be able to measure excellent timing. This is physics, and not related to the specific electronics you are using.

Best regards,
Stefan

 

 

 

 

 

  544   Mon Oct 10 11:30:37 2016 Danny Petschketime difference between 2 channels only ~30-35ps @ 5GSmples/s

Hello Stefan,

Chn2 & Chn3 were used for delay-determination as you can see on the second picture.

 

The second picture shows all 4 Channels without any voltage input.

On Channel 4 streaks (red circle) occur often and Channel 1 has totally different Offset (Picture 1). 

Thanks

 

Stefan Ritt wrote:

Can you post a screenshot of your measurement?

Stefan

Danny Petschke wrote:

(Board Type:9, DRS4)

Hello,

I´m trying to reach the timig resolution of about 2.5ps as written in the manual. 

My settings are:

5GSamples/s

+/-0.5V

I followed the instructions of the manual. The chip was warm and ran about 10h. Then, Timing- followed by Voltage-Calibration.

The test-signal is a splittet sine-wave of 20MHz (function-generator) brought on A0 and A1 (A1 signal is delayed by 1ns-cable).

I´ve been testing different trigger-logic: (Chn1 AND Chn2), (Chn1 OR Chn2) and only Chn1 or Chn2. 

Trigger-levels were changed too.

All setups show the same result of 1.009ns +/- 30-35ns (results from the DRS-Oscilloscope).

What is wrong from my side? 

Thanks a lot for your help

 

 

Attachment 1: allChannels_zero_scaled.png
allChannels_zero_scaled.png
Attachment 2: Chn2_Chn3_1ns_delay_scaled.png
Chn2_Chn3_1ns_delay_scaled.png
  543   Sun Oct 9 11:39:18 2016 Stefan Ritttime difference between 2 channels only ~30-35ps @ 5GSmples/s

Can you post a screenshot of your measurement?

Stefan

Danny Petschke wrote:

(Board Type:9, DRS4)

Hello,

I´m trying to reach the timig resolution of about 2.5ps as written in the manual. 

My settings are:

5GSamples/s

+/-0.5V

I followed the instructions of the manual. The chip was warm and ran about 10h. Then, Timing- followed by Voltage-Calibration.

The test-signal is a splittet sine-wave of 20MHz (function-generator) brought on A0 and A1 (A1 signal is delayed by 1ns-cable).

I´ve been testing different trigger-logic: (Chn1 AND Chn2), (Chn1 OR Chn2) and only Chn1 or Chn2. 

Trigger-levels were changed too.

All setups show the same result of 1.009ns +/- 30-35ns (results from the DRS-Oscilloscope).

What is wrong from my side? 

Thanks a lot for your help

 

  542   Sun Oct 9 10:43:35 2016 Danny Petschketime difference between 2 channels only ~30-35ps @ 5GSmples/s

(Board Type:9, DRS4)

Hello,

I´m trying to reach the timig resolution of about 2.5ps as written in the manual. 

My settings are:

5GSamples/s

+/-0.5V

I followed the instructions of the manual. The chip was warm and ran about 10h. Then, Timing- followed by Voltage-Calibration.

The test-signal is a splittet sine-wave of 20MHz (function-generator) brought on A0 and A1 (A1 signal is delayed by 1ns-cable).

I´ve been testing different trigger-logic: (Chn1 AND Chn2), (Chn1 OR Chn2) and only Chn1 or Chn2. 

Trigger-levels were changed too.

All setups show the same result of 1.009ns +/- 30-35ns (results from the DRS-Oscilloscope).

What is wrong from my side? 

Thanks a lot for your help

  541   Thu Oct 6 15:23:18 2016 Will Flanagan 

Hi Stefan,

That is exactly what I'm looking for. Thanks again!

Will

  540   Thu Oct 6 11:18:05 2016 Stefan RittTimestamp for each DRS4 waveform

In the mentioned read_binary.cpp file you have the line where you read the event header

i = fread(&eh, sizeof(eh), 1, f);

The C structure eh now contains the full timestamp, and you can access it with 

eh.year
eh.month
eh.day
eh.hour
eh.minute
eh.second
eh.millisecond

Cheers,
Stefan

Will Flanagan wrote:

Hi DRS4 Experts,

I have been analyzing DRS4 binary data with scripts based on Stefan's (very helpful!) macro:

https://midas.psi.ch/elogs/DRS4+Forum/361

I would now like to look at the stability of my waveforms over a long period of time. In order to do this, I would need a timestamp encoded with each waveform. Are there timestamps within default DRS4 binary data? If so, does anyone have sample code for extracting them?

Best Regards,

Will

 

  539   Wed Oct 5 22:43:29 2016 Will FlanaganTimestamp for each DRS4 waveform

Hi DRS4 Experts,

I have been analyzing DRS4 binary data with scripts based on Stefan's (very helpful!) macro:

https://midas.psi.ch/elogs/DRS4+Forum/361

I would now like to look at the stability of my waveforms over a long period of time. In order to do this, I would need a timestamp encoded with each waveform. Are there timestamps within default DRS4 binary data? If so, does anyone have sample code for extracting them?

Best Regards,

Will

  538   Fri Sep 30 17:03:38 2016 Stefan RittOutput Timing Drifting

Hi Jacob,

you are missing the timing calibration. Each sampling cell has not the same width. Running at 5 GSPS, cell widths scatter from 150 ps to 250 ps. If you integrate these widhts, you get a time scale which can be off by a few ns between chips, something you see in your plot. Here is a paper which explains in detail how to do a timing calibration: https://arxiv.org/abs/1405.4975

Cheers,
Stefan

Jacob Hwang wrote:

Hello,

I have designed four DRS4 chips (36 channels) on my board running at 1GHz (REFCLK=488.28KHz) and ROI mode. All 4 chips' REFCLK, DWRITE, RSRLOAD, and SRCLK are buffer driven by the same source.  SRCLK is set to 40MHz to reduce the readout time.

If I injected a sine waveform, buffered and splitted into all 36 channels,I noticed all 9 channels on each DRS4 chip output almost the same as expected.  But the output phase from chip to chip is drifting as shown in attached picture which is from two different channels of different chips.  From the few boards I have built, I found few chips are drifting more than the others and is different on every board.

The sympton look like the DRS4 internal PLL is drifting, but I checked the DTAP output on every chip and found it's dead-lock steady even I used persistance setting on my oscilloscope.  Do you have any suggestion how to attack this problem?  Thank you.

Jacob Hwang
 

 

  537   Thu Sep 29 17:26:13 2016 Jacob HwangOutput Timing Drifting

Hello,

I have designed four DRS4 chips (36 channels) on my board running at 1GHz (REFCLK=488.28KHz) and ROI mode. All 4 chips' REFCLK, DWRITE, RSRLOAD, and SRCLK are buffer driven by the same source.  SRCLK is set to 40MHz to reduce the readout time.

If I injected a sine waveform, buffered and splitted into all 36 channels,I noticed all 9 channels on each DRS4 chip output almost the same as expected.  But the output phase from chip to chip is drifting as shown in attached picture which is from two different channels of different chips.  From the few boards I have built, I found few chips are drifting more than the others and is different on every board.

The sympton look like the DRS4 internal PLL is drifting, but I checked the DTAP output on every chip and found it's dead-lock steady even I used persistance setting on my oscilloscope.  Do you have any suggestion how to attack this problem?  Thank you.

Jacob Hwang
 

Attachment 1: Output_Drifting.jpg
Output_Drifting.jpg
  536   Mon Aug 29 12:51:48 2016 Stefan Rittincrement write config register on the fly?

The problem is when you change the write config register from 11111111 to 01111111, or from 00001111 to 00000111, then the last 256 sampels of the previous channel (in the first case #0, in the scond #4) would be overwritten as soon as dwrite =1 again. So you loose 1/4 ef each channel.

Concerning the readout, indeed you can keep track in the FPGA, but only with a certainty of a few cells. This gives some timing inacccuracy of maybe 10-20 ns, which certainly would be disturbing you.

 

benjamin legeyt wrote:

If I may trouble you for a little more information, the critical point then is that there should not be any zeroes in the write config register while the sampling is active?  In case it was unclear I would only be reading out once sampling was stopped (dwrite = 0).  

As for the readout, I know that I would have to read out all 1024 samples each time, and keep track of where each channel stopped in the FPGA.  I would never know the exact cell where sampling stopped but I hoped that if I discard some number of cells on each side of the expected stopping point that I would be OK.  

Thanks again

Stefan Ritt wrote:

The issue with "stopping at cell 767" would also affect this mode of operation. Furthermore, the DRS4 chip has only 10 bit register which records in which cell the event has occured, and where the readout must be started. If you record 8 separate events, you don't know where to start the readout.

The DRS5 chip will have all this possibilitied, but unfortunately it won't be ready before 2-3 years from now.

Stefan

 

benjamin legeyt wrote:

Hello,

I have a question about using the write config register to enable/disable sampling on the fly.  I am looking to instrument an experiment at EPFL where multiple short events need to be captured during a 20us period followed by an 80us quiet period during which we could read out the chip.  Would it be possible to start an acquisition with all channels seeing the same signal and the write config register set to 111111111 and then shift a zero into the write config reg after each event is detected to freeze the channels in time one-by-one?  In this way we could measure up to 8 different events during the active period and then read them all out together during the quiet period.  I have read the posts about the simultaneous read-write mode and the issue with waveforms stopping at cell 767.  not knowing the exact details of what causes this issue I wonder if it would effect this sort of operation?  Also, I would like to know if dwrite must be de-asserted while the write config register is being updated or if it could be done while the sampling is active?  The latter would obviously be preferable as we would not incur any dead-time during the active period.

Thanks in advance for the information,

Benjamin LeGeyt

 

 

 

  535   Mon Aug 29 12:18:49 2016 benjamin legeytincrement write config register on the fly?

If I may trouble you for a little more information, the critical point then is that there should not be any zeroes in the write config register while the sampling is active?  In case it was unclear I would only be reading out once sampling was stopped (dwrite = 0).  

As for the readout, I know that I would have to read out all 1024 samples each time, and keep track of where each channel stopped in the FPGA.  I would never know the exact cell where sampling stopped but I hoped that if I discard some number of cells on each side of the expected stopping point that I would be OK.  

Thanks again

Stefan Ritt wrote:

The issue with "stopping at cell 767" would also affect this mode of operation. Furthermore, the DRS4 chip has only 10 bit register which records in which cell the event has occured, and where the readout must be started. If you record 8 separate events, you don't know where to start the readout.

The DRS5 chip will have all this possibilitied, but unfortunately it won't be ready before 2-3 years from now.

Stefan

 

benjamin legeyt wrote:

Hello,

I have a question about using the write config register to enable/disable sampling on the fly.  I am looking to instrument an experiment at EPFL where multiple short events need to be captured during a 20us period followed by an 80us quiet period during which we could read out the chip.  Would it be possible to start an acquisition with all channels seeing the same signal and the write config register set to 111111111 and then shift a zero into the write config reg after each event is detected to freeze the channels in time one-by-one?  In this way we could measure up to 8 different events during the active period and then read them all out together during the quiet period.  I have read the posts about the simultaneous read-write mode and the issue with waveforms stopping at cell 767.  not knowing the exact details of what causes this issue I wonder if it would effect this sort of operation?  Also, I would like to know if dwrite must be de-asserted while the write config register is being updated or if it could be done while the sampling is active?  The latter would obviously be preferable as we would not incur any dead-time during the active period.

Thanks in advance for the information,

Benjamin LeGeyt

 

 

  534   Mon Aug 29 10:57:33 2016 Stefan Rittincrement write config register on the fly?

The issue with "stopping at cell 767" would also affect this mode of operation. Furthermore, the DRS4 chip has only 10 bit register which records in which cell the event has occured, and where the readout must be started. If you record 8 separate events, you don't know where to start the readout.

The DRS5 chip will have all this possibilitied, but unfortunately it won't be ready before 2-3 years from now.

Stefan

 

benjamin legeyt wrote:

Hello,

I have a question about using the write config register to enable/disable sampling on the fly.  I am looking to instrument an experiment at EPFL where multiple short events need to be captured during a 20us period followed by an 80us quiet period during which we could read out the chip.  Would it be possible to start an acquisition with all channels seeing the same signal and the write config register set to 111111111 and then shift a zero into the write config reg after each event is detected to freeze the channels in time one-by-one?  In this way we could measure up to 8 different events during the active period and then read them all out together during the quiet period.  I have read the posts about the simultaneous read-write mode and the issue with waveforms stopping at cell 767.  not knowing the exact details of what causes this issue I wonder if it would effect this sort of operation?  Also, I would like to know if dwrite must be de-asserted while the write config register is being updated or if it could be done while the sampling is active?  The latter would obviously be preferable as we would not incur any dead-time during the active period.

Thanks in advance for the information,

Benjamin LeGeyt

 

  533   Mon Aug 29 09:36:34 2016 benjamin legeytincrement write config register on the fly?

Hello,

I have a question about using the write config register to enable/disable sampling on the fly.  I am looking to instrument an experiment at EPFL where multiple short events need to be captured during a 20us period followed by an 80us quiet period during which we could read out the chip.  Would it be possible to start an acquisition with all channels seeing the same signal and the write config register set to 111111111 and then shift a zero into the write config reg after each event is detected to freeze the channels in time one-by-one?  In this way we could measure up to 8 different events during the active period and then read them all out together during the quiet period.  I have read the posts about the simultaneous read-write mode and the issue with waveforms stopping at cell 767.  not knowing the exact details of what causes this issue I wonder if it would effect this sort of operation?  Also, I would like to know if dwrite must be de-asserted while the write config register is being updated or if it could be done while the sampling is active?  The latter would obviously be preferable as we would not incur any dead-time during the active period.

Thanks in advance for the information,

Benjamin LeGeyt

ELOG V3.1.4-80633ba