MPVI A/D input filtering

[Keith@HPTuners]

In 3.1 (Beta) and 3.2 (future), the MPVI inputs will be filtered a bit better.

You won't lose any resolution that you currently have, we'll just take more instantaneous samples and average them together to give you an even better read.

[B00STJUNKY]

I like, and approve of this. Thanks for hearing us, and listening. You guys rock!

[schpenxel]

I, too, like and approve of this

Do we have to do anything or is it automatic?

[Keith@HPTuners]

Automatic

[jcmg8]

Here are examples showing the smoothing. One log is 3.0.47, the second is 3.1.129 (with smoothing). MVPI1 is AEM ANA (AEM 30-0300 analog), MVPI2 is AEM 100PSIg(psi) For reference, EQ(lambda) is the AEM 30-0300 CANBUS

3.0.47:


3.1.129:

[dr.mike]

That's actually pretty amazing. Especially all zoomed in like that
It means that the total error from the all-digital CANbus filtering @100Hz ( From 1000Hz source ) deviates less than 0.01 lambda from the total of :

1. The analog conversion error in the gauge's DAC output
2. The effect of the gauge's ground offset compensation amplifier.
3. The MVPI A/D conversion error
4. The new MVPI filtering @ 100Hz ( from 500Hz source )

If anything, it looks like the new 3.1 filtering causes the A/D signal to trail the CAN data by maybe 10ms ( 1 sample )

[schpenxel]

Pretty amazing to me!

[Keith@HPTuners]

The new method:

So what the MPVI is doing currently, for A/D inputs, is, averaging the last 10ms worth of samples (probably 5-10 samples), and then spitting out the average.

So, what the user sees is the MPVI A/D inputs having resolution of 10ms, which is 100hz, that's a lot of data! We average them together so that the logs don't get too large in size.


The old method simply sent the latest MPVI A/D Input frame out every 10ms, whatever the most recent frame was, and dropped all the frames between the last frame that was dispatched through the scanner.

[MeentSS02]

The new method:

So what the MPVI is doing currently, for A/D inputs, is, averaging the last 10ms worth of samples (probably 5-10 samples), and then spitting out the average.

So, what the user sees is the MPVI A/D inputs having resolution of 10ms, which is 100hz, that's a lot of data! We average them together so that the logs don't get too large in size.


The old method simply sent the latest MPVI A/D Input frame out every 10ms, whatever the most recent frame was, and dropped all the frames between the last frame that was dispatched through the scanner.

I like this new method...I'll gladly clear more room on my hard drive for larger file sizes.

[schpenxel]

I agree.. that makes more sense to me. I noticed the latest beta was quite a bit smoother on external inputs. I'll give it some more time today.

Good news is i haven't had any issues with external inputs freezing since the fix was released.

[shmo925]

so is the scheme a pure averaging method? or is there some sort of low-pass or high-paas filter involved? (analog or digital)

[jcmg8]

Food for thought here. While having a smooth response is desirable, at the cost of added latency it is debatable IMO. While I'm not a calibrator by any means, I do know being able to see response(s) in order aids in troubleshooting resolution. If the MVPI is not in sync with the CANBUS data due to its own latency, let alone reduced sample rate, I'd prefer a bit more noise. For example, if running FI and have a manifold referenced fuel controller, I would want to see MAP and fuel pressure lockstep, not the Fuel pressure reading delayed further due to system latency. One question I have is, what is the sample rate of the ECM? Does it have different rate based on sensor IE knock sensor? Ok, gone a bit past MVPI sampling discussion. Back to MVPI, it apparently does some processing - it there any plan to update the unit with better processor/more storage (removable?)