ID 
Date 
Author 
Subject 
140

Wed Dec 14 00:44:37 2011 
Hao Huan  Synchronization Delay in the Firmware for 8051 Controller  Hi Stefan,
I have a question regarding the DRS 4 evaluation board firmware for the 8051 controller embedded in the CY7C68013 USB chip: on the board the controller is running at 12 MHz and the FIFO interface of the USB chip is running at 30 MHz, so the number of delay cycles for synchronization as defined in fx2sdly.h should be (3*12000+5*300001)/(2*30000)=3, but the actual number used in drs_eval.c is (3*12000+5*480001)/(2*48000)=2, so there is a mismatch between the IFCLK frequency used in this calculation and the actual IFCLK frequency configured. Am I misunderstanding something or is there an explanation for that?
Thanks,
Hao Huan 
139

Mon Dec 12 16:43:04 2011 
Stefan Ritt  DC coupled DRS4 input stage  In the attachement you will find a working DCcoupled input stage to the DRS4 chip. The bandwidth of this design is about 700 MHz, the gain is 1.
The upper version does not have an additional input buffer. This is not a very "clean" design, since the differential driver has an input impedance of 150 Ohm, which together with the 75 Ohm termination resistor gives about 50 Ohm termination.
The lover version has an additional input buffer, which nicely decouples the input from the differential driver, so a proper 50 Ohm termination can be used at the cost of additional power for that buffer.
The COM common mode voltage and the OFS voltage have to be set according to the required input range, so that ranges such as 0V...1V, 0.5V...+0.5V, 1V...0V can be used. The COM voltage can be high impedance (simple resistor divider), while the OFS voltage needs to be low impedance (fast active buffer). The analog switch ADG918 can be used to digitize a precise calibration voltage CAL+, which can then be used for precise gain calibration of the DRS4 sampling cells. 
138

Fri Dec 9 17:45:48 2011 
Michael Büker  Fixes to DOScreen.cpp for recent built on linux  > I was just building version 3.1.0 and ran into some problems in DOScreen.cpp. Basically the conversions from
> char* to wxString were generating "ambiguous overload" errors (in gcc 4.4.3, wx2.8)
>
> The simple fix is given in the following diff output.
Today, I ran into the same problem and was happy to find your fix. I've incorporated it into a unified diff file,
that can easily be applied with the patch program by saving it into a file ('drsosc3.1.0wxfix.patch', say), and
in the drs3.1.0 directory running:
patch 1 < drsosc3.1.0wxfix.patch
This is the file:
 src/DOScreen.cpp.orig 20111209 15:49:48.682201902 +0100
