0
$\begingroup$

I am creating a data acquisition software, based on Sparrow's Kmax. There I would like to add a feature that will show the system's dead time.

I have already a text field that shows the real time and live. My question has to do, with the dead time.

Is it right to say that the dead time is

$\text{dead time}=\dfrac{\text{total time of recording events}}{\text{total time of acquisition}}=\dfrac{\text{live time}}{\text{real time}}$

$\endgroup$
  • $\begingroup$ Isn't dead time the time that the detector takes to recover after an event? That is, the short period after a detection during which the detector cannot respond and therefore might miss other events. $\endgroup$ – John Rennie Feb 20 '14 at 9:34
  • $\begingroup$ @JohnRennie: Exactly! The thing is I cannot measure that time. I can measure how long my measurement is on(real time) an how long does my system records(live time). Is it correct to say so? $\endgroup$ – Thanos Feb 20 '14 at 9:50
  • $\begingroup$ No. The dead time is typically some constant, $\tau$, so the total dead time is $\tau$ multiplied by the number of events detected. $\endgroup$ – John Rennie Feb 20 '14 at 10:24
  • $\begingroup$ I can agree to that. The thing is I cannot find a way to show to the user the system's dead time which includes detectors, electronics and software. $\endgroup$ – Thanos Feb 20 '14 at 10:49
3
$\begingroup$

Measuring dead-time (or other hardware efficiencies) is a non-trivial proposition, and there is no completely general solution.

The answer that John gives in the comments ($\tau \times \text{number of events}$) is the best case: a system with few interconnections and no "extensible" contributions to the dead time.

"Extensible" describes a system where events coming in during the dead time re-set the recovery clock. Because very high rates can leave such system dead essentially all the time such systems are also called "paralyzable".

So let's try to categorize a few cases

  • Intrinsic dead-time of individual cascading particle detector elements. There are generally of the non-extensible, fix-time per event variety. Often with quite a short $\tau$. You measure dead time by counting events and you design your experiment to keep the total small.

  • Dead-time due to a background veto system (cosmic ray veto for a activity measurement or some such). Depending on the electronics design these can be extensible or non-extensible, but they probably should be extensible. Yuck. If you are getting much extensions you need to reduce the background.

    The KamLAND muon veto was in principle extensible but the rates were so low that it didn't happen often eoungh to matter. Because muon vetos were recorded in the data stream the total dead time could be simple added up later.

    Dead times that arise from veto signal can be estimated by counting a clock signal as vetoed and raw. Of course, you need to have designed this in.

  • Computer dead-time due to read-out delays or a rate-limiting by imposed sampling window. This is generally a non-extensible dead time characterized by a simple counting again. The only issue here is that the $\tau$ may need to be evaluated by Monte Carlo if the system consists of multiple parts with different response times. (Because a trigger that occurs near the transition between "live" and "dead" periods might be missed if one part of the signal is registered on the other side of the cut off; I needed to do that for a KamLAND study once.)

$\endgroup$
  • $\begingroup$ Thank you very much for your answer! It is really educative. The thing is that I need a rough estimate of the whole system's dead time. Reading your answer, I think that the computation of dead time, by dividing live time with real time, while multiplying by a roughly estimated factor(of 3 for instance) would be a way to estimate system's dead time. Do you think that this would work? $\endgroup$ – Thanos Feb 21 '14 at 16:25
  • $\begingroup$ The important question always "What is the actual detector attached to the DAQ?". Assuming this is intended to be a very general system you can't really make any assumptions and about the best you can do is ask the user to estimate $\tau$ and state if the system is extensible or non-extensible. $N\tau$ with $N$ the number of events will then be as good as the user's estimate of $\tau$ for non-extensible systems, and still usable for extensible systems if $N\tau \ll \text{running time}$. $\endgroup$ – dmckee Feb 21 '14 at 19:28
  • $\begingroup$ That is really a nice approach! Let the user chose! I think that is very fair! An estimation of a silicon detector dead time? How to measure or estimate the dead time of a detector?(If you agree, I can post it as a new question). $\endgroup$ – Thanos Feb 23 '14 at 10:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.