Advanced LPF filtering

Post Reply
SVentas
Posts: 13
Joined: Fri Sep 16, 2011 5:29 pm
Location: Lithuania

Advanced LPF filtering

Post by SVentas »

Hi,

to filter noise from acc signal more effectively I replaced digital first order low pass filter (LPF) with Chebyshev LPF. This is not my idea; actually it came from AeroQuad software.
Chebyshev LPF is an infinite impulse response (IIR) filter. It has the following characteristics:
  • type – II (with ripples in stop band),
  • order - 6,
  • attenuation - 72dB,
  • normalized cut-off frequency – 0.1.
Filter is designed with GNU Octave using the following function:

Code: Select all

[b,a]=cheby2(6,72,0.1)

Normalized cut-off frequency of 0.1 means that if one samples acc 200 times per second (200 Hz) then the highest frequency that is present in the signal is 200/2=100 Hz (Niquist frequency) and low pass filter cuts-off all frequencies above 100*0.1=10Hz.
I suggest to use looptime = 5000. Then acc is sampled at 200Hz and filter cuts-offs frequencies above 10Hz.
To turn the filter on, one must set value of the acc_lpf_factor greater then 0 e.g. acc_lpf_factor = 4 (default value). Actual value of the acc_lpf_factor does not matter. If acc_lpf_factor = 0 then the filter is disabled.
It is easy to include chebyshev LPF into feature list, then one can choose between first order LPF (configurable by acc_lpf_factor) and chebyshev LPF. Maybe I’ll do it later.
I am not a filter designer; I am just an amateur programmer :). This online book inspired me to try advanced filtering techniques.
The binary (and code) attached is flight tested :).
Attachments
baseflight_chebyLPF.zip
6-th order Chebyshev type II LPF
(55.07 KiB) Downloaded 287 times
Last edited by SVentas on Sun Jan 13, 2013 9:06 pm, edited 1 time in total.

brm
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

Re: Advanced LPF filtering

Post by brm »

to be tested :)

but the cutoff frequency should not be below 200 hz.
the dynamic range from what we fly is invetween 150 and 250 hz - as a guess.

john ihlein created a motor vibration filter based on tschebyscheff filters --> baseflightplus
i did run into some crashes - as usual difficult to say the what the underlaying issue is.

we have two problem areas:
- high frequency noise
- low frequency noise (propellor wash)

we need a cutuff frequency at 200hz to solve the first issue - i don't care what method.
the 2nd one can be solved when having rpm feedback to install dynamic bandfilters.
here you need some fft analysis in front to get the spikes.

initially i had a cutoff frequency at 80 hz and upped it constantly.

brm
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

Re: Advanced LPF filtering

Post by brm »

do not put filter stuff in imu.c - move it to another more meaningfull file ;)
the mess gets more messed up.

SVentas
Posts: 13
Joined: Fri Sep 16, 2011 5:29 pm
Location: Lithuania

Re: Advanced LPF filtering

Post by SVentas »

Well... Maybe I don‘t understand what You mean :) ?..
The proposed Chebyshev low pass filter effectively removes (72dB attenuation) high frequency noise from acc signal. If acc’s sampling (reading) rate is 200Hz, then everything above 10 Hz (higher then 10Hz) is removed. In AeroQuad software (and baseflight_plus software) this frequency is set to 12,5 Hz.
In Kalman observer You implemented first order LPF (Kalman based) (only 6dB attenuation) which does similar high frequency noise filtering. If You set looptime = 3500 then acc is sampled ~300 times per second and bandwidth of acc is 300/2=150Hz (no way for 200Hz :D ).

If You need 150…200Hz bandwidth, then You have to sample (read) acc at least 400 times per second (Nyquist theorem) (looptime=2500) with acc’s internal digital LPF (DLPF) disabled (if one exists). However in baseflight code signal from MPU6050 acc and gyro goes to internal DLPF with cut off frequency set to 42 Hz.

Code: Select all

i2cWrite(MPU6050_ADDRESS, MPU_RA_CONFIG, MPU6050_DLPF_CFG); // where MPU6050_DLPF_CFG = 3 (42Hz cutoff)

So it is impossible to have 150Hz or 200Hz bandwidth with existing configuration!
If You use ADXL or MMA accs then it is possible to have 200Hz bandwidth. But I don’t understand why to have 200Hz bandwidth for acc when gyro bandwidth is only 42Hz :D?

brm
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

Re: Advanced LPF filtering

