Low-Pass Filter: Optimizing Alpha

Android Accelerometer: Low-Pass Filter: Optimizing Alpha

The low-pass filter has a compromise between smoothing and latency. Different applications will have different priorities and it will take some experimenting to decide the best compromise between a smooth signal and a latent signal. 

Author: Kaleb Kircher

Version: 3.0

Refactoring History:

v1.0 Kaleb Kircher Authored
v2.0 Kaleb Kircher Refactored
v3.0 Kaleb Kircher Refactored

Copyright: 2012-2015 Kircher Engineering, LLC

Associated Applications Projects: 

Acceleration Explorer for Android:

 Acceleration Explorer promotional graphic

Acceleration Explorer is an Android code example and working application. The application allows users to plot and log the outputs from the devices acceleration sensor in real-time. The diagnostic mode allows the user to investigate the noise, offset and skew associated with the acceleration sensor.

You can download Acceleration Explorer for free from the Google Play Store! 

Google Play icon

You can fork the Acceleration Explorer source code from GitHub!

GitHub icon

The Low-Pass Filter:

This post takes off from Low-Pass Filters: The Basics. For the examples, I used the Wikipedia low-pass filter.  In this version of the low-pass filter, a value of alpha that is close to 1 means that very little smoothing is occurring and there is almost no latency in the output. The time constant is the relative length of the signal that the low pass filter will act on. Any signal much longer than the time constant will be passed through the filter, any signal shorter than the time constant will be filtered out. For the purposes of this article, we will just work with a static alpha and assume a constant sample period, dt. However, you should be aware that a dynamic alpha should be used to accommodate different devices with different sensor output frequencies. This process is described in Low-Pass Filters: The Basics.

The Wikipedia LPF Code:

For these examples, we will use the most simple version of the LPF.

static final float alpha = 0.9f;

public float[] lowPass(float[] output, float[] input, float timestamp)
	output[0] = output[0] + alpha * (input[0] - output[0]);
	output[1] = output[1] + alpha * (input[1] - output[1]);
	output[2] = output[2] + alpha * (input[2] - output[2]);

	return output;


Alpha 0.9:

I used a Droid Razr that delivers updates from the sensor about every 50Hz, or 0.02 of a second. The time constant, T, is assumed to be T = dt*((1-alpha)/alpha) where dt is the sample period (time between sample updates, i.e 0.02 seconds). If we assume an alpha of 0.9, this filter has a time constant of 0.002 seconds, so it will only filter out very short signals. You can also look at the time constant as lag. A large time constant will produce a large amount of lag, but a very smooth signal. A short time constant, like we see here, will produce a noisy signal, but almost no lag.

Note that while is it difficult to see two the two plot lines here, there are in-fact two. The low-pass filter responds so quickly that the lines essentially overlap the entire time. You will also notice that very little, if any, smoothing occurs. This is slightly more evident in this plot.

Alpha 0.5:

This filter has a time constant of 0.02 (equal to the sample period). A filter with an alpha of 0.5 is more effective at smoothing the signal than an alpha of 0.9. Since the time constant is only 0.02, you should expect minimal latency from the LPF.

Alpha 0.1:

This filter, with an alpha of 0.1, offers a considerable amount of smoothing.  The low-pass filter has a time constant of 0.18 seconds at 50Hz sample period. Any signal that is shorter than 0.18 seconds is being filtered out. Here we can see a significant reduction in the amount of noise, however, there is now a latency of at least 0.18 seconds.