Hi Stefan,

According to the datasheet DRS_rev09, the write signal is always 16 cells wide. So when the domino wave runs in infinite mode and be stopped by setting DENABLE low , there are always 16 cells capicitors tracking the input signal . It means that the effective sample cells is 1024-16=1008? That's confusing. 

Hallo,
I'm using DRS4 Evaluation Board Rev 4.0 and I'm trying to change the output of the samples to be an average of  #  measurements (1000 or even more)
during the process I have encountered some difficulties I hope you will be able to help me  with:

1. the DRS chip have 8 channels but the Evaluation board have only 4 channels. does the default mode of the DRS in the Evaluation Board is 1024 bins for each channel or 2048?

2. in the readout mode, does it samples all the 1024 bins waveform from a channel and then move to the next one, or after each bin it move to the next channel?

3. In the file "drs4_eval4_app.vhd", I have a problem finding the names of the signals that represents the registers bits which tell me what is the number of the bin (1-1024) the ADC is reading from the DRS, and the signals

that represents registers A0-A3. can you send me their names? 

4. In another matter- is the -0.5V to 0.5V is the  upper and lower  limit of the input (or just a working range), and if not what is the limit for AC?  is there a fuse on the board in case of overload from the input? (I didn't see  it in the User's Manual, but I didn't know if you will mention it there in case there is one).

thanks in advance and have a nice day,

Tmiron

Thank you for the answer.

Have a nice week,

Tmiron.

 Hi Stefan,

I'm trying to add the averaging feature to the oscilloscope instead. I have a basic knowledge in C++ so I'm having problem finding the initial place (places) of the data acquisition. furthermore, I saw you already made an averaging possibility for some of the features in the program at the measure window.
Can you please tell we in which of the programs of the Scope (and in what line if possible) can I find the initial\main data acquisition so I could follow it from there, and where is the location of the averaging function you already made?

have a nice week,

Tmiron

I have been trying to compile my changes to the program, but have a problem with the "wxWidgets". can you tell me which version of the wxWidgets and which c++ program did you use to built the drs4's scope program?

I'm using "microsoft visual c++ 2010 express", and the closest I got to compile something was with the wxWidgets 2.8.12 version (It's tell me I'm missing the file "wxmsw28d_core.lib" although I built it).

have a nice day,

Tmiron.

My problem is not with wxWidgets itself but with links your program is doing to the wxWidgets. if you can please tell me the wxWidget version you used, I'll use this one instead the version I'm using and I think it will solve the problem.

Tmiron.

 but was version 2.9.4 the one you used when you built  Version 4.0.0 of the DRS4 oscilloscope program, or was it an erilar version, and if so, do you remeber what version it was?

tmiron.

 Hi Stefan.

I managed to add the averaging possibility to the oscilloscope program, but it runs too slow, so now I'm tring to add this option to the example file you attached to the program (drs_exam.cpp).
My problem is that when I run the file is not passing  the stage of getting the trigger. (it just wait after writing the line "Waiting for trigger...")
When testing the software, I work with a signal of up to 10 MHz, limited in voltage to the DRS Eval 4 ability, and I connect the signal to channel 1,from it by default is supposed to get the trigger. I also tried to change the channel settings to other channels or external trigger, and use them,  but it still not working.

I found out that the problem is related to the line "while (b->IsBusy());" in the code, but I have a problem understanding what the function "IsBusy" do and how it's work.

Can you please explain me a bit what this function does?

have a nice day,

Tmiron

Hi satefan,

I did some debug on the DRSOsc program and saw that everywhere you used the function "IsBusy()", you used it with "SoftTrigger()", which (to my understanding) create a software trigger. did you used another function, other than "ISBusy", that check the hardware trigger?

have a nice day,

Tmiron.

 hallo stefan,

I managed to fixed the problem. The problem was with the number I inserted to the function "b->SetTriggerSource" th get external trigger (it suppose to be "16" and not "4" or "12" as I understood from the function's comments).

Right now I'm trying to speed up the number of wavefrom  per second. I'm using your  drs_exam.cpp program you wrote as my basic program. When you wrote it you used the function "b->StartDomino()" inside the loop, which means that before every trigger you gave him a command to start the domino-wave.

From  the "DRS4 datasheet" (page 8) I understand that I can bypass the need to restart the  domino-wave by using "b->SetDominoActive(1)" and "b->SetDominoMode(1)", but when I tried it didn't work (the waveform I got every readout remain the same which means the dominowave froze after the first readout).

Am I understanding wrong or do I need to add somthing more\else so the domino-wave will not stop after each readout? is there any hazard by doing that, as mentiond in page 8 of the the datasheet?

thanks again,

Tmiron.

Hello, everyone.
I'm a student in Japan.
Please forgive me if this is a very rudimentary question.

Am I right in thinking that inputting 1 to DMODE (Bit0) in the configuration register will connect the 1024th cell to the 1st cell?

Also, let's assume that after sampling 1024 cells on channel 0, 200 cells are sampled in the second week.
Does the readout of 1024 cells start from cell 0?
Or does it start from the 200th cell?

Dear Stefan

Thanks a lot.

I solved it.

Hello Sir,

Regarding to analog pulse counting by using DRS4 Rev.2.0 board, you have said that "There is a way to perform the counting dead time free, but that requires the V4 board, which has a hardware comparator on all four channels (The V2 board has only one comparator and a multiplexer). The output of these comparators go directly to the FPGA, which can then trigger on these signals. In principle one could implement a hardware counter in the FPGA, which works practically dead time free. But this requires a new firmware which has to be written. Either you do it yourself using the Xilinx development tools, or you wait until I find some time to implement this, which could take a couple of weeks or even months."

I am interested in it. I have DRS4 Rev.2.0 board. I have FPGA and Microcontroller firmware for this board. How can I implement this concept of counting pulses?

I am having a general problem getting read back using the ROI mode.  In the transparent mode everything looks good. These are the steps that I take:

1) configure register (b"11111111",addr = "1100")

2) configure write shift register (b"11111111", addr = "1101")

3)  assert DENABLE and DWRITE

4) wait for trigger

5) on trigger deassert DWRITE

6) Strobe RSRLOAD

7)Set drs4 address to enable all channels (address = "1001")

8)give n SRCLK pulses

9) goto 3 and repeat.

Am I missing something? Everything looks straight forward based on the manual yet in the readout mode I only get noise. I do get the stop position on SROUT and the refclk is at 475 KHz as desired and I get the desired behaviour  for DTAP toggling at the same frequency as refclk.

Thanks for replying Stefan.

I was more so just concerned with the steps in the firmware when I had asked. However, yes the ROFS (1.05V) and O-OFS (0.9 V was 1.3 V earlier but, changed this becasue of ADC input requirements) are per spec, the VDD voltages are all there and input voltages are within the rails and finally the RSLOAD  (16 ns) too is ok. Looking at your eval board firmware , on appearance it looks exactly like what I am doing. I thought maybe I was/ still am missing some intermediate addressing stage. What I wrote earlier is what I still have.

hello i am an student and i want to do my final project with drs4 board and i really can´t find how to open waveform file and how can i save or opened many of them quickly.

if you can tell me how i will be very grateful.

thanks,

kind regards.

Hi

the drs4 start to generate Dtap signal after reset and standard configuration.

while in reset Denable and  Dwrite are low

after reset we put Denable in high

the Dtap starts to toggle, and the plllck stabilizes on about 1V.  

After 40Msec the Dtap stops to toggle and the plllck go to 2.5V

Why do the Domino stop working?

Thanks, Mony

my refclk is 1.25Mhz

what are the inputs and voltage you need to see?

Avdd and Dvdd are 2.5v

Denable is "1" Dwrite "0"

currently i am doing an external reset cycle, after that i am doing the configuration cycle.

should i relay on the internal reset?

the Dtap is toggling for 33.8msec and then just stops.

Thanks, Mony 

Hi

We have some meesurs to show (attached)

1. Dtap and Denable
2. Dtap+Denable in zoom
3. Dtap + Ref+
4. Dtap + Dspeed

From the screen shots it can be seen that ref+ is not synchronized with Dtap (PLL not working correctly)

And Dspeed is going done to zero after some time.

In our system Dspeed is shorted to pllout.

So it looks like pllout do not pump the RC filter capacitors.

We tested various value of R and C's.

Also we checked that pllout is sorted to Dspeed.

Thanks, mony

Hi

We have some measures to show (attached)

1. Dtap and Denable
2. Dtap+Denable in zoom
3. Dtap + Refck+
4. Dtap + Dspeed

From the screen shots it can be seen that refck+ is not synchronized with Dtap (PLL not working correctly)

And Dspeed is going done to zero after some time.

In our system Dspeed is shorted to pllout.

So it looks like pllout do not pump the RC filter capacitors.

We tested various value of R and C's.

Also we checked that pllout is sorted to Dspeed.

Thanks, mony

Hi Stefan

Thanks for your input.

We are in the process of assemble another PCB board.

so soon we can compere between two boards.

As for the PLLEN bit, we set it.

We checked several times the soldering of the DRS4 using a microscope.

Everything looks ok.

In what method do you recommend to solder the DRS4?

Thanks for the invitation to meet.

120Km is not so far J

mony

Hi

We have resolve the problem, the Dtap is now working correctly.

There were two problems:

1. After configuration we put the all address bits to one (standby mode)

We are now setting the address bits to all zero. Failure

to do so result in Dtap  stop toggling after several hundred milliseconds.

1. The DMODE bit in contradiction to the data sheet should be set to 0

And not to 1.

Is this a known bug in the chip?

Only bay setting DMODE to zero we got the Dtap to work correctly.

The PLL locks after 1 milisec.

If we set it to one we get Dtap that stop toggling after several hundred milliseconds.

We have test it on two boards, they both worked in the same.

Never did we get a One shot  Dtap.

Did you published a errata page to the drs4?

Thanks, Mony

surrey i forgot to update..

after carefully examining our VHDL we found out that there are brief times that we put A0-A3 in 1111

after making shore that a0-a3 never get 1111 value thae drs4 woks as expected.

The dtap toggols ok.

We can sample and read all the data channels.

So, putting A0-A3 value of 1111 even for very short period  " confuse " the DRS and then it start to behave in a strange manner.

mony

Hi all

it is possible to use the evaluation board like a counter?

I'm interested in the arriving time of all self trigger event in to a channel.

the input signal are 2V TTL of 10 ns at 50ohm, and the time acquisition window is 1 second.

can someone help me?

thanks in advance,

Lorenzo

  Hello everyone！I'm a new user of DRS4 board,but it seems that some files are missing in my demo project.So I hope someone could help me by sending a correct VHDL hardware project to my Email:lcyiss900@gmail.com.Thanks in advance!

T

 I checked my project today and I think I need the file USR_LIB_VEC_IOFD_CPE_NALL.I don't know if is it a VHD files or a IP core.

I'll be extremely grateful.

I m trying to measure lifetime in our lab and I intend to take
measurement with DRS4 at that point I have a little bit confused about
DRS4 time range.In My system I opened 10 us gate but after triggering
DRS4 measure nearly 1.2 us. Because of this I want to extend DRS4 time range that
measurement range from 1.2us to 10 us.  

