"Real time" integration of signal with non-zero average

[Wuhtzu]

Hi everyone

I have a periodic signal obtained from an accelerometer with a non-zero average (small DC offset) and I'm trying to integrate it in "real time" to obtain the velocity.With real time I mean that I cannot record 10 seconds of data, then do the integration and so forth - the integrated signal has to be visible alongside the measure signal as soon as possible.

If I do nothing about the non-zero average of the signal the integral will ofcourse just keep growing which is not desireable. So what I am trying to do is to calculate the cycle average of the signal and subtract it from the signal before integrating. This causes the drift of the integral to get alot smaller - now the mean of the signal grow by 50% per 2 hours instead of 100% per 30sec. So quite a good improvement, but it's not enough since the measurement is going on around the clock...

I've attached 3 VI's if anyone wants to have a look

integration_test.vi a wrapper for pt by pt integration

amplitude demo signal_test.vi wrapper for generation of signal with some noise

Integration TopVI_test corrected avg.vi generates a signal, computes it's cycle average using Amplitude and Level Measurements VI, subtracts the cycle average from the signal and integrates it using pt by pt integration.

Do you guys have any idea on how to minimize the drift in average of the integrated signal even further? I guess it's an inherit problem with numeric analysis. The computed cycle average (for obvious reasons) oscillates up and down on the 3rd decimal and that will ofcourse cause the integral to oscillate as well. And since the integral is either growing or falling the oscillations of the cycle average must not add up to zero - if they did I guess the integrated signal would not drift, also just oscillate...

Any ideas are welcome. Thanks

Jonas C. Jeppesen, Denmark

[Wuhtzu]

Noone who has dealt with this kind of problem before?

Thanks again,

Wuhtzu

[altenbach]

Well, you need to know what is real and what is drift, and that depends on the data. Is the frequency of the signal constant and known?

If the wavelenght is constant, you can simply subtract the average value if you process exact multiples of the wavelength each time.

How does the real data look like? Is it similar to the simulated data in your example?

Why is there a while loop in the signal generator?

Why do you use the pt-by-pt integration if you process entire segments? The plain integral could do the same without any loops.

Why is there a wait in the toplevel loop, even though the loop rate should be determined by the signal timing?

[Wuhtzu]

Thank you for your reply altenbach.

Those issues you mentioned are clearly to be adressed. I will work on those first and  on computing the means from multiples of periods before comming to conclusions about the drift again.

Thanks, Wuhtzu

[MPCC]

Hey,

I was wondering if you had any success with your project.

I am also dealing with a DC offset in my accelerometer.

I am trying to get a high pass filter on my acceleration signal working that should elliminate the offset.

[Wuhtzu]

No, unfortunately not. I was told by my employer not to see it through at the time. It will be seen through at some point spacetime though.... how ever, it must be a question of getting the averaging in sync with the data collection and averaging over an interval large enough to ignore not having cm integral multiple of periods. If the signal is not periodic one would have to be more creative in order to obtain the dc offset. please also sort any results you might obtain 🙂

[WhyUseAnAlias]

This is an almost universal problem in signal processing.  Rick Lyon's summarized it in the "tricks" section of "Understanding Digital Signal Processing", and there's a lot of discussion about this solution for DC removal on the DSP web sites.

The solution is a simple (recursive, IIR) high-pass filter with a zero at DC:

    Yn = A*Yn-1 + Xn - Xn-1

where A is less than one but really really close to one, like 511/512 = 0.998046875.

The discussion works this way:  if you're using floating point numbers, just code it;  if you've only got an integer cpu, be really really careful about Yn-1 rounding errors.

Cheers