Post by brm »

put the mpu in fifo mode and read all the samples.
then you at get all samples at 8khz.
you can do the same for adxl - if you have one.
doing so i see that the mpu60x0 is not better as the duo adxl and mpu3000.
i have been using 4000 to 5000 as loop time.
the 42 hz is a matter of a configuration definition.

happy downsampling.

EDIT:
before i forget.
there is also a gyro with noise.
what about a filter for this device?

SVentas
Posts: 13
Joined: Fri Sep 16, 2011 5:29 pm
Location: Lithuania

Re: Advanced LPF filtering

Post by SVentas »

OK. Good point :). I agree that FIFO can help.
Yes, output data rate (ODR) of MPU60X0 with DLPF disabled and sample_rate_divider = 0 is 8kHz (otherwise ORD < 8kHz and with DLPF enabled ODR <= 1kHz).
IMHO 8kHz ODR on I2C is useless. Let’s calculate :). If one uses 5000 us looptime, then FIFO will contain 8000 * 5000 / 1000000 = 40 samples. Unfortunatelly MPU60X0 FIFO size is 32 samples. If looptime is 4000 then 8000*4000/1000000=32. Seems OK :). But… How long it will take to read 32 samples from FIFO via I2C @ transfer speed = 400kHz? 1000000/400000 * 32*6*16=7680 us (here 6 - number of acc + gyro samples, 16 – number of bits per sample, + best case scenario – transfer of register address in not included). So 7680 >> 4000 :(.
If one uses FIFO + sample rate divider or DLPF (ODR=1kHz) then bandwidth of ~200 Hz can be achieved.

I'd like to get back to the discussion about 150…200 Hz bandwidth. If the main loop runs less then 300Hz then everything that runs faster is insignificant (except for antialiasing filter). It just gets aliased.
Now let’s look at the complimentary filter:

Code: Select all

EstG.A[axis] = (EstG.A[axis] * (float)cfg.gyro_cmpf_factor + accSmooth[axis]) * INV_GYR_CMPF_FACTOR;

This code performs fusion of acc and gyro data, but looks like ordinary LPF :).
.gyro_cmpf_factor is big (200…400) so influence of accSmooth[axis] (new filtered acc value) is small. High frequency data of acc signal will not get through this filter. Only relatively low frequencies of motion and overload will have effect.
Sorry for being so stupid, but once again (if You are not tired :) )… Why do You want to have 200Hz bandwidth for acc? :)

P.S. In case of a gyro I fully agree that wide bandwidth is very important. I think that the only way to have a cleaner gyro signal is downsampling or usage of internal DLPF to avoid aliasing problems. But we have baseflight code with 42Hz gyro bandwidth. Changing precision of the gyro (increasing) drives baseflight and MultiWii crazy. I don’t have an answer to this issue.

brm
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

Re: Advanced LPF filtering

Post by brm »

hi,
hmm - the device is not optimal - it inserts noise by accidient as i would say.
therefore the approach having no lpf filtering installes and doing everything myself.

the dynamics of the copter and when i am going back to use madgewick, then i would not have a too heavy filter which filters out to much and therefore confuses the sensor fusion.

having my super simple kalman in place results in having a very twitchy vehicle - nearly unflyable.
but still very very stable.
i have to look at the data - i assume we have a bit too much noise there.

brm
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

Re: Advanced LPF filtering

Post by brm »

hi,

today i discussed the tschebysheff filter with our control law guy.
the first surprise: why an even number for the order.
the question is: http://www.dspguide.com/ch20/3.htm
with even tap numbers you are dealing with overshoots - one reason to start with uneven tap numbers.
the 2nd thought is: the filter is extremely aggressiv.

as i already said - i did run into a few crashes when steering hard manoeuvres.
a crash is always difficult to explain.

but i prefer a simple -3 db filter like the pt1 element - makes the filter very predicatble.
and also a constant delay is not a real problem.

once you are going to use or test one of these angle kalman filter used in the picopter you would not like any overshoots in the pre-filtering.
if you like i can commit my picopter like kalman filter - but for baseflight plus.

SVentas
Posts: 13
Joined: Fri Sep 16, 2011 5:29 pm
Location: Lithuania

Re: Advanced LPF filtering

Post by SVentas »

brm wrote:the first surprise: why an even number for the order.

brm wrote:with even tap numbers you are dealing with overshoots

