I m trying to measure lifetime in our lab and I intend to take
measurement with DRS4 at that point I have a little bit confused about
DRS4 time range.In My system I opened 10 us gate but after triggering
DRS4 measure nearly 1.2 us. Because of this I want to extend DRS4 time range that
measurement range from 1.2us to 10 us.  

Have a look at the Evaluation Board description at http://www.psi.ch/drs/evaluation-board. It says that you have 1024 sampling points per channel. So If you sample at 0.7 GSPS, this gives you a time range of 1/0.7 GHz * 1024 = 1.46 us.

Best regards,
Stefan

Dear Stefan

Is there an easy way to reduce sampling speed below 0.7 GSPS? I would like to record traces up to 5 usec long.

Thank you

Dmitry 

No. See the DRS4 datasheet: http://www.psi.ch/drs/DocumentationEN/DRS4_rev09.pdf 

Minimum sampling speed is 700 MSPS.

/Stefan

 Hello,  I want use cascading of channels for 2048 cell - SetChannelConfig(0,8,4), but i can't understand how . Please, help me. Where i can dowload 2048_mode.ppt. (I found information about this file in DRS.cpp  (3445 line  "/ combine two halfs correctly, see 2048_mode.ppt")

Best regards,

Schablo Kostya 

You have to combine two channels into one, and depending on where the domino wave stopped, things get a bit complicated. I attach 2048_mode.ppt for your reference, but am not sure if this will really help.

/Stefan 

Sorry for my question.

 I'm trying change "drs_exam.cpp" for read 2048 cell. 

I'm using SetChannnelConfig(0,8,4) and this code in "drs_exam.cpp" :

              ...

              float arrX[2048];

              float arrY[2048];

              ....

             b->GetTime(0, b->GetTriggerCell(0), arrX);

             b->GetWave(0, 0, arr.Y); 

             ....

Return 2048 values in arrX[2048] - correct values, but  in arrY[2048] -  not correct values.

   I can't understand what values return "GetWave" function. Please, say me how make, that GetWave function return correct values.  " not - correct values "(i mean that i give signal in drs bord and values not true.) 

Best regards,

Schablo Kostya 

The evaluation board V4 does not support cascading by default. You have to connect each input to two channels, which can in principle be made by soldering some zero Ohm resistors on the board, but these are tiny parts and not everybody can do it. Note that the 2048 cell mode is an option when ordering the board. So first make sure that you can modify the board before trying to run the software. 

 I installed Mac OS package on macbook (late 2013). DRSOsc starts to write file but freezes; need to be restarted to restore connection with DRS4 evaluation board (ordered Aug 2011). 

When I ran from the command line, I see these messages:

phone$ /Applications/DRSOsc.app/Contents/MacOS/DRSOsc

2013-11-18 15:11:31.278 DRSOsc[96539:507] CoreText performance note: Client called CTFontCreateWithName() using name "Lucida Grande" and got font with PostScript name "LucidaGrande". For best performance, only use PostScript names when calling this API.

2013-11-18 15:11:31.279 DRSOsc[96539:507] CoreText performance note: Set a breakpoint on CTFontLogSuboptimalRequest to debug.

2013-11-18 15:11:31.281 DRSOsc[96539:507] CoreText performance note: Client called CTFontCreateWithName() using name "Lucida Grande" and got font with PostScript name "LucidaGrande". For best performance, only use PostScript names when calling this API.

2013-11-18 15:11:31.283 DRSOsc[96539:507] CoreText performance note: Client called CTFontCreateWithName() using name "Lucida Grande" and got font with PostScript name "LucidaGrande". For best performance, only use PostScript names when calling this API.

2013-11-18 15:11:31.285 DRSOsc[96539:507] CoreText performance note: Client called CTFontCreateWithName() using name "Lucida Grande" and got font with PostScript name "LucidaGrande". For best performance, only use PostScript names when calling this API.

0 - 0.250

1 - 0.250

2 - 0.250

3 - 0.250

0 - 0.250

1 - 0.250

2 - 0.250

3 - 0.250

2013-11-18 15:11:32.933 DRSOsc[96539:507] CoreText performance note: Client called CTFontCreateWithName() using name "Lucida Grande" and got font with PostScript name "LucidaGrande". For best performance, only use PostScript names when calling this API.

...

...

and these:

musb_write: requested 10, wrote 0, errno -4 (Unknown error: -4)

musb_read error 0

musb_write: requested 10, wrote 0, errno -4 (Unknown error: -4)

musb_read error 0

...

...

I tried to compile Linux package, but got error messages:

drs-4.0.1$ make

cc -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -I/opt/local/include -DOS_DARWIN -DHAVE_USB -DHAVE_LIBUSB10 -DUSE_DRS_MUTEX -c src/musbstd.c

cc -g -O2 -Wall -Wuninitialized -fno-strict-aliasing -Iinclude -I/opt/local/include -DOS_DARWIN -DHAVE_USB -DHAVE_LIBUSB10 -DUSE_DRS_MUTEX -c src/mxml.c

In file included from src/mxml.c:79:

include/strlcpy.h:27:14: error: expected parameter declarator

