Speed density (again)
Jan 30, 2009, 03:11 PM
#1
Evolved Member
Thread Starter
Speed density (again)
I'm developing some ideas of how to do this as simply, neatly and effectively as possible.
We use the stock MAP sensor calibration table's output (we change the values in the table to suit our sensor and the scaling) and insert it into the MAF sensor interrupt routine at the point where it has just added up the MAF sensor pulses between this and the previous CAS pulse.
Thereafter we remap various stock ECU tables to make everything work (async accel enrichment, MAF scaling for VE, air temp comp, ignition trim vs air temp comp). I do not think we need to add any tables at all, but we do need to fix a few issues with a few small additional code changes:
BARO:
Fix the baro reading in the code. The reason for this is that the present baro reading isn't really used as baro, it is a pressure compensation for our volume MAF sensor. If we compensate a MAP based reading in the same way it will not reflect the physics.
IAT:
Various options depending on user preference - in code or with wiring we would get more accuracy if this was a post intercooler or inlet manifold temperature.
The main practical difference in mapping is that the load calculations are not VE corrected, so at 25C IAT you will have load=MAP(kPa). So in vacuum areas, your load will be higher than before. The standard fuel maps will work pretty well though as in closed loop the lookup is 14.7 anyway. Full throttle stuff on a flat boost curve will go straight down one load column until the temperature changes.
The existing MAF scaling is used for VE compensation for IPW calculation. It is much easier to setup a speed density system using a 2d airflow (MAP*RPM) vs VE map like this rather than a 3d MAP vs RPM VE lookup. I know this because I've done it for a MAF simulator before. VE varies much less by RPM than it does by MAP, but mapping VE vs RPM*MAP gives accuracy and ease of setup. You can have distinct zones for lift off, idle, slow cruise, fast cruise, part throttle boost, peak torque, peak power, red line - eg about 8 interpolated zones.
These are my collected thoughts on the topic having spent the last few months disassembling the MAF sensor routines. I know Eric may be disappointed that I'm going away from an airflow based load, but actually the OEM ECU only really properly compensates (usingn MAF scaling) the rather non-linear MAF sensor for the IPW lookup.
Discuss!
We use the stock MAP sensor calibration table's output (we change the values in the table to suit our sensor and the scaling) and insert it into the MAF sensor interrupt routine at the point where it has just added up the MAF sensor pulses between this and the previous CAS pulse.
Thereafter we remap various stock ECU tables to make everything work (async accel enrichment, MAF scaling for VE, air temp comp, ignition trim vs air temp comp). I do not think we need to add any tables at all, but we do need to fix a few issues with a few small additional code changes:
BARO:
Fix the baro reading in the code. The reason for this is that the present baro reading isn't really used as baro, it is a pressure compensation for our volume MAF sensor. If we compensate a MAP based reading in the same way it will not reflect the physics.
IAT:
Various options depending on user preference - in code or with wiring we would get more accuracy if this was a post intercooler or inlet manifold temperature.
The main practical difference in mapping is that the load calculations are not VE corrected, so at 25C IAT you will have load=MAP(kPa). So in vacuum areas, your load will be higher than before. The standard fuel maps will work pretty well though as in closed loop the lookup is 14.7 anyway. Full throttle stuff on a flat boost curve will go straight down one load column until the temperature changes.
The existing MAF scaling is used for VE compensation for IPW calculation. It is much easier to setup a speed density system using a 2d airflow (MAP*RPM) vs VE map like this rather than a 3d MAP vs RPM VE lookup. I know this because I've done it for a MAF simulator before. VE varies much less by RPM than it does by MAP, but mapping VE vs RPM*MAP gives accuracy and ease of setup. You can have distinct zones for lift off, idle, slow cruise, fast cruise, part throttle boost, peak torque, peak power, red line - eg about 8 interpolated zones.
These are my collected thoughts on the topic having spent the last few months disassembling the MAF sensor routines. I know Eric may be disappointed that I'm going away from an airflow based load, but actually the OEM ECU only really properly compensates (usingn MAF scaling) the rather non-linear MAF sensor for the IPW lookup.
Discuss!
Jan 30, 2009, 03:55 PM
#3
I don't know if I completely agree with this. VE is going to change a lot based on RPM. You can have a steady boost from let's say 4000 RPM -8000 RPM and you VE can change from 100% to 80%, for example.
Edit: Let me rephrase that...I agree with your statement, but also point out that RPM does and can alter VE by a significant amount.
I am. 
But, in the end, I don't mind how this is implemented. I understand how to tune it either way and whatever works for the coders and the general public is fine with me. I'm just glad that you guys are working on it and hope we see something soon.
Edit: Let me rephrase that...I agree with your statement, but also point out that RPM does and can alter VE by a significant amount.
But, in the end, I don't mind how this is implemented. I understand how to tune it either way and whatever works for the coders and the general public is fine with me. I'm just glad that you guys are working on it and hope we see something soon.
Last edited by l2r99gst; Jan 30, 2009 at 04:00 PM.
Jan 30, 2009, 04:14 PM
#4
Evolved Member
Thread Starter
I'm not playing down the variation by RPM, but numerically the effect is much less than MAP. Combining both sounds a bit odd until you realise you can map it by just checking your (simulated) MAF Hz to know which zone to change, and tweak away. I point out the variation by MAP as most people tend to think about the variation by RPM already. Combining them does work well in practice, there is of course still an RPM element in there. On full boost you'll be climbing the MAF Hz VE table by RPM which allows you to smooth from peak torque VE to peak power VE. The main fuel and timing maps can as usual pick up the details.
Conceptually it is rather more difficult to do 2 separate 2d tables, one for MAP and RPM, and if you do a 3d map of RPM vs MAP it is a bit awkward and you end up with a ragged map where you make block changes.
Practically, I think you could just set your fuel map to what you want to see on the wideband, then adjust the MAF Hz VE table to make it happen. On a standard car, the top end timing will need to be advanced by the equivalent to about 1 load column (20 load) since this is the drop off you see on a plot of MAP(kPa) vs load moving from midrange to top end.
If you already have a nice timing map you could simply log your timing on the MAF sensor and map trace it over a MAP vs RPM grid in Evoscan or similar. Then you would see the areas you need to tweak in your timing map to bring it into line. Easier than it sounds, and certainly a lot easier than rewriting lots of code on lots of ECUs.
The code changes should be no worse than eg MAP based boost control etc.
Conceptually it is rather more difficult to do 2 separate 2d tables, one for MAP and RPM, and if you do a 3d map of RPM vs MAP it is a bit awkward and you end up with a ragged map where you make block changes.
Practically, I think you could just set your fuel map to what you want to see on the wideband, then adjust the MAF Hz VE table to make it happen. On a standard car, the top end timing will need to be advanced by the equivalent to about 1 load column (20 load) since this is the drop off you see on a plot of MAP(kPa) vs load moving from midrange to top end.
If you already have a nice timing map you could simply log your timing on the MAF sensor and map trace it over a MAP vs RPM grid in Evoscan or similar. Then you would see the areas you need to tweak in your timing map to bring it into line. Easier than it sounds, and certainly a lot easier than rewriting lots of code on lots of ECUs.
The code changes should be no worse than eg MAP based boost control etc.
Last edited by jcsbanks; Jan 30, 2009 at 04:19 PM.
Jan 30, 2009, 04:17 PM
#5
But if you had axis of mass airflow, then all you need is a 2d table of VE vs RPM. 
I think I'm just so used to thinking in terms of mass airflow and not map. Overall, it sounds like what you are suggesting should be the easiest and should work out fine, especially since you are basically replacing the maf reading with a map reading and both are roughly proportional to mass airflow. I'd like to see more once the concept comes more to design and the resulting tables that we would have to tune.
I think I'm just so used to thinking in terms of mass airflow and not map. Overall, it sounds like what you are suggesting should be the easiest and should work out fine, especially since you are basically replacing the maf reading with a map reading and both are roughly proportional to mass airflow. I'd like to see more once the concept comes more to design and the resulting tables that we would have to tune.
Last edited by l2r99gst; Jan 30, 2009 at 04:19 PM.
Jan 30, 2009, 04:22 PM
#7
Practically, I think you could just set your fuel map to what you want to see on the wideband, then adjust the MAF Hz VE table to make it happen. On a standard car, the top end timing will need to be advanced by the equivalent to about 1 load column (20 load) since this is the drop off you see on a plot of MAP(kPa) vs load moving from midrange to top end.
If you already have a nice timing map you could simply log your timing on the MAF sensor and map trace it over a MAP vs RPM grid in Evoscan or similar. Then you would see the areas you need to tweak in your timing map to bring it into line. Easier than it sounds, and certainly a lot easier than rewriting lots of code on lots of ECUs.
The code changes should be no worse than eg MAP based boost control etc.
If you already have a nice timing map you could simply log your timing on the MAF sensor and map trace it over a MAP vs RPM grid in Evoscan or similar. Then you would see the areas you need to tweak in your timing map to bring it into line. Easier than it sounds, and certainly a lot easier than rewriting lots of code on lots of ECUs.
The code changes should be no worse than eg MAP based boost control etc.
From winter to summer, the same boost pressure can produce very different mass airflows, which would require very different timing values. So, having a timing map of just map vs rpm would, in conjunction, need another compensation map for T.
A map vs RPM for fuel is ideal, but not for timing.
Trending Topics
Jan 30, 2009, 04:28 PM
#8
Evolved Member
Thread Starter
The big temperature compensation already happens in the OEM arrangement in calculating the various load values. I propose to keep this arrangement. The only question really is whether to apply VE to load calculations. I think the only area you would really notice the difference would be if you were trying to convert an original timing table to the new arrangement, you'd have some vac changes to do, and adding a bit at high RPM/full boost.
Last edited by jcsbanks; Jan 30, 2009 at 04:31 PM.
Jan 30, 2009, 04:31 PM
#9
So, you are going to keep the stock ECU load calculation, but just replace the maf reading with a map reading?
OK, if so, what are the axes going to be for the timing map for example? Is it staying load vs rpm or chaning to map vs rpm? If it's the latter, it won't work because of the T correction that is needed. If it is staying as load (mass airflow vs RPM) then the T compensation, as you mentioned, is already in the code.
Maybe I'm just not following.
Jan 30, 2009, 04:36 PM
#10
Evolved Member
Thread Starter
Yes, just replace MAF volume (before it gets temp compensated) with MAP.
So the axes will be in units of kPa (at 25C). If you are at -5C then your load will be 10% higher, if you are at 55C then your load will be 10% lower (we can change this with the air temp comp that the ECU already has). So temperature is just as it works now. The only thing different is that I wasn't planning to apply VE to load calculations, so at idle and low airflows the ECU will read from slightly higher load sites, at high RPM and high airflow the ECU will read from slightly lower load sites.
So the axes will be in units of kPa (at 25C). If you are at -5C then your load will be 10% higher, if you are at 55C then your load will be 10% lower (we can change this with the air temp comp that the ECU already has). So temperature is just as it works now. The only thing different is that I wasn't planning to apply VE to load calculations, so at idle and low airflows the ECU will read from slightly higher load sites, at high RPM and high airflow the ECU will read from slightly lower load sites.
Jan 30, 2009, 04:44 PM
#11
OK, I follow that fine.
But, what confuses me is that you are mentioning load sites from the maps, when the axes are going to be map based.
I would like them to be load based, but I think you are saying they are going to be map based. If this is the case, what are you going to be using the ECU calculated load for?
Anyway, I am about to run out. I wold love to discuss this some more, but I feel as if I am cluttering your thread already with dumb questions.
But, what confuses me is that you are mentioning load sites from the maps, when the axes are going to be map based.
I would like them to be load based, but I think you are saying they are going to be map based. If this is the case, what are you going to be using the ECU calculated load for?
Anyway, I am about to run out. I wold love to discuss this some more, but I feel as if I am cluttering your thread already with dumb questions.
Jan 31, 2009, 01:53 AM
#13
Evolved Member
Thread Starter
Eric, you're not cluttering it, it is good and useful discussion.
The two options have the following load calc:
1. Load = MAP, and the ECU also calculates a temperature compensated load from there. In this case the map lookups are not VE compensated and we need to do VE compensation on the IPW calc using the old MAF scaling table. Apart from fixing the baro reading and substituting MAP for MAF in the MAF sensor interrupt, there are no real coding changes
or
2. Load = MAP * VE, ECU also calcs a temperature compensated load that ends up much like what we have now. In this case we do not want to VE compensate twice, just do it once for load and don't do it in the IPW calculation. We would have to recode a little to get the load calculated by VE.
The reality is that doing option 2 is not quite as sexy as it may seem because the OEM ECU doesn't really calculate load "correctly" (it uses an airflow meter reading that is not linear to calculate linear load, and fixes it in the IPW calculation). If we use option 2 we could scale it to be "correct" in that load really would be proportional to air density, but things will still move a bit.
Option 1 is easier to code and has the advantage that you know exactly what cells you're hitting for a given MAP and IAT.
The two options have the following load calc:
1. Load = MAP, and the ECU also calculates a temperature compensated load from there. In this case the map lookups are not VE compensated and we need to do VE compensation on the IPW calc using the old MAF scaling table. Apart from fixing the baro reading and substituting MAP for MAF in the MAF sensor interrupt, there are no real coding changes
or
2. Load = MAP * VE, ECU also calcs a temperature compensated load that ends up much like what we have now. In this case we do not want to VE compensate twice, just do it once for load and don't do it in the IPW calculation. We would have to recode a little to get the load calculated by VE.
The reality is that doing option 2 is not quite as sexy as it may seem because the OEM ECU doesn't really calculate load "correctly" (it uses an airflow meter reading that is not linear to calculate linear load, and fixes it in the IPW calculation). If we use option 2 we could scale it to be "correct" in that load really would be proportional to air density, but things will still move a bit.
Option 1 is easier to code and has the advantage that you know exactly what cells you're hitting for a given MAP and IAT.
Last edited by jcsbanks; Jan 31, 2009 at 02:04 AM.
Jan 31, 2009, 03:41 AM
#14
Evolved Member
Thread Starter
Eric, thinking about this more, when you look at your MAF scaling table (with the 140 added), it goes from about 0.10 at low flow to 0.135 at peak torque. Given that the OEM ECU doesn't use this compensation for load, only for IPW calculations, then the load is incorrect by this factor (if we are defining load as air mass per cylinder charge).
Interestingly, if you just stick MAP into the MAF pulse variable it isn't far away... this is support for using option 1 and not VE compensating load, it might actually need hardly any changes to a map! You could actually end up changing the ignition map a lot more if you VE compensate the load instead of the IPW.
Interestingly, if you just stick MAP into the MAF pulse variable it isn't far away... this is support for using option 1 and not VE compensating load, it might actually need hardly any changes to a map! You could actually end up changing the ignition map a lot more if you VE compensate the load instead of the IPW.
Jan 31, 2009, 08:19 AM
#15
I agree option 1 is better and that we shouldn't VE compensate load.
I think your new findings that the maf scaling has no influence on load is very interesting to me. I always thought of that table as a VE table or sorts, which makes sense since the IPW factors it in. But, it's still unusal that it isn't factored into the load value.
I always like to know the true mass airflow and that is why I liked mrfred's patch to calculate that from the OBD II routine. Now that I think about it more, I'm wondering what exactly goes into that. I remember talking with mrfred and acamus about it, but I forgot most of it already (in terms of what the ECU was using, not the pure math/science behind it).
Anyway, thanks for the explanations. It's starting to make a bit more sense. I think I'll feel better when I get to play around with the numbers and do some math for various conditions to see how it effects landing on the various cells of the timing map.
I think your new findings that the maf scaling has no influence on load is very interesting to me. I always thought of that table as a VE table or sorts, which makes sense since the IPW factors it in. But, it's still unusal that it isn't factored into the load value.
I always like to know the true mass airflow and that is why I liked mrfred's patch to calculate that from the OBD II routine. Now that I think about it more, I'm wondering what exactly goes into that. I remember talking with mrfred and acamus about it, but I forgot most of it already (in terms of what the ECU was using, not the pure math/science behind it).
Anyway, thanks for the explanations. It's starting to make a bit more sense. I think I'll feel better when I get to play around with the numbers and do some math for various conditions to see how it effects landing on the various cells of the timing map.