So from my thead on spark advance, where I plugged the question into an AI...

I started playing around with AI on TPS sensitivity for throttle response just to see what it said...

It came back with some parameter at location 43e...

I then told it that I couldn't find that parameter

When I created that parameter in the S_AUJP xdf, I found that the factory AUJP value is .05. So there must be something at 43e

It then said...

When I look at the ANHT hac, if I search on 43e, I don't see anything in there...

 

 

My throttle response is excellent right now, by virtue of essentially disabling a bunch of other lag filters and stuff...

Curious if this parameter is real and what happens if I increase it...

 

If it’s not in anht it’s not anywhere else unless it’s custom code by saujp devs.

that said, you may be missing an indirect addressing issue and it IS there.

in other words the code could pull a value at 43d and load to register x. Then after, it could add one to x (43d+1=43e) and when it then uses register x it’s now reading 43e having never called the address directly.

you can see this behavior (I believe) in the BLM cells. I think only a couple cells are directly addressed but they are all used with indirect addressing.

so just because you don’t see that address used doesnt mean it’s not there and used.

 

Understood. I guess the fact that the XDF was able to create the scalar using that 42e location suggests something is in fact there. The table/scalar has to already be present in the code for the XDF to be able to bring it out into a user interface.

Also to your point, maybe I need to try to re-create it using a factory AUJP/ANHT bin instead of starting with S_AUJP. That'll tell me if the 42e was a factory piece of code, or if it was added by the S_AUJP authors.

Though it did find the value of .05 from a factory AUJP bin when I opened that bin in my modified XDF... and the AI seemed to know what that value means. I guess we'll see...

I don't really use AI for much of anything, but it's interesting in terms of continuing with this DIY PROM thing. It seems so many past gurus and experts from the "glory days" of this forum are no longer here and activity has dwindled to a trickle. With my lack of understanding of the raw code and all of that, the AI seems to be able help out in that regard.

From a thread a while ago, there's a point right after a hot startup where the throttle response is razor sharp... I mean sharp-sharp-sharp...(some might call it "hair-trigger" sharp). It lasts for about 30-40 seconds and then you lose that. After that time period, the response is still fantastic, but I can tell the difference. I.e., if someone got in my car and drove it around, they probably wouldn't notice the difference, but I do.

Its also not something i can detect in the data, since i captured the operation in that time period a few times trying to see what the difference was between that 40 seconds and everything after that.

I've always felt like it had something to do with the ECM's sensitivity to TPS changes, but I could never find a parameter that addressed it. There is a scalar that deals with the delta-TPS threshold to activate TPS AE... the factory setting is 1.17% and I lowered it the minimum .39% (at least what TP displays as the minimum). That made a HUGE difference with the Miniram.

But again, it always felt like there was just the tiniest bit of delay in the ECM responding to the TPS (like some sort of hidden lag filter or something). I also knew it had to be TPS related and not MAP related because the time scale seems to be way too short.

I can envision the GM engineers putting some kind of delay in there to make the throttle not so much of a hair trigger for the average driver. But for me, I want that.

Any rate, I'm eager to try this new scalar out and see what happens with it.

 

Two things before you proceed…

Just because tunerpro shows a value doesnt mean it’s correct! ANY address in the ROM can do that. So that is NOT proof of anything at all.

Second, be EXTREMELY careful with AI and this stuff. I tried using several AI models to help do it quicker and they were COMPLETELY WRONG. I was trying to track down some things and do some stuff and they told me 100% that a subroutine did that and it was COMPLETELY wrong. Over and over. It was constantly so far off I stopped using it completely.

I have tried to use AI to debug some embedded software I wrote for an other project and it told me 3 fixes at the same time. All 3 were wrong. I had to debug it myself and it was so simple the fact that AI couldn’t do it was pathetic. PATHETIC.

 

Also... 43E is part of a table. The value there is 0D. THAT is a startup enrichment LOOKUP table. This is NOT an independent variable.

 

well that sucks...

I guess my question would be is if there is anything in 8D regarding TPS sensitivity that may not be showing up in any of the 8D xdf's?

But that was also a little bit of confusion for me as well... there were things where the TP hex address for a particular scalar seemed to have a different scalar for that address in the ANHT hac. But that could also be a function of me not looking at it correctly too...

 