size_t EXPRT strlcpy(char *dst, const char *src, size_t size);

             ^

/usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'

  __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))

                                           ^

/usr/include/secure/_common.h:39:62: note: expanded from macro '__darwin_obsz'

#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)

                                                             ^

/usr/include/secure/_common.h:30:32: note: expanded from macro '_USE_FORTIFY_LEVEL'

#    define _USE_FORTIFY_LEVEL 2

                               ^

In file included from src/mxml.c:79:

include/strlcpy.h:27:14: error: expected ')'

/usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'

  __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))

                                           ^

/usr/include/secure/_common.h:39:62: note: expanded from macro '__darwin_obsz'

#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)

                                                             ^

/usr/include/secure/_common.h:30:32: note: expanded from macro '_USE_FORTIFY_LEVEL'

#    define _USE_FORTIFY_LEVEL 2

                               ^

include/strlcpy.h:27:14: note: to match this '('

/usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'

  __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))

                                           ^

/usr/include/secure/_common.h:39:53: note: expanded from macro '__darwin_obsz'

#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)

                                                    ^

In file included from src/mxml.c:79:

include/strlcpy.h:27:14: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]

size_t EXPRT strlcpy(char *dst, const char *src, size_t size);

             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

/usr/include/secure/_string.h:105:44: note: expanded from macro 'strlcpy'

  __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))

                                           ^~~~~~~~~~~~~~~~~~~~

/usr/include/secure/_common.h:39:31: note: expanded from macro '__darwin_obsz'

#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)

                              ^~~~~~~~~~~~~~~~~~~~~

In file included from src/mxml.c:79:

include/strlcpy.h:27:14: error: conflicting types for '__builtin___strlcpy_chk'

/usr/include/secure/_string.h:105:3: note: expanded from macro 'strlcpy'

  __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))

  ^

include/strlcpy.h:27:14: note: '__builtin___strlcpy_chk' is a builtin with type 'unsigned long (char *, const char *, unsigned long, unsigned long)'

/usr/include/secure/_string.h:105:3: note: expanded from macro 'strlcpy'

  __builtin___strlcpy_chk (dest, src, len, __darwin_obsz (dest))

  ^

In file included from src/mxml.c:79:

include/strlcpy.h:28:14: error: expected parameter declarator

size_t EXPRT strlcat(char *dst, const char *src, size_t size);

             ^

/usr/include/secure/_string.h:111:44: note: expanded from macro 'strlcat'

  __builtin___strlcat_chk (dest, src, len, __darwin_obsz (dest))

                                           ^

/usr/include/secure/_common.h:39:62: note: expanded from macro '__darwin_obsz'

#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)

                                                             ^

/usr/include/secure/_common.h:30:32: note: expanded from macro '_USE_FORTIFY_LEVEL'

#    define _USE_FORTIFY_LEVEL 2

                               ^

In file included from src/mxml.c:79:

include/strlcpy.h:28:14: error: expected ')'

/usr/include/secure/_string.h:111:44: note: expanded from macro 'strlcat'

  __builtin___strlcat_chk (dest, src, len, __darwin_obsz (dest))

                                           ^

/usr/include/secure/_common.h:39:62: note: expanded from macro '__darwin_obsz'

#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)

                                                             ^

/usr/include/secure/_common.h:30:32: note: expanded from macro '_USE_FORTIFY_LEVEL'

#    define _USE_FORTIFY_LEVEL 2

                               ^

include/strlcpy.h:28:14: note: to match this '('

/usr/include/secure/_string.h:111:44: note: expanded from macro 'strlcat'

  __builtin___strlcat_chk (dest, src, len, __darwin_obsz (dest))

                                           ^

/usr/include/secure/_common.h:39:53: note: expanded from macro '__darwin_obsz'

#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)

                                                    ^

In file included from src/mxml.c:79:

include/strlcpy.h:28:14: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]

size_t EXPRT strlcat(char *dst, const char *src, size_t size);

             ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

/usr/include/secure/_string.h:111:44: note: expanded from macro 'strlcat'

  __builtin___strlcat_chk (dest, src, len, __darwin_obsz (dest))

                                           ^~~~~~~~~~~~~~~~~~~~

/usr/include/secure/_common.h:39:31: note: expanded from macro '__darwin_obsz'

#define __darwin_obsz(object) __builtin_object_size (object, _USE_FORTIFY_LEVEL > 1 ? 1 : 0)

                              ^~~~~~~~~~~~~~~~~~~~~

In file included from src/mxml.c:79:

include/strlcpy.h:28:14: error: conflicting types for '__builtin___strlcat_chk'

/usr/include/secure/_string.h:111:3: note: expanded from macro 'strlcat'

  __builtin___strlcat_chk (dest, src, len, __darwin_obsz (dest))

  ^

include/strlcpy.h:28:14: note: '__builtin___strlcat_chk' is a builtin with type 'unsigned long (char *, const char *, unsigned long, unsigned long)'

/usr/include/secure/_string.h:111:3: note: expanded from macro 'strlcat'

  __builtin___strlcat_chk (dest, src, len, __darwin_obsz (dest))

  ^

2 warnings and 6 errors generated.

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

