Jack_of_Trades

iTrader: (17)

I've been trying to get down the exact path of the fuel map. I started learning how most stand-alone's calculate their fuel settings and it really makes sense that the stock ECU follows a very similar path. Usually with a stand-alone, the fuel map is viewable 3 ways; RAW, Injector Pulse Width, and Injector Duty Cycle. We have a handy little AFR formula to make the table somewhat seem like the correct AFR values but its nothing more than a formula for convenience. Here is a link to the AEM Engine Management Software, it will really help you see what a full layout should look like.

Someone can correct me if I'm wrong but "usually" the fuel map is nothing more than the IPW value for that cell. This is the base setting before ANY corrections have been implemented (i.e; Air Temp Compensation, Coolant Temp Compensation, Barometric Pressure Compensation,Boost Compensation, etc...). If you are viewing the RAW table, its in 8bit decimal form from 0-255. The IPW and IDC tables are just a formulated version of the RAW table for easier viewing/editing.
There are two types of variables used which I don't think we have looked for but are definitely used.

The first is the "MicroSec/bit" value which tells you how much the IPW time increases (in microseconds) for every decimal value you increment. So if you set the MicroSec/bit value to 100, for every decimal value you increment, the IPW changes by 0.1ms (1000 microseconds = 1 millisecond). You would want to set this value so the maximum IPW adjustment was slightly higher than the largest IPW value required on your current fuel map, to have the greatest resolution possible.

The second is sometimes called "LD0MPC" which is a scaling ratio. It changes the scaled value of the lowest load (a load value of 0) and expodentially increases the ratio all the way up to the highest load column with a 1:1 ratio. So the highest load column uses the 100 MicroSec/bit value and the it will slowly decrease as the load colulmns go down towards the 0 load column. The LD0MPC value is usually 8bit from 0-255 with 255 being a full 1:1 ratio in the 0 LOAD column. If you set it to 128, it would basically be 128/256= 50% of the MicroSec/bit value. So the ECU would start with a MicroSec/bit value of 50 at the 0 LOAD column and increase as it approached the highest LOAD column which would be a MicroSec/bit value of 100.

The main reason for the LD0MPC scalar is to improve the resolution in the lower load cells. Otherwise, jumping from a byte value of 4 to 5 would jump the IPW way too much in one increment. This helps cruising and idling greatly.

So those are two things I'd LOVE to find. Also, I wanna find how many sub's or correction values are tied to the initial Fuel Table cell values. During Disassembly, it seems when I graphed the fuel map layout it never references the fuel table, but rather the fuel table is the LAST setting in the chain.

I'll be posting some samples to better explain this stuff soon. Any input?

2k4EvoVIII

iTrader: (15)

Here are the graphs. First one is showing the High_Octane Fuel map being at the bottom in blue and everything that leads to it. The second one is just the top half of the same graph.





Chris

Jack_of_Trades

iTrader: (17)

Yeah, I was going to post an example of that shortly, thanks Chris

2k4EvoVIII

iTrader: (15)

BTW sorry about that Jack. I guess i should mention that is for ecu id 94170008.

Chris

bnice01

iTrader: (4)

nice info jamie, I like were this is going

Jack_of_Trades

iTrader: (17)

Ok, here is some visual aid to explain what I am looking for regarding the MicroSec/bit and LD0MPC values and tables.

This is the standard fuel map view with the AFR formula. Below are the actual byte decimal values for each cell.




To determine what the scaling factor seemed to be, I loaded a 3rd gear pull in excel and if you sort the data so it ascends the load column (lowest load readings to highest load readings), then create a new column which divides the IPW by the AFRMap cell value...you get the LD0MPC scaling variation.

Here is a sample file: SAMPLE FILE

This is a break-down of how the ratio breaks down from the lowest load column to the highest load column. The highest load column is always a 1:1 ratio with the MicroSec/bit value. The LD0MPC determines the lowest load ratio, then the ECU averages the ratio's for each load column in between.






Here is what I would LIKE to see the fuel maps look like, showing the actual IPW values (before all of the correction tables).

JohnBradley

iTrader: (30)

Wow, just wow...While this is totally totally awesome and I see what you could do with this, only because I am not totally in sync with IPW I would go with IDC or something.

OR AFRs that matched more or less.

I remember having to tune with raw values in some early software for Hondas and that always made things a little ... different when I couldnt just look at a number and KNOW it was gonna be something or not.

This would make tuning larger injectors a little more simple I spose.

Jack_of_Trades

iTrader: (17)

