DRS4 Forum
  DRS4 Discussion Forum, Page 37 of 42  Not logged in ELOG logo
ID Date Author Subjectup
  318   Fri Dec 13 11:37:58 2013 Stefan Rittinput protection in DRS4 evaluation board

Dmitry Hits wrote:

Last month I was using a DRS4 evaluation board to digitise the signal from the charged particles in piM1 beam line at PSI. The beam in piM1 is a mixture of pions with a small percentage of protons. Pions are close to minimum ionising and were producing the signals on the order of 250 mV (Landau distributed). The protons at this momentum (250 MeV) are not minimum ionising  and produced much higher signals ( I could not exactly measure them because they were of scale for the DRS4 board). The pulses were on the order of 0.5 usec long. At low rate (~1kHz) the board was able to handle them, but when I turned the rate of particles to about ~300 kHz, the channel went flat. My question is whether the evaluation board has some type of input protection that would be possible to replace? Or does that mean that I have burned the input of the DRS4 board itself? Other channels behaving normal.

As written in the manual, the board withstands +-20V pulses which are shorter then 2 usec, and a DC input of +-10V. If your pulses are bigger or longer, you will kill the input buffer chip, which needs to be re-soldered. You can check if the channel is broken by applying a periodic signal of known amplitude (e.g. a 100 mV 1 MHz sine wave). If the measured amplitude differs significantly from the others (like only half the amplitude) or is completely flat, you burned the input stage. When you are next time at PSI you can bring the board and we can then fix it.

/Stefan

  837   Thu Oct 14 15:19:00 2021 Keita Mizukoshilivetime (or deadtime) of DRS4 evaluation board

Dear experts,

 

I would like to use the DRS4 evaluation board for actual physics experiment.

I made a CUI script based on the drs_exam, https://github.com/mzks/drs4_tools/blob/main/build/source/drscmd.cpp.

In this framework, how can we obtain DAQ livetime (or deadtime)?

Has some function already provided to evaluate them from firmware?

 

Best regards,

Keita

  838   Thu Oct 14 15:25:07 2021 Stefan Rittlivetime (or deadtime) of DRS4 evaluation board

The one thing you can do easily is to look at the scaler values. If one channel counts all physical events, and you have all read out events, then the ratio give you the live/deadtime. The hardware scalers also keep running during the DRS readout.

Stefan

Keita Mizukoshi wrote:

Dear experts,

 

I would like to use the DRS4 evaluation board for actual physics experiment.

I made a CUI script based on the drs_exam, https://github.com/mzks/drs4_tools/blob/main/build/source/drscmd.cpp.

In this framework, how can we obtain DAQ livetime (or deadtime)?

Has some function already provided to evaluate them from firmware?

 

Best regards,

Keita

 

  839   Thu Oct 14 18:03:52 2021 Keita Mizukoshilivetime (or deadtime) of DRS4 evaluation board

Thank you very much for your response.
Excuse me for my very stupid confirmation.
If I take N events finally and the hardware scaler value is M, the livetime is realtime*(N/M). Is this correct?

Stefan Ritt wrote:

The one thing you can do easily is to look at the scaler values. If one channel counts all physical events, and you have all read out events, then the ratio give you the live/deadtime. The hardware scalers also keep running during the DRS readout.

Stefan

Keita Mizukoshi wrote:

Dear experts,

 

I would like to use the DRS4 evaluation board for actual physics experiment.

I made a CUI script based on the drs_exam, https://github.com/mzks/drs4_tools/blob/main/build/source/drscmd.cpp.

In this framework, how can we obtain DAQ livetime (or deadtime)?

Has some function already provided to evaluate them from firmware?

 

Best regards,

Keita

 

 

  840   Thu Oct 14 18:42:31 2021 Stefan Rittlivetime (or deadtime) of DRS4 evaluation board

I would say not exactly, but it's a good approximation.

Keita Mizukoshi wrote:

Thank you very much for your response.
Excuse me for my very stupid confirmation.
If I take N events finally and the hardware scaler value is M, the livetime is realtime*(N/M). Is this correct

  841   Fri Oct 15 06:15:53 2021 Keita Mizukoshilivetime (or deadtime) of DRS4 evaluation board

Thank you very much.

Stefan Ritt wrote:

I would say not exactly, but it's a good approximation.

Keita Mizukoshi wrote:

Thank you very much for your response.
Excuse me for my very stupid confirmation.
If I take N events finally and the hardware scaler value is M, the livetime is realtime*(N/M). Is this correct

 

  246   Tue May 21 12:39:00 2013 Enrico Contimac osx 10.6
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
  247   Tue May 21 13:25:41 2013 Stefan Rittmac osx 10.6
> 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
  248   Tue May 21 13:32:13 2013 Martin Petriskamac osx 10.6
> 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
  249   Tue May 21 17:45:05 2013 Enrico Contimac osx 10.6
> 
> 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.
  250   Tue May 21 17:48:45 2013 Enrico Contimac osx 10.6
> 
> 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
  251   Tue May 21 17:51:09 2013 Stefan Rittmac osx 10.6
> > 
> > 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
  252   Tue May 21 18:30:11 2013 Enrico Contimac osx 10.6
> > > 
> > > 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
  253   Fri May 24 17:58:07 2013 Enrico Contimac osx 10.6
> > > 
> > > 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!
  254   Fri May 24 18:20:14 2013 Stefan Rittmac osx 10.6
> 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
  255   Sat May 25 12:45:46 2013 Enrico Contimac osx 10.6
> > 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
  315   Tue Dec 10 14:48:42 2013 ismail okan atakisimeasurement range

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.  

  316   Tue Dec 10 14:54:46 2013 Stefan Rittmeasurement range

ismail okan atakisi wrote:

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

  737   Wed Feb 20 08:03:04 2019 Lev Pavlovmeg?

Hey. Strange problem. Why does the compiler refer there at all? Library installed drsosc works

 

LINK : fatal error LNK1104: cannot open file "C:\meg\online\drivers\drs\libusb-1.0\libusb-1.0.lib"

  738   Wed Feb 20 08:08:42 2019 Stefan Rittmeg?

You have to change the path to libusb-1.0.lib to the one where you installed it.

Stefan

Lev Pavlov wrote:

Hey. Strange problem. Why does the compiler refer there at all? Library installed drsosc works

 

LINK : fatal error LNK1104: cannot open file "C:\meg\online\drivers\drs\libusb-1.0\libusb-1.0.lib"

 

ELOG V3.1.4-80633ba