Speed-Density & Barometric correction

[tmbryhn]

I'm working on a new basemap for another aircooled VW engine running 3D printed intakes. This config has one single TB on each side feeding two cylinders - iow. not a perfect ITB setup, nor a typical plenum setup where all intake runners are merged in a common plenum.

It's the first time I'm tuning such a setup, and I've decided to start out with the Speed-Density strategy.
The ECU incorporates 2x MAP sensors; one for reading MAP between the two intakes (T-ed together), and one for realtime barometric reading.

Assuming Barometric sensor is activated under "Baro sensor" in TS;
does the SPD strategy or equation implement any form of theoretical correction based on measured baro pressure, thus using the "Baro Correction" table only as an additional correction (1), or is the baro correction solely based on the values in the "Baro Correction" table (2)?

If (2) is true; how would you suggest one approaches the task of making a barometric correction table from a theoretical point of view?

I've been checking out some random speed-density maps @ RusEFi Online, but none seem to have any other values than "1.0" scattered across the "Baro Correction" table.

As a sidenote, Megasquirt has two similar strategies for SPD; "Speed Density" and "%Baro":
The latter, as far as I have figured, takes the Baro pressure into account and calculates the ratio between MAP and Baro, rather than using the raw MAP value as a load factor. This makes the load scale a percentage scale, thus letting the ECU access the entire load range regardless of barometric pressure limitations (one would never access 101kPa at the top of Pikes Peak in regular SPD mode).
To me this strategy makes more sense from the aspect of measuring actual volumetric efficiency, as the engine in principle would pump the same volume for a given throttle position/RPM regardless of air density.
Is this "%Baro" feature implied in the SPD strategy for RusEFi?

Any relevant link covering this subject would also be much appreciated. Thanks for the input

[tmbryhn]

I made a density table as a function of ambient pressure and temperature.
I assume that the sole purpose for the barometric correction factor, is to adjust the calculated required fuel for variable air density as a function of static ambient pressure.

Barocorr.jpg (160.71 KiB) Viewed 2706 times

I found the RusEFi Speed Density equation in the online manual. As far as I can see, there's no barometric correction part to this calculation:

"
fuel_squirt_duration = injector_lag_curve_lookup(V_BATT) + warm_up_curve_lookup(COOLANT_TEMPERATURE) * (cylinder_displacement * VE_table_lookup(RPM, MAP) * MAP / GAS_R * charge_temp(COOLANT_TEMPERATURE, INTAKE_AIR_TEMP, TPS)) / target_afr_table_lookup(RPM, MAP) / injector_flow

where: MAP is the average of multiple 10KHz ADC readings within specified camshaft angle range, value in kPa
VE is intake volumetric efficiency coefficient
GAS_R is gas constant
"

Where and how does the factor from the baro corr. lookup table fit in?

Feel free to move this thread if it fits better in another sub-category.

[mck1117]

The result from that table just gets multiplied in at the end, we make no automatic correction.

Somewhat counterintuitively, that actually isn't the correct shape of that table. The MAP sensor already compensates for almost all of the change on the intake side of the engine, so you're actually compensating for the reduced throttling losses and easier exhaust flow as the baro pressure drops (ie, the values are >1 when below standard pressure).

Do you need this table though? It's set to flat 1.0 for me. Closed loop fueling will clean up any small variations, so you don't really need it so long as you aren't regularly driving from sea level to 3000m and back.

[mk e]

For a long I saw no reason for a baro sensor as the only people loving them were MS user and they had a specific issue where the the code was set up for baro and if you didn't have one would read the MAP at key on and store the value as baro and that makes a mess of the mixture if you dirve up or down a mountain.

But for most applications there is more to it than that. Normally WOT is tuned for max power and cruise is tuning to stoich if you have a cat or best mileage is you don't and and connecting those something in between. I usually keep shoich to about 70 or 80% throttle unless there is a heat issue. Anyway, what this mean is the ECU is determining driver intent (hp or economy) base on the MAP value and if you say drive up a mountain and MAP drops so even at WOT ECU assumes you no longer want full power and gives you ECO mixtures just like the table tells it to do. Similar but less issue with weather changes.

The issue is one sensor can not measure 2 things, so while the MAP correctly tells the ECU the air pressure it can not know if that pressure is caused by the driver opening/closing the throttle or a change in ambient conditions....the only way to tell the ECU what the driver's intent is is add a second sensor. TPS can be use but its difficult. The easier answer is to add a baro sensor and make the tuning table axis MAP/Baro then WOT is always 1 or 100% load and everything just kind of works out. Air density still gets calculated base on MAP/Temp/VE, but the mixture desired mixture pulled from the lambda table wants to be base on %load (MAP/Baro) rather than MAP alone if you want it to give desired mixture under all conditions I think.

[tmbryhn]

That's exactly my thought too regarding the "%baro" feature as described above. Would've been nice to see this feature implemented in RusEFi

[tmbryhn]

Barometric correction table is greyed out when in Alpha-N mode.
Can this be fixed on the next release?