Thread Subject:

HELP: how do I correctly apply a phase shift to a waveform?

In a system simulation that I've been working on I am unsuccessfully attempting to apply a uniform
phase shift to a non-periodic waveform. What I've tried to do is take the Fourier transform of the
signal, apply an offset to the phase and then take the inverse transform of that. I thought the output
of this process should be my original waveform with all of its frequency components delayed by the same
number of radians (different amounts of time). However, I am not getting this result. I've tried this
in both LabVIEW and Matlab. Here's a Matlab implementation using a sine wave as the input:

t = [0:pi/128:4*pi];
x = sin(t);
X = fft(x);
MX = abs(X);
AX = angle(X);
UAX = unwrap(AX) - pi/2;
Y = MX .* exp(j*UAX);
y = ifft(Y);
plot(real(y));

I've observed that with no phase offset the imaginary part of y is zero and the real part is
a replica of x. However, when I apply a phase offset (pi/2 in the above example) the imaginary
part becomes non-zero and the real part no longer resembles the input. What the heck am I doing
wrong?

TIA
Hugh

"Hugh" <yahugh@hotmail.com> wrote in message
news:3D2C4C06.2080607@hotmail.com...
> In a system simulation that I've been working on I am unsuccessfully
attempting to apply a uniform
> phase shift to a non-periodic waveform. What I've tried to do is take the
Fourier transform of the
> signal, apply an offset to the phase and then take the inverse transform
of that. I thought the output
> of this process should be my original waveform with all of its frequency
components delayed by the same
> number of radians (different amounts of time). However, I am not getting
this result. I've tried this
> in both LabVIEW and Matlab. Here's a Matlab implementation using a sine
wave as the input:
>
> t = [0:pi/128:4*pi];
> x = sin(t);
> X = fft(x);
> MX = abs(X);
> AX = angle(X);
> UAX = unwrap(AX) - pi/2;
> Y = MX .* exp(j*UAX);
> y = ifft(Y);
> plot(real(y));
>
> I've observed that with no phase offset the imaginary part of y is zero
and the real part is
> a replica of x. However, when I apply a phase offset (pi/2 in the above
example) the imaginary
> part becomes non-zero and the real part no longer resembles the input.
What the heck am I doing
> wrong?
>
> TIA
> Hugh
>

This trick is to, when applying the offset factors
(exp(j*2*pi*f*shift_amount)) ensure that they are symmetric (in the
conjugate sense) about zero frequency, corresponding to a real signal in the
time domain. Like so:

N = 1024;
t=(0:N-1)/N*4*pi;
x=sin(t);
X=fft(x);
p = 0.234; % Fraction of a time period to shift data
Y=exp(j*2*pi*p*((0:N-1)-N/2)/N); % Conjugate-Symmetric shift
Z=X.*Y; % Apply the shift
z=ifft(Z); % Back into the time domain - should be real (more or less)
z=real(z);
plot(t,x,'b',t,z,'r')

The key is in the assignment of Y: symmetric in amplitude, anti-symmetic in
phase (just like X). Other wise a contant complex phasor infiltrates the
time domain data.
:-) Aj

"Hugh" <yahugh@hotmail.com> wrote in message
news:3D2C4C06.2080607@hotmail.com...
> In a system simulation that I've been working on I am unsuccessfully
attempting to apply a uniform
> phase shift to a non-periodic waveform. What I've tried to do is take the
Fourier transform of the
> signal, apply an offset to the phase and then take the inverse transform
of that. I thought the output
> of this process should be my original waveform with all of its frequency
components delayed by the same
> number of radians (different amounts of time). However, I am not getting
this result. I've tried this
> in both LabVIEW and Matlab. Here's a Matlab implementation using a sine
wave as the input:
>
> t = [0:pi/128:4*pi];
> x = sin(t);
> X = fft(x);
> MX = abs(X);
> AX = angle(X);
> UAX = unwrap(AX) - pi/2;
> Y = MX .* exp(j*UAX);
> y = ifft(Y);
> plot(real(y));
>
> I've observed that with no phase offset the imaginary part of y is zero
and the real part is
> a replica of x. However, when I apply a phase offset (pi/2 in the above
example) the imaginary
> part becomes non-zero and the real part no longer resembles the input.
What the heck am I doing
> wrong?

