DRS4 Forum
  DRS4 Discussion Forum, Page 7 of 15  Not logged in ELOG logo
New entries since:Thu Jan 1 01:00:00 1970
Entry  Wed Oct 26 21:15:35 2016, Alexey Lubinets, Problems 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
    Reply  Thu Oct 27 08:29:26 2016, Stefan Ritt, Problems 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
       Reply  Fri Oct 28 15:02:18 2016, Simon Mendisch, Problems 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
          Reply  Fri Oct 28 15:51:59 2016, Stefan Ritt, Problems 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?
Entry  Tue Oct 11 22:11:26 2016, Stefan Ritt, time 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

 

Entry  Sun Oct 9 10:43:35 2016, Danny Petschke, time 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

    Reply  Sun Oct 9 11:39:18 2016, Stefan Ritt, time 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

 

       Reply  Mon Oct 10 11:30:37 2016, Danny Petschke, time difference between 2 channels only ~30-35ps @ 5GSmples/s allChannels_zero_scaled.pngChn2_Chn3_1ns_delay_scaled.png

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

 

 

          Reply  Mon Oct 10 12:03:27 2016, Stefan Ritt, time difference between 2 channels only ~30-35ps @ 5GSmples/s Screen_Shot_2016-10-10_at_12.01.03_.pngScreen_Shot_2016-10-10_at_12.01.57_.pngScreen_Shot_2016-10-10_at_12.36.48_.png

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

 

 

 

 

 

             Reply  Tue Oct 11 09:04:33 2016, Danny Petschke, time 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

 

 

 

 

 

 

                Reply  Tue Oct 11 09:20:04 2016, Stefan Ritt, time 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

 

Entry  Thu Oct 6 15:23:18 2016, Will Flanagan,  

Hi Stefan,

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

Will

Entry  Wed Oct 5 22:43:29 2016, Will Flanagan, Timestamp 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

    Reply  Thu Oct 6 11:18:05 2016, Stefan Ritt, Timestamp 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

 

Entry  Thu Sep 29 17:26:13 2016, Jacob Hwang, Output Timing Drifting Output_Drifting.jpg

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
 

    Reply  Fri Sep 30 17:03:38 2016, Stefan Ritt, Output 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
 

 

Entry  Mon Aug 29 09:36:34 2016, benjamin legeyt, increment 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

    Reply  Mon Aug 29 10:57:33 2016, Stefan Ritt, increment 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

 

       Reply  Mon Aug 29 12:18:49 2016, benjamin legeyt, increment 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

 

 

          Reply  Mon Aug 29 12:51:48 2016, Stefan Ritt, increment 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

 

 

 

Entry  Wed Jun 29 09:10:01 2016, Stefan Ritt, Negative input signals 

Hello everybody,

I get often asked if the DRS4 evaluation board can accomodate negative input pulses going to -1V. This is unfortunately not possible, since the board is mainly for evaluation of the DRS4 chip and should not be seen as a complete oscilloscope with flexible input stage. So the maximum it can do is -0.5V to +0.5V or 0V to 1V. For -1V signals, one can use however a passive inverter like this one:

http://www.phillipsscientific.com/pdf/460ds.pdf

And for signals going furhter (-2V, -10V) one can use a passive attenuator like this one:

http://www.pomonaelectronics.com/pdf/d4108_K5513_101.pdf

 

Best regards,

Stefan

 

Entry  Sun Jun 12 08:45:52 2016, Michael, problems of DRS4 

Hi

I want to use DRS4 to digitize 16 channels of signals. The width of signal is about 20 ns, with frequency of 50Hz. The time differences between these 16 signals are not constant, arranging from 3us to 0. I am confused about this in some aspects.

  1. Can I use SIMULTANEOUS WRITINT AND READING to realize this? I saw the VHDL program, and if I understand it correctly, it did not work at this state.
  2. Or sampling at 1GSPS, using CASCADING OF CHANNELS, I can sample signal at most 4us or 8us, then digitizing all signals of one chip. Have you tested 4 or more channels cascading before?

Besides, any advice will be helpful!

Thank you.

    Reply  Wed Jun 15 14:49:00 2016, Stefan Ritt, problems of DRS4 

1. Simultaneous writing and reading is not possible with the DRS4 chip. The manual says differently on p. 14, but due to a bug in the chip waveforms get clipped at the end if one does that. We hopt to fix this problem in a future version of the chip.

2. You can cascade 2,4 or 8 channels. If you cascade 8 channels and run at 1 GSPS, you digitize a window of 8 us. If you have 16 signals, you then need 16 chips.

/Stefan

Michael wrote:

Hi