I thought that Chebyshev filter always has overshoot in step response because of a filter design. It doesn't mater if filter has even or odd number off taps. Today I did an experiment and find out that it is true (3-rd, 4-th, 5-th and 6-th order filters overshoot if supplied a step function).
I don't think that 10 Hz the filter is very aggressive. If one uses LPF with acc_lpf_factor=100 and do not crash then 10 Hz Chebyshev filter isn't aggressive at all.
Maybe next week I will do some comparison between different kinds of filters :) ...

brm
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

Re: Advanced LPF filtering

Post by brm »

my first intention is to remove noise.
the overshoot you noticed causes the noise to be amplified.

the filter acts strange on agressive changes.

SVentas
Posts: 13
Joined: Fri Sep 16, 2011 5:29 pm
Location: Lithuania

Re: Advanced LPF filtering

Post by SVentas »

brm wrote:the overshoot you noticed causes the noise to be amplified.

Very strange conclusion, I would say :). The overshoot and ringing of Butterworth, Chebyshev and Elliptic filters is a response to a very special function – step or Heaviside function. All high frequencies from the step function are removed. Overshoot and ringing of the filter is in low frequency region so it is impossible for high frequency noise to get amplified.
The overshoot and ringing effect can be visualized during acc calibration process. When one places FC in level and hits CALIB_ACC button, ACC Z readings suddenly (during one sample) changes from 1G to 0 and stays at 0 for quite a long time. This is a step function and one can see overshoot + ringing on the ACC_Z graph. This is the price we have to pay for really good frequency separation and fast execution time. In the real world under normal conditions it is almost impossible to produce a step function. Therefore overshoot and ringing effect is negligible in filtering process of the real sensors data.
Yesterday I did some modeling and found out that previously proposed 6-th order Chebyshev filter using precision of the float variables rings/oscillates. Oscillations are not observed when using filters of the 4-th order.
To correct the oscillation problem and minimize overshoot in step function responce I calculated coefficients for Butterworth filter. This is the 4-th order IIR filter with 5Hz cut-off (looptime=5000) frequency (more then enough for complimentary filter with gyro_cmpf_factor = 400). Filter doesn’t oscillate using float precission and is implemented as a feature.
To enable Butterworth filter using CLI interface, one has to type “feature IIR_LPF” and acc_lpf_factor has to be greater than 0 (e.g. “set acc_lpf_factor = 10”).
Attachments
baseflight_butterLPF.zip
4-th order Butterworth filter
(80.18 KiB) Downloaded 281 times

ABL
Posts: 72
Joined: Tue Dec 25, 2012 12:12 pm
Location: Lithuania

Re: Advanced LPF filtering

Post by ABL »

I tested that.
Works great!
No tuning, just put old values here. Flying very well, much better compared to "original" baseflight. At least:
- wobbles on descent: not a lot
- yaw on descent: a bit, compared to ~90° on original baseflight

EDIT: Video about copter stability:
http://www.youtube.com/watch?feature=player_detailpage&v=sDCBvrkeJu0#t=65s
(gyro+acc+baro)
Also, by cropping 2.7K video i cut some oscillations, so they're not visible...
Actually, in fast-forward part it's swinging to sides. Does not visible on other modes (straight "throttle-up", level flying). I will try to lower P values on roll even more, didn't noticed such effect in baseflight.

My settings (not tuned - i just put old values, as said earlier):

Code: Select all

map taer1234
feature ppm
feature vbat
feature motor_stop
feature servo_tilt
feature iir_lpf
set gimbal_flags=16
set gimbal_pitch_gain = 25
set gimbal_roll_gain = -26
set gimbal_pitch_mid = 1350
set gimbal_roll_mid = 1650
set vbatscale = 112
set looptime=5000
set acc_lpf_factor = 10
set p_pitch = 64
set i_pitch = 18
set d_pitch = 30
set p_roll = 64
set i_roll = 18
set d_roll = 30
set p_yaw = 80
set i_yaw = 56
set d_yaw = 0
set p_alt = 18
set i_alt = 11
set d_alt = 7
set p_level = 58
set i_level = 10
set d_level = 20
Last edited by ABL on Wed Jan 23, 2013 8:37 pm, edited 2 times in total.

brm
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

Re: Advanced LPF filtering

Post by brm »

SVentas wrote:
brm wrote:the overshoot you noticed causes the noise to be amplified.

