I see your point. Actually I will soon have the same issue since we design right now a board with an AD9637 using the transparent mode. Which one are you using? The common mode range given in the datasheet is limited to guarantee optimal performance. But some ADCs allow a slightly bigger common mode range with reduced performance, but which might still be ok for some application. A "real" solution would be to put switchable level shifters between the DRS and the ADC, but that requires 8 additional chips which is bad. Alternative the ADC could pick up the signal not at the DRS output but at the DRS input, but that would aslo require additional chips for multiplexing. So unfortunately no perfect solution for that...

Here's the problem. My external ADC has 2Vpp differtial input voltage range. And the common-mode voltage of the inputs need to be 1.3V. I cannot make both the transparent-output and the readout-output meet the ADC input requirement.

The ROFS signal has no effect in the transparent mode, so you have to adjust O_OFS between sampling and transparent mode accordingly. Either use a DAC or two voltages with an analog switch.

Hello Mr. Stefan Ritt

  For DRS4 differential inputs ranges form 500mV to 1100mV, with ROFS set to 1.55V, O_OFS set to 1.3V, the outputs of DRS4 is shown in the attachment.

  The left part of the waveform,DRS4 works in transparent mode, and then the readout take place. The DMV of transparent mode is bigger then the readout mode, and that makes ADC sampling harder.How may I solve this problem?

  Best wishes!

                                 Chenfei Yang

DRSBoard::GetTriggerSource() simply returns what has been enabled via DRSBoard::SetTriggerSource(). The actual source which causes the trigger is not stored in the hardware of the board, because I can be reconstructed easily from the waveforms. So just look which of the channels is above your trigger threshold. If none of the channels has a waveform obove the threshold, then the trigger must have been come from the external trigger.

I am trying to use 4 evaluation boards with a powered USB hub (since eventually, I will have to do this on a laptop).  It seems like destroying the DRS object is insufficent to properly close the boards when on the hub (i.e. I get usb read errors next time I run my program). When all the boards are plugged into the computer, all is fine.  This is on Linux using libusb1. My guess is something about resetting the port doesn't work properly (but maybe that's this particular hub's fault?).  Has anyone else experienced a similar issue. If not, can someone recommend a hub that is known to work?

I'd like to be able to know which channel (0,1,2,3 or external) was responsible for the trigger.  DRSBoard::GetTriggerSource() seems to always return 1.  Is there a way to get this information?  Using the DRS4 evaluation board and software version 5.0.3.

Thanks,

Cosmin

Sure, for a V3 board you need a pre-V5 software, but I assumed Julien had a V5 board. 

I also use Ubuntu 14.04 LTS and for my V3 borad I have to use drsosc 4.x or ealier to perform the calibration.

1) I tried to cablirate a V5 board with drsosc 5.0.3 and it just worked fine for me. No idea what went wrong in your case.

2) The "found 4096 stuck pixels on this board" can be safely ignored. It comes from the fact that the standard evaluation board has four cannels unconnected (the DRS4 chip has 8 channels, four are connected to in the evaluation board and four are unconnected). So the software sees wrong values on four channels because they are unconnected and thinks something is wrong. Unfortunately the software cannot determine if the channels are connected or not. So just ignore it.

3) I heard several people having to reset their boards under Linux in a similar way than you. This is probalby due to some instability in the USB part of the linux kernel, since the problem does not occur on other systems (Windows, Mac OSX). So I cannot do anything from the software side.

/Stefan

Your first assumption is correct, e.g.

source = 00000000'00000001 = 0x0001 ==> CH1

source = 00010001'00000000 = 0x1100 ==> CH1 and EXT

So the lower byte is the "OR" block, and the upper byte is the "AND" block. Both blocks are combined via an "OR" so

source = 00011000'00000011 = 0x1803 is (EXT and CH4) OR (CH1 or CH2)

The "OR" combination between the two blocks is fixed in the firmware and cannot be changed without changing the firmware, but theoretically any logical combination between five inputs would be possible if you touch thr firmware.

/Stefan

The resolution coming from the sampling rate goes into these numbers, but just marginally. At 5 GSPS, you get a few ps reolution, while at 1 GSPS, you get like 15 ps. If you convolve 15 ps with 400 ps, you get 400.3 ps, which is not significantly worse than 400 ps.

Hi Stefan,

do you know how these numbers (400ps and 60ps) scale with the sampling rate? The manual says they are for 5GS/s, do they change with slower sampling?

Thanks and best regards,

Simon

Hi

I have a question about the function SetTriggerSource in the class DRSBoard (DRS.h/DRS.cpp)

In the implementation there is the following comment:

// 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

