Printable View
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.Quote:
Originally Posted by space387
I am using the egr output to control cutouts. Is there a better option?Quote:
Originally Posted by 84Elky
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?
The goal is to open above 2500 and at a tps of over 50%
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.Quote:
Originally Posted by 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.
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.Quote:
Originally Posted by space387
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.Quote:
Originally Posted by space387
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.Quote:
Originally Posted by 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
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?
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.
Have the silence code from the working ADX I just need to know can I just add it to the new ADX without wreaking havok
You can't break anything permanently, so may as well just give it a shot.
so I got it to work. I had to carry over the entire connect and Mode 1 dump instructions to get the S_AUJP adx to work but it does and I have a few values to look at. I do think something is changed in the spark control because I'm showing a consistent 30* advance during a cold idle.
*edit- so um... seems I have it set to 30* on the main spark table. Strange it was staying fairly close to the 24* on the idle table before.
i'm totally confused. We started out addressing S-AUJP control of exhaust cut-outs with EGR activity from the ECM. Now:Quote:
Originally Posted by space387
1)
What issues with running S_AUJP on the 7727? There is no functional difference between the 7727 and the 7730 ECM other than the 7727 being the underhood version.
2)
The posted bin is not S_AUJP. Neither are the XDF and ADX. So if your're having issues, I'm just not able to help with other than S_AUJP because too many differences from other versions.
3)
If the ADX silence commands are not what you want, change to yours. But no S_AUJP user to my knowledge has had problems with those provided. Frankly, despite other comments here, they are likely not even needed because the original pre-S_AUJP ads file posted on tunerpro.net does not include them and virtually all early $8d users used that file. There is not a problem with the S_AUJP ADX. Hundreds are using it. Something else is wrong.
4)
Yes, the Factory $8d shift light logic was removed from S_AUJP in its release, along with other CARS logic because most was not used. The read me describes what to do to implement the new shift light. See Note 2 below:
Shift Light
Purpose: Uses the Check Engine (CE) Light to indicate a RPM Shift Point when illuminated.
How to Use: Two Scalars control Shift Light operation while in gear (0x031 b0=1 = In Gear). If b0=0 =In P/N, the light is inoperative:
The CE Light will be illuminated when RPM is >= the Scalar below:
---0x365 Scalar: Shift Light-ON if RPM >= (Shift Point) [Default: 7969 RPM]
The Shift Light will remain on for the time specified in the following Scalar as long as RPM is above the Shift Point RPM:
---0x254 Scalar: Shift Light-Maximum Time CEL On [Default 1.0 Seconds]
Default: Shift light illumination is OFF by default with the above 0x365 Scalar being set = 7969 RPM
NOTES:
1. In reviewing logs, it’s possible there can be what appears to be a lag from when the Shift Light is indicated ON relative to the reported RPM. For example, if the Shift Point is set at 5000 RPM, it’s possible to see the Shift Light indicated ON in a log sample at a slightly higher RPM, say 5025 RPM.
This is caused by timing differences between when the Shift Light is indicated ON and when the corresponding RPM is reported in the ALDL data stream. The light is always indicated on, and turned on, at exactly the Shift Point RPM. This reporting difference can occur because code activities occur as fast as 160 times a second (every 6.25ms); while log samples are, on balance, provided every 100ms or so, causing intervening activities to not be reported.
2. If a more visible light or audible signal is desired, a 12v light or audible device (buzzer) can be connected to ECM Pin F1. Anything connected to this Pin will provide original Factory GM $8d shift light functionality and will work in concert with the CEL Shift Light.
space --- Something is clearly wrong with your S_AUJP bin. There is no change to spark logic. Again, there are hundreds of users without incident.Quote:
Originally Posted by space387
If you would please post that listed below, I'll be glad to help. But can only deal with pure S_AUJP files -- not hybrids or mix and match.
-S_AUJP bin that is allegedly not working properly
-The $8d bin used to create the S_AUJP bin
-S_AUJP ADX and XDF files being used
Elky
Elky, not trying to sound argumentative but how may users have tested this on a corvette? There are quite a few extra modules that share the Aldl line and without a silence command they cause a communication nightmare. Below I have linked the starting .Bin .xdf and .adx Along with the S_AUJP V6 I am using and is working properly now. With the unchanged stock .adx you provide I get intermittent data/ garbage readings with a repeated checksum error. If I use the 1990Corvette.Adx it reads properly with a few missing bits of info caused by the variation in definitions. By mimicking the connect procedure of the corvette.adx on yours the connection is working just fine. It was not a .Bin code issue.
The spark "issue" is not an issue just something I did not notice in the past. Due to hardware limitations I would have an issue getting startup and cold idle logs but now that is fixed with new logging hardware and software. I can not explain why on some logs I would see the idle advance at 30* and others at 23-24* aside from not fully understanding the trigger for the idle advance tables.
I am sorry this thread took a tangent but there was mention of the ability to try using the S_AUJP and frankly I wanted its benefits to reflect the changes I made to my engine. It is unsettling to think about tuning an engine built to run to 6500 with a fuel table that stops at 5600. FWIW this is no longer a TPI but a LT1/L98 hybrid. That's where the .bin names come from, not mashing of your code with factory code. Sorry for any confusion.
About the factory Shift Light, you mentioned the use of F1. Is this the same pin as used on the Corvette or are we discussing a different pin. I was hoping it was possible to retain the factory shift light without having to rewire.
Thank you for sticking this out.
Thanks for your detailed reply for things now makes sense. So a couple of comments:
1)
Yes, to interface with other modules (BCM/CCM, etc.), the ADX Commands may require change. Some history. The initial release of S_AUJP did not have an ADX file released with it. That was only done with later releases as a courtesy due to additional items that could be reported via an ADX. Due to the varied requirements for "Commands" in certain applications, only the most generic were included. They were based off the initially released pre-S_AUJP ads file. So this would possibly necessitate BCM/CCM applications copying over the working commands as you have done. This is something that will be added to the docs in the future. Unfortunately it's not possible to provide every command set used. But I do know there are other Corvette S_AUJP users who are not having any issues. Perhaps they are using their original ADX. Bottom line, glad it's solved!
2)
Yes, Pin F1 is the factory manual transmission pin for shift lamp control. You can also connect a 12v buzzer or light to this pin to augment the CEL. You may have to play with the light duration control bit to get the result you want. The shift control portion of the code was deemed unnecessary for performance applications so it was removed in favor of other features. The shift light functionality was retained, but rewritten.
3)
It is unsettling to think about tuning an engine built to run to 6500 with a fuel table that stops at 5600. FWIW this is no longer a TPI but a LT1/L98 hybrid.I assume "fuel table" refers to the VE table. If so, to address the issue you raised, note in the XDF there is an LT1-style Extended VE table that is graduated at 5 kPa increments, and RPM is scaled up to 6400 RPM. This table is accessed by setting the bit: S_AUJP OPT 1 (0x98E), b5, Use Z69 EXTENDED VE Table to 6400 RPM. There is also an Extended PE table to 8000 RPM that can be similarly accessed.
Again, thanks for the detailed post and sorry for the confusion and HTH,
Elky
No worries, had plenty of experienced like this learning my way through megasquirt. If there is any thing else I could do to help you with future improvements of they system please let me know.
An update on the ecu controlled cutouts, they work and rather well. There was a mention about the adjustments to compensate for the egr flow, that is referenced to a partial pressure table that can be zeroed. After looking over the jp_AUJP2 code it looks like making a new table would be easier than modifying the current egr duty cycle table. Would it be possible to get a little direction on how one makes a new table in the code?
If you are not proficient in assembly language programming and don't have the ability to assemble the code into a bin file, ti is not possible. Perhaps if you explained exactly how it is working now and what you want to change or trying to implement, I might be able to help, but need details.Quote:
Originally Posted by space387
Elky
I have an arduino set up to drive a waterproof servo on the dump valve I am trying to operate. I use a 5v constant with a 100ohm resistor to the arduino and the egr trigger wire off the ecu(a4 if I remember correctly). The arduino can detect if the ecu is triggering the egr circuit by the voltage dropping at the arduino. I have changed the partial pressure table to read zeros so the eco isn't trying to adjust the calculated air flow. I also disabled the egr test to prevent a ses light all the time.. Past that i have left the settings pretty much stock.
What I am looking for is to allow the egr table to be 400 rpm higher. Don't need added precision I just need the computer to keep the egr "on" to 2000 and shut off somewhere around 2400. I guess making the existing table start at 1200 and end at 2400 would be fine and we just need to change the hard limit to a larger value.
OK, here's a solution but it's not elegant. I have simulated it to ensure it works. But CAUTION:Quote:
Originally Posted by space387
THIS SOLUTION ONLY APPLIES TO THE LATEST PRODUCTION RELEASE OF S_AUJP: S_AUJP v6-28.BIN date/time-stamped 12/20/2019 2:40 PM
I assume you are referring to the table: "EGR, % Duty Cycle RPM .vs. Vacuum (kPa)" identified by TunerPro (TP) to be located at 0x2B5.
If so:
- Load the above BIN in TP (that is your v6-28 S_AUJP bin with your calibration)
- Change byte 0x2B2 from 20 to 30. This causes the table to now have a RPM range of 1200-2400, with the minimum RPM being 1200 (0x30=48d x 25 =1200)
- Change the following bytes from 50 to 60: 0x5B80 and 0x5B84. This changes the test for max allowed RPM from 2000 to 2400 (0x60=96d x 25 =2400)
- Save the modified bin perhaps with a different name to indicate bytes have been "poked", which changes how it functions.
That's it, but can't stress the above caution enough because the 0x5nnn addresses are certain to change with future released bins. Warning given!
HTH, Elky
PS ---
it would be appreciated if you would post your results.
Thanks for the reply. I am returning from the mountains tomorrow so I will test it out in the next few days. I looked through the V2 code that is already broken down and noted and compared it to the Anht some one also decompiled and noted on to find the address in the V6 code did not match up with what I expected.
The main reason I was trying to dig into this was to expand the use of the extra outputs for the 7727 and 7730 ecu. A large amount of people ditch egr, air and ccp so this would make them extra outputs for what ever people fancy. It might be worth in the future making the hard limit use the rpm limit and have the table definition a changeable variable so you don't have to walk us through making changes like this with every update.