Actually in the original drs_exam.cpp the sine wave oscillator is turned off with this command

/* use following line to turn on the internal 100 MHz clock connected to all channels  */
//b->EnableTcal(1);

If you remove the "//" then the generator gets enabled. Probably you did this by accident. With this line commented out, you see the proper input like this:

Event #0 ----------------------
  t1[ns]  u1[mV]  t2[ns] u2[mV]
  0.000     1.9   0.000    -2.4
  0.195     0.5   0.195     0.3
  0.391     0.1   0.391    -1.4
  0.586    -0.7   0.586    -0.4
  0.781    -1.1   0.781    -2.4
  0.977    -0.6   0.977     0.0
  1.172    -1.5   1.172    -2.8
  1.367    -0.4   1.367    -0.6
  1.562    -1.2   1.562    -3.8
  1.758    -1.5   1.758    -1.7
  1.953    -1.0   1.953    -3.3
  2.148    -0.7   2.148    -1.8
  2.344    -1.6   2.344    -4.2
  2.539     0.5   2.539    -1.5
  2.734     0.2   2.734    -3.6
...

167.969    -3.4 167.969    -5.2
168.164    -3.7 168.164    -3.6
168.359     0.0 168.359    -2.0
168.555     1.9 168.555    -0.2
168.750     2.8 168.750    -2.8
168.945     5.4 168.945    -1.4
169.141    18.0 169.141     1.2
169.336    26.6 169.336     2.7
169.531    46.2 169.531     0.4
169.727    56.2 169.727     1.6
169.922    93.3 169.922     0.1
170.117   115.6 170.117     0.0
170.312   174.4 170.312    -1.5
170.508   206.9 170.508    -0.8
170.703   282.2 170.703    -2.4
170.898   328.4 170.898    -1.2
171.094   419.6 171.094    -3.2
171.289   465.8 171.289    -2.5
171.484   500.0 171.484    -2.0
171.680   500.0 171.680    -0.6
171.875   500.0 171.875    -4.0
172.070   500.0 172.070    -1.1
172.266   500.0 172.266    -3.7
172.461   500.0 172.461    -2.1
172.656   500.0 172.656    -5.0
172.852   500.0 172.852    -3.3
173.047   500.0 173.047    -4.8
173.242   500.0 173.242    -4.1
173.438   500.0 173.438    -5.1
173.633   500.0 173.633    -3.3
173.828   500.0 173.828    -6.4
174.023   500.0 174.023    -3.9
174.219   500.0 174.219    -5.5
174.414   500.0 174.414    -3.2
174.609   500.0 174.609    -3.6
174.805   500.0 174.805    -2.6
175.000   500.0 175.000    -5.2
175.195   500.0 175.195    -2.7
175.391   434.3 175.391    -3.9
175.586   391.7 175.586    -2.4
175.781   312.2 175.781    -4.1
175.977   275.7 175.977    -1.8
176.172   202.4 176.172    -3.8
176.367   167.6 176.367    -1.4
176.562   117.4 176.562    -2.9
176.758    96.1 176.758    -2.3
176.953    62.8 176.953    -3.3
177.148    49.1 177.148    -1.8
177.344    35.9 177.344    -4.3
177.539    33.4 177.539    -2.6
177.734    30.4 177.734    -4.2
...

Hi Rodrigo, I'm wondering how you solved your original triggering problem. We are also having trouble with collecting data continously using the example. Thanks.

I see. Where is the code that we can use to turn off the generator? I thought the example is taking data with CH1 as the trigger.

For our board, which is BoardType == 9, it is running these lines:

      b->EnableTrigger(1, 0);           // enable hardware trigger
      b->SetTriggerSource(1<<0);        // set CH1 as source

Is that not using the hardware trigger with CH1 as the source?

Sure, that’s correct. The example program turns on the internal sine wave generator in case people don’t have a real signal. That’s why it’s called „example“. Find the code which turns on the generator and change it. You will also have to change the trigger settings depending on your actual signal.

Stefan

We are using the drs_exam.cpp to read out waveforms, but it seems to be outputting only sin waves on all channels - as if it was reading out the simulated waveform from the oscilloscope program if we run it without the board plugged in. Does anyone know what is causing this?

We are taking data with a pulser plugged into channel 1, which produces a single pulse with width of 8ns, and nothing plugged into channel 2. 

Our board is as follows:

Found DRS4 evaluation board, serial #2567, firmware revision 21305
Board type: 9

The output is something like the following:

Event #0 ----------------------
  t1[ns]  u1[mV]  t2[ns] u2[mV]
  0.000  -452.7   0.026  -469.3
  0.289  -460.8   0.293  -469.8
  0.413  -477.3   0.400  -481.5
  0.642  -485.3   0.650  -482.4
  0.806  -486.9   0.821  -477.8
  1.086  -476.8   1.085  -457.2
  1.183  -467.3   1.162  -446.4
  1.450  -435.6   1.459  -405.1
  1.619  -410.1   1.630  -373.3
  1.843  -366.2   1.851  -323.9
  1.945  -342.9   1.948  -298.9
  2.221  -275.7   2.210  -229.3
  2.359  -237.6   2.357  -187.6
  2.602  -165.6   2.609  -111.2
  2.687  -141.1   2.697   -84.3
  2.976   -50.5   2.987     5.5
  3.164     8.4   3.144    53.3
  3.377    73.9   3.384   124.2
  3.503   111.4   3.506   158.0
  3.753   182.0   3.769   226.9
  3.924   227.5   3.929   265.8
 

