DSPRelated.com
Forums

Envelope Detector using Hilbert Transform

Started by w106pjs July 27, 2005
All

I have been kind going through previous threads in this group on similar
concern and question that I have. Still I feel my feet is not on the
ground yet...with this issue..

Background:
I have working with ultrasound signals (300 Khz) from a solid state sensor
to a target at 3". The received signals from the sensor (300 Khz) are
digitized through a sampling card and imported into MATLAB, to preserve
the time information as precisely as possible, sampling frequency is high
Fs = 50Mhz.
To generate a envelope on the 300Khz received echo, conventional magnitude
of the analytic is used in MATLAB.

Envelope = abs(hilbert(echo_signal));
It works as expected. and then rest of the processing continues on the
envelope signal.

Question and Concern: 
1. What should be an alternative approach to acheive the same. ?
Say FIR hilbert transformer, All pass IIR design..
With sampling frequency this high, my fear is FIR may generate real higher
length filter.Correct me If I am wrong!!

2. Hilbert function in MATLAB works using the FFT and IFFT approach.What
approach should be more efficient in terms of implementing it in real time
on the DSP processor.

thanks in advance.
Paul







		
This message was sent using the Comp.DSP web interface on
www.DSPRelated.com
"w106pjs" <w106pjs@yahoo.com> wrote in
news:9fGdnTz2ELZZLnrfRVn-tQ@giganews.com: 

> All > > I have been kind going through previous threads in this group on > similar concern and question that I have. Still I feel my feet is not > on the ground yet...with this issue.. > > Background: > I have working with ultrasound signals (300 Khz) from a solid state > sensor to a target at 3". The received signals from the sensor (300 > Khz) are digitized through a sampling card and imported into MATLAB, > to preserve the time information as precisely as possible, sampling > frequency is high Fs = 50Mhz. > To generate a envelope on the 300Khz received echo, conventional > magnitude of the analytic is used in MATLAB. > > Envelope = abs(hilbert(echo_signal)); > It works as expected. and then rest of the processing continues on the > envelope signal. > > Question and Concern: > 1. What should be an alternative approach to acheive the same. ? > Say FIR hilbert transformer, All pass IIR design.. > With sampling frequency this high, my fear is FIR may generate real > higher length filter.Correct me If I am wrong!! > > 2. Hilbert function in MATLAB works using the FFT and IFFT > approach.What approach should be more efficient in terms of > implementing it in real time on the DSP processor. > > thanks in advance. > Paul >
I'm not sure why you need to oversample by so much, so I will only comment on the hilbert implementation. The easiest way to do a hilbert transform is to use an odd length anti symmetric FIR filter. I generally use a Parks McClelland (remez exchange) fit for the filter to make the passband ripple small. The fir filter is a bandpass filter. It doesn't need to be very long if the signal of interest is not too close to DC. If you are sampling at 50MHz, and the signal is a 300k, you are close to DC, so the filter will be fairly long. Sample at a few MHz, and the filter will be very easy to implement on a DSP. You get the real output from the center tap of the same delay line that is used for the imaginary part. Rick Lyon's book: Understanding Digital Signal Processing ( 2nd edition) explains this approach. Marvin Frerking's book: Digital Signal Processing for Communication Systems is another excellent reference (but very hard to find). The envelope is the SQRT (r^2 + i^2). This is easy to implemt on a SHARC or similiar floating point DSP. We have boards that can do this application. -- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.com
>"w106pjs" <w106pjs@yahoo.com> wrote in >news:9fGdnTz2ELZZLnrfRVn-tQ@giganews.com: > >> All >> >> I have been kind going through previous threads in this group on >> similar concern and question that I have. Still I feel my feet is not >> on the ground yet...with this issue.. >> >> Background: >> I have working with ultrasound signals (300 Khz) from a solid state >> sensor to a target at 3". The received signals from the sensor (300 >> Khz) are digitized through a sampling card and imported into MATLAB, >> to preserve the time information as precisely as possible, sampling >> frequency is high Fs = 50Mhz. >> To generate a envelope on the 300Khz received echo, conventional >> magnitude of the analytic is used in MATLAB. >> >> Envelope = abs(hilbert(echo_signal)); >> It works as expected. and then rest of the processing continues on the >> envelope signal. >> >> Question and Concern: >> 1. What should be an alternative approach to acheive the same. ? >> Say FIR hilbert transformer, All pass IIR design.. >> With sampling frequency this high, my fear is FIR may generate real >> higher length filter.Correct me If I am wrong!! >> >> 2. Hilbert function in MATLAB works using the FFT and IFFT >> approach.What approach should be more efficient in terms of >> implementing it in real time on the DSP processor. >> >> thanks in advance. >> Paul >> > >I'm not sure why you need to oversample by so much, so I will only >comment on the hilbert implementation. > >The easiest way to do a hilbert transform is to use an odd length anti >symmetric FIR filter. I generally use a Parks McClelland (remez exchange)
>fit for the filter to make the passband ripple small. > >The fir filter is a bandpass filter. It doesn't need to be very long if >the signal of interest is not too close to DC. If you are sampling at >50MHz, and the signal is a 300k, you are close to DC, so the filter will
>be fairly long. Sample at a few MHz, and the filter will be very easy to
>implement on a DSP. > >You get the real output from the center tap of the same delay line that >is used for the imaginary part. > >Rick Lyon's book: Understanding Digital Signal Processing ( 2nd edition)
>explains this approach. Marvin Frerking's book: Digital Signal Processing
>for Communication Systems is another excellent reference (but very hard >to find). > >The envelope is the SQRT (r^2 + i^2). This is easy to implemt on a SHARC
>or similiar floating point DSP. > >We have boards that can do this application. > > >-- >Al Clark >Danville Signal Processing, Inc. >-------------------------------------------------------------------- >Purveyors of Fine DSP Hardware and other Cool Stuff >Available at http://www.danvillesignal.com >
Al Clark Thank you for your prompt reply. 1. The reason it is oversampled by a significant amount is to preserve the time resolution in the application. The DSP algorithm is being used to precisely measure the time of flight for the ultrasound signal through air which demands high resolution. Sampling at a low rate and interpolating for better resolution was experimented with very little sucess compared to oversampled routine. 2. Since 300K is not what signal of interest @ Fs=50 Mhz, the lenght would certainly be large, does it become really impractical to implement on the real hardware. Is IIR filters (All pass filters) would be of any help in this case. What band edges would you recommend for FIR BP filter. thanks again. Paul This message was sent using the Comp.DSP web interface on www.DSPRelated.com
"w106pjs" <w106pjs@yahoo.com> wrote in
news:eIOdnTdh47fuVHrfRVn-ow@giganews.com: 

