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
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.
1990 Corvette (Manual)
1994 Corvette (Automatic)
1995 Corvette (Manual)
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.
Last edited by space387; 11-03-2020 at 07:38 AM.
i'm totally confused. We started out addressing S-AUJP control of exhaust cut-outs with EGR activity from the ECM. Now: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.
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?
Last edited by space387; 05-12-2021 at 09:38 PM.
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.
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.
Last edited by space387; 05-16-2021 at 05:30 AM.
OK, here's a solution but it's not elegant. I have simulated it to ensure it works. But CAUTION:
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.
Last edited by space387; 05-17-2021 at 03:48 PM.
Posting Permissions
Reply With Quote
Bookmarks