Hi,

    We are using drs4 board, but oscilloscope app will somehow stop to work if we config trigger into "or and", When I look into the drs4 firmware file drs4_eval3_app.vhd, I couldn't find the trigger_config value assignment which is mentioned at(#7 offset 0x1E from 31 downto 16) in manual_version 4.

could you help me find this trigger_config access point? Or is there any drs4_eval4_app.vhd missing in the source files?

thanks

Hongwei

 Ah, great, that helps, Thank you!

Hongwei

 By the way, will there be a drs4_eval4.vhd as well?

 Thanks. have a good day

Hi

I have just installed DRS4, but when I try to view it from the USB it don't work. Why?

  [  .../home  $] lsusb -d 04b4:1175 -v

Bus 002 Device 008: ID 04b4:1175 Cypress Semiconductor Corp.
Couldn't open device, some information will be missing
Device Descriptor:

Is DRS4 suitable for use with Silicon surface barrier detectors?

Hello! I'm using DRS4 evaluation board V5 with the drs command line interface,but the mannal only explained the meaning of the command--"info".And I can't get the hang of the use of other commands through "help",so is there anywhere can I learn more about other commands?Or I can only learn it through the datasheet of DRS4 chip.

Thanks!

OK!Thank you! One more question,when I use the Oscillocope ,I found that the actual speed is a constant value of 1.007G,how can change this speed.

Thank you very much !! All my fault for I thought it too comlicated. Thank you sincerely!

Hi! Stefan:

  when I change a new computer(win7,64bit),I meet a problem that the drscl app cannot found the board! It shows"USB successfully scanned,but no boards found",but the drsosc runs well . when I connect to other win7*64bits computer,only one of them runs property! Is there any driver else I need to install? 

Thank you!

Chen

Hi! Jim:

  It seems that I meet the same question with you ,and I am confused ,have you find out the reason about this problem?Or can you tell me how you deal with it?

Thank you very much!

chen

I have tried about 4 computers,only one worked fine.I truly want to know how others get this fixed,can you get in touch with them?

Hi,Stefan:

  recently,whtn I study the drs.cpp code ,I found that  the buffer[1] is char but the addr and the base_addr are all unsigned int,isn't there any problem that the addr may be cut off to 8 bits? Also ,I found that the data fpga recieved from the usb is 16 bits,so how can fpga get the true 32bits address from the PC.

Hi Stefan:

  I'm still confused that althought the 8 bits buffer is enough,the FPGA receive the command through the uc_data_i register which is 16 bits wides.As we can see in the firmware, the locbus_addr is 32 bits wides. Does it means the locbus_addr[31:8] are always '0' because the address in buffer is only 8 bits. Does it means the usrbus_status_sel and usrbus_ram_sel are also '0' all the time .

thanks!

chen

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

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

Working with the DRS evaluation board we noticed some funny behavior: See attatchment 1. In about 1% of scope traces we see the first and last bin take on a value substantially different from the baseline, note the small spikes on the end of the traces. These spikes occur across all channels and either appear in all channels or in none. Attachment two shows what several thousand scope traces look like. You can clearly see that some of the traces are offset from the normal base line. Has anyone observed this behavior before? Any ideas?