What the best way to build DRSOsc on the Mac OS X?

Thanks,

Andriy.

DRSOsc seems broken on OSX 10.9. I'm working on this right now. Some of the problems are related to wxWidgets, so I'm waiting for a new version running stably under OSX 10.9. The compilation problem related to "strlcpy" comes from the fact that OSX 10.9 now comes with its own version of that function, while all previous versions did not. So simply removing strlcpy.h/c from the project fixes that.

There will be a new version of DRSOsc next month which fixes all this problems, so just stay tuned.

/Stefan 

 I will have beam test next week :-(

I installed wxWidgets-3.0 using MacPorts (and libusb too). After removing strlcpy and hacking of Makefile I managed to build MacOS application. 

When I launch DRSOsc.app/Contents/MacOS/DRSOsc from terminal, I see constantly pouring messages about fonts:

2013-11-19 12:21:22.232 DRSOsc[99520:507] CoreText performance note: Client called CTFontCreateWithName() using name "Lucida Grande" and got font with PostScript name "LucidaGrande". For best performance, only use PostScript names when calling this API.

2013-11-19 12:21:22.275 DRSOsc[99520:507] CoreText performance note: Client called CTFontCreateWithName() using name "Lucida Grande" and got font with PostScript name "LucidaGrande". For best performance, only use PostScript names when calling this API.

...

How may I get rid of them?

Another problem: I was not able to save data in binary (*.dat) file. I used DRSOsc settings to set binary format, I specified explicit extension *.dat, tried everything (including hiding extension), but was not able to save in binary format. Do I need to apply some trick? How may I hardcode usage of the binary format?

Thanks,

Andriy.

The CoreText issue comes from WxWidgets or a combination with OSX 10.9. Many other people have the same problem:

https://bugzilla.mozilla.org/show_bug.cgi?id=934261

and I have no idea how to get rid of it.

Concerning your problem with the binary format, just have a look at elog:272

Hi,

I have install drs software on ASUS EeeBox with Ubuntu 12.04 LTS. When I try to use ./drsosc the oscilloscope window flickers. Can you suggest what might be the problem?

Here is some more info:

******************************************************

System:

Ubuntu 12.04 LTS

Memory: 992.9 MiB

CPU: Intel Atom CPU N270 @ 1.6GHz x 2

32 Bit

Disc: 156.5 GB

***************************************

Software:

Due to version Ubuntu I had to install the wxWidgets from source (wxWidgets with x11)

Thank you,

Dmitry.

This problem is new. Even on a slower Raspberry Pi we did not see any flickering. Have you tried a different version of wxWidgets? 

yes the problem was in wxWidgets, I have downgraded the ubuntu version and installed packaged version of wxWidgets. Now it works without problems.

Thank you,

Dmitry. 

  Hello everyone！I'm a new user of DRS4 board,but it seems that some files are missing in my demo project.So I hope someone could help me by sending a correct VHDL hardware project to my Email:lcyiss900@gmail.com.Thanks in advance!

T

 I checked my project today and I think I need the file USR_LIB_VEC_IOFD_CPE_NALL.I don't know if is it a VHD files or a IP core.

I'll be extremely grateful.

 USR_LIB_VEC_IOFD_CPE_NALL is defined in firmware/srs/usr_lib.vhd which is part of the software package.

Hi,

I wish to interface the DRS4 with the 8-channel ADC AD9222 (or AD9637).

I'm reading from the DRS4 datasheet that "the analog output of the DRS4 chip has been designed to match directly the input of the AD9222". OUT+ output of DRS4 is in the range from 0.8V to 1.8V and OUT- output is shifted by the voltage applied to the O-OFS pin.

The span of the AD9222 ADC core is defined by REFT and REFB which are resp. 1.4V and 0.4V in a typical case (AVDD=1.8V, VREF=1V). My understanding is that the ADC analog inputs must be within the voltage range defined by REFT and REFB and so I don't quite see how this matches the DRS4 outputs.

Can we use the full-scale range indeed? Do we have to use AC-coupling with mid-supply bias? What is the point I missed?

Thank you for your help.

Is it possible to set sampling frequency at 100 MHz in DRS4 eval board? Trying to set 0.1GHz in Osci program results in around 0.7 GHz. In drscl.exe i'm able to set freq at 0.1GHz but calibration is impossible.

Thank For Help!

Andrzej Rychter

700 MHz is the minimal sampling frequency. If you need 100 MHz, just buy a "normal" commercial ADC.

Best regards,

Stefan 

 OK!

Thanks for fast reply.

Andrzej

Hallo,
I'm using DRS4 Evaluation Board Rev 4.0 and I'm trying to change the output of the samples to be an average of  #  measurements (1000 or even more)
during the process I have encountered some difficulties I hope you will be able to help me  with:

1. the DRS chip have 8 channels but the Evaluation board have only 4 channels. does the default mode of the DRS in the Evaluation Board is 1024 bins for each channel or 2048?

2. in the readout mode, does it samples all the 1024 bins waveform from a channel and then move to the next one, or after each bin it move to the next channel?

3. In the file "drs4_eval4_app.vhd", I have a problem finding the names of the signals that represents the registers bits which tell me what is the number of the bin (1-1024) the ADC is reading from the DRS, and the signals

that represents registers A0-A3. can you send me their names? 

4. In another matter- is the -0.5V to 0.5V is the  upper and lower  limit of the input (or just a working range), and if not what is the limit for AC?  is there a fuse on the board in case of overload from the input? (I didn't see  it in the User's Manual, but I didn't know if you will mention it there in case there is one).

thanks in advance and have a nice day,

Tmiron

1. All 8 channels are read out, but only 4 are displayed in the oscilloscope.

2. It reads all 1024 bins from a channel, then switch to the next channel.

3. The ADC readout happens in lines 1576+. The register for the sample count is drs_sample_count, and the signal for the address is drs_addr.

4. The evaluation board manual explicitly mentions the maximum allowed input range on page 5.

/Stefan 

Thank you for the answer.

Have a nice week,

Tmiron.

 Hi Stefan,

I'm trying to add the averaging feature to the oscilloscope instead. I have a basic knowledge in C++ so I'm having problem finding the initial place (places) of the data acquisition. furthermore, I saw you already made an averaging possibility for some of the features in the program at the measure window.
Can you please tell we in which of the programs of the Scope (and in what line if possible) can I find the initial\main data acquisition so I could follow it from there, and where is the location of the averaging function you already made?

have a nice week,

Tmiron

The averaging possibility in the measure window is just a "place holder" for future extensions, which are not yet implemented.

A good point to implement averaging is in the function Osci::ReadWaveforms() in Osci.cpp.

/Stefan 

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

Working with the DRS evaluation board we noticed some funny behavior: See attatchment 1. In about 1% of scope traces we see the first and last bin take on a value substantially different from the baseline, note the small spikes on the end of the traces. These spikes occur across all channels and either appear in all channels or in none. Attachment two shows what several thousand scope traces look like. You can clearly see that some of the traces are offset from the normal base line. Has anyone observed this behavior before? Any ideas?

see https://muon.npl.washington.edu/elog/g2/Detectors/550 for full discussion. 

Actually the first and last sample are even more off the baseline, so I cut them out in software in the DRSOscilloscope. So actually the chip has only 1022 "usable" cells. It might happen in some rare cases that more cells are affected, although I have not yet seen this (maybe I did not look close enough). So I propose that you cut out one more bin at the beginning and the end, so a total of 1020 cells, and you should be fine.

/Stefan 

 Thanks for the quick reply. Our quick fix was to do just that. 

 We've encountered similar issues with board v2.0. Cell #2 across all channels would occasionally go full negative amplitude (0 I guess).

I don't remember if calibration fixed the problem, might have.

Hi,

I would like to save the waveform in a binary format. When I click Save then change format from xml to dat in the menu. I still get xml format but with dat extension.

what I am missing?

Thank you,

Dmitry.

Version 4.0.1 has a problem there. Please use 4.0.0. If you can compile the program yourself, just change this line:

--- DOFrame.cpp (revision 20656)
+++ DOFrame.cpp (revision 20655)
@@ -517,7 +517,7 @@
       if (!filename.empty()) {
          m_btSave->SetLabel(_T("Close"));
          m_btSave->SetToolTip(_T("Stop saving waveforms"));
-         if (filename.Find(_T(".")) != wxNOT_FOUND) {
+         if (filename.Find(_T(".xml")) != wxNOT_FOUND) {
             m_WFfd = 0;
             m_WFFile = mxml_open_file(filename.char_str());
             if (m_WFFile)

 Thanks that fixed it!

Dmitry

Hi,

while trying to create python bindings for the DRS stuff using SWIG 2.0.4, two undefined methods prevent the python interpreter from loading the generated shared library. These methods are:

• int DRSBoard::SetADCActive(unsigned char)
• bool ResponseCalibration::Calibrate(unsigned int,unsigned int,float *,float *,float,bool)

Can we safely removed those methods from the DRS header files or (what I have actually done) is it better to fake some empty implementation in the input file to SWIG?

Another minor issue is that the python interpreter always terminates with a SegFault after script termination. I had not yet time to track that down...

Thanks & regards

Hermann-Josef

Thanks for pointing that out. My C++ compiler does not complain about such errors. You can safely remove these functions. I did so as well, so future versions will not contain that any more.

/Stefan 

Hello Sir,

Regarding to analog pulse counting by using DRS4 Rev.2.0 board, you have said that "There is a way to perform the counting dead time free, but that requires the V4 board, which has a hardware comparator on all four channels (The V2 board has only one comparator and a multiplexer). The output of these comparators go directly to the FPGA, which can then trigger on these signals. In principle one could implement a hardware counter in the FPGA, which works practically dead time free. But this requires a new firmware which has to be written. Either you do it yourself using the Xilinx development tools, or you wait until I find some time to implement this, which could take a couple of weeks or even months."

I am interested in it. I have DRS4 Rev.2.0 board. I have FPGA and Microcontroller firmware for this board. How can I implement this concept of counting pulses?

As I said above, you need a V4 board which has the four hardware comparators mounted. You cannot do that with the V2 board, even with a firmware upgrade.

The firmware upgrade for the V4 board is not yet ready and I won't have time for that in the next 3-4 weeks, but afterwards maybe.

Best regards,

Stefan 

 Thank you for your response.

The DRS4 Rev.2.0 with one Multiplexer and a Comparator I think may be is ok for me. Since I wanted to implement counter in FPGA, I have gone through firmware but its very difficult for me to get the flow of data from DRS to USB. Could you help me to get familiar with or to get flow of the data from DRS to the USB?

Thank You,

Sonal

Hi Sonai,

unfortunately I cannot teach you VHDL, you should take a course somewhere. Actually you don't have to touch the USB part, you just have to implement a new register in the firmware, and connect it to a VHDL counter attached to the trigger input. I will do this in a couple of weeks myself, so you can also just wait. I will however only do this for the V4 board, so you have to port it back to the V2 firmware.

Best regards,

Stefan

Hello, Stefan. Have you implemented pulse counting yet?

Best, Osip.

Nope. 

 Will it be done in the foreseeable future?

Yes. I will announce it in the forum. 

Hi,

I would like to use the DRS4 with my macbook pro running osx 10.6.8.
I have installed the wxWidgets and the libusb-1.0 libraries and I am using the Linux code vers. 4.0.1. After
compilation, the following errors come out:

ld: warning: in musbstd.o, file was built for unsupported file format which is not the architecture being linked
(i386)
ld: warning: in mxml.o, file was built for unsupported file format which is not the architecture being linked (i386)
....
....
ld: warning: in main.o, file was built for unsupported file format which is not the architecture being linked (i386)
Undefined symbols:
  "_main", referenced from:
      start in crt1.10.6.o
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [drsosc] Error 1


Do you have any idea on how to solve the problem ?? or maybe do you have a package working with osx 10.6 ? I
remember to have seen, long time ago, a package that could work with 10.6 (or 10.5 ?), but I cannot find it now
(but maybe I remember wrong).

Thanks for any help,

Enrico

> Hi,
> 
> I would like to use the DRS4 with my macbook pro running osx 10.6.8.
> I have installed the wxWidgets and the libusb-1.0 libraries and I am using the Linux code vers. 4.0.1. After
> compilation, the following errors come out:
> 
> ld: warning: in musbstd.o, file was built for unsupported file format which is not the architecture being linked
> (i386)
> ld: warning: in mxml.o, file was built for unsupported file format which is not the architecture being linked (i386)
> ....
> ....
> ld: warning: in main.o, file was built for unsupported file format which is not the architecture being linked (i386)
> Undefined symbols:
>   "_main", referenced from:
>       start in crt1.10.6.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make: *** [drsosc] Error 1
> 
> 
> Do you have any idea on how to solve the problem ?? or maybe do you have a package working with osx 10.6 ? I
> remember to have seen, long time ago, a package that could work with 10.6 (or 10.5 ?), but I cannot find it now
> (but maybe I remember wrong).
> 
> Thanks for any help,
> 
> Enrico

Can it be that you have a old PowerPC MAC? I have no experience with that, but probably you have to adjust the Makefile
ans set some flags correctly for PPC instead of Intel.

/Stefan

> 
> Can it be that you have a old PowerPC MAC? I have no experience with that, but probably you have to adjust the Makefile
> ans set some flags correctly for PPC instead of Intel.
> 
> /Stefan


No, I have a MacBook Pro 2.8 GHz Intel Core 2 Duo.

> Hi,
> 
> I would like to use the DRS4 with my macbook pro running osx 10.6.8.
> I have installed the wxWidgets and the libusb-1.0 libraries and I am using the Linux code vers. 4.0.1. After
> compilation, the following errors come out:
> 
> ld: warning: in musbstd.o, file was built for unsupported file format which is not the architecture being linked
> (i386)
> ld: warning: in mxml.o, file was built for unsupported file format which is not the architecture being linked (i386)
> ....
> ....
> ld: warning: in main.o, file was built for unsupported file format which is not the architecture being linked (i386)
> Undefined symbols:
>   "_main", referenced from:
>       start in crt1.10.6.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make: *** [drsosc] Error 1
> 
> 
> Do you have any idea on how to solve the problem ?? or maybe do you have a package working with osx 10.6 ? I
> remember to have seen, long time ago, a package that could work with 10.6 (or 10.5 ?), but I cannot find it now
> (but maybe I remember wrong).
> 
> Thanks for any help,
> 
> Enrico

it looks like 64bit vs 32bit problem, you have to compile all libraries for the same architecture. Maybe, make clean to 
remove all precompiled object files .o and recompile it again. Try to compile first that simple example without wxWidgets.

Martin

> 
> it looks like 64bit vs 32bit problem, you have to compile all libraries for the same architecture. Maybe, make clean to 
> remove all precompiled object files .o and recompile it again. Try to compile first that simple example without wxWidgets.
> 
> Martin


Good point, but all libraries are already compiled to 32 bits, since the laptop is running at 32 bits. Unless you mean that I
have to convert to 64 bits, but this means to change all content of the PC, and I don't want to do this. Can the applications
run with 32 bits or do they need 64 ? 

Thanks,
Enrico

> > 
> > it looks like 64bit vs 32bit problem, you have to compile all libraries for the same architecture. Maybe, make clean to 
> > remove all precompiled object files .o and recompile it again. Try to compile first that simple example without wxWidgets.
> > 
> > Martin
> 
> 
> Good point, but all libraries are already compiled to 32 bits, since the laptop is running at 32 bits. Unless you mean that I
> have to convert to 64 bits, but this means to change all content of the PC, and I don't want to do this. Can the applications
> run with 32 bits or do they need 64 ? 
> 
> Thanks,
> Enrico

There is no specific reason to run it on 64 bits, so just all libraries have to match, that's all. But the original Makefile has been written for 64 bits, so it might need some 
adjustments.

/Stefan

> > > 
> > > it looks like 64bit vs 32bit problem, you have to compile all libraries for the same architecture. Maybe, make clean to 
> > > remove all precompiled object files .o and recompile it again. Try to compile first that simple example without wxWidgets.
> > > 
> > > Martin
> > 
> > 
> > Good point, but all libraries are already compiled to 32 bits, since the laptop is running at 32 bits. Unless you mean that I
> > have to convert to 64 bits, but this means to change all content of the PC, and I don't want to do this. Can the applications
> > run with 32 bits or do they need 64 ? 
> > 
> > Thanks,
> > Enrico
> 


> There is no specific reason to run it on 64 bits, 

Good.

> so just all libraries have to match, that's all. But the original Makefile has been written for 64 bits, so it might need some 
> adjustments.

Ok, but I don't understand where is the point to correct. 64 bits do not appear explicitally (at least to me, who am not a drake of programming ...) 
neither in the Makefile neither in the (few) source files I have examined.

Thanks again,
Enrico

> > > 
> > > it looks like 64bit vs 32bit problem, you have to compile all libraries for the same architecture. Maybe, make clean to 
> > > remove all precompiled object files .o and recompile it again. Try to compile first that simple example without wxWidgets.
> > > 
> > > Martin
> > 
> > 
> > Good point, but all libraries are already compiled to 32 bits, since the laptop is running at 32 bits. Unless you mean that I
> > have to convert to 64 bits, but this means to change all content of the PC, and I don't want to do this. Can the applications
> > run with 32 bits or do they need 64 ? 
> > 
> > Thanks,
> > Enrico
> 
> There is no specific reason to run it on 64 bits, so just all libraries have to match, that's all. But the original Makefile has been written for 64 bits, so it might need some 
> adjustments.
> 
> /Stefan

Hi Stefan,
   I made some progress. Understood what was wrong in the make phase. You have only to add the option -arch i386 in the CFLAGS line of the makefile.
Then the make is ok, it produces the 3 executables. drs_exam and drscl seem to work correctly. 
DRSOsc.app does not work as app, in the sense that if you click it, an error message comes saying "You can't use this version of the application DRSOsc.app with 
this version of Mac OS X. You have Mac OSX 10.6.8. The application requires Mac OS X 10.7 or later. "
If you execute drsosc from the terminal, the graphical window pops up, the waveform is displayed, but you don't have access to the graphical interface, no button works, you can't do
anything. To quit the app, you have to kill it from the terminal with the kill command.
But anyway is a progress with respect to yestarday.
Any idea/suggestion to overcome the above problems ? I thought it is a problem with the graphical library (xwWidgets) but I have checked it, it's ok, I have also reinstalled it
(release 2.8.12_3) but nothing changed.

PS. the chip test output (done with the drscl ) is the following (see below). Is it normal or what ? THANKS.

B0> ct
Press 'q' to quit, any other key to repeat test.

Max. frequency is 5.1 GHz
Cell error on channel 1, cell 5: -137.6 mV instead 0 mV
Chip Error!

Max. frequency is 5.1 GHz
Cell error on channel 1, cell 5: -129.4 mV instead 0 mV
Chip Error!

> I made some progress. Understood what was wrong in the make phase. You have only to add the option -arch i386 in the CFLAGS line of the makefile.
> Then the make is ok, it produces the 3 executables. drs_exam and drscl seem to work correctly. 
> DRSOsc.app does not work as app, in the sense that if you click it, an error message comes saying "You can't use this version of the application DRSOsc.app with 
> this version of Mac OS X. You have Mac OSX 10.6.8. The application requires Mac OS X 10.7 or later. "
> If you execute drsosc from the terminal, the graphical window pops up, the waveform is displayed, but you don't have access to the graphical interface, no button works, you can't do
> anything. To quit the app, you have to kill it from the terminal with the kill command.

To run an executable as an app, you have to put it into a certain directory structure. The Makefile has the target "make app" which exactly does that. It executes following code:

DRSOsc.app: drsosc
        -mkdir DRSOsc.app
        -mkdir DRSOsc.app/Contents
        -mkdir DRSOsc.app/Contents/MacOS
        -mkdir DRSOsc.app/Contents/Resources
        -mkdir DRSOsc.app/Contents/Resources/English.lproj
        echo 'APPL????' > DRSOsc.app/Contents/PkgInfo
        cp drsosc.xcodeproj/Info-processed.plist DRSOsc.app/Contents/Info.plist
        cp drsosc DRSOsc.app/Contents/MacOS/DRSOsc
        cp drsosc.xcodeproj/DRSOsc.icns DRSOsc.app/Contents/Resources

You can also do this manually. You will then see the subdirectly DRSOsc.app actually as an App icon (you don't see it as a subdirectory in the Finder).  That's the way Apple has chosen to do this.

The chip test facility has been made for a certain test board we use for chip testing. It has a feature that is not present in the evaluation board. I have to disable that command there.

Best regards,
Stefan

> > I made some progress. Understood what was wrong in the make phase. You have only to add the option -arch i386 in the CFLAGS line of the makefile.
> > Then the make is ok, it produces the 3 executables. drs_exam and drscl seem to work correctly. 
> > DRSOsc.app does not work as app, in the sense that if you click it, an error message comes saying "You can't use this version of the application DRSOsc.app with 
> > this version of Mac OS X. You have Mac OSX 10.6.8. The application requires Mac OS X 10.7 or later. "
> > If you execute drsosc from the terminal, the graphical window pops up, the waveform is displayed, but you don't have access to the graphical interface, no button works, you can't do
> > anything. To quit the app, you have to kill it from the terminal with the kill command.
> 
> To run an executable as an app, you have to put it into a certain directory structure. The Makefile has the target "make app" which exactly does that. It executes following code:
> 
> DRSOsc.app: drsosc
>         -mkdir DRSOsc.app
>         -mkdir DRSOsc.app/Contents
>         -mkdir DRSOsc.app/Contents/MacOS
>         -mkdir DRSOsc.app/Contents/Resources
>         -mkdir DRSOsc.app/Contents/Resources/English.lproj
>         echo 'APPL????' > DRSOsc.app/Contents/PkgInfo
>         cp drsosc.xcodeproj/Info-processed.plist DRSOsc.app/Contents/Info.plist
>         cp drsosc DRSOsc.app/Contents/MacOS/DRSOsc
>         cp drsosc.xcodeproj/DRSOsc.icns DRSOsc.app/Contents/Resources
> 
> You can also do this manually. You will then see the subdirectly DRSOsc.app actually as an App icon (you don't see it as a subdirectory in the Finder).  That's the way Apple has chosen to do this.
> 
> The chip test facility has been made for a certain test board we use for chip testing. It has a feature that is not present in the evaluation board. I have to disable that command there.
> 
> Best regards,
> Stefan

Hi Stefan,
yes, the makefile has already the recipe to create the app. For OSX 10.6 a obvious modification must be done in the info.plist file. Then everything goes right. Now I have the DRSOsc application
running on my mac with 10.6.
Thanks for the help.
Best regards,
Enrico

Hello!
let me apologize in advance if this has already been covered somewhere and I missed it. 

I have a question about a statement made regarding the ADC clock in the evaluation board v4.0 manual.  At the bottom or page 23 there is a mention of jitter between the SRCLK signal and the ADC clock causing a baseline variation in the sampled output of up to a few mV.  Is there any more information out there about this?  I find this confusing for the following reason: If the DRS output has mostly settled after 28ns and the signal that is being sampled is a DC signal, I don't understand why an aperture jitter in the sampling ADC should cause a voltage error in the measured signal.  I already know about the possibility of noise spikes every 32 samples if these clocks are not properly aligned, though I don't know the origin of those spikes.  are these two things related?

Many Thanks!
 

Hi Benjamin,

In principle you are right, for a DC signal that should not matter. But in reality the DRS4 output signal is not constant even for a DC signal. When you switch from one sampling cell to another during readout, there is something called "charge injection". This causes the output to change up to several 10 mV. After 28 ns this is mostly settled, but not completely, since the DRS4 output driver has a relatively low bandwidth (~50 MHz). Furthermore, the signal line between the DRS4 and the ADC is not terminated, so you have some reflections going forth and back. In addition, you have some crosstalk from the SRCLK signal. So it's better that you sample on each cycle at exactly the same time. Here you see a plot of that (green: DRS4 output, blue: ADC clock, yellow SRCLK):

Hi Stefan,

Is either some example code or a detailed written description available for the improved DRS4 timing-calibration algorithm described by Daniel Stricker-Shaver at MIC 2012?  I think you told me that you had verified the results with your own test set-up, so I figure there must be at least two sets of code in existence to implement this calibration.  (I have Daniel's presentation slides.)

I managed to find a ping-pong distribution of cell widths that looks quite similar to that shown in Daniel's slides, using an algorithm similar to the technique one uses to find radial offsets in a tracking chamber (i.e. using residuals weighted by track slope), but I'd rather use the method with which you and Daniel have already found good results.  (The attached graph shows in black the histogram of cell widths for essentially the algorithm used in DRS.cpp/DRSBoard::AnalyzeWF, and in blue the histogram of cell widths extracted from the slope-weighted residuals for a periodic reference signal.)

By the way, since Daniel finds a FWHM coincidence-timing resolution around 20-25ps at 5 GSPS (for perfectly identical pulses), should I expect a FWHM resolution (for synthesized, ideal pulses) of around 50-65ps at 2 GSPS?

(I'm posting here instead of writing you both privately because I figure there may be broader interest in Daniel's algorithm.)

-Bill

Hi Bill,

there are several reasons why we have not yet published Daniel's method (I'm in constant contact with him).

1. The method still changes, becomes simpler and more accurate. Originally he used sine waves with varying frequency, which you only get from an external function oscillator. Currently, we found that a single frequency could do a similar, maybe even better job. The current result is much better than the 20-25ps quoted at MIC 2012.

2. Daniel found out that for the ultimate resolution you have to calibrate each channel inside a chip separately. I do understand in meantime the reason for that. So I plan for a V5 evaluation board, which contains means of sending a log-jitter clock to all channels. This board is in test phase and will be made available once it's working as expected.

So my plan is to finish the V5 board and implement the best possible timing calibration on it. Daniel achieved already <5 ps RMS (!) independent of the delay between the two optimal pulses (up to 50 ns). This is actually better than what you can do with a high-end oscilloscope, since scopes have internal interleaving and similar problems due to aliasing etc. than the DRS chip, but scope manufacturers do not put such an emphasis on accurate timing measurements. Once we can reproduce the 5 ps result with the evaluation board, we will publish it. When we found the optimal method, we plan to write a paper about it and explain everything in great detail. We will also be at Seoul for MIC 2013. I'm topic convener there for the session "Digitalization, Acquisition, and Signal Processing Technologies". So probably we will put the DRS4 timing talk there, since it's of more general interest not only to medical applications (and honestly, for a 150 ps TOF-PET you do not need a 5 ps electronics resolution). So stay tuned!

/Stefan

 Hi,

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

Thank you,

Dmitry.

I have noticed some differences in the source code between Windows (4.0.0) and Linux (4.0.1) Version.

drs_exam.cpp: In the windows version when setting the trigger there is no part "if (b->GetBoardType() == 8) {...} else {...}" like in Linux version. So under Windows drs_exam does not start readout of DRS 4 Evalutation Board V4, because it does not get the trigger, under linux the board can be read out succesfull. I have found out, that adding the missing part solves the problem for the windows version.

drs.cpp (Windows Version), line 2101, function "int DRSBoard::SetTriggerDelayNs(int delay)":

There is no operation which  calculates the variable "fTriggerDelayNs" out of variable "ticks" like in function "int DRSBoard::SetTriggerDelayPercent(int delay)" (Line 2073). So "fTriggerDelayNs" can get diverse values when using one of the Trigger Setting Functions. Was this intended?

Thanks for reporting the problem in drs_exam.cpp. The windows and linux versions sometimes differ a bit. I'm working right now on a complete new version, wich will bring both together again.

Concerning fTriggerDelayNs and ticks, they are correlated. One tick is a single delay unit in the FPGA. On the newest boards the unit is 4.8ns long. So

ticks = fTriggerDelayNs / 4.8

fTriggerDelayNs = ticks * 4.8

fTriggerDelayNs gets set at the first line of SetTriggerDelayNs:

int DRSBoard::SetTriggerDelayNs(int delay)
/* set trigger delay in nanoseconds */
{
   short ticks, reg;
   fTriggerDelayNs = delay;

So I cannot see how fTriggerDelayNS should get diverse values?

When starting Chip Test in DRS Command Line Interface, I receive the following message:

Cell error on channel 1, cell 5: -154.4 mV instead 0 mV

Chip Error!

What does this mean? The maximal peak-to-peak Amplitude given to channel was for a short time 10V.

The graphical interface shows no artefacts when using channel 1.

The "Chip Test" command is made for a special test board we use for chip testing. This command will not work with the evaluation board, since only four of the 8 DRS channels are connected there. So just ignore it and verify the board functionality by looking at the graphical interface.

/Stefan 

Hi,
I am considering using the DRS4 evaluation board as an ADC card for the wire chamber in the physics lab (VP) experiment at ETH. However, the wire 
chamber has 8 outputs, so I would need to have two of such boards. Is it possible to synchronise them, online or offline? From the website, it looks 
like yes, but the documentation says that these features (trigger and clock out) may not have been implemented in firmware yet. Could you tell me 
the status?

Thank you very much,

Dmitry.

> Hi,
> I am considering using the DRS4 evaluation board as an ADC card for the wire chamber in the physics lab (VP) experiment at ETH. However, the wire 
> chamber has 8 outputs, so I would need to have two of such boards. Is it possible to synchronise them, online or offline? From the website, it looks 
> like yes, but the documentation says that these features (trigger and clock out) may not have been implemented in firmware yet. Could you tell me 
> the status?
> 
> Thank you very much,
> 
> Dmitry.

I'm right now working on it. If you only need 2-3 ns accuracy  between the two boards then you can do this already now without firmware upgrade. The software for this is in principle ready, but I have to 
finish the documentation. Since I'm on a business travel right now this might take me some time (weeks?). 

If you want better timing (O(100ps)) between the boards, then you will need a firmware update. Or you wait until we ship boards with the new firmware. I will announce this through this forum.

Stefan