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

[Ying Xiong]

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-]

[Jon Harris]

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" 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 m> 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, w
hen 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 Marshall]

"Hugh" wrote in message Hugh wrote:
>
> > 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.
>
> Thanks everyone for your responses.
>
> We're building a servo controlled hydraulic brake which is used to produce
> rapidly changing braking forces in an automotive crash test simulator. We know
> what we want the brake pressure waveform to look like based on a fairly
> straightforward F = ma calculation, where 'a' is the deceleration of the vehicle
> and 'm' is its mass. F is then the braking force that you get when you apply some
> brake pressure. The problem is controlling the hydraulic flow into and out of
> the brake. That's my job: to somehow generate the servovalve control signal
> that will result in the desired brake pressure waveform.
>
> The whole thing is pretty nonlinear. For starters the hydraulic flow is proportional
> to the square root of the pressure difference across the valve orifice so
> you can pretty much throw classical control system stuff out the window. The
> approach we've taken is to use a non-linear simulation to come up with a brake
> control signal that gives us fairly good results - like within 15% of what we want -
> running open loop. However, we've found that we still need to apply some feedback
> to compensate for things that our simulation isn't so good at modeling, such as
> valve leakage. That gets us closer yet to the desired results but it's still not
> good enough. Now I'm looking into ways to get even closer. If you're still with me,
> then you might find the control system block diagram interesting:
>
> +---------------+ +------------+
> | brake control | | |
> | signal | +-----+ | brake |
> | (from |------------>| + |-------| |----+
> | simulation) | +-----+ | | |
> +---------------+ ^ +------------+ |
> | |
> +---------------+ +------+ |
> |ideal pressure | | PID | actual pressure |
> | signal |----------->| |<------------------------+
> +---------------+ +------+
>
> The ideal pressure signal is that which was the input to the simulation which
> generated the brake control signal in the first place. During a crash test the two
> signals are "played back" simultaneously. The actual brake pressure is acquired
> and subtracted from the ideal pressure to produce an error signal. The challenge
> is to somehow relate this error signal to the brake control and apply it as a
> correction to the brake control signal. We've had good results applying PID control,
> at least for slowly changing errors. However, we're having trouble tracking higher
> frequency errors.
>
> One thing that occurred to me is this: we know from our basic performance testing
> that if we apply a sine wave of any frequency to the brake control input, the
> resulting pressure always lags the input signal by 90 degrees for any frequency.
> Thankfully, this can also be explained theoretically: the brake pressure is proportional
> to the integral of the hydraulic flow, which is what we control when we open and
> close the valve. So, my bright idea 😉 was that in the closed loop system maybe we
> need to compare the actual pressure to a delayed version of the ideal pressure signal
> since we already know the actual pressure will lag the command signal. A uniform time
> delay (linear phase) doesn't seem to help. It seems to me that inasmuch as the ideal
> pressure signal can be synthesized from discrete sines (thanks Mr. Fourier) maybe the
> correct approach is to delay each component by 90 degrees. Which brings us to my bumblings
> in Matlab. What I need to design (I think) is a filter which will introduce a phase
> shift of 90 to any frequency component of any signal input to it.

Hugh,

Strange, I don't see this post except in Jerry's recent message. Anyway, here are some comments.
I have read your message and understand it and the diagram.

Right off I don't understand the architecture. What is the ideal signal and where did it come from? 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.

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.

You have said that you want to control the acceleration of the vehicle according to some desired acceleration profile. So, here is a different block diagram:

+---------------+ +------------+ +------------+
> | brake control | | | | |
> | signal | A (+) +-----+ C | valve V | | Brake B |
> |(acceleration |------------>| +/- |-------| |----+---| |----+
> | profile) | +-----+ | p to p | | p to F | |
> +---------------+ (-) ^ +------------+ | | |
> | +------------+ |
> | |
> | actual acceleration |
+--------------------------------------------------+
>



Desired acceleration profile: A
Valve control signal: C
Valve transfer function: V from Pressure source to Brake as a function of C and delta pressure.
Brake transfer function: B from pressure at brake to braking force on the vehicle which could be a function of velocity and temperature.
Vehicle acceleration:D =
Servo controller: H has input A, D and transfer function H on D.

So D/A = [V*B]/[1 + V*B*H] which you want to be unity so D=A.

The first conclusion thing you note is that you would use an accelerometer for a feedback sensor and use the desired acceleration profile as the control signal. If you assume for the moment that the valve and brake are linear, that the valve has unity gain and the brake has some pressure to force relationship we'll still call B, and the feedback H is also unity, then the equation becomes:

D/A = B/[1+B] which approaches the desired value of unity (D=A) as B gets to be large.

Actually, you might be concerned about this approach because I suspect what you might *really* want is to control the vehicle velocity? If so, here's another approach that might meet your needs:


+---------------+ +------------+ +------------+
> | brake control | | | | |
> | signal | A (+) +-----+ C | valve V | | Brake B |
> |(velocity |------------>| +/- |-------| |----+---| |----+
> | profile) | +-----+ | p to p | | p to F | |
> +---------------+ (-) ^ +------------+ | | |
> | +------------+ |
> | +----+ | |> | | | actual acceleration |
+--| H |------------------------------------------+
> | |
+----+

Here the feedback is still assumed to be acceleration and now H is introduced which would be at least an integrator so that the velocity of the vehicle is now being controlled. You might initialize the integrator after the vehicle is at speed so that the error signal C goes to zero before the controlled event. You could generate the velocity profile from the existing desired acceleration profile by integrating it.

To belabor the point, here is what you currently have by my understanding:


+---------------+ +------------+ +------------+
> | brake control | | | | |
> | signal | A (+) +-----+ C | valve V | | Brake B |
> |(acceleration |------------>| +/- |-------| |-----+---| |----+???
> | profile) | +-----+ | p to p | | | p to F |
> +---------------+ (-) ^ +------------+ | | |
> | | +------------+
> | +----+ | |> | | | brake fluid pressure|
+--| ?? |---------------------+
> | |
+----+

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.

I hope this helps,

Fred

[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

[Fred Marshall]

"Hugh" 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]

>
> 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

[Jerry Avins]

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
����������������������������������������������������������������������

[Hugh]

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

[chutla]

Hello Hugh:

The simplest way to do this is to use the "Waveform Subset" in the WAveform toolbox. Just wire the "start" terminal to a numerical control...it will delay the start by X number of data points. If you put the whole shebang inside a While loop, you can get phase Lag as well...just be sure your loop iteration time is shorter than your wavefile length.