see https://muon.npl.washington.edu/elog/g2/Detectors/550 for full discussion. 

 Thanks for the quick reply. Our quick fix was to do just that. 

 Dear Mr. S. Ritt

       i am Ms. student , am working with your DRS4 board to calculate the time of flight of the cosmic particle which passes trough  the hodoscope . i see the signals at scope , which is negative (i don't want to take positive side of the signal).

       i am using your drs_exap.cpp file to  take the data, i set the analog trigger source , threshold level is negative, like this(b->SetTriggerLevel(-30, true) ); but the exam file also registers the positive side of signal (i think  that is spike or internal reflection), is it possible to eliminate this spike? Also i want to register  the data just after the threshold value, but that is always triggered, i think that caused from the mode. Is it possible to set the trigger mode to normal in exam file?,and  how can i do that?

Best regards.

Sincerely,

 Ali YILMAZ (ali.yilmaz@roma1.infn.it)

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 ? 

Hello.

We are designing a waveform sampling board for Si strip array detector ,whose rise time is less than 10 ns, which makes we doubt whether the DRS4 can do more accurate than traditional charge integral circuit for charge measuring.

So we need to know what sort of detectors for physical experiment the DRS4 has been used in?

Can you give me some information? For example, Si strip array detector or CsI scintillator r ball detector ? PMT or APD ?

When Denable and Dwrite is high , the voltage of PLLOUT is 0 V.  And  the Dtap is turn high with no delay when the Denable turns high.

After power up and configuration(the WSR,WCR,CR are all set to 11111111), the readout data is no change whenever the input analog signal and rofs,bias,oofs changes. I have test useing the DAC to supply the Dspeed voltage, and change a new DRS4 chip, but all is the same. The readout data is strange : the first about 100 cells is rise or fall  and the last 900 cells is out of the range of ADC.

So how should I do for debugging the drs4 now.

 "Keep Denable and Dwrite low (required during power-on, see elog:10), set Dspeed to 2.5V, then rise Denable and Dwrite. You should see Dtap toggling at about 2.4 MHz. "

In this process ,  should i config any registers( WSR,WCR,CR  ) ?

Hi,

I found an old thread regarding a fix for DOScreen.cpp for DRS-3.1.0, that fixes an "ambiguous overload problem." Currently when I attempt to build the drs-4.0.0, I get this similar error:

src/DOScreen.cpp:332:39: error: call of overloaded ‘Append(int)’ is ambiguous
 

This section of code is different than what the previous thread was correcting, and though I attempted to apply the logic of the old thread, I haven't fixed this yet.

The following is the code for that section:

-----

329  for (int i=0 ; i<5 ; i++)
330       if (tc & (1<<(i+8))) {
331            if (i < 4)
332              wxst1.Append(wxT('1'+i));
333            else
334              wxst1.Append(wxT('E'));
335           wxst1.Append(wxT('&'));
336        }
337      if (wxst1.Length() > 0)
338         wxst1 = wxst1.Left(wxst1.Length()-1);
339      wxst1.Append(wxT(')'));

------

I've attempted a few fixes, but unfortunately, my understanding of the code is not great, and I haven't managed to fix this yet. Any help would be appreciated.

Thanks,

Zach Miller

 Hi Stefan,

Thanks for the response. I have tried that and it fixes all the lines except the ones that have:

wxst1.Append((char) (wxT('1'+i)));

Those lines still don't compile for me. I've also tried: wxst1.Append((char) (wxT('1'+(char)i))); and wxst1.Append((char) (wxT((char)'1'+i))); as well as a few other combinations of (char) and Append.

I get the same error of: "Call of overloaded "Append(int)" is ambiguous."

Any other help would be greatly appreciated. Thanks!

-Zach

 Aha!

wxst1.Append((char) (wxT('1'+i)));

That one actually works as you initially thought, but you my editor was being picky of (char)wxt... instead of (char) (wxt....). For some reason, it has to have the extra set of parentheses around wxt(). Thank You!

Hi,

Our group had previously heard that a "DRS-5.0" might be on the horizon and that it may have ethernet capabilities as well as 16-input channels (we heard this when ordering the DRS-4). Is this still in the works and accurate information? If so, is there a rough estimate to the "release date?"

Thanks for your time,

Zach Miller

 Thanks, Stefan. That was the information we were looking for.

Cheers.

-Zach

Hello,

Hi i am using DRS4 Eval Board V2, How to acquire data to a bin file using it.    

I need to synchronize two signals. These signals have a different polarity.

I can set triggers on different levels. But I can't set different polarity of triggers.

Now I can set (T1 and T2), I need to set (T1 and (not T2))

Is it possible?

d->SetTriggerLevel(-0.4,0.4,0.0,0.0,false);

d->EnableTrigger(1, 0);  // Enable trigger

d->SetTriggerSource(1<<8 | 1<<9);  // T1 and T2

file DRS.cpp:

int DRSBoard::SetTriggerLevel(double voltage1,double voltage2, double voltage3,double voltage4,bool negative)

{

…

      SetDAC(fDAC_TLEVEL1, voltage1/2 + 0.8);

      SetDAC(fDAC_TLEVEL2, voltage2/2 + 0.8);

…

Quick question - what type of connectors are used for the trigger and clock in/out on the v4 eval board?

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

Hi, 

I'm running a LIDAR application that requires that every outgoing pulse be captured. My current setup firess sets of 20-50 pulses at 1 ms intervals, about 10 times a second, but only 10-20 pulses a second are captured. 

When I fire at full speed (1KHz - one pulse every ms), about 500-600 pulses a second are captured. 

At the moment, I'm triggering on channel 1 and captureing the data on channel 2. Would it help if I used the external trigger? Is there anything else I can do?

Yoni

Hi, 

I'm trying to do the same thing (get 1 channel with 8192 bins), but I'm having some trouble with it. When I call SetChannelConfig(0, 8, 1) as suggeted, I get output that looks like noise on all readouts. Could you please explain what is supposed to happen in this case? 

I will happily write the code to combine the channels correctly (and debug it) if I can understand what needs to be done. 

(I should mention that my primary concern is a MATLAB interface which I have already written and don't mind sharing when it's complete). 

Yoni Sher

Hi, 

The board is modified (and checks out with the DRSScope program). Could you please point me to the drs_exam_2048.cpp file? I can't seem to fine the most up-to-date git repository....

Thanks, 

Yoni

I am using a DRS4 Evaluation Board v5 and running the drsosc.exe version 5.06 on a Window 7 machine. I have performed the voltage and timing calibration.

With test pulses on channel 1 and 2, I collected binary data file with all 4 channels active sampling at 5GSPS. 

Attached is a distribution of the bin_width vs. cell # for all the 4 channels. Note that there are few cells with bin_width < 10 ps. 

Channel 1: bin_width[498] = -0.000348, bin_width[1010]= -0.000348

Channel 2: bin_width[498] = 0.007363

Channel 3: bin_width[498] = 0.007843

Channel 4: bin_width[498] = 0.005948

Is this normal? How can you get negative bin_width? What does negative bin_width means?

I have attached the binary data file for your verification.

Using a test pulse split into two channels of the DRS4 Evaluation Board v5, I looked at the time resolution using a leading edge threshold. The voltage and timing calibration was performed. One method (1) is to linearly interpolate between two points of the raw waveform that is above and below the threshold (this is exactly the algorithm given in read_binary.c in the drs4 source distribution); and another (2) is to use a cubic spline interpolation of the raw waveform. The results I obtained are:

Method 1: dt = 1.298 ns +/- 7.22 ps

Method 2: dt = 1.293 ns +/- 15.48 ps

I am really puzzled why the time resolution of the spline interpolation is about a factor 2 worse than the simple linear interpolation. Has anyone studied the time resolution using similar or other interpolation methods?

Just a follow-up update.

It turns out that I was using a cubic spline interpolation with smoothing. If I required the cubic spline to go through the sampled points, then I obtained similar time resolution as the simple linear interpolation.

Hi all, 

When connecting the board and running the Zadig program, some Windows PCs may return "driver installation failed." I coudn't find the solution from their download website. So I started the drscl first. Apparently it shows: Successfully scanned, but no boards found. Therefore I checked the Device Manager. A breakdown warning triangle appears under the serial port...

The possible solution may be found here.

Infact, the WinUsb driver has been in existence in your PC. One can just follow the instructions here: 

https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/winusb-installation 

1. Plug in your device to the host system.
2. Open Device Manager and locate the device.
3. Right-click the device and select Update driver software... from the context menu.
4. In the wizard, select Browse my computer for driver software.
5. Select Let me pick from a list of device drivers on my computer.
6. From the list of device classes, select Universal Serial Bus devices.
7. The wizard displays WinUsb Device. Select it to load the driver.

In the wizard, somehow the default setting displays Microsoft Device on the Top of the list and replaced the WinUsb Device. You can easily re-load the WinUsb Device. Just ignore the WARNING from the device manager. The board should work fine now. 

Willy

Hi DRS4 Experts,

I have an extremely naive question: Is there any official macro to unpack the DRS4 binary files? All I am looking to do is to plot a few of my waveforms and manipulate them in root. I am using OSX 10.10 and ROOT 5.34.

Thanks in advance,

Will

I should of course mention that I looked through the DRS4 website and didn't see anything obvious: https://www.psi.ch/drs/evaluation-board

Thanks,

Will

Hi Stefan,

This is absolutely perfect.

Thanks,

Will

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

Hi Stefan,

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

Will

Dear DRS4 community,

Is there a way to extract timestamps with sub-ms precision? The milliseconds of an event is clearly given when unpacking the header. I would like to determine how far apart events are when they are within the same millisecond.

Thanks,

Will

 Hi,

 The diagram below is DRS4 output. Green is the output8+, blue is the output8-. Output8+ of the first channel is below  the baseline. It is not  right.

Others channel  is suitable. I check the circuit , Hardware is no problem, so I want to konw where the FPGA code  is wrong. what reason is caused? Thanks!

 Hi,

   I want to describe this phenomenon again. The diagram below is DRS4 output. There is no input signal. Green is the output8+, blue is the output8-. Output8+ of the first channel is below  the baseline. The output is saturation when input ADC. It is not right, and what is it  in front of the first channel? It seemed there are two channels.  Others channel  is suitable. I check the circuit , Hardware is no problem, so I want to konw where the FPGA code  is wrong. What reason is caused? Can anyone help me to solve the problem? Thanks!

Dear Laura

You need to disable driver signature enforcement.  Then try again with path option.

 It helped me.

http://www.drivethelife.com/windows-drivers/how-to-disable-driver-signature-enforcement-on-windows-10-8-7-xp-vista.html

Best regards,

Volodymyr

Hello Stefan

I tried to convert binary to a simple txt file and found next problem - strange time output.

Here is output from little modification for read_binary.cpp (Its last output line also is strange: dT = -1.#IOns +- -1.$ps)

Found data for board #0
Found timing calibration for channel #1
Found boards#  1
     event    channel   waveform       time      point
         1          0  -0.000092   0.000000          0
         1          0   0.030548   0.000000          1
         1          0   0.059418   0.000000          2
         1          0   0.080200   0.000000          3
         1          0   0.094223   0.000000          4
         1          0   0.097702   0.000000          5
         1          0   0.094055   0.000000          6
         1          0   0.079117   0.000000          7
         1          0   0.060364   0.000000          8
         1          0   0.030960   0.000000          9
         1          0   0.000504   0.000000         10
         1          0  -0.031555   0.000000         11
         1          0  -0.057465   0.000000         12
         1          0  -0.080536   0.000000         13
         1          0  -0.095413   0.000000         14
         1          0  -0.099365   0.000000         15

I used output string in the following places, but it didn't help:

// reach channel data

:for (i=0 ; i<1024 ; i++) {
               // convert data to volts
               waveform[0][chn_index][i] = (voltage[i] / 65536. + eh.range/1000.0 - 0.5);
               // calculate time for this cell
               for (j=0,time[b][chn_index][i]=0 ; j<i ; j++)
                  time[b][chn_index][i] += bin_width[b][chn_index][(j+tch.trigger_cell) % 1024];

printf("%10d %10d %10f %10f %10d\n", eh.event_serial_number , chn_index , waveform[0][chn_index][i]  ,  time[0][chn_index][i]  , i);

And after alignment procedure:

t1 = time[b][0][(1024-tch.trigger_cell) % 1024];
         for (chn=1 ; chn<4 ; chn++) {
            t2 = time[b][chn][(1024-tch.trigger_cell) % 1024];
            dt = t1 - t2;
            for (i=0 ; i<1024 ; i++)
               time[b][chn][i] += dt;

printf("%10d %10d %10f %10f %10d\n", eh.event_serial_number , chn_index , waveform[0][chn_index][i]  ,  time[0][chn][i]  , i);
         }

Does it caused by some software or drivers changes?

Best regards,

Volodymyr

Hi again.

Okay, it works with 5.05 version very good and it is enough for me.

Besides,

What do I need to fix in this code for 2048 board?

Best wishes,

Volodymyr

Hello.

I have a simple question, can I set SetTriggerDelayNs() more than 1631 ns?

I need to set this delay to about 5 us... Can I do this? 

Thank you in advance! 

With best regards, 

Vadym

Thank you for your reply!

 Hello!

I have a question concerning the sampling speed of the DRS4 evaluation board.

It is written in the manual that the sampling speed of  DRS4 Evaluation Board is supported above 0.7 GHz.

However I was able to set the sampling speed to be 0.5 GHz with the function DRSBpard::SetFrequency(0.5)  and realized that DRSBoard::GetTime function fills time array in every 2 ns.

I am wondering if the data taken with 0.5 GHz sampling is reliable or not.

Best regards,

Tsutomu Nagayoshi

Dear Stefan,

I am using an DRS4 board to record the signals from an plastic scintillator detector. It was working really good, yet a few day ago the signals became "not right". When I checked the signal using an oscilloscope it show the normal signals previously recorded. The signal amplitude are clearly reduced (from 0.3 in oscilloscope to lower than 0.1 in DRS4). Can you show me how to show this problem?

Thank you very much!

Best Regards,

Thien 

I'm writing the drs_exam.cpp to use multi-boards(v3, firmware:4.0.0), and taking data succeeded. But I have several questions about function written in DRS.cpp.

1. I wrote following code in drs_exam.cpp to set input range -0.4~0.6

                                     b1->SetInputRange(0.1);

            And the 100mV offset appeared(I attached a picture). I think this is due to the voltage calibration isn't done.(Calibrated to -0.5~0.5mV in DRS Oscilloscope)

            If so, could you show me a simple usage of "CalibrationWaveform()" function in DRS.cpp? (or other function?)

       2. Although this question might be the almost same with above, is there any way to execute voltage and timing calibration in drs_exam.cpp?

           Now I start DAQ by executing drs_exam.cpp after I execute voltage and timing calibration to each board by DRS Oscilloscope program.

      3. Which command is right to use external trigger?

                                   b1->SetTriggerSource(4);   or  b1->SetTriggerSource(1<<4);

Best regards,

Toshihiro Nonaka

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

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

Hello,

I 'm using four evaluation boards v.3 to construct the multi-board DAQ system. One channel for each board is used as reference clock, then calibrate timing offline, which allow below 10ps resolution between boards.

Is it possible to keep the time resolution between boards below 10ps in daisy-chain mode with v.5 boards?

Thank you in adcance.

Best regards,

Toshihiro Nonaka

Hello,

I am working on a custom PCB design with the DRS4 chip, and I can't get the PLL to lock.  I'm feeding CLKIN with a 1MHz CMOS clock (REFCLK- tied to VDD/2), and I'm using the same loop filter as the eval board.  I see from the datasheet that the PLL is enabled by default, so I'm not writing anything to the config register on startup.  I am just driving DENABLE high approx. 100ms after startup and looking for the PLL lock bit to go high.  When I look at DTAP, I see a 3MHz signal.  Can anyone tell me what I'm doing wrong?

-Tom

Stefan,

Thanks for responding so quickly.  Yes I have my clock source going to REFCLK+ (CLKIN is the signal name on my schematic).  BIAS is 0.7V exactly, /RESET is high, A0-A3 are 0x0000, and the loop filter has a 4.7nF cap to GND with a 130ohm resistor + 1uF cap in parallel, just like the eval board.

Regarding the clock - I am not using an LVDS clock, but rather a 2.5V-level clock signal, with REFCLK- tied to 1.25V.  Sheet 9 of the datasheet states:  If no LVDS reference clock signal is available, a CMOS signal can be connected to REFCLK+ and the REFCLK input is connected to VDD/2 via a resistor divider.

Is that not a true statement?

-Tom
 

Probe capacitance makes that tricky - if I put my probe on DSPEED, I see that it starts at approx. 2.5V then gradually decreases until it hits 0V.  DTAP decreases from 3MHz to 0 during this time.

I'll try to get something together to show you.

Thats not a simple modification to my PCB, but I'll give it a try.  Thanks for your help

I found the problem, and it had nothing to do with the CMOS clock input.  As it turns out, even though I was using the default state of the config register, I still had to write to it after powerup.  Once I did that, the PLL locked immediately.

-Tom

Hello,

I'm working on a project wherein we're looking at photomultipliers. We've already acquired a DRS4 evaluation board with the intent of using it to gather our data.

I've looked at the source code for the software with the intent of maybe writing a patch to add additional functionality. I was hoping you could answer some quick questions in that regard.

Am I correct in assuming that drsosc and drscl are functionally equivalent regarding collecting data? We want to run the DRS4-EB for a predefined amount of time. However, the DRS4 scope application seems only to run for a predefined set of measurements. Have I got that right? Is there some reason to avoid running the DRS4-EB for a predefined amount of time that I should be aware of?

Appreciate any help you can provide. Thanks!

Kind regards,

Thomas

Yes, you've got it exactly right. Thank you, that helps a lot! 

Thomas

Hi everyone,

I wonder if there is a way to pass parameters to drscl. What I specifically want to do is calling drscl from a shell script and read/save some data. I want to schedule a measurement. Therefore I need to call drscl from the command line using some parameters.

It would look something like this;

#!/bin/bash

for i in {0..100}

  do

    echo "Reading $i"

    ./drscl read 0 0 test.xml

    sleep 1

done

This doesn't work of course. drscl won't take arguments from the command line. Can you suggest a way to do this please?

Thank you.

Dear all,

I have a question about the function that drs4 can perform.

Is there any function in drs4 that is analogous to that of "persistence display" in oscilloscope?? (accumulating pulses)

Thank you

I don't know if this question is already documented elsewhere.

I am developing a DAQ code for the DRS evaluation board, v4 for a test beam experiment. I link parts of the existing DRS code as a library.

To understand the effect of various flags used in calls to the functions DRSBoard::GetTime() and DRSBoard::GetWave(), I performed several tests with the 100 MHz signal connected to the inputs of the chip (DRSBoard::EnableTcal()), and several tests with signals from scintillation counters.

My question is about the flag "adjustToClock" in the call to DRSBoard::GetWave(). From looking at the code, I expected it to cause the waveforms to be "rotated" to start from the trigger cell, in a similar way that the flag "rotated" in the call to DRSBoard::GetTime() does for the time array. However, "adjustToClock" seems to shift the waveforms wrongly. I.e., if I want both the time and the amplitude arrays "rotated"  to start from the trigger cell, I should set rotated=true for time and adjustToClock=false for the amplitude. This is also how these functions are called in e.g., Osci::ReadWaveforms().

Is this correct, and does this mean that the amplitude array is "rotated" already during the transfer from the board?

I am using DRS evaluation board serial #2733, firmware revision 30000.

Many thanks,

Strahinja

Thanks.

Strahinja

Hello All,

I too have been struggling with trying to get the drs4 (507) to work on my windows machine and I found it to be a problem with the libusb library. My solution is as follows and has worked on multiple PC's. I ran this solution after I first plugged in the drs4 and installed 507.

Go to http://zadig.akeo.ie/ and install the corresponding software.

After that, you will need to plug in the DRS4 to your computer. From there go to ‘Options’, and select ‘List all Devices’.

Finally, choose the DRS4 evaluation board from the list and press install driver and let it run. You should be fine after that. 

Best,

Steven

Hello All,

I am currently trying to figure out how to properly characterize the dead time of the DRS4 board. My most recent experiment to try and answer this question involved using an external trigger that can range from 1Hz to 2MHz. I fed this trigger into the DRS4 and collected 1000 samples with no input to any channels. I repeated this across the range of my external trigger by a factor of ten [10Hz, 100Hz, 1kHz...etc]. After I had saved these runs in XML format, I looked at the difference between timestamps on the events. Attached are my findings. Can someone offer an explanation for the periodic peaks? I am new to the DRS4 and don't really understand how it works. My guess is that there is a buffer that has to be emptied every so often, but if so, the buffer emptying time varies with the frequency of the trigger. I would ideally like to be able to know the relation of the dead time to a particular setting I change on the DRS4 such as locking the sampling speed or changing external trigger frequency. 

Best,

Steven

That is extremely helpful! Many thanks. One more question; If I were to take inputs from 2 channels at once, would that scale the dead time to 64us using your example? 

Steven

Hello,

I have a question about how ROI works. From what I have read, it will only save data that ocurs some time [t_a] dictated by the user after an event is triggered as well as a small time [t_b] before the event. The technical manual seems to indicated that the deadtime assciated with operating in ROI mode can be reduced by the following factor: 

.

Where N is the number of points in the time window (ex. 2048 or 1024). Is it ok to describe this as:

Where N' is the number of samples in the ROI and N is the same as before.

For example, if I were running at 5Gsps (200ps between samples), only recording 1024 samples per event and I had an signal that lasted 2ns, that means the signal would last 10 samples. If I set the ROI to only save 20 samples around this signal, would my Deadtime go to:

? (The second portion of this equation comes from a response I recieved earlier, but I just want to make sure I understand this concept properly)

I recognize that the caveat is that this would work only if the signal was detected during acquistion, which leads to my next question. If no signals were detected in the 1024*200ps time frame in ROI mode, would the DRS4 go dead for 32us (using the factor = 1 from above equation), or would it dump the earliest events in the buffer for the more recent ones until it detects a signal? 

Finally, I assume this functionality can only be utilized with custom electornics with the DRS4, not the evaulation/demo board, please let me know if this is the case. 

Best,

Steven

Great! That is very helpful. 

One more question. If no signals were detected in the 1024*200ps time frame in ROI mode, would the DRS4 go dead for 32us (or 30us depending on the supply)  for, or would it dump the earliest events in the buffer for the more recent ones until it detects a signal to readout? Or rather, does filling the buffer force a readout or can it dynamically shift out old data until it detects a signal to readout. 

Steven

Hi,

I wish to interface the DRS4 with the 8-channel ADC AD9222 (or AD9637).

I'm reading from the DRS4 datasheet that "the analog output of the DRS4 chip has been designed to match directly the input of the AD9222". OUT+ output of DRS4 is in the range from 0.8V to 1.8V and OUT- output is shifted by the voltage applied to the O-OFS pin.

The span of the AD9222 ADC core is defined by REFT and REFB which are resp. 1.4V and 0.4V in a typical case (AVDD=1.8V, VREF=1V). My understanding is that the ADC analog inputs must be within the voltage range defined by REFT and REFB and so I don't quite see how this matches the DRS4 outputs.

Can we use the full-scale range indeed? Do we have to use AC-coupling with mid-supply bias? What is the point I missed?

Thank you for your help.

Hi,

I'm trying to recompile the USB microcontroller firmware starting from the drs_eval.c file but I'm not able to get a .iic file close to the one provided with the eval board. It seems to me that this drs_eval.iic file does not match the drs_eval.c and drs_eval.hex files or that I'm doing something wrong. Could you please help or give me an explanation.

Thank you.

Stephane

 Thank you Stefan.

Would that be possible to get the corresponding drs_eval.c source file since I'm assuming the one provided with the eval board is not the right one?

Thank you.

Stephane

I'm very sorry to insist but if I take the .hex of the distribution, convert it to .iic using the hex2bix utility, and reprogram the board, I can't read the board correctly (invalid magic number read with drscl for instance). Also, when using the uVision2 project file you provide and compiling the drs_eval.c, I get the same result  (i.e. no way to generate a functional .iic file starting from the sources). So, either I'm doing something wrong (and I don't know what) or the drs_eval.c is not the correct one.

It works as expected.

Thanks for the help.

I'm not doing this for fun, checking that the source matches the .iic ! I know I could directly use the .iic and forget about the hex and c files.

I just wanted to use your source file as the starting point for my own board, as everybody is doing at the application level.

 Welcome to the DRS4 Discussion Forum. This forum contains information and discussions related to the DRS4 chip. Please subscribe to this forum to receive automatic email updates. If you have any technical questions, please feel free to post it here.

Several people mentioned that the external trigger input (TTL) does not work on the DRS4 Evaluation Board Rev. 1.1. This is not true. The requirement however is that the input signal must exceed approximately 1.8V. Since the input is terminated with 50 Ohms, not all TTL drivers may deliver enough current to exceed this threshold. To verify this, the trigger signal can be monitored with an oscilloscope at test point J24. Only if the input signal exceeds 1.8V, the signal will be seen at J24 and correctly trigger the FPGA. If the TTL driver is too weak, the termination resistor R9 can be optionally removed, but care should then be taken that reflections in the trigger input do not cause double triggers. The locations of the tap point for the input signal, the termination resistor R9 and the tap point J24 after the input level converter U5 are shown in this image:

Another tricky issue comes from the fact that the external TTL trigger and the comparator are in a logical OR. So if the comparator level is set such that the signal is always over the threshold, the trigger is always "on" and the TTL trigger does not have any effect. It is therefore necessary to set the analog trigger level to a very high value in order to make the TTL trigger work. 

 Please note the new datasheet Rev. 0.8 available from the DRS web site. It fixes the label of pin #76, which was AGND but is actualy AVDD. The input IN8+ is located at pin #20 and not at pin #19 as described in the old table 2.

Many applications using the DRS4 need to measure fast rising signals, like for PMTs or MCPs. This short note shows the minimal rise-times which can be measured with different input signal conditioning.

Evaluation Board

The evaluation board contains four passive transformers ADT1-1WT from Mini-Circuits to convert the single-ended input signal into a differential signal. Although these parts are rated 800 MHz bandwidth (-3dB), they have hard time to drive the DRS4 inputs. This is because at high frequencies the input impedance of DRS4 becomes pretty small (~20 Ohm at 500 MHz) due to its capacitive nature. Furthermore, each transformer drives two DRS4 inputs (channel cascading) which enhances this problem by a factor of two. We made a quick test sending a signal to the evaluation board with a rise time of 277ps and a fall time of 280ps. The result measured with the evaluation board is seen here:

The measured rise-time (10%-90%) is only about 2ns. Disconnecting the second channel from each transformer improves this situation a bit:

so the rise-time comes down to ~1.6ns.

Active ADA4937 driver

We tested the behavior using an active buffer ADA4937 to replace the passive transformer. Without the DRS4 connected to this buffer, we measured with the oscilloscope a rise time of 408ps and a fall time of 644ps. When we connect the DRS4 (single channel), this values increase to 702ps (rise) and 1400ps (fall), all measured with a differential oscilloscope probe (WL300 4 GHz Bandwidth, LeCroy 7300A, 3 GHz Bandwidth). In this case the rise time seen by the DRS4 is wieth ~700ps accordingly shorter:

(The signal was not properly terminated and therefore we have a small overswing). 

Conclusion

To obtain an optimal rise-time measurement, the design of the input stage is rather important. A fast active driver seems to do a better job than a passive transformer (which was used on the evaluation board for power reasons). Connecting only one DRS4 channel to the input improves the rise-time measurement significantly. If channel cascading is still needed, a design should use one driver for each channel, and not driver two or more DRS4 inputs from a single buffer.

If anybody comes up with an even better input driver, I'm happy to publish the results here.

This is a quick notification to all users of the current DRS4 evaluation board.

As you all know, the DRS4 chip needs some calibration for each individual cell which corrects the offset and the non-equidistant width in time. While the first evaluation boards have been shipped without this calibration, the current version of the software implements a full amplitude and timing calibration. The offset correction reduces the noise of the board by almost an order of magnitude to below 1 mV RMS. The timing calibration using an on-board reference clock allows a timing accuracy in the order of 10 ps. To illustrate that the following two pictures show a reference clock signal before and after timing calibration:

The integral temporal nonlineairy at 5 GSPS before timing calibration is about 600 ps as can be seen by the jitter of the overlaid waveforms.

In order to do a timing calibration, the firmware revison 13297 or later is required. The current software package 2.1 contains an updated firmware, but unfortunately one needs a Xilinx download cable to flash this new firmware (see http://drs.web.psi.ch/download/ under "Software Versions"). If some people want an update but do not want to buy such a cable, we offer a free update at our institute (just the postage has to be paid). The old evaluation board (Rev. 1.0, plastic housing) can unfortunately not be updated.

After the offset calibration is made, there are small (~20mV) short spikes left. They probably come from some cross-talk between the USB interface and the analog part of the board. This is currently under investigation. If new updates become available, they will be announced in this forum.

April 27th, 2009,

Stefan Ritt

Several people asked for s simple application to guide them in writing their own application to read out a DRS board. Such an application has been added in software revions 2.1.1 and is attached to this message. This example program drs_exam.cpp written in C++ does the following necessary steps to access a DRS board:

• Crate a "DRS" object and scan all USB devices
• Display found DRS boards
• Initialize the first found board and set the sampling frequency to 5 GSPS
• Enable internal trigger on channel #1 with 250 mV threshold
• Start acquisition and wait for a trigger
• Read two waveforms (both time and amplitude)
• Repeat this 10 times

I know that we are still missing a good documentation for the DRS API, but I have not yet found the time to do that. I hope the example program is enough for most people to start writing own programs. For Windows users (MS Visual C++ 8.0) there is a drs.sln project file, and for linux users there is a Makefile which can be used to compile this example program.

One note: The program drs_exam.cpp published in the previous message needs the current version of the DRS library in DRS.cpp and DRS.h. They are contained in the software release 2.1.1 which has to be downloaded. For simplicity, I attached the two files to this message.

 A new software verison for the DRS4 Evaluation Board has been has been released. Version 2.1.3 adds a switch for the input range of the DRS4 board. Once can choose between -0.5V...0.5V and 0V...1V:

A board firmware update is not necessary for this. It was originally planned to have even a negative range -1V...0V, but this is not possible with the current board design. People who want to record negative pulses have to use an inverter to produce positive pulses. In a future version of the board it might be possible to include this functionality since this is determined by the analog front-end and not the DRS4 chip.

Maybe some of you have experienced that the DRS4 chip can get pretty hot after power up. After it's initialized the first time, the power consumption goes back to normal. I finally found the cause of this problem and have a remedy. Here is the new paragraph from the updated data sheet:

During power-up, care has to be taken that the DENABLE and DWRITE signals are low. If not, the domino wave can get started before the power supply voltages are stable, which brings the DRS4 chip into a state where it draws a considerable amount of current and heats up significantly. This can be problematic if the signals are directly generated by a FPGA, since most FPGAs have internal pull-up resistors which get activated during the configuration phase of the FPGA. In such a case, the DENABLE and DWRITE signals should be connected to GND with a pull down resistor. This resistor should be much smaller than the FPGA pull-up resistor in order to keep the signals close to GND during the FPGA configuration. A typical value is 4.7 kOhm.

The attached schematics shows the location of the two required resistors.

The current version of the DRS readout example program drs_exam.cpp has two problems:

1. The sampling frequency cannot be changed, it will always stay in the region around 5 GSPS
2. The waveform obtained by GetWave is rotated such that the first DRS cell corresponds to the first array bin

Both problems have been fixed and the fix will be contained in an upcoming software release.

It has turned out that the stability of the AVDD and DVDD power supplies for the DRS4 are very critical. On the evaluation board I use a REG1117-2.5, on our VME board I use a ADP3338-2.5 for the DVDD power supply. When the domino wave is started, the power consumption of the DRS4 chip jumps up by ~40 mA, which has to be compensated by the linear regulator. Following screen shot shows what happens:

The blue trace is the DWRITE signal indicating the sampling phase when high. The yellow is the SRCLK showing when the readout takes place. The pink is now the DVDD power. It can be clearly seen that there is a dip of ~50 mV when the domino wave starts, a positive dip when it stops and another smaller dip when the readout starts. This causes strange effects: If the trigger arrives during the first dip, the actual sampling takes place when the DVDD is ~50 mV smaller, which leads to a baseline shift of a sampled 0V DC input voltage of about the same amount (-50 mV).

The obvious improvement is to put a huge capacitor on the power supply, but that does not help much:

The dip gets a bit smaller, but it's still there. So a better solution would be to use a faster LDO regulator. Please take care of this if you plan a new design.

Furthermore, I believe that the chip internally has some "warmup" phase, where the die heats up a bit when the additional 40 mA are drawn. So a "good" solution is to wait some time after starting the domino wave until one allows for triggers. Tests showed that a few milliseconds are necessary to keep the baseline shifts below a few millivolts. This of course decreases the dead time of the system significantly, so one has to choose the proper balance between increase dead time and increased base line shift. On some applications where a baseline shift is not an issue, one could opt for the minimum dead time.

It turned out that the VDD switch off speed plays some important role. On our VME board, we have a linear regulator, then a 4.7 uF capacitor, then the DRS4 chip (DVDD and AVDD). When switching off the VME power, it takes quite some time to discharge the 4.7 uF capacitor, since the DRS4 chip goes into a high impedance mode if VDD < ~1V. This gives following VDD trace:

Rising edge is power on, falling edge is power off. Note the horizontal time scale of 2 s/div. So to get below 0.3 V or so, it takes up to 30 seconds. If the power is switched back on when AVDD is above 0.3V, the DRS4 chip can get into a weird state, where probably many domino waves are started and the chip draws an enormous amount of current. Typically the linear regulator limits the current, so the 2.5V drops to ~1.5V, and the board is not working. If people are aware of this and always wait >30sec. before turning the power on again, this is fine, but people might forget.

So the solution is to put a resistor (typically 100 Ohm to 1 kOhm) parallel to the 4.7 uF capacitor in order to have some resistive current load of a few mA. The discharge then looks like this:

Note the horizontal scale of 10ms/div. So after 30 ms AVDD is discharged and powering on the chip again does not do any harm. The same should be done to DVDD.

The clock-to-output delay is the same if one uses the multiplexer or not. I found however that in most cases the delay of 38 ns needs some fine tuning to get optimal performance. So I typically use a shifted clock generated by the FPGA clock manager with a programmable delay (+-5 ns for Xilinx) and optimize this in the running system.

"internal buffers" are all internal operational amplifiers in the DRS4 chip. Every OPAMP needs a bias (just look it up in any electronics textbook), which determines the linearity and the speed of the OPAMP. When designing DRS4, I was not sure if the required BIAS voltage changes over time, or between chips, so I made it available at a pin, which is a common technique in chip design. But it turns out now that this voltage is not very critical, so just keeping the pin open will work in most cases. 

No. It shifts about ROFS-0.25V. So only if ROFS=1.55V, the shift will be 1.3V.

Just read the datasheet under "ANALOG OUTPUTS". I'm sorry if I did not describe this clearly, but the U+ voltage is fixed (only dependent on ROFS), and U- can be calculated using Uofs as written in the datasheet. 

OUT+ is 0.8V~1.8V, OUT- is 2*Uofs-OUT+. So you can only change the OUT- level, not the OUT+ level. 

Please find attached the complete dimensions.

Indeed you have to make an external trigger. The evaluation board uses the "transparent mode" of the DRS4 to "mirror" the input signal at the output, then puts a comparator there. The schematics of the evaluation board is in the manual. This does then not degrate the analog performance. You can of course also split the signal at the input, this will only add a minor additional load to the input signal, since the load of the DRS4 chips itself is much bigger than that of any comparator.

An alternative is to turn on the transparent mode and continuously digitize all 8 outputs with your AD9252. Then you make the trigger purely digital in your FPGA. You can put there a comparator, or even more complex logic like multiplicity etc. Note however that this causes some latency, since the ADC has a pipeline which is quite long, so you have to buffer the latency of your trigger in the analog window of the DRS4 sampling cells. Like if you run the DRS4 at 1 GSPS, you can accomodate 1024 ns of sampling depth, which is good for maybe 500 ns of trigger latency plus 500 ns of the waveform of interest.

The amplitude of the analog signal is not degraded by the transparent mode, since the signal is buffered on the chip, and the output of this buffer is send off the chip. The waveform digitizing of course requires quite some current to charge up all capacitors, so there is  maximum current of ~1mA for 5 GSPS. If you only have a weak signal source, your bandwidth might be limited by that. On the evaluation board for example we use passive transformers to produce the differential input signal from a single-ended signal. Although the transformers are rated 1 GHz Bandwidth, we only achieve 200 MHz with the passive transformers. By using active high speed differential drivers, you can get about 700 MHz right now.

If you have two channels with 500 ns and 510 ns trigger latency, there is no difference in the "domino stop position" since there is only one domino circuit per chip which can be stopped. So the stop position is the same for all eight channels on a chip. 

There is one analog buffer per channel at the output, as indicated on the FUNCTIONAL BLOCK DIAGRAM of the datasheet. The section ANALOG INPUTS clearly states that the input signal has to load directly the sampling capacitors.

All other people using the chip so far correctly understood these things so far, so I believe more information beyond the datasheet is not necessary. I believe you have a principal problem of understanding, which can hardly be clarified by email. Best would be if you directly call me, I can then explain things to you.

Please note that SetTriggerLevel(level, polarity) needs "level" in volts, not millivolts, so you need SetTriggerLevel(-0.3, true). The trigger mode is not specified with any library call, but depends on what your program does. If you always poll on IsBusy(), then you are already in "normal" mode. The auto mode can only be achieved on the user application level by doing an "artifical" trigger by calling SoftTrigger() if there are no hardware triggers for a certain time. 

A firmware update requires a power cycle of the evaluation board. Have you tried that? I attached for you reference the current drs_eval1.mcs file, which is meant to go into the XCF02S PROM. There were recent changes also in the DRS library, and I'm not sure if yous if recent enough. So I put also the current C files which go with the firmware. They contain also some improvements which should reduce the intrinsic noise of the board.  

There is no built-in possibility to open waveform files, you have to write your own programs to do that. 

Yes, but you have to recompile the oscilloscope application. Find following line in the source file DOFrame.cpp:

            m_WFfd = open(filename.char_str(), O_RDWR | O_CREAT | O_TRUNC | O_TEXT, 0644);

and replace it with

            m_WFfd = open(filename.char_str(), O_RDWR | O_CREAT | O_TRUNC | O_BINARY, 0644);

 that fixes the problem. To compile the program, you need MS Visual C++ and you have to install the vxWidgets library. Let me know if you have any problem with that.

Anyhow I plan a major software update soon (weeks), which not only fixes this problem, but also reduces the noise considerably by doing a kind of two-fold calibration.

- Stefan

The locking time is typically 20-30 cycles of the external reference clock, I will update the numbers in the datasheet soon. I attached a screenshot of the chip when starting up at 1 GHz (0.5 MHz REFCLK), so you can see the behaviour. The upper curver is the DTAP signal, the lower curve the PLLLCK signal. As you can see, the PLLLCK signal is not purely digital. Actually it's a simple XOR between the REFCLK and the DTAP signal, so you need an external 4.7nF capacitor to "integrate" this signal. Without this capacitor, you would see small negative spikes whenever there is s small phase shift between the DTAP and the REFCLK signal. Have a look at your DTAP signal, is it in phase with the REFCLK? 

Hello,

may I draw your attention to the upcoming Real Time Conference 2010, taking place in Lisbon, Portugal, May 23rd to May 28th, 2010.

http://rt2010.ipfn.ist.utl.pt/

Several groups which are developing DRS4 electronics will come to this conference and present their work, so it will be a good opportunity to exchange ideas and experiences. There will also be a short course on digital pulse shape processing, which is highly relevant for our field.

Looking forward to see you in Lisbon,

    Stefan 

Actually the XOR is followed by an inverter, so it will integrate to high if the two clocks are in phase. 

If the WSRin is fed internally to WSROUT, then the level of the WSRIN pin does not matter, it's just disconnected. You can leave the pin open without problem. WSROUT is however active, so you can observe the internal state of the write shift register. In the default configuration (8x1024 sampling cells), all 8 channels are active all the time, so the WSR is loaded with ones. The inverter at the output then makes all zeros from this. If you configure the chip as 4x2048 cells, then you will observe switching bits at WSROUT. 

Actually I double checked the schematics, WSROUT has NO inverter at the output. So the output should be always one in a 8x1024 channel configuration.

Concerning the read/write you are right. On each clock cycle, SRIN will be shifted into the first bit, and the last bit will be visible at SROUT.

The start/stop requirement is obsolete and has been replaced by  elog:10. I need to update this in the datasheet. The delay between the RSRLOAD and the SRCLK has the following reason: On the RSRLOAD the first sampling cell is output to the chip and to the ADC. This can sometimes be a rather high swing, which needs some time to settle, and some warm-up for the output driver. But actually I never really measured it, so it's there just as a safety margin. But I would encourage you to try to reduce this time and see it the first few bins of the readout change in offset.

The reason for the 16.5 MHz is the following:

After each block of 32 bins, the DRS4 chip switches an internal segment, which causes some small spike at the analog output of the chip. This spike is a bit wider than 30ns, so if everything is digitized with 33 MHz, then you see small spiked each 32 cells. The appropriate solution would be to modify the firmware to digitize all cells with 30ns (33 MHz) and all cells with the spike with ~50 ns (20 MHz). If you do the ROI readout mode, you don't know for the first 10 cells if one of them belong to this class, since the cell address takes 10 cycles to be read out. So you would first have to read 10 cells, and then if you realize that one of them is one of the problematic ones (cell number modulo 32 is zero), you have to re-read the first 10 cells, and digitize the problematic cell with a longer settling time. Now this is a bit complicated to implement in the firmware, so I was just too lazy to do it and decided to digitize everything with 16.5 MHz. But if you are worried about the dead time, you should consider implementing the mentioned algorithm. 

Yes you do. But if you have WSRLOOP=1 in the config register, this is done automatically. So the SR output is visible at the pin and will be fed back into the input.

That's not correct. Have a look at Figure 14 of the datasheet. Do you see a single RSRLOAD pulse or many? There is only one RSRLOAD pulse to initialize the readout shift register, then the cells are clocked by SRCLK pulses. 

A single RSRLOAD pulse loads the RSR with a "1" at the domino stop position and "0" in all other places. A pulse on SRCLK shifts this "1" down the RSR. When it arrives at cell #1023, it will be visible for one clock cycle at WSROUT. The "double" functionality of WSROUT has the following background: Assume you use channel cascading 2x2048. Now the domino wave stopps in cell 1020 of the first channel for example. You have to read cells 1020,1021,1022,1024 of the first channel, then you continue with 0,1,2 on the second channel. But how do you know that you have to switch channels after the first four clock cycles? The SROUT output encodes the stop position (in this case 1020), but it needs 10 clock cycles before the information is available, so you don't have it after four cycles. That's where WSROUT comes into play: Since it outputs RSR bit by bit, it will show three "0", then a "1", when you are at cell 1023. Then you know that you have to switch channels immediately. That's why I output RSR via WSROUT if DWRITE is low.

In transparent mode, the input signal also gets routed to the output, where it goes through an output buffer, which limits the bandwidth to about 50 MHz, but only for the output. The effective bandwidth to the sampling cells is not changed. Please note however that the 950 MHz are for the "chip only". We measured this by keeping the input amplitude from a function generator constant at the input pin of the chip (measured with a high speed oscilloscope). Since each signal source has a non-zero impedance, the signal tends to "shrink" at high bandwidth, and we had to adjust the level of the function generator to keep the amplitude constant at high frequencies. If you do a realistic input stage with the THS4508 for example, the achievable bandwidth will be around 800 MHz.

No, since they are not constant. The bus segments charge up between readouts with a time constant of about 0.5s. So if you do the readout with 1Hz event rate and with 100Hz event rate, the peaks will differ by a factor up to 10, so a constant offset correction cannot take care of that.

The setup of the evaluation board is a good compromise which runs between 1 GHz and 5 GHz. Unfortunately I never found the time to investigate this in more detail. So if someone is willing to measure settling time and phase jitter with various combinations of R, C1 and C2, I'm more than happy to include this into the datasheet. 

The evaluation board is as good or bad as an digital oscilloscope to work like a counter. At 1 GSPS, you have a window of one microsecond, which is certainly too short for your application. 

Please post an oscilloscope screenshot here and I can tell you. 

The evaluation boards are not really made for multi-board applications. What you have to do is to maintain an external trigger which synchronizes the boards. So you need:

- two boards connected to two USB ports

- an external flip-flop connected to the two trigger inputs of both boards

If a trigger is sent to the flip-flop, it sends a trigger to both evaluation boards. You poll on one of the boards to see if it has triggered (vis IsBusy()), then you read out both boards. Now you have to reset the external flip-flop somehow from the computer. If you have a CAMAC I/O board or some other means of sending a logical signal to it, that could do the job. From the software point, you get a "DRS" object upon initialization, which contains then two "DRSBoard" objects, over which you can iterate. Look at the "drscl" program from the distribution on how to do that.

Hi, Stefan,

I found that my collaborator bought 2 older version of evaluation board before.
They are the version 1.2 in plastics case with firmware 13191.

Can I upgrade the firmware from 13191 to 13279?
I'm wondering if the older version of evaluation board is working with firmware 13279.

Thanks,
Heejong

I checked and there is no significant difference between the two revisions, so I would just leave it. 

1.55V-U0 is the theoretical values, but there are certain "dirt" effects like chip-to-chip variation and charge injection. The difference between various chips is easily 20-30mV, so there is not a single "correct" value. The formula 1.6V-1.25*U0 I developed for a special evaluation board, where it kind of worked better than the theoretical value, but I never made systematic studies. One should average over several chips and use some solid average there. Best is if you try both formulas and check what give you the better linearity.

Yes there is a transistor-level spice model, which I used to design the chip, but you won't be happy with it: Given the 500,000+ transistors on the chip, a 100 ns simulation takes a couple of weeks. We tried to make a simplified model just for the analog input using some measured S-parameters, but found that the RF behavior of the chip is almost impossible to describe to better than let's say 50%. In the end you have to fine-tune your analog front-end experimentally, to obtain optimal bandwidth. We are just working on a reference design with gives you 850 MHz bandwidth using an active input buffer.

I just checked and realized that we are not allowed to give out the "huge" model since it contains parameters from the chip manufacturer's library which are confidentially. 

Please find attached the S-parameters. 

You cannot compare the DRS4 noise directly with an amplifier for example. The noise mainly comes from variations of the charge injection into the storage cells, and some noise during the readout process, which happens in a completely different frequency domain than the sampling.

So what I did is to keep the inputs open, measure a 1024-bin waveform, and compute the RMS of this waveform. So I believe that this is kind of equivalent noise voltage from 1-950 MHz. It does not start from zero since very low frequency noise (like 50 Hz) just causes a baseline shift and does not influence the RMS, but this is not so important since in most applications people do an event-by-event baseline subtraction to get rid of low frequency noise in their apparatus. The 0.35 mV RMS also depend on the electronics around the chip. On our USB evaluation board the noise it typically smaller (0.31 mV RMS), while in some VME board we measure 0.42 mV RMS. If you do the perfect analog design around the chip, you can maybe push this maybe even lower.

To be honest, we never really succeeded to do any good simulation above let's say 500 MHz. We carefully tried to simulate the bond wire of the chip, the parasitic capacitances of the traces of the chip etc. but we always were off by a factor or two or so. Other groups reported the same problems. Some even did some 3D simulation model, without success. So our conclusion is that if you are interested in anything precise above 500 MHz, do a measurement.

So our current best design is with the THS4508. There is an AC coupled version going to 600 MHz, and a DC coupled version (uses more power) going to 800 MHz (-3dB). If you use passive inputs with a transformer for example, you can't go above 220 MHz. Next week I will publish both designs in this forum.

I found that sometimes even a reinitialization fails if the pull-down resistors are missing. So instead playing with capacitors at DVDD, I would just solder two resistors on the board which should fix the problem completely.

Something is wrong. I have 800 chips, and they all start up fine. Check with your scope the RESET, DSPEED, DENABLE and DTAP signals. When RESET is applied, DSPEED should go to 2.5 V. When DENABLE goes high, the domino wave is started and you should see DTAP toggle. DSPEED is then lowered by the PLL until DTAP matches your external reference clock. I usually keep DENABLE high all the time after initialization, so the domino wave just continues running.

Another problem could however be the chip readout. If some channel gives null output, it could be that your readout has a problem. Do you use RSRLOAD to initialize the readout sequence?

The design of high frequency differential input stages with the DRS4 is a challenge, since the chip draws quite some current at the input (up to 1 mA at 5 GSPS), which must be sourced by the input buffer. A simple transformer as used in the DRS4 Evaluation Board 2.0 limits the bandwidth to 220 MHz. In meantime two active input stages have been worked out and successfully been tested, both utilizing the THS4508 differential amplifier. The first design is AC-coupled and uses less power, the second design is DC-coupled and uses more power with the benefit of delivering a higher bandwidth.

Both designs use a clamping diode at the input as a protection against high voltage spikes at the input. We used a RCLAMP0502B diode from SEMTECH, but any fast voltage suppressor diode will do the job. 

The CMOFS input to the THS4508 set the common mode of the differential amplifier. In the AC version the level is set to mid-rail (2.5V), in the DC version it's set to 1.8V to match the input range of the DRS4.

The CAL+ and CAL- signals are used to bias the inputs to a well-defined DC level and can also be used to calibrate the chip. For bipolar inputs, they are both set to 0.8V. A positive 0.5V input pulse then drives DRS_IN+ to (0.8+0.25)V = 1.05V and DRS_IN- to (0.8-0.25)V = 0.55V. A negative 0.5V pulse then drives then DRS_IN+ to 0.55V and DRS_IN- to 1.05V. With ROFS=1.6V, the full dynamic range of the DRS4 is then used. Note that the THS4508 has a gain of 2, and the input has a -6dB voltage divider to compensate for that. To use other input ranges, such as -1V...0V, the CAL+ and CAL- signals can be adjusted accordingly. Note that the inputs of the DRS4 must always be between 0.1V and 1.5V.

AC-coupled version

                                                                                                                                                                                                                                     (click to enlarge)

Power supply: +5 V 40 mA

Bandwidth (-3dB): 600 MHz

CMOFS: 2.5 V

Transfer function:

                                                                                                                                                            (click to enlarge)

The transfer function was measured by applying a fixed amplitude sine wave to the input, and measuring the peak-to-peak value of the read out waveform with the DRSOsc application.

DC-coupled Version

The DC-coupled version has a slightly higher power consumption since there is a constant current flowing through the output into the DRS4 chip. On the other hand, the bandwidth is a bit higher and the peaking around 400 MHz is a bit smaller. The input is still AC-coupled, so both positive and negative pulses can be accepted. 

                                                                                                                                                                                                                             (click to enlarge)

Power supply: +5 V 115 mA

Bandwidth (-3dB): 800 MHz

CMOFS: 1.8 V

Transfer function:

                                                                                                                                                              (click to enlarge)

Achievable performance

With the active input stage, much faster rise- and fall times can be achieved. Following picture shows a signal from a external clock having a fall time of about 300 ps being recorded with the AC-coupled version of the active input stage. The fall time of the recorded signal is about 800 ps, which is about the minimum which can be achieved with the AC-coupled version. The DC-coupled version achieves about 700ps.

Just some ideas:

• Is DENABLE really kept high all the time?
• Is DRESET only applied once during initialization, after that it should stay high
• Does  REFCLK+/REFCLK- really toggle at the required sampling speed / 2048?
• Is the REFCLK really a good differential signal? Note that it must be biased properly since the DRS4 inputs are high impedance
• Is the Bit1 in the Config Register really at "1" to enable the PLL?

The only way the SRIN level could affect the PLL is if you address the Config Register (A="1100") and you clock in a few bits with SRCLK.

Have you thought about 'crazy' things such as:

• Defining the DRS4 chip wronly in your CAD software so that the pins are different from what you think?
• Some soldering problem of the DRS4 chips (we had this in the past) so that some pins are not connected at all and others have shorts

I guess you checked most of the things, so I'm just wildly guessing in order to stimulate some thoughts.

The ultimate check would be to get one of the evaluation boards (I sent a few to Jean-Francois Genat some time ago...) and compare the DRS4 signals pin by pin.

First, the 200 MHz is not correct. Table 1 clearly states ANALOG OUTPUTS - Bandwidth (-3dB): 50 MHz. This is also shown in plot 11 (revision 0.9). But that does not necessarily mean that you have to drive your discriminators from the input of the DRS4 chip. If you use this for triggering, a 1-2 ns timing jitter does not matter, since stopping the domino wave anyhow has a 3-4 cell jitter. If you send a very fast signal though a 50 MHz low pass filter, the timing anyhow doe not change, only the slope of your signal gets lower, so you are more sensitive to noise, which in turn causes the 1-2 ns timing jitter. But I personally would not worry about that too much. Putting any signal splitting components in the input path would reduce the input bandwidth, which would be much more of an issue.

So the main difference, if I understand correctly, is the setting of the Config Register. Actually I never tried that, I always went with the default settings (all "1"). What happens if you write "00000000"? You know Bit1 controls the PLL, maybe there is a bug and the signal needs to be inverted. 

Have you made sure that DENABLE and DWRITE stays low during the reset? 

Ok, then I have no idea. I never tried several reset pulses (actually this is not needed), so I have to reproduce the problem myself and investigate it. Actually in all my designs the reset input is just left open, since the internal initial reset is enough, so I have to modify my design first... 

Dear DRS4 users,

a new version of the evaluation board has been designed and is in production now. The main difference is that it uses active input amplifiers, which result in an analog bandwidth of 700 MHz (as compared with the 220 MHz of the previous board) at moderate power consumption, so the board can still be powered by the USB port. New orders will receive boards V3, the old V2 boards are not available any more.

It is mandatory to use the software revision 3.0.0 or later with the new board. This software has also many new features in the oscilloscope application, and together with the new firmware it reduces the noise of the board below 0.5 mV RMS. Although the software can be used with old V2 boards, some limitations might apply due to the old firmware of the boards. People having a Xilinx download cable can flash the firmware contained in the 3.0.0 revision to their V2 board to get all features of the new software.

The evaluation board manual V3 contains the new schematics of the analog inputs using the THS4508 differential amplifier, so people doing their own design can use this schematics as and example.

Best regards,

   Stefan Ritt

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 (low-to-high) 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 500-0.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

The expression ENOB for 1Vpp/0.35mV(RMS) is wrong, but I learned this later. Now I call it SNR. The ENOB is calculated in a more complicated way, see for example http://en.wikipedia.org/wiki/ENOB. If you measure the ENOB without timing correction, it's pretty poor (in the order of 7-8 bits). This is because without timing calibration, a sine input has huge side bands, and the ENOB involves the power of your signal over the power of the side bands. If you do a proper timing calibration, you spectrum gets "sharper", and hence the ENOB increases. But I have to admit that I never measured it carefully, since we are still optimizing the timing calibration. Once we have a perfect timing calibration, I will do it and update the data sheet. 

No you are right about that. The THS4508 has a gain of +2, and by using the resistor pairs we do

1) Reduce the gain back to unity

2) Reduce the input DC level from 1.8V to 0.9V to match the input range

3) Terminate the signals at the input of the DRS chip to minimize reflections

I know this is not so obvious from the schematic, so thanks for asking.

- Stefan 

No, not in this version. We plan a future version of the evaluation board with clock synchronization, but that board will not be ready before 2-3 months. Anyhow the board is more meant as an evaluation board, to test the chip and develop own electronics, and not to build a complete DAQ system. Note that CAEN distributes now a VME board containing the four DRS4 chips and 32 channels on a board. 

Well, one thing you can do is to generate an external trigger and send it to the external trigger input of both cards. Then you can determine the time in respect to the trigger point in both boards. But since the trigger cell jitters by 2-3 cells in each chip, the accuracy is limited to about 1-2 ns when running at 2 GS/s. 

Dear colleague,

if you live not so far from Zurich, you might be interested in this workshop:

http://www.xtronix.ch/hep/psi_workshop.htm

This is a combined PSI-CAEN presentation of digitizer hardware including the new V1742 board based on the DRS4 chip. The workshop will also show how digital pulse processing can be used to effectively extract time and energy from detector signals, and thus replace more and more traditional analog electronics. Please register at the above site if you are interested.

Best regards,

    Stefan Ritt

> Hello,
> 
> 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, wx-2.8)
> 
> The simple fix is given in  the following diff output.
> 
> Cheers,
> 
> Bob
> 
> diff drs-3.1.0_o/src/DOScreen.cpp drs-3.1.0/src
> 237c237
> <      wxst = wxString(m_frame->GetOsci()->GetDebugMsg(),wxConvUTF8);  //BH
> ---
> >       wxst = m_frame->GetOsci()->GetDebugMsg();
> 246c246
> <       wxst = wxString(m_debugMsg,wxConvUTF8);  //BH
> ---
> >       wxst = m_debugMsg;
> 477c477
> <     wxst = wxString("AUTO",wxConvUTF8); //BH
> ---
> >          wxst = "AUTO";
> 479c479
> <     wxst = wxString("TRIG?",wxConvUTF8);  //BH
> ---
> >          wxst = "TRIG?";
>  

