Recording Ultrasonic Noise with PCI-6132

[Now_With_Underscores]

If you still aren't measuring a signal, I recommend using the test panels in Measurement and Automation to see if this is a hardware or software setup issue.  To access the test panels, go to Start»Programs»National Instruments»Measurement and Automation.  Once open, right click on your DAQmx device (listed under Devices and Interfaces) and select 'show test panels.'  See if you can acquire data here.  If not, this is more than likely a hardware issue.  Keep us up to date on what you find.  Have a great weekend!

[McMurray]

Thanks everyone for all the advice.  I'm going to try to acquire an ocilliscope, but probably won't be able to until after the holiday, since no one is at work these days except for me (and all of you!).  I'll let you all know how that goes.  As far as the .wav issues go, 192kHz may not be fast enough.  The sounds we'll be recording will be in the range of 45kHz to 90kHz, so we'll need to sample considerably higher than 192kHz.  I was hoping for something in the neighborhood of 3MS/s since I intend to play them back and look at behavioral response (need to maintain fidelity as much as possible).  It may be that I'll need to take samples of my total recording and time-expand them to allow for fitting into the .wav container (both in frequency and in total file size, as pointed out).  This sounds arduous...  Joy.  My card allows for sampling at 3MS/s, so that shouldn't be an issue.  Just need to resolve the hardware now I guess.  Once I get recordings I'm confident that I can make them "analyzable".

Matt

[Now_With_Underscores]

Hey Matt,

We can definitely write at 3MS/s, but keep in mind this is almost 12MB/s for 2 channels at 14 bits resolution, which means you can only record for 341 seconds before you hit the 4GB .wav limit; keep in mind that your hard drive will need to be able to write continuously at 12MB/s.  Also, just a heads up that to sample at 3MS/s on your card you will need to use an onboard counter, as described in the user's manual.  Best of luck in your application!  Happy holidays!

[McMurray]

So, I've had good success with the recording now. We've got it sampling at 2MS/s saimultaneously on the 4 channels, though it required a bit of fancy trickery (background measurement, triggers, producer-consumer arcitecture, and a really fast computer).  Interestingly, we ran into a buffering error using the TDMS format, which is supposedly optimized for streaming.  We didn't get this error using the *.wav format.  Perhaps wav's actually write to disk faster than TDMS?

I'm now working on the playback of the noise using a PCI-6731, and I've run into a bit of a problem.  I always end up with the error:

Error -50103 occurred at DAQmx Write (Analog 1D Wfm NChan NSamp).vi:12

Possible reason(s):

The specified resource is reserved. The operation could not be completed as specified.

Task Name: _unnamedTask<1C>

Any thoughts on how to fix this error? I've attached the VI so you can see how it's working.  Thanks for your continued help!

Matt

[RavensFan]

You can't have two separate DAQ tasks running at the same time.  Once one starts running, it takes the clock which blocks the other from running.  You will need to create a single task that has both channels being used.  Then they are able to share the clock.

Actually searching the forums for that error number http://forums.ni.com/ni/search?board_id=170&submitted=true&q=50103 would turn up hundreds of messages discussing this.

Message Edited by Ravens Fan on 05-09-2009 12:54 AM

[McMurray]

When setting up my task, I need obviously to incorporate the DAQmx Timing. How do I account for the variation in the langth of the two AOs?  They'll both be the same sample rate, but the length file of each can very, thus the timing would also vary?  Is this correct?  So, I thought to use the waveform function of the DAQmx Timing, but since I'm using 2 waveforms simultaneously, which waveform should I base the timing on? I've attached the vi I'm working with below.

[Now_With_Underscores]

Hi McMurray,

If you want both waveforms to start at the same time, you can simply pad the shorter of the two waveforms and that will make them the same length.  If you want the waveform to start n points into the other waveform, you could simply buffer the waveform with n points on the input and then [length(longerwaveform)-n] points on the output.  We could also repeat part of the shorter waveform, etc.  The sample clock will be based on the dt of the input waveforms, which must be the same per analog output task.

If you want to output at different AO rates, you could always use another DAQ card and then the AO would be independent.  This limitation is due to the fact that we only have 1 hardware source clock for AO.  If one of the signals is at a multiple divisor (m) sampled rate of the other, we could simply output each of the shorter waveform's point repeatedly m times per sample from the longer signal.  For example, if s1 is [1 2 3 4 5 6 7 8 9] and has a dt of 5ms and s2 is [4 5 6] and has a dt of 15ms, we could output each value of s2 3 times per s1 value.  This would yield an s1 output of [1 2 3 4 5 6 7 8 9] and an s2 output of [4 4 4 5 5 5 6 6 6].

In short, there are several ways around this AO timing limitation, depending on what we're trying to output.

Regards,
John S

Applications Engineer
National Instruments