Using $8D, S_AUJP_v7, tuning my '90 C4. This scalar, is a possible adder to commanded idle at startup. Factory bin had it at 1000rpm, but I have since put it to 0, to prevent a large idle flare-up. Description says this value is added to 0x0112, Commanded Idle rpm, if xxxxxxxx conditions are met. However, location 0112 is for the upper spark advance table.

The commanded idle vs coolant table, is located at 0x632, which is right after the above scalar, at 0x631. So, is this just a typo in the description? Talks about this scalar aiding a hard starting engine. Anyone have any experience with this?

 

You are misunderstanding the locations. The 0x631 & 0x632 are addresses in the PROM. IOW, calibration parameters. Once the PROM is inserted into the ECM the cal/code is offset by 0x8000. So they are at 0x8631 and 0x8632 (to the ECM).

The location 0x112 is a RAM memory address. It is working memory that holds the desired idle speed value.

RBob.

 

Misunderstanding, yes and no. I know about the addresses in the bin. Don't know what IOW means. And yes, I program the chips with a starting address of 8000. Dont really care about that offset.
What I didn't know, was that 0x112 is a RAM memory address. The description in the XDF for this scalar is misleading. (after your explanation, I'm NOT saying it is wrong, just misleading). I just need to know, if this scalar at 0x631, is added to the table value at 0x632 (based on coolant temp), to give me a commanded idle.

 

IOW "in other words"

As for the idle speed table and L0112, it is stored there, but with modifiers. Such as hot restart retard and A/C on and P/N difference. Along with the open loop RPM adder from 0x831

RBob.

 

Ok now. I think this is clear as mud. Knew about the modifiers as well. I will update the description for this scalar, in my XDF, with notes from I have just learned.
One of the many great features of TP, you can edit and user-modify things like there is no tomorrow!

 

Mike, a bit of clarification (and perhaps confusion I created). There are 2 hex values of concern: one is in the Calibration and the other in RAM). Throughout the XDF descriptions, references to 0xnnn (n=3 digits) are Calibration values. References to 0xnnnn (n=4 digits) are RAM variables. As RBob indicated, these variables are identified in the code as "Lnnnn". Had that nomenclature been used, it would have created even more confusion.

Bottom line, and in retrospect, there should be no 0xnnnn references in the descriptions -- only a text reference to identify a RAM variable where necessary for clarity (such as "Commanded Ilde RPM" and NOT "0x0112=Commanded Idle RPM"). Someday, I'll make those corrections.

Clear as mud now?

PS ---
The reason for using 0xnnn and not 0x8nnn is because in TPro, one can search for Calibration items using the "nnn" value, which is an offset from the beginning of the Calibration.

 

Hey Tom. Surprised you didnt respond to this 2 months ago when I originally posted it. Just had to re-visit this thinking, thats all. (Working on my VE tables now, after O2 sensor change)
Regardless, clear as can be. Agree with the bolded text above, no ref to RAM locations needed in the descriptions. This is what I put in my description, for this scalar:

This RPM is added to RAM location 0x0112 (Commanded Idle RPM).... if:
- IAC Idle Adjustment NOT Allowed (meaning engine not yet declared running) ---AND---
- NOT Moving ---AND—-
- TPS% < 0.78%
Appears to be an aid in case having difficulty starting engine. Setting this scalar high will cause RPM Over-Speed condition which will increase SA, which in turn will affect how IAC steps are adjusted.

Keeping the RAM locations out of the descriptions is one option. Or just need to make a better statement when talking about address of the cal parameters, vs working RAM locations for rolling live data......
Understand tho, there is a lot going on in $8D, S_AUJP_v7, hard to keep everything clear as mud!
Mike