Period counter input reads only one value instead of N samples

[ryz]

Hi!

I am currently using a USB NI DAQ card (NI USB-6216 OEM) to monitor a frequency modulated output signal.

I am using a period measurement to measure the time between falling edges. My VI already gives some results but it yields only one measurement result after every loop execution even though I configured it to N sample. On the attached picture of the front panel it is clearly visible that several periods take place during one cycle but somehow I get only one result. Since the waveform was also recorded with the same DAQ card the hardware is not a limitation...

It would be a great help if anyone could give me a hint on what I am doing wrong.

If you have any questions, or something is unclear please don't hesitate to ask!

I attached only pictures of my VI since without the required hardware it is not possible to recreate the VI execution anyways. If you want me to post the VI nevertheless, I can do that too of course.

Front panel

Block diagram

Thank you!

[ryz]

Hi, just a follow up: I added an implicit timer to the counter input which was missing. Now it is much better, although it still skips many periods.

[Norbert_B.]

Hi,

Normally, these are the ways you measure frequency: http://zone.ni.com/devzone/cda/epd/p/id/5000 

Since the 6216 is not capable of doing these, you either have to find another way, or get anoter instrument.

You can use period measurement and then convert it to frequency. I ttached a block diagram that shows how to do that.

Regards,

Norbert

[John_P1]

For the record, the 6216 is capable of measuring frequency (even though it isn't included in the hardware list on the previously linked Developer Zone, but these lists are rarely up to date).

Anyway, in the original example (without any timing on the counter task) there is no buffer so I believe you should only expect a single sample per read call (I believe the read call initiates the measurement, and then the following period's sample will be returned--although it isn't typical to read back N samples with a non-buffered task so I'm not 100% sure that this is truely how it works).

Adding implicit timing is a requirement if you want a sampled measurement for each period (it configures a buffer in which samples are latched based on the edge of your external signal).  However, I believe the inconsistency that you are still seeing is a result of not specifying a number of samples to read.  On a USB device, data is transferred from the hardware buffer to your PC in bulk to maximize efficiency.  Reading -1 samples (which is the default if a number is not specified) does not initiate a data transfer and instead reads whatever is currently available in the software buffer.  If samples are still in a hardware buffer they would not be returned by your read (but they are not lost either, they will be available whenever they are transferred from the device to your computer).

The situation presents a catch-22.  If you specify a fixed number of samples to read, the call to DAQmx Read will initiate the data transfer from the hardware to your PC.  However, it isn't possible to know how many samples have been acquired until they have already been transferred.  So... how does one know how many samples to ask for?

I've found that making 2 read calls gives pretty reasonable results.  Explicitly reading 1 sample will initiate the transfer (and the other samples in the hardware buffer will be transferred as well) and then reading -1 will read back whatever is left in the buffer.

Best Regards,