Measure frequency lower than sampling rate - how?

[Nicke_N]

Hi!

My situation is quite simple. I'm using an X-series card (USB-6341) and I want to sample analog, digital and frequency at a sampling rate of 1000Hz. I want to use the analog sampling clock so that I get the digital and frequency channels synchronized with the analog input. What I have found is that I should use the AI Sample Clock as counter source. If I'm right the gate shall be my unknown frequency to measure and I shall use the method "Sample Clocked Buffered Frequency Measurement".

Now I read in the X series user manual that the frequency to measure must be at least twice the sample clock. But my frequency to measure ranges from 1 Hz to 10 kHz. Can it be that such a simple (and I guess common) task cannot be done with an X-series card that is supposed to be a top-of-the-line DAQ?

If it is possible, how shall I do it?

Many thanks for all input!

[Izzzzz]

Hello Nicke_N,

Please take a look at this KnowledgeBase Article which discusses the issue you might encounter if you attempt to set the sample rate higher than your measured frequency. Although the measurement type does not apply to your specific instance the overall reasoning remains the same. To help you with your application I have a couple of questions and suggestions. 

1. What is your intent by using the AI sample clock as the sample clock for the frequency task?

    a). Are you trying to synchronize it with the digital and analog task? 

    b). Or are you trying to get a more accurate frequency measurement along a wide range of frequencies? (Ensure that the property node CI.Freq.Enable.Averaging is set to true.) 

2. If the answer to the above questions a and b are no then I would suggest either switching your DAQm Sample Clock to the implicit instance and selecting the Large Range Two Counter Method so that you do not run into the issue you are experiencing.

3. If a is no but b is yes then do not use the 1KHz sample clock from the analog input. Borrow another sample clock from an Analog Output, Digital Output, or create one using the Frequency Generator Out or a Counter Output and set it to the specified rate (lower than the range of frequencies you expect). 

4. If both a and b are true then I would suggest using another counter or the Frequency Generator and decimate the 1KHz down to a sample clock rate that would allow for your range of measurable frequencies..

Regards, 

Izzy O. 

Applications Engineer 

National Instruments

ni.com/support

[Nicke_N]

Hi Izzy!

Thanks for your interest.

Regarding question 1. The main reason is a. I want to synchronize my frequency measurement with the analog and digital measurement. 1b have I not even thought about, but I do have a large frequency range from below sampling rate to well above.
So I would say that answer to question 1 is yes on both a and b (synchronized with analog and digital task + wide frequency range).

I just want to explain my test scenario. I have an engine revving up from stand still (engine speed is the frequency measurement) and I am also interested in some analog signals and digital states. I want to measure them at the same time so I can correlate the data.

You suggested "using another counter or the Frequency Generator and decimate the 1KHz down to a sample clock rate that would allow for your range of measurable frequencies". To this I have 2 questions:

- can I decimate the 1kHz sampling clock internally on the USB 6341 somehow?

- let’s say that I have decimated the 1kHz down to 1Hz so I can cover the lower part of my frequency range. Does it mean that on high frequencies (5000Hz) I only get a value update every 1s? Because that is not what I hoped for. I want that every "sample point" (1kHz) gets the frequency of the last completed signal period of my unknown signal (engine speed).

Many thanks for your help!

[Izzzzz]

Hello Nikke_N. 

1. Please take a look at the example below for how you would decimate a 1KHz sample clock down to 100Hz inside the USB-6341 using another counter. Then you would point the source of the sample clock in your Frequency task to the Counter(n) internal output or the Output terminal you specified via the property node. 

2. Yes, at all ranges of frequencies, samples will be stored in the buffer at 1 sample per second. If your engine is going at 5000KHz then 1KHz is an allowable sample rate and you will not need to decimate the sample clock. Although, if your frequency is below 1KHz then you will run into the issue discussed in the previously posted KnowledgeBase Article where you are attempting to put samples in the buffer that have yet to be measured. 

Best Regards, 

Izzy O. 

Applications Engineer

National Instruments

ni.com/support

[Nicke_N]

Thanks Izzzzz!

So if I actually want to have data in my whole frequency range (1-10000Hz) I can not do that at a sampling rate of 1kHz unless I accept that at high frequencies the data will be up to 1s old. And there is no workaround 😞

It looks that the only solution to have synchronized sampling of analog, digital and frequency (with frequencies higher AND lower than sampling rate) is to go for an (expensive) fpga-device.

That's sad.

[John_P1]

