richardjh

Hi all.

For anyone who has a tuned Ralliart still running on stock TD04, listen up. Your ECU isn't calculating load very well during spool-up.

First things first...

** Special thanks to tephra for his invaluable research, input and assistance **


Okay, some background. As tephra posted up in late 2010, Evo X and Ralliart ECUs calculate load using three inputs...

1. MAPCalcs (sourced from the "3 x MAP tables", compensated by ECT/IAT/Baro)
2. IMAPCalcs (the above item, but zero-interpolated, and "messed" with)
3. MAFCalcs (sourced from the MAF Scaling table)


Item 1 is pressure-related. Item 3 is airflow-related. Item 2 is a load of old crap, but does have its uses. More on that later.


The ECU simply looks at these, chooses the MIDDLE of the three values, and bases its subsequent load work on that choice.

As it turns out, IMAPCalcs is likely to be lower than the other two, so it comes down to a choice between MAPCalcs and MAFCalcs.



Now here is where it gets interesting...

What you get isn't just the lower of the two. The final "Chosen" load is subject to LIMITS as to how rapidly it can rise and fall. The ECU applies Ramp Rate restrictions to this Load value, presumably to aid in delivering smoothness and sanity.


But here's the thing:

The factory ECU's Upward Load Ramp Rate is not sufficient to handle a tuned Ralliart's turbocharger spool-up rate.

Here's what you see when you log MAPCalcs, MAFCalcs, IMAPCalcs and ChosenCalc during spool-up.


See Exhibit (A)...



Check out the point highlighted with the vertical red line.

At this point, note that MAPCalcs (237.5) is lower than MAFCalcs. It is therefore The Chosen One.

But... ChosenCalc is lagging behind. It is only at 225.0. This is due to the factory Load Ramp Rate limit being enforced.

In my testing, I've seen Chosencalc lag as much as 18 behind MAPCalcs.

What does this mean in the real world? Well, an artificially low Load value will generally mean...

• Leaner fuel mixture.
• More advanced timing.
• Increased chance of knock.
• Weird SST stuff, like reduced clutch pressure.

...and this is all right when boost is peaking. Not exactly the best time to be short on fuel and long on timing advance.


Of course, the outcome all depends on your mods and tune. Your MAF scaling, MAP tables, fuel, timing, MIVEC, exhaust, intake, etc. all have a bearing on things. Most important is how your tuner approached things when setting the above. Good tuners will typically leave a safety margin. I expect many tuners will simply review the spool-up AFR logs and "skew" the 160+ Load areas of the fuel map to add in extra fuel.

That's exactly what I did. I've been bashing my head against this issue for 18 months now.

Another factor in all this is how the car is used. For the average street-driven RA with boostpill, we know from experience that the odd WOT squirt won't make the engine explode. Base Map users, don't get your panties in a knot.

But, you see... mine gets tracked. It sees plenty of throttle-stomping - WOT at 4000-5000rpm, again and again. That's why I've been bugged so much by the mystery of lean spool-up AFRs.


So...

Now that the mechanism REALLY at work here has been unmasked, we can deal with it properly, once and for all.


Thanks to tephra (this whole thing carries a "thanks to tephra" stamp), the relevant Load Ramp Rate variable responsible has been identified. The "fix" is very easy... just double the max allowed Ramp Rate for this particular load increase situation.

And here's a test showing the outcome.

See the same Exhibit A section in this log graph...





And voila! ChosenCalc is exactly 100% in line with MAPCalcs. So much so that the graph line of the former is completely obscured behind the latter, right through spool, to peak load.

You only see ChosenCalc once it starts to follow MAFCalcs... once that drops down and becomes the lower of the two.


This was same spool-up, rpm, MAPCalcs, etc. etc. Directly comparable tests. At the same highlighted point as before, MAPCalcs = ChosenCalc = 239.063.

The fix that I applied? I simply changed that pesky Load Ramp Rate from 3.5% to 7.0%, giving Load the ability to rise fast enough.

Ultimately, the solution was a 1-byte edit to the ROM. This allowed me to discard a whole custom "enrichment" patch, a custom AFRMAP compensation table, plus some dynamic timing reduction edits. Much cleaner!


I don't think this will be an issue with Evolution X turbochargers, as the spool-up load increase won't be quite so fast.


