DAQmx period measurement- buffer is cut when frequency is too high

[Kevin_Price]

Shafran,

The 6602 gives you lots of counters -- perhaps some extra ones can be used to help?

1. Let's suppose you don't directly measure the period of the raw photon pulses, which are quite narrow and may produce bursts at too high a freq for reliable buffered period measurement.  I'm guessing it's a problem with the very small on-board FIFO.

2. Instead, use the raw pulses as the trigger signal for retriggerable single pulse generation.  This will cause each pulse to be delayed by a fixed delta time, and you can use this delayed pulse output as the signal for buffered period measurement.  The new output pulses will have the same period as the original raw pulses. 

   Well, almost.  The exception is during pulse bursts where a 2nd raw pulse comes in before the 1st delayed pulse is fully generated.  In this case, the 2nd raw pulse is effectively ignored, and you'll need a 3rd raw pulse coming in to trigger the 2nd delayed pulse.

   The pulse parameters can be selected to provide the desired cut-off freq, perhaps something in the order of 100 kHz.

3. This much by itself can help prevent your data acq error, but will leave you with an unknown # of ignored raw pulses

4. If you also set up another counter task to count edges of the raw photon pulses, you'll known the total # of raw pulses that came in.  The difference between this and the # of buffered periods will be the # of high-freq raw pulses that were ignored.

5. If needed, the edge-counting task could become a buffered task.  Then you can determine which interval the missed pulse(s) belong to.  However, a buffered task will be more taxing on the data transfer problem that's causing you trouble.

6. It may be worth mentioning that this kind of issue has come up many times before.  Others have sometimes resorted to binning -- generating a fixed frequency "sample clock" pulse train and then counting photon pulses per sampling interval.  Just another option out there that seems to be sufficient for some situations.

-Kevin P.

[Eyal_S.]

Hi Kevin,

Thanks for all your help. I'm sorry for the late reply I didn't get to it until recently. Your suggestions helped me a lot, I'm know able to run the program without problems.

I'm using the measured signal as a trigger and I selected the pulse parameters to provide a cut-off freq of about 200ns. My only concern is that even such "low" cut-off freq can affect the quality of my results.

I'll elaborate a bit more about my application :

I'm trying to continuously  measure the time interval between each two corresponding pulses that are generated by an APD . The average intensity varies  (depending on the experiment) between 2-30 kHz, however, sometimes there are bursts that are estimated at several MHz. The width of the pulses that are generated by the APD are 38ns. It would be best if I didn't have to cut-off any frequencies because that would greatly improve the accuracy of my results. I don't use the count events possibility since it will use a lot of memory at a high resolution (to my understanding, please correct me if I'm wrong).

I'm open to suggestions...

Thanks again for all the help 

Shafran

[Kevin_Price]

Sorry, but I don't think I've got any different ideas.  The purpose of the "filtering" (implemented here as a retriggerable pulse) is specifically to make sure that you DON'T pass through frequencies too high for the board to buffer to RAM.  Unfortunately, the counters have only a 2-sample FIFO on board, and can't transfer data through the PCI bus fast enough to prevent overwrites when you sample too fast.

"Too fast" is system-dependent, but seems to be in the 100's of kHz for sustained transfer when the PCI bus has nothing else to do but handle the counter data acq task.  Very brief bursts in the MHz realm *might* by possible, but wouldn't be reliable.  The trouble is that the overwrite error is unrecoverable, so your app needs to be sure that it happens *never* rather than *rarely*.

I'm not sure what *your* understanding is of the edge-counting suggestion, so am not sure if this is a correction.  My idea was that the edge counting task would sample at the same rate as the period measurement task -- using the "filtered" retriggerable pulse as a sampling clock.  The edges to be counted would be the raw APD pulses.  During normal firing rates, the edge count would simply increase by 1 on each sample.  During a high-freq burst however, the count would increment internally though no samples would be buffered.  When the burst is over and you get normal pulse rates again, you'd see the discontinuity in the edge count buffer and be able to know exactly when the burst occurred and how many pulses were filtered out.

There's actually an even neater way to do this if you configure for position measurement as an Up/Down encoder.  Then pass the raw APD pulses into the Source input (causing increments) and the retriggerable pulse into the AUX/UpDn input (causing decrements).  If you sample on the trailing edge of the retriggerable pulse, you'll get 0 values during every interval that was NOT filtered and you'll increase by the # of filtered pulses during the high-freq bursts.  There's no hardware advantage to this method, but the data is a bit easier to understand at a glance.

-Kevin P.

[KrisJa]

Hello Kevin Price or anybody else with experience... I am trying to find a solution to the problem I posted about here:

http://forums.ni.com/ni/board/message?board.id=40&thread.id=2779&view=by_date_ascending&page=2

The last post of mine in that thread.

Looking for a solution myself I stumbled onto this thread. The problems seem quite similar yet I fail to come up with a solution. You guys seem to know what you're talking about so I was wondering what your thoughts would be on the matter.

Cheers,

KrisJ