What does this exactly mean? I am assuming that this are the bits which are set?

e.g

source = 1 ==> CH1

source = 4352 = 0x1100 ==> CH1 and ext

How is the AND/Or logic implemented?

When i have:

source = 0x1803 (bit 12,11,1,0)

what is the right way to set the brackets to expalin the logic?

(EXT and CH4 ) or CH2 or CH1 ?

Cheers Felix Bachmair

ETH Zurich

Hi,

I`m trying to calibrate my DRS4 evoluation board to an input range of 0-1V but it doesn`t work.

1) First I tried to calibrate it with the drsosc (version 5.0.3) Software. The -0.5V - 0.5V calibration works, but during the 0 - 1V calibration the Software crashes.

2) I also tried to calibrate the input range with a C++ DAQ Package (based on drs_exam). Here the code of the calibration:

    ....

    b->SetInputRange(0.) (Center at 0 V )

    b->CalibrateVolt(NULL);

   ....

   Calibration Works

   ....

   b->SetInputRange(0.5) (Center at 0.5 V )

   b->CalibrateVolt(NULL);

  ....

   Results in: Found 4096 stuck pixels on this board.

Did I do a mistake or is this a normal behaviour of the board? Also the board often crashes and I get a magic number 0000 after restarting the DAQ. Then the board needs to be restarted via pulling the plug. ( I ensured that I terminate the USB connection before I close the program with "delete drs"). Is there a possibility to avoid this error?

My OS: Ubuntu 14.04 LTS.

Ciao,

Julien

I don't know if it helps, but we measured the time resolution between two independendly running v3 boards using a single PC (latest software) in Linux. (http://arxiv.org/abs/1405.4975)

You start the DRS DAQ program with only one USB board connected, first. Afterwards connect the second board and start another session. If you externally trigger (global) both boards with less than 1 Hz, you can garantee that both programs save the same events independently (from two individual DRS boards).

Daniel

I never had in mind running two systems in parallel, that's why the code claims all interfaces when started. You have to dig into the usb code which is located in musbstd.c at function musb_open(). There you will find a line libusb_claim_interface() which requests exclusive access to the usb subsystem. The code is there because I copied it from some standard example for the libusb library. You have to read the documentation for libusb (http://libusb.sourceforge.net/api-1.0/) and see if you can get rid of that. Probaby you have to claim/release the interface on each access, but I never tried that.

Stefan

Hi,

we want to run two instances of our little DRS DAQ program but obviously the first instance started always claims all DRS boards for itself and the other one exits with an error. The 2 boards used in the example below have the serial number # 2413 and #2414 and are v5 boards.

The first one:

mathes@ikauger5:~/src/DRS4/Cpp> ./drsdaq -b 2413
DRSController: found board with serial number #2413
DRSController: found board with serial number #2414
DRSController: using board with serial number #2413
CalibratedFrequency= 1.00721
====================================
DRS type:            DRS4
Board type:          9
Serial number:       2413
Firmware revision:   21260

...
And the second one:

mathes@ikauger5:~/src/DRS4/Cpp> ./drsdaq -b 2414
musb_open: usb_set_configuration() error -6
musb_open: Found USB device 0x04b4:0x1175 instance 0, but cannot initialize it: please check permissions on "/proc/bus/usb/1/7" and "/dev/bus/usb/1/7"
USB successfully scanned, but no boards found
...

How can our goal be achieved?

Thanks

Hermann-Josef

Hello,

I compiled base file for drs system  (DRS.cpp) to root framework (root.cern.ch) as dynamic library DRS.so. It can be used for building many kind of applications under the root system. I applied it for older version of  root 5.28 and for latest version 6.02 too.

If anyone is interesting, I can help, please write to me andrzej.grzeszczuk@us.edu.pl

Regards

Andrzej

> Hello,
> 
> I can compile version 5.0.3 of DRS4sc on Mac OSX 10.0 without errors but when I want to execute the program I get the following error:
> 
> [home]$ ./DRSOsc
> DRSOsc(48068,0x7fff7ac5e300) malloc: *** error for object 0x7f88d9434a80: incorrect checksum for freed object - object was probably 
> modified after being freed.
> *** set a breakpoint in malloc_error_break to debug
> 
> Is this a known error? Will it be fixed in the next release?

When I compile on OSX 10.10.1 with XCode 6.1.1 I get no error. I'm using wxWidgets 3.0.0. Same when I compile with the command line 
tools (which you first have to install from Apple) via "make", "make app", "open ./DRSOsc.app". You cannot start a graphical program 
directly from the command line like under Linux, you have to make an app and the do "open <app>".

Best regards,
Stefan