DRS4 Forum
  DRS4 Discussion Forum, Page 36 of 40  Not logged in ELOG logo
IDup Date Author Subject
  715   Tue Sep 4 13:04:30 2018 Stefan Ritt"Symmetric spikes" fixed

Yes it's possible, but I have to find time for that. The software of the evaluation board takes care of the spikes ("remove spikes"), so I thought it's not so urgent to fix that in the FPGA (which takes me some time).

Stefan

Martin Petriska wrote:

Hi,

Is it possible to fix it by FPGA changes?  I see readout cycle (proc_drs_reedout) in drs4_eval(4)5_app.vhd, but not sure where to exactly put this three commands. Could you please attach app.vhd file for eval board with example how to fix ?

Regards,

Martin

 

Stefan Ritt wrote:

Good news for all DRS4 users. After many years, I finally understand where the "symmetric spikes" come from and how to fix them.

The "symmetric spikes" are small spikes of 17-18mV, which randomly happen at 1-2 cells. They alwas come in groups of 2 in each channel, symmetric around sampling cell #512. See first attachment.

The reason for the spikes is the previous readout cycle. On each readout cycle, the "read bit" is clocked through all 1024 cells to switch one cell contents to the DRS4 output. At the end of the 1024 cycles, the read bit stays at its last position. The bit is carried by a metal line on the chip, which crosses all 9 channels (second attachment). This bit now influences the sampling cells below the metal line capacitively, so their contents is "pushed up" by a few mV, just like the ROFS offset does. Since the DRS sampling channels are in a snake layout, going 0-512 from left, then 512-1023 back again, the line crosses two cells in each channel, and thus the symmetric spikes.

Previously, there was a software solution for that. In the evaluation board software DRSOsc there is a button "Remove spikes" which tries to fix this in software. Although this works most of the time, it's annoying and not 100% safe. Like when the spike sits on top of a noise signal, it might not be recognized. Fixing this in hardware is however straight forwar. After the readout cycle ends, push the read bit out of the chip:

  • Address the read shift register by applying 1011b to A3:A0
  • Switch SRIN low
  • Apply 1024 clock cycles to SRCLK

This shifts the bit out of the chip, so that the next event is not affected by the read bit. The third attachment show the effect of this. The "clear cycle" increases the readout time a little bit, but depending on the application this might be worth it.

Regards,
Stefan

 

 

  716   Thu Sep 13 18:09:13 2018 Martin Petriska"Symmetric spikes" fixed

Ok, so I made it ... and Yes it works :), 

https://youtu.be/0noy4CoFoh8 

here is changed part in drs4_eval4_app.vhd

               
        when done =>
          drs_readout_state    <= spikeoff;
          drs_stat_busy        <= '0';
          drs_dpram_we1        <= '0';
          drs_write_set        <= '1';   -- set drs_write_ff in proc_drs_write
                                         -- to keep chip "warm"

 -- spike fix ELOG 697        
 
          when spikeoff => 
            o_drs_addr       <= "1011"; -- Address the read shift register by applying 1011b to A3:A0
            o_drs_srin       <= '0'; -- Switch SRIN low             
             drs_readout_state                 <= spikecycle;
             -- Apply 1024 clock cycles to SRCLK     
             drs_sr_count         <= 0;

          when spikecycle =>      
             drs_sr_count         <= drs_sr_count + 1;
             o_drs_srclk          <= not o_drs_srclk;
             if (drs_sr_count = 1024) then
                drs_readout_state <= idle;
             end if;      


        -- set-up of configuration register        

Stefan Ritt wrote:

Yes it's possible, but I have to find time for that. The software of the evaluation board takes care of the spikes ("remove spikes"), so I thought it's not so urgent to fix that in the FPGA (which takes me some time).

Stefan

Martin Petriska wrote:

Hi,

Is it possible to fix it by FPGA changes?  I see readout cycle (proc_drs_reedout) in drs4_eval(4)5_app.vhd, but not sure where to exactly put this three commands. Could you please attach app.vhd file for eval board with example how to fix ?