Thanks for mentioning this. I always overlook this because I develop under Windows where this warning does not show 
up. I fixed that in the current version. Usually I just use _T() instead wxString() because this is shorter and 
recommended by the developers.

Cheers, Stefan.

Indeed that's what I had before. If you don't need the 9th channels, you can use it to identify the spikes. But we have applications where we need all 9 channels. That's why I made Osc::RemoveSpikes a bit more complicated, so it will still work when all 9 channels are used. This new version is release 3.1.0. If you just blindly subtract the 9th channel, your noise could increase by a sqrt(2). 

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 

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. 

I'm not so sure about the temperature stability of the default (DRS4 internal O-OFS) 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 "mis-used" as a comparator, where the comparator level (=LVDS negative input) comes from a DAC.

- Stefan

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

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

- Stefan 

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

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.

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 

In the attachement you will find a working DC-coupled 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.

You are right. The SYNCDELAY should contain three wait cycles. I kind of remember that this delay is not very critical. That might be the reason why the system works even with the wrong delay reliably. 

The issue is that the V4 board has new trigger capabilities (such as coincidences between two channels) which require a slightly different configuration. Here it the new code:

   /* use following lines to enable hardware trigger on CH1 at 50 mV positive edge */
   if (b->GetBoardType() == 8) {     // Evaluaiton Board V4
      b->EnableTrigger(1, 0);           // enable hardware trigger
      b->SetTriggerSource(1<<0);        // set CH1 as source
   } else {                          // Evaluation Board V3
      b->EnableTrigger(0, 1);           // lemo off, analog trigger on
      b->SetTriggerSource(0);           // use CH1 as source
   }

