DRS4 Forum
  DRS4 Discussion Forum, Page 15 of 45  Not logged in ELOG logo
ID Date Authordown Subject
  370   Fri Sep 12 13:41:43 2014 Stefan Rittsynchronizing two DRS4 evaluation boards readout with one computer

Dmitry Hits wrote:

Stefan Ritt wrote:

Dmitry Hits wrote:

 Hi everyone,

Has anyone tried to synchronize 2 (two) DRS4 evaluation boards readout by the same computer? I have read about some attempts on this board in the past, but I do not know if they have succeeded. If yes, could you share your experience and/or software.

Thank you very much,

Dmitry.

 

Please read the manual http://www.psi.ch/drs/DocumentationEN/manual_rev50.pdf page 25 where this is described in detail.

/Stefan

 Hi Stefan,

 

Thank you for pointing me to the document. Does it apply only to version 5 of the board or can it be applied also to version 4 (which is the one I have)?

Dmitry

In principle it should also work with version 4, but I'm not sure how well the V4 software supports this. You might try the V5 software with your V4 boards.

/Stefan 

  372   Fri Sep 12 16:08:49 2014 Stefan Rittcompilation error for v5.0.2

Dmitry Hits wrote:

 Hi,

I am getting the following compilation error when trying to compile version 5.0.2 software:

src/DOFrame.cpp:617:14: error: invalid conversion from ‘char*’ to ‘wxChar {aka wchar_t}’ [-fpermissive]
 
I have wxWidgets v. 2.8.12 package on Fedora version 3.9.10-100.fc17.x86_64
 
Has anyone seen this before?
 
Thank you,
 
Dmitry 

 

---------------------------------------------------------------------------------------------

Full error report:

g++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -I/usr/local/include -DOS_LINUX -DHAVE_USB -DHAVE_LIBUSB10 -DUSE_DRS_MUTEX -I/usr/lib64/wx/include/gtk

2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -c src/DOFrame.cpp
src/DOFrame.cpp: In member function ‘void DOFrame::LoadConfig(char*, int)’:
src/DOFrame.cpp:617:14: error: invalid conversion from ‘char*’ to ‘wxChar {aka wchar_t}’ [-fpermissive]
In file included from /usr/include/wx-2.8/wx/memory.h:16:0,
                 from /usr/include/wx-2.8/wx/object.h:20,
                 from /usr/include/wx-2.8/wx/wx.h:16,
                 from include/DRSOscInc.h:9,
                 from src/DOFrame.cpp:9:
/usr/include/wx-2.8/wx/string.h:1413:13: error:   initializing argument 1 of ‘wxString& wxString::operator+=(wxChar)’ [-fpermissive]

I don't get this error under gcc 4.4.7, so I guess you have a newer version. Each one becomes more picky. Just try to replace

str += filename; 

with

str += (wxString) filename;

in line 617 of DOFrame.cpp

/Stefan

 

  375   Mon Sep 22 14:52:21 2014 Stefan Rittcompilation error for v5.0.2

Dmitry Hits wrote:

Stefan Ritt wrote:

Dmitry Hits wrote:

 Hi,

I am getting the following compilation error when trying to compile version 5.0.2 software:

src/DOFrame.cpp:617:14: error: invalid conversion from ‘char*’ to ‘wxChar {aka wchar_t}’ [-fpermissive]
 
I have wxWidgets v. 2.8.12 package on Fedora version 3.9.10-100.fc17.x86_64
 
Has anyone seen this before?
 
Thank you,
 
Dmitry 

 

---------------------------------------------------------------------------------------------

Full error report:

g++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -I/usr/local/include -DOS_LINUX -DHAVE_USB -DHAVE_LIBUSB10 -DUSE_DRS_MUTEX -I/usr/lib64/wx/include/gtk

2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -c src/DOFrame.cpp
src/DOFrame.cpp: In member function ‘void DOFrame::LoadConfig(char*, int)’:
src/DOFrame.cpp:617:14: error: invalid conversion from ‘char*’ to ‘wxChar {aka wchar_t}’ [-fpermissive]
In file included from /usr/include/wx-2.8/wx/memory.h:16:0,
                 from /usr/include/wx-2.8/wx/object.h:20,
                 from /usr/include/wx-2.8/wx/wx.h:16,
                 from include/DRSOscInc.h:9,
                 from src/DOFrame.cpp:9:
/usr/include/wx-2.8/wx/string.h:1413:13: error:   initializing argument 1 of ‘wxString& wxString::operator+=(wxChar)’ [-fpermissive]

