Fourier Transform - how to increment in time?

[blaughli]

I'm working on some research with a professor, and we're looking at data collected by an x-band radar array looking at ocean waves as they approach the coast (the radar is on land, and we can see about 3 miles out).

What we're trying to do is perform an fft on the signal using Matlab, and then manually increment the fft in time to see if we can inverse it and get back an image similar to one taken by the radar at a different time.

We gave it a shot but the inverse transform quickly went to garbage as our delta_t's got bigger. Small delta_t's gave back an image that looked more like the original image but everything was sortof blurred.

I can provide some of the code, but does anyone have any general advice on how to do this or know of any resources/examples to check out? I'm posting the question here because I think that what we're after is an answer to a physics/math question. But perhaps this is better addressed to the programming community..?

Thanks!

 

[thegreenlaser]

What do you mean by "manually increment the fft in time"?

 

[blaughli]

I'm new to this stuff, but I think that we're incrementing the phase of the coefficients by omega*delta_t. The idea is that you've got a bunch of "snapshots" of these ocean waves coming in, at different times. Take one, perform an fft on it, increment the phase of the coefficients by the mentioned quantity, and then inverse the transform. We would hope to get back a picture that looks like one taken at an earlier (or later) time... Does that make sense?

 

[meBigGuy]

How about you do a sliding transform on the data and see how the fft varies in time. I expect you will find that simply adjusting the phase does not really reverse you in time. It might be close for a very small increment in time, but all you are really doing is adjusting the phase relationships of a bunch of average frequencies (energies). Remember that the fft is over a window in time. It isn't about any instant. It contains no information about the averages in prior windows in time except to the extent that you might independently develop some sort of correlation function.

 

[Khashishi]

I don't think you've explained what you are doing clearly enough. What is the signal that you are taking the Fourier transform of? You said it's a snapshot of an ocean wave, but what does that mean?

 

[thegreenlaser]

I'm new to this stuff, but I think that we're incrementing the phase of the coefficients by omega*delta_t. The idea is that you've got a bunch of "snapshots" of these ocean waves coming in, at different times. Take one, perform an fft on it, increment the phase of the coefficients by the mentioned quantity, and then inverse the transform. We would hope to get back a picture that looks like one taken at an earlier (or later) time... Does that make sense?

I think I understand now... you're taking a snapshot of the wave at time t₀ and then you're taking a spatial Fourier transform of that snapshot. So you're getting the wave as a function of wavenumber (spatial frequency) k at time t₀. Then you're trying to predict what the spatial Fourier transform will look like at time t₀ + Δt by advancing the phase of the spatial Fourier transform by ω*Δt.

A critical part of this process would stem from the fact that the temporal frequency ω is a function of the spatial frequency k, and if you're going to change the phase of the wave by ω*Δt at each value of k, then you'd better know what the value of ω is for each k. If you're using the wrong relationship between ω and k and/or you're not implementing that relationship correctly in the software, that will lead to dispersion, which would explain the appearance of blurriness as you progress time. So it could be either a physics problem (wrong ω-k relationship) or a software problem (not implementing the ω-k relationship correctly) or both.

I'm not really sure what your background is... did what I just said make sense to you? Are you familiar with terms like wavenumber, dispersion, phase velocity, and group velocity? Are you fairly familiar with Fourier transforms and discrete Fourier transforms?

 

[Baluncore]

I think you are making the false assumption that the frequency of a sine wave showing up in one frequency channel or bin of the DFT has a frequency exactly at the centre of that frequency channel.

A pure sine wave will show up in one bin with some bleed into neighbouring bins. The amplitude will be inconsistent depending on the offset of the sine wave frequency from the bin centre.

A window function applied prior to the forward transform will spread the energy over more channels, but will correct some of the amplitude variability and eliminate high frequency noise.

So if you window your input data you can expect energy to be spread over three or more channels. You can have no idea where in the channel the frequency really was / is. This introduces a +/-180° phase error and prevents tracking phase between shots.

Because of this problem, power spectrum accumulation of successive shots must be used since it eliminates phase indeterminacy.