I want to use DRS4 to digitize 16 channels of signals. The width of signal is about 20 ns, with frequency of 50Hz. The time differences between these 16 signals are not constant, arranging from 3us to 0. I am confused about this in some aspects.

  1. Can I use SIMULTANEOUS WRITINT AND READING to realize this? I saw the VHDL program, and if I understand it correctly, it did not work at this state.
  2. Or sampling at 1GSPS, using CASCADING OF CHANNELS, I can sample signal at most 4us or 8us, then digitizing all signals of one chip. Have you tested 4 or more channels cascading before?

Besides, any advice will be helpful!

Thank you.

 

Entry  Sun Jun 12 08:49:54 2016, Michael, problems of DRS4 

Hi

I want to use DRS4 to digitize 16 channels of signals. The width of signal is about 20 ns, with frequency of 50Hz. The time differences between these 16 signals are not constant, arranging from 3us to 0. I am confused about this in some aspects.

  1. Can I use SIMULTANEOUS WRITINT AND READING to realize this? I saw the VHDL program, and if I understand it correctly, it did not work at this state.
  2. Or sampling at 1GSPS, using CASCADING OF CHANNELS, I can sample signal at most 4us or 8us, then digitizing all signals of one chip. Have you tested 4 or more channels cascading before?

Besides, any advice will be helpful!

Thank you.

Entry  Wed Jun 1 22:29:01 2016, Dominik Neise, problems when stop cell >= 767 ?? stop_cell_distribution.png

Hello Stefan,

some colleages told me a story, I was neither able to confirm nor find anything in the datsheet about. According to them:

For some internal reason of the DRS4, if the “stop capacitor” of the DRS4 is >= 767, the true stop channel is one before the stop channel read from the DRS4. In other words, the stop channel which returns the DRS4 shifts after sampling to the capacitor ID 766.

Can you confirm that, or even say a few words about that matter?

I wanted to confirm this by plotting the stop cell distribution for random triggered data, taken with one of the FACT boards. I assumed (possibly misunderstanding the matter), that this would lead to missing values in the area of stop cell 767, but cannot see any significant excess or lack of entries in that area.

 

    Reply  Wed Jun 1 23:16:01 2016, Stefan Ritt, problems when stop cell >= 767 ?? 

I cannot confirm the story with the "stop capacitor > 767". It can be seen from your plots that the distribution of stop cells are even, no holes or bins with double height.

There is an issue with cell 767, but this is when one tries to do simultaneous reading/writing to the chip. This does not really work as writen in the data sheet. Waveforms sometimgs get cut off at cell 767. But the stop cell is always correct, otherwise one could not calibrate the data. If you use the evaluation board for example, which is perfectly calibrated, and introduce an "artifical" shift like

if stop cell > 767 then
  stop cell = stop cell + 1

then you would see that the voltage calibration would become wrong and very noisy.

Stefan

Dominik Neise wrote:

Hello Stefan,

some colleages told me a story, I was neither able to confirm nor find anything in the datsheet about. According to them:

For some internal reason of the DRS4, if the “stop capacitor” of the DRS4 is >= 767, the true stop channel is one before the stop channel read from the DRS4. In other words, the stop channel which returns the DRS4 shifts after sampling to the capacitor ID 766.

Can you confirm that, or even say a few words about that matter?

I wanted to confirm this by plotting the stop cell distribution for random triggered data, taken with one of the FACT boards. I assumed (possibly misunderstanding the matter), that this would lead to missing values in the area of stop cell 767, but cannot see any significant excess or lack of entries in that area.

 

 

Entry  Wed May 11 04:01:14 2016, Maksat, DRS4 Macro to save events 

Dear Stefan,

I am trying to setup DRS inside radiation enclosure and would like to write a simple script that will automatically save certain number of events.

Could you please point to me an example that can I use for Mac OS? I saw there is drs_exam.cpp in the directory but was not able to get work in Mac OS. Any help would be greatly appreciated.

Thanks

 

 

    Reply  Thu May 12 12:38:17 2016, Stefan Ritt, DRS4 Macro to save events 

Dear Maksat,

If your car does not run, and you call the car dealer and tell him "my car does not run", what will the car dealer ask you? Eh... ? Right ! He will ask "what are the symptoms, what did you try, what did and what did not work". Here it's the same. "was not able to get it work" is not a valid statement, since I have absolutely no idea what did not work and what you did try.

The official way is to follow the instruction in the evlauation board manual on section 2.4 - Installation under Linux. If that does not work, please be a bit more precise what errors you get.

Cheers,
Stefan

Maksat wrote:

Dear Stefan,

I am trying to setup DRS inside radiation enclosure and would like to write a simple script that will automatically save certain number of events.

Could you please point to me an example that can I use for Mac OS? I saw there is drs_exam.cpp in the directory but was not able to get work in Mac OS. Any help would be greatly appreciated.

