Open ryandoherty opened 9 years ago
So while we have solved some of the problems by implementing the quite period in RPM timing, this is still insufficient to customer issues. What we need is some form of software filter to eliminate the spikes as well. Frankly, our digital measurements are almost too good. Every little glitch or bump in voltage shows up in our measurements. Obviously while its good that we see this its not good for the end measurements.
Often the nature of the noise involves noise that occurs for a single sample noise spike. With a small buffer (1-3 samples) we can actively discard any sample that is above a certain percentage threshold. e.g.
5000, 5005, 20000, 5010 - we'd discard the 20000 value.
This filtering could / should be done on top of the existing exponential moving average filter.
I suggest to use simple Kalman filter for denoising. Simple moving average as a low pass filter makes it hard if not impossible to denoise it. Standard approach - anti-aliasing, denoising, low pass filter. Or anti-aliasing, predictive filtering (like Kalman).
@kosenko-max Got any good links to Kalman filter implementations in C that are open source? Been looking into these...
We already have an exponential moving average filter enabled on these inputs, same as the analog channels. The filter's alpha value needs to be exposed through the app jnterface. On May 1, 2016 7:27 PM, "Andrew Stiegmann" notifications@github.com wrote:
@kosenko-max https://github.com/kosenko-max Got any good links to Kalman filter implementations in C that are open source? Been looking into these...
— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/autosportlabs/RaceCapture-Pro_firmware/issues/139#issuecomment-216094203
Unfortunately exponential moving average in the form of IIR is not really denoising anything - if you have noise spikes - it influences signal until it will be lost with a series of rounding. Single spike can easily shift data out for significant amount of time from the true value. And it most probably going to get new spike before it will calm down. And while data will look smooth it will be far away from the true value all the time. It can be fixed by application of properly tapped FIR over median values, but then you might find that 1000hz is not a lot.
So I'm suggesting to spend more time eventually on a subject of antialiasing and predictive filtering before implementing controls in GUI. Controls in GUI would be necessary since nature of data is different and one size would not fit them all.
An effective software filtering technique can be employed by creating a dead zone / ignore zone X uS after a main pulse has fired. This would help mask noisy ringing typically exhibited after an ignition pulse.
The dead zone / ignore zone should be configurable (in uS) and the timer needs to be configured for rising edge or falling edge signals.
Requires API change. Needs analysis if all timer channels can accommodate this feature, or if only one can do it. The current solution is to use a secondary timer to provide the 'dead zone' feature.
Info about noisy signals: http://autosportlabs.net/CoilX
Preliminary firmware that was able to accurately read raw noisy RPM signals without any hardware filtering: https://github.com/autosportlabs/RaceCapture-Pro_firmware/tree/v2.8.1_rpm_noise_filtering