# IIR constant phase shift network, absolute vs. relative phase

Started by 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.
```