LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

SingleToneInfo frequency results off by 10^5.

Solved!
Go to solution

I've got one of the brand new PXIe-5172 8 channel digitizers in my PXI Chassis, running niScope 17.2. I'm capturing data at the max rate, 250 MSPS. I call niScope_ConfigureHorizontalTiming to configure the sample rate and number of samples to acquire, niScope_Read to get the waveform data, and SingleToneInfo to process the waveform.

 

With all settings the same, the frequency returned from SingleToneInfo changes based on the number of data points to acquire that I pass in the horizontal timing call.   Here's the relevant code. Please note that I cannot get the code from the PXI Chassis, and had to type it in by hand. That's why the error code is abbreviated, and it might have typo's.

 

if (niScope_ConfigureHorizontalTiming(vi, 250000000, acqSize, 10.0, 1, VI_TRUE) != VI_SUCCESS) {
    printf("Error\n");
}

// Get the number of waveforms
if (niScope_ActualNumWfms(vi, channel, &numWaveforms) != VI_SUCCESS) {
printf("Error\n");
}

wfmInfoPtr = malloc(sizeof(struct niScope_wfmInfo) * numWaveforms);

// Read in the waveform data
ViStatus status;
if ((status = niScope_Read(vi, channel, timeout, acqSize, waveformData, wfmInfoPtr)) != VI_SUCCESS) {
printf("Error\n");
}

// Get the info from SingleToneInfo
double freq = 0.0, amplitude = 0.0, phase = 0.0;
double samplePeriod = wfmInfoPtr->xIncrement * wfmInfoPtr->actualSamples;
SearchType search = { 14700000.0, 5.0 };

SingleToneInfo( waveFormData, wfmInfoPtr->actualSamples, samplePeriod, search, &freq, &amplitude, &phase );


The input signal is 14.7 MHz, at 1.5 V peak to peak.

 

The results are below. Sample period is in seconds, and frequency is Hz.

# Samples  SamplePeriod   Frequency

100              0.0000004        147016.3

1000            0.000004          14700.5

10000          0.000040          1469.999

100000        0.000400           147.000030

 

Non power-of-10 results

50000          0.000200           294.000128

75000          0.000300           196.000089

 

So I can see that the frequency returned from SingleToneInfo is related to the number of samples. That shouldn't be, so I must be doing something incorrect. Does anyone have any ideas where I might be using SingleToneInfo wrong?

 

I'm using LabWindows/CVI 2017, with niScope 17.2.

 

Thanks in advance for your help!

0 Kudos
Message 1 of 6
(3,533 Views)

Some years ago I found strange behaviors with SingleToneInfo() and I opened this discussion.

NI confirmed at least one bug, but I don't know if it has been fixed.

Could your problem be related?

Vix
-------------------------------------------
In claris non fit interpretatio

-------------------------------------------
Using LV from 7
Using LW/CVI from 6.0
0 Kudos
Message 2 of 6
(3,487 Views)

Hi Vix,

 

Thanks for the response. I am quite familiar with that discussion thread. It came up repeatedly during my information searches on this topic. There is just not that much out there on SingleToneInfo. That thead helped me to understand a little more about the Search parameter.

 

I've tried passing NULL for the Search parameter, and a Search parameter with the correct center frequency and a frequency width of 0, 5, 10, 15, etc all the way up to 100. None of those changes made any difference at all in my results.

 

The frequency returned by SingleToneInfo varies with the sample rate and the number of points that I acquire. I just happened to notice a returned frequency of 147.000030 Hz one time while experimenting with different rates and points. My actual frequency is 14.700000 MHz. I thought, "That's weird!" And from then on we've seen how that frequency is related to the number of points we acquire, as long as we keep the sample rate constant (it's maxed out for the 5172 at 250 MSPS).

 

I'm glad you saw this. Did you ever get your problem fixed? I'm using the 2017 version, which is a long way from 2012. Hopefully it's been fixed by now.

 

Thanks,

Steve

0 Kudos
Message 3 of 6
(3,479 Views)

Hi Steve,

I don't know if the issue has been fixed or not.

When I first saw the problem I needed a quick fix (because the software was running at the customer site), so I use a fixed value of

200/buffer_length

for frequencyWidth parameter (which is expresses as a percentage of the sampling rate - so this value is 2 spectral lines).

This worked and so I didn't investigate anymore the behavior of SingleToneInfo.

 

As an example, if buffer_length is 2048, I set frequencyWidth to 0.097; I get right results only with values greater that 0.0001 and less than 0.1.

I don't know if your values (0, 5, 10, 15, ...) work or not.

Could you try settting frequencyWidth to 0.1, for example?

 

I remember that neither in the public forum, nor in private messages NI could clarify enough how frequencyWidth is supposed to work with SingleToneInfo().

Vix
-------------------------------------------
In claris non fit interpretatio

-------------------------------------------
Using LV from 7
Using LW/CVI from 6.0
0 Kudos
Message 4 of 6
(3,474 Views)

I know of at least two other groups here where I work (Colorado Springs, CO. USA) that are successfully using SingleToneInfo, but one is a C# program, and the interface is very object oriented - SingleToneInfo is an object with the details hidden. The other is LabView. No one is using LabWindows/CVI like I am.

 

So I'm pretty sure the bug has been fixed, but I tried 0.01, and 200/sample_count; neither made a difference. I still get a frequency of 147.000030. 10^5 off.

 

I'll contact my local National Instruments engineer. He's pretty good about finding answers.

 

I'll post the fix if I get there.

 

Thanks Vix!


Steve

0 Kudos
Message 5 of 6
(3,470 Views)
Solution
Accepted by topic author PikesPeakNIUser

OK guys - here's the answer.

 

I got a call from an Charlie Johnston, a senior NI Engineer. He said that the "Sample Period" parameter is the time between samples, not the total time of the acquisition. So I changed my call to SingleToneInfo, and it works properly.

 

Thanks Charlie!

 

Steve

Message 6 of 6
(3,456 Views)