The complete file is attached. Please try again with the new code. Probably next week I will make a new software release (including a Mac version of all programs) which will contain the new code. Sorry for any inconvenience.

Best regards,
Stefan

If you just want to count pulses, you do not need a DRS board. Just use a discriminator and a counter, that's much simpler. The DRS board is not dead time free. 

I understand that. But still the board has some dead time which is dominated by the USB data transfer speed.

There is a way to perform the counting dead time free, but that requires the V4 board, which has a hardware comparator on all four channels (The V2 board has only one comparator and a multiplexer). The output of these comparators go directly to the FPGA, which can then trigger on these signals. In principle one could implement a hardware counter in the FPGA, which works practically dead time free. But this requires a new firmware which has to be written. Either you do it yourself using the Xilinx development tools, or you wait until I find some time to implement this, which could take a couple of weeks or even months.

Best regards,

Stefan 

Hello,

I'm co-organizing the upcoming Real Time Conference, which covers also fields of waveform processing and sampling, so it might be interesting for people working with the DRS4 chip. If you have recent results, you could also consider to send an abstract to this conference.  It will be nicely located in Berkeley, California. We plan excursions to San Francisco and to Napa Valley.

Best regards,

Stefan Ritt

18th Real Time Conference
June 11 – 15, 2012
Berkeley, CA

