robs wrote:Black99rt wrote:muythaibxr wrote:Matt Yates (y8s) had an idea that I'm trying on ms3 that could easily be backported to ms2:
If the TPS value doesn't change more than <user settable> %, set TPSdot to 0. I *think* this will allow things to remain just as responsive while not false triggering. Essentially I've implemented half your changes.
This will help for detecting changes off 0% TPS well. It won't help with false triggers at cruise.
I think you may have misread Ken's posting. It's set tpsDOT to 0, not TPS. It should work at cruise. I'll leave your other points for the experts.
And Jason, I think we are at cross-purposes. My basic point is that the DOT values, the slopes, are best derived from unsmoothed data. So the sort of pseudocode I recommend would be:
Code: Select all
rawMAP = read_atd(MAP_UNIT)
MAP = smooth(rawMAP, ...)
mapDOT = calc_slope(rawMAP, ...)
as opposed to using the cooked values
Code: Select all
rawMAP = read_atd(MAP_UNIT)
MAP = smooth(rawMAP, ...)
mapDOT = calc_slope(MAP, ...)
Which is more the way the code currently is.
But, a confession. I was wrong again: I lied when I said that the lag value was a weighted average at all.... A lag value of (say) .75 gives you T(n) = T(n-1) + .75[T(n)-T(n-1)]. Since T(n-1) depends similarly on T(n-2), there is actually a little feedback from everything that has ever happened, except that truncation of fractions soon wipes that out.
Ah OK, this is an implementation called an IIR (infinite impulse reponse) filter. This particular on is a 1st order lopass filter with a variable time constant (lag). If you do it twice on the data (with the same lag value), what you are implementing is actually a 2nd order Bessel filter. These work very well.
And Jason, I think we are at cross-purposes. My basic point is that the DOT values, the slopes, are best derived from unsmoothed data.
Ahh. Given that, there are 2 approaches.
1) 2 separate filtered MAP values. 1st one for the lookup tables (I presume that's what the filtered MAP value in your pseudocode is for) and a 2nd for the MAPdot.
2) The 2nd approach is to filter the MAP "properly" so that it is useful for both the MAPdot and the other usage.
The problem with using unfiltered MAP values as you know is that noise will cause false triggering. If you say, "well, we can put a threshold on the MAPdot before triggering accel enrichment, and put a duration threshold before you trigger accel enrichment", well, that *is* a form of filtering. What I'm saying is, the proper overall filtering and triggering strategy *should* include *some* IIR or Bessel filtering.
As I alluded to in an earlier post, the proper filtering depends on the signal and noise characteristics, and the characteristics of the information contained in the signal. And, one of the rules of system design is: always band-limit your signal to that which is needed. Any unnecessary bandwidth will just allow noise to enter. Just as an extreme example. Let's pretend that the sampling rate of MAP is 1 MHz. Obviously a 500 kHz signal riding on it is noise and should be ignored.
With this in mind, here are a few questions to help us design the filtering scheme:
1) What is the sampling rate of TPS and MAP?
2) Can we assume that the largest acceptable fueling error is 10%?
2a) What is the shortest amount of time (fastest) that MAP can actually change by 10% due to a throttle input, or due to turbo spoolup?
3) What is the fastest that TPS can change?
Also, let's take a step back. Remember that the whole purpose of acceleration enrichment is this:
-- if MAP is rising rapidly the MAP may be higher than what the last injection point was calculated for. Adding fuel as a function of MAPdot is an attempt to correct for this. If deltaT is the time between the time injW was last calculated and the time time the intake valve closes, then the shortfall in fuel is proportional to MAPdot*deltaT.
-- the filtering on the MAP signal which *needs to be slower* than the TPS signal (due to intake manifold pressure pulses, see my thread)
http://www.miataturbo.net/showthread.php?t=48665
will cause an additional deltaT delay. (This goes back to what I said about signal and noise characteristics, determining the filtering you need) This is not a problem for when the MAP has been rising for some time already. The problem this creates is that when MAP actually *begins* to rise, the MAPdot will NOT show up until after some other delay.
-- the onset delay in MAPdot can be addressed by TPSdot.
-- what I'm saying is that you need a *combo* of MAPdot and TPSdot. MAPdot is used for most of the accel anrichment, while TPSdot is used to fill in just the initial part of tip-in where MAPdot is delayed. Importantly, MAPdot addresses the lag in the MAP signal as it rises as a turbo spools up *after* the throttle is already closed.