There are slight differences in addresses in the different Bins. Mine is very close to anht, but after a certain address where the code is slightly different, the addressing from then on is not the same. This is why my hacks don't translate to other Bins without fixing that issue first.

Regarding TPS sensitivity, that is controlled by 2 things that I know of. Anything beyond would not be TPS, but independent routines for OTHER things.
1. TPS voltage RAW value. This is what the ECU reads directly from the TPS.
2. The Coef Filter(s) applied to that for various other routines.

 

In other words, what are you trying to do? TPS is split into a few variables independently filtered for the intended routines.

 

You may be looking for the variable at x5F3. This might be the blend speed of spark timing changes in the routine you're looking for. Try increasing it, SLOWLY.

My bin is set to 1. ANHT is set to 2.

 

It's what I was saying earlier....

From what I understand, the ECM delays the response to delta-V on the TPS (for a few milliseconds?) to make sure (for small changes) that the delta-V is due to an actual change in throttle position, versus being caused electrical noise in the system. In which case, it's this delay factor I would want to get access to (which I don't think is in any of the current 8D xdf's)

 

I can... the only thing is looking at old data, I don't see any instances where the ECM is reducing SA-ref in a non-knock-retard, non-stall-saver, or non-DFCO, situation. So I'm not sure how this would benefit me... unless I'm missing something?

You're saying to increase it, but you're running less than factory ANHT?

 

Youre looking for a TPS parameter that likely doesn’t exist.

Use the anht file.

find where the ecu reads the tps sensor itself. It loads $50 then jumps to a subroutine to read the analog voltage. Then it will staa or stab to a new ram spot. Thats TPS A/D your raw tps signal.
after that it will load up a coef and jump to a lag filter routine and then again staa or stab to another ram address variable.

use control f and the raw tps address to see where it’s pulled both times. Trace every single ram variable saved afterwards.

then through every step of that make sure every coef used before that lag filter routine is defined in your xdf.

after that search throughout the anht fpr uses of each and every tps variable and see what it does with those ram variables elsewhere. There could be filters and coefs applied to each one of those. Make sure they’re all defined in your xdf.

it should be relatively easy to find your problem if you are methodical about this and take notes and follow each one as far as you can.

 

I’m running axxd. I haven’t changed that value from OEM.

it may not do anything. It may blow up your car. It may make 700 more hp. I don’t know. I just went off what you posted and did a Quick Look to try to understand your ai stuff and saw it differently than it. So I could be as far off as your AI but mine at least could make sense where the ai completely failed.

 

I'll try, thanks.

"TPS A/D your raw tps signal."

There's a MAP version of this scalar that I can see... seems like it'd stand to reason that there'd be a TPS version of it.

 

Yes the aldl data stream has 2 tps values. One is raw.

 

So one thing that might help me is defining some of these terms... I'm not at all well versed in code-speak... I appreciate your willingness to respond to these stupid questions of mine... lol

staa? stab?

ram address?

raw address?

Also when I search on $50 in the ANHT hac, it takes me here...

But, when you say "raw TPS address", which address do I look for in terms of searching for it in Tunerpro?

 

staa store data to ram at address (L0094)
stab same
Ram address = address for live data storage
Rom address = address for tables, scalars, code
Raw is unchanged by code. Read direct from sensor.
register is a data byte the computer is actively using.

starting at your tps code there:
ldaa ##50 = load 50 to register a (sensor channel to read)
jsr LF0D2 = jump to code at address (F0D2 = read sensor at channel 50)
staa L0094 = store register a in ram at address (0094) this is TPS RAW data.

 

For ram addresses to read live data in tunerpro.

there is a list of 64 bytes sent through aldl.
if You search anht for 0094 the very first one should be the list.
if you count which number it is on the list (9th or whatever it is) and look at the tunerpro xdf the place on the list is the offset. x09 or something like that.

so if you want to read custom sensor data or any thing in ram:
edit the list.
so if you edit the 10th spot (0F=10) and make a custom scan variable at an offset of x0Fyou can read it live.

 

I still don't fully grasp everything you're saying.... butbased on what you're saying and re-reading the ANHT-hac as well as looking at the S_AUJP v7 xdf...

I found a few things that I can at least correlate between the xdf and the ANHT hac, so that's some progress at least.