We invite you to the Hotel Shattuck Plaza in downtown Berkeley, California for
the 2012 Real-Time Conference (RT2012).   It will take place Monday, June 11
through Friday, June 15, 2012, with optional pre-conference tutorials Saturday
and Sunday, June 9-10.

Like the previous editions, RT2012 will be a multidisciplinary conference
devoted to the latest developments on realtime techniques in the fields of
plasma and nuclear fusion, particle physics, nuclear physics and astrophysics,
space science, accelerators, medical physics, nuclear power instrumentation and
other radiation instrumentation.

Abstract submission is open as of 18 January (deadline 2 March). Please visit

http://www.npss-confs.org/rtc/welcome.asp?flag=44675.77&Retry=1 to submit an

abstract.

Call for Abstracts 

RT 2012 is an interdisciplinary conference on realtime data acquisition and
computing applications in the physical sciences. These applications include:

* High energy physics 
* Nuclear physics 
* Astrophysics and astroparticle physics 
* Nuclear fusion 
* Medical physics 
* Space instrumentation 
* Nuclear power instrumentation 
* Realtime security and safety 
* General Radiation Instrumentation 

Specific topics include (but are certainly not limited to) the list shown below.
We welcome correspondence to see how your research fits our venue.   

Key Dates

* Abstract submission opened:  January 18, 2012 
* Abstract deadline:  March 2, 2012 
* Program available: April 2 

