I have been trying to compile my changes to the program, but have a problem with the "wxWidgets". can you tell me which version of the wxWidgets and which c++ program did you use to built the drs4's scope program?

I'm using "microsoft visual c++ 2010 express", and the closest I got to compile something was with the wxWidgets 2.8.12 version (It's tell me I'm missing the file "wxmsw28d_core.lib" although I built it).

have a nice day,

Tmiron.

I guess it should work with 2.8.12. Try to compile their examples, and consult their documentation if it does not work. I cannot give support for a package I have not written.

/Stefan 

My problem is not with wxWidgets itself but with links your program is doing to the wxWidgets. if you can please tell me the wxWidget version you used, I'll use this one instead the version I'm using and I think it will solve the problem.

Tmiron.

I currently use version 2.9.4, but chances are high that it will work with 2.8.12.

/Stefan 

 but was version 2.9.4 the one you used when you built  Version 4.0.0 of the DRS4 oscilloscope program, or was it an erilar version, and if so, do you remeber what version it was?

tmiron.

I used 2.8.12 for Version 4.0.0.

/Stefan 

 Hi Stefan.

I managed to add the averaging possibility to the oscilloscope program, but it runs too slow, so now I'm tring to add this option to the example file you attached to the program (drs_exam.cpp).
My problem is that when I run the file is not passing  the stage of getting the trigger. (it just wait after writing the line "Waiting for trigger...")
When testing the software, I work with a signal of up to 10 MHz, limited in voltage to the DRS Eval 4 ability, and I connect the signal to channel 1,from it by default is supposed to get the trigger. I also tried to change the channel settings to other channels or external trigger, and use them,  but it still not working.

I found out that the problem is related to the line "while (b->IsBusy());" in the code, but I have a problem understanding what the function "IsBusy" do and how it's work.

Can you please explain me a bit what this function does?

have a nice day,

Tmiron

The function b->IsBusy() returns true if there has been no trigger. So "while (b->IsBusy());" is simply an endless loop until the board triggered. Please check your signals and trigger configuration. Maybe you have to adjust the trigger level or polarity via b->SetTriggerLevel(). Try signals with lower event rates. Verify that the board triggers with the DRSOsc program, you can then read off the optimal trigger level from there. 

/Stefan

Hi satefan,

I did some debug on the DRSOsc program and saw that everywhere you used the function "IsBusy()", you used it with "SoftTrigger()", which (to my understanding) create a software trigger. did you used another function, other than "ISBusy", that check the hardware trigger?

have a nice day,

Tmiron.

No. IsBusy() is the only way the hardware trigger is checked. If there is no hardware trigger, you can issue a "fake" trigger (called software trigger) to stop the acquisition. This happens for example if you switch DRSOsc to "Auto" trigger instead of "Normal" trigger, very similar than a normal oscilloscope does.

/Stefan 

 hallo stefan,

I managed to fixed the problem. The problem was with the number I inserted to the function "b->SetTriggerSource" th get external trigger (it suppose to be "16" and not "4" or "12" as I understood from the function's comments).

Right now I'm trying to speed up the number of wavefrom  per second. I'm using your  drs_exam.cpp program you wrote as my basic program. When you wrote it you used the function "b->StartDomino()" inside the loop, which means that before every trigger you gave him a command to start the domino-wave.

From  the "DRS4 datasheet" (page 8) I understand that I can bypass the need to restart the  domino-wave by using "b->SetDominoActive(1)" and "b->SetDominoMode(1)", but when I tried it didn't work (the waveform I got every readout remain the same which means the dominowave froze after the first readout).

Am I understanding wrong or do I need to add somthing more\else so the domino-wave will not stop after each readout? is there any hazard by doing that, as mentiond in page 8 of the the datasheet?

thanks again,

Tmiron.

The Domino wave anyhow is always active in mode 1, but you have to enable the writing to the memory cells (via the DENABLE signal). This is done with the b->StartDomino(). You are right that this call takes about 1ms over USB 2.0, so avoiding it would speed up the DAQ by about a factor of two. I have some plans to implement an automatic restart in firmware of the evaluation board, but I won't have time for that until fall of this year.

/Stefan

drs4b is now officially on these distributions:

https://repology.org/project/drs4eb/versions

enjoy

Hello! My name is Dmitry. I am from SiPM Lab is NRNU MEPhI (Russia, Moscow). We bought DRS4 evaluation board V5 with firmware 21305. We use 5.0.4 build 21911 2015-11-23 software version (and before that we used 5.0.3 build 21508, 2014-10-15) with Windows 7 32bit.

We observe some strange behaviour. When we save waveforms (in xml or binary data) we see that some of them have the baseline shifted of about -5 mV.

The first picture (pic1) is 1000 waveforms which were glued in one. It is clearly see that baseline quite often has the shift.

The same effect can be seen without saving (writting): rarely when we use normal or auto trigger mode (pic3), and always in single trigger mode (pic2).

The images are attached.

Do you have any idea how it can be fixed?

Thanks, Dmitry.

The baseline shift comes from some instable power supply inside the evaluation board which cannot be controlled to the mV level. In a real measurement, you usually get an additional baseline shift due to some environmental electromagnetic interferences, such as a 50 Hz signal. People fix this shifting baseline by always aquiring a small portion (10-20 samples) of the baseline before any signal from a particle detector. The signal is then corrected event-by-event by subtracting the baseline from each waveform. By doing that, you fix not only the 50 Hz noise, but also the shifting baseline you mention.

Stefan

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

> 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

> 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

 Hi,

Does anyone has a program that converts a binary file from drsosc  output to a ROOT tree format?

Thank you,

Dmitry.