Speed Density 2.0?
Evolved Member
Joined: Mar 2008
Posts: 730
Likes: 3
From: Lattitude 48.38°, Longitude 17.58°, Altitude 146m = Slovakia, for common dude
Now the question is what shall I take as a base 1,2 or 3?
1
Unless somebody wants to make a good, easy to follow guide on the live map application with an up to date version.
I know there are a couple different versions floating around.
Unless somebody wants to make a good, easy to follow guide on the live map application with an up to date version.
I know there are a couple different versions floating around.
I'd also suggest 1.
This would be really nice to get set up. Making the SD easier to tune will make it one step closer to having a program similar to VEanalysisLive running on Tuner Studio for MS, but for the Evo ECU instead.
http://www.youtube.com/watch?v=l_SPSGj3CR4
In that setup, it tunes a VE map with kPa and rpm as the axes. It's very similar to what's been suggested already in this thread.
-You have predefined MAP calibration for each sensor type.
-You start with a rough VE map that gets the car running.
-You slowly rev/drive the car and move between cells as the live tuning software compensates.
We wouldn't be making the jump to that yet, but it would be nice to have a target like that so we can chose the proper path to follow.
Note: There's a high percentage of DSMs posting in this thread. LOL
This would be really nice to get set up. Making the SD easier to tune will make it one step closer to having a program similar to VEanalysisLive running on Tuner Studio for MS, but for the Evo ECU instead.
http://www.youtube.com/watch?v=l_SPSGj3CR4
In that setup, it tunes a VE map with kPa and rpm as the axes. It's very similar to what's been suggested already in this thread.
-You have predefined MAP calibration for each sensor type.
-You start with a rough VE map that gets the car running.
-You slowly rev/drive the car and move between cells as the live tuning software compensates.
We wouldn't be making the jump to that yet, but it would be nice to have a target like that so we can chose the proper path to follow.
Note: There's a high percentage of DSMs posting in this thread. LOL
One thing I wanted to mention, no matter what method is used for the VE table.
We will still need a baro+temp compensated load for the fuel and ignition maps. I don't know if that was being changed or suggesting to be changed, but just wanted to throw that out there. I think the changes suggested by Ceddy were only for the VE table and not the way the ECU then calculates the other load variables. Basically, I'm assuming just going along with John's patch, but with a 3D VE table.
Obivously 30psi at 0* and 150* are going to be two completely different mass airflows needing very different fueling and ignition.
We will still need a baro+temp compensated load for the fuel and ignition maps. I don't know if that was being changed or suggesting to be changed, but just wanted to throw that out there. I think the changes suggested by Ceddy were only for the VE table and not the way the ECU then calculates the other load variables. Basically, I'm assuming just going along with John's patch, but with a 3D VE table.
Obivously 30psi at 0* and 150* are going to be two completely different mass airflows needing very different fueling and ignition.
Last edited by l2r99gst; Jan 28, 2010 at 03:53 PM.
That is what the separate fuel and ignition trims are for.
There isn't a MAP based standalone that I've seen that used compensated load for table lookups.
You have RPM and MAP. Not RPM and MAP+IAT.
There isn't a MAP based standalone that I've seen that used compensated load for table lookups.
You have RPM and MAP. Not RPM and MAP+IAT.
Yes, I understand that, but the way the ECU is coded already, it's very simple to create SD like John did. If you want to make your fuel and ignition maps have map as an axis, then you have to change a ton of code, along with adding the trim maps with respect to temperature.
As long as the load we use is temp compensated (PV=nRT), then we should be OK.
That's why John's code was so nice and easy. It still left all of the compensated loads to be calculated from the MAT temperature, which is our baro+temp load.
As long as the load we use is temp compensated (PV=nRT), then we should be OK.
That's why John's code was so nice and easy. It still left all of the compensated loads to be calculated from the MAT temperature, which is our baro+temp load.
The SD routine is actually pretty simple, its amazing JCSBanks wrote it with so little code.
It emulates the MAFs signal (MAF ticks/rev)
MAP VE & Calibration[kPa] x RPM VE[rpm] = AirCounts [MAF ticks/rev](Also called MasterLoad)
Then in the normal code:
AirCounts / Time_Per_Rev = MAF Hz
AirCounts x MAFSize / 65536 = Load
So you can think of the SD code as emulating Load, even though its not its immediate output.
But table wise you can't just have a VE% table, you also need the Calibration table, its what transforms kPa into "Load".
I think a RPM x kPa table with VE% lookups, and the Calibration table locked 1:1(kPa:Load), is probably the ideal setup for 3-D tables.
It emulates the MAFs signal (MAF ticks/rev)
MAP VE & Calibration[kPa] x RPM VE[rpm] = AirCounts [MAF ticks/rev](Also called MasterLoad)
Then in the normal code:
AirCounts / Time_Per_Rev = MAF Hz
AirCounts x MAFSize / 65536 = Load
So you can think of the SD code as emulating Load, even though its not its immediate output.
But table wise you can't just have a VE% table, you also need the Calibration table, its what transforms kPa into "Load".
I think a RPM x kPa table with VE% lookups, and the Calibration table locked 1:1(kPa:Load), is probably the ideal setup for 3-D tables.
Also, at what point does the ecu provide air temp compensation? Is it after this load value is calculated (IE: is that raw load above then the ecu applies this to the air temp tables to come up with real load to apply to the fuel and timing maps).
But, yes, I think the temp compensated loads and mass airflows are then calculated from pV=nRT (table lookups) later in the code. That's what I was suggesting not be changed in my post above, but I don't think Ceddy was suggesting that it was going to be. These loads are then used in the fuel and timing maps as follows:
(from mrfred)
spark advance lookup: For air temp below 77F, baro+airtemp compensated load is used for spark advance. For temps above 77F, then baro compensated load is used.
afr lookup: for closed loop conditions when load is < ~20, uncompensated load is used, otherwise, baro+airtemp compensated load is used. This means that baro+airtemp compensated load is used essentially all the time for AFR lookup.
Baro is already compensated for in the map sensor when using SD with the map sensor. Baro can be locked down to 1 atmosphere for the ecu, and I think it allready is in the SD code currently.
Yes, I understand that, but the way the ECU is coded already, it's very simple to create SD like John did. If you want to make your fuel and ignition maps have map as an axis, then you have to change a ton of code, along with adding the trim maps with respect to temperature.
As long as the load we use is temp compensated (PV=nRT), then we should be OK.
That's why John's code was so nice and easy. It still left all of the compensated loads to be calculated from the MAT temperature, which is our baro+temp load.
As long as the load we use is temp compensated (PV=nRT), then we should be OK.
That's why John's code was so nice and easy. It still left all of the compensated loads to be calculated from the MAT temperature, which is our baro+temp load.
Evolving Member
Joined: Apr 2008
Posts: 265
Likes: 1
From: Reading, PA
Load16Bit = AirCounts x MAFSize / 65536
Load8Bit = Load16Bit / 2, and Limited to 255
LoadBaro16 = Load16Bit x BaroComp
LoadBaro8 = LoadBaro16 / 2, and Limited to 255
LoadIAT16 = Load16Bit x AirTempComp
LoadIAT8 = LoadIAT16 / 2, and Limited to 255
LoadIATBaro16 = Load16Bit x AirTempComp x BaroComp
LoadIATBaro8 = LoadIATBaro16 / 2, and Limited to 255
Is that sub_11598 on 96530006?
I don't know if it would take as much code change as you are thinking, L2R99Gs-t. It would require carefully evaluating when each load is used though. Testing may also prove to have other downfalls with this method.
Most stuff, using the original loads is probably fine. However, for fuel and spark, it seems like limiting everything down to uncompensated load in the look up tables would be the better option. That way you don't move around in the table when IAT changes. You DO NOT want to drop to a lower load when IATs go up, because the tune gets more aggressive when you go down. You just want to compensate with ignition retard or fuel increases across the board when at higher loads and the temps go up.
As far as IAT ignition compensation, it's already in the code. Same with IAT fuel compensation for IPW. It's already there and already being used.
The load comps used change WHERE in the map the ECU grabs values from. However, it does NOT change the IPW and ignition directly. That is handled by additional tables mentioned above.
I don't know if it would take as much code change as you are thinking, L2R99Gs-t. It would require carefully evaluating when each load is used though. Testing may also prove to have other downfalls with this method.
Most stuff, using the original loads is probably fine. However, for fuel and spark, it seems like limiting everything down to uncompensated load in the look up tables would be the better option. That way you don't move around in the table when IAT changes. You DO NOT want to drop to a lower load when IATs go up, because the tune gets more aggressive when you go down. You just want to compensate with ignition retard or fuel increases across the board when at higher loads and the temps go up.
As far as IAT ignition compensation, it's already in the code. Same with IAT fuel compensation for IPW. It's already there and already being used.
The load comps used change WHERE in the map the ECU grabs values from. However, it does NOT change the IPW and ignition directly. That is handled by additional tables mentioned above.
Last edited by 03whitegsr; Jan 28, 2010 at 06:45 PM.
Well thats fine if you think it can be done easily. Now that I think about it the stock maf setup reads baro, iat, and mas hz stock so it already has tables for the iat trim for timing and air density compensations for the fuel map.