Your sea clutter will have broad spectrum profiles, not single sine waves. Because of that, no one bin will contain anyone sine wave. It is just a big mix of everything. 0% of the signal is at the exact centre of any bin.

 

[AlephZero]

This seems like the classic error of "trying to make a math model of something but ignoring the physics".

Ocean waves are not shaped like sine waves. The shape depends on the amplitude, and the wave velocity also depends on the water depth, which presumably changes over the 3 miles covered by your radar data.

You probably don't need a very accurate and detailed model of the physics to make this work, but you do need something that captures the real-world behavior, and IMO that is not "changing the phase coefficients in an FFT".

http://hyperphysics.phy-astr.gsu.edu/hbase/waves/watwav2.html
http://en.wikipedia.org/wiki/Airy_wave_theory

 

[Baluncore]

Ocean waves are not shaped like sine waves.

The reflected Doppler radar signal is analysed by a DFT which is equivalent to a bank of , (probably Gaussian profile), "Fourier = sinusoidal wave" filters, each tuned to a different centre frequency.

The information available from the DFT gives the spread of the water movement velocity components in the range direction. Since the various parts of the wave can travel at different velocities, there are really no single sine waves in the returned data, it is a continuum over frequency, with occasional noise bursts in time and frequency due to prominent events. It is the shape of the doppler radar spectrum that yields sea-state information from the radar. Waves sets due to local wind and a number of longer term swells can be separately extracted.

Two mistakes are being made;
1. In the frequency domain, the transform is discrete, while the signals are continuous, and;
2. That the statistical energy detected by any channel does not come from a sine wave of the exact centre frequency of that channel.

 

[thegreenlaser]

This seems like the classic error of "trying to make a math model of something but ignoring the physics".

Ocean waves are not shaped like sine waves. The shape depends on the amplitude, and the wave velocity also depends on the water depth, which presumably changes over the 3 miles covered by your radar data.

You probably don't need a very accurate and detailed model of the physics to make this work, but you do need something that captures the real-world behavior, and IMO that is not "changing the phase coefficients in an FFT".

http://hyperphysics.phy-astr.gsu.edu/hbase/waves/watwav2.html
http://en.wikipedia.org/wiki/Airy_wave_theory

If I'm understanding him correctly, he must not be completely ignoring the physics... Without some physical model determining the phase velocity or wavenumber at each frequency, there would be no way of knowing how much to change the phase by. If the physics provides a distinct phase velocity for each frequency, then I see no reason why this method shouldn't work in principle (the issues would likely be numeric as Baluncore is suggesting). However, you may be right that the physics just doesn't allow for a simple relationship between phase velocity and frequency because of the non-uniform depth.

 

[Baluncore]

I think there is quite a bit of cross-misunderstanding going on here.

A radar carrier reflected from the sea returns with a doppler frequency distribution determined by the velocities of all the sea surface disturbances that reflect energy. That is a simple doppler radar velocity measurement. If the reflected signal received is multiplied by the transmitted carrier, then an audio signal is generated as the difference frequency of the reference oscillator and the mush of signals returned.

The profile of the water waves and their phase velocity is in no way related to the shape of the sine and cosine waves used in the FFT. All the FFT is doing is sorting the doppler derived velocities into a velocity distribution based on radar doppler shift.

The broad spectrum of velocities computed will identify sea-state. X-band will probably also show the down-range wind speed by measuring the velocity of spindrift from white-caps.

Without further information we cannot tell if the radar is a CW, pulse or a chirp system.

 

[Claude Bile]

My suspicion is that your simulations turn to rubbish because of reflections from the domain walls.

A solution (other than expanding the simulation domain) is to implement a transparent boundary condition, where the wave is assumed to be a plane wave at the edge of the simulation domain. This reduces (but does not eliminate) the issue.

It is always a good sanity check to see if manual constraints (i.e. simulation domain, mesh, etc.) change the simulation results. If so, then it is highly probable that what you are seeing is an artifact of your numerical implementation.

Claude.