mrfred

iTrader: (50)

Roadspike's 3D SD implementation utilizes a 2D kPa -> load conversion table and then a 3D table of VE vs rpm and kPa. Is there any reason not to combine these into a single 3D table of load vs RPM and kPa?

211Ratsbud

iTrader: (1)

Question:

Would that effect the ability of the maf > sd conversion by logging a maf function to create a 3d table?

Are we pretty much under the agreement that kpa : load is 1:1 in a 3d ve set up anyways?

mrfred

iTrader: (50)

Nope. Plan is to allow a baseline VE tuning mode where SD load is calculated and loggable but MAF still controls things. This should be very useful for the self-tuners.

It seems like a reasonable starting point.

EvocentriK

Not many actually run 1:1 though, the 500kpa is not 1:1 with load in the stock map, and from what I've read most don't run it 1:1 after tuning. Anything that makes SD easier to set up I'm down for, I'm just starting out and it's doing my head in, the how to establish the VE table values from MAF logging etc.

211Ratsbud

iTrader: (1)

Can you reasonably make the ve table smaller? Look at donners 8858. It's perfect IMHO.


https://www.evolutionm.net/forums/at...7&d=1349397883

When converting with dtt method I believe he states that kpa : load should be 1:1. That's his method and very reasonably I don't see everyone doing it that way. 2d sd guys rape the mapve: load table for sure

I'm all for the combined table that you speak of especially I'd it simplifies various tables that aren't always obvious to be adjusted such as the kpa load etc.

Evocentrik what is the problem with your conversion process? I just started logging ve from my maf set up myself and building a ve table. Maybe I could help a little? Pm me

Previously I set my fuel map to desired afr and adjusted my ve to suit .

mrfred

iTrader: (50)

With a combined 3D VE and load translation table, the user is free to enter whatever load they want, effectively allowing any baseline ratio of kPa to load.

It will definitely be smaller than the tephra big maps tables, but maybe one or two columns wider than donner's. One of my sanity check's is that it fit on a 1024x768 screen.

wreckleford

iTrader: (2)

I think having load in the table would make things simpler and quicker to tune. I don't see any downside.

211Ratsbud

iTrader: (1)

I don't quite understand how they would be combined, do you have a quick and dirty way to illustrate ?

90zcrex

iTrader: (11)

I'm also a little confused on how you will have all 4 parameters (VE,KPA,LOAD,RPM) on the one map?

JohnBradley

iTrader: (30)

So rather than the numbers being imaginary the current load numbers would in fact be kpa or PSI or whatever we want to set it to and then tune?

That's just strict adherence to the proper MAF voltage and then dropping all the airflow conversion stuff correct? No more of the supposed ariflow hz /rpm * 852 stuff?

mrfred

iTrader: (50)

Here is a quick example. For the Karmann Vortex MAF on the Evo, the master load is not corrected by either baro or IAT. That gets done later. With SD, the master load does not have an IAT correction, but it inheriently has a baro correction built into it. At a steady altitude, SD master load is quite easily used in place of KV MAF master load. In summary, I'm producing the same kind of load that John Banks' SD patch produces, but I'm doing it with a single 3D table rather than two 1D tables.

Perhaps what you guys are slightly confused by is how I set up the boost (kPa) axis. There is one additional table that will convert MAP sensor voltage to kPa, but that table is fixed by each sensor type and it not a tunable table.

211Ratsbud

iTrader: (1)

Gotcha! So you tune or fine tune the master load value in that table and the axis are the same! Basically were stepping away from the tuning of ve% and tuning load values. Cutting out redundancy.

After all it never really was ve% right?

And will we need a baro value functioning from now on?

we can log master load on maf to insert into kpa columns ?

mrfred

iTrader: (50)

There's no getting away from the MAF Hz variable that we see throughout the code. Its built into the core of the airflow and fuel metering code. It is not the actual raw MAF Hz variable as calculated from the pulse counts at the KV MAF. The actual raw MAF Hz variable is used only to calculate the master load. The MAF Hz variable that we see throughout the code is actually calculated from the master load variable and is a reincarnation of the MAF Hz. You can think of it as a filtered MAF Hz value. At any rate, its in the code and there's no deleting it. The MAF Hz values that result from SD load can be thought of as estimated airflow numbers.

If you are referring to the MAF compensation or MAF scaling tables (they actually do exactly the same thing), those tables only affect fuelling and have nothing to do with the load calculation in any way. They can be set to have no effect on fuelling, or they can be used as fuel only compensation. Since it works as a function of airflow, it lends itself naturally to acting as a sort of VE compensation table that affects only fuel.

mrfred

iTrader: (50)

VE is real, but I'm just including it in the table by virtue of using actual master load values. Its still up to the tuner to get the load values right.

Baro is still needed for dealing with idle and startup and perhaps other things.

Yes, it will be possible to log rpm, kPa, and MAF master load as long as the MAF is still installed.

211Ratsbud

iTrader: (1)

I thought baro never worked and we just used a set value?

Where does the baro read from once you delete the maf?

Donner gave me the baro read address for 8858 but I never used it.

Last thing .. + 1 or 8858(lol )