>>"w106pjs" <w106pjs@yahoo.com> wrote in >>news:9fGdnTz2ELZZLnrfRVn-tQ@giganews.com: >> >>> All >>> >>> I have been kind going through previous threads in this group on >>> similar concern and question that I have. Still I feel my feet is >>> not on the ground yet...with this issue.. >>> >>> Background: >>> I have working with ultrasound signals (300 Khz) from a solid state >>> sensor to a target at 3". The received signals from the sensor (300 >>> Khz) are digitized through a sampling card and imported into MATLAB, >>> to preserve the time information as precisely as possible, sampling >>> frequency is high Fs = 50Mhz. >>> To generate a envelope on the 300Khz received echo, conventional >>> magnitude of the analytic is used in MATLAB. >>> >>> Envelope = abs(hilbert(echo_signal)); >>> It works as expected. and then rest of the processing continues on >>> the envelope signal. >>> >>> Question and Concern: >>> 1. What should be an alternative approach to acheive the same. ? >>> Say FIR hilbert transformer, All pass IIR design.. >>> With sampling frequency this high, my fear is FIR may generate real >>> higher length filter.Correct me If I am wrong!! >>> >>> 2. Hilbert function in MATLAB works using the FFT and IFFT >>> approach.What approach should be more efficient in terms of >>> implementing it in real time on the DSP processor. >>> >>> thanks in advance. >>> Paul >>> >> >>I'm not sure why you need to oversample by so much, so I will only >>comment on the hilbert implementation. >> >>The easiest way to do a hilbert transform is to use an odd length anti >>symmetric FIR filter. I generally use a Parks McClelland (remez >>exchange) > >>fit for the filter to make the passband ripple small. >> >>The fir filter is a bandpass filter. It doesn't need to be very long >>if the signal of interest is not too close to DC. If you are sampling >>at 50MHz, and the signal is a 300k, you are close to DC, so the filter >>will > >>be fairly long. Sample at a few MHz, and the filter will be very easy >>to > >>implement on a DSP. >> >>You get the real output from the center tap of the same delay line >>that is used for the imaginary part. >> >>Rick Lyon's book: Understanding Digital Signal Processing ( 2nd >>edition) > >>explains this approach. Marvin Frerking's book: Digital Signal >>Processing > >>for Communication Systems is another excellent reference (but very >>hard to find). >> >>The envelope is the SQRT (r^2 + i^2). This is easy to implemt on a >>SHARC > >>or similiar floating point DSP. >> >>We have boards that can do this application. >> >> >>-- >>Al Clark >>Danville Signal Processing, Inc. >>-------------------------------------------------------------------- >>Purveyors of Fine DSP Hardware and other Cool Stuff >>Available at http://www.danvillesignal.com >> > > Al Clark > > Thank you for your prompt reply. > 1. The reason it is oversampled by a significant amount is to > preserve the time resolution in the application. The DSP algorithm is > being used to precisely measure the time of flight for the ultrasound > signal through air which demands high resolution. Sampling at a low > rate and interpolating for better resolution was experimented with > very little sucess compared to oversampled routine. > > 2. Since 300K is not what signal of interest @ Fs=50 Mhz, the lenght > would certainly be large, does it become really impractical to > implement on the real hardware. > Is IIR filters (All pass filters) would be of any help in this case. > What band edges would you recommend for FIR BP filter. > > thanks again. > Paul > > > This message was sent using the Comp.DSP web interface on > www.DSPRelated.com >
I think I am going to get myself in trouble, but here goes: Is the ultrasonic sensors transmitting at 300kHz and you are trying to recover a reflection? It seems to me you will have an uncertainty due to the wavelength of 300kHz since BT >= 1 (bandwidth time product). I don't see how oversampling by approximately 167/1 is going to provide additional resolution. Assuming air: sound travels at 344m/s You have a spatial resolution of 344m/300k = 1.146mm I think you achieve the same answer sampling at 2MHz as sampling at 50MHz. This isn't really my area of expertise. Someone should jump in a clarify all of this, please. -- Al Clark Danville Signal Processing, Inc. -------------------------------------------------------------------- Purveyors of Fine DSP Hardware and other Cool Stuff Available at http://www.danvillesignal.com

