DAQmx sampling and displaying

[jfrech14]

Hello, I have seen a lot of topics about sampling and FFT resolution and such, but I am having the issue where I am sampling 5 AI channels on the PCIe6321 at 50ksps each and set the buffer to 1MS. If it is much lower than that it says the software can't keep up. I am also writing to the two AO 50-100ksps (this value is of little importance to me on the signal side, I simply need a clean sine wave around 0-10Hz). 

I am noticing that changing the buffer size of the AO directly changes the update rate of my graphs and the resolution of the FFT. I understand why, but is there a way to set an additional buffer (perhaps delayed from real time) so that the graph can have a continuous update while still having a large enough buffer to have a high resolution FFT? For example, at 50ksps on the AO with 50ks buffer, the graph updates every 1 second and the FFT has a 1Hz resolution. I would like a 50mHz resolution but I don't want the graph to update every 2 seconds. Is this possible?

Thank you!

[Bob_Schor]

Do you understand Sampling Theory?  If you are interesting in signals in the 0-10Hz range, why are you sampling at 50KHz?  Please use standard abbreviations -- I can "guess" that 50ksps = 50KHz, but 1MS, to me, means 1 Mega-second, which makes no sense.

It would help us understand what you mean if you attached the VI (not a picture of it, but the actual VI file, itself) to your reply.

Bob Schor

[jfrech14]

I do understand sampling theory and I was trying to get the AO and the AI at the same rate because I am reading in the strain gauge and want to get the same number of samples so that I can do math on the AI signal and AO signal without using the resampling VI, which I can't get it to work correctly.

Yes, ksps is kHz, which is what I was taught in systems class and see all over the place which is why I used it.  I have never seen MS meaning megaseconds but I've seen it be used for megasamples, again which is why I used it. I'm in physics, so I'm not an expert in the field, so i apologize for not using standard language. MS here is megasamples like when an oscilloscope company refers to a scopes memory depth.

I didn't attach the VI on purpose because I was trying to get a general answer, not one for the specific VI and I didn't want the VI being critiqued on it's format rather than the question at hand, which I have seen very often. I don't program in LabVIEW much. I use c++ most of the time so don't have great LabVIEW practices which are often ridiculed on posts I've read.

[cbutcher]

Hi jfrech,

Although it's true that sometimes comments on this forum can be directed at programming style, this doesn't mean they're invalid - if you wrote your C++ code with horrendously mixed indentation and a bunch of single letter named variables outside of close loops, wouldn't you want someone to suggest alternative styles?

To come to your original problem, I think the VI might really be helpful. If for some reason (including, if you feel very strongly about it, programming style) you can't upload it, perhaps a description of the approach could guide responses. This however is like me telling you I have a problem with my template metaprogramming, but not describing what I've done - you can guess at common problems, but it will be frustrating for both of us.

In this case, experienced LabVIEW programmers might be willing to guess at common DAQmx issues, but there's no guarantee (or even good chance) that the problem will be solved.

Regarding doing maths on two signals at different rates, perhaps that's something forum users could help with? Use of arrays of clusters of arrays might help, if the problem is zero padding in 2D arrays for the shorter arrays (e.g. AO if at lower sample rates)

[Bob_Schor]

Here's a guess (based on some of your responses) -- you have a signal that you want to sample, and simultaneously you want to create a 10Hz Sinusoid (perhaps as a stimulus).  You are interested in analyzing the Signal by displaying its spectrum as it is acquired (and maybe other things that you haven't described).

At one point, you described sampling 50,000 points at 50 KHz, getting one set of data per second.  The reciprocal of the sampling time (i.e 1/(1 sec) = 1Hz) will be the frequency resolution of the FFT, and the maximum frequency will be N/2 times this frequency, or 1 * 50,000/2 = 25 KHz.  To change the frequency resolution or the lowest frequency resolvable, increase the sampling time by either increasing the number of samples or decreasing the sampling frequency (since Sampling Time = N (number of Samples) / SF (Sampling Frequency)).

If my assumptions above are correct, then you only have to decide what parameters you want for your FFTs.  Are you trying to record time-varying spectra?  This is a separate topic, with its own literature, which can be approximated by serial sampling (as suggested here), but there are other techniques ...

Bob Schor

[jfrech14]

I don't have the VI with me, but when I get to the lab, probably Monday, I will upload it. For now, I will describe exactly what I am doing.

I am driving a stage with 1 piezo per axis 0-10V with the two AO on my PCIe 6321. 2 of the AI are reading the strain gauges on each axis that will be used to form a PID loop for closed-loop operation which, I am guessing, will require a reasonably quick sampling rate. The other 3 AI I am using are reading in 3 signals from a quadrant detector. One of those signals is to normalize the other two. The two I am normalizing will go through an FFT with the goal to have a power spectrum from 0 to 50kHz to find the roll-off frequency ( which should be between 10-30kHz).