[update]I've uploaded the EcuFlash XML definition for this for all the common Ralliart ROMs. It's now available from goldenevo.com, and looks like this:





In due course, I'll provide a clean and easy way to log the various load calc variables. I'll post up more details here as I go. In parallel, Tephra is posting up info on the defs and mechanisms that have made this 'ere stuff possible.


Cheers,

Rich


PS. What's the mysterious "(B)" marker in the first graph, you ask? Well, that's another story! Once you start logging the three load inputs, you see all kinds of crazy. There's another weird mechanism affecting MAPCalcs and IMAPCalcs, and "refining" it can smooth out some unexplained little kinks in the load graph. That's going to have to wait for its own thread, though... real soon now.

richardjh

Reserved for additional awesomeness.

Rich

Veronica

iTrader: (2)

I
Think
I
Understand (great feat, eh?)

Wow - the complexity boggles me (from an engineering / development standpoint)... My first assumption is, 'it is there for a reason' and we just need to eventually figure it out (since, alas, we don't have development documentation

But now i suspect there is more 'leftover DNA' (code that serves no purpose now, but once did... our ECU's 'Vestigal Tail' as it were...

meh. [shrug]

nunyas

iTrader: (2)

so, how long til Reaganomics allows this to show up in the basemaps?

deprydation

iTrader: (1)

This is brilliance. To be honest I have noticed funky load scales on a few logs I have. This is probably the problem.

One question.

When you adjust the load scaling like this do we need to make any tweaks to the CPRU maps to compensate for a quicker scaled load?

sstevojr

iTrader: (7)

Nicely done Rich!
I cruise the freeway right around 3k rpm, which is also my major wgdc event. So when I give it a bit of throttle in 6th it's very common that is takes a moment for cpru to grab on.
Following you logic, I'd bet the "signals" are gettign crossed to the TCU as well, since Load governs all (as of now). Yes I've seen the same "not quite right" Load value when getting on throttle heavily. As a work around I've "blocked" my timing.

TLDR; I think this will have an impact on the TD-05's IF they are tuned aggressively.

Impatiently waiting......

richardjh

I guess it's so that load doesn't bounce all over the shop. The ECU takes inputs from several sources, and uses it to "drive" the final load calc up or down. It's a matter of balancing smoothness vs. responsiveness.

No way would the factory Ralliart tune ever suffer from having this Load Ramp Rate set at 3.5%. It's not until you hit it with aggressive MIVEC, boost pill, etc. that you start to outstrip the default Load "delta" limits.



The "Load Ramp Rate" stuff that tephra found involves half a dozen items. Some are individual values, and some are 3D tables. The one that really matters for this spool-up situation is an individual "1D" value, and is used when Load > 70.

That particular magic number is the lowest Ramp Rate % of all.


Your instant throttle-on thing probably isn't related to this - it would take a wee bit of time to get Load over 70. Probably 0.1 to 0.2 seconds, I'd say. So the higher Load Ramp Rate values would be in play for that initial period.


Rich

parralegend

Rich, you must view life like the terminator calculations happening to everything you see.

It's a great asset to have you investing your time into working out the toughest of problems, thank-you.

Thanks to Tephra as well.

richardjh

40% Terminator
40% Marvin the Paranoid Android
20% ED209 (the occasional "slight" overreactions, and the embarrassing clumsiness, lol)

Rich

parralegend

Just open your own tuning shop I'd drive to Melbourne for that lol

richardjh

No chance.

And I'm not in Melbourne, anyway, lol.

Rich

parralegend

Serious question though, how much does this pick up response rate especially for your e.g. when your on the track? Will you reach full boost/sustain faster & longer? *Victoria same s***

richardjh

I don't expect much difference in performance with this change. In my graph example above, the whole divergence/convergence of MAPCalcs and ChosenCalc occurs in less than half a second.

I do reckon it'll run more cleanly with the fix applied, though.

At the track, I've always had knock issues right where this load divergence occurred.

Hopefully, I'll see less spool-up knock with this Load Ramp Rate thing tweaked. I'm testing out my tune on the track this afternoon, so fingers crossed.

Rich

sstevojr

iTrader: (7)

You can see the improvement in the rpm line itself, a smoother breathing engine .

richardjh

Nah... I just had more items being logged in the first graph.

...and my netbook is very low power.

Rich