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.

 

Another one...

AIR FUEL Param, TPS Initialization Voltage Filter Coefficient 0x3E6

Set to 0%.

I'm not sure what it is with these filter coefficients and why 0% seems to be such an ideal value for a performance oriented tune. I don't even know how to describe it, but there's this seat-of-the-pants feel to it now at part to moderate throttle that feels like the ECM has been transformed into more of a performance ECM rather than one that was made for a generic production car.

It's not like the car is running richer or anything like that (I'm not seeing any noticeable difference in the AFR's ether during throttle transitions or at steady state). But something is different in the way the fueling is being applied with all these filter coefficients at 100%.

What I was chasing after in this thread.... it actually runs better than that now...

https://www.thirdgen.org/forums/diy-...rt-7730-a.html

 

Sounds like one of these if not more is the filter coefficient for the blm pid, have you tried just changing one at a time to see if or which one locked the blm to 128?

 

don’t know if you got your answers.

A Filter coef is used to smooth voltage inputs and to filter out sudden jumps in values.

Higher number smooths more, smaller changes to value and slower updating . Lower number allows bigger jumps but faster updating.


So what you’re enjoying is a more rapid updating to those sensor values. What you’re not noticing is the negative which is some more erratic values processed.
id suggest trying 5% minimums to see if you still get what you want and have a little bit of filtering still.

 

Interesting.... Thanks for taking a look at that.

No freaking way... lol.

I absolutely love the throttle response the way it is!

 

And one last thing to those running $8d and curious about these tables in their bin file that isn’t aujp. The low aujp address values (0x001 - 0xFFF) Are probably the same for your bin as well so you can try to copy the definition to your xdf and see if it’s the same.

Address Values with a 4th number IE 0x7604 are most likely NOT correct to transfer.

 

Then don’t change. Just be aware doing this to other sensor coefficient values may not be ok and could end your fun.

 

One thing I did notice though...

The TPS voltage has to get to .94V before the TPS% registers an increase in Tunerpro...

https://www.thirdgen.org/forums/diy-...ml#post6557511

 

Hmm so what I’m thinking is if his BLM is locked at 128 and long term fuel trims are essentially sensor degradation corrections, so if in fact these are sensor voltage filter coefficients by setting them to 100% no filter then no correction to BLM?

 

You’ll have to expound on your issue.
Are you saying it has set 0 point as .94v so anything under that reads as no TPS input?

change the adx to log the value with no scaling of both and see if it’s using the same address offset for the aldl data of both tps V and %.

im 99% sure they’re different as I think I hijacked one of them for my wideband afr voltage data.

So if the aldl address offset is different it’s possibly something you changed. If voltage is read and run through a lag filter with a coef and you’re reading a tps ram through the lag filter at a different point with a coef you changed that can explain your behavior.

There’s multiple ram variables for each sensor to be used throughout the ecu so variances will happen especially if you’re changing coefficients.

 

Not so much an "issue" per se. Just a curiosity...

The details are better described in a few posts before that...

Particularly this one...

https://www.thirdgen.org/forums/diy-...ml#post6556696

Seat of the pants, you'd never suspect a delay in the TPS% response since the throttle so crisp (especially given how sensitive the Miniram is to that).

 

First, to clarify a couple things. You mention in the link that TPS % is voltage * .39. It is not. It is the INT value of the AD read * .39.
If you take 5v (100%) TPS and multiply by .39 you get 200% throttle.
However, if you take the AD channel's read on the wire, turn it into an 8 bit integer you get 255 (100%) throttle. 255* .39 = 100%.

Next bit of clarity. When you use at least the definitions I've found online, TPS Voltage is packet 9. TPS % is packet 17. In other words, these are NOT the same thing. They should very closely match. If you take either one of those tunerpro values and change the scaling, you would be able to scale to Voltage OR to TPS%. I don't know the purpose of having both. Perhaps it was GM research for drive-by-wire. They did this a lot through the years. Scanning and running code in the background to be used for R&D.

Now to look at your post again...

 

The OEM only seems to use that value you're changing to initialize a value before the first voltage read. That's it.
Once to initialize the ECU at startup and again if engine off. After init it immediately goes to the TPS subroutine where the lag filter filters it but ONLY if the TPS is lower. It does not lag filter it if TPS is higher. Other than that, i see nothing.

Here's a fun thought. Change those coefs back and see if you can get it to still show your issue.

If those coefs allow the random values I warned you about, then you'll throw codes for TPS over and over. When the ECU believes there's a TPS problem it'll load it's init values.