niScope xIncrement

[Chris_Regan]

I have stumbled upon a bug that is screwing up our FFTs.  We are using a USB-5133 digitizer, but I doubt that matters.  The problem can be easily demonstrated using the example "niScope EX Digital Filtering.vi", and is present in Labview 8.2 and 8.5 at least.

To demonstrate the bug, open the vi and probe the wires leading to "filtered waveform" and "Spectrum" on the block diagram.  Set the min sample rate to 3M, select your device, and run the vi.  I see xIncrements of 1.6E-7 and 1525.88 respectively with the probes.  These values are correct.

Now turn off the filter.  The second xIncrement on my system changes to 762.939.  It should not change at all.  Now the xIncrement in the FFT is only correct for certain magical values of the sample rate.  The FFT itself is now also wrong, but I haven't bothered to figure out exactly how.  I don't see a straightforward workaround, since even though I can calculate the correct xIncrement, that information is not passed into the Fetch Measurement vi in an obvious way where I could intercept it and correct the value.

Can someone help?

[hoffiz]

Hi Chris,

I’m in the team that supports the 5133 and I would be more than glad to troubleshoot this issue with you. I currently have a USB-5133 on my desk and running your same set up. Sampling rate of 3 MS/s and a record length of 4096 (default value for that control) I get a xIncrements equal to: 330ns (1/3.0303MS/s).

Something that I would like you to be aware is that setting a sampling rate of 3 MS/s will coerce to 3.0303 MS/s, because the sampling clock is a divide down of: the “100 MHz onboard oscillator”,  100MHz/X = 3.0303 where X can only be an integer value.

Now the xIncrements for the Spectrum: “The FFT amplitude spectrum is calculated using a split-radix real FFT, and the frequency corresponding to the maximum amplitude is returned. If the input waveform size is not a power of two, the waveform is zero padded to the next higher power of two. The frequency resolution is sampling rate / number of points”.

As you can see the frequency resolution comes from dividing down the sampling rate and the number of samples. The problem you are experiencing is that both of those numbers are actually been coerce to a different value, this value can be pulled from their respective property nodes. I will suggest looking in the Digitizers.chm for the help on that measurment.

Let me know if this helps.
P.D, attach is a VI has all the necessary property nodes. 

[Chris_Regan]

Hi Jamie,

I think I understand your comments, but I don't see how they address the issue we're having.  In particular, since 4096 is a power of 2, I don't see why there would ever be any zero padding.  And without zero padding, I don't see how to get the discrepancies between the expected and the observed Xincrements.

Going through the math:

record length R=4096

min sample rate = 3MHz

actual sample rate S=100MHz/33

expected frequency resolution =S/R=739.82 Hz

Observed frequency resolution (with the probe), digital filtering enabled = 739.82 Hz

Observed frequency resolution, digital filtering off =  369.91 Hz (half the expected value)

That last value makes no sense to me.  Note that with the digital filtering off, the FFT has 4096 data points (in other words, in all cases the FFT extends out to the Nyquist frequency S/2).  I don't see how this is possible, unless it were showing positive and negative frequencies separately (you can't observe a 0.5Hz signal if you only take data for only 1s).  With filtering on, or at certain magic min sample rate frequencies (e.g. 1, 2, 5, & 10 MHz), we see the proper number 2048 data points in the FFT. 

I think that, with the digital filtering off, for certain values of the sampling frequency, the FFT routine gives nonsense.  If you still think I'm mistaken, could you try to explain one more time?

Best regards,

Chris

ps. I can't open your LV8.6 vi with LV8.5.

[Jeff_B.]

I think there might be a few sources of confusion here.

1) When you request 4096 points and then set the Min. Sample Rate to 3.00MHz, the driver will actually configure the device to acquire more points than the 4096 you requested.  The driver is actually trying to cover a sampling time, and since the device can not sample at exactly 3MHz, it needs to acquire more samples at 3.03MHz to cover the same amount of time.  You can observe this by looking at the returned filtered waveform array's size.

2) When using a digital filter, there is a property called "Percent Waveform Transient".  This property will define what percentage at the beginning of the filtered waveform is discarded.  By default it is 20%.  This will discard 20% of the returned waveform, resulting in a shorter waveform passed to the FFT.

3) Due to numbers 1 and 2 above and also to the FFT zero padding Jamie mentioned, it is possible you are performing the FFT on a different power of 2 sized waveform when the filter is enabled vs disabled.

Hopefully this helps, good luck.

[Chris_Regan]

Hi Jeff,

Your comments are illuminating, and seem to explain everything.  I guess all I can say at this point is that I don't like the way this piece of code is written.  The number of data points returned can be smaller than my minimum(!) record length (with a filter), larger (with a sample rate that does not divide 100 MHz evenly), or the same (with no filter and a magic frequency).   That the number of data points returned depends on 2 different, unexpected variables (filter and frequency) in non-obvious ways is unfortunate.

Now that I see what's going on here I can work around it.  If there is a way to actually specify a record length robustly, please let me know.  Thanks for the help.

Chris

[hoffiz]

Hi Chris,

Unfortunately there is no way to fix or hardcode the length of a record, this behavior, that Jeff explained,  is in accordance to the IVI specification and is not specific to the NI-SCOPE driver. To accomplish what you are looking for we can peform a quick check on the code, first we can check if “actual sample rate=requested sample rate”, if they’re not, then we can work our way back, to make so you get a power of to record length.

Let’s say you want 4096 samples to be passed to the FFT (this is a power of 2 so there is no zero padding).  Then if you requests a rate of 3MHz since the device can only achieve 3.03030303MHz it will acquire a couple more samples to keep the requested measurement time constant.   Some ideas: assuming you want to keep the default setting of 20% transient.

1) 4096/0.8 = 5120 =number of samples that will need to be sampled prior to filtering
2) Requested sample rate/Actual Sample Rate =3/3.030303 =0.99= sampling rate increase factor (this will be 1 if the requested sample rate is achievable by the board).
3) Number to provide the NI-SCOPE for minimum number of samples = Floor (Number to be sampled (1) x Sampling Rate Increase Factor) =5068

Working backwards for a quick check:
1) 5068/3.MHz= 1.6893333ms to sample for
2) 1.689333ms x 3.030303MHz=5119.1919 (can’t take 5119 because that would be less than the required time, so take 5120).
3) 5120 - 20% = 5120 x 0.8 =4096

Let me know what you think