Speed Density Implementation Discussion
Thread Starter
Joined: Feb 2007
Posts: 9,486
Likes: 67
From: Melbourne, Australia
It sure will. And of course I will need testers - so they obviously will get their ROMID's done first.
However let me get it working first - We are still a long way away from having something workable
However let me get it working first - We are still a long way away from having something workable
Excellent. I guess i'm going to have to machine myself a part so i can replace my stock mdp sensor with something like the zeitronix 5 bar map sensor or a 3 bar.
I just skimmed through most of this thread. Lots of good discussion. I can't add a whole lot other than a quick and easy fix for the baro input. A 1kOhm resistor in place of the sensor gives a 100kpa reading to the ECU, which is what most people see anyway (unless you live in the mountains). As far as where to put the IAT sensor, I had mine in the manifold, but with water meth, I was getting really erratic readings whenever the sensor got wet. I moved it to my UICP pre-nozzle, but I haven't run it much in that location.
I don't fully understand how Bez's patch works, I just know how to adjust the tables to give me the results I want.
Tephra, when you get a beta working version, I have the setup to test it already and unlimited dyno access. I think I got my poor sealing head issues fixed (stupid block dowel pins), so I'm ready to roll.
I don't fully understand how Bez's patch works, I just know how to adjust the tables to give me the results I want.
Tephra, when you get a beta working version, I have the setup to test it already and unlimited dyno access. I think I got my poor sealing head issues fixed (stupid block dowel pins), so I'm ready to roll.
Alright Gents (and Ladies if there are any reading)
How about something like:
Note the 25 point 'load' axis, don't take too much notice of the AFR map, its just a stock one copied and then extended to hit 25 columns.
Using my current formula/scaling (x/4096) we can specify down to 0.0002 (1/4096) accuracy. lol
That scaling wasn't so much chosen for the accuracy of the 'load' axis but rather my divider for the variable where the g/rev is stored in the ECU.
Remember the ECU only thinks in integers, 1,2,3 etc
Obviously 1g/rev vs 2 g/rev is a MASSIVE change, so I make the number artificially bigger (in ECU land) then divide it once we can think in floating point.
So 3.5 g/rev in the ECU is actually 14336 (3.5 *4096), thus to get 14336 back into a "human readable/understandable/real" number we divide it by 4096... back to 3.5 g/rev
Anyways - I have basically done the code that calculates the g/rev - I just need to integrate the VE stuff and then its almost ready to be tested.
How about something like:
Note the 25 point 'load' axis, don't take too much notice of the AFR map, its just a stock one copied and then extended to hit 25 columns.
Using my current formula/scaling (x/4096) we can specify down to 0.0002 (1/4096) accuracy. lol
That scaling wasn't so much chosen for the accuracy of the 'load' axis but rather my divider for the variable where the g/rev is stored in the ECU.
Remember the ECU only thinks in integers, 1,2,3 etc
Obviously 1g/rev vs 2 g/rev is a MASSIVE change, so I make the number artificially bigger (in ECU land) then divide it once we can think in floating point.
So 3.5 g/rev in the ECU is actually 14336 (3.5 *4096), thus to get 14336 back into a "human readable/understandable/real" number we divide it by 4096... back to 3.5 g/rev
Anyways - I have basically done the code that calculates the g/rev - I just need to integrate the VE stuff and then its almost ready to be tested.
For fuel, I don't think we need a 0 column, to keep in line with the stock maps, unless you are coding to need it. Also, down low in the map, I think your resolution from column to column should be smaller. A jump of .1g/rev or less down low would be a bit better. As you approach 1 g/rev, then you can start widending the gap from column to column, like .2g/rev, etc.
Overall, looks good. Having a 25 column map is pretty sweet, too.
This may be a noob question, but if we don't want to run the MAP setup, can we still utilize the 25 axis fuel map? Seems like having more resolution in the fuel map would help people running bigger turbos and E85 on the stock looking setups. Just a thought.
DL the software for AEM Pro (updated software as of 10/20/08), that is all speed density stuff. Thats a good model to work off of since thats what 90% of the Evo community ditches the stock ECU for. Great work guys, keep it up!
Jack do you happen to know what tables will need to be modified to run a traditional MAP sensor in place of the MDP? I see a lot of threads on the JDM map sensor I want to know if a different 5 bar 5 volt sensor will work out.
I would imagine Tephra has a 2-D table that converts the MDP voltage input into a kPa or PSI value which is then used in the load routine. This should allow you to scale for just about any sensor.
I could be wrong though?
I could be wrong though?
That looks very good with plenty of resolution.
Just so that I got this right. Say your running 5.6g/rev at 7000rpm's. With that map above, will the ecu try to run a target of 8.3 grams/rev? If the answer is yes, and the ecu will be able to correct up to 10g/rev then I say things will work out great.
Just so that I got this right. Say your running 5.6g/rev at 7000rpm's. With that map above, will the ecu try to run a target of 8.3 grams/rev? If the answer is yes, and the ecu will be able to correct up to 10g/rev then I say things will work out great.
Thread Starter
Joined: Feb 2007
Posts: 9,486
Likes: 67
From: Melbourne, Australia
well those are still standard AFR's in the map. so it will try to target 8.3 like normal
but if you knew you were going to urn 5.6g/rev then you would rescale the map..
but if you knew you were going to urn 5.6g/rev then you would rescale the map..
Would it be possible to setup the AFR map to more closely match reality?
I guess if you are using a VE map you could toss in some values to make the AFR map match reality, but it would be good if the table was based off realistic values.
I guess if you are using a VE map you could toss in some values to make the AFR map match reality, but it would be good if the table was based off realistic values.