Regards,

Martin

 

Stefan Ritt wrote:

Good news for all DRS4 users. After many years, I finally understand where the "symmetric spikes" come from and how to fix them.

The "symmetric spikes" are small spikes of 17-18mV, which randomly happen at 1-2 cells. They alwas come in groups of 2 in each channel, symmetric around sampling cell #512. See first attachment.

The reason for the spikes is the previous readout cycle. On each readout cycle, the "read bit" is clocked through all 1024 cells to switch one cell contents to the DRS4 output. At the end of the 1024 cycles, the read bit stays at its last position. The bit is carried by a metal line on the chip, which crosses all 9 channels (second attachment). This bit now influences the sampling cells below the metal line capacitively, so their contents is "pushed up" by a few mV, just like the ROFS offset does. Since the DRS sampling channels are in a snake layout, going 0-512 from left, then 512-1023 back again, the line crosses two cells in each channel, and thus the symmetric spikes.

Previously, there was a software solution for that. In the evaluation board software DRSOsc there is a button "Remove spikes" which tries to fix this in software. Although this works most of the time, it's annoying and not 100% safe. Like when the spike sits on top of a noise signal, it might not be recognized. Fixing this in hardware is however straight forwar. After the readout cycle ends, push the read bit out of the chip:

  • Address the read shift register by applying 1011b to A3:A0
  • Switch SRIN low
  • Apply 1024 clock cycles to SRCLK

This shifts the bit out of the chip, so that the next event is not affected by the read bit. The third attachment show the effect of this. The "clear cycle" increases the readout time a little bit, but depending on the application this might be worth it.

Regards,
Stefan

 

 

 

  717   Sun Sep 23 02:22:46 2018 Gerard Arino-EstradaTrigger OUT pulse width variable from 100 us up to 100 ms

Hello Stefan,

I am using the DRS4 board connected to a Raspberry PI and through the drsosc application. I am interested on using the "Trigger OUT" signal to do some extra data processing with NIM modules. According to the manual, for each hardware trigger a TTL pulse of 150 ns width should be send through the "trigger OUT". In my case I do see pulses with widths ranging from 100 microseconds up to hundreds of miliseconds. I am connecting the signal directly to an oscilloscope with 50 Ohm termination. I have tried two DRS4 boards in identical conditions and both show the same behavior.  Having such wide and variable pulses makes it complicated for me to do the extra post-processing. Have you any idea of what might be going wrong? Thank you very much.

Best regards,

Gerard

  718   Wed Sep 26 14:44:14 2018 Stefan RittTrigger OUT pulse width variable from 100 us up to 100 ms

The "Trigger OUT" has changed recently. It goes high on a new trigger, but then STAYS high until the board has been read out by the PC and re-started. This allows better synchronization with some external trigger, which can be re-armed with the falling edge of the trigger out signal. The signal can be quite long, since readout of an event via USB typically takes 2 ms, but can be more if the PC is busy. If you need back your 150 ns pulse, send the trigger out to an external pulse shaper with fixed shaping width.

Stefan

Gerard Arino-Estrada wrote:

Hello Stefan,

I am using the DRS4 board connected to a Raspberry PI and through the drsosc application. I am interested on using the "Trigger OUT" signal to do some extra data processing with NIM modules. According to the manual, for each hardware trigger a TTL pulse of 150 ns width should be send through the "trigger OUT". In my case I do see pulses with widths ranging from 100 microseconds up to hundreds of miliseconds. I am connecting the signal directly to an oscilloscope with 50 Ohm termination. I have tried two DRS4 boards in identical conditions and both show the same behavior.  Having such wide and variable pulses makes it complicated for me to do the extra post-processing. Have you any idea of what might be going wrong? Thank you very much.

Best regards,

Gerard

 

  Draft   Wed Sep 26 18:25:07 2018 Gerard Arino-EstradaTrigger OUT pulse width variable from 100 us up to 100 ms

Thank you very much for the answer, I really appreciate your help.

Thanks!

Gerard

