RomRaider

This is from seaching inside Denso ECU ROM calibration section.

AG572-1355 DBW ecu JDM 2003 Forester Turbo.
This should be helpful for NA engine tuners.

Do those ROMs have something like this?

I personally prefer AlphaN driving NA car against SD setup...

Discussion started here:
topic1070.html

Nice, not really sure about the NA cars though

Any recommendations for maf-less tuning on turbo cars?

I've got my SD code ready to roll other than a good compensation to account for varying backpressure.

My position is as follows:

search.php?keywords=SD+AlphaN&terms=all&author=&sc=1&sf=all&sk=t&sd=d&sr=posts&st=0&ch=300&t=0&submit=Search

I strongly believe that AlphaN (at part throttle) and SD (under boost) blending should be used.

I doubt that there is any simple approach for back pressure (and time variable turbine efficiency), intake temperature and hot weather humidity compensations. In such a case the MAF installed bitween IC and the throttle fills the bill.

I've been looking into this also.

Graham Bell's book says a couple things. Pure AlphaN is not recommended for turbo cars, and he recommends a SD system that cross references MAP with TPS, so in effect, a hybrid.

Now, what I'm not sure about, is how to implement this. I see two options:

Pull VE from SD and AlphaN tables, then use a map slider to blend them. I'm thinking the slider should reference MAP?

OR

Pull VE from SD table, then apply a compensation from a 3D table of MAP vs TPS.

As for turbine dynamics, I'm thinking a delta(throttle) that stores the peak delta, and decays the value. The decay would be adjustable and maybe dependent on some parameter(s). Then apply a compensation based on this value.

Thoughts?

The most straight forward approach for AlphaN\SD blending is a 3D "weight" table with appropriate atmospheric baro\intake temperature compensation applied to both VE values.

VE = (SD based VE) x W + (AlphaN based VE) x (1-W)

where W depends on (TPS, RPM).

I have come to something like this:
the less (AlphaN VE) gradient the greater W (that means that SD based VE is preferred).

Just look at SD and AlphaN VE tables and you will see what do I mean.

In order to have correct AFR I am running CL almost any time . There is a but. After "markable AlphaN_VE" changes I am running OL for about 0.3-0.5 sec.

Two kind of STFT are used ( probably VAG does this) - multiplyer (commonly used) and adder (is a must at low engine loads).

Yep, that's what I meant by the "slider", the stock ecu code contains a few of them, but most are unused.

Not sure about basing W off of TPS/RPM table, I'll have to think about it. MAP/RPM makes more sense to me.

I will likely end up coding a single subroutine that uses SD, AlphaN, and both tables for W, using switches to determine what runs. i.e.: can run either MAF, pure SD, pure alphaN, SD/AN blending, or SD/MAF blending, and choose blending (W) table.

All I can say is great discussion guys, and I can't wait for SD for an 11J '05 STi rom. I would definitely volunteer if/when testers are needed.

I tryed this for NA setup.
Formarly TPS\RPM is a table "on demand", MAP\RPM is a table "as resulted".

Intake pressure is oscillating (being dependant on the throttle position and engine\turbine dynamics). As a result fueling blending strategy varyes accordingly.

I have got oscillating part throttle acceleration when SD was preferred. This was not the case for AlphaN. From the other hand AlphaN is not very promising at full throttle with the turbine variable efficiency involved.

That is why I recommend to rely upon AlphaN (low load-middle to high RPMs) and throttle based blending weghting.

Avoid using swiching the fueling strategies on the fly. For driveability reason it is much better to use smoothed weighting functions\tables.

The next pattern probably clarifies the preferred fueling strategy (TPS - as X, RPM as Y)

SD SD SD SD
AN SD SD MAF
AN AN SD MAF
AN AN AN MAF

Good explanation, I was just thinking about effects of stabbing the throttle, but it makes more sense now.

The code I've written so far only blends two airflows, and isn't meant for on the fly mode switching, just reflashing the switches to test different methods to get empirical results and tune the SD/AN/MAF maps separately.

Triple blending as you describe won't be hard to code, maybe negative values for the third or blending one after the other.

To clarify, where is the origin? Bottom left?

Shame on me.
I missed your question..

Preffered strategies are as follows:

left-to-right - TPS 0-100%
Upper-to-bottom - RPM Idle-RevLimit
SD SD SD SD
AN SD SD MAF
AN AN SD MAF
AN AN AN MAF

Is that for N/A?

For a turbo, I'm thinking:
MAF should not be used at high RPM for a BOV or during boost transition with a FMIC
And AlphaN should not be used in boost as turbo dynamics will really throw things off
SD shouldn't be used at low tps because of pressure fluctuations

I've got the code compiled, just triple checking everything and tying up all the loose ends. I'll be testing on my car with no motor to check the code for big errors and make sure that MAF flow is still passed through for testers.

Will you be able to log MAF as calculated by the MAF sensor and MAF as calculated by SD?

Seems like it would be useful to be able to log both at once when dialing in the SD calculations / compensations.

MAF should never be used with open BOV. Intake air pressure allows this condition to be checked.
MAF installed pre-turbo should not be used under transitions. Throttle voltage rate and engine acceleration allow this condition to be checked.

SD is the only reliable air flow measure at low load low RPM.

It looks like SD, MAF, AlphaN (VE or EngineLoad) and used value for fueling together with Fuel correction should be logged.

After that an applicable fueling strategy (including tip-in enrichment) maybe justified.

The way I have it set up now, it uses two switches and always logs at least MAF and raw (SD) airflow.

Master switch selects output to MAF or SD/Blend
If SD/Blend is selected, the blending switch selects output to pure SD or blended SD

In MAF only mode; raw airflow (SD calculation) is logged along with MAF output. VE map can be interpolated with a spreadsheet to calculate the SD VE airflow for tuning VE map while running on MAF.

In SD/blend + Pure SD; MAF, raw airflow, and SD VE airflow are logged.

In SD/blend + Blend SD; MAF, raw airflow, SD VE airflow, and AlphaN VE airflow are logged.

I have it set up this way as the blending routine will add alot of CPU cycles as it requires 2 or 3 additional 3d map pulls, several floating point operations, and more memory access/store ops.