Suggested Topics

* Realtime system architectures 
* Intelligent signal processing 
* Programmable devices 
* Fast data transfer links and networks 
* Trigger systems 
* Data acquisition 
* Processing farms 
* Control, monitoring, and test systems 
* Upgrades 
* Emerging realtime technologies 
* New standards 
* Realtime safety and security 
* Feedback on experiences 

Contact Information

If you have a question or wish to opt in for occasional e-mail updates about
RT2012, send us a message at RT2012@lbl.gov. To view full conference
information, visit http://rt2012.lbl.gov/index.html

DRS4 is used for PMTs and APDs. The minimal rise/fall time which can be recorded with the DRS4 on the evaluation boards is about 0.8ns (see elog:84). Concerning charge measurement, it depends on your integration time. If your signal is for example 20ns and you sample with 5 GSPS, you get actually 100 samples. You digitize with 12 bits, but the S/N ratio is more like 11.5 bits. But since you have 100 samples, the accuracy of the measurement scales with sqrt(100)=10. So you have more like 11.5+3 bits = 14-15 bits, or a SNR of 20'000. Now your signal usually does not have an amplitude of 1V, will be more like 100mV or so, in which case your SNR goes to 2000. But this still gives you a resolution of 1/2000 = 0.5 per mille.

We did tests with a Ge detector for spectroscopy applications, where we used a shaping time of 2 micro seconds, both with traditional electronics and the DRS4, integrating the signal over 2 micro seconds. Both gave a resolution of about 0.4%, indicating that the resolution was not limited by the DRS but by the detector.

