Modify table parameters in $8D

[space387]

I am looking to repurpose the egr function to activate a set of exhaust cutouts on my 1990 corvette. It is running the $8D bin on a 1227277 ecu. Looking over the parameters of the egr activation I see the duty cycle table tops at 2000. Is it possible in the decompiled code to change the table range? Ideally I would like it to shift the range up to 3000. If there is a better suited channel on this ecu that would also be an option.

Thanks in advance.

[84Elky]

I am looking to repurpose the egr function to activate a set of exhaust cutouts on my 1990 corvette. It is running the $8D bin on a 1227277 ecu. Looking over the parameters of the egr activation I see the duty cycle table tops at 2000. Is it possible in the decompiled code to change the table range? Ideally I would like it to shift the range up to 3000. If there is a better suited channel on this ecu that would also be an option.

Thanks in advance.

Having difficulty relating EGR activation to exhaust cutouts. Please elaborate more on what you are trying to accomplish.

[space387]

Having difficulty relating EGR activation to exhaust cutouts. Please elaborate more on what you are trying to accomplish.

I am using the egr output to control cutouts. Is there a better option?

[steveo]

without modifying the code, the egr output could be an annoying/unreliable way to control the cutouts. as an emissions control, it may have test cycles (open briefly when you don't want it to). it may have parameters that are undocumented that prevent its operation as well.

what are your desired parameters for your cutouts to open? minimum tps? rpm? map?

[space387]

The goal is to open above 2500 and at a tps of over 50%

[84Elky]

I am using the egr output to control cutouts. Is there a better option?

Sorry, misread you post. If it's working, great. If not, no way to change upper RPM of the table at 0x8b5 without code modification. What about CCP. It's controlled by MPH, MAP, TPS% and air flow. Don't know how to make it work, but it may be a candidate.

[space387]

I was actually asking about code modification to fit my needs. There are a few tables I could benefit from changing but this was the most direct. Basically what I was hoping was to figure out how the tables are defined and without changing the number of addresses change the rpm scale of it.

[space387]

Using the already decompiled and expanded ANHT and JP_AUJP2 I found the table definitions at x2B2 for the minimum RPM, x2B3 for the minimum load value and x2B4 the number of lines per RPM block. x2B2 is 20 in hex and 32 in decimal, leading me to believe it is this value in decimal x25.x2B3 is load so I am not sure if this is a KPA reading or a calculated load based on kpa temp tps and a few other factors. Any clarification on this would be great because the scaler is noted as load and the table is noted as MAP. my current changes are to make x2B2 40 to raise the rpm base to 1600 and x2B3 to 14 for a base of 20(load/KPA)

[84Elky]

Using the already decompiled and expanded ANHT and JP_AUJP2 I found the table definitions at x2B2 for the minimum RPM, x2B3 for the minimum load value and x2B4 the number of lines per RPM block. x2B2 is 20 in hex and 32 in decimal, leading me to believe it is this value in decimal x25.x2B3 is load so I am not sure if this is a KPA reading or a calculated load based on kpa temp tps and a few other factors. Any clarification on this would be great because the scaler is noted as load and the table is noted as MAP. my current changes are to make x2B2 40 to raise the rpm base to 1600 and x2B3 to 14 for a base of 20(load/KPA)

Your logic is sound about modifying the table entry points. However, the code hard-code-restricts RPM to 2000 (0x50) max, so any value > 2000 is forced to 2000 for table lookup making it impossible to access anything in the current 1600 and 2000 RPM areas of the table. The lower boundary change to 1600, would then present those areas as 2400 and 2800 RPM, respectively, making them inaccessible. Also note that the kPa used is vacuum and not pressure. I simulated the code to ensure this is in fact what will happen.

[space387]

Thank you elky. With the use of electric solenoids maybe I could use that table for when to have it closed.

[84Elky]

Thank you elky. With the use of electric solenoids maybe I could use that table for when to have it closed.

Hate to be a downer, but using the table without EGR active will not work. The Table at 0x2B2 (table actually at 0x2B5 because there are 3 Scalars at 2B2-2B4), can only be accessed if MAT is >= the MAT Threshold value at 0x2B0 (Factory default =0x01E =30d ~=41*F). And this causes EGR to be active which could cause other unintended things to happen because you can't prevent partial pressure calculations which may have unknown results without chasing the entire code. The unintended result may be nothing or a crappy running engine, but nothing harmful.

So if you're running S_AUJP (which you should be), and are adventurous and really want to do this, here's what you can do:
- Create 2 XDF Scalars, one pointing to 0x5B80 and the other pointing to 0x5B84. These are the code locations of the 0x50 (2000 RPM) limit. You can verify this by looking at the BIN in a hex editor. WARNING: Code locations only applicable to S_AUJP.
- Set XDF Conversion = X * 25, but maximum entry value cannot exceed 2800 RPM if the minimum RPM value at 0x2B2 is changed from 0x20 (800) to 0x40 (1600).
- Set the VACUUM (note it's not pressure) minimum at 0x2B3 to what you want. Zero is the likely value because 0 kPa vacuum is 100kPa pressure.
- Enter the 0x2B5 table values you want.

Give it a shot, but please report back the results if you trry it.

[space387]

Hate to be a downer, but using the table without EGR active will not work. The Table at 0x2B2 (table actually at 0x2B5 because there are 3 Scalars at 2B2-2B4), can only be accessed if MAT is >= the MAT Threshold value at 0x2B0 (Factory default =0x01E =30d ~=41*F). And this causes EGR to be active which could cause other unintended things to happen because you can't prevent partial pressure calculations which may have unknown results without chasing the entire code. The unintended result may be nothing or a crappy running engine, but nothing harmful.

So if you're running S_AUJP (which you should be), and are adventurous and really want to do this, here's what you can do:
- Create 2 XDF Scalars, one pointing to 0x5B80 and the other pointing to 0x5B84. These are the code locations of the 0x50 (2000 RPM) limit. You can verify this by looking at the BIN in a hex editor. WARNING: Code locations only applicable to S_AUJP.
- Set XDF Conversion = X * 25, but maximum entry value cannot exceed 2800 RPM if the minimum RPM value at 0x2B2 is changed from 0x20 (800) to 0x40 (1600).
- Set the VACUUM (note it's not pressure) minimum at 0x2B3 to what you want. Zero is the likely value because 0 kPa vacuum is 100kPa pressure.
- Enter the 0x2B5 table values you want.

Give it a shot, but please report back the results if you trry it.

On my week off I will give this a try. Unfortunately I still can't use the S-aujp adx for communication. I tried following the instructions in the read me but it comes up as garbage. By swapping to the y body adx I have it reads just fine but lacks some data. I have heard of one or two others with this issue in the corvette and figured it to be one of the extra systems not shutting up.

[84Elky]

Two tings:
1.
I spent some more time looking at the EGR table, etc. and have discovered that the MAP variable used to access the table is NOT vacuum after all. It is Scaled MAP kPa pressure. Scaled just means it has been adjusted for table lookups and comparisons in the code. This mislabeling of the variable goes all the way back to the first $8d hack produced. But it's easy to see why the initial conclusion was that it was vacuum. Too complicated to explain, but adding that variable to another known to be vacuum yields approx 101 kPa (sea level pressure) proving it is pressure and not vacuum

2.
There is no reason why the S_AUJP ADX will not work unless it's corrupted. It doesn't know a Corvette from a Yugo -- just that it's $8d. So please either:
-Post your BIN, XDF and ADX, or
-Email the them to me if you do not want to post and I'll figure out what's wrong (PM sent with email address).

Elky

[space387]

sorry for the delayed response, work has been hell. So I was thinking about the issue I have running S_AUJP on my corvette and I do not think it is an issue with 1227727 ecm and the modified code. I got to thinking that maybe it was just the ADX was missing a few silence commands allowing the CCM and ABS module to keep flooding the aldl line. Now I looked at the silence commands for the two ADX files and there are separate commands for the CCM and ABS on my working ADX. The silence commands for the S_AUJP are using different hex values. I do not know nearly enough about the code to understand what the difference but is it possible that the corvette needs the extra commands? The included file is my goto for data logging and even works with S_AUJP for most of the data

Also I was looking over the features of the S_AUJP and noticed there are no variables for the Corvette upshift light. If I leave these values from the current Bin in the transfer will I still have that feature or has that been coded out to make room for other options?

[NomakeWan]

Corvettes absolutely need different/more silence commands from most other GM cars due to how many computers are on that bus. I'd tag steveo to see if he has any hints, since he's mostly got Corvette communication working in EEHack (for 94-95) and nailed flashing without interruption for the same cars.