Frequency shift error using S&V Recorder (DAQmx)

[Midlothian]

Hi Kallis,

Thanks again for your suggestions. Can you tell me where I can control the reset option for first iteration only is this a standard selection?

I am reading from home now and the DAQ is where it belongs back in the office 

[Kallis]

Hi,

Probably you are using a loop (while loop?) around the DAQmx Read vi and the Wav write vi to run it continuously. So you can use the iteration count of this loop to decide whether its the first iteration or not. See attached image. Here I assumed that you are using the resample vi inside the send Write Waveform.vi.

Kallis

[Midlothian]

Thanks Kallis

That is very  clear now. I will give that a go first thing.

Are using the S&V Toolkit yourself, or is this inspiration from other LabVIEW experiences?

[Kallis]

Hi

You can see vi's with resent input in other places also. Most of these store some state information (usually in uninitialized shift registers) which will be required for processing continuous data. So this applies not only to SVT but to any such VI in LV.

Kallis

[Midlothian]

Thanks again.

There is no while loop in the standard SV Toolkit Recorder at the location shown.

I have now added one as shown in your diagram. The  reset terminal is not on the WDT Write sub-vi.

I have opened the block diagram and there are no reset terminals on the lower level vi's either.

I am sorry if this is obvious, but where do I connect the reset?

[Kurt_NISalesEngineer]

Hi,

This information is not directly intended to answer the the most recent post but may offer overall explaination.

 

If you look on page 16 of the 9233 specifications, you will notice that there are only 26 available sample rates for the USB-9233.  You can specify 44.1 kHz on sample rate enum, but notice right below that there is an indicator called "actual sample rate".  You will see 50 kHz here instead of 44.1 kHz.  If you ask the 9233 to sample at an unsupported rate, it will automatically round up the rate to the next supported value.  So it is important to recognize that the 9233 cannot sample at 44.1 kHz but the data is saved with a dt of that is the inverse of 44.1 kHz.  This means that the data is sampled with a dt of 2E-5 but is saved with a dt of 2.26E-5.  When your sinusoid data is read, the points will be spread out a bit and the overall frequency will be lower or "shifted" as you described.

There is a solution though, you can use the "Resample Waveforms (continuous).vi" and specify a "dt" of 1/44.1k.  The new waveform will be an interpolated version of the one sampled at 50k.  Make sure you do this before you save the waveform to the file. As I think has been suggested already.

KB: Valid Sampleing Rates for the NI 9233 

As correctly stated by Kallis, this is not a limitation of LabVIEW but a result of the 9233 itself. 

Kurt NIUK & Jeff NIC
Application Engineers

[Midlothian]

Thanks,

That resampling has been done to the 44,1kHz before saving (see above).

The error however persists with the saved Wave file shifting the frequency.

The root cause is still unclear.

[Midlothian]

I have added the reset to the resampler for the first iteration only as suggasted - no improvement.

[Midlothian]

Kurt,

Thank you for your NI contribution.

I have carefully re-read the 9233 specification and I am absolutely certain that I am using it correctly.

The sampling rate is selected to be 50KS/s the and vi wave output is selected to a compliant rate.

You said  "As correctly stated by Kallis, this is not a limitation of LabVIEW but a result of the 9233 itself"

I strongly disagree with the above statement since this is not just a limitation of LabVIEW  it is an ERROR.

The LabVIEW SVXMPL_WAV Recorder (DAQmx) was used to record the wave file.

The LabVIEW SVXMPL_WAV Power Spectrum.vi to read it.

The result is an incorrect representation of a calibrated signal.

Could NI please provide a corrected vi for recording from the 9233 into wave format.

[Kurt_NISalesEngineer]

Hi

This VI looks at reading the single tone sine signal from myWavFile.wav.txt file that you posted and doing an FFT on the signal shows 882.116

Which is similar to the third Party FFT analyzer.

See VI attached.

Kurt