w106pjs wrote:
> All > > I have been kind going through previous threads in this group on similar > concern and question that I have. Still I feel my feet is not on the > ground yet...with this issue.. > > Background: > I have working with ultrasound signals (300 Khz) from a solid state sensor > to a target at 3". The received signals from the sensor (300 Khz) are > digitized through a sampling card and imported into MATLAB, to preserve > the time information as precisely as possible, sampling frequency is high > Fs = 50Mhz. > To generate a envelope on the 300Khz received echo, conventional magnitude > of the analytic is used in MATLAB. > > Envelope = abs(hilbert(echo_signal)); > It works as expected. and then rest of the processing continues on the > envelope signal. > > Question and Concern: > 1. What should be an alternative approach to acheive the same. ? > Say FIR hilbert transformer, All pass IIR design.. > With sampling frequency this high, my fear is FIR may generate real higher > length filter.Correct me If I am wrong!! > > 2. Hilbert function in MATLAB works using the FFT and IFFT approach.What > approach should be more efficient in terms of implementing it in real time > on the DSP processor.
Let's see, 300kHz/50MHz = 0.006. That's a serious amout of oversampling. 3" = 8 cm, the medium is air... What kind of application is this? How much noise is present in the data? How stable is the temperature, humidity and wind in the air where you make your measurements? To take the "half-easy" part first, Rick Lyons mentioned a couple of months ago that somebody had submitted a Hilbert transformer to his "DSP Tricks" column in IEEE Signal Processing Magazine. The "new" stuff with this Hilbert transformer was that it was supposed to be reliable for seriously oversampled signals, like the ones you have. If you are lucky, Rick is lurking here and may perhaps let you know when the article is published. The second concern, is whether the very accurate timing information you get, is useful. Remember, the sound velocity in air depends on lots of factors (humidity, temperature, wind, atmospheric pressure). You ought to be a ware that any very-fine-scale variations you observe in your measurements *could* be due to such factors, and not necessarily the physical distance you try to measure. Rune
> > >w106pjs wrote: >> All >> >> I have been kind going through previous threads in this group on
similar
>> concern and question that I have. Still I feel my feet is not on the >> ground yet...with this issue.. >> >> Background: >> I have working with ultrasound signals (300 Khz) from a solid state
sensor
>> to a target at 3". The received signals from the sensor (300 Khz) are >> digitized through a sampling card and imported into MATLAB, to
preserve
>> the time information as precisely as possible, sampling frequency is
high
>> Fs = 50Mhz. >> To generate a envelope on the 300Khz received echo, conventional
magnitude
>> of the analytic is used in MATLAB. >> >> Envelope = abs(hilbert(echo_signal)); >> It works as expected. and then rest of the processing continues on the >> envelope signal. >> >> Question and Concern: >> 1. What should be an alternative approach to acheive the same. ? >> Say FIR hilbert transformer, All pass IIR design.. >> With sampling frequency this high, my fear is FIR may generate real
higher
>> length filter.Correct me If I am wrong!! >> >> 2. Hilbert function in MATLAB works using the FFT and IFFT
approach.What
>> approach should be more efficient in terms of implementing it in real
time
>> on the DSP processor. > >Let's see, 300kHz/50MHz = 0.006. > >That's a serious amout of oversampling. 3" = 8 cm, the medium is air... > >What kind of application is this? How much noise is present in the >data? How stable is the temperature, humidity and wind in the air >where you make your measurements? > >To take the "half-easy" part first, Rick Lyons mentioned a couple of >months ago that somebody had submitted a Hilbert transformer to his >"DSP Tricks" column in IEEE Signal Processing Magazine. The "new" >stuff with this Hilbert transformer was that it was supposed to be >reliable for seriously oversampled signals, like the ones you have. >If you are lucky, Rick is lurking here and may perhaps let you know >when the article is published. > >The second concern, is whether the very accurate timing information >you get, is useful. Remember, the sound velocity in air depends >on lots of factors (humidity, temperature, wind, atmospheric >pressure). You ought to be a ware that any very-fine-scale variations >you observe in your measurements *could* be due to such factors, and >not necessarily the physical distance you try to measure. > >Rune >
Rune , Al Clark I have been thnking about this problem with a different perspective.. Say the target is at 3.000". What if you intend to measure the a target movement of +/- 0.001" or less.. i.e target displacement from 2.999" - 3.001" or so.. the time resolution you would need should be better than the change in the time of flight to the target.. I realise the effect of change in Temperature, RH, Pressure.. wind turbulence...and other factors.. Let me.. know ... what you think about this.. I have been hearing about the article you mentioned in the previous threads... does... someone.. has a copy of that article... Also please share some more thoughts on the hilbert transformer.. implementation in MATLAB... Thanks Paul This message was sent using the Comp.DSP web interface on www.DSPRelated.com
w106pjs wrote:
>> >>w106pjs wrote:
...
>>Let's see, 300kHz/50MHz = 0.006. >> >>That's a serious amout of oversampling. 3" = 8 cm, the medium is air... >> >>What kind of application is this? How much noise is present in the >>data? How stable is the temperature, humidity and wind in the air >>where you make your measurements? >> >>To take the "half-easy" part first, Rick Lyons mentioned a couple of >>months ago that somebody had submitted a Hilbert transformer to his >>"DSP Tricks" column in IEEE Signal Processing Magazine. The "new" >>stuff with this Hilbert transformer was that it was supposed to be >>reliable for seriously oversampled signals, like the ones you have. >>If you are lucky, Rick is lurking here and may perhaps let you know >>when the article is published. >> >>The second concern, is whether the very accurate timing information >>you get, is useful. Remember, the sound velocity in air depends >>on lots of factors (humidity, temperature, wind, atmospheric >>pressure). You ought to be a ware that any very-fine-scale variations >>you observe in your measurements *could* be due to such factors, and >>not necessarily the physical distance you try to measure. >> >>Rune >> > > > Rune , Al Clark > > I have been thnking about this problem with a different perspective.. > > Say the target is at 3.000". > What if you intend to measure the a target movement of +/- 0.001" or > less.. > i.e target displacement from 2.999" - 3.001" or so.. > the time resolution you would need should be better than the change in the > time of flight to the target..
I think you -- to quote my President -- misunderestimate how much faster than sound light is.
> I realise the effect of change in Temperature, RH, Pressure.. wind > turbulence...and other factors.. > Let me.. know ... what you think about this.. > I have been hearing about the article you mentioned in the previous > threads... does... someone.. has a copy of that article... > > Also please share some more thoughts on the hilbert transformer.. > implementation in MATLAB...
The square root of Re^2 + Im^2 (with Im possibly computed using a Hilbert transformer) gives the envelope even when few samples are taken near the peaks of the waveform. With a continuous waveform, a simple peak detector is enough. You are so heavily oversampling that a peak detector should work for you just fine. I doubt that the oversampling will do you much good aside from that, but you might as well benefit from it that way. Jerry -- Engineering is the art of making what you want from things you can get. &#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;
>w106pjs wrote: >>> >>>w106pjs wrote: > > > ... > >>>Let's see, 300kHz/50MHz = 0.006. >>> >>>That's a serious amout of oversampling. 3" = 8 cm, the medium is
air...
>>> >>>What kind of application is this? How much noise is present in the >>>data? How stable is the temperature, humidity and wind in the air >>>where you make your measurements? >>> >>>To take the "half-easy" part first, Rick Lyons mentioned a couple of >>>months ago that somebody had submitted a Hilbert transformer to his >>>"DSP Tricks" column in IEEE Signal Processing Magazine. The "new" >>>stuff with this Hilbert transformer was that it was supposed to be >>>reliable for seriously oversampled signals, like the ones you have. >>>If you are lucky, Rick is lurking here and may perhaps let you know >>>when the article is published. >>> >>>The second concern, is whether the very accurate timing information >>>you get, is useful. Remember, the sound velocity in air depends >>>on lots of factors (humidity, temperature, wind, atmospheric >>>pressure). You ought to be a ware that any very-fine-scale variations >>>you observe in your measurements *could* be due to such factors, and >>>not necessarily the physical distance you try to measure. >>> >>>Rune >>> >> >> >> Rune , Al Clark >> >> I have been thnking about this problem with a different perspective.. >> >> Say the target is at 3.000". >> What if you intend to measure the a target movement of +/- 0.001" or >> less.. >> i.e target displacement from 2.999" - 3.001" or so.. >> the time resolution you would need should be better than the change in
the
>> time of flight to the target.. > >I think you -- to quote my President -- misunderestimate how much faster
>than sound light is. > >> I realise the effect of change in Temperature, RH, Pressure.. wind >> turbulence...and other factors.. >> Let me.. know ... what you think about this.. >> I have been hearing about the article you mentioned in the previous >> threads... does... someone.. has a copy of that article... >> >> Also please share some more thoughts on the hilbert transformer.. >> implementation in MATLAB... > >The square root of Re^2 + Im^2 (with Im possibly computed using a >Hilbert transformer) gives the envelope even when few samples are taken >near the peaks of the waveform. With a continuous waveform, a simple >peak detector is enough. You are so heavily oversampling that a peak >detector should work for you just fine. I doubt that the oversampling >will do you much good aside from that, but you might as well benefit >from it that way. > >Jerry >-- >Engineering is the art of making what you want from things you can get.
>&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295;&#4294967295; >
Jerry Sorry for getting everybody offtrack....I guess my concern for resolving implementation of hilbert transformer still remains ... How would the transofmer.be implemented in MATLAB ? Please share some thoughts... and possibly recommend any good literature as well.. Thanks Paul This message was sent using the Comp.DSP web interface on www.DSPRelated.com