Dear Stefan, 

Thanks so much for clarifying this. We made wait_vdd a parameter controlled by software and will try to experiment with it to find some compromise between deadtime and the offset added by the droop in VDD. 

Best regards, 

Andrew

Dear Andrew,

the posting you mention is still accurate. Any power supply will drop when you start the Domino wave, no matter how big your capacitor is. Unfortunately the output signal of the DRS4 scales with VDD. So if your VDD drops by 40 mV and you get a trigger and you immediately start the readout, the output baseline will also be shifted by about 40 mV. If you are sensitive to dead time, you can remove the wait_vdd state completely, but then you have to deal with varying baseline shifts. If you have narrow signals sitting on a broad baseline, you can correct for this by measuring the baseline outside your signal, then subtracting it before integrating your pulse. If you have lots of pile-up in your signals, it might sometimes be hard to evaluate the baseline on an event-by-event basis.

Stefan

Dear Stefan,

I am working with others at UCLA on a custom made board built around the DRS4. We are in the process of writing firmware so I am adapting the readout state machine from the evaluation board firmware.

I see in the state machine of the eval board firmware that after a trigger is received, the FPGA goes into the start readout state and then into "wait_vdd", where the FPGA waits "~120 us for vdd to stabilize" before reading out the ADC.

Our application is sensitive to deadtime and this wait_vdd state adds very significantly.  I am trying to find anything explaining the necessity of wait_vdd in the documentation / elog and have only found so far your old forum posting, https://elog.psi.ch/elogs/DRS4+Forum/12

Does this forum posting explain wait_vdd or is there a another purpose that I have missed?

If this post is relevant to wait_vdd, does the advice of large capacitance and an LDO with fast transient response still apply or are there any new recommendations?

Thank you,

Andrew Peck

If you have two signal going through two cables, the cable have never the same length (on a scale of picoseconds), and you have to calibrate that anyway. So a proper timing calibration is not a crutch.

What do you mean by "manual 50ps"? The manual does not mention any resolution. In my experience, you can achieve about 10ps between channels of the SAME board easily. The phase shift between boards in multi-mode is always there, unfortunately there are no cable which conduct current faster than the speed of light! What you can do is to split a common reference clock and send a copy to one channel of each board, then calculate the timing relative to the next edge in that reference signal. This way you get rid of the phase shift, but this is also a kind of calibration, so in your laguange that would be "a big crutch".

Stefan

Good afternoon, I use 5 boards in multi-mode, everything is connected according to the instructions. Can I measure the phase difference between the two signals on channel 1 and channel 20? with each board the phase shift is added +16 ns I can not figure out how to compensate for this. give thanks

I understand this, thanks. But my Chief does not understand this, he wants to see the phase difference without “crutches”. And what is meant in the manual 50 ps resolution? Maybe I just do not understand something? And if you submit a reference signal not in the mode of a garland, but simultaneously in parallel to all the boards, will this shift go? Thanks

Lev Pavlov

Good afternoon, I use 5 boards in multi-mode, everything is connected according to the instructions. Can I measure the phase difference between the two signals on channel 1 and channel 20? with each board the phase shift is added +16 ns I can not figure out how to compensate for this. give thanks

Subtract 16 ns from your measured value ;-)

Stefan

Good afternoon, I use 5 boards in multi-mode, everything is connected according to the instructions. Can I measure the phase difference between the two signals on channel 1 and channel 20? with each board the phase shift is added +16 ns I can not figure out how to compensate for this. give thanks

Good afternoon, I use 5 boards in multi-mode, everything is connected according to the instructions. Can I measure the phase difference between the two signals on channel 1 and channel 20? with each board the phase shift is added +16 ns I can not figure out how to compensate for this. give thanks

Dear Stefan,

I have emailed drs4@psi.ch a couple of times regarding the pricing of the evaluation kits for academic use in India and have not received any reply and hence writing in this forum. Could you please help me in this?

Thanks and regards,
Deepak Samuel.

The older root macro did not work for me for data acquired with the newest software.

so for the newest software and multiple boards, I modified the read_binary.cpp into read_binary.C for those who like to use the root macro, see the attachment.  

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

"dynamic" or "static" does not matter, as long as you don't use your program on another computer. I have no more idea about the "no board found" problem. It works ok on all computers I tried at our lab.

Stefan

Hello. When compiling drs_exam, do you need to use a "static "version of usblib or a "dynamic" version?"The problem with "no board found" is not solved. Thanks for your help.

Lev.

Could be. Have you tried that elog:657

Stefan

Hey. Yes, the program is running as administrator. By the way, this is win10. Your drs_exam works fine. My drs_exam compiled wrote no board found. Maybe this is a problem like in the post https://elog.psi.ch/elogs/DRS4+Forum/698. Maybe there were solutions to the problems?

Thank You

Lev

No idea. Maye some access problem. Have you tried to start your program under an admin account?

Stefan