DRS4 Forum
  DRS4 Discussion Forum  Not logged in ELOG logo
Entry  Thu May 17 13:29:34 2018, Stefan Ritt, "Symmetric spikes" fixed with.pngScreen_Shot_2018-05-17_at_13.30.23_.pngwithout.png
    Reply  Mon Sep 3 11:17:26 2018, Martin Petriska, "Symmetric spikes" fixed 
       Reply  Tue Sep 4 13:04:30 2018, Stefan Ritt, "Symmetric spikes" fixed 
          Reply  Thu Sep 13 18:09:13 2018, Martin Petriska, "Symmetric spikes" fixed 
Message ID: 714     Entry time: Mon Sep 3 11:17:26 2018     In reply to: 697     Reply to this: 715
Author: Martin Petriska 
Subject: "Symmetric spikes" fixed 

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

 

ELOG V3.1.5-fe60aaf