No this is not possible. But you can delay your signal externally (like with a delay cable or electronically) and then send the dealyed signal to the evaluation board for triggering.

Stefan

Thank you for your reply!

I am using the V5 board at a fixed sampling frequency. With the `drsosc` app I have executed the time calibration at 5 GS/s (actually 5.12 GS/s). This is how my setup looks like in the app:

Now I want to replicate this using the C++ API (not the positive width measurement shown, the signal sampling only). I am seting the sampling frequency to 5 GS/s, as I do in the `drsosc` app. Then I get the time information using the `DRSBoard::GetTime(unsigned int chipIndex, int channelIndex, int tc, float *time)` function (which I don't find defined either in `DRS.h` or `DRS.cpp` but somehow it works). How can I know if these times that I get here are being corrected with the time calibration? If so, should I expect the time resolution to be < 3 ps? Are these 3 ps accumulative, such that in the end I end up having a contribution from the evaluation board of 3 ps × 5 Gs/s × 100 ns where 100 ns is the time difference between my two pulses? (This does not seem to be the case because if so I would expect the jitter to be ~ 1 ns, and we see that the "Pos Width" measurement is ~ 0.1 ns std.)

Why am I asking? I want to measure the jitter between the two falling edges. This cannot be done easily with the `drsosc` app I think, so I am acquiring the data and doing this offline. I have done this measurement in the past using a LeCroy WaveRunner oscilloscope with 20 GS/s and 4 GHz bandwidth (offline, same code) and I have seen it vary from ~5 ps → 30 ps when I vary a voltage that I can control. Now if I calculate this time fluctuation using the data acquired with the V5 evaluation board I get a value ~100 ps and independent of this voltage, which leads me to conclude that the limiting factor is being the evaluation board itself. So now I am wondering if I have reached its limit, or if there is some setting that can still improve this result.

Thanks!

DRSBoard::GetTime is declared in DRS.h line 720.

If you want to measure timing down to ps, you need some basic knowledge, especially about signal-to-noise and risetime. This cannot be taught in a few sentenses, needs a full lecture. As a starting point please read that papat:

https://arxiv.org/abs/1405.4975

then you will understand why you measure different resolutions with different peak heights (and different rise times).

Concerning the DRS4 measurement, please be aware that the sampling poings are not equidistant, like not every 200ps for GSPS. They vary bin by bin significantly, from 50ps to 300ps. So you alway have to analyse the X/Y points as an array, not just the Y values assuming deltaX of 200ps. Probably you forgot that. Then, you have to interpolate between bins to find the crossing over your threshold. Linear interpolation is already good, spline interpolation even better. Deep inside Measurement.cpp of the drsosc program you find in the source code:

t1 = (thr*(x1[i]-x1[i-1])+x1[i-1]*y1[i]-x1[i]*y1[i-1])/(y1[i]-y1[i-1]);

which is the linear interpolation (thr is the threshold). You have to use (and understand!) similar code.

Best,
Stefan

Dear Stefan,

For the time of each bin I am using the values returend by `GetTime` without any assumption by my side. I did not notice before that the sampling time is not uniform, but I see that this is already happening. This is an example plot from one of the signals I processed:

The bin at 65.5 ns and the next one are closer than their neighbors. So this seems to indicate that the time calibration is being taken into account when I acquire the time bins using `GetTime`, is this correct?

To obtain the final time resolution I am using the constant fraction discriminator method and the signals are linearly interpolated to obtain the time at each percentage value, as seen in the plot. I have already measured time resolutions in the 5-100 ps range with exactly the same setup but using the LeCroy oscilloscope, which I am using just for data acquisition, and my software for offline analysis as shown in the plot above. Now what I am trying to do is to replace the LeCroy by the DRS4 Evaluation Board basically, so I can use the oscilloscope in a different setup.

Best,
Matias.

Looks like you have the some time calibration, not sure if it's the correct one. Sample the sine wave from the calibration clock, once with and once without the timing calibration, then you will see if all points lie on a smooth line. Left: without timing calibration, right: with proper timing calibration:

If your points do not lie on a smooth line, you might habe a problem such as the wrong channel for calibration, an offset of 1 in the index of the time array or some other software bug. Measure the same signal with the DRSOsc application and then your code. If the results differ, you have a software problem on your side.

Stefan

Thanks for your help. If I look into the app the behavior for the 4 channels is exactly as you show:

Now, when I sample with my code something strange happens, two of the channels are fine and the other two are wrong:

This is a surprise to me because I acquire the 4 channels in the same way within a `for` loop. To get the time data I use `DRSBoard::GetTime` with the `tcalibrated` argument set to `true`. Is there any aditional step to use the calibration?

Best,
Matias.

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 

First thing is to do another voltage calibration. Disconnect input, "Config", "Execute Voltage Calibration". If this does not fix the problem, the board is probably broken. This can happen if you send very high input singals to the board (like >10V) and exceed the maximul allowed limit from the datasheet. In that case the board needs to be repaired. Please contact me directly (via email) so that we can make you a quote.

Best regards,
Stefan

 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 Stefan,

We are using an DRS4 board V5.1 for building a metering system for the scintillator detector by a Labview program. The program was built based on the functions in DRS.cpp and it reads data from channel 0 very well (Fig 1). Now, I am having a problem with the data acquisition from DRS4 board. The data acquisition speed on this program is only about 30-50 Acq / s, while using the DRS Oscilloscope that of about 300-400 Acq / s.

When the program was installed with fDominoMode = 0 and fDominoActive = 0, the data acquisition speed was about 300-400 Acq / s. However, the waveform is inaccurate.

I do not know if I installed the wrong function! Can you show me how to solve this problem?

In the Labview program, functions (corresponding to functions in DRS.cpp) are called with the following parameters:

InitFPGA();

SetMultiBuffer(0);

fROFS = 1.6;              // differential input range -0.5V ... +0.5V

fRange = 0;

SetDAC(fDAC_ROFS_1, fROFS);

 fCommonMode = 0.8;        // 0.8V +- 0.5V inside NMOS range

SetDAC(fDAC_CALP, fCommonMode);

SetDAC(fDAC_CALN, fCommonMode);

SetDAC(fDAC_BIAS, 0.70);

/* set default number of channels per chip */

SetChannelConfig(0, fNumberOfReadoutChannels - 1, 8);

// set ADC clock phase

      fADCClkPhase = 0;

      fADCClkInvert = 0;

   // default settings

fMultiBuffer = 0;

   fNMultiBuffer = 0;

   fDominoMode = 1;

   fReadoutMode = 1;

   fReadPointer = 0;

   fTriggerEnable1 = 1;

   fTriggerEnable2 = 0;

   fTriggerSource = 0;

   fTriggerDelay = 0;

   fTriggerDelayNs = 0;

   fSyncDelay = 0;

   fNominalFrequency = 1;

   fDominoActive = 1;

// load calibration from EEPROM

ReadCalibration();

...

SetDominoMode(fDominoMode);

   SetReadoutMode(fReadoutMode);

   EnableTrigger(fTriggerEnable1, fTriggerEnable2);

   SetTriggerSource(fTriggerSource);

   SetTriggerDelayPercent(0);

   SetSyncDelay(fSyncDelay);

   SetDominoActive(fDominoActive);

   SetFrequency(fNominalFrequency, true);

   SetInputRange(fRange);

SelectClockSource(0); // FPGA clock

// disable calibration signals

   EnableAcal(0, 0);

   SetCalibTiming(0, 0);

   EnableTcal(0);

   // got to idle state

   Reinit();

////////

SetFrequency (1,false);

settranspmode (1);

setinputrange(0);

EnableTcal (0,-,-);

EnableTrigger(1, 0);

SetTriggerSource(0);

SetTriggerLevel(0);

SetTriggerPolarity(false);

SetTriggerDelayNs(512);

// in loop of read data from DRS4:

 {

StartDomino();

while (b->IsBusy());

TransferWaves(0, 8);

GetTime(0, 0, b->GetTriggerCell(0), time_array[0]);

GetWave(0, 0, wave_array[0]);

}

Thank you very much!

Best Regards,

Chuan

How do you tigger the board? In your code below you start the board (StartDomino()) and then wait for a trigger. Setting the trigger level to zero (via SetTriggerLevel(0)) is certainly wrong. Please have a look at drs_exam.cpp in the distribution and use the same functions used there. If you want to trigger the board, you need some external pulser with high enough rate (more than 500 Hz or course). You can also "software" trigger the board with a call to SoftTrigger() just after StartDomino(). This is then like the "auto" trigger on an oscilloscope.

Stefan

Thank Stefan Ritt, I added the SoftTrigger() just after StartDomino(), so now, The data acquisition speed the same speed as in the DRS oscilloscope. I have misunderstood the "auto" trigger on an oscilloscope as setting SetTriggerLevel (0).
Thank so much!

Phan Van Chuan

Hi Stefan,

    I have a question regarding the DRS 4 evaluation board firmware for the 8051 controller embedded in the CY7C68013 USB chip: on the board the controller is running at 12 MHz and the FIFO interface of the USB chip is running at 30 MHz, so the number of delay cycles for synchronization as defined in fx2sdly.h should be (3*12000+5*30000-1)/(2*30000)=3, but the actual number used in drs_eval.c is (3*12000+5*48000-1)/(2*48000)=2, so there is a mismatch between the IFCLK frequency used in this calculation and the actual IFCLK frequency configured. Am I misunderstanding something or is there an explanation for that?

    Thanks,

Hao Huan

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. 

Hello everybody,

I was trying to create a stand-alone program that would perform a time calibration on the board. My goal would be the following.

- acquire  about 10k sinus waveforms

- write them to disk (also for later reanalysis)

- run the time calibration on the recorded data

- store the clibration results in a file / database

Being not an expert, my question here is the following. Would it be easier to try to isolate the time calibration part from the DRS.cpp source code or re-write entirely the code from scratch?

Thanks.

Hard to say. Timing calibration is quite delicate. If you start from scratch, better read this paper: https://arxiv.org/abs/1405.4975

If you try to extract the code from DRS.cpp, better read the paper, too. Probably it will not be possible to develop or extract the code without knowing how it works. 

Best,
Stefan

Hi Stefan,

Thank you for your reply. I have read the paper already. I looked through the code and I understand that the LTC and GTC are performed by the AnalyzeSlope and AnalyzePeriod functions, respectively, correct? It seems to me to be a complicated business to re-write that part from scratch, at least for an inexperienced programmer like me. It made more sense to try to isolate that part from the original DRS.cpp. Ideally, I would like to have a stand-alone program that would work on any SCA without references to the drs hardware specifics.

Than you can try to isolate the code. Note that different SCAs might work differently. Like the DRS4 has a channel-to-channel jitter which others might not. But you will see.

Stefan

Thank you for your help Stefan. I will try to get the TC part isolated.