I don't get this error under gcc 4.4.7, so I guess you have a newer version. Each one becomes more picky. Just try to replace

str += filename; 

with

str += (wxString) filename;

in line 617 of DOFrame.cpp

/Stefan

 

Hi Stefan,

 

Unfortunately that did not work and from suggestions in the error I do see a good solution:

----------------------------

src/DOFrame.cpp: In member function ‘void DOFrame::LoadConfig(char*, int)’:

src/DOFrame.cpp:617:25: error: call of overloaded ‘wxString(char [1024])’ is ambiguous

src/DOFrame.cpp:617:25: note: candidates are:

/usr/include/wx-2.8/wx/string.h:722:3: note: wxString::wxString(const wxWCharBuffer&) <near match>

/usr/include/wx-2.8/wx/string.h:722:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘const wxWCharBuffer&’

/usr/include/wx-2.8/wx/string.h:692:3: note: wxString::wxString(wxChar, size_t) <near match>

/usr/include/wx-2.8/wx/string.h:692:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘wxChar {aka wchar_t}’

/usr/include/wx-2.8/wx/string.h:690:3: note: wxString::wxString(const wxString&) <near match>

/usr/include/wx-2.8/wx/string.h:690:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘const wxString&’

/usr/include/wx-2.8/wx/string.h:682:3: note: wxString::wxString(int) <near match>

/usr/include/wx-2.8/wx/string.h:682:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘int’

---------------------------------

 

let me know if you see one.

 

Thank you,

 

Dmitry.

 

 

 

_____________________________________________________________________________________________________________________________________________

Full error:

++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -I/usr/local/include -DOS_LINUX -DHAVE_USB -DHAVE_LIBUSB10 -DUSE_DRS_MUTEX -I/usr/lib64/wx/include/gtk

2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -c src/DOFrame.cpp

src/DOFrame.cpp: In member function ‘void DOFrame::LoadConfig(char*, int)’:

src/DOFrame.cpp:617:14: error: invalid conversion from ‘char*’ to ‘wxChar {aka wchar_t}’ [-fpermissive]

In file included from /usr/include/wx-2.8/wx/memory.h:16:0,

                 from /usr/include/wx-2.8/wx/object.h:20,

                 from /usr/include/wx-2.8/wx/wx.h:16,

                 from include/DRSOscInc.h:9,

                 from src/DOFrame.cpp:9:

/usr/include/wx-2.8/wx/string.h:1413:13: error:   initializing argument 1 of ‘wxString& wxString::operator+=(wxChar)’ [-fpermissive]

[dmitry@kitkat ~]$ more error-drs4v5_2

g++ -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -I/usr/local/include -DOS_LINUX -DHAVE_USB -DHAVE_LIBUSB10 -DUSE_DRS_MUTEX -I/usr/lib64/wx/include/gtk

2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -pthread -c src/DOFrame.cpp

src/DOFrame.cpp: In member function ‘void DOFrame::LoadConfig(char*, int)’:

src/DOFrame.cpp:617:25: error: call of overloaded ‘wxString(char [1024])’ is ambiguous

src/DOFrame.cpp:617:25: note: candidates are:

In file included from /usr/include/wx-2.8/wx/memory.h:16:0,

                 from /usr/include/wx-2.8/wx/object.h:20,

                 from /usr/include/wx-2.8/wx/wx.h:16,

                 from include/DRSOscInc.h:9,

                 from src/DOFrame.cpp:9:

/usr/include/wx-2.8/wx/string.h:722:3: note: wxString::wxString(const wxWCharBuffer&) <near match>

/usr/include/wx-2.8/wx/string.h:722:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘const wxWCharBuffer&’

/usr/include/wx-2.8/wx/string.h:692:3: note: wxString::wxString(wxChar, size_t) <near match>

/usr/include/wx-2.8/wx/string.h:692:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘wxChar {aka wchar_t}’

/usr/include/wx-2.8/wx/string.h:690:3: note: wxString::wxString(const wxString&) <near match>

/usr/include/wx-2.8/wx/string.h:690:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘const wxString&’

/usr/include/wx-2.8/wx/string.h:682:3: note: wxString::wxString(int) <near match>

/usr/include/wx-2.8/wx/string.h:682:3: note:   no known conversion for argument 1 from ‘char [1024]’ to ‘int’

make: *** [DOFrame.o] Error 1 

I just tried with the current Ubuntu version (gcc version 4.8.2, wxWidgets 3.0.1) and it worked without any problem. So please upgrade to wxWidgets 3.0.1

