Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!apple!netcomsv!mcmahan
From: mcmahan@netcom.COM (Dave Mc Mahan)
Newsgroups: comp.dsp
Subject: Re: 180 deg phase shift
Message-ID: <1991May9.045343.24744@netcom.COM>
Date: 9 May 91 04:53:43 GMT
References: <1991May7.152409.3933@njitgw.njit.edu> <1991May8.022953.781@appmag.com> <102387@sgi.sgi.com>
Sender: netnews@netcom.COM (USENET Administration)
Organization: Dave McMahan @ NetCom Services
Lines: 38


 In a previous article, karsh@trifolium.sgi.com (Bruce Karsh) writes:
>In article <1991May8.022953.781@appmag.com> todd@appmag.com (Todd Day) writes:
>
>>First of all, 180 deg phase shift is not the same as simply inverting
>>the signal.  A phase shift implies a time delay of some sort.
>
>Sorry, but a phase shift need not imply a time delay.  The amount of delay
>is called the group delay and it is the slope of the graph of the delay
>function.  It's really only meaningful to think of it as a delay if the
>delay function is largely a straight line.
>
>The problem is that sine waves are periodic, so you can't really say whether
>on is delayed with respect to another, or advanced.  Since the signal
>is composed of the sum of sine waves, if you delay (or advance) all the
>sin waves by 180 degrees, then you've just inverted all their signs.  When
>you sum them all together, you get -1 times the original signal.

This works great for pure tones, but if you have a signal (such as that from
an ECG or a modem that uses phase or frequency shifting) then the input signal
will not be a pure tone, but rather a sum of sine waves that vary in
amplitude over time.  I think (just to add another voice to this mess) that
the correct 'theoretical' answer is to find a filter that actually does 
produce the proper time shift for each frequency.  The 'realistic' answer is
that this just negating the input signal (Y[n] = -X[n]) is probably what the
original poster needs to know.  Once again, I guess you have to know the
full needs of the application before you can provide the full answer.
(Is this another case where we engineers charge off to solve the wrong
 problem?  :-)

>			Bruce Karsh
>			karsh@sgi.com

  -dave

-- 
Dave McMahan                            mcmahan@netcom.com
					{apple,amdahl,claris}!netcom!mcmahan