> 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

> 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

> 
> 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.

> 
> 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

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

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

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?

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

Thank you very much.

 Dear Stefan

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.

Thank you

Dmitry. 

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

Hello,

I have a question about using the write config register to enable/disable sampling on the fly.  I am looking to instrument an experiment at EPFL where multiple short events need to be captured during a 20us period followed by an 80us quiet period during which we could read out the chip.  Would it be possible to start an acquisition with all channels seeing the same signal and the write config register set to 111111111 and then shift a zero into the write config reg after each event is detected to freeze the channels in time one-by-one?  In this way we could measure up to 8 different events during the active period and then read them all out together during the quiet period.  I have read the posts about the simultaneous read-write mode and the issue with waveforms stopping at cell 767.  not knowing the exact details of what causes this issue I wonder if it would effect this sort of operation?  Also, I would like to know if dwrite must be de-asserted while the write config register is being updated or if it could be done while the sampling is active?  The latter would obviously be preferable as we would not incur any dead-time during the active period.

Thanks in advance for the information,

Benjamin LeGeyt

The issue with "stopping at cell 767" would also affect this mode of operation. Furthermore, the DRS4 chip has only 10 bit register which records in which cell the event has occured, and where the readout must be started. If you record 8 separate events, you don't know where to start the readout.

The DRS5 chip will have all this possibilitied, but unfortunately it won't be ready before 2-3 years from now.

Stefan

If I may trouble you for a little more information, the critical point then is that there should not be any zeroes in the write config register while the sampling is active?  In case it was unclear I would only be reading out once sampling was stopped (dwrite = 0).  

As for the readout, I know that I would have to read out all 1024 samples each time, and keep track of where each channel stopped in the FPGA.  I would never know the exact cell where sampling stopped but I hoped that if I discard some number of cells on each side of the expected stopping point that I would be OK.  

Thanks again

The problem is when you change the write config register from 11111111 to 01111111, or from 00001111 to 00000111, then the last 256 sampels of the previous channel (in the first case #0, in the scond #4) would be overwritten as soon as dwrite =1 again. So you loose 1/4 ef each channel.

Concerning the readout, indeed you can keep track in the FPGA, but only with a certainty of a few cells. This gives some timing inacccuracy of maybe 10-20 ns, which certainly would be disturbing you.