Very strange conclusion, I would say :). The overshoot and ringing of Butterworth, Chebyshev and Elliptic filters is a response to a very special function – step or Heaviside function. All high frequencies from the step function are removed. Overshoot and ringing of the filter is in low frequency region so it is impossible for high frequency noise to get amplified.
The overshoot and ringing effect can be visualized during acc calibration process. When one places FC in level and hits CALIB_ACC button, ACC Z readings suddenly (during one sample) changes from 1G to 0 and stays at 0 for quite a long time. This is a step function and one can see overshoot + ringing on the ACC_Z graph. This is the price we have to pay for really good frequency separation and fast execution time. In the real world under normal conditions it is almost impossible to produce a step function. Therefore overshoot and ringing effect is negligible in filtering process of the real sensors data.
Yesterday I did some modeling and found out that previously proposed 6-th order Chebyshev filter using precision of the float variables rings/oscillates. Oscillations are not observed when using filters of the 4-th order.
To correct the oscillation problem and minimize overshoot in step function responce I calculated coefficients for Butterworth filter. This is the 4-th order IIR filter with 5Hz cut-off (looptime=5000) frequency (more then enough for complimentary filter with gyro_cmpf_factor = 400). Filter doesn’t oscillate using float precission and is implemented as a feature.
To enable Butterworth filter using CLI interface, one has to type “feature IIR_LPF” and acc_lpf_factor has to be greater than 0 (e.g. “set acc_lpf_factor = 10”).


having ripple in the passband is ...
what would you guess?

http://de.wikipedia.org/wiki/Butterworth-Filter
the german wiki entry uses as coment: beträchtliches Überschwingen bei der Sprungantwort, verschlechtert sich mit der Ordnung
maybe you will use google translate.
http://www.dspguide.com/ch20/3.htm

i don't know what kinda accelerometer you have.
but when it is quitly sitting on your desk and it shows +-1G changes i would say it is defect, isn't it :D
but inserting +- 1G as step response would be ok to me.

one of the later findings is: everything above 10hz can be viewed as noise and could be filtered out - this is for the accelerometer.

edit:
before i forget - there is a simpler approach.
use the digital filters in the accelerometer.

Code: Select all

#define BITS_DLPF_CFG_10HZ                              0x05


for the mpu-60x0 just activate the filter for the upper frequency and you are done.
in essence this means reducing the cut off frequency from 42 hz as currently defined to 10 hz.
for the other devices just have a look in the datasheet.

SVentas
Posts: 13
Joined: Fri Sep 16, 2011 5:29 pm
Location: Lithuania

Re: Advanced LPF filtering

Post by SVentas »

ABL wrote:I tested that.
Works great!

I am surprised.
To be honest, my quadcopter with IIR LPF filter activated hovers (I can’t fly indoors) only a little bit better compared to original baseflight.
ABL wrote:Actually, in fast-forward part it's swinging to sides. Does not visible on other modes (straight "throttle-up", level flying).

I have no idea why this happens. I have to think...

Yesterday, I wrote a "toy". It displays acc data (one axis at a time) filtered by two different LP filters (baseflight hex and code attached).
Image
Red - raw acc data;
Green – acc data filtered by first order low pass filter (default filter) configurable by acc_lpf_factor;
Blue – acc data filtered by fourth order Butterworth filter.
If angle mode is activated, toy displays acc_Y data (Y axis). If horizon mode is activated (angle mode deactivated), toy displays acc_Z data (Z axis). If angle mode and horizon mode are deactivated, toy displays acc_X data (X axis).
Feel free to play :) and compare performance of filters visually.
Attachments
baseflight_filter_cmp.zip
baseflight toy to compare performance of filters
(92.17 KiB) Downloaded 241 times

brm
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

Re: Advanced LPF filtering

Post by brm »

>Actually, in fast-forward part it's swinging to sides. Does not visible on other modes (straight "throttle-up", level flying). I will try to lower P values on roll even more, didn't noticed >such effect in baseflight.

fast forward means having no smooth data stream - now you seeing the sideeffects ;)
a filter with n-poles is ...

i found out the problem with only having the blue light being active.
the toolchain is optikmzed for an m4 - when i went back to codesourcery all is ok back again.

brm
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

Re: Advanced LPF filtering

Post by brm »

>I have no idea why this happens. I have to think...
simple - lower the cutoff frequency for the digital filter and test again.

ABL
Posts: 72
Joined: Tue Dec 25, 2012 12:12 pm
Location: Lithuania

Re: Advanced LPF filtering

Post by ABL »

