Dear Muniandi

Using matlab function you have mentioned will create a lag as you said because it needs all window size samples to calculate the average of these samples. You can build your own version of this function and and calculate the mean based on advanced samples.

Dear sir, can you clarify the meaning of advanced samples, does it mean future samples? Does lag is permitted in real-time applications? thanks

Yes, I mean future sample.

And about lag, it depends on application. So,if your phenomena you're trying to measure is slow, one second lag will be acceptable. Otherwise you need to reduce your lag time

Every (causal) filter introduces some time lag as every filter relies on "historical data". This does not interfere with "real-time" if the delay is within acceptable limits. What's to be considered "acceptable" depends on the individual application. 1 second sounds much, but your average sample is just 0.5 seconds "old". Thus I'd consider the time delay in your case to be more like 0.5 s.

Dear sir, What about IIR filter, I've seen most of the real-time signal processing works relying on them. Does it produce lag? and I also found out that savisky golay filter doesn't produce lag.

As all filters implement some kind of weighted addition of values and as these values constitute a time series of which only the current galue is recent, all of these filters - including IIR and Savitzky-Golay - introduce some delay.

To precisely determine the amount of delay you would plot input and output on the same time axis - e.g. measuring the step response vs. the input. Savitzky-Golay is a bit special as its window width is variable; thus the definition of the delay may be difficult. The same applies for other more sophisticated filters (e.g. Kalman). Anyway, each of these filters introduces some amount of delay.

Sir by using movmean function, i'm getting exactly the same signal length, for eg: original signal length 3500x1, filtered signal length 3500x1.

As per matlab definition this is what movmean does

movmean(A,k) - returns an array of local k-point mean values, where each mean is calculated over a sliding window of length k across neighboring elements of A. When k is odd, the window is centered about the element in the current position. When k is even, the window is centered about the current and previous elements. The window size is automatically truncated at the endpoints when there are not enough elements to fill the window. When the window is truncated, the average is taken over only the elements that fill the window. M is the same size as A.

@ Arunraj Munaiandi

I understand your description of movmean(). This is one of at least two ways to implement such a sliding window.

(Another way would be to calculate the mean value without truncating the window - resulting in (A-ww) output values for A input values.)

Regarding the time delay: movmean() cannot be calculated unless all elements within the window have been acquired. This means that movmean() has a delay of half the width of the window.

Thus, when plotting you have to plot the results from movmean() 1/2 window width delayed with respect to the input signal.

(Unless you let Matlab run "live" this is something that's not so obvious. But this is what has to be done to make the delay visible.)

Sir, does that means truncating the window doesn't produce delay.. In worst case, If i don't truncate the window, as per your definition shall i assume that 1 sec window(sliding window) + 0.5 sec delay(due to moving average)?.. So can i say my system process signal at 1.5 sec window?

Truncating the window is intended to get the same number output values as there are input values. The truncation in itself alters the filter's response and results in smaller delays during "ramp-up" and "ramp-down" towards both ends. So the delay will be ww/4 from the start - gradually incrementing to ww/2 (for full window width) and decreasing again to ww/4 towards the end.

NB that the 1 s sliding window results in a delay of "only" 0.5 s - not 1.5 s ! (The "average age" of an input value in the 1 s sliding window is 0.5 s.)

You can easily characterize your filter by creating some "artificial" input stream - e.g. with one step from 0 to max and another step down to 0 again. Should not be too difficult.

Thank you for your useful insights and expertise Mr. Dreher.

Hi,

As Mr Dreher says, there is no miracle solution to remove the delay of a filter. To compute the local (or windowed) mean of your signal, you need a window of 1sec centered on the sample you are filtering. In real-time, it would mean that you need 0.5sec of future data to compute your mean (which is of course impossible in real-time; you need to wait 0.5sec to have the complete window). We can see the problem in another way: if you compute the mean of the window containing the last 1sec of data you have, this window is thus centered on a sample that was recorded 0.5sec ago. You thus end up with a delay of 0.5sec.

One thing you could do would be to extrapolate your position based on previous filtered data, using dynamic information (like considering a uniformly accelerated signal locally) and somehow combine this information with the current measured data. From what I know, this is the intuition of Kalman filtering. Here is a comprehensive explanation of Kalman filtering : http://www.bzarg.com/p/how-a-kalman-filter-works-in-pictures/

If the movement you are recording is slow enough, it might help reduce your delay.

1) 1sec moving average means that, for each sample of your signal, your compute the mean of a window of 1 second centered on this sample. So 1sec moving average = 1sec sliding window, simply.

2) For each sample, you have a window centered on it; so for a signal of 2400 frames, you compute 2400 windows. The idea is exactly like convolution (with a constant window of 1 second here).

You can get more info on moving average on matlab (with an intuitive image here) : https://nl.mathworks.com/help/matlab/ref/movmean.html#input_argument_d119e675984

About convolution : https://en.wikipedia.org/wiki/Convolution

check "One Euro" filter, it is more appropriate for Accelerometer data.

Like the colleagues said, you are asking the impossible here. Only ideal low-pass filters have zero phase. Meaning, for the filter to be causal and implementable, you have to delay it. Otherwise, you will need future values, which you cannot have.

Even if you try to predict the future values, are you sure this will not introduce more delays. If you want to predict, then use a Kalman filter like was mentioned.