Hugh,

Without fixing your code one way or another, here are a couple of things to
consider:

It looks like you're trying to solve a problem that's been dealt with often.
Take a look at Hilbert transformer design. That's another term for a 90
degree phase shifter. You will end up with a filter. You can design a
Hilbert transformer using the Parks-McClellan filter design program.

Some tutorial information that may be useful:

As a backdrop sort of viewpoint, a system yielding pure constant phase shift
of a general, multifrequency or broadband signal isn't physically
realizable. Also, consider a pure time delay which will not perturb the
waveform at all but does change the relative phase at all frequencies. The
time delay is the derivative of the phase shift. Note that a time delay is
also a perfect all-pass and a constant phase shifter would also might be
viewed as an all-pass.

The Fourier transform of a time delay is e^(-j*omega*delay). This is also
known as the time-shifting property and a useful Fourier transform pair. So
a pure delay gives a phase shift of omega*delay and the derivative with
respect to omega is "delay".

If you apply a constant to the phase terms [again emphasis on the plural] as
you have done, you are delaying each frequency differently. That means the
individual components can no longer add to reconstruct the original time
series.

You might also benefit from knowing a few transform pair identities:

A real and even function transforms into a real function.
A general real function transforms into a complex function.
An real and odd function transforms into an imaginary function.

So, by changing the phase term by a constant changes both the real and
imaginary parts while keeping the amplitude constant. The result is some
general complex function which will have a complex transform. Also probably
not what you want - to have a complex time series.

You might also look at your code to make sure it's doing what you want. I
would be suspicious of "unwrap" unless I'd tested it.
Also, it would help you get better answers if you tell us what you're trying
to do with this thing - more the system context.

Fred

AJ \no z\ Johnson wrote:
>
>
> "Hugh" <yahugh@hotmail.com> wrote in message
> news:3D2C4C06.2080607@hotmail.com...
>> In a system simulation that I've been working on I am
unsuccessfully
> attempting to apply a uniform
>> phase shift to a non-periodic waveform. What I've tried to do
is take the
> Fourier transform of the
>> signal, apply an offset to the phase and then take the inverse
transform
> of that. I thought the output
>> of this process should be my original waveform with all of its
frequency
> components delayed by the same
>> number of radians (different amounts of time). However, I am
not getting
> this result. I've tried this
>> in both LabVIEW and Matlab. Here's a Matlab implementation
using a sine
> wave as the input:
>>
>> t = [0:pi/128:4*pi];
>> x = sin(t);
>> X = fft(x);
>> MX = abs(X);
>> AX = angle(X);
>> UAX = unwrap(AX) - pi/2;
>> Y = MX .* exp(j*UAX);
>> y = ifft(Y);
>> plot(real(y));
>>
>> I've observed that with no phase offset the imaginary part of y
is zero
> and the real part is
>> a replica of x. However, when I apply a phase offset (pi/2 in
the above
> example) the imaginary
>> part becomes non-zero and the real part no longer resembles the
input.
> What the heck am I doing
>> wrong?
>>
>> TIA
>> Hugh
>>
>
> This trick is to, when applying the offset factors
> (exp(j*2*pi*f*shift_amount)) ensure that they are symmetric (in the
> conjugate sense) about zero frequency, corresponding to a real
signal in
> the
> time domain. Like so:
>
> N = 1024;
> t=(0:N-1)/N*4*pi;
> x=sin(t);
> X=fft(x);
> p = 0.234; % Fraction of a time period to shift data
> Y=exp(j*2*pi*p*((0:N-1)-N/2)/N); % Conjugate-Symmetric shift
> Z=X.*Y; % Apply the shift
> z=ifft(Z); % Back into the time domain - should be real (more or
less)
> z=real(z);
> plot(t,x,'b',t,z,'r')
>
> The key is in the assignment of Y: symmetric in amplitude,
anti-symmetic in
> phase (just like X). Other wise a contant complex phasor
infiltrates the
> time domain data.
> :-) Aj


Hugh, thanx for asking this question. I had a similar problem. Aj
thanx for your suggestion.