Best regards,

Stefan 

As I said above, you need a V4 board which has the four hardware comparators mounted. You cannot do that with the V2 board, even with a firmware upgrade.

The firmware upgrade for the V4 board is not yet ready and I won't have time for that in the next 3-4 weeks, but afterwards maybe.

Best regards,

Stefan 

Hi Sonai,

unfortunately I cannot teach you VHDL, you should take a course somewhere. Actually you don't have to touch the USB part, you just have to implement a new register in the firmware, and connect it to a VHDL counter attached to the trigger input. I will do this in a couple of weeks myself, so you can also just wait. I will however only do this for the V4 board, so you have to port it back to the V2 firmware.

Best regards,

Stefan

It is muuuuch easier to upgrade to a V4 board!

Modification of firmware is not so easy. You have to learn and understand VHDL. Then, you have to add additional registers for this thresholds, which requires modification of the C library as well. The data inside the evaluation boards is not yet calibrated (this is only done on the C library), so you have an uncertainty of 30-40mV in this data. 

No. 

There are two readout modes "Full Readout Mode" and  "ROI mode". 

In the Full Readout Mode, the Read Shift Register has to be initialized before the first readout by applying the sequence shown in Figure 11 in the data sheet. This clears the full shift register and sets the first cell to "1". In principle in the following events one applies each time 1024 clocks. Since the shift register is circula, the single "1" rotates through the shift register and is at the same position after 1024 clocks. So in principle the register does not have to be re-initialized. To be hones I have never tried this myself, so I'm not completely sure if that works.

In the ROI mode, you initialize the Read Shift Register by a single RSRLOAD pulse as shown in Figure 15. Since the inverter chain stops at different positions in each event, this pulse has to be applied before each event. The SROUT bits will then tell you where the inverter chain has been stopped.

Most people I know of use the ROI mode, since the initialization is much simpler (just a single pulse).

Best regards,

Stefan

If you run at 2 GSPS, you have a time window of 500 ns like on an oscilloscope. If you trigger on 1st PMT, you will get the traces of all 4 inputs for the next 500 ns. So I guess this is what you want. 

On the evaluation board, yes. This board is not optimized for high readout rate. If you do your own electronics, like GBit Ethernet, you could be much faster. 

With GBit Ethernet you get close to 100 MB/sec, which is the maximal line speed. The protocol to be implemented will achieve that rate. What one usually does is to send events in large blocks upon request from the PC. The trick is to do the request in a clever way, like using a high water mark on the receiving event buffer. So as long as the PC can digest the data quickly enough, the board just keeps sending, which means no overhead.

I have no experience with dev-c++, so I cannot be of help here. The supported systems are Linux and Windows with MS Visual C++. But it looks like the problems are related to compiling wxWidgets, which actually you do NOT need for drs_exam.cpp. The wxWidgets library is only needed for the DRSOsc application. If you want to compile it anyhow, first learn how to compile standard WxWidgets applications from

http://www.wxwidgets.org/docs/tutorials/devcpp.htm

Best regards,

Stefan 

I never worked out an exact formula for the parameters. It also depends if you want a fast locking time, or a low phase jitter of the PLL. A good starting point are the values from the evaluation board:

R = 130 Ohm

C1 = 4.7 nF

C2 = 1 uF

They should work from 800 MHz to 5 GHz.

- Stefan 

Just put (char) in front of wxT(...), like

   if (tc > 0) {

      wxString wxst1, wxst2;

      wxst1.Append((char)wxT('('));

      for (int i=0 ; i<5 ; i++)

         if (tc & (1<<i)) {

            if (i < 4)

               wxst1.Append((char) (wxT('1'+i)));

            else

               wxst1.Append((char) wxT('E'));

            wxst1.Append((char) wxT('|'));

         }

      for (int i=0 ; i<5 ; i++)

         if (tc & (1<<(i+8))) {

            if (i < 4)

               wxst1.Append((char) (wxT('1'+i)));

            else

               wxst1.Append((char) wxT('E'));

            wxst1.Append((char) wxT('&'));

         }

      if (wxst1.Length() > 0)

         wxst1 = wxst1.Left(wxst1.Length()-1);

      wxst1.Append((char) wxT(')')); 

wxst1.Append((char) (wxT((char)('1'+i))));     maybe ??? 

You mix up two things: The DRS5 chip is a new device with improved samling speed (10 GSPS) and lower dead time. This chip might come in 2-3 years. The 16-input board you mentioned is a DAQ board based on the DRS4 chip. This board well be operational beginning of 2013 as a prototype. It is not clear however at this point in which way this board will be made available for public. Maybe we will license this to industry. The design is however pretty much defined: 16 channels with gain 0.1-100, 1 GHz Bandwidth, Gigabit Ethernet output, and multi-board capabilities. Trigger on each channel with logical combinations. 80 MSPS continuous sampling (in addition to the DRS4 sampling). Each channel can be biased 0-210 V for SiPMT or APD power. A 19" 3 HE crate will host 16 boards with 256 channels.

/Stefan

Domino Ring Sampler. 

The "and" in the trigger section means now "coincidence". So the V4 board can trigger on a coincidence between two or more channels. If there is no pulse at the same time on the coincidence channels, the board will of course not trigger. The according firmware was introduced in V4, so please look at drs4_eval4_app.vhd (not eval3).

I just realized that the V4 firmware might be missing in the distribution, so I have attached it here. Look for drs_ctl_trigger_config.

Best regards,

Stefan

 Here it is.

 Yes, yes, no. To get spike removals, you need the function RemoveSpikes from Osci.cpp in the DRSOsc project.

This mode is not yet implemented in firmware. Maybe I find some time towards the end of this year to add this. At the moment, you have to build and external trigger to synchronize the two boards. There are also 16-channel boards on the market where you would not need a multi-board mode. Just Google for "DT5742".

/Stefan

I made a pre-compiled package for Mac OSX 10.8 (Mountain Lion), so one should be able to install the DRS Oscilloscope software with one mouse click on a recent Mac.

The Makefile in the tar ball now also supports OSX 10.8, so one could even compile it from the sources on a Mac, after libusb-1.0 and wxWidgets have been installed. That might then also work on older versions of OSX.

In addition, the software has been adaptes so that it compiles nicely on a Raspberry Pi (http://www.raspberrypi.org), a screenshot has been attached. Together with a Raspberry Pi and an old screen, the evaluation board is one of the cheapest available oscilloscopes.

You have to write your own program. DRS Oscilloscope does not (yet) support this. Take drs_exam.cpp as a starting point and try to extend it to two boards. One tricky point is that the external trigger may only fire AFTER the two boards have been read out. So you need some means of re-enabling the external trigger after you read out both boards.

Stefan 

The first thing to make work is to have DTAP oscillating with fsamp/2048. Keep Denable and Dwrite low (required during power-on, see elog:10), set Dspeed to 2.5V, then rise Denable and Dwrite. You should see Dtap toggling at about 2.4 MHz. If not, double check all supply voltages, and especially all soldering points. The QFN package is a bit hard to solder.

/Stefan 

After power-up reset, these registers are all set to "1", which should be ok to start.

BTW, Jinhong Wang <wangjinh@mail.ustc.edu.cn> from your institute hast the chip correctly working. Maybe he can help you in a more direct way than I can.

Sorry, I don't understand that question. The DRS4 Evaluation board input signal range is 1V. If you have larger signals, you have to attenuante them externally.

/Stefan 

 Sure, you can set the trigger level with the vertical slider (see attached figure). The trigger level works form -0.5V to +0.5V. Just like with a normal oscilloscope. I thought this would be obvious...

Sorry the late reply.

In V4, triggering has changed. You can trigger now on an OR or AND of channels. Therefore you have to supply a bitmask, where the 1st bit = CH1, 2nd bit = CH2 and so on. Have a look at the most recent drs_exam. It contains code:

   /* use following lines to enable hardware trigger on CH1 at 50 mV positive edge */
   if (b->GetBoardType() == 8) {     // Evaluaiton Board V4 
      b->EnableTrigger(1, 0);           // enable hardware trigger
      b->SetTriggerSource(1<<0);        // set CH1 as source
   } else {                          // Evaluation Board V3
      b->EnableTrigger(0, 1);           // lemo off, analog trigger on
      b->SetTriggerSource(0);           // use CH1 as source
   } 

So if you want CH1 && CH2, you look at the source code of SetTriggerSource. It contains

      // Set trigger configuration
   // OR  0=CH1, 1=CH2, 2=CH3, 3=CH4, 4=EXT
   // AND 8=CH1, 9=CH2, 10=CH3, 11=CH4, 12=EXT

So an AND between CH1 and CH2 needs a

    b->SetTriggerSource(1<<8 | 1<<9);

Your code looks interesting. Do you have a screenshot or can you explain what it does? 

The capacitors sample the input voltage, not the charge, so the actual size of the capacitors does not matter on first order (the variations might be in the order of 5%). A bigger effect is the variation of the analog switches in the front of the capacitors, which is about 15%. So the actual bandwidth each cell sees varies by maybe 20% (given by the R and the C), but this comes only into play when sampling steep edges.

Stefan

The buffer buffers the voltage, not the charge. The curves in Fig. 12, 14 indicate that the voltage followers take some time until they settle. 

Stefan

Interesting paper. I was not aware of this method. Sounds interesting. AFAIK, nobody has implemented it so far.

My (old) plan was to linearly interpolate samples (something you could do in an FPGA as well), but this will introduce (small) errors. The next best thing would be to do some spline interpolation, but this is time consuming and not suited for an FPGA.

If you get good results with the method above, please let others know about it.

/Stefan 

There is no way to select different polarities, it is not implemented in the firmware. Like your digital oscilloscope has also only one polarity switch.

The only way to do it is to use a (passive) inverter, so that you have two signals of the same polarity. Something like this:

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

> Hi,
> I am considering using the DRS4 evaluation board as an ADC card for the wire chamber in the physics lab (VP) experiment at ETH. However, the wire 
> chamber has 8 outputs, so I would need to have two of such boards. Is it possible to synchronise them, online or offline? From the website, it looks 
> like yes, but the documentation says that these features (trigger and clock out) may not have been implemented in firmware yet. Could you tell me 
> the status?
> 
> Thank you very much,
> 
> Dmitry.

I'm right now working on it. If you only need 2-3 ns accuracy  between the two boards then you can do this already now without firmware upgrade. The software for this is in principle ready, but I have to 
finish the documentation. Since I'm on a business travel right now this might take me some time (weeks?). 

If you want better timing (O(100ps)) between the boards, then you will need a firmware update. Or you wait until we ship boards with the new firmware. I will announce this through this forum.

Stefan

Nope.