/Stefan

  376   Mon Sep 22 15:04:37 2014 Stefan RittTiming Calibration Fail

Hannes Wachter wrote:

Hi,

has anyone experienced a shutdown of the DRSosc.exe or DRScl.exe when executing a Timing Calibration? Also, when we add the command b->CalibrateTiming(NULL); to the drs_exam.cpp and run the exe, our program shuts down immediately and windows shows an error message (identical to DRSosc and DRScl).

Any help is appreciated.

 

Actually there is no need to call b->CalibrateTiming() at all from drs_exam.cpp. The timing calibration, once executed, will remain valid over a wide temperature range and for very long time (years), so no need to redo it over and over again.

/Stefan 

  378   Mon Oct 13 16:46:56 2014 Stefan RittUSB Microcontroller firmware

Stephane Debieux wrote:

Hi,

I'm trying to recompile the USB microcontroller firmware starting from the drs_eval.c file but I'm not able to get a .iic file close to the one provided with the eval board. It seems to me that this drs_eval.iic file does not match the drs_eval.c and drs_eval.hex files or that I'm doing something wrong. Could you please help or give me an explanation.

Thank you.

Stephane

 

I did not touch the firmware since a couple of years, but I can confirm that the drs_eval.iic is the correct firmware file, since we use this one on all of our boards. To program it, you need the Cypress USB Console. You remove the jumper (to detach the EEPROM), then power the board (which then boots from the internal memory), connect to the board via the Cypress console, the put back the jumper while the board is running, then program the file into the EEPROM.

Best,
Stefan 

  380   Mon Oct 13 17:14:58 2014 Stefan RittUSB Microcontroller firmware

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Hi,

I'm trying to recompile the USB microcontroller firmware starting from the drs_eval.c file but I'm not able to get a .iic file close to the one provided with the eval board. It seems to me that this drs_eval.iic file does not match the drs_eval.c and drs_eval.hex files or that I'm doing something wrong. Could you please help or give me an explanation.

Thank you.

Stephane

 

I did not touch the firmware since a couple of years, but I can confirm that the drs_eval.iic is the correct firmware file, since we use this one on all of our boards. To program it, you need the Cypress USB Console. You remove the jumper (to detach the EEPROM), then power the board (which then boots from the internal memory), connect to the board via the Cypress console, the put back the jumper while the board is running, then program the file into the EEPROM.

Best,
Stefan 

 Thank you Stefan.

Would that be possible to get the corresponding drs_eval.c source file since I'm assuming the one provided with the eval board is not the right one?

Thank you.

Stephane

There is only one drs_eval.c version around, and I confirm that it is the one in the distribution. If you use different compiler settings, like optimisations, you might get a different executable file (and thus a .iic file), but the files have the same functionality.

Stefan 

  382   Tue Oct 14 16:29:12 2014 Stefan RittUSB Microcontroller firmware

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Hi,

I'm trying to recompile the USB microcontroller firmware starting from the drs_eval.c file but I'm not able to get a .iic file close to the one provided with the eval board. It seems to me that this drs_eval.iic file does not match the drs_eval.c and drs_eval.hex files or that I'm doing something wrong. Could you please help or give me an explanation.

Thank you.

Stephane

 

I did not touch the firmware since a couple of years, but I can confirm that the drs_eval.iic is the correct firmware file, since we use this one on all of our boards. To program it, you need the Cypress USB Console. You remove the jumper (to detach the EEPROM), then power the board (which then boots from the internal memory), connect to the board via the Cypress console, the put back the jumper while the board is running, then program the file into the EEPROM.

Best,
Stefan 

 Thank you Stefan.

Would that be possible to get the corresponding drs_eval.c source file since I'm assuming the one provided with the eval board is not the right one?

Thank you.

Stephane

There is only one drs_eval.c version around, and I confirm that it is the one in the distribution. If you use different compiler settings, like optimisations, you might get a different executable file (and thus a .iic file), but the files have the same functionality.

Stefan 

I'm very sorry to insist but if I take the .hex of the distribution, convert it to .iic using the hex2bix utility, and reprogram the board, I can't read the board correctly (invalid magic number read with drscl for instance). Also, when using the uVision2 project file you provide and compiling the drs_eval.c, I get the same result  (i.e. no way to generate a functional .iic file starting from the sources). So, either I'm doing something wrong (and I don't know what) or the drs_eval.c is not the correct one.

And what happens if you program the .iic file from the distribution? 

  384   Tue Oct 14 16:38:14 2014 Stefan RittUSB Microcontroller firmware

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Stefan Ritt wrote:

Stephane Debieux wrote:

Hi,

I'm trying to recompile the USB microcontroller firmware starting from the drs_eval.c file but I'm not able to get a .iic file close to the one provided with the eval board. It seems to me that this drs_eval.iic file does not match the drs_eval.c and drs_eval.hex files or that I'm doing something wrong. Could you please help or give me an explanation.

Thank you.

Stephane

 

I did not touch the firmware since a couple of years, but I can confirm that the drs_eval.iic is the correct firmware file, since we use this one on all of our boards. To program it, you need the Cypress USB Console. You remove the jumper (to detach the EEPROM), then power the board (which then boots from the internal memory), connect to the board via the Cypress console, the put back the jumper while the board is running, then program the file into the EEPROM.

Best,
Stefan 

 Thank you Stefan.

Would that be possible to get the corresponding drs_eval.c source file since I'm assuming the one provided with the eval board is not the right one?

Thank you.

Stephane

There is only one drs_eval.c version around, and I confirm that it is the one in the distribution. If you use different compiler settings, like optimisations, you might get a different executable file (and thus a .iic file), but the files have the same functionality.

Stefan 

I'm very sorry to insist but if I take the .hex of the distribution, convert it to .iic using the hex2bix utility, and reprogram the board, I can't read the board correctly (invalid magic number read with drscl for instance). Also, when using the uVision2 project file you provide and compiling the drs_eval.c, I get the same result  (i.e. no way to generate a functional .iic file starting from the sources). So, either I'm doing something wrong (and I don't know what) or the drs_eval.c is not the correct one.

And what happens if you program the .iic file from the distribution? 

It works as expected.

 Then why don't you use the .iic file and forget about the hex and c files? Honestly speaking, I don't remember what source file I compiled a couple of years ago, and it could be that an older file slipped into the repository, but that's all I have. I would have to investigate myself, try to compile and program the c file, do the debugging, and find out what the differences are. But unfortunately I don't have time for that right now. So just stick with the .iic file.

  387   Wed Oct 15 10:52:58 2014 Stefan RittClock settings in daisy chain DAQ

Simon Weingarten wrote:

Hi,

I'm currently working on a little DAQ system with four DRS evaluation boards. Do i need to apply any specific settings when using the clock in/out connectors for synchronization? I do not see anything like that in the drs_exam_multi example.

Any help would be greatly appreciated!

Best,

Simon

Right, I did not yet put any code there. What you need on all slave boards is

b->SetRefclk(true);

b->SetFrequency(...);

Set SetFrequency() is needed to restart the boards with the external clock.

This works of course only if you have the clock signals connected as written in the manual. If not, the boards won't work after you switch the reference clock.

Best regards,
Stefan 

  389   Wed Oct 15 12:15:58 2014 Stefan RittClock settings in daisy chain DAQ

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.

  390   Thu Oct 16 16:15:16 2014 Stefan Rittbinary files with more than 4 drs board ver. 5.0.2
> 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
  391   Thu Oct 16 16:16:12 2014 Stefan Rittbinary files time calibration header in drs-5.0.2
> 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
  394   Tue Nov 25 14:06:34 2014 Stefan RittRaspberry Pi drsosc does not exit properly

Mickey Chiu wrote:

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.

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 

  396   Fri Jan 16 14:12:19 2015 Stefan RittMac OSX Yosemite 10.10
> 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
  399   Tue Mar 17 02:53:26 2015 Stefan RittRunning 2 instances of a DRS DAQ program

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

Hermann-Josef Mathes wrote:

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

 

  404   Mon Apr 20 13:08:24 2015 Stefan RittClock settings in daisy chain DAQ

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.

Simon Weingarten wrote:

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

Stefan Ritt wrote:

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.

 

 

  405   Tue Apr 21 12:01:45 2015 Stefan Ritt DRSBoard::SetTriggerSource

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

 

Felix Bachmair wrote:

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

 

  406   Tue Apr 21 12:52:18 2015 Stefan RittDRS4 Evaluation Board Baseline/Voltage 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

Julien Wulf wrote:

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

 

  408   Tue Apr 21 13:06:39 2015 Stefan RittDRS4 Evaluation Board Baseline/Voltage Calibration

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

Daniel Stricker-Shaver wrote:

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.

  411   Wed May 13 08:19:53 2015 Stefan RittGetting Trigger Source

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.

Cosmin Deaconu wrote:

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

 

 

ELOG V3.1.5-fe60aaf