Stefan Ritt wrote:

The "Trigger OUT" has changed recently. It goes high on a new trigger, but then STAYS high until the board has been read out by the PC and re-started. This allows better synchronization with some external trigger, which can be re-armed with the falling edge of the trigger out signal. The signal can be quite long, since readout of an event via USB typically takes 2 ms, but can be more if the PC is busy. If you need back your 150 ns pulse, send the trigger out to an external pulse shaper with fixed shaping width.

Stefan

Gerard Arino-Estrada wrote:

Hello Stefan,

I am using the DRS4 board connected to a Raspberry PI and through the drsosc application. I am interested on using the "Trigger OUT" signal to do some extra data processing with NIM modules. According to the manual, for each hardware trigger a TTL pulse of 150 ns width should be send through the "trigger OUT". In my case I do see pulses with widths ranging from 100 microseconds up to hundreds of miliseconds. I am connecting the signal directly to an oscilloscope with 50 Ohm termination. I have tried two DRS4 boards in identical conditions and both show the same behavior.  Having such wide and variable pulses makes it complicated for me to do the extra post-processing. Have you any idea of what might be going wrong? Thank you very much.

Best regards,

Gerard

 

 

  720   Wed Sep 26 18:28:20 2018 Gerard Arino-EstradaTrigger OUT pulse width variable from 100 us up to 100 ms

Thank you very much for the answer, I really appreciate your help.

Thanks!

Gerard

Stefan Ritt wrote:

The "Trigger OUT" has changed recently. It goes high on a new trigger, but then STAYS high until the board has been read out by the PC and re-started. This allows better synchronization with some external trigger, which can be re-armed with the falling edge of the trigger out signal. The signal can be quite long, since readout of an event via USB typically takes 2 ms, but can be more if the PC is busy. If you need back your 150 ns pulse, send the trigger out to an external pulse shaper with fixed shaping width.

Stefan

Gerard Arino-Estrada wrote:

Hello Stefan,

I am using the DRS4 board connected to a Raspberry PI and through the drsosc application. I am interested on using the "Trigger OUT" signal to do some extra data processing with NIM modules. According to the manual, for each hardware trigger a TTL pulse of 150 ns width should be send through the "trigger OUT". In my case I do see pulses with widths ranging from 100 microseconds up to hundreds of miliseconds. I am connecting the signal directly to an oscilloscope with 50 Ohm termination. I have tried two DRS4 boards in identical conditions and both show the same behavior.  Having such wide and variable pulses makes it complicated for me to do the extra post-processing. Have you any idea of what might be going wrong? Thank you very much.

Best regards,

Gerard

 

 

  721   Wed Sep 26 19:21:03 2018 Stefan RittTrigger 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

 

  722   Mon Nov 5 17:17:08 2018 Sean QuinnPi attenuator on eval board inputs?

Dear DRS4 team,

 

I am curious about this part of the circuit:

What is the purpose of this?

  723   Thu Nov 8 09:57:26 2018 Stefan RittPi 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?

 

  724   Thu Nov 8 11:44:35 2018 Davide DepaoliTiming 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
  725   Thu Nov 8 11:54:33 2018 Stefan RittTiming 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
  726   Thu Nov 8 12:02:34 2018 Davide DepaoliTiming 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
  727   Tue Jan 29 14:43:44 2019 Abaz KryemadhiROOT 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

  728   Wed Jan 30 06:51:37 2019 Saurabh NeemaDRS4 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,

 

  729   Wed Jan 30 08:02:25 2019 Stefan RittDRS4 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,

 

 

  730   Wed Jan 30 17:08:58 2019 Stefan RittROOT 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

 

  731   Sat Feb 2 00:13:12 2019 Hans SteigerSaving 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 

  732   Sat Feb 2 10:10:22 2019 Stefan RittSaving 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 

 

  733   Mon Feb 4 16:42:08 2019 Hans SteigerDifferent 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

  734   Mon Feb 4 16:46:04 2019 Stefan RittDifferent 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

 

ELOG V3.1.4-80633ba