Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Why do I get SVFA Power Spectrum error?
22 views
Skip to first unread message
David BME
Jun 25, 2008, 4:10:08 PM6/25/08
to
Hello,
I'm having trouble with acquiring sound data from a microphone using the PCI-4474 and the DAQ Assistant and analyzing with the Sound & Vibration toolkit in LabVIEW 8.5.1. Every so often, I'm getting the following error from the Power Spectrum Express VI:
Error -1931 occurred at SVFA Power Spectrum (1 Ch).vi:4Possible reason(s):
Sound & Vibration: The number of samples should be greater than 0.
One time I also got error -200284 at the DAQ Assistant VI. I know that normally means a timeout issue, but it shouldn't be timing out because I'm acquiring 299 samples @ 60 kS/s, and the timeout is set to 11 seconds. I don't think it's a trigger issue either because the problem only happens occasionally, at somewhat random times, and I'm not using an external trigger.
What really stumps me is that I don't get this error every time, and if I click Continue on the error dialogs, it seems to return to normal, at least for a while.
Any suggestions would be greatly appreciated.
Thanks!
David
I'm having trouble with acquiring sound data from a microphone using the PCI-4474 and the DAQ Assistant and analyzing with the Sound & Vibration toolkit in LabVIEW 8.5.1. Every so often, I'm getting the following error from the Power Spectrum Express VI:
Error -1931 occurred at SVFA Power Spectrum (1 Ch).vi:4Possible reason(s):
Sound & Vibration: The number of samples should be greater than 0.
One time I also got error -200284 at the DAQ Assistant VI. I know that normally means a timeout issue, but it shouldn't be timing out because I'm acquiring 299 samples @ 60 kS/s, and the timeout is set to 11 seconds. I don't think it's a trigger issue either because the problem only happens occasionally, at somewhat random times, and I'm not using an external trigger.
What really stumps me is that I don't get this error every time, and if I click Continue on the error dialogs, it seems to return to normal, at least for a while.
Any suggestions would be greatly appreciated.
Thanks!
David
dsb@NI
Jun 25, 2008, 4:40:13 PM6/25/08
to
The error correctly points out that you should not call the Power Spectrum with an empty block of data. One simple test would be to look at the size of the waveform and only compute the power spectrum (put the power spectrum inside a case structure) if the number of samples = required block size.
You are reading 299 samples? This is a very small block size. This block size means that your acquisition loop must run every 5ms with a corresponding frequency resolution in the power spectrum of ~200 Hz. This is very coarse resolution for audio data. There are ways to decouple the block size from the frequency resolution. For instance, you can use Zoom FFT or Fractional Octave Analysis.
You are reading 299 samples? This is a very small block size. This block size means that your acquisition loop must run every 5ms with a corresponding frequency resolution in the power spectrum of ~200 Hz. This is very coarse resolution for audio data. There are ways to decouple the block size from the frequency resolution. For instance, you can use Zoom FFT or Fractional Octave Analysis.
David BME
Jun 26, 2008, 11:10:15 AM6/26/08
to
Hello Doug,
Thanks for your reply. Actually what I'm trying to do is detect beeps of a specified frequency from an instrument and measure the duration of the tone. The frequencies I'm supposed to detect all have tolerances specified as ą 200 Hz. On the other hand, some of the beeps have pretty short durations (in one case, the spec is 8 ą 0.8 ms). So I'm thinking time resolution is more important to me than frequency resolution for this application. That's why I set the number of samples so low, because I was trying to get a time resolution of 5 ms. I guess if I'm trying to measure a resolution of ą 0.8 ms, I'd need an even smaller sample size. The problem is, I noticed that starting and stopping acquisition so often introduced a lot of nasty noise into the signal, which messes up my threshold detection with false triggers. Is there a better way to measure durations of ą 0.8 ms without taking such a small sample size? (I'm actually an intern and new to signal processing, so I'm not really familiar with a lot of the ways to get around these problems.)
I've attached the code so you can get a better picture of what I'm doing.
Thanks,
David
Thanks for your reply. Actually what I'm trying to do is detect beeps of a specified frequency from an instrument and measure the duration of the tone. The frequencies I'm supposed to detect all have tolerances specified as ą 200 Hz. On the other hand, some of the beeps have pretty short durations (in one case, the spec is 8 ą 0.8 ms). So I'm thinking time resolution is more important to me than frequency resolution for this application. That's why I set the number of samples so low, because I was trying to get a time resolution of 5 ms. I guess if I'm trying to measure a resolution of ą 0.8 ms, I'd need an even smaller sample size. The problem is, I noticed that starting and stopping acquisition so often introduced a lot of nasty noise into the signal, which messes up my threshold detection with false triggers. Is there a better way to measure durations of ą 0.8 ms without taking such a small sample size? (I'm actually an intern and new to signal processing, so I'm not really familiar with a lot of the ways to get around these problems.)
I've attached the code so you can get a better picture of what I'm doing.
Thanks,
David
test20080626.vi:
http://forums.ni.com/attachments/ni/100/1799/1/test20080626.vi
PBear
Jun 27, 2008, 12:40:11 PM6/27/08
to
Hi David,
I'm not sure I understand why taking a smaller amount of samples will give you a better time resolution in the time domain. The only parameter that effects this is your sampling rate. You could take ten or ten thousand samples at 200kS/s and you'd still have data every 5u seconds (which is much lower than .8ms). Also, if you'd like to setup and close your DAQ task outside your main while loop, try breaking up the DAQ assistant by right clicking on it and generating the code. You can then put only the read VI in the recurring code loop. See the DAQmx Getting Started guide for ideas and guides. If you are looking for frequency components relative to time, try some of the JTFA functionality in the Sound and Vibration toolkit. Look at the following information for more references.
Perform Spectrum Analysis with the Proper FFT Tools<a href="http://zone.ni.com/devzone/cda/tut/p/id/3772" target="_blank">http://zone.ni.com/devzone/cda/tut/p/id/3772</a>
Sound and Vibration Measurements: How-To Guide<a href="http://zone.ni.com/devzone/cda/tut/p/id/7110" target="_blank">http://zone.ni.com/devzone/cda/tut/p/id/7110</a>
Using Fast Fourier Transforms and Power Spectra in LabVIEW<a href="http://zone.ni.com/devzone/cda/tut/p/id/4541" target="_blank">http://zone.ni.com/devzone/cda/tut/p/id/4541</a> Message Edited by PBear on 06-27-2008 11:31 AM
I'm not sure I understand why taking a smaller amount of samples will give you a better time resolution in the time domain. The only parameter that effects this is your sampling rate. You could take ten or ten thousand samples at 200kS/s and you'd still have data every 5u seconds (which is much lower than .8ms). Also, if you'd like to setup and close your DAQ task outside your main while loop, try breaking up the DAQ assistant by right clicking on it and generating the code. You can then put only the read VI in the recurring code loop. See the DAQmx Getting Started guide for ideas and guides. If you are looking for frequency components relative to time, try some of the JTFA functionality in the Sound and Vibration toolkit. Look at the following information for more references.
Perform Spectrum Analysis with the Proper FFT Tools<a href="http://zone.ni.com/devzone/cda/tut/p/id/3772" target="_blank">http://zone.ni.com/devzone/cda/tut/p/id/3772</a>
Sound and Vibration Measurements: How-To Guide<a href="http://zone.ni.com/devzone/cda/tut/p/id/7110" target="_blank">http://zone.ni.com/devzone/cda/tut/p/id/7110</a>
Using Fast Fourier Transforms and Power Spectra in LabVIEW<a href="http://zone.ni.com/devzone/cda/tut/p/id/4541" target="_blank">http://zone.ni.com/devzone/cda/tut/p/id/4541</a> Message Edited by PBear on 06-27-2008 11:31 AM
David BME
Jun 27, 2008, 3:10:08 PM6/27/08
to
Hi PBear,
Thanks for replying. I probably should have explained better. The reason I was trying to take a sample of data smaller than 0.8 ms is because of the method I was using to calculate the exact duration of the beep. For each set of samples, I used the SVL AC & DC Level VI to calculate the signal level, then if it was above a threshold I captured a time stamp. During each subsequent iteration of the while loop, I would keep thresholding the signal and capturing a time stamp until the signal fell below the threshold, at which point I would collect a final time stamp and subtract the first time stamp from it to get the duration. This method works, but it's only accurate to the duration of the samples collected (maybe not even that). I'm sure there's a better method but that was the only way I could think of at the time. Anyway, that's what I meant by time resolution -- resolving the duration of the beep. I didn't mean the actual time resolution of signal acquisition; I know that depends only on the sampling rate.
Hopefully now I've explained it more clearly and you can see my dilemma. You're right, if I sampled at 200 kS/s, I would have a data point every 5 盜. The problem is, I need a signal level (i.e. RMS value), not just one data point. And I need RMS values in high enough time resolution that I can verify the duration of the beep to within 0.8 ms. That's why I was trying to run my acquisition loop so often, because I only get one RMS value for each loop iteration. That sounds like a pretty inefficient method, though. Is there a way to capture more data points per iteration but somehow chop them up into smaller groups in real time and get more RMS values per iteration? And then how would I know my time stamps are accurate? (Am I anywhere in the ballpark?):smileyvery-happy:
Thanks for your suggestion on the DAQ Assistant. I'll see what I can do there -- maybe that will eliminate some of the extra noise.
Below I've posted the latest version of my VI -- it's a little cleaner than the one I posted yesterday. Take a look at it and maybe my explanation will make a little more sense.
Thanks,
David
Thanks for replying. I probably should have explained better. The reason I was trying to take a sample of data smaller than 0.8 ms is because of the method I was using to calculate the exact duration of the beep. For each set of samples, I used the SVL AC & DC Level VI to calculate the signal level, then if it was above a threshold I captured a time stamp. During each subsequent iteration of the while loop, I would keep thresholding the signal and capturing a time stamp until the signal fell below the threshold, at which point I would collect a final time stamp and subtract the first time stamp from it to get the duration. This method works, but it's only accurate to the duration of the samples collected (maybe not even that). I'm sure there's a better method but that was the only way I could think of at the time. Anyway, that's what I meant by time resolution -- resolving the duration of the beep. I didn't mean the actual time resolution of signal acquisition; I know that depends only on the sampling rate.
Hopefully now I've explained it more clearly and you can see my dilemma. You're right, if I sampled at 200 kS/s, I would have a data point every 5 盜. The problem is, I need a signal level (i.e. RMS value), not just one data point. And I need RMS values in high enough time resolution that I can verify the duration of the beep to within 0.8 ms. That's why I was trying to run my acquisition loop so often, because I only get one RMS value for each loop iteration. That sounds like a pretty inefficient method, though. Is there a way to capture more data points per iteration but somehow chop them up into smaller groups in real time and get more RMS values per iteration? And then how would I know my time stamps are accurate? (Am I anywhere in the ballpark?):smileyvery-happy:
Thanks for your suggestion on the DAQ Assistant. I'll see what I can do there -- maybe that will eliminate some of the extra noise.
Below I've posted the latest version of my VI -- it's a little cleaner than the one I posted yesterday. Take a look at it and maybe my explanation will make a little more sense.
Thanks,
David
test20080627.vi:
http://forums.ni.com/attachments/ni/100/1803/1/test20080627.vi
PBear
Jun 30, 2008, 3:10:10 PM6/30/08
to
Hi David,
I wouldn't use the timestamp method for accurate correlation back to your acquisition. Simply put, since you know the sample clock rate, you can take the number of elements you are interested in, multiple by the period, and you'll have the duration of the beep. The sample clock can give you much more precision than your computer's timestamp.
Your code has the chance of being highly inaccurate when detecting a beep and also it's length as it's dependent on your computer's performance and loop iteration speed. The more of this that can be done in hardware, the better the results. Depending on your board, try using an analog start or reference trigger to acquire the moment your signal has the characteristics your program in. If analog triggering is not supported by your board, you can use software level triggers and index the read array and do your calculations then. Both these ways are more accurate than your current setup.
I hope these ideas help.
I wouldn't use the timestamp method for accurate correlation back to your acquisition. Simply put, since you know the sample clock rate, you can take the number of elements you are interested in, multiple by the period, and you'll have the duration of the beep. The sample clock can give you much more precision than your computer's timestamp.
Your code has the chance of being highly inaccurate when detecting a beep and also it's length as it's dependent on your computer's performance and loop iteration speed. The more of this that can be done in hardware, the better the results. Depending on your board, try using an analog start or reference trigger to acquire the moment your signal has the characteristics your program in. If analog triggering is not supported by your board, you can use software level triggers and index the read array and do your calculations then. Both these ways are more accurate than your current setup.
I hope these ideas help.
0 new messages