The frequency of a signal (which is the inverse of its period) can only be updated to a new value each time a complete period occurs.  The problem is how to reconcile this with the sample clock which is running at its own independent rate.  An FPGA would give you more options on how to handle this use case, but you would have to define the behavior you are looking for.

(wishlist)

For me, I would have liked the option (or really just make this the default behavior) to report the previously acquired samples repeatedly (I don't believe X Series is capable of this though since a hardware error is thrown when you get two sample clocks with no new period):

It would report 0 Hz when the frequency is unknown (the ?s above).  

An added suggestion that would likely only be possible on an FPGA:  Once the time between the last rising edge of the measured signal and the clock edge exceeds the previously measured period, report the inverse of this time rather than the last period (so the reported measurement would be more responsive towards the measured signal slowing--if the signal stops altogether the reported value would gradually decrease toward 0 Hz).

(/wishlist)

Having said that, you *could* configure an edge count task (X series period tasks throw away the first sample ) on the counter, use the 100 MHz timebase as the source, use the signal to be measured as the sample clock.  Use the start trigger of the analog task to arm the counter.  Then you'll have an array of rising edge times of your singal relative to the start of the AI task which could pretty easily be processed (in software, no FPGA required) into the format that you desire (a frequency for each analog sample point).  Be sure to handle rollovers at 2^32 bits (every ~43 seconds using the 100 MHz timebase). 

Best Regards,

[Nicke_N]

John, the thing in your "wishlist" is exactly what I hoped would exist as a NI-DAQmx function. To me, it is the most straightforward solution for measuring frequency. But you are right regarding initial samples and the situation where pulses (frequency) suddenly stops coming. But as long as the user can define the behavior it should be OK.

Your suggested solution using the X-series looks very interesting. I hope it is possible in LabView (I have never used it).

Many thanks! And you just got a +1 for your wishlist.

[Henrik_Volkers]

What you clain a quite easy task 😉 needs more specification:

What is the target resolution of your frequency measurement?

How should frequency output behave at 1kSPS if you only have a 1Hz, 10Hz .... pulse?

Maybe you are only stuck with your one pulse per revolution signal 🙂

How about using an incremental encoder giving more pulses (your card is fast enough 😉 )?

Or use an analog (inductive) resolver providing sin/cos signals and capture it analog?

Another solution is to increase the samplerate to >2x  f_max and do some math and decimation.

I assume that if you capture current and voltage of the electical engine powersupply  you will get ripple on that signals with 2x up to 50x the RPM , so a higher samplerate will help anyway (or you use analog filters).

[Nicke_N]

For sure there are a lot more specification to be done but the main idea in John's wishlist holds.

When it comes to frequency resolution I guess it is limited by 1 period of the 100MHz timebase used for counting (+ the timebase's clock tolerances) which is well within my requirements.

I don't really understand your question about how the frequency output should behave at 1Hz, 10Hz... when sampling with 1kSa/s. I'd do as in John’s picture; pick the previous valid frequency as long as there is no new, even if I receive 999 sample points between every 1Hz period.

Well, I'm pretty stuck with my 1 pulse/rev. I cannot change the system, just observe it...

I don’t understand how an increase in sample rate would help? I capture my systems dynamic well with 1kS/s and increasing the sampling frequency will only limit my lowest possible measured frequency if I do the Sample Clocked Buffered Frequency Measurement as suggested by NI (from X-series user manual: "With sample clocked frequency measurements, ensure that the frequency to measure is twice as fast as the sample clock to prevent a measurement overflow.")

By the way, I'm not worried about the measured current/voltages from the power supply. Their bandwidth is very limited so I can filter heavily both analog and digital 🙂

Thanks for all good input!

[FTI_Newton]

That last situation is pretty much how we do it around here, all handled in the read loop.

If there are no samples ready to be read from the buffer, simply return the value you read during the last iteration (store it in a shift register).

Keep a a timeout running in parallel. If I've been reading the old value for up to the timeout period, return '0' as an assumption that the shaft has stopped rotating (no triggers have generated a read, so it's a safe bet).

Be sure that you dno't simply compare the last read value - if you have a fixed frequency that doesnt' change, you'll eventually hit your timeout and get back a zero.

You sample rate, desired resolution, number of triggers per revolution, and lowest detectable frequency (longest period) are all interdependent operating parameters. There will be some lower limit under which you cannot measure, which should dictate your timeout. You only have one trigger which makes that bound higher, but It doesn't sound like you need to measure that low rotation rate anywy