Thanks

 

 

 

Entry  Thu May 12 05:18:47 2016, Yu, Problem For Software Download 

Hi

 I can't download the software for windows on this website 'www.psi.ch/drs/software-download', there is some mistake when i click on download. 

 If convenient, can you send the software Version 5.0.5 for windows to me? My E-mail address is 'yuhaiyang421@163.com'. Thank you!

 

Best Regards

Yu

    Reply  Thu May 12 08:16:41 2016, Stefan Ritt, Problem For Software Download 

Can you tell me (screendump) what is the problem on the web site https://www.psi.ch/drs/software-download ? It should redirect you to

https://www.dropbox.com/sh/qul1cgtm4x7zx13/AADKQ-qGQGdAHPu6OR3vTNY0a?dl=0

for the Windows download.

I cannot send executables via email, that won't go though any spam filter.

Stefan

Yu wrote:

Hi

 I can't download the software for windows on this website 'www.psi.ch/drs/software-download', there is some mistake when i click on download. 

 If convenient, can you send the software Version 5.0.5 for windows to me? My E-mail address is 'yuhaiyang421@163.com'. Thank you!

 

Best Regards

Yu

 

Entry  Wed May 11 15:48:57 2016, SANDJONG Saturnin Orly, Probléme de Calibration de la DRS4 piedestaux_per_time.jpg

Bonjour, Je suis en stage dans un laboratoire ou on utilise pour echantillonnage des données, une cartes DRS4 5GSPS avec 1024 cell, mon probléme réside dans la partie Calibration en tension selon l'article "Novel Calibration Method for Switched Capacitor Arrays Enables Time Measurements with Sub-Picosecond Resolution". 

En fait je ne comprends pas précisément ces 3 parties de la calibration en tension. Quelqu'un pourras t-il s'il vous plait m'expliquer assez clairement avec des exemples comment il faut s'y prendre? 

Merci et bien Cordialement. 

Entry  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.

    Reply  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.

 

       Reply  Mon May 2 14:31:28 2016, Dmitry Hits, two DRS4 boards configuration with 2048 samples each 

Hi Stefan

Any chance you have time to fix the software for multiboard configuration with 2048 samples each. I tried 5.0.5, but drsosc still shows only half of the waveform.

Dmitry

Stefan Ritt wrote:

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.

 

 

Entry  Thu Apr 28 15:47:53 2016, Stefan Ritt, New software version and binary format 

A new software version 5.0.5 has been released today. This fixes a few bugs in multi-board configurations, and adds saving of the scaler values into XML and binary files. Please note that the binary file format has been changed for that. The new format is described in an updated manual (page 25), and reflected in a new read_binary.cpp program contained in the distribution.

/Stefan

Entry  Wed Apr 27 20:04:12 2016, Abaz Kryemadhi, Best settings for time measurements 

I am studing some pulses that are about 200-300 ns wide and a rise time of few ns,    which settings would be best for coincidence time measurements?

In some preliminary work I found for 700 MegaS the time measurement is better without time calibration (in -0.05 to 1V) rather than with time calibration in -0.5 to 0.5,  my pulses are about 60 mV.   Is it expected that always with time calibration time accuracy would be better or depends?   

Also I use this code snippet to find time for channel 1 and the same idea for chan. 2.

// find peak in channel 1 above threshold
      for (i=0 ; i<1022 ; i++)
         if (waveform[0][i] < threshold1 && waveform[0][i+1] >= threshold1) {
            tt1 = (threshold1-waveform[0][i])/(waveform[0][i+1]-waveform[0][i])*(time[0][i+1]-time[0][i])+time[0][i];
            break;
         }

 

Thanks!

Abaz

    Reply  Thu Apr 28 15:46:34 2016, Stefan Ritt, Best settings for time measurements 

The DRS4 chip has been designed to work best at high sampling speeds. At 700 MSPS, the chip is at it's limit and timing is very poorr (ns?). In order to get good timing, run it at least at 2 GSPS.

Stefan

Abaz Kryemadhi wrote:

I am studing some pulses that are about 200-300 ns wide and a rise time of few ns,    which settings would be best for coincidence time measurements?

In some preliminary work I found for 700 MegaS the time measurement is better without time calibration (in -0.05 to 1V) rather than with time calibration in -0.5 to 0.5,  my pulses are about 60 mV.   Is it expected that always with time calibration time accuracy would be better or depends?   

Also I use this code snippet to find time for channel 1 and the same idea for chan. 2.

// find peak in channel 1 above threshold
      for (i=0 ; i<1022 ; i++)
         if (waveform[0][i] < threshold1 && waveform[0][i+1] >= threshold1) {
            tt1 = (threshold1-waveform[0][i])/(waveform[0][i+1]-waveform[0][i])*(time[0][i+1]-time[0][i])+time[0][i];
            break;
         }

 

