DSPRelated.com
Forums

Sampling rate required to resolve separate sonar echoes

Started by Nicholas Kinar January 20, 2009
Jerry Avins wrote:
> > Moreover, Kinar wrote in his opening post, "...greater than 2*f_h, where > f_h is the maximum frequency of interest in the analog signal." > Frequencies higher than f_h, whether interesting or not, will alias. The > higher sample rate moves that alias out to where a digital LPF can > suppress it. > > Jerry
Yep, I agree, Jerry. Like it or not, some form of low-pass filtering is always required in DSP. Thank you for clarifying this. Nicholas
Here's another question that I'm placing under this thread.

Does the sampling rate of the ADC influence the accuracy with which the 
time-of-flight (TOF) of a sonar pulse can be determined?

If I sample at a higher sampling rate, can I measure with greater 
accuracy the arrival time of a pulse?

However, is it correct to assume that the time-bandwidth product only 
applies to resolving pulses of a certain duration and not the pulse 
arrival time?

So let's say that I have a seismic source and two receivers.  If I 
perform velocity analysis using the data from the two receivers, will my 
velocity analysis will be more accurate with a higher DAC sample rate?


Nicholas
On Tue, 20 Jan 2009 18:14:13 +0000, mblume wrote:

> Am Tue, 20 Jan 2009 08:44:30 -0800 schrieb Rune Allnor: >>> >>> Understandably, it is the bandwidth that is the bottleneck in this >>> situation.  Why the 5-10x oversampling rule? >> >> Because it prevents users from shaving the sampling rate too close to >> Nyquist. Making hardware and doing experiments is both time-consuming >> and expensive, so selecting the sampling rate is a major design >> decision that, once implemented, can not easily be revised. >> >> You can always add a decimation step afterwards, if the amounts of data >> become too large to handle with 10x oversampling. If you sample at >> 1.05x Nyquist you are stuck with no leeway. >> > In addition to what Rune said, you'll have to take into consideration > that you have to filter your analog data before it is given to an A/D > converter. This filter being analog, it is easier to have one with a > slower roll-off. If you oversample, you can either work with the > unncessary bigger bandwidth throughout the whole chain or decimate at > some intermediate step. > > Just my 0.02$. Analog electrical engineers might want to disagree :-) > Martin
Nyquist didn't say that -- http://www.wescottdesign.com/articles/Sampling/ sampling.html. Anti-alias filtering is only helpful if there is significant alias energy to filter out, and if the action of the filtering won't screw up your signal. So AA filtering is a great thing for applications like audio, where your microphone can pick up _anything_, and some of that would sound _terrible_ when it's aliased down. But for things like control loops and characterizing pulses, it's often best left off. -- http://www.wescottdesign.com
> > Nyquist didn't say that -- http://www.wescottdesign.com/articles/Sampling/ > sampling.html. Anti-alias filtering is only helpful if there is > significant alias energy to filter out, and if the action of the > filtering won't screw up your signal. So AA filtering is a great thing > for applications like audio, where your microphone can pick up > _anything_, and some of that would sound _terrible_ when it's aliased > down. But for things like control loops and characterizing pulses, it's > often best left off. >
That's a good point, Tim--and I like your article on Nyquist. I'm working with sonar signals and other "audio-like" stuff, but it's interesting to note that for pulse characterization, aliasing filters are sometimes not used. Nicholas
On 20 Jan, 19:33, Nicholas Kinar <n.ki...@usask.ca> wrote:
> Here's another question that I'm placing under this thread. > > Does the sampling rate of the ADC influence the accuracy with which the > time-of-flight (TOF) of a sonar pulse can be determined?
Not directly. Under certain conditions it is possible to estimate the time of arrival to within a fraction of the sampling interval by taking the analysis to frequency domain and investigate the phases of certain spectra. However, that's a rather intricate procedure that is not guaranteed to work, so this is yet another argument for using oversampling.
> If I sample at a higher sampling rate, can I measure with greater > accuracy the arrival time of a pulse? > > However, is it correct to assume that the time-bandwidth product only > applies to resolving pulses of a certain duration and not the pulse > arrival time?
It depends on the design of the experiment. If you can control the transmitted pulse well enough you can use a matched filter to squeeze the ToA estimate down to near-optimal accuracies. Provided the transmission path is non-dispersive. However, in *seismic* experiements (as opposed to sonar experiments) one does not control the source well enough to control (or even estimate) the source wavelet. In such cases the matched filter doesn't work and the time-bandwidth product makes a mess of things. Since you specifically target dispersive propagation, there is no reason to expect the matched filter to work even if you control the source.
> So let's say that I have a seismic source and two receivers. &#4294967295;If I > perform velocity analysis using the data from the two receivers, will my > velocity analysis will be more accurate with a higher DAC sample rate?
No. Velocity analysis is a completely different cup of tea that depends on several additional factors than ToA. The accuracy of the ToA estimate doesn't affect the analysis until you have a general algorithm that works. The dispersive nature of your propagation path will mess things severely up as is. Don't spend time with hardware design prematurely. Simulate your intended wave propagation first, and see what it takes to recover the parameetrs of the input model from the simulated data. Repeat with several different sampling rates, and see what effects they have on the processing. Rune
Rune Allnor wrote:
> On 20 Jan, 19:33, Nicholas Kinar <n.ki...@usask.ca> wrote: >> Here's another question that I'm placing under this thread. >> >> Does the sampling rate of the ADC influence the accuracy with which the >> time-of-flight (TOF) of a sonar pulse can be determined? > > Not directly. Under certain conditions it is possible to estimate > the time of arrival to within a fraction of the sampling interval > by taking the analysis to frequency domain and investigate the > phases of certain spectra. However, that's a rather intricate > procedure that is not guaranteed to work, so this is yet > another argument for using oversampling. > >> If I sample at a higher sampling rate, can I measure with greater >> accuracy the arrival time of a pulse? >> >> However, is it correct to assume that the time-bandwidth product only >> applies to resolving pulses of a certain duration and not the pulse >> arrival time? > > It depends on the design of the experiment. If you can control > the transmitted pulse well enough you can use a matched filter > to squeeze the ToA estimate down to near-optimal accuracies. > Provided the transmission path is non-dispersive. > > However, in *seismic* experiements (as opposed to sonar > experiments) one does not control the source well enough to > control (or even estimate) the source wavelet. In such cases > the matched filter doesn't work and the time-bandwidth > product makes a mess of things. > > Since you specifically target dispersive propagation, there > is no reason to expect the matched filter to work even if > you control the source. > >> So let's say that I have a seismic source and two receivers. If I >> perform velocity analysis using the data from the two receivers, will my >> velocity analysis will be more accurate with a higher DAC sample rate? > > No. Velocity analysis is a completely different cup of tea that > depends on several additional factors than ToA. The accuracy > of the ToA estimate doesn't affect the analysis until you have > a general algorithm that works. The dispersive nature of your > propagation path will mess things severely up as is. > > Don't spend time with hardware design prematurely. Simulate > your intended wave propagation first, and see what it takes to > recover the parameetrs of the input model from the simulated > data. Repeat with several different sampling rates, and see > what effects they have on the processing. > > Rune
You know, this is some very good advice, Rune. Models are important in the development process and will help me understand exactly what is going on. I'm going to use a model to test the algorithms needed for my measurement system. Is there a way to generate synthetic seismic traces with spatial offset using Biot-Stoll theory? I am aware of the convolution model of a seismic trace but I am uncertain how to apply this in lossy material, and for different receivers positioned in 2-D space above the seabed. Perhaps finite-element methods are needed to solve the acoustic wave equations in 2D? A few years ago, I recall finding on the Internet a computer code which was used for generating sonar data suitable for DSP analysis. Using Google, I can't seem to find this code. I wonder if there are any sonar codes which include the basics of Biot-Stoll theory? Nicholas
On 20 Jan, 22:28, Nicholas Kinar <n.ki...@usask.ca> wrote:

> Is there a way to generate synthetic seismic traces with spatial offset > using Biot-Stoll theory? &#4294967295;I am aware of the convolution model of a > seismic trace but I am uncertain how to apply this in lossy material, > and for different receivers positioned in 2-D space above the seabed.
That's a standard modeling task. Technicalities depend a bit on geometry vs frequency bands, but this ought not to be a very big deal.
> Perhaps finite-element methods are needed to solve the acoustic wave > equations in 2D?
In the worsk case, yes. But I think it would be possible to do these sorts of things with simpler codes.
> A few years ago, I recall finding on the Internet a computer code which > was used for generating sonar data suitable for DSP analysis. &#4294967295;Using > Google, I can't seem to find this code. &#4294967295;I wonder if there are any sonar > codes which include the basics of Biot-Stoll theory?
The Biot-Stoll factors are basically dispersive loss factors in the linear Helmholz equation. There might be more to it (I don't know if the naive linear approach includes Biot's 2nd wave) but there used to be a linear acoustics model that included the Biot factors. It's been a while since I looked into those sorts of things, but I *think* it was Henrik Schmidt's OASES package, but I might be wrong. Henrik Schmidt used to be with MIT (he might still be, for all I know), but Michael Porter used to have a web page where he collected pointers to some of the important acoutstics models. Porter used to be with a univeristy in New Jersey, but he had just moved to the west coast when I left that field of work. Rune
On 20 Jan, 22:51, Rune Allnor <all...@tele.ntnu.no> wrote:
> On 20 Jan, 22:28, Nicholas Kinar <n.ki...@usask.ca> wrote:
> > A few years ago, I recall finding on the Internet a computer code which > > was used for generating sonar data suitable for DSP analysis. &#4294967295;Using > > Google, I can't seem to find this code. &#4294967295;I wonder if there are any sonar > > codes which include the basics of Biot-Stoll theory? > > The Biot-Stoll factors are basically dispersive loss factors in the > linear Helmholz equation. There might be more to it (I don't know > if the naive linear approach includes Biot's 2nd wave) but there > used to be a linear acoustics model that included the Biot factors. > It's been a while since I looked into those sorts of things, but > I *think* it was Henrik Schmidt's OASES package,
It was, and here it is: http://acoustics.mit.edu/faculty/henrik/oases.html It's been ten years since I used this package, on a UNIX computer. I have no idea if it can be used under windows. Rune
Rune Allnor wrote:
> On 20 Jan, 22:51, Rune Allnor <all...@tele.ntnu.no> wrote: >> On 20 Jan, 22:28, Nicholas Kinar <n.ki...@usask.ca> wrote: > >>> A few years ago, I recall finding on the Internet a computer code which >>> was used for generating sonar data suitable for DSP analysis. Using >>> Google, I can't seem to find this code. I wonder if there are any sonar >>> codes which include the basics of Biot-Stoll theory? >> The Biot-Stoll factors are basically dispersive loss factors in the >> linear Helmholz equation. There might be more to it (I don't know >> if the naive linear approach includes Biot's 2nd wave) but there >> used to be a linear acoustics model that included the Biot factors. >> It's been a while since I looked into those sorts of things, but >> I *think* it was Henrik Schmidt's OASES package, > > It was, and here it is: > > http://acoustics.mit.edu/faculty/henrik/oases.html > > It's been ten years since I used this package, on a UNIX > computer. I have no idea if it can be used under windows. > > Rune
Rune, first and foremost thank you once again for all of this really useful information. I don't know what I would do without all of your help. So thank you! Yes, I remember OASES. I believe that I downloaded it about six years ago, thinking that it would be useful. Since I wasn't using that particular software package at that time, I never compiled it. Apparently OASES will only run under a GNU/Linux/Unix operating system. This is not a big deal, since I prefer to do most of my number crunching and DSP under Ubuntu Linux/Debian. I find that most numerical libraries have been written for UNIX, or are easier to compile under these operating systems. I dual-boot with Windows since some of my JTAG devices and other electronics instruments (i.e. oscilloscope) will only communicate with Windows programs. Windows is also the platform of choice for my PCB layout software. I'll give the software a try, and perhaps even take a look at the source code. If there is something that needs to be modified, I'll try to roll my own version. Thanks Rune. Nicholas
Tim Wescott wrote:
> On Tue, 20 Jan 2009 18:14:13 +0000, mblume wrote: > >> Am Tue, 20 Jan 2009 08:44:30 -0800 schrieb Rune Allnor: >>>> Understandably, it is the bandwidth that is the bottleneck in this >>>> situation. Why the 5-10x oversampling rule? >>> Because it prevents users from shaving the sampling rate too close to >>> Nyquist. Making hardware and doing experiments is both time-consuming >>> and expensive, so selecting the sampling rate is a major design >>> decision that, once implemented, can not easily be revised. >>> >>> You can always add a decimation step afterwards, if the amounts of data >>> become too large to handle with 10x oversampling. If you sample at >>> 1.05x Nyquist you are stuck with no leeway. >>> >> In addition to what Rune said, you'll have to take into consideration >> that you have to filter your analog data before it is given to an A/D >> converter. This filter being analog, it is easier to have one with a >> slower roll-off. If you oversample, you can either work with the >> unncessary bigger bandwidth throughout the whole chain or decimate at >> some intermediate step. >> >> Just my 0.02$. Analog electrical engineers might want to disagree :-) >> Martin > > Nyquist didn't say that -- http://www.wescottdesign.com/articles/Sampling/ > sampling.html. Anti-alias filtering is only helpful if there is > significant alias energy to filter out, and if the action of the > filtering won't screw up your signal. So AA filtering is a great thing > for applications like audio, where your microphone can pick up > _anything_, and some of that would sound _terrible_ when it's aliased > down. But for things like control loops and characterizing pulses, it's > often best left off.
Control loops need at least 5X oversampling and often deal with inherently band-limited systems. A one-sample delay at half the sample rate amounts to a 180-degree phase shift. The same oversampling needed for decent phase margin makes the AA filter superfluous. Jerry -- Engineering is the art of making what you want from things you can get. &macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;&macr;