The AI have to be read in at the same rate, so I am keeping the AI rate at 50kHz since it has around 120kHz aggregate and I can't get it to go faster, but I don't need it to. I have been writing the AO at the same rate so that resampling doesn't have to be done since I am comparing the 2 AI with the output from function generators that go to the AO. Everything works fine, but the graph updates slowly as if I am not using continuous sampling mode. I found out this is because I am sampling at 50kHz with a buffer of 50kSamples, meaning the graphs update at 1second intervals. This is fine, but the software is for undergrad students to use, so I need it to be as natural and intuitive as possible. The PID loop isn't working, but that is a different story for another post, another day.

So my goal is to make another buffer so that I can write the AO samples to a buffer large enough so I can use non-regenerative mode and still get a smooth, continuous graph update. If I use regeneration mode, I get issues where the phases mess up random points but it runs perfectly fine with a small buffer. 1Hz resolution is fine over 50kHz, so the buffer as I have it is fine unless it is beneficial to up it and thus increase the FFT resolution at the same time.

The spectra are of stochastic motion, so actually, time averaging them would be beneficial. The motion I am monitoring is Brownian motion.

Thank you for your replies and sorry if I appeared standoffish or rude. All of the negative berating in other posts has actually caused me to be a bystander for years, but I would prefer to not keep struggling on this for a month. I don't often participate in forums.

Josh

[Bob_Schor]

Thanks for the explanation!

I'm not sure of the specifics of your DAQ device, but I would expect that the AI and AO use the same (basic) clock, but don't need to run at the same clock rate.  What if you generated a 100-point sinusoid at 1KHz (regeneratively) in its own (parallel) loop?  Sample the waveform with your 50KHz AI and verify that you have a good waveform.  Depending on your hardware, it is possible that there may be some (fixed) phase offset between starting the AI and AO loops, but you should be able to "program in" the appropriate Phase Shift in the AO waveform to bring the phase to 0.

Letting the AO "run free" using regeneration means you can devote all the CPU cycles to your AI loop and FFT processing.

Bob Schor

[Kevin_Price]

1. If you want the power spectrum to span up to 50 kHz, you *must* have a sample rate of at least 100 kHz.  

2. High-speed sampling, with buffering, is somewhat at odds with PID control.  The buffering needed to enable high sample rates under Windows *also* adds latency.

3. Regeneration mode should be possible for your AO.  You probably need to be extra careful about making sure you fit an exact integer # of sinuosoid cycles into the buffer.

4. On the other hand, PID and regeneration also seem likely to be at odds with one another, unless something *other* than AO is intended to be your PID control output signal.

5. There's a way to use DAQmx to read data in ways other than a single, lossless, sequential stream.  One thing that can be done is to read overlapping windows of data as often as you like.  So for example, you could read 1 second chunks of data (giving 1 Hz FFT resolution), but do it a a rate like 10 times a second.  (90% of the data from one chunk to the next would be identical in this scenario.)

   The tradeoff is that while it can help you get both rapid updates *and* good freq resolution on your FFT's, the time domain data can't easily be compared with your AO generation signals.

6. If you *do* set up an independent loop for a non-regenerative AO buffer, realize that this buffering will add additional latency to the AO signals.  That won't be helpful if the AO is meant to be a PID control signal.

Overall, I get the impression that several of the specific elements of this app would be manageable in isolation, but bringing them all together at once may be a much more formidable task.  The PID part in particular might be a show-stopper if you need a fast control loop and low latency while running under Windows.

-Kevin P

[GerdW]

Hi Bob,

Please use standard abbreviations -- I can "guess" that 50ksps = 50KHz, but 1MS, to me, means 1 Mega-second, which makes no sense.

Well, ksps is quite common… (Often with datasheets of ADC ICs.)

Otherwise "KHz" is unknown to me: With SI units you should use a small "k" to denote "kilo".

Why do you think "mega seconds" with "MS": this clearly is "MegaSiemens", the reciprocal of µOhm…

(Just some Sunday evening joking about SI units used by US people not used to metric system. :D)

[Bob_Schor]

I stand corrected (and I just checked, GerdW is, of course, correct).  I certainly know the difference between "milli" (m) and Mega (M), and (incorrectly) reasoned by analogy that "kilo" would be K (and, it seems to me, I've seen KHz many times, but probably on US instruments, right next to "ft-lbs").  I knew MS couldn't be "Mega-Siemens", so I (again, incorrectly) guessed Mega-Seconds (which, of course, would correctly be Ms, thank you, mademoiselle).

Bob Schor