ln

On Wed, 10 Jul 2002 09:00:22 -0600, Hugh <yahugh@hotmail.com> wrote:

>In a system simulation that I've been working on I am unsuccessfully attempting to apply a uniform
>phase shift to a non-periodic waveform. What I've tried to do is take the Fourier transform of the
>signal, apply an offset to the phase and then take the inverse transform of that. I thought the output
>of this process should be my original waveform with all of its frequency components delayed by the same
>number of radians (different amounts of time). However, I am not getting this result. I've tried this
>in both LabVIEW and Matlab. Here's a Matlab implementation using a sine wave as the input:
>
>t = [0:pi/128:4*pi];
>x = sin(t);
>X = fft(x);
>MX = abs(X);
>AX = angle(X);
>UAX = unwrap(AX) - pi/2;
>Y = MX .* exp(j*UAX);
>y = ifft(Y);
>plot(real(y));
>
>I've observed that with no phase offset the imaginary part of y is zero and the real part is
>a replica of x. However, when I apply a phase offset (pi/2 in the above example) the imaginary
>part becomes non-zero and the real part no longer resembles the input. What the heck am I doing
>wrong?
>
> TIA
> Hugh
>

Hi Hugh,
  If you want a constant time delay, shift the phase of
the spectral components by values that are proportional
to their individual frequencies. That is if you shift
a 100 Hz component by 20 degrees, shift the 200 hz component
by 40 degrees. The amount of shift vs. freq should
look like this:

            
 ^ *
 | | *
phase | *
shift | *
            | *
         -Fs/2 ------*-------- +Fs/2 ------> Freq
                      0 * |
                          * |
                            * |
                              * |
                                * |

The slope of that phase shift function (line) will
be proportional to the resultant time delay in the
time domain. (That "0" above means zero Hz.)

God Luck,
[-Rick-]

Rick Lyons wrote:
>
> On Wed, 10 Jul 2002 09:00:22 -0600, Hugh <yahugh@hotmail.com> wrote:
>
> >In a system simulation that I've been working on I am unsuccessfully attempting to apply a uniform
> >phase shift to a non-periodic waveform. What I've tried to do is take the Fourier transform of the
> >signal, apply an offset to the phase and then take the inverse transform of that. I thought the output
> >of this process should be my original waveform with all of its frequency components delayed by the same
> >number of radians (different amounts of time). However, I am not getting this result. I've tried this
> >in both LabVIEW and Matlab. Here's a Matlab implementation using a sine wave as the input:
> >
> >t = [0:pi/128:4*pi];
> >x = sin(t);
> >X = fft(x);
> >MX = abs(X);
> >AX = angle(X);
> >UAX = unwrap(AX) - pi/2;
> >Y = MX .* exp(j*UAX);
> >y = ifft(Y);
> >plot(real(y));
> >
> >I've observed that with no phase offset the imaginary part of y is zero and the real part is
> >a replica of x. However, when I apply a phase offset (pi/2 in the above example) the imaginary
> >part becomes non-zero and the real part no longer resembles the input. What the heck am I doing
> >wrong?
> >
> > TIA
> > Hugh
> >
>
> Hi Hugh,
> If you want a constant time delay, shift the phase of
> the spectral components by values that are proportional
> to their individual frequencies. That is if you shift
> a 100 Hz component by 20 degrees, shift the 200 hz component
> by 40 degrees. The amount of shift vs. freq should
> look like this:
>
>
> ^ *
> | | *
> phase | *
> shift | *
> | *
> -Fs/2 ------*-------- +Fs/2 ------> Freq
> 0 * |
> * |
> * |
> * |
> * |
>
> The slope of that phase shift function (line) will
> be proportional to the resultant time delay in the
> time domain. (That "0" above means zero Hz.)
>
> God Luck,
> [-Rick-]

Rick,

I think a careful reading will show that he wants the same phase shift
at all frequencies, and different time delays. For a 90-degree shift, a
Hilbert transformer does that in the time domain, and the real/imaginary
switch I mentioned earlier does it in the frequency domain. Mike's more
general frequency-domain transformation can be used for any angle.

