hi a question
prasatkumar
I have two curves which varies in time.
There is phase lag and some amplitude .
I just want to know how to get them.
Thanks in advance
Prasat
--
Posted via http://dbforums.com
Andreas Fromm
> I have two curves which varies in time.
> There is phase lag and some amplitude .
> I just want to know how to get them.
really hard to get.
> Thanks in advance
You're wellcome.
Andreas
Dan Tex1
>I have two curves which varies in time.
>There is phase lag and some amplitude .
>I just want to know how to get them.
>Thanks in advance
>Prasat
The first step will be to communicate your problem more clearly. All you've
stated above is that you have some curves which vary in time and have
amplitude. You need to explain a LOT more than that if you want someone to
help you out.
Dan :-)
Richard Maine
> The first step will be to communicate your problem more clearly.
At times I think that the entire first course in programming, before
any programming languages are introduced, should be devoted to the
subject of coherently formulating problems. Certainly one of the
first steps to solving any problem is to know what the problem is. It
is an important step, which often seems to be neglected.
Perhaps we should form a programmers anonymous group. Step 1
is to recognize that you have a problem.... :-)
Though I do wonder if there might be some (human) language
translation problems in this case.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
Kevin G. Rhoads
>any programming languages are introduced, should be devoted to the
>subject of coherently formulating problems. Certainly one of the
>first steps to solving any problem is to know what the problem is. It
>is an important step, which often seems to be neglected.
Oh, that would be GREAT. But then you'd need to go into what
happens when you can only get a sloppy problem definition until
you've taken at least one crack at solving it. Fortunately
wicked problems like that are rare.
Paul Curtis
industrial/scientific data
acquisition/processing/organization are NEVER well-characterized, as to the
nature of the "problem", or the truly important data entities and their
correct
relationships. And situations where computer-based solutions (programming)
are commissioned by non-technical managers are GUARANTEED to be
totally FUBAR.
prasatkumar
okay let me post it correctly and precisely.
I have two curves A(t) and B(t) they are periodic with period 2pi.
Ofcourse they have phase lag and aplitude difference.
Ihvae got the data of bot A(t) and B(t).
I want to find compute out the phase lag and the amplitude by using fft
transforms.
Last time i was in hurry could not write out everythig in detail.
Thanks in advance from your attention.
PS:if somebody is working with signal processing should be able
to help me.
J. F. Cornwall
RARE???!!!???!!!??? Seems like it happens on every project I've ever
been involved in, from military weather programs to graduate school
class projects to hydrologic databases...
Jim Cornwall
Gordon Sande
Fred Brooks said "Build one to throw one away" and the whole rapid
prototyping thing is all about finding out what the real specifications
are all about. All too often there is the nominal problem and then there
are all the unspoken important side issues that are so important that
they are taken for granted (until someone does not understand and does
them wrong).
J. F. Cornwall
Yep. Problems arise, though, when the rapidly developed prototype gets
deployed as the production version... :-(
Jim
Richard Edgar
: Yep. Problems arise, though, when the rapidly developed prototype gets
: deployed as the production version... :-(
Being cynical in my youth, I've formed the opinion that that's the normal
method of software development these days :-/
Richard
------------------------------------------------------------------
Richard Edgar rg...@ast.cam.ac.uk
IoA http://www.ast.cam.ac.uk/~rge21/
Cambridge
PGP Fingerprint: AC9C 8DB8 A8FC 443B 0C9F 06C0 518B F8F1 ECEA 82CB
Duane Bozarth
>
> J. F. Cornwall (JCor...@cox.net) wrote:
>
> : Yep. Problems arise, though, when the rapidly developed prototype gets
> : deployed as the production version... :-(
>
> Being cynical in my youth, I've formed the opinion that that's the normal
> method of software development these days :-/
Being realistic in my (apparently rapidly advancing) <old> age, I've
formed the opinion that's <always> been the method of software
development... :(
Kevin G. Rhoads
>transforms.
Does it have to be FFT? If all you want is amplitude for each
and relative phase between the two, FFT may well not be the
best way to go.
One way to proceed would be to compute an average value for
wach waveform, and then subtract it point by point. The
resulting waveforms are now zero-centered. Find the zero
crossings, and look for max positive and max negative between
every second zero crossing. The differences between max pos
and max neg give the one cycle amplitudes which can be averaged
or min/maxed or whatever to get some measure of overall amplitude.
The spacing between zero crossings in one wave are a measure of
the half-period, and between the two waves a measure of the
lag which can be converted to phase terms by using the period.
Of course if the data are very noisy, this would be a very bad
way to proceed. Perhaps if you tell us a bit more, we can
suggest something suitable to your particulars.
If the data are noisy, then the overhead of an FFT may
be justified, just watch out for aliasing, binning issues,
and length vs. nearest power of two (or conversely devolving
into a simple DFT if non-power of two lengths are used
with most implementations ...)
Prefiltering, data set size, data format, possible data
drop-outs &c are all interesting complications that may
be relevant or not.
HTH
Kevin
Kevin G. Rhoads
however many (perhaps most) real-world problems
end up being wicked. But that is not because
they are inherently so, but rather for the second
reason you mentioned: "commissioned by non-technical
It isn't a problem-domain problem, but an organizational
domain problem. Certainly, if I include those then
rather than rare, they are the norm. But most of
those did not have to be wicked problems.
Sincerely
Kevin
Brooks Moses
[> prasatkumar <membe...@dbforums.com> wrote]
> >I want to find compute out the phase lag and the amplitude by using fft
> >transforms.
>
> Does it have to be FFT? If all you want is amplitude for each
> and relative phase between the two, FFT may well not be the
> best way to go.
> If the data are noisy, then the overhead of an FFT may
> be justified, just watch out for aliasing, binning issues,
> and length vs. nearest power of two (or conversely devolving
> into a simple DFT if non-power of two lengths are used
> with most implementations ...)
Even if the data are noisy, an FFT is overkill; he knows the frequency,
and can thus merely compute that component of the Fourier transform
rather than the full spectrum.
The process, essentially, would be this: over the set of data points,
numerically integrate (y*sin(t)) and (y*cos(t)) where t is the time and
y is the amplitude of that point. Normalize the results by the
integrals of (sin(t)*sin(t)) and (cos(t)*cos(t)), which you can either
calculate analytically or calculate numerically using the same numerical
integration; the former will be far quicker, but the latter is probably
better if you have only a few data points or odd spacings or such. Then
use atan2 on the two results to get the phase angle, and use the square
root of the sum of the squares to get the amplitude.
- Brooks
Kevin G. Rhoads
>RARE???!!!???!!!??? Seems like it happens on every project
I was distinguishing between problems for which no
definition except a sloppy one *can* be made vs.
definitions that are sloppy due to people, incompetence,
organizational issues &c. I quite agree, that sloppy
problem statements (for the latter reasons) are common.
But solving that involves sociology, psychology, management
and who knows what; no amount of schooling (such as
the esteemed Mr. Maine suggested) will solve those issues.
Sincerely
Kevin