continous period, overwritten error

[LiangJiaQing]

I am working for a project to counting every photon for about 10 seconds.

I used the pci-6602 and a computer with a 2.8Ghz Core i5-2300 CPU and a 16GB RAM.

The software is Measure studio 2010 SP1 and NI DAQmx 9.5.

But there will be an error:

Data was overwritten before it could be read by the system.

If Data Transfer Mechanism is Interrupts, try using DMA. Otherwise, divide the input signal before taking the measurement.

For average 300kHz input signal, the error appeared immediately, but for average 1kHz input signal, the error still appeared after 3-5 seconds.

Here is my setting:

myTask.CIChannels.CreatePeriodChannel(counterComboBox.Text, "",

                    Convert.ToDouble(minValueTextBox.Text),

                    Convert.ToDouble(maxValueTextBox.Text), edge,

                    CIPeriodMeasurementMethod.LowFrequencyOneCounter, 0.001, 4, CIPeriodUnits.Seconds);

        myTask.Timing.ConfigureImplicit(SampleQuantityMode.ContinuousSamples, 100000);

        myTask.CIChannels.All.DataTransferMechanism = CIDataTransferMechanism.Dma;

        myTask.CIChannels.All.DuplicateCountPrevention = false;

        myTask.Stream.ReadWaitMode = ReadWaitMode.Poll;

        myTask.Stream.ConfigureInputBuffer(1000000);

I tried many solutions and changed many setting, but the result didn’t changed.

I heard that the on board memory of pci6602 is small, but for 1kHz signal it still can’t work.

Please help me to solve this problem.

Thanks very much.

[Kevin_Price]

Not too surprised that 300 kHz can't be sustained due to the very small on-board FIFO.  I *am* surprised that 1 kHz is a problem, and would suspect some kind of electrical signal noise that looks like multiple edges at a high rate.  Test this out by feeding clean 1 kHz TTL pulses from a function generator or another on-board counter.  If these sources work without similar errors at 1 kHz, I'd recommend this as a good time to figure out you system limits.  Crank those freqs up until you start seeing the errors again.  I'd expect you to reach 100 kHz or higher.

-Kevin P

[Avina]

Sorry for replying you for such a long time. We have tried the method you give me and the result was just like what you expected. When I cranked the freqs to 130kHz the errors would appear and I checked the freqs that made it overwrite when I use our experiment detectors instead the generator, it was almost 1000kHz that much higher than 130kHz. However, in our real experiments, we can’t make the data all keep in one same frequence, and it must have some data is higher than 130kHz although the average freqs is lower than 100kHz. So, what can we do to solve this problem?

Thank you so much and hope to receive your reply.

[Avina]

Sorry for forgetting to introduce myself. I'm the partner of Jiaqing and did the test you told us. Hoping to receive your respond soon. Thank you!

[Kevin_Price]

The problem is likely to be the very small onboard FIFO (only 1 or 2 samples) of the 6602.  A short high-freq burst of pulses will overrun the FIFO before the data can be transferred to your system RAM. 

I've got 2 very different possible suggestions:

1. Replace the 6602 with a board which has a deeper FIFO, such as an X-series multifunction board.  This alone is likely to solve your problem if you have brief bursts of high freq but an average < 100 kHz.  I think this is likely a much better solution than the next one.

2. Approach the problem differently.  Rather than a period measurement of each individual pulse, approach it by binning counts at a fixed sample rate.  This approach may or may not give you sufficient resolution -- it very much depends on what you're studying.  I've not done photon detection, so can't offer any field-related advice.

-Kevin P

[Avina]

Thank you first to reply, I have some questions about your suggestion.

1. What do you mean about binning counts at a fixed sample rate? I'm not so clear about how to do it?

2. And could you tell me more about how this way may affect our experiment reslut and what kind of experiment may not get the sufficient resolution usually?

And by the way, I have seen many people met this problem before, and someone said a method called "divede the signal". Do you know this method? Could you explain this?

Thank you!

Avina 

[Kevin_Price]

1. The basic idea is that instead of measuring the period between each individual photon detector pulse, you simply count the # of pulses occurring within a fixed interval.  The fixed interval would be a constant rate sample clock and you could use another counter to create it.  You may need to look into the "Duplicate Count Prevention" property because you will want to capture the many intervals in which 0 pulses occur.

2. Impossible for me to judge what resolution or format you need for your data.  In general, count-binning will give you a measurement of average photon activity per sampling interval.  If you get 10 counts in 1 msec, you'll only be able to see that as an *average* of 10 kHz.  Reality may be 10 pulses at > 100 kHz and a lot of idle time.

  Freq or Period measurement on individual pulses gives you much more information about photon activity and you can also do some binning-like averaging after the fact.  But the occasional fast bursts may cause a data acq error.  The high precision trades off against the chance of losing all the data due to a data acq error.

If it was me, I'd lobby for a more suitable data acq board like an X-series and measure individual pulses.  But it may be that your particular experiments & studies don't demand that precision, in which case binning is a method that should work with the data acq board you've already got.

-Kevin P

[Avina]

Thank you but our experimen need to collect every photon. Is there no other ways to solve this problem? I have seen many people have met this problem and all them change another card finally? 

By the way, I have seen this on another board:

"To most efficiently handle this issue, I would recommend placing the build array VI's inside a case structure that only executes if there has been no error on the DAQmx counter task.  That way, you will be able to simply discard the "corrupted" data. 

The other option is to build the array, and then post process the data to remove long strings of zeros by using the Search 1D Array and Delete from Array VI's. 

Then, you can remove the error and resume your acquisition with another case structure that executes when the error code matches the error code that you commonly see when 2 photons arrive too close together.  Then, inside that case structure, you can use the Clear Errors.vi to clear the error from the data wire and continue your acquisition. "

Do you think this way can work and I think this method is a little complex?

--Avina

[Kevin_Price]

If you need to collect every photon, then you'd better get a data acq board that's better suited for the acquisition.  The 6602 just isn't a good choice for handling high frequency bursts.  A PCIe X-series board seems likely to solve the problem.

The method you quote doesn't sound like a good solution if you really need *every* photon.    It's just another workaround for having a data acq board that can't handle the incoming pulse rate.  The essence of it is to be ready to see data acq errors and reprogram the task as soon as you detect them.  Each error & reprogramming *guarantees* that you will be completely blind to new photons for a little while.  You'd end up with discontinuous data, never knowing what kinds of pulses may have occurred while you were busy reprogramming the task.  So if you really need "every photon", the solution is to prevent and avoid errors, not plan for reacting to them.

Again, a decent workaround if you're totally stuck.  But I strongly advise: don't be stuck.  Get a capable board. 

-Kevin P

[Avina]

Would you tell me more details about the new card? There are too many cards in PXI-series. Did the other people meet this problem before all change another card finally and which card did they change for?

Thank you!

--Avina