When you click on links to various merchants on this site and make a purchase, this can result in this site earning a commission. Affiliate programs and affiliations include, but are not limited to, the eBay Partner Network.
Newer PCMs all moved to load based timing. More predictable, better adaptability etc.
So I just ran a datalog with my ECU that can run off Load instead of MAP. (it doesn't, I'm testing it)
But this history table was quite interesting regarding the variability of timing with MAP vs Load.
Below the output is of Load vs RPM output: Spark TDC range values.
You can see a massive variance is some of these timing areas.
The amount of predictability to be gained from this looks substantial...
I don't have any useful input, but I am curious to know about what's going on here. What exactly is load, and what sensors are being used by the ECU to calculate it?
In my ecu load is calculated as: Load = ((Rpm x VE)/MAT)+15
Load is the % of engine exertion. It takes into account all sensors associated with that formula not just MAP.
The numbers across the top of my table (21/42/63etc) if you multiply by .39 is a percent.
It dynamically adjusts to weather and conditions making the car feel the same year round in good weather and bad. There is still a performance difference due to actual air density in those conditions but the car can now adapt to them and properly time spark for perfect power at all times.
Im also confused... I thought MAP was a proxy for load. What is load based on in your example?
it is. And it does a great job. But if you optimize a tune in winter it will be slow in summer. With Load based that goes away.
You get ideal timing year round with load.
Interesting... After I instituted what I refer to as "quasi closed loop", I seem to get that same effect on consistency across a range of ambient temperatures...
I found these two scalars in the S_AUJP xdf for $8D...
Loop Closed Param, SLOW o2 Coolant Temp Factor 0x4A0 Factory setting => 60.2%. No description on what it does.
AIR FUEL Param, Coolant lag filter coefficient 0x3E7 Factory setting => 6.27% No description on what it does
I was curious what they do, so I started playing around with them, iterating my way to an actual result. I had them at zero, 50% and everywhere in between.
In the end, I wound up with both of them at 100%, and I have to say the car runs more consistently (in terms of seat-of-the-pants power... over varying air and coolant temperatures). Have no idea why. It's not night vs day difference, but I can definitely feel it. It was pretty consistent before, but as picky as I am, I can feel the improvement and I'm liking it... lol.
The only thing I notice in terms of running data is that the BLMs are now essentially locked at 128, with only the integrator varying. Almost like a "quasi-closed-loop".
I had the BLMs pretty narrowly dialed before in such that I was between 124 and 132 at all times. So I'm not too concerned about having them locked at 128, and the AFR's look really good on the WB. So I'm going to leave it like this I think.
Out of curiosity, if anyone knows what exactly it was I did I'd like to know.... lol.
That was ~2 years ago and I've since refined the fueling via the WB and O2 thresholds, along with converting to the various 4th gen LT1 O2 and Integrator filter tables, so it's now even better than when I posted that... even though I still don't know exactly why it's improved.... lol...
I have to do everything by trial and error since I don't have even 1/100000 the knowledge of the code that you do.
Interesting... After I instituted what I refer to as "quasi closed loop", I seem to get that same effect on consistency across a range of ambient temperatures...
That was ~2 years ago and I've since refined the fueling via the WB and O2 thresholds, along with converting to the various 4th gen LT1 O2 and Integrator filter tables, so it's now even better than when I posted that... even though I still don't know exactly why it's improved.... lol...
I have to do everything by trial and error since I don't have even 1/100000 the knowledge of the code that you do.
You can do very well with MAP based, no doubt. You have proven that.
But imagine your timing table did 85% of all that work in a single 20 minute tuning session.
Load based will not benefit a drag racer much if at all.
A daily driver will definitely notice more power under the curve and better mpg. Ease of tuning and year round performance.
The biggest difference is that in MAP you have to sacrifice some timing in large parts of the table to not knock because in this situation you knock but in that situation you don’t. So you pull timing to avoid knock. With LOAD timing automatically goes down in the first situation and automatically goes up in the second. It’s like allowing knock to adapt your timing perfectly without knocking at all.
Also, youre talking about fueling. This is for spark timing.
Understood... i guess what im saying is that I seem to be getting the same effect on consistency by going after the fueling with the approach I mentioned.
Understood... i guess what im saying is that I seem to be getting the same effect on consistency by going after the fueling with the approach I mentioned.
That’s good for consistency of power. But you’re missing the OPTIMIZATION of timing that leads to more power and better mpg.
Think about the fact that ls1s switched to load based timing. They get better mpg and power for a multitude of reasons. One of them is load based tables.
But on 8D, isn't VE an inferred/calculated quantity based on the MAP reading? In which case, aren't you still effectively using the MAP value?
Yes MAP is a part of the airmass calculation. Instead of that calculation I’m now using the speed density airmass calculation stored at $6f which has some other compensations baked in. if you want to see it in anht search for 006f. That value i datalogged from around 15 idle, 22 cruise, 75 wot. If I multiply them then by 2.5 I get some raw numbers datalogged from 37 - 55 - 190. Pretty good for a MAP table replacement and leaves room for power growth.
i ran another log that showed how much load % changed but still used the same MAP based timing cell. The engine was working harder but still commanding the same timing advance because it doesn’t know load.
The variance was all over but 7% in high map areas.
so in one single map cell the engine was exerting up to 7% harder and still commanding the same timing.
That’s actually a large variance in exertion. In other words I currently have to back my timing off in that map based cell to a lower value because I may have kr in that cell when load is high but if load was 7% Lower I wouldn’t. In a load based table I could maximize it everywhere because it knows when it’s working harder and based timing off how hard it’s actually working.