Jerry
--
      "The rights of the best of men are secured only as the
       rights of the vilest and most abhorrent are protected."
    -Chief Justice Charles Evans Hughes, around when I was born.
 
"They that give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -Benjamin Franklin, 1759
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

I haven't played with MATLAB for a quit long time. Could you tell what
the function unwrap(.) means? Generally, if you want to keep the
converted signal as real as the original one, you have to shift the
positive and negative frequency components by the phases of opposite
signs, like the Hilbert transform (pi/2 shift) in the special case.
Otherwise, the converted signal will be complex.

Ying

Hugh <yahugh@hotmail.com> wrote in message news:<3D2C4C06.2080607@hotmail.com>...
> In a system simulation that I've been working on I am unsuccessfully attempting to apply a uniform
> phase shift to a non-periodic waveform. What I've tried to do is take the Fourier transform of the
> signal, apply an offset to the phase and then take the inverse transform of that. I thought the output
> of this process should be my original waveform with all of its frequency components delayed by the same
> number of radians (different amounts of time). However, I am not getting this result. I've tried this
> in both LabVIEW and Matlab. Here's a Matlab implementation using a sine wave as the input:
>
> t = [0:pi/128:4*pi];
> x = sin(t);
> X = fft(x);
> MX = abs(X);
> AX = angle(X);
> UAX = unwrap(AX) - pi/2;
> Y = MX .* exp(j*UAX);
> y = ifft(Y);
> plot(real(y));
>
> I've observed that with no phase offset the imaginary part of y is zero and the real part is
> a replica of x. However, when I apply a phase offset (pi/2 in the above example) the imaginary
> part becomes non-zero and the real part no longer resembles the input. What the heck am I doing
> wrong?
>
> TIA
> Hugh

On Wed, 10 Jul 2002 20:05:53 -0400, Jerry Avins <jya@ieee.org> wrote:

   (snipped)
>
>I think a careful reading will show that he wants the same phase shift
>at all frequencies, and different time delays. For a 90-degree shift, a
>Hilbert transformer does that in the time domain, and the real/imaginary
>switch I mentioned earlier does it in the frequency domain. Mike's more
>general frequency-domain transformation can be used for any angle.
>
>Jerry

Aarrggh! You're right.

However, monkeying with Hugh's code I see that
his results make sense. Using the following:

clear
t = [0:pi/128:4*pi];
x = sin(t);
figure(5)
subplot(3,1,1), plot(x,'-bo')
X = fft(x);
MX = abs(X);
AX = angle(X);
UAX = unwrap(AX) - pi/2;
Y = MX .* exp(j*UAX);
y = ifft(Y);
subplot(3,1,2), plot(real(y));
subplot(3,1,3), plot(imag(y));

The final time-domain real part is just
computational errors on the order of
10^(-13). They should be all zeros.
The final time-domain imaginary part
is sinusoidal going negative right after t = 0.
This is correct. Think of Euler's equations for
a sinewave. After the -pi/2 phase shift, the
two complex exponentials, at t = 0, are no longer
pointing North and South, but are pointing East and
West. As time progresses beyond zero, the sum of
the two complex exponentials will sum to a
negative imaginary value.

Hugh started with a real-only time-domain sequence so
its spectral phases will be conjugate symmetrical.
That phase shift of -pi/2 made the spectral
phase asymetrical, which leads to a non-zero
imaginary part in the time domain.

[-Rick-]

On 11 Jul 2002 01:02:01 -0700, ying@omnexcontrols.com (Ying Xiong)
wrote:

>I haven't played with MATLAB for a quit long time. Could you tell what
>the function unwrap(.) means?

Hi Ying,
  The "unwrap()" command removes the
discontinuities (of 2pi radians) in phase
angle values that occur when the arctan is
performed.

It turns a phase plot like this

          * * * *
           * * * *
            * * * *
             * * * *
                  freq -->

to this

         *
          *
           *
            *
             *
              *
               *
                *
                 *
                  *
                   *
                    *
              freq -->


>Generally, if you want to keep the
>converted signal as real as the original one, you have to shift the
>positive and negative frequency components by the phases of opposite
>signs, like the Hilbert transform (pi/2 shift) in the special case.
>Otherwise, the converted signal will be complex.

