"For TPS, should it be previous, mean, or recent? IE, where in the movement do we consider it to be for lookup purposes?"

That's a fairly dynamic thing. IE if you were to lug the engine at a *low RPM moving the throttle from 50% to 90% may have zero effect on the amount of airflow. IMO you may need a secondary flag/lookup, IE did the manifold pressure or mass air reading change.

The stuff I sketched up worked a bit more generically(fuel % vs RPM). If the calculated fuel(PW) went up or down, you know state changed, you don't really care what changed(TPS/MAP/MAF).

"you don't really care what changed"

You certainly *do* care about what changed!

If you're on it hard (WOT) and ramping up into boost, then PW is changing massively, and yet there's no requirement for any transient enrichment at all, or at least, very minimal and/or immeasurable.

MAF is laggy as hell and near useless for this, too.

TPS is typically used for this because it's in real time. Even MAP lags TPS slightly (even on an NA setup).

You're obviously right that a throttle that's *effectively* WOT when changed from current to real WOT will exhibit very little difference in behaviour, though :-)

Perhaps what's needed is to map actual TPS to effective TPS first, and do a delta of that. However you'd still have a non-linearity to take care of within the range where it did affect airflow, anyway.

Fred.

"You certainly *do* care about what changed!"

Some algorithms don't. In my experience the most responsive ones seem to be TPS based though. Typically TPS is in the front of the chain of events so it makes sense.

"MAF is laggy as hell and near useless for this, too."
"Even MAP lags TPS slightly (even on an NA setup)."

This kind of broadens the term "Transient Enrichment", in that you have to make up for changing operating conditions and input signals that are lagging.

"map actual TPS to effective TPS first"

I think something like that, even if super simplified would keep guys from over fueling in certain conditions.

I'm probably off, but to mee it seems like you need to monitor the acceleration of the signal (TPS) and have an acceleration threshold config. Essentially padding the position sensor calculated input when the value changes at a rapid rate as soon as the event is detected. I'm probably missing a lot of use cases here, but that's a simple handler for the detection. I have no idea what the lookup ought to be, but with each configuration table you add, set up become more difficult. If there were a single value that detects the event and possibly another value that pads the value (probably a binomial if you're looking for a sloped curve).

Notice: this comes from someone who doesn't understand the enrichment requirement well.

Edit: After reading a bit on MS, I realized that those tables are built based on configuration variables, that could essentially be building a binomial equation, so I retract the part of simple to set up. I also realized that the goal is to tune these values based on engine response, in a way that can be measured using a certain condition, such as CHT increased over time.

You can probably gauge the weight of the TPS movement by the reading the MAP sensor at the time of change. IE the lower the pressure the more change in airflow you can expect from X % of TPS movement.

Not so sure I would call it laggy as hell, ey?



yellow = rpm

I was asked today why I didn't respond to the above post, and the answer was that I knew I was being baited. Also that I was pretty busy and didn't have time to argue/debate. The setup above is impressively fast, however not all MAFs are like this. There are a few reasons:

• At least three different types of sensors, flap being worst.
• Most in-car MAF setups have really long pipes, especially turbo stuff.

Additionally, I wonder if the TPS signal in the above setup is over filtered?

Fred.

What I find interesting is the map signal going up while airflow signal goes down, then again nevermind, rpm is dropping and with that the ability to pull a high negative pressure is not as great as well as less airflow is being consumed.

in my ugly ms2 logs my nissan maf seemed as repsonsive as the map sensor was. of course we know ms2 datalogging is slow as get out.

Also iirc AFM are volumetric devices and don't measure mass flow. Would it be interesting to see later on a working vechile running freeems and using an afm, maybe for certain racing that requires all orginal sensors, personally i don't care for AFM.

lol
I would have said "corrected" "MAF is laggy as hell and near useless for this, too." I had to give you a little bit of shizzle, that statement was a bit too prejudice for me to brush off hehe. I did a fair amount of research to make sure I would get *good response, as I once held a *generic prejudice against MAF sensors. Prejudices are not always true. Don't get me wrong, I wouldn't call myself Mr MAF by any means, but they do/can server a purpose in certain applications. Who knows, maybe even transient fueling.....

A couple of thoughts come to mind after reading the above. Anybody feel free to call BS/critique what I'm saying. I also don't have any experience with boosted applications, so some of the following may not factor in those setups.

1. Model TPS and ignore MAP/MAF. After all we are talking about Simple Transient Enrichment. A changing TPS is what starts the dominoes of increased airflow, increased condensation, unwanted short term transient enleanment. MAP/MAF are handy, but in this case are (as Fred stated) a laggy representation of what just happened at the TPS. Correctly setup TPS based systems such as Alpha-N have always been very responsive & a major reason for that is that the throttle plate opening is the beginning of the chain of events that lead to grins/giggles when you floor it.

2. What we care about modeling/predicting is how much enleanment happens when we get a delta TPS. RPM is a great influence of this because of sheer air flow. For a given RPM (read that CFM airflow flowing in the intake) larger DTPS swings bring on greater wetting -> more enleanment. As CFM grows, the amount of enleanment become less pronounced as fuel cannot condense out onto the intake as easy. It takes X amount of time for the condensation to occur, so I'm assuming that with the air flowing faster, there just isn't as much time for this to happen, thus less enleanment when RPM goes up.

3. The two primary variables I see to build a table around would be DTPS and RPM. User's are very comfortable seeing RPM vs VE, & RPM vs AFR. RPM vs DTPS would follow those formats and be easy to comprehend. I think the map could be kept small (8x8) so as not to overwhelm the user with points to enter & the units could be %current fuel delivered. This map would give the initial enrichment & then decay based on time. I do think the decay should be faster with larger RPMS, but I don't know if another table is warranted. Maybe just a simple variable to count Revolutions. Set the enrichment to taper off at a set rate/Rev. Then the taper takes care of it's self....faster RPM faster decay.

More thinking aloud on RPM. A carb pump doesn't know anything about RPM, it just responds to foot pressure. You hit it harder, it pumps harder. DTPS is a great indicator of how hard you hit the pedal. I assume the carb engineers just sized the "PUMP" to account for the enleanment down in the typical RPMS (lower) where you normally get on it & allowed a slightly rich AFR if you punched it while already at a higher RPM. Slightly rich at higher RPMS is not the worst thing in the world anyway. Of course if your foot is already in it a little, the amount of punching it you can do is smaller & thus less enrichment in this condition.

Thoughts/Ideas?

Lenny