Hi Bill,

there are several reasons why we have not yet published Daniel's method (I'm in constant contact with him).

1. The method still changes, becomes simpler and more accurate. Originally he used sine waves with varying frequency, which you only get from an external function oscillator. Currently, we found that a single frequency could do a similar, maybe even better job. The current result is much better than the 20-25ps quoted at MIC 2012.

2. Daniel found out that for the ultimate resolution you have to calibrate each channel inside a chip separately. I do understand in meantime the reason for that. So I plan for a V5 evaluation board, which contains means of sending a log-jitter clock to all channels. This board is in test phase and will be made available once it's working as expected.

So my plan is to finish the V5 board and implement the best possible timing calibration on it. Daniel achieved already <5 ps RMS (!) independent of the delay between the two optimal pulses (up to 50 ns). This is actually better than what you can do with a high-end oscilloscope, since scopes have internal interleaving and similar problems due to aliasing etc. than the DRS chip, but scope manufacturers do not put such an emphasis on accurate timing measurements. Once we can reproduce the 5 ps result with the evaluation board, we will publish it. When we found the optimal method, we plan to write a paper about it and explain everything in great detail. We will also be at Seoul for MIC 2013. I'm topic convener there for the session "Digitalization, Acquisition, and Signal Processing Technologies". So probably we will put the DRS4 timing talk there, since it's of more general interest not only to medical applications (and honestly, for a 150 ps TOF-PET you do not need a 5 ps electronics resolution). So stay tuned!

/Stefan

You misunderstood. The answer is yes. drs_exam.cpp contains already code to write to an ASCII file. If you actually look into the file, you see:

   f = fopen("data.txt", "w");
   ...
   b->GetTime(0, b->GetTriggerCell(0), time_array);
   ...
   b->GetWave(0, 0, wave_array[0]);
   ...
   fprintf(f, "%5.2f %6.2f\n", time_array[i], wave_array[0][i]);

which actually pulls out the timing and voltage and writes it to the file.

 Ha! So then the answer is no, there isn't a ready made function/method to pull out the timing and voltage,  like how it was done in osci.cpp. That's all I wanted to know. (Not whether you would write it for me! Only trying to save time!) Thanks!

/Jill

Hi Stefan,

Is either some example code or a detailed written description available for the improved DRS4 timing-calibration algorithm described by Daniel Stricker-Shaver at MIC 2012?  I think you told me that you had verified the results with your own test set-up, so I figure there must be at least two sets of code in existence to implement this calibration.  (I have Daniel's presentation slides.)

I managed to find a ping-pong distribution of cell widths that looks quite similar to that shown in Daniel's slides, using an algorithm similar to the technique one uses to find radial offsets in a tracking chamber (i.e. using residuals weighted by track slope), but I'd rather use the method with which you and Daniel have already found good results.  (The attached graph shows in black the histogram of cell widths for essentially the algorithm used in DRS.cpp/DRSBoard::AnalyzeWF, and in blue the histogram of cell widths extracted from the slope-weighted residuals for a periodic reference signal.)

By the way, since Daniel finds a FWHM coincidence-timing resolution around 20-25ps at 5 GSPS (for perfectly identical pulses), should I expect a FWHM resolution (for synthesized, ideal pulses) of around 50-65ps at 2 GSPS?

(I'm posting here instead of writing you both privately because I figure there may be broader interest in Daniel's algorithm.)

-Bill

Well, you have to learn C programming, I won't do it for you. drs_exam.cpp contains already code to write to the ASCII file data.txt, so you just can use that or modify it to your needs.

/Stefan

 Stefan, thanks for your help so far. If I go with your plan A of just modifying drs_exam.cpp, is there a quick way to get it to save the data from the wave, like how osci.cpp spits out an xml file? (Ignoring the cascading aspect for now)

Thanks again :)

/Jill

 Hi,

Does anyone has a program that converts a binary file from drsosc  output to a ROOT tree format?

Thank you,

Dmitry.

Sure it would be possible to code it, but it's not just a few lines. Besides Osci.cpp you have to massage DOScreen.cpp, Measurement.cpp and probably more since they all rely on the array size of the waveform. So if I would do it it would take me probably a couple of days including the debugging, which I don't have right now. Furthermore, as I said you have to combine all eight channels properly. For two channels, it's already pretty complicated (see lines 3537+ in DRS.cpp). I had to make myself a visual scheme in order to understand it correctly, which I attached. For eight channels, the write shift register (WSR) can have values 0-7, depending in which channel you got a trigger. Then you have to sort it out again to get one linear array with the proper order of the fragments. So you see, it's not just changing a few lines of code. In principle it's possible, but it's lots of work.

Best regards,

Stefan

 Would it be possible to just hardcode a few lines in the SetChannelConfig in DRS.cpp method as such:

     fChannelConfig = 0x01; //gives me eight
      d = fChannelConfig | (fDominoMode << 8) | (1 << 9) | (fWSRLoop << 10) | (0xF8 << 8);

      Write(T_CTRL, REG_CHANNEL_CONFIG, &d, 2);
      fChannelDepth = 8 * (fDecimation ? kNumberOfBins/2 : kNumberOfBins);// gives eight times the bins

then modify the GetWave method/function to include another else if statement similar to  "else if (fChannelCascading == 2) {"  but would be modifidied for fChannelCascading == 8?

By, "But then you will hit the hard-wired limit in Osci.cpp" do you mean  hard-coded? Would changing the hard code just amount to resizing all of the arrays, and replacing all the '2*kNumberBins"  with '8*kNumberBins' ?

I'm afraid of drs_exam.cpp because it doesn't come with all the perks of Osci.cpp. It seems less daunting to just modify Osci.cpp then to try understanding everything I need to include in drs_exam.cpp because I'm also using an external trigger, and saving the waveform to an external text file.