SVentas wrote:Yesterday, I wrote a "toy". It displays acc data (one axis at a time) filtered by two different LP filters (baseflight hex and code attached).

If i want "real-time" flight data, i need to attach second controller to multicopter frame, with radio telemetry, right?
Have everything, except some spare time ;-)

brm wrote:fast forward means having no smooth data stream - now you seeing the sideeffects ;)
a filter with n-poles is ...

Then why no oscillations on pitch axis, only roll (roll/pitch PID's are identical, copter CoG balanced)?

brm
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

Re: Advanced LPF filtering

Post by brm »

the dynamics of a copter is quite complex.
to verify the test i would re-configure the digital filter inside the accelerometer.
pls. adjust the filter settings to match a 10hz filter.
then we will see.

to obtain flight data you need some sort of memory: an spi or qspi flash chip.
with highspeed telemetry you have not enough bandwith to collect real time data.

why mentions the wikipedia:
- beträchtliches Überschwingen bei der Sprungantwort, verschlechtert sich mit der Ordnung
- significant overshoot in the step response, deteriorates with the order

>Then why no oscillations on pitch axis, only roll (roll/pitch PID's are identical, copter CoG balanced)?
fyling fast forward means the wind acts as dampening force - if the system gets instable it will break away on the roll axe.

SVentas
Posts: 13
Joined: Fri Sep 16, 2011 5:29 pm
Location: Lithuania

Re: Advanced LPF filtering

Post by SVentas »

brm wrote: to verify the test i would re-configure the digital filter inside the accelerometer.
pls. adjust the filter settings to match a 10hz filter.
then we will see.

WARNING! If someone is going to use and reconfigure ADXL345 accelerometer then it is fine. But if someone is going to reconfigure MPU6050 accelerometer then… "MPU-6000 and MPU-6050 Register Map and Descriptions Revision 3.2" page 11: "The DLPF is configured by DLPF_CFG. The accelerometer and gyroscope are filtered according to the value of DLPF_CFG as shown in the table below…".
IMHO it is not a good idea to fly with 10Hz DLPF on acc AND on gyro.

brm
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

Re: Advanced LPF filtering

Post by brm »

RTFM - verify the current config and then scan for the exception - maybe you will understand.

SVentas
Posts: 13
Joined: Fri Sep 16, 2011 5:29 pm
Location: Lithuania

Re: Advanced LPF filtering

Post by SVentas »

brm wrote:RTFM
.
Sorry, brm. Could You please, download the document "MPU-6000 and MPU-6050 Register Map and Descriptions Revision 4", scroll down to page 13 and read the chapter "4.3 Register 26 – Configuration".
It’s widely known limitation of MPU6000 and MPU6050 sensors discussed in many forums e.g. here
According to the table, currently MPU6050 is running at 1kHz sample rate and is configured for 42Hz bandwidth on gyro and 44Hz bandwidth on acc. That’s why I need a separate DLP filter in software.

ABL wrote:If i want "real-time" flight data, i need to attach second controller to multicopter frame, with radio telemetry, right?
Have everything, except some spare time ;-)

Well… You can fly with toy’s firmware because it is still flyable :). There is no need to attach the second board ;).
However, the purpose of the toy is to provide visual comparison of the signal filtered by different filters. You can shake multirotor as hard as you can or rotate multirotor as fast as you can and look for artifacts like overshoots, distorted signal, etc.
Fortunately, you will not notice any artifacts because Butterworth filter function or frequency response or transfer function (amplitude/gain vs. frequency represented by Bode diagram) is nice and has flat passband by definition:
Image
However, step response (amplitude/gain vs. time) of the Butterworth filter has an overshoot. Overshoots can be visualized during acc calibration process where two step or Heaviside functions are generated:
Image
There are one "negative" (a) and one "positive" (b) overshoots. As brm pointed out the overshoot gets bigger when order of the filter is increased.
Fortunately, step function has nothing to do with real world signals, because real world signals are smooth. So you are absolutely safe to use Butterworth filter.
Chebyshev type 2 filter is also fine because it has nice and flat passband, but has ripples in stopband:
Image
In general, higher order filter is better because it has steeper cutoff compared to first order filter or in other words higher order filter separates noise from signal better. They are successfully used in ArduPilot, AeroQuad, PiCopter and probably other flight control software.

brm
Posts: 287
Joined: Mon Jun 25, 2012 12:00 pm

Re: Advanced LPF filtering

Post by brm »

ahh, as usual the readings cause a problem:

where Gyroscope Output Rate = 8kHz when the DLPF is disabled (DLPF_CFG = 0 or 7), and 1kHz when the DLPF is enabled (see Register 26).


is this clear?
the term dlpf disabled as well?

what looks great on the paper is sometimes not really usefull in the real world.
for example using baseflight plus i get crashes - reproducable - when having the cheby filter active.

the multiwii sensorfusion is more robust with regards to phase delays as in mahony, bachmann and magdwick type sensor fusion.
when you name the openpilot mahony type sensor fusion then there is a bug which makes it more sensitive to errors. in this case
between the given accelerometer measurements and the expected direction of the gravity.
also the i-term integrator makes the system vulnerable to problems on the measurement side.
having propellors and motors with not so nice vibrations and the i-term collectur sums up quickly until the copte rcrashes.

from a theoretical approach the papers are ok - but you need to talk with a real control law guy.
i assume you have no knowlegde about control laws. when you lok at the table you mentioned then you see the column delay.
the delay is 0 (zero) which means no filter active - your interpretation is that a filter is actice.

now you need to explain what type of filter can/could have zero delay?
there is a solution for that ;)

olaf45
Posts: 24
Joined: Sun Nov 25, 2012 11:38 am
Location: France

Re: Advanced LPF filtering

Post by olaf45 »

Hi ,

I can't understand how the acc_lp_factor works .

"accLPF32[axis] -= accLPF32[axis]>>(ACC_LPF_FACTOR);
accLPF32[axis] += accADC[axis];
accSmooth[axis] = accLPF32[axis]>>(ACC_LPF_FACTOR);"

For me a LFP should be like :

fXg = Xg * alpha + (fXg * (1.0 - alpha));

Someone can explain the functioning ?

Thank

Olivier

timecop
Posts: 1880
Joined: Fri Sep 02, 2011 4:48 pm

Re: Advanced LPF filtering

Post by timecop »

Are you talking about 8bit version here?
They're probably using shifts because their retarded platform doens't have divide or multiply instruction.

olaf45
Posts: 24
Joined: Sun Nov 25, 2012 11:38 am
Location: France

Re: Advanced LPF filtering

Post by olaf45 »

Hello,

No, it's in multiwiiV2.2 but in an old release ( V1.9 ) the FLP was clearer :

"accLPF[axis] = accLPF[axis] * (1.0f - (1.0f/ACC_LPF_FACTOR)) + accADC[axis] * (1.0f/ACC_LPF_FACTOR);"

Regards

Alexinparis
Posts: 1630
Joined: Wed Jan 19, 2011 9:07 pm

Re: Advanced LPF filtering

Post by Alexinparis »

olaf45 wrote:Hi ,

I can't understand how the acc_lp_factor works .

"accLPF32[axis] -= accLPF32[axis]>>(ACC_LPF_FACTOR);
accLPF32[axis] += accADC[axis];
accSmooth[axis] = accLPF32[axis]>>(ACC_LPF_FACTOR);"

For me a LFP should be like :

fXg = Xg * alpha + (fXg * (1.0 - alpha));

Someone can explain the functioning ?

Thank

Olivier


imagine this function like this:
accLPF32[axis] = accLPF32[axis] + accADC[axis] - accLPF32[axis]>>(ACC_LPF_FACTOR)
= (accADC[axis]*(2^ACC_LPF_FACTOR))/(2^ACC_LPF_FACTOR) + accLPF32[axis]x(1-1/(2^ACC_LPF_FACTOR))

Xg = accADC[axis]*(2^ACC_LPF_FACTOR)
alpha = 2^ACC_LPF_FACTOR

accSmooth[axis] = accLPF32[axis]/(2^ACC_LPF_FACTOR)

probably less readable, but much more efficient than float calculations

olaf45
Posts: 24
Joined: Sun Nov 25, 2012 11:38 am
Location: France

Re: Advanced LPF filtering

Post by olaf45 »

Hello,

Thank for your explanation. Mathematically it's correct but the weight of the ACC_LPF_FACTOR became very light. ( no impact on the result )

Regards

milom
Posts: 2
Joined: Mon Mar 09, 2015 12:42 pm

Re: Advanced LPF filtering

Post by milom »

Hello friends, all the files are corrupted, can you repost the right files? thanks

milom
Posts: 2
Joined: Mon Mar 09, 2015 12:42 pm

Re: Advanced LPF filtering

Post by milom »

Rar not work but 7zip open the files..

Post Reply