The best way to get used to this is to download the AEM stand-alone ECU software in the AEM forums and see how they lay out their fuel maps. They have 3 fuel maps, one that displays the RAW values, one that displays IPW values in milliseconds and one that displays IDC in percentage. If you edit one table, the other two change as well so they are all in sync. This is something i have NO IDEA how to do with tables. We'd need each cell value to reference RPM and LOAD tables, plus get thrown into a formula.

If we go with a fully closed loop wideband setup, using a direct analog input, we can set up the fuel maps to true AFR 'targets'. The car will work just like closed loop does now and will try to correct the AFR, probably around +/-5% per cell target. Once we (the ECUFlash community) unlock all of the fuel map variables, this is my next quest. The Zeitronix Wideband O2 sensors analog output has a sample rate of 1000 times per second! There are a few companies already running fully closed loop WB mapping, the reason its not the standard is the cost, thats it really. Most cars dont need such control, so why toss money into the car when most people would see any benefit? Well we see the benefit! lol

20Grockit

iTrader: (10)

awesome write up man. im sure this can come in handy to alot of us.

cossie1

This looks very interesting, although I will admit at the moment I don't understand the "in's and out's" of it all.

But I think t that you are saying with this formula, then what we tell the car to run fuel wise, is what it will run.

However....
That sounds awesome, but if the wideband sensor goes down, or out of calibration, won't we then be risking the engine ?

l2r99gst

iTrader: (2)

100us=.1ms (you have .01ms) I'm sure it's just a typo, but I figured I would mention it, so it doesn't throw anyone off.

Maybe I'm reading into this too simply, but having a display of one table three different ways in ECUFlash is easy. All you need to do is setup your XML for that table 3 times (the same address) with different scalings for the data. That way, when you edit any one of the three tables, all of them change accordingly, since you are really only changing one table, but it is viewed three different ways.

Is this what you were asking or am I just misunderstanding what you are saying?


As far as finding the variables in the ECU, if tephra, jscbanks, mrfred, etc, haven't already diassembled these routines and found these values, I would recommend posting your question on AktiveMatrix. Bez is also very good at this disassembly stuff and when he wrote his map-speed density patch, I know he had to disassemble the entire airflow routines and I am assuming fueling routines as well. I'm pretty sure he has disassembled most of the ROM that he had been working on. So, if anyone knew if these variables exist and where they are in the stock ECU, I would bet Bez would be a good person to start with. That way we can leave tephra alone so that he can work on his v5 code.

Eric

Jack_of_Trades

iTrader: (17)

Thanks, that was just a typo. Good eye, good eye


Well, I've done that before. Since the end result is always that you are changing the hex value in the rom, it does effect all 3 tables. My concern is how to have it accurately determine the correct values for IPW and IDC? IPW will need the MicroSec/bit value included in the formula. IDC would need the RPM value for EACH cell in the formula, correct? I would assume that you'd need to determine the IPW from the RAW 8bit value first in order to determine the IDC. And to determine IDC, you need to know the RPM in that cell. Is there a way to reference the x or Y axis value in the formula???



I figured I'd throw this out into the EVO-M waters first and see what interest it sparks before expanding my searches. So far, the best (and easiest) template to follow is the AEM EMS software found HERE. It helped me see how calculations are derived from different tables that affect the final values.

l2r99gst

iTrader: (2)

OK, I see what you are saying. I don't know if ECUFlash has that capability or not. If not, maybe it is something Colby can be asked to add.


Eric

GrocMax

Except if its anything like the earlier mits fueling strategy the table is actually grams per revolution, and being a volume air flow sensor there are corrections for baro and temp. The FSM and tech info manuals cover the basics pretty well.

If you are trying to compare from standalone strategies try Motec instead, you can change the fueling strategies from S/D to true MAS and about everything in between.

l2r99gst

iTrader: (2)

That's what I've been saying for a while and Bez's disassembly agreed with it. Load is really a g/rev value (at least the load variable that we commonly use). There are a number of load variables, with some compensated and some not, but in general, if no error conditions, etc, the compensated load variable is used.

That is how I came up with the equation that load/95 = g/rev. I don't know how accurate this is, but it seems to agree pretty well with most logs I have seen and some that I have correlated with actual OBD lb/min data.

The old DSM ECUs fuel and timing tables went up to about 2.1 g/rev as the last load column. If the load/95 is correct (or close) for the Evo, the stock VIII tables go up to roughly 2.74 g/rev (260/95) and the IX tables go up to roughly 3.16 g/rev (300/95).


Eric