Write File stops at 152 Mb

[Qualle]

The signal will come from a detector. For the type of analysis I'll do I'll need the time stamp of each detection, rather than detections per time bin which is a more common way of collecting data. The sampling rate will be variable which makes the situation easier. At the moment I don't know the count rate in the experiment exactly, but it will be in the range of 10 kHz - 1 MHz.

At the moment, I'm satisfied to be able to collect data from a mean count rate of 400 kHz. If it turns out to be too low, I'll consider the options you have given me on this forum. I do really appreciate your help. Thank you.

Calle

[Kevin_Price]

Photon detector?  I don't use them myself, but have been in a number of related threads.  Aren't the individual arrival times governed by some distribution function?  If you plot arrival frequency vs. time, don't you end up with a lot of jitter?  And then wind up doing some smoothing to characterize the general trend of rate vs. time?  If so, read on...

I ask because even 400 kHz sounds like an aggressively high average sample frequency to count on.  If you find that trying to timestamp every individual arrival time leads to too many of those DAQmx errors, here's my suggestion:  Use 2 of the other counters to divide-down the incoming pulses.  It's fairly easy to divide by any integer >= 4. 

Let's say you divide by 10.  Then you'd get actual data at an average rate of 40 kHz, which gives you an update to your "trending" information every 25 microsec.  Later in analysis, you account for the fact that the 25 microsec sample accounts for 10 incoming pulses.  So you treat that datapoint as 10*40 kHz = 400 kHz.  You'll have true information, just less of it.

Just an option that will give you much more headroom in the hardware so that you won't lose experimental data due to the DAQmx error.

-Kevin P.

[TCPlomp]

Fun,
Kevin's answer is just the theory behind dead-time compensation of an X-ray counter

Ton