You bet.

[-Rick-]

On 11 Jul 2002 01:02:01 -0700, ying@omnexcontrols.com (Ying Xiong)
wrote:

Hi Ying,
   check out page 19 of the document at:

http://klabs.org/richcontent/MAPLDCon00/Presentations/Session_A/A1_Bassett_S.PDF

Regards,
[-Rick-]

Rick, thank you for both messages. By the way, are you also working on
digital communications stuff such as DSP-based digital transceivers?

Ying

ricklyon@remove.onemain.com (Rick Lyons) wrote in message news:<3d2e02fd.7514113@news.earthlink.net>...
> On 11 Jul 2002 01:02:01 -0700, ying@omnexcontrols.com (Ying Xiong)
> wrote:
>
> Hi Ying,
> check out page 19 of the document at:
>
> http://klabs.org/richcontent/MAPLDCon00/Presentations/Session_A/A1_Bassett_S.PDF
>
> Regards,
> [-Rick-]

From the Matlab help file:

    UNWRAP(P) unwraps radian phases P by changing absolute
        jumps greater than pi to their 2*pi complement.

Basically, it is a way to show phase shifts larger than +-180 degrees.

"Ying Xiong" <ying@omnexcontrols.com> wrote in message
news:56b54115.0207110002.55f56b09@posting.google.com...
> I haven't played with MATLAB for a quit long time. Could you tell what
> the function unwrap(.) means? Generally, if you want to keep the
> converted signal as real as the original one, you have to shift the
> positive and negative frequency components by the phases of opposite
> signs, like the Hilbert transform (pi/2 shift) in the special case.
> Otherwise, the converted signal will be complex.
>
> Ying
>
> Hugh <yahugh@hotmail.com> wrote in message
news:<3D2C4C06.2080607@hotmail.com>...
> > In a system simulation that I've been working on I am unsuccessfully
attempting to apply a uniform
> > phase shift to a non-periodic waveform. What I've tried to do is take
the Fourier transform of the
> > signal, apply an offset to the phase and then take the inverse transform
of that. I thought the output
> > of this process should be my original waveform with all of its frequency
components delayed by the same
> > number of radians (different amounts of time). However, I am not getting
this result. I've tried this
> > in both LabVIEW and Matlab. Here's a Matlab implementation using a sine
wave as the input:
> >
> > t = [0:pi/128:4*pi];
> > x = sin(t);
> > X = fft(x);
> > MX = abs(X);
> > AX = angle(X);
> > UAX = unwrap(AX) - pi/2;
> > Y = MX .* exp(j*UAX);
> > y = ifft(Y);
> > plot(real(y));
> >
> > I've observed that with no phase offset the imaginary part of y is zero
and the real part is
> > a replica of x. However, when I apply a phase offset (pi/2 in the above
example) the imaginary
> > part becomes non-zero and the real part no longer resembles the input.
What the heck am I doing
> > wrong?
> >
> > TIA
> > Hugh

Fred,


>
> Right off I don't understand the architecture. What is the ideal signal
> and where did it come from?


The ideal signal is the brake cylinder pressure vs. time that we want to
produce. The relationship between this pressure and the acceleration is
very much a direct one (assuming a constant coefficient of friction) and
is also very easily measured.

> It seems to me that the simulated signal is
> the "ideal" in that at least you have a simulation to generate it. So
> that's a confusion.


The brake control signal is generated by our simulation ahead of time with
the "ideal pressure signal" as the input to the simulation.

If the simulation were perfect you could just play this resulting brake control
signal into the system and get the desired brake pressure out. That is, in
fact, what I tried first and it worked surprisingly well. The error signal
(ideal pressure - actual pressure) was something that I simply looked at
after the fact to see how good a job of generating the brake control signal
my simulation was doing. It was when I realized that valve leakages were causing
long term drifts in the brake pressure that I first tried using the error signal
to generate a correction to the brake control signal. This worked well for relatively
slowly changing errors (on the order of 1e-2 sec) but didn't help with rapidly
changing errors (1e-4 sec). Mt attempts to deal with this latter problem are
what eventually started this thread.