Thanks!

/Jill

Sorry for my late reply, I was away for some days.

To use channel cascading, you have to physically connect one input to all eight channels. This is not possible with the evaluation board, you have to make your own board. What you could do however is to split a signal externally and feed it to all four inputs, given that the signal delay is the same for every channel. But then you will hit the hard-wired limit in Osci.cpp. This code was never foreseen to cover 8*1024 bins (since it does not make much sense with the evaluation board). Some arrays are only 2*1024 bins wide, so you would have to rewrite code at many places.

The easiest way to get what you want is to modify drs_exam.cpp. You need SetChannelConfig(0, 8, 1) as you realised correctly, and then you have to retrieve all 8 channels via b->GetWave() and concatenate them correctly.

/Stefan 

Thanks for reporting the problem in drs_exam.cpp. The windows and linux versions sometimes differ a bit. I'm working right now on a complete new version, wich will bring both together again.

Concerning fTriggerDelayNs and ticks, they are correlated. One tick is a single delay unit in the FPGA. On the newest boards the unit is 4.8ns long. So

ticks = fTriggerDelayNs / 4.8

fTriggerDelayNs = ticks * 4.8

fTriggerDelayNs gets set at the first line of SetTriggerDelayNs:

int DRSBoard::SetTriggerDelayNs(int delay)
/* set trigger delay in nanoseconds */
{
   short ticks, reg;
   fTriggerDelayNs = delay;

So I cannot see how fTriggerDelayNS should get diverse values?

All I'm trying to do is cascade one input signal, though all available channels, so that I end up with 8*1024 bins per event.

Here is the read out on my board/chip:

Mezz. Board index:    0
DRS type:             DRS4
Board type:           8
Serial number:        2249
Firmware revision:    17662
Temperature:          35.2 C
Input range:          -0.5V...0.5V
Calibrated range:     -0.5V...0.5V
Calibrated frequency: 5.120 GHz
Status reg.:          0000001A
Control reg.:         00000010
  DMODE circular
Trigger bus:          00000000
Frequency:            5.120 GHz

What I've tried thus far:

In Osci.cpp, in the method/function  SelectSource(int board, int firstChannel, int chnSection), I added a line.. (in bold)

//----------------------------------------------------------------------------------------------------------------------------------------------

 if (b->GetBoardType() == 5 || b->GetBoardType() == 7 || b->GetBoardType() == 8) {
         
        
             if (chnSection == 2)
                b->SetChannelConfig(0, 8, 4);
             //added
             else if(chnSection == 1)
                 b->SetChannelConfig(0, 8, 2);
             //added
             else
                b->SetChannelConfig(0, 8, 8);
//----------------------------------------------------------------------------------------------------------------------------------------------

I've also tried doing settings such as SetChannelConfig(0, 8, 1);   , SetChannelConfig(0, 8, 2); , SetChannelConfig(0, 1, 2); , etc..

Which always ends up making the run fail.. and sometimes I get index errors..

As far as I understanding the program now, this is what I know:

fChannelCascading determines getChannelCascading,
this determines the  if (casc == 2) line in configDialogue.cpp, which sets:
 b->SetChannelConfig(config, 8, 4);

fChannelCascading is being set by:
 switch (nConfigChannels) {
      case 1:
         fChannelConfig = 0x01;
         fChannelCascading = 8;
         break;
      case 2:
         fChannelConfig = 0x11;
         fChannelCascading = 4;
         break;
      case 4:
         fChannelConfig = 0x55;
         fChannelCascading = 2;
         break;
      case 8:
         fChannelConfig = 0xFF;
         fChannelCascading = 1;
         break;
      default:
         printf("Invalid channel configuration\n");
         return 0;
      }

which is being set by nConfigChannels in DRS.cpp, in the method:
SetChannelConfig(int firstChannel, int lastChannel, int nConfigChannels)



SetChannelConfig is being called in the ConfigDialogue.cpp,  but the default Osci program is such that you can't do a configuration for a cascade of one signal using all the channels. At least, not that I am aware of. 

So what buttons do I need to enable, or what do I need to call, or write, so that I can cascade a signal to end up with 8*1024 bins per event?

This has had me going in circles for weeks, so thank you for your help!!!!

I have noticed some differences in the source code between Windows (4.0.0) and Linux (4.0.1) Version.

drs_exam.cpp: In the windows version when setting the trigger there is no part "if (b->GetBoardType() == 8) {...} else {...}" like in Linux version. So under Windows drs_exam does not start readout of DRS 4 Evalutation Board V4, because it does not get the trigger, under linux the board can be read out succesfull. I have found out, that adding the missing part solves the problem for the windows version.

drs.cpp (Windows Version), line 2101, function "int DRSBoard::SetTriggerDelayNs(int delay)":

There is no operation which  calculates the variable "fTriggerDelayNs" out of variable "ticks" like in function "int DRSBoard::SetTriggerDelayPercent(int delay)" (Line 2073). So "fTriggerDelayNs" can get diverse values when using one of the Trigger Setting Functions. Was this intended?

The "Chip Test" command is made for a special test board we use for chip testing. This command will not work with the evaluation board, since only four of the 8 DRS channels are connected there. So just ignore it and verify the board functionality by looking at the graphical interface.

/Stefan 

Nope. 

Hello, Stefan. Have you implemented pulse counting yet?

Best, Osip.

> 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

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.

When starting Chip Test in DRS Command Line Interface, I receive the following message:

Cell error on channel 1, cell 5: -154.4 mV instead 0 mV

Chip Error!

What does this mean? The maximal peak-to-peak Amplitude given to channel was for a short time 10V.

The graphical interface shows no artefacts when using channel 1.

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