Forums

IIR constant phase shift network, absolute vs. relative phase

Started by bitrex July 19, 2019
In the Hilbert transformer-based phase shifting network implementation
a la:

<https://www.dsprelated.com/showarticle/1147.php>

They measure the shift of the final y output as a relative phase with 
respect to the I output of the digital Hilbert transformer.

It looks like it's possible to also make an absolute phase shift with 
respect to the input signal to the transformer by adjusting the 
coefficients for the I/Q multiplier stage and reducing the calculated 
shift in proportion to the number of delay taps in the transformer, yes?
On 7/19/19 8:08 PM, bitrex wrote:
> In the Hilbert transformer-based phase shifting network implementation > a la:
Sorry, I meant FIR in the title, not "IIR."
On Friday, July 19, 2019 at 5:08:21 PM UTC-7, bitrex wrote:
> In the Hilbert transformer-based phase shifting network implementation > a la: > > <https://www.dsprelated.com/showarticle/1147.php> > > They measure the shift of the final y output as a relative phase with > respect to the I output of the digital Hilbert transformer. > > It looks like it's possible to also make an absolute phase shift with > respect to the input signal to the transformer...
Yes, but the sampling theorem applies; it's only an absolute phase shift when the Hilbert coefficients are adequate for resolving the signal. With 2 coefficients, the filter could do an absolute TIME shift, which is different phase for all frequencies; going to 16 coefficients can get absolute phase shft over more range, with spurious outputs only outside the carrier-plus-modulation bandwidth that one ends up using. If I'm reading the math correctly, you want to have an eight-cycle delay (latency) in the I path to match the FIR because H-transformer output has eight samples of nominally 'future' data on which it depends.
On Fri, 19 Jul 2019 20:08:16 -0400, bitrex <user@example.net> wrote:

>In the Hilbert transformer-based phase shifting network implementation >a la: > ><https://www.dsprelated.com/showarticle/1147.php> > >They measure the shift of the final y output as a relative phase with >respect to the I output of the digital Hilbert transformer. > >It looks like it's possible to also make an absolute phase shift with >respect to the input signal to the transformer by adjusting the >coefficients for the I/Q multiplier stage and reducing the calculated >shift in proportion to the number of delay taps in the transformer, yes?
In fig 2, given an I and Q output from the phase-shift network, one can rotate the output any desired angle. That's high-school trig. The problem is the "Hilbert", whose relative phase output is 90 degrees but the absolute phases squirm as a function of frequency. An actual Hilbert transform box would output true 0 and 90 relative to the input at all frequencies. Unfortunately, a true Hilbert transform is non-causal hence impossible to make. An FIR approximation to the Hilbert transform adds time delay, which wrecks the phase shifts. It's like trying to simulate an ideal lowpass filter: the better the filter response, the longer the time delay. There are lots of ways to make a network that shifts phase a programmable amount, but the programming has to change as a function of frequency. A variable delay line will do that too. We recently finished up an all-analog dual IQ modulator box that our user programs by putting in I and Q as DC levels (actually waveforms) from one of our 4-channel ARBs. It only works at one frequency, so the "Hilbert" is just two RCs, one a 45 degree lead and one a 45 lag. -- John Larkin Highland Technology, Inc lunatic fringe electronics
On 7/20/19 11:56 AM, John Larkin wrote:
> On Fri, 19 Jul 2019 20:08:16 -0400, bitrex <user@example.net> wrote: > >> In the Hilbert transformer-based phase shifting network implementation >> a la: >> >> <https://www.dsprelated.com/showarticle/1147.php> >> >> They measure the shift of the final y output as a relative phase with >> respect to the I output of the digital Hilbert transformer. >> >> It looks like it's possible to also make an absolute phase shift with >> respect to the input signal to the transformer by adjusting the >> coefficients for the I/Q multiplier stage and reducing the calculated >> shift in proportion to the number of delay taps in the transformer, yes? > > In fig 2, given an I and Q output from the phase-shift network, one > can rotate the output any desired angle. > > That's high-school trig. The problem is the "Hilbert", whose relative > phase output is 90 degrees but the absolute phases squirm as a > function of frequency.
Ok, I think I have it. So I can have a relative phase shift between the I output and the Y output of e.g. 90 degrees over some bandwidth, but the y output will shift in absolute phase as a function of frequency wrt the input signal. If I wanted otherwise I'd have to dynamically adjust the HT delay line coefficients.
> An actual Hilbert transform box would output true 0 and 90 relative to > the input at all frequencies. Unfortunately, a true Hilbert transform > is non-causal hence impossible to make. An FIR approximation to the > Hilbert transform adds time delay, which wrecks the phase shifts. It's > like trying to simulate an ideal lowpass filter: the better the filter > response, the longer the time delay.
As I understand it how good an approximation the constant relative phase shift is between the I and y outputs, and what bandwidth, depends on how many taps (and hence delay) you're willing to put into the transformer. Since the HT kernel is infinite you have to window it somehow which leads to ripple in the constant-phase pass band and the Gibbs phenomena at the edges, etc. Fortunately Matlab/Octave provides design tools for that
> There are lots of ways to make a network that shifts phase a > programmable amount, but the programming has to change as a function > of frequency. A variable delay line will do that too. > > We recently finished up an all-analog dual IQ modulator box that our > user programs by putting in I and Q as DC levels (actually waveforms) > from one of our 4-channel ARBs. It only works at one frequency, so the > "Hilbert" is just two RCs, one a 45 degree lead and one a 45 lag.
The client would like a constant 90 degree phase shift over about an octave of the telephone voice band, 300-3kHz, and would prefer digital implementation. If they're OK with a delayed relative shift and not absolute sounds like it should be feasible, the DSP API they're using supports an enormous number of taps in its FIR building-block. If they must have an absolute phase shift then it sounds like a tough row to hoe.
On Sat, 20 Jul 2019 12:46:41 -0400, bitrex <user@example.net> wrote:

>On 7/20/19 11:56 AM, John Larkin wrote: >> On Fri, 19 Jul 2019 20:08:16 -0400, bitrex <user@example.net> wrote: >> >>> In the Hilbert transformer-based phase shifting network implementation >>> a la: >>> >>> <https://www.dsprelated.com/showarticle/1147.php> >>> >>> They measure the shift of the final y output as a relative phase with >>> respect to the I output of the digital Hilbert transformer. >>> >>> It looks like it's possible to also make an absolute phase shift with >>> respect to the input signal to the transformer by adjusting the >>> coefficients for the I/Q multiplier stage and reducing the calculated >>> shift in proportion to the number of delay taps in the transformer, yes? >> >> In fig 2, given an I and Q output from the phase-shift network, one >> can rotate the output any desired angle. >> >> That's high-school trig. The problem is the "Hilbert", whose relative >> phase output is 90 degrees but the absolute phases squirm as a >> function of frequency. > >Ok, I think I have it. So I can have a relative phase shift between the >I output and the Y output of e.g. 90 degrees over some bandwidth, but >the y output will shift in absolute phase as a function of frequency wrt >the input signal.
Right. The analog all-pass works the same way. One network has a sloping, slightly wiggly phase-frequency response. A second one is the same but offset a bit. The difference is close to 90 degrees over some frequency range. It's impressive: you can get about 1 degree max error over an 80:1 frequency with just 6 opamps. See the Williams book 3e, sec 7.5.
> >If I wanted otherwise I'd have to dynamically adjust the HT delay line >coefficients. > >> An actual Hilbert transform box would output true 0 and 90 relative to >> the input at all frequencies. Unfortunately, a true Hilbert transform >> is non-causal hence impossible to make. An FIR approximation to the >> Hilbert transform adds time delay, which wrecks the phase shifts. It's >> like trying to simulate an ideal lowpass filter: the better the filter >> response, the longer the time delay. >As I understand it how good an approximation the constant relative phase >shift is between the I and y outputs, and what bandwidth, depends on how >many taps (and hence delay) you're willing to put into the transformer. >Since the HT kernel is infinite you have to window it somehow which >leads to ripple in the constant-phase pass band and the Gibbs phenomena >at the edges, etc.
I think the two legs of the phase shifter can be designed to wiggle a bit, like designing a Chebychev filter.
> >Fortunately Matlab/Octave provides design tools for that > >> There are lots of ways to make a network that shifts phase a >> programmable amount, but the programming has to change as a function >> of frequency. A variable delay line will do that too. >> >> We recently finished up an all-analog dual IQ modulator box that our >> user programs by putting in I and Q as DC levels (actually waveforms) >> from one of our 4-channel ARBs. It only works at one frequency, so the >> "Hilbert" is just two RCs, one a 45 degree lead and one a 45 lag. > >The client would like a constant 90 degree phase shift over about an >octave of the telephone voice band, 300-3kHz, and would prefer digital >implementation. If they're OK with a delayed relative shift and not >absolute sounds like it should be feasible, the DSP API they're using >supports an enormous number of taps in its FIR building-block. >
11:1 frequency and 1.3 degree error takes four opamps! No ADCs, no DACs.
>If they must have an absolute phase shift then it sounds like a tough >row to hoe.
Yeah, causality sucks. -- John Larkin Highland Technology, Inc lunatic fringe electronics
On 7/20/19 1:53 AM, whit3rd wrote:
> On Friday, July 19, 2019 at 5:08:21 PM UTC-7, bitrex wrote: >> In the Hilbert transformer-based phase shifting network implementation >> a la: >> >> <https://www.dsprelated.com/showarticle/1147.php> >> >> They measure the shift of the final y output as a relative phase with >> respect to the I output of the digital Hilbert transformer. >> >> It looks like it's possible to also make an absolute phase shift with >> respect to the input signal to the transformer... > > Yes, but the sampling theorem applies; it's only an absolute phase shift > when the Hilbert coefficients are adequate for resolving the signal. > With 2 coefficients, the filter could do an absolute TIME shift, which > is different phase for all frequencies; going to 16 coefficients can > get absolute phase shft over more range, with spurious outputs only > outside the carrier-plus-modulation bandwidth that one ends up using. > > If I'm reading the math correctly, you want to have an eight-cycle > delay (latency) in the I path to match the FIR because H-transformer > output has eight samples of nominally 'future' data on which it depends. >
Hilbert transform filters (constant 90 degree phase shift) only work well on fairly narrow-band signals. The trouble is that there's an infinite singularity at DC, and the long high-frequency tail also has infinite energy. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
On 7/20/19 11:56 AM, John Larkin wrote:
> On Fri, 19 Jul 2019 20:08:16 -0400, bitrex <user@example.net> wrote: > >> In the Hilbert transformer-based phase shifting network implementation >> a la: >> >> <https://www.dsprelated.com/showarticle/1147.php> >> >> They measure the shift of the final y output as a relative phase with >> respect to the I output of the digital Hilbert transformer. >> >> It looks like it's possible to also make an absolute phase shift with >> respect to the input signal to the transformer by adjusting the >> coefficients for the I/Q multiplier stage and reducing the calculated >> shift in proportion to the number of delay taps in the transformer, yes? > > In fig 2, given an I and Q output from the phase-shift network, one > can rotate the output any desired angle. > > That's high-school trig. The problem is the "Hilbert", whose relative > phase output is 90 degrees but the absolute phases squirm as a > function of frequency. > > An actual Hilbert transform box would output true 0 and 90 relative to > the input at all frequencies. Unfortunately, a true Hilbert transform > is non-causal hence impossible to make. An FIR approximation to the > Hilbert transform adds time delay, which wrecks the phase shifts. It's > like trying to simulate an ideal lowpass filter: the better the filter > response, the longer the time delay. > > There are lots of ways to make a network that shifts phase a > programmable amount, but the programming has to change as a function > of frequency. A variable delay line will do that too. > > We recently finished up an all-analog dual IQ modulator box that our > user programs by putting in I and Q as DC levels (actually waveforms) > from one of our 4-channel ARBs. It only works at one frequency, so the > "Hilbert" is just two RCs, one a 45 degree lead and one a 45 lag. > >
Sometimes punting on the fancy stuff is a big win. Cheers Phil Hobbs -- Dr Philip C D Hobbs Principal Consultant ElectroOptical Innovations LLC / Hobbs ElectroOptics Optics, Electro-optics, Photonics, Analog Electronics Briarcliff Manor NY 10510 http://electrooptical.net http://hobbs-eo.com
On 7/20/19 5:34 PM, John Larkin wrote:
> On Sat, 20 Jul 2019 12:46:41 -0400, bitrex <user@example.net> wrote: > >> On 7/20/19 11:56 AM, John Larkin wrote: >>> On Fri, 19 Jul 2019 20:08:16 -0400, bitrex <user@example.net> wrote: >>> >>>> In the Hilbert transformer-based phase shifting network implementation >>>> a la: >>>> >>>> <https://www.dsprelated.com/showarticle/1147.php> >>>> >>>> They measure the shift of the final y output as a relative phase with >>>> respect to the I output of the digital Hilbert transformer. >>>> >>>> It looks like it's possible to also make an absolute phase shift with >>>> respect to the input signal to the transformer by adjusting the >>>> coefficients for the I/Q multiplier stage and reducing the calculated >>>> shift in proportion to the number of delay taps in the transformer, yes? >>> >>> In fig 2, given an I and Q output from the phase-shift network, one >>> can rotate the output any desired angle. >>> >>> That's high-school trig. The problem is the "Hilbert", whose relative >>> phase output is 90 degrees but the absolute phases squirm as a >>> function of frequency. >> >> Ok, I think I have it. So I can have a relative phase shift between the >> I output and the Y output of e.g. 90 degrees over some bandwidth, but >> the y output will shift in absolute phase as a function of frequency wrt >> the input signal. > > Right. The analog all-pass works the same way. One network has a > sloping, slightly wiggly phase-frequency response. A second one is the > same but offset a bit. The difference is close to 90 degrees over some > frequency range. It's impressive: you can get about 1 degree max error > over an 80:1 frequency with just 6 opamps. See the Williams book 3e, > sec 7.5. > > > > > > > > > >> >> If I wanted otherwise I'd have to dynamically adjust the HT delay line >> coefficients. >> >>> An actual Hilbert transform box would output true 0 and 90 relative to >>> the input at all frequencies. Unfortunately, a true Hilbert transform >>> is non-causal hence impossible to make. An FIR approximation to the >>> Hilbert transform adds time delay, which wrecks the phase shifts. It's >>> like trying to simulate an ideal lowpass filter: the better the filter >>> response, the longer the time delay. >> As I understand it how good an approximation the constant relative phase >> shift is between the I and y outputs, and what bandwidth, depends on how >> many taps (and hence delay) you're willing to put into the transformer. >> Since the HT kernel is infinite you have to window it somehow which >> leads to ripple in the constant-phase pass band and the Gibbs phenomena >> at the edges, etc. > > I think the two legs of the phase shifter can be designed to wiggle a > bit, like designing a Chebychev filter. > > > > >> >> Fortunately Matlab/Octave provides design tools for that >> >>> There are lots of ways to make a network that shifts phase a >>> programmable amount, but the programming has to change as a function >>> of frequency. A variable delay line will do that too. >>> >>> We recently finished up an all-analog dual IQ modulator box that our >>> user programs by putting in I and Q as DC levels (actually waveforms) >>> from one of our 4-channel ARBs. It only works at one frequency, so the >>> "Hilbert" is just two RCs, one a 45 degree lead and one a 45 lag. >> >> The client would like a constant 90 degree phase shift over about an >> octave of the telephone voice band, 300-3kHz, and would prefer digital >> implementation. If they're OK with a delayed relative shift and not >> absolute sounds like it should be feasible, the DSP API they're using >> supports an enormous number of taps in its FIR building-block. >> > > 11:1 frequency and 1.3 degree error takes four opamps! No ADCs, no > DACs.
Yeah I tried to sell 'em on that route, not interested. it's an mod to some already extant ADC + DSP solution that also does EQ and dynamic range compression talking about analog daughterboards doesn't seem to win many hearts and minds, however straightforward they may be.
>> If they must have an absolute phase shift then it sounds like a tough >> row to hoe. > > Yeah, causality sucks. > >
If they must have closer to being able to read the future than digital can provide in this case they'll go for the analog solution I expect they won't have a choice
On 7/20/19 6:45 PM, Phil Hobbs wrote:
> On 7/20/19 1:53 AM, whit3rd wrote: >> On Friday, July 19, 2019 at 5:08:21 PM UTC-7, bitrex wrote: >>> In the Hilbert transformer-based phase shifting network implementation >>> a la: >>> >>> <https://www.dsprelated.com/showarticle/1147.php> >>> >>> They measure the shift of the final y output as a relative phase with >>> respect to the I output of the digital Hilbert transformer. >>> >>> It looks like it's possible to also make an absolute phase shift with >>> respect to the input signal to the transformer... >> >> Yes, but the sampling theorem applies; it's only an absolute phase shift >> when the Hilbert coefficients are adequate for resolving the signal. >> With 2 coefficients, the filter could do an absolute TIME shift, which >> is different phase for all frequencies; going to 16 coefficients can >> get absolute phase shft over more range, with spurious outputs only >> outside the carrier-plus-modulation bandwidth that one ends up using. >> >> If I'm reading the math correctly, you want to have an eight-cycle >> delay (latency) in the I path to match the FIR because H-transformer >> output&nbsp; has eight samples of nominally 'future' data on which it depends. >> > > Hilbert transform filters (constant 90 degree phase shift) only work > well on fairly narrow-band signals.&nbsp; The trouble is that there's an > infinite singularity at DC, and the long high-frequency tail also has > infinite energy. > > Cheers > > Phil Hobbs >
So I'm still a little unclear on how the number of taps/coefficients in the FIR Hilbert transformer affects the performance vis a vis relative phase error in-band between the I and Y outputs, and absolute phase error between the Y output and the input signal. Probably time to just fire up Matlab and experiment and look at the plots.