>
> Also, the braking force relationship to brake fluid pressure is out of
> the feedback loop. This means that variations in the system caused by
> things like brake temperature are outside of your control right now.
> That could be a big deal in the context of trying to get better than 15%
> error.
>


True. However, right now we're working with a testbed that simply measures
brake pressure. We expect that when we actually apply braking forces to a
moving sled the coefficient of friction will vary over time due to heating
and that we will have to compensate for this. At that point we will have to
measure the actual braking force and we think we know how to do that without
resorting to accelerometers which are noisy and which also pick up undesirable
mechanical resonances from the device under test.


[chomp]


>
> I would first start with an accelerometer and the desired acceleration
> profile and nothing in H. No simulated profile required to do this and
> no fancy feedback either. It's likely that this will work with no
> compensation because it's such a simple control system with plenty of
> lag. If it becomes unstable, then you can go to more elaborate methods.
>

One of our main competitors has attempted to do things in much the manner that
you describe above with, uh, less than ideal results. The valve nonlinearities,
valve leakages, valve zero offsets and accelerometer noise have all combined to
thwart the most valiant efforts of a group of researchers.

Hugh

"Hugh" <yahugh@hotmail.com> wrote in message
news:3D3301A8.1060404@hotmail.com...
> Fred,
>
>
> >
> > Right off I don't understand the architecture. What is the ideal signal
> > and where did it come from?
>
>
> The ideal signal is the brake cylinder pressure vs. time that we want to
> produce. The relationship between this pressure and the acceleration is
> very much a direct one (assuming a constant coefficient of friction) and
> is also very easily measured.
>
> > It seems to me that the simulated signal is
> > the "ideal" in that at least you have a simulation to generate it. So
> > that's a confusion.
>
>
> The brake control signal is generated by our simulation ahead of time with
> the "ideal pressure signal" as the input to the simulation.
>
> If the simulation were perfect you could just play this resulting brake
control
> signal into the system and get the desired brake pressure out. That is, in
> fact, what I tried first and it worked surprisingly well. The error signal
> (ideal pressure - actual pressure) was something that I simply looked at
> after the fact to see how good a job of generating the brake control
signal
> my simulation was doing. It was when I realized that valve leakages were
causing
> long term drifts in the brake pressure that I first tried using the error
signal
> to generate a correction to the brake control signal. This worked well for
relatively
> slowly changing errors (on the order of 1e-2 sec) but didn't help with
rapidly
> changing errors (1e-4 sec). Mt attempts to deal with this latter problem
are
> what eventually started this thread.
>
>
> >
> > Also, the braking force relationship to brake fluid pressure is out of
> > the feedback loop. This means that variations in the system caused by
> > things like brake temperature are outside of your control right now.
> > That could be a big deal in the context of trying to get better than 15%
> > error.
> >
>
>
> True. However, right now we're working with a testbed that simply measures
> brake pressure. We expect that when we actually apply braking forces to a
> moving sled the coefficient of friction will vary over time due to heating
> and that we will have to compensate for this. At that point we will have
to
> measure the actual braking force and we think we know how to do that
without
> resorting to accelerometers which are noisy and which also pick up
undesirable
> mechanical resonances from the device under test.
>
>
> [chomp]
>
>
> >
> > I would first start with an accelerometer and the desired acceleration
> > profile and nothing in H. No simulated profile required to do this and
> > no fancy feedback either. It's likely that this will work with no
> > compensation because it's such a simple control system with plenty of
> > lag. If it becomes unstable, then you can go to more elaborate methods.
> >
>
> One of our main competitors has attempted to do things in much the manner
that
> you describe above with, uh, less than ideal results. The valve
nonlinearities,
> valve leakages, valve zero offsets and accelerometer noise have all
combined to
> thwart the most valiant efforts of a group of researchers.


Hugh,

OK, I think I understand a bit better now.

I understand that the output of the PID is simply a measure of the error
between what you're doing and what is happening regarding brake cylinder
pressure and not between vehicle acceleration and the control signal.

The simulation is also a very key ingredient here. Do I understand that you
have:
1) Determined the ideal brake cylinder pressure ahead of time as you have
an idealized direct relationship between cylinder pressure and braking force
/ vehicle acceleration / velocity?