There are three TPS scalars in the XDF that may be related to what I'm looking for?? I also see them in the ANHT hac, but I'm not sure how they're used while the engine is running (it appears to be something used at initial startup).

Location 3E4

XDF Title: AIR FUEL Param, TPS Factor for Low Voltage

XDF Description: If after lag filtering, TPS voltage is lower than a calculated threshold (0x0099-see AIR FUEL Param, TPS Initialization Voltage), this factor is used to increase TPS voltage to an acceptable level before computing TPS%. Factory Default = 0.41

Location 3E5

XDF Title: AIR FUEL Param, TPS Initialization Voltage

XDF Description: Initial TPS voltage at key-on or if engine not running. Becomes the threshold (0x0099) against which TPS voltage is measured after being lag filtered. Factory Default = 0.94 Volts

Location 3E6

XDF Title: AIR FUEL Param, TPS Initialization Voltage Filter Coefficient

XDF Description: Used to gradually reduce lag filtered TPS Initialization Voltage. Factory Default = 0.39%

****************
So, the factory TPS voltage setting is .54V at the sensor (which is what I have mine set to). 3E5 says the default value in the code is .94V?

3E4 seems to be saying if the lag filtered voltage (via 3E6) is less than 3E5 (.94V), its using .41V somehow to bring the TPS voltage to an acceptable level?


So is the difference between the .94V in the calibration and the .54V at the TPS causing this delay? Curious what would happen if I changed that .94V to .54V? Then set the lag filter to 0?

In the ANHT hac, the 3E6 appears to store that filtered result at L0099, and that L0099 seems to get called up at numerous other places in code.

 

Going back (cautiously) to the AI, it seems that those TPS voltage scalars are in fact related to startup evaluation of the TPS voltage by the ECM. So that sounds like a bust...

Though playing around with it a little more, it identified hex addresses 5970 and 5971 as being related to that TPS lag.

The only thing is I don't see (or know how to find) those addresses in the ANHT hac, so I can't corroborate it. Nor does TP seem to find them with a CTRL-F search. But its saying...




Now I do see those values in the hex editor....

 

I found a scalar

MAP Sensor Param, A/D Lag Filter Coefficient at location 6DC

There are references in the ANHT hac to getting the MAP sensor raw A/D, so the lag filter must be how the ECM reacts to that A/D value.

Since the ANHT hac mentions a TPS A/D, seems like it'd stand to reason that there'd be a lag filter coefficient associated with it?

 

There is a lag filter for everything.

what you might be missing in the correlation between the xdf and the anht:

the anht operates with an offset.
the address in xdf is say 3E4. In anht it’s 83E4.
8000 + xdf address is anht address UP UNTIL the OS is different and then all addresses will be different between the 2.

since you don’t know hex you need to know addressing.
if xdf is 3 digits just put an 8 before it. But if there’s another number you add the HEX digit before it.

first digit / hex to add for anht
0 / 8
1 / 9
2 / A
3 / B
4 / C
5 / D
6 / E
7 / F

so if you see the xdf point to 3C44 the anht address will be BC44. Or nearby if the code is different.

that should help you correlate.

 

Thanks Vanilla... appreciate the patience on this. I actually do understand what you're saying here. I've been hammering on this stuff the last couple of days and I feel like I've just made a fingernail scratch in the surface of being able to know what I"m looking at it.

The addresses in the TunerPro (whether the generic 8d or SAUJP xdf) seem to be fromatted as 0x534 for example, for Accel delta TPS pulsewidth scale factor.

