ID |
Date |
Author |
Subject |
370
|
Fri Sep 12 13:41:43 2014 |
Stefan Ritt | synchronizing 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 Ritt | compilation 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 Ritt | compilation 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 Ritt | Timing 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 Ritt | USB 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 Ritt | USB 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 Ritt | USB 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 Ritt | USB 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 Ritt | Clock 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 Ritt | Clock 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. |
Attachment 1: drs_exam_multi.cpp
|
/********************************************************************\
Name: drs_exam_multi.cpp
Created by: Stefan Ritt
Contents: Simple example application to read out a several
DRS4 evaluation board in daisy-chain mode
$Id: drs_exam_multi.cpp 21509 2014-10-15 10:11:36Z ritt $
\********************************************************************/
#include <math.h>
#ifdef _MSC_VER
#include <windows.h>
#elif defined(OS_LINUX)
#define O_BINARY 0
#include <unistd.h>
#include <ctype.h>
#include <sys/ioctl.h>
#include <errno.h>
#define DIR_SEPARATOR '/'
#endif
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include "strlcpy.h"
#include "DRS.h"
/*------------------------------------------------------------------*/
int main()
{
int i, j, k;
DRS *drs;
DRSBoard *b, *mb;
float time_array[8][1024];
float wave_array[8][1024];
FILE *f;
/* do initial scan, sort boards accordning to their serial numbers */
drs = new DRS();
drs->SortBoards();
/* show any found board(s) */
for (i=0 ; i<drs->GetNumberOfBoards() ; i++) {
b = drs->GetBoard(i);
printf("Found DRS4 evaluation board, serial #%d, firmware revision %d\n",
b->GetBoardSerialNumber(), b->GetFirmwareVersion());
if (b->GetBoardType() < 8) {
printf("Found pre-V4 board, aborting\n");
return 0;
}
}
/* exit if no board found */
if (drs->GetNumberOfBoards() == 0) {
printf("No DRS4 evaluation board found\n");
return 0;
}
/* exit if only one board found */
if (drs->GetNumberOfBoards() == 1) {
printf("Only one DRS4 evaluation board found, please use drs_exam program\n");
return 0;
}
/* use first board with highest serial number as the master board */
mb = drs->GetBoard(0);
/* common configuration for all boards */
for (i=0 ; i<drs->GetNumberOfBoards() ; i++) {
b = drs->GetBoard(i);
/* initialize board */
b->Init();
/* select external reference clock for slave modules */
/* NOTE: this only works if the clock chain is connected */
if (i > 0) {
if (b->GetFirmwareVersion() >= 21260) { // this only works with recent firmware versions
if (b->GetScaler(5) > 300000) // check if external clock is connected
b->SetRefclk(true); // switch to external reference clock
}
}
/* set sampling frequency */
b->SetFrequency(5, true);
/* set input range to -0.5V ... +0.5V */
b->SetInputRange(0);
/* enable hardware trigger */
b->EnableTrigger(1, 0);
if (i == 0) {
/* master board: enable hardware trigger on CH1 at 50 mV positive edge */
b->SetTranspMode(1);
b->SetTriggerSource(1<<0); // set CH1 as source
b->SetTriggerLevel(0.05); // 50 mV
b->SetTriggerPolarity(false); // positive edge
b->SetTriggerDelayNs(0); // zero ns trigger delay
} else {
/* slave boards: enable hardware trigger on Trigger IN */
b->SetTriggerSource(1<<4); // set Trigger IN as source
b->SetTriggerPolarity(false); // positive edge
}
}
/* open file to save waveforms */
f = fopen("data.txt", "w");
if (f == NULL) {
perror("ERROR: Cannot open file \"data.txt\"");
return 1;
}
/* repeat ten times */
for (i=0 ; i<10 ; i++) {
/* start boards (activate domino wave), master is last */
for (j=drs->GetNumberOfBoards()-1 ; j>=0 ; j--)
drs->GetBoard(j)->StartDomino();
/* wait for trigger on master board */
printf("Waiting for trigger...");
fflush(stdout);
while (mb->IsBusy());
fprintf(f, "Event #%d =====================================================\n", j);
for (j=0 ; j<drs->GetNumberOfBoards() ; j++) {
b = drs->GetBoard(j);
if (b->IsBusy()) {
i--; /* skip that event, must be some fake trigger */
break;
}
/* read all waveforms from all boards */
b->TransferWaves(0, 8);
for (k=0 ; k<4 ; k++) {
/* read time (X) array in ns */
b->GetTime(0, k*2, b->GetTriggerCell(0), time_array[k]);
/* decode waveform (Y) arrays in mV */
b->GetWave(0, k*2, wave_array[k]);
}
/* Save waveform: X=time_array[i], Channel_n=wave_array[n][i] */
fprintf(f, "Board #%d ---------------------------------------------------\n t1[ns] u1[mV] t2[ns] u2[mV] t3[ns] u3[mV] t4[ns] u4[mV]\n", b->GetBoardSerialNumber());
for (k=0 ; k<1024 ; k++)
fprintf(f, "%7.3f %7.1f %7.3f %7.1f %7.3f %7.1f %7.3f %7.1f\n",
time_array[0][k], wave_array[0][k],
time_array[1][k], wave_array[1][k],
time_array[2][k], wave_array[2][k],
time_array[3][k], wave_array[3][k]);
}
/* print some progress indication */
printf("\rEvent #%d read successfully\n", i);
}
fclose(f);
printf("Program finished.\n");
/* delete DRS object -> close USB connection */
delete drs;
}
|
390
|
Thu Oct 16 16:15:16 2014 |
Stefan Ritt | binary 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 Ritt | binary 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 Ritt | Raspberry 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 Ritt | Mac 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 Ritt | Running 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 Ritt | Clock 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 Ritt | DRS4 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 Ritt | DRS4 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 Ritt | Getting 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
|
|
|