Thanks!

Abaz

 

Entry  Wed Apr 27 08:14:14 2016, Toshihiro Nonaka, serial number problem  serial.png

Dear all,

I'm using 3 DRS boards simultaneously and their serial numbers are 2169, 2170, 2172 respectively.

Recently however,  I obtain serial number "0" by DRSBoard::GetBoardSerialNumber() for #2172 board.

Data taking can be done without any problems, but I'd like to know what is happening.

Any advice?

Thank you.

Toshihiro Nonaka

    Reply  Wed Apr 27 09:04:01 2016, Stefan Ritt, serial number problem  

If dis- and reconnecting the board does not help, there is the (small) chance that the serial number got erased in the board. You can re-set it with the "drscl" command line tool:

$ drscl
Found DRS4 board 0 on USB, serial #0, firmware revision 21305
B0> serial 2172

 

Toshihiro Nonaka wrote:

Dear all,

I'm using 3 DRS boards simultaneously and their serial numbers are 2169, 2170, 2172 respectively.

Recently however,  I obtain serial number "0" by DRSBoard::GetBoardSerialNumber() for #2172 board.

Data taking can be done without any problems, but I'd like to know what is happening.

Any advice?

Thank you.

Toshihiro Nonaka

 

       Reply  Wed Apr 27 09:51:37 2016, Toshihiro Nonaka, serial number problem  

The serial number has been fixed by using drscl. Thank you!

Stefan Ritt wrote:

If dis- and reconnecting the board does not help, there is the (small) chance that the serial number got erased in the board. You can re-set it with the "drscl" command line tool:

$ drscl
Found DRS4 board 0 on USB, serial #0, firmware revision 21305
B0> serial 2172

 

Toshihiro Nonaka wrote:

Dear all,

I'm using 3 DRS boards simultaneously and their serial numbers are 2169, 2170, 2172 respectively.

Recently however,  I obtain serial number "0" by DRSBoard::GetBoardSerialNumber() for #2172 board.

Data taking can be done without any problems, but I'd like to know what is happening.

Any advice?

Thank you.

Toshihiro Nonaka

 

 

Entry  Fri Apr 15 12:58:46 2016, Konstantin Gusev, DRS4 purchase information 

    Hi,

 I can't contact with Anita Van Loon about DSR4 chip's price and delivery.

Did you still sell it? Can you provide me this information?

    Reply  Tue Apr 26 13:42:42 2016, Stefan Ritt, DRS4 purchase information 

Just be patient. Anita is not at work this week.

Konstantin Gusev wrote:

    Hi,

 I can't contact with Anita Van Loon about DSR4 chip's price and delivery.

Did you still sell it? Can you provide me this information?

 

Entry  Thu Apr 21 22:16:43 2016, Kyle Weinfurther, Negative fCellDT values from GetTimeCalibration() ch5.pngch7.pngch9.png

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

    Reply  Sat Apr 23 12:33:17 2016, Daniel Stricker-Shaver, Negative fCellDT values from GetTimeCalibration() 

Hi Kyle,

If I remember right the negative sampling width happens only for 498 and at high sampling speeds. It is described in a paper from Stefan:

http://arxiv.org/pdf/1405.4975.pdf

or

“Novel Calibration Method for Switched Capacitor Arrays Enables Time Measurements With Sub-Picosecond Resolution”( IEEE Transactions on Nuclear Science 61 (2014),Nr. 6, 3607–3617)

Kyle Weinfurther wrote:

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

 

       Reply  Tue Apr 26 09:54:16 2016, Stefan Ritt, Negative fCellDT values from GetTimeCalibration() 

I just realized that the negative bin widht is not explicitly mentioned in the quoted paper. So let me explain it here:

The negative value of cell 498 is correct and "real" in the sense that the signal is first captured in cell 498 and later in cell 497. This is due to the exact layout of the cells on the chip and the input signal. Cell 498 is simply much closer to the input, so sees the signal earlier than cell 497, even if it's triggerd after cell 497. So nothing to worry about.

Stefan

Daniel Stricker-Shaver wrote:

Hi Kyle,

If I remember right the negative sampling width happens only for 498 and at high sampling speeds. It is described in a paper from Stefan:

http://arxiv.org/pdf/1405.4975.pdf

or

“Novel Calibration Method for Switched Capacitor Arrays Enables Time Measurements With Sub-Picosecond Resolution”( IEEE Transactions on Nuclear Science 61 (2014),Nr. 6, 3607–3617)

Kyle Weinfurther wrote:

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

 

 

ELOG V3.1.5-2eba886