The ANHT hac document (going to post it here just in case you don't have it)... has address $8534. So I see that 8 offset you're talking about.

So using that logic...

I see the $8260 address for the raw TPS A/D value in the ANHT hac. If I continue to search in the hac for 260, I see it being used in only one other place.

;------------------------ L8260: FCB 246 ; IF TPS A/D VAL > SET ERR 21A

If I search through the hac on TPS A/D, all I see are more references to ERR 21, with addresses at 261 and 265.

I can see the TP parameters for those addresses... and they're all having to do with the TPS ERR code.

Nothing that I can see in TP or the hac in terms of using that TPS A/D value for anything in terms of engine management.

So either the hac is not 100% complete, or the 8d only uses it for determining the Code 21 TPS error.

Conversely on the MAP A/D side...

I see the raw MAP A/D value at 0074 in the hac.... although in TP, 0074 seems to correspond to a value in the lower spark table. Not sure

But in the hac, the 0074 does seem to get employed in some calculations. While I don't fully understand the calculations, it looks like the ECM is using the value for something. There's one spot in the hac where 0074 is used and then within that subroutine I see the 86DC address for the MAP A/D lag filter, which corresponds to what I see in TP for that address.

So again, either the hac is not complete, or the TPS A/D value is only used for ERR 21?? But that would imply GM just used the raw TPS value as is... and like you said, there has to be a lag filter.

Now, that said, there is that table AE-TPS, TPS% Lag Filter Coefficient .vs. RPM, but I'm not sure if that's it or not. In the hac, this table doesn't seem to have a reference back to the TPS A/D value. And earlier descriptions from RBob seem to say that it actually is more to do with how much fuel gets delivered, vs how fast the ECM reacts to the raw TPS value.

 

Here's a description from Elky a while back on that AE Filter Coefficient table in 8D

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

Maybe the ECM does use the raw TPS value, but the uses this table do lag filter it? In which case this is what I"m looking for?

But it seems to be related to calculating AE on the delta between the raw and the lag filtered value of the TPS... not necessarily how fast the ECM is reacting to the raw value in the first place. Unless that's a non-sequitur and this whole notion I have is a wild goose chase.... lol.

All I know is that hot re-start throttle response is in fact different than what's typical... something has to be causing it.

 

you are mixing up ram and rom.
live changing values are ram. There is no address in tuner pro to read it. It changes. You can’t tune it.

rom is the addresses for code and tables, values etc.

 

I asked you this a couple days ago and got an invalid response from you saying you already said it.

the issue you are trying to pin down IS IN FACT AE specifically? Because that narrows the search considerably and was what I was asking clarity on.

 

I'm surmising it has to be AE related. It's an assumption of course.

During the ~40 seconds after hot re-start, the response time from the gas pedal to the feel of the throttle response in the seat of the pants... it's so instantaneous I can't imagine it's Delta-MAP. Intuitively it seems like it'd have to be based on a direct mechanical cable connection between the gas pedal and the throttle (and hence the TPS), versus delta-MAP where there's time that has to elapse between the throttle blades opening to the manifold pressure change, to the MAP sensor detecting it and then the ECM reacting to that...

 

can you/have you logged run time? The ecu can run only so many lines of code per second. If it’s running less code at startup everything updates quicker. Crazy wild thought.

 

I have yeah... in the past. and then I'll filter the data on that time period looking for what may be different from the time period after... but nothing jumps out at me.

 

Got in touch with 84Elky over email.

There's a sensor diagnostic ADX file in the suite of SAUJP files that I wasn't aware of.

It has the TPS and MAP raw readings (both voltage and raw hex) next to the TPS%. I added the bit masks "In AE TPS" and "In AE MAP".

It's raining this week, but when I get a chance I'm going to take the car out and drive it around, taking data. I'll also do some of the hot restarts and take data.

That'll tell me hopefully how quickly the TPS and MAP AE are reacting (at least within the sample rate of Tunerpro, which is ~140 milliseconds), and if there's any difference between hot restart and other conditions.

Hopefully some time next week since it's raining this week...

 

I would not bother doing this. Aldl data is not updated as fast as the rest.

my idea was to see how many updates of ALL aldl data were sent per second.

if in your early timeframe you get 10 points per second and after you notice it’s only 7 that MIGHT tell you something.

but its HIGHLY likely a waste of time IMO.

 

There was a break in the rain, so I took the opportunity...

You're right... the "In TPS AE" flag is not anywhere indicative of anything useful... it's coming on at random times.

In addition, I'm not seeing any difference in TPS reactions between normal driving and hot-start

Shucks...

The only thing I notice is the following:

Zero TPS on my car is .57V

The ECM will display a .59V value during a slow throttle transition, but I won't see an actual TPS% increase until .61V, which equates to .78%. The lowest TPS% that TP will register and display is .78%

I'm not sure how much actual throttle blade movement .59V translates to though, or whether that's enough to cause any kind of lag. But I do see the same TPS response on the hot-restart datalog as well, so that t suggests this isn't the issue either.

Shucks... shucks.... back to square one.