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

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?

Unfortunately I don't have a pi here right now, so I cannot reproduce your problem. I checked on a linux system and it worked fine with wxWidgets 3.0.1 and GTK2 2.20. The wxWidget library sends an wxID_EXIT event to DOFrame::OnExit, which then closes the window. The destructor of DOFrame then calls SaveConfig() to save the current settings. Maybe you can debug this.

/Stefan 

When running drsosc on a raspberry pi, it seems the exit doesn't seem to work at all.  This is true for the "exit" button on the window, or the file menu exit, or the "x" on the window.  I end up having to kill drsosc manually from the command line.  This wouldn't be such a bad thing except that it doesn't seem to store any settings when killed in this way.  I'm wondering if anyone else sees the same thing, or if there is a fix out there, before I go and delve into why.

 Hi,

    Is there a straightforward way to convert the xml file format into the binary format?  I have some runs taken mistakenly with xml.

Best,

Chris

> Dear Stefan
> 
> I have a problem considering binary data files.
> Usually binary files start with TIME... (the time calibration header). But I observed the following reproducible problem.
> 1. Start to save a binary file (e.g. 001.dat) with 1000000 events. 
> 2. Hit the close button before this limit has reached. (so far the binary files seems to be ok) 
> 3. Start to save again a file with the SAME filename (and agree to replace the already existing it)
> If I do it like this, the file has no time information anymore and starts directly with EHDR.
> 
> could it be that the m_evSerial counter is not reset in this specific situation?
> 
> Cheers,
> Roman

This problem has also been fixed in version 5.0.3

/Stefan

> Dear Stefan
> 
> after having some problems with writing binary files with more than 4 drs boards (in multiboard-mode) I might 
> have found the solution.
> In the file src/Osci.cpp at line 838 is: 
> unsigned char buffer[100000];
> 
> If I understand the binary format right, this works only with up to four boards. With the maximum number of 
> boards in your specification (16 boards) and all channels switched on on all boards this array needs to have 
> about 400000 entries (for the first event, where the time information is written too).
> 
> Could you please cross-check that?
> 
> Thank you very much!
> Cheers,
> Roman

This problem has been fixed in software version 5.0.3

/Stefan

Here is the full version of the program with clock daisy-chaining. Before switching to the external clock, it checks if the clock really is there (by reading an internal scaler), and only then enables it. Note that the code also works without clock daisy-chaining. But without clock daisy-chaining your have some 400 ps time resolution between boards, and with clock daisy-chaining you get some 60 ps.