+++ src/DOScreen.cpp 20111209 15:51:45.666000111 +0100
@@ 234,7 +234,7 @@ void DOScreen::DrawWaveform(wxDC& dc, wx
// display optional debug messages
if (*m_frame>GetOsci()>GetDebugMsg()) {
 wxst = m_frame>GetOsci()>GetDebugMsg();
+ wxst = wxString(m_frame>GetOsci()>GetDebugMsg(),wxConvUTF8);
dc.SetPen(wxPen(*wxLIGHT_GREY, 1, wxSOLID));
dc.SetBrush(*wxGREEN);
dc.SetTextForeground(*wxBLACK);
@@ 243,7 +243,7 @@ void DOScreen::DrawWaveform(wxDC& dc, wx
dc.DrawText(wxst, m_x1+4, m_y1+2);
}
if (m_debugMsg[0]) {
 wxst = m_debugMsg;
+ wxst = wxString(m_debugMsg,wxConvUTF8);
dc.SetPen(wxPen(*wxLIGHT_GREY, 1, wxSOLID));
dc.SetBrush(*wxGREEN);
dc.SetTextForeground(*wxBLACK);
@@ 474,9 +474,9 @@ void DOScreen::DrawWaveform(wxDC& dc, wx
if (m_osci>GetNumberOfBoards() && m_osci>IsIdle()) {
dc.SetTextForeground(*wxGREEN);
if (m_osci>GetTriggerMode() == TM_AUTO)
 wxst = "AUTO";
+ wxst = wxString("AUTO",wxConvUTF8);
else
 wxst = "TRIG?";
+ wxst = wxString("TRIG?",wxConvUTF8);
dc.GetTextExtent(wxst, &w, &h);
dc.DrawText(wxst, m_x2  w  2, m_y1 + 1);
} 
137

Tue Nov 1 11:07:02 2011 
Stefan Ritt  How to link PMT 
Zhongwei Du wrote: 
I want to measure the signal from PMT . But it is a current signal, should i just put a series resistance, or use a amplifier to convert it to voltage signal before drs4?
Can you give me some advice ?

The evaluation board has a 50 Ohm termination resistor, which already converts your current into a voltage signal. If the resulting signal is too low (<20 mV) you can put in an amplifier or raise the HV of your PMT (inside the valid range given by its datasheet of course).
 Stefan 
136

Mon Oct 31 09:15:02 2011 
Zhongwei Du  How to link PMT  I want to measure the signal from PMT . But it is a current signal, should i just put a series resistance, or use a amplifier to convert it to voltage signal before drs4?
Can you give me some advice ? 
135

Mon Oct 24 10:30:15 2011 
Stefan Ritt  Phase Shift for ADC Readout 
Hao Huan wrote: 
Dear Dr. Ritt,
In the DRS 4 datasheet it is recommended to sample the analog output of the chip after 8~10 ns of the SRCLK edge for it to stablize and thus a phase shift between SRCLK and the ADC sampling clock is necessary. However in the latest version of the evaluation board firmware the phaseshifted clock was generated but not really used for the ADC interface. Is there any reason for that?

Good questions. I looked myself in the code and found:
drs_readout_clk <= I_CLK33;
drs_readout_clk_ps <= I_CLK33;  phase shifted clock for FADC
drs_serial_clk <= I_CLK33;
which is apparently wrong (should be drs_readout_clk_ps <= I_CLK33_PS;) . But apparently the board is working with the unshifted clock. Could be that the PCB traces to the DRS and the ADC have different lengths, and by accident, they have just the right value.
The way to find that out is to keep the ADC clock phase variable (most FPGAs allow a +5 ns phase adjustment inside their clock blocks), and then try different values. If the phase shift is wrong, you will see spikes every 32 samples in the readout. The spikes are always there (from some internal switching of bus segments), and you can see them with a differential probe at the DRS output. The ADC phase must then be made such that the sampling point of the ADC comes after that spike, just at the end of the settling time, barely before the next analog value shows up at the DRS output. This is a bit tricky and can be made best just by trying out different values. 
134

Sun Oct 23 23:32:28 2011 
Hao Huan  Phase Shift for ADC Readout  Dear Dr. Ritt,
In the DRS 4 datasheet it is recommended to sample the analog output of the chip after 8~10 ns of the SRCLK edge for it to stablize and thus a phase shift between SRCLK and the ADC sampling clock is necessary. However in the latest version of the evaluation board firmware the phaseshifted clock was generated but not really used for the ADC interface. Is there any reason for that? 
133

Sat Oct 22 00:40:02 2011 
Stefan Ritt  DRS4 eval board: readout rate 
Aurelien Bouvier wrote: 
Hi,
Our setup uses a DRS4 evaluation board (version 2.0).
Although we trigger the board at a rate of ~4kHz (on channel2), readout through USB2 is only happening at a rate of ~125Hz.
After some investigation, we could pin down that it is due to the time it takes to complete the following commands: musb_write() and musb_read() which both take ~150 microsecond to complete. Because they are called multiple times, reading out 1 trigger takes ~8 millisecond which explains the 125Hz we're seeing.
Is ~150 us to complete a musb_read()/musb_write() command expected?
Is there any way we could speed up the readout rate of the DRS4 board so that data acquisition through USB2 is closer to our trigger rate of 4kHz?
Any feedback you might have on this topic would be greatly appreciated.
Many thanks,
Aurelien

With version 4 of the DRSOsc program and a decent computer, you should be able to achieve something close to 500 Hz, but that's the limit. The board is for evaluation purposes of the chip, not for production data acquisition. The main limit comes from USB2, which is limited to ~25 MB/sec. We are in the process of designing a new board with Gigabit Ethernet readout, with which you should be able to get your 4 kHz. But this board will not be ready before spring. There is also a VME board by CAEN in Italy which sits in a VME crate. This board is also much faster than the USB board. Here is the link:
http://www.caen.it/csite/CaenProfList.jsp?parent=13&Type=WOCateg&prodsupp=home

132

Sat Oct 15 04:45:25 2011 
Aurelien Bouvier  DRS4 eval board: readout rate  Hi,
Our setup uses a DRS4 evaluation board (version 2.0).
Although we trigger the board at a rate of ~4kHz (on channel2), readout through USB2 is only happening at a rate of ~125Hz.
After some investigation, we could pin down that it is due to the time it takes to complete the following commands: musb_write() and musb_read() which both take ~150 microsecond to complete. Because they are called multiple times, reading out 1 trigger takes ~8 millisecond which explains the 125Hz we're seeing.
Is ~150 us to complete a musb_read()/musb_write() command expected?
Is there any way we could speed up the readout rate of the DRS4 board so that data acquisition through USB2 is closer to our trigger rate of 4kHz?
Any feedback you might have on this topic would be greatly appreciated.
Many thanks,
Aurelien 
131

Mon Sep 19 08:53:22 2011 
Stefan Ritt  compilation error for version 4.0.0 on linux 
Andriy Zatserklyaniy wrote: 
To fix it I added TriggerDialog.o into CPP_OBJ line of the Makefile:

Thanks. I added your fix to the current 4.0.0 distribution.
 Stefan 
130

Fri Sep 16 22:06:07 2011 
Andriy Zatserklyaniy  compilation error for version 4.0.0 on linux  Hi Stefan,
When I compiled DRS4 software version 4.0.0 on Linux (Debian Squeeze) I got this compilation error:
g++ g O2 Wall Wuninitialized fnostrictaliasing Iinclude DOS_LINUX DHAVE_LIBUSB DUSE_DRS_MUTEX musbstd.o mxml.o strlcpy.o DRS.o ConfigDialog.o DOFrame.o DOScreen.o DRSOsc.o MeasureDialog.o Measurement.o Osci.o InfoDialog.o DisplayDialog.o AboutDialog.o EPThread.o rb.o main.o o drsosc lpthread lutil lusb pthread lwx_gtk2u_richtext2.8 lwx_gtk2u_aui2.8 lwx_gtk2u_xrc2.8 lwx_gtk2u_qa2.8 lwx_gtk2u_html2.8 lwx_gtk2u_adv2.8 lwx_gtk2u_core2.8 lwx_baseu_xml2.8 lwx_baseu_net2.8 lwx_baseu2.8
DOFrame.o: In function `DOFrame':
/srv/zatserkl/work/drs4/drs4.0.0/src/DOFrame.cpp:237: undefined reference to `TriggerDialog::TriggerDialog(wxWindow*)'
/srv/zatserkl/work/drs4/drs4.0.0/src/DOFrame.cpp:237: undefined reference to `TriggerDialog::TriggerDialog(wxWindow*)'
collect2: ld returned 1 exit status
make: *** [drsosc] Error 1
To fix it I added TriggerDialog.o into CPP_OBJ line of the Makefile:
CPP_OBJ = DRS.o ConfigDialog.o DOFrame.o DOScreen.o DRSOsc.o MeasureDialog.o Measurement.o Osci.o InfoDialog.o DisplayDialog.o AboutDialog.o EPThread.o rb.o TriggerDialog.o
Best,
Andriy. 
129

Fri Sep 9 09:31:33 2011 
Stefan Ritt  DRS4 and AD9222 
Guillaume Blanchard wrote: 
Thank you for your answers,
Another question : Have you ever tried to split the differential signal at the output of the DRS4 chip ? For example to feed both an AD9222 and a diff. amplifier (followed by discriminators) ?

Yes. Just have a look at the schematics of the evaluation board. This is exactly what is done there.
Actually in the newest version we went one step further and put the comparator at the input of the DRS chip. This way it is active even during the readout of the DRS4 chip and we can use this as a counter to count the overall hit rate at the input.
 Stefan 
128

Fri Sep 9 09:28:57 2011 
Guillaume Blanchard  DRS4 and AD9222  Thank you for your answers,
Another question : Have you ever tried to split the differential signal at the output of the DRS4 chip ? For example to feed both an AD9222 and a diff. amplifier (followed by discriminators) ?

127

Wed Sep 7 17:28:25 2011 
Hannes Friederich  DRS4 and AD9222 
Guillaume Blanchard wrote: 
Hello,
I am designing a DAQ board with both DRS4 + AD9222 and a FPGA to monitor.
Do I have to change the default value of OOFS ?
Does a simple lowpass filter (series resistor + capacitor) on each AD9222 input is enough to limit the noise ?
I am planning to use the (DRS4,AD9222,FPGA) group as both a trigger and digitizing system (as shown in the DRS4 datasheet). The DRS4 will be working at 5Ghz with 8 active channels.
So each channel will have a time depth of 1/5Ghz x 1024 = 204.8ns. So, in order to miss nothing, the ADC latency + the trigger decision must be inferior to 204.8ns, am I correct ?
This leads me to implement on my board the 65Mhz version of the AD9222 as this converter has a 8 clock period latency, i.e. 123ns and it left me 81ns to perform a trigger decision ?
Cordially,
G.Blanchard

Like Stefan pointed out, your time constraints are quite tight. In those 81 ns, you also need to deserialize the AD9222 output. Unless you implement some really fancy input comparison logic, this will consume another 12 ADC clock cycles. Perhaps you should first verify that your FPGA design actually can do its job within those 81 ns. In our system, we sample at only 12 GHz and have enough margin to implement really complex triggers in FPGA. But the total latency (ADC + FPGA deserialization) takes 250 ns.
Depending on the application, you do need a lowpass filter. Not only because of the noise, but also in order to be able to trigger reliably. Using fast PMTs for example, you will not be able to see all pulses in full size if the bandwidth is 50 MHz and you're only sampling at 65 MSPS.
Hannes 
126

Wed Sep 7 16:56:43 2011 
Stefan Ritt  DRS4 and AD9222 
Guillaume Blanchard wrote: 
Hello,
I am designing a DAQ board with both DRS4 + AD9222 and a FPGA to monitor.
Do I have to change the default value of OOFS ?
Does a simple lowpass filter (series resistor + capacitor) on each AD9222 input is enough to limit the noise ?
I am planning to use the (DRS4,AD9222,FPGA) group as both a trigger and digitizing system (as shown in the DRS4 datasheet). The DRS4 will be working at 5Ghz with 8 active channels.
So each channel will have a time depth of 1/5Ghz x 1024 = 204.8ns. So, in order to miss nothing, the ADC latency + the trigger decision must be inferior to 204.8ns, am I correct ?
This leads me to implement on my board the 65Mhz version of the AD9222 as this converter has a 8 clock period latency, i.e. 123ns and it left me 81ns to perform a trigger decision ?
Cordially,
G.Blanchard

I'm not so sure about the temperature stability of the default (DRS4 internal OOFS) value, that's why I used a precision DAC in my design. But actually I never tried without. Probably the default internal value is good enough if you calibrate each chip (which you do anyhow).
Most designs use no filter between DRS4 and AD9222. Since the DRS4 output is BW limited at around 50 MHz, there is not much you win if you put a 32.5 MHz low pass there. And the PCS gets just so much simpler.
You are right with the latency of the AD9222, this is an issue. From the remaining 81 ns you loose a few going out of the FPGA, you need one or two FPGA clock cycles to make the decision, the DRS4 has also some stopping latency (maybe 10 ns). So you are at the edge. Some people use hardware comparators which are faster than the AD9222, one guy uses even directly an LVDS input of the FPGA "misused" as a comparator, where the comparator level (=LVDS negative input) comes from a DAC.
 Stefan 
125

Wed Sep 7 16:45:17 2011 
Guillaume Blanchard  DRS4 and AD9222 
Hello,
I am designing a DAQ board with both DRS4 + AD9222 and a FPGA to monitor.
Do I have to change the default value of OOFS ?
Does a simple lowpass filter (series resistor + capacitor) on each AD9222 input is enough to limit the noise ?
I am planning to use the (DRS4,AD9222,FPGA) group as both a trigger and digitizing system (as shown in the DRS4 datasheet). The DRS4 will be working at 5Ghz with 8 active channels.
So each channel will have a time depth of 1/5Ghz x 1024 = 204.8ns. So, in order to miss nothing, the ADC latency + the trigger decision must be inferior to 204.8ns, am I correct ?
This leads me to implement on my board the 65Mhz version of the AD9222 as this converter has a 8 clock period latency, i.e. 123ns and it left me 81ns to perform a trigger decision ?
Cordially,
G.Blanchard 
124

Wed Jul 13 04:26:52 2011 
Stefan Ritt  Fixed Patter Timing Jitter 
Jinhong Wang wrote: 
Stefan Ritt wrote: 
Jinhong Wang wrote: 
Stefan Ritt wrote: 
Jinhong Wang wrote: 
Hi Stefan, can you give some suggestions on determination of fixed pattern timing jitter of DRS4? Thanks~

I will prepare some more detailed description of how to do this in the near future, but we are still learning ourselves constantly how to do that better.
So for the moment I only can recommend you to read the function DRSBoard::CalibrateTiming() and AnalyzeWF(). What you basically do is to define an array of "effective" bin widths t[i]. You start with the nominal bin width (let's say 500ps at 2 GSPS). Now you measure a periodic signal, and look for the zero crossings. If you have a 100 MHz clock, the time between two positive transitions (lowtohigh) is 10.000ns. Now you measure the width as seen by the DRS chip, assuming the effective bin widths. The exact zero crossing you interpolate between two samples to improve the accuracy. Now you measure something different, let's say 10.1ns. So you know the ~20 bins between the zero crossings are "too wide", but you don't know which one of them is too wide. So you distribute the "too wide" equally between all bins, that is you decrease the effective width of these bins from 500ps to 5000.1ns/20=499.995 ps. Then you do this iteratively, that is for all cycles in the waveform, and for many (1000's) of recorded waveforms. It is important that the phase of you measured clock is random, so that all bins are covered equally. Then you realize that the solution oscillates, which you can reduce by using a damping factor (called "damping" in my C code). So you do not correct to 499.995ps, but maybe to 499.999ps. If you iterate often enough, the solution kind of stabilizes.
The attached picture shows the result of such a calibration. Green is the effective bin width which in the end only slightly deviates from 500ps. But the "integral temporal nonlinearity" shows a typical shape for the DRS chip. It's defined as
n
Ti[n] = Sum (t[i]500ps)
i=0
where t[i] is the effective bin width. So Ti[0] is zero by definition, but the deviation around bin 450 can go up to 1ns at 2 GSPS.
Now you can test you calibration, by measuring again the period of your clock. If you do everything correctly and have a low jitter external clock and no noise on your DRS4 power supply voltages, you should see a residual jitter of about 40ps.
Hope this explanation helps a bit. Let me know if I was not clear enough at some points.
 Stefan

Hi, Stefan,
I noticed other groups of SCA reported the technique to histogram the zero crossings of a sine wave, and use the bin occupancy to derive the effective aperture width. Recently , I tried this technique to DRS4. In my test, the frequency of the sine wave was selected uncorrelated to the domino frequency.The results were discouraging. Large variations of the domino tap delay was observed. Besides, I also tried to induce an external trigger, which is uncorrelated to the domino frequency, and histogram the stop positions. Unfortunately, large variations were obtained again. I knew there must be something wrong. Do you have any suggestions?
The attachment is the histogram of the stop positions (the vertical axis is the bin count, the horizontal axis is the bin number). First, I calculate the ration of each bin count to the total counts, supposed the total count is 10000, count of bin 37 is 12, so the corresponding ratio is 12/10000=0.0012. The bin delay is derived by multiplying its ratio to the whole domino period (1024*1/FSamp, eg., for 5 GSP/s, this period is 200ps *1024). (The bin delay i observed was with an variation of about 30 ps). If the external trigger is uncorrelated to the domino frequency, so, the stop positions are supposed to distribute equally to all bins? If this is true, can i calculate the bin delay via the histogram ?
thank you~
Wang Jinhong

One obvious problem in your method is your statistics. If you have n hits in a bin of the histogram, the error of n is sqrt(n). So if you measure 100 hits, this is more like 100+10 hits. If you want a better precision, you need much higher statistics. I myself never used this method, but I attach a typical nonlinearity curve running at 2 GSPS, sot hat you know what you should expect. I do some smoothing between neighbor bins so that they do not scatter too much. As you can see, the integral nonlinearity goes almost up to +2 ns. This value is smaller at higher sampling speeds.
 Stefan

Thank you, Stefan. It is really kind of you to offer suggestions or comments on our concern.
Recently, we input a sine wave to our DRS board. DRS works at about 5 GS/s. The frequency varies from 131 MHz to 231MHz. The attached picture shows the reconstructed points of sine wave (vertical is the amplitude, horizontal axis is the point numbers). We noticed that the variation of the length of the zero crossing segments is very large. The max. length is perhaps two times the length of the min. I marked in blue color in the picture. It means the corresponding sampling interval of the max. is two times of that of the min. If this is true, DNL of the DRS sampling interval would be very large. We know, for uniform sampling, the length of the zero crossing segments are assumed to be uniform. Do you have any comments? Thank you~

The length of the segments is a combination of the sampling jitter and the voltage noise. If you signal contains some noise (and all signals do) it will translate to timing jitter. The DNL of the DRS sampling interval shows a variation from the mean of typically 30%. After you correct for it, it will of course become much smaller. As I said, some people measured 10 ps timing with the DRS4 after careful timing calibration. 
123

Tue Jul 12 09:49:08 2011 
Jinhong Wang  Fixed Patter Timing Jitter 
Stefan Ritt wrote: 
Jinhong Wang wrote: 
Stefan Ritt wrote: 
Jinhong Wang wrote: 
Hi Stefan, can you give some suggestions on determination of fixed pattern timing jitter of DRS4? Thanks~

I will prepare some more detailed description of how to do this in the near future, but we are still learning ourselves constantly how to do that better.
So for the moment I only can recommend you to read the function DRSBoard::CalibrateTiming() and AnalyzeWF(). What you basically do is to define an array of "effective" bin widths t[i]. You start with the nominal bin width (let's say 500ps at 2 GSPS). Now you measure a periodic signal, and look for the zero crossings. If you have a 100 MHz clock, the time between two positive transitions (lowtohigh) is 10.000ns. Now you measure the width as seen by the DRS chip, assuming the effective bin widths. The exact zero crossing you interpolate between two samples to improve the accuracy. Now you measure something different, let's say 10.1ns. So you know the ~20 bins between the zero crossings are "too wide", but you don't know which one of them is too wide. So you distribute the "too wide" equally between all bins, that is you decrease the effective width of these bins from 500ps to 5000.1ns/20=499.995 ps. Then you do this iteratively, that is for all cycles in the waveform, and for many (1000's) of recorded waveforms. It is important that the phase of you measured clock is random, so that all bins are covered equally. Then you realize that the solution oscillates, which you can reduce by using a damping factor (called "damping" in my C code). So you do not correct to 499.995ps, but maybe to 499.999ps. If you iterate often enough, the solution kind of stabilizes.
The attached picture shows the result of such a calibration. Green is the effective bin width which in the end only slightly deviates from 500ps. But the "integral temporal nonlinearity" shows a typical shape for the DRS chip. It's defined as
n
Ti[n] = Sum (t[i]500ps)
i=0
where t[i] is the effective bin width. So Ti[0] is zero by definition, but the deviation around bin 450 can go up to 1ns at 2 GSPS.
Now you can test you calibration, by measuring again the period of your clock. If you do everything correctly and have a low jitter external clock and no noise on your DRS4 power supply voltages, you should see a residual jitter of about 40ps.
Hope this explanation helps a bit. Let me know if I was not clear enough at some points.
 Stefan

Hi, Stefan,
I noticed other groups of SCA reported the technique to histogram the zero crossings of a sine wave, and use the bin occupancy to derive the effective aperture width. Recently , I tried this technique to DRS4. In my test, the frequency of the sine wave was selected uncorrelated to the domino frequency.The results were discouraging. Large variations of the domino tap delay was observed. Besides, I also tried to induce an external trigger, which is uncorrelated to the domino frequency, and histogram the stop positions. Unfortunately, large variations were obtained again. I knew there must be something wrong. Do you have any suggestions?
The attachment is the histogram of the stop positions (the vertical axis is the bin count, the horizontal axis is the bin number). First, I calculate the ration of each bin count to the total counts, supposed the total count is 10000, count of bin 37 is 12, so the corresponding ratio is 12/10000=0.0012. The bin delay is derived by multiplying its ratio to the whole domino period (1024*1/FSamp, eg., for 5 GSP/s, this period is 200ps *1024). (The bin delay i observed was with an variation of about 30 ps). If the external trigger is uncorrelated to the domino frequency, so, the stop positions are supposed to distribute equally to all bins? If this is true, can i calculate the bin delay via the histogram ?
thank you~
Wang Jinhong

One obvious problem in your method is your statistics. If you have n hits in a bin of the histogram, the error of n is sqrt(n). So if you measure 100 hits, this is more like 100+10 hits. If you want a better precision, you need much higher statistics. I myself never used this method, but I attach a typical nonlinearity curve running at 2 GSPS, sot hat you know what you should expect. I do some smoothing between neighbor bins so that they do not scatter too much. As you can see, the integral nonlinearity goes almost up to +2 ns. This value is smaller at higher sampling speeds.
 Stefan

Thank you, Stefan. It is really kind of you to offer suggestions or comments on our concern.
Recently, we input a sine wave to our DRS board. DRS works at about 5 GS/s. The frequency varies from 131 MHz to 231MHz. The attached picture shows the reconstructed points of sine wave (vertical is the amplitude, horizontal axis is the point numbers). We noticed that the variation of the length of the zero crossing segments is very large. The max. length is perhaps two times the length of the min. I marked in blue color in the picture. It means the corresponding sampling interval of the max. is two times of that of the min. If this is true, DNL of the DRS sampling interval would be very large. We know, for uniform sampling, the length of the zero crossing segments are assumed to be uniform. Do you have any comments? Thank you~ 
122

Tue Jul 5 10:09:43 2011 
Stefan Ritt  Fixed Patter Timing Jitter 
Jinhong Wang wrote: 
Stefan Ritt wrote: 
Jinhong Wang wrote: 
Hi Stefan, can you give some suggestions on determination of fixed pattern timing jitter of DRS4? Thanks~

I will prepare some more detailed description of how to do this in the near future, but we are still learning ourselves constantly how to do that better.
So for the moment I only can recommend you to read the function DRSBoard::CalibrateTiming() and AnalyzeWF(). What you basically do is to define an array of "effective" bin widths t[i]. You start with the nominal bin width (let's say 500ps at 2 GSPS). Now you measure a periodic signal, and look for the zero crossings. If you have a 100 MHz clock, the time between two positive transitions (lowtohigh) is 10.000ns. Now you measure the width as seen by the DRS chip, assuming the effective bin widths. The exact zero crossing you interpolate between two samples to improve the accuracy. Now you measure something different, let's say 10.1ns. So you know the ~20 bins between the zero crossings are "too wide", but you don't know which one of them is too wide. So you distribute the "too wide" equally between all bins, that is you decrease the effective width of these bins from 500ps to 5000.1ns/20=499.995 ps. Then you do this iteratively, that is for all cycles in the waveform, and for many (1000's) of recorded waveforms. It is important that the phase of you measured clock is random, so that all bins are covered equally. Then you realize that the solution oscillates, which you can reduce by using a damping factor (called "damping" in my C code). So you do not correct to 499.995ps, but maybe to 499.999ps. If you iterate often enough, the solution kind of stabilizes.
The attached picture shows the result of such a calibration. Green is the effective bin width which in the end only slightly deviates from 500ps. But the "integral temporal nonlinearity" shows a typical shape for the DRS chip. It's defined as
n
Ti[n] = Sum (t[i]500ps)
i=0
where t[i] is the effective bin width. So Ti[0] is zero by definition, but the deviation around bin 450 can go up to 1ns at 2 GSPS.
Now you can test you calibration, by measuring again the period of your clock. If you do everything correctly and have a low jitter external clock and no noise on your DRS4 power supply voltages, you should see a residual jitter of about 40ps.
Hope this explanation helps a bit. Let me know if I was not clear enough at some points.
 Stefan

Hi, Stefan,
I noticed other groups of SCA reported the technique to histogram the zero crossings of a sine wave, and use the bin occupancy to derive the effective aperture width. Recently , I tried this technique to DRS4. In my test, the frequency of the sine wave was selected uncorrelated to the domino frequency.The results were discouraging. Large variations of the domino tap delay was observed. Besides, I also tried to induce an external trigger, which is uncorrelated to the domino frequency, and histogram the stop positions. Unfortunately, large variations were obtained again. I knew there must be something wrong. Do you have any suggestions?
The attachment is the histogram of the stop positions (the vertical axis is the bin count, the horizontal axis is the bin number). First, I calculate the ration of each bin count to the total counts, supposed the total count is 10000, count of bin 37 is 12, so the corresponding ratio is 12/10000=0.0012. The bin delay is derived by multiplying its ratio to the whole domino period (1024*1/FSamp, eg., for 5 GSP/s, this period is 200ps *1024). (The bin delay i observed was with an variation of about 30 ps). If the external trigger is uncorrelated to the domino frequency, so, the stop positions are supposed to distribute equally to all bins? If this is true, can i calculate the bin delay via the histogram ?
thank you~
Wang Jinhong

One obvious problem in your method is your statistics. If you have n hits in a bin of the histogram, the error of n is sqrt(n). So if you measure 100 hits, this is more like 100+10 hits. If you want a better precision, you need much higher statistics. I myself never used this method, but I attach a typical nonlinearity curve running at 2 GSPS, sot hat you know what you should expect. I do some smoothing between neighbor bins so that they do not scatter too much. As you can see, the integral nonlinearity goes almost up to +2 ns. This value is smaller at higher sampling speeds.
 Stefan 
121

Mon Jul 4 05:06:00 2011 
Jinhong Wang  Fixed Patter Timing Jitter 
Stefan Ritt wrote: 
Jinhong Wang wrote: 
Hi Stefan, can you give some suggestions on determination of fixed pattern timing jitter of DRS4? Thanks~

I will prepare some more detailed description of how to do this in the near future, but we are still learning ourselves constantly how to do that better.
So for the moment I only can recommend you to read the function DRSBoard::CalibrateTiming() and AnalyzeWF(). What you basically do is to define an array of "effective" bin widths t[i]. You start with the nominal bin width (let's say 500ps at 2 GSPS). Now you measure a periodic signal, and look for the zero crossings. If you have a 100 MHz clock, the time between two positive transitions (lowtohigh) is 10.000ns. Now you measure the width as seen by the DRS chip, assuming the effective bin widths. The exact zero crossing you interpolate between two samples to improve the accuracy. Now you measure something different, let's say 10.1ns. So you know the ~20 bins between the zero crossings are "too wide", but you don't know which one of them is too wide. So you distribute the "too wide" equally between all bins, that is you decrease the effective width of these bins from 500ps to 5000.1ns/20=499.995 ps. Then you do this iteratively, that is for all cycles in the waveform, and for many (1000's) of recorded waveforms. It is important that the phase of you measured clock is random, so that all bins are covered equally. Then you realize that the solution oscillates, which you can reduce by using a damping factor (called "damping" in my C code). So you do not correct to 499.995ps, but maybe to 499.999ps. If you iterate often enough, the solution kind of stabilizes.
The attached picture shows the result of such a calibration. Green is the effective bin width which in the end only slightly deviates from 500ps. But the "integral temporal nonlinearity" shows a typical shape for the DRS chip. It's defined as
n
Ti[n] = Sum (t[i]500ps)
i=0
where t[i] is the effective bin width. So Ti[0] is zero by definition, but the deviation around bin 450 can go up to 1ns at 2 GSPS.
Now you can test you calibration, by measuring again the period of your clock. If you do everything correctly and have a low jitter external clock and no noise on your DRS4 power supply voltages, you should see a residual jitter of about 40ps.
Hope this explanation helps a bit. Let me know if I was not clear enough at some points.
 Stefan

Hi, Stefan,
I noticed other groups of SCA reported the technique to histogram the zero crossings of a sine wave, and use the bin occupancy to derive the effective aperture width. Recently , I tried this technique to DRS4. In my test, the frequency of the sine wave was selected uncorrelated to the domino frequency.The results were discouraging. Large variations of the domino tap delay was observed. Besides, I also tried to induce an external trigger, which is uncorrelated to the domino frequency, and histogram the stop positions. Unfortunately, large variations were obtained again. I knew there must be something wrong. Do you have any suggestions?
The attachment is the histogram of the stop positions (the vertical axis is the bin count, the horizontal axis is the bin number). First, I calculate the ration of each bin count to the total counts, supposed the total count is 10000, count of bin 37 is 12, so the corresponding ratio is 12/10000=0.0012. The bin delay is derived by multiplying its ratio to the whole domino period (1024*1/FSamp, eg., for 5 GSP/s, this period is 200ps *1024). (The bin delay i observed was with an variation of about 30 ps). If the external trigger is uncorrelated to the domino frequency, so, the stop positions are supposed to distribute equally to all bins? If this is true, can i calculate the bin delay via the histogram ?
thank you~
Wang Jinhong 
