 Tue May 21 13:25:41 2013, Stefan Ritt, mac osx 10.6
|
> Hi,
>
> I would like to use the DRS4 with my macbook pro running osx 10.6.8.
|
|
Tue May 21 13:32:13 2013, Martin Petriska, mac osx 10.6
|
> Hi,
>
> I would like to use the DRS4 with my macbook pro running osx 10.6.8.
|
|
Tue May 21 17:45:05 2013, Enrico Conti, mac 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.
|
|
Tue May 21 17:48:45 2013, Enrico Conti, mac 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.
|
|
Tue May 21 17:51:09 2013, Stefan Ritt, mac 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.
|
|
Tue May 21 18:30:11 2013, Enrico Conti, mac 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.
|
|
Fri May 24 17:58:07 2013, Enrico Conti, mac 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.
|
|
Fri May 24 18:20:14 2013, Stefan Ritt, mac 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 |
|
Sat May 25 12:45:46 2013, Enrico Conti, mac 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 |
 Thu Oct 14 15:19:00 2021, Keita Mizukoshi, livetime (or deadtime) of DRS4 evaluation board
|
Dear experts,
I would like to use the DRS4 evaluation board for actual physics experiment. |
|
Thu Oct 14 15:25:07 2021, Stefan Ritt, livetime (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 |
|
Thu Oct 14 18:03:52 2021, Keita Mizukoshi, livetime (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? |
|
Thu Oct 14 18:42:31 2021, Stefan Ritt, livetime (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. |
|
Fri Oct 15 06:15:53 2021, Keita Mizukoshi, livetime (or deadtime) of DRS4 evaluation board
|
Thank you very much.
Stefan
Ritt wrote:
I would say not exactly, but it's a good approximation. |
|
Fri Dec 13 10:37:18 2013, Dmitry Hits, input protection in DRS4 evaluation board
|
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 |
|
Fri Dec 13 11:37:58 2013, Stefan Ritt, input 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 |
|
Mon Aug 29 09:36:34 2016, benjamin legeyt, increment write config register on the fly?
|
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. |
|
Mon Aug 29 10:57:33 2016, Stefan Ritt, increment write config register on the fly?
|
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. |
|
Mon Aug 29 12:18:49 2016, benjamin legeyt, increment write config register on the fly?
|
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. |
|
Mon Aug 29 12:51:48 2016, Stefan Ritt, increment write config register on the fly?
|
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 |