2) Created a feedback system in the simulation or iterate in the simulation
to determine the necessary valve input to achieve the desired valve output?
This is a key area - can you describe it?

Measuring the braking force will be necessary later on........ that's an
accelerometer by any other name I think. So, if you have to do it anyway,
why not jump right in up front? With the kind of spec's you have it
appears that open loop will continue to be a bigger problem than single axis
accelerometer implementation, noise handling, etc. Of course, in your
situation there are ways to make the measurement noiseless depending on the
parameters of the system - but it's likely it can be done.

Fred

>
> Hugh,
>
> OK, I think I understand a bit better now.
>
> I understand that the output of the PID is simply a measure of the error
> between what you're doing and what is happening regarding brake cylinder
> pressure and not between vehicle acceleration and the control signal.
>
> The simulation is also a very key ingredient here. Do I understand that you
> have:
> 1) Determined the ideal brake cylinder pressure ahead of time as you have
> an idealized direct relationship between cylinder pressure and braking force
> / vehicle acceleration / velocity?


Yes. (Acceleration is what we're ultimately interested in, not velocity per se.)


>
> 2) Created a feedback system in the simulation or iterate in the simulation
> to determine the necessary valve input to achieve the desired valve output?
> This is a key area - can you describe it?
>


It's difficult to describe in detail without a rather involved diagram. In
particular, the hydraulic flow through the valve orifice is proportional to the
square root of pressure differential (deltaP) across it. deltaP, in turn, varies
as the brake is applied and released creating a non-linear feedback element in
the system itself. Also, as you switch the brake from filling to bleeding you get
big discontinuities in the deltaP - another gross nonlinearity.


> Measuring the braking force will be necessary later on........ that's an
> accelerometer by any other name I think.


Not exactly. I have to be a little evasive about this point as its sort of a
trade secret. But we can measure the force directly. An accelerometer will pick
up mechanical resonances of the device under test which, if you put them into
the feedback loop, will cause the brake to try and null out errors that aren't
actually there.

> So, if you have to do it anyway,
> why not jump right in up front?


As I mentioned, we're working with a static test bed which only allows us
to measure pressure. It's simpler and less costly to learn how to make such
a static system do what we want than it would be to deal with a full scale
moving sled system. Incorporating force as the feedback term instead of
pressure should be straightforward once we have the static system working.

> With the kind of spec's you have it
> appears that open loop will continue to be a bigger problem than single axis
> accelerometer implementation, noise handling, etc. Of course, in your
> situation there are ways to make the measurement noiseless depending on the
> parameters of the system - but it's likely it can be done.
>


I agree that we can't do what we want running open loop! However, experience
has already shown us that you can't make this work by simply building a closed
loop system in which you try and make the acceleration of the device under test
track that of the desired acceleration. Some kind of hybrid approach seems to
be required.

Hugh

Fred Marshall wrote:
>
> ...
>
> Measuring the braking force will be necessary later on........ that's an
> accelerometer by any other name I think. So, if you have to do it anyway,
> why not jump right in up front? With the kind of spec's you have it
> appears that open loop will continue to be a bigger problem than single axis
> accelerometer implementation, noise handling, etc. Of course, in your
> situation there are ways to make the measurement noiseless depending on the
> parameters of the system - but it's likely it can be done.
>
> Fred

Fred, Is it possible that by braking pressure, Hugh means the force
applied to the brake pad ("squeezion"?) rather than its effect,
deceleration? It's what he seems to say, but then it could be scaled
pretty accurately from the hydraulic pressure, so your interpretation is
possible.

To answer your earlier questions about my garbled Hilbert discussion,
the output of a Hilbert transformer consists of all frequencies delayed
the same time, and shifted to quadrature with respect to a replica of
the original signal delayed an equal amount. I like HTs with an odd
number of taps so I can take the simply delayed signal from the middle
tap.

It's not often that linear phase and quadrature shift are needed
simultaneously. Then a quadrature pair can more easily be generated as a
pair of signals in quadrature with one another, but having no special
phase relation to the input. Two chains of three op-amps each can
provide such signals over a decade with about a half-degree error at
most. Good for single sideband voice and such.

Jerry
--
      "The rights of the best of men are secured only as the
       rights of the vilest and most abhorrent are protected."
    -Chief Justice Charles Evans Hughes, around when I was born.
 
"They that give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -Benjamin Franklin, 1759
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Jerry Avins wrote:

> Fred Marshall wrote:
>
>> ...
>>
>>Measuring the braking force will be necessary later on........ that's an
>>accelerometer by any other name I think. So, if you have to do it anyway,
>>why not jump right in up front? With the kind of spec's you have it
>>appears that open loop will continue to be a bigger problem than single axis
>>accelerometer implementation, noise handling, etc. Of course, in your
>>situation there are ways to make the measurement noiseless depending on the
>>parameters of the system - but it's likely it can be done.
>>
>>Fred
>>
>
> Fred, Is it possible that by braking pressure, Hugh means the force
> applied to the brake pad ("squeezion"?) rather than its effect,
> deceleration? It's what he seems to say, but then it could be scaled
> pretty accurately from the hydraulic pressure, so your interpretation is
> possible.


We measure the hydraulic pressure developed in the brake cylinder. Squeezion
(I like that word) falls out of this:

SqeezionForce = CylinderPressure * BrakeSurfaceArea

The braking force then is simply

BrakingForce = SqeezionForce * FrictionCoeffient

SqeezionForce is difficult to measure directly - it requires a load cell on the ground
side of the brake. It turns out that you can also measure the reaction force of the
brake by looking at the brake strain in the direction perpendicular to its face. This
strain is proportional to BrakingForce and includes changes in the coefficient of
friction but without the nasty side effects that you get with an accelerometer. (My
boss, the mechanical guy, explains it thusly: the friction surface acts like a filter
which doesn't transmit the resonances from the device under test. Cool!) We plan to
do just this when we build the full sled system. For now we're limited to the static
system which uses just the hydraulic pressure.

>
> To answer your earlier questions about my garbled Hilbert discussion,
> the output of a Hilbert transformer consists of all frequencies delayed
> the same time, and shifted to quadrature with respect to a replica of
> the original signal delayed an equal amount.

[chomp]

I tried applying the Hilbert transform to some test signals in LabVIEW (using
LabVIEW's stock Hilbert transform VI) and it appears to do exactly what I
had in mind. I can't test it on my actual system as it's down for some mechanical
rework for probably the next 2 ~ 3 weeks. I'll report back when I've had a chance
to run some more tests.

Once again, thank you everyone for your thoughtful responses.

Hugh

I know this is an old thread but I thought I'd reply to it as I'm essentially using the script posted here. Here is the script that I've got just now:

close all
N = 101;
t=[-0.1:0.002:0.1];
x=(1-2.*pi^2.*20^2.*t.^2).*exp(-pi^2.*20^2.*t.^2); % Produce Ricker wavelet
X=fft(x);
p = 2; % Fraction of a time period to shift data
Y=exp(1i*2*pi*p*((0:N-1)-N/2)/N); % Conjugate-Symmetric shift
Z=X.*Y; % Apply the shift
z=ifft(Z); % Back into the time domain - should be real (more or less)
z=real(z);
figure
plot(t,x,'b',t,z,'r') % Plot original and shifted wavelet
figure
f=[0:1:100];
f=f*(500/2)/(101/2); % Create frequency range for plotting
plot(f,abs(X),'b',f,abs(Z),'-.r') % Plot frequency spectra
axis([0 250 0 12]) % Limit axis range to Nyquist frequency
figure
plot(f,angle(X),'b',f,angle(Z),'-.r') % Plot phase spectra
axis([0 250 -4 4])

What I'm trying to do here is produce a 20 Hz Ricker wavelet, phase shift it by 360 degrees then plot the original and shifted wave followed by their frequency and phase spectra. The problem I'm having is that when I plot the shifted wavelet, the whole wavelet has moved by two samples and I don't know why. If I replace line 3 (and make other changes where appropriate) with "t=[-0.1:(0.2/1023):0.1];" this shift disappears but the frequency spectra of the two wavelets no longer looks right. I've tried padding my original t out with 0s to 1024 but that doesn't help.

Thanks in advance for the help.

Daniel