DIY PROMDo It Yourself PROM chip burning help. No PROM begging. No PROMs for sale. No commercial exchange. Not a referral service.
Welcome to ThirdGen.org!
Welcome to ThirdGen.org.
You are currently viewing our forum as a guest, which gives you limited access to view most discussions and access our other features. By joining our community, at no cost, you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content and access many other special features. Registration is free, fast and simple, join the ThirdGen.org community today!
If you want to tune you will need to swap in a supported ECU. GM 7747 and 8746 and EBL (dynamicefi.com) come to mind. Something tells me you need to repin your harness(see TurboCity, Painless Wire) to do so OR modify the ECU board called HAM see Speedtronics.net
Some background is in order. I have TunerPro RT up and running on my laptop because I use it on my Turbo Buick.
With the proper .ads and .xdf files, can it be hooked up to my 84 Z28?
If so, does anybody have the needed .ads and .xdf files for this application?
And what type of hookup do I need from the laptop to the ALDL connector?
Can this be done?
TIA
Your '84 should be a CCC set up. Unless maybe a Crossfire? Either way they would both be 160 baud, same as the '89 TTA ECM.
The only downside is that most likely a 10K resistor will be required between A&B on the ALDL connector. This is required to get the CCC ECM to send data. And of course, also puts the ECM into diagnostic mode which changes how it runs the engine.
Check the Tuning Guide Book sticky for information on the CCC setups. There may be something there that will help with the required files and such.
Thanks guys. I was afraid the carburated 84 L69 wouldn't be supported. No big deal really. I just thought it would be another use for the TunerPro RT that I'm running on my 86 GN.
Since I'm trying to sell my 84 Z, I really don't want to have to change anything just to data log. It's almost 100% original and I'd like to keep it that way.
Didn't see any .xdf files, but that particular set of .bin files is for the '82-87 Camaros with the ZZ4 engine kit and CCC if I interpret them correctly.
Hope that helps....
__________________ 1993 Chevy Z/71 with Vortec 350, ZZ4 cam,TBI mods. Switching to TPI next year I hope
1999 Monte Carlo Z/34
1989 Trans Am GTA, 350, Trick Flow Super 23 Degree heads, LT4 HOT cam kit, Holley StealthRam, BBK 58mm TB, RamAir hood with cold air induction
Couldn't address hit tracing be used to datalog without using the datastream and enabling diagnostic mode?
From my understanding it just tells you what addresses it HIT, and not the data at those addresses. Also you are talking about hundreds of hits per second. I need to play with the address tracing some more to make sure this is correct.
__________________ Paul Schwab
93 Black/Black Typhoon #424 www.code59.org - Code Tester and XDF Creator
From my understanding it just tells you what addresses it HIT, and not the data at those addresses. Also you are talking about hundreds of hits per second. I need to play with the address tracing some more to make sure this is correct.
Knowing what address is hit, should be able to indicate what values are being used and from that and your tactile senses and a WBO2 reading should be able to tell what needs to be changed.
Knowing what address is hit, should be able to indicate what values are being used and from that and your tactile senses and a WBO2 reading should be able to tell what needs to be changed.
But, it was just an idea.
What's "address hit tracing" and how do I get it?
That would "kind of" work, but would be very convoluted and prone to error and innacuracy. For one, address hit tracing misses about 75% of actual hits (it's good for rough indication of where you're running in a table, when ALDL data isn't available for the correlation). Second, the value for an address hit is relevant only to that value in the calibration, and that doesn't necessarily reflect the value in RAM that the ECU is actually functioning off of. For instance, an address hit might indicate that a value in the spark table was requested, but that value in the table might not (read: probably doesn't) reflect the final spark that's being outputted, since the final spark takes into account spark correction, base timing setting in cal, ALDL spark, etc.
That would "kind of" work, but would be very convoluted and prone to error and innacuracy. For one, address hit tracing misses about 75% of actual hits (it's good for rough indication of where you're running in a table, when ALDL data isn't available for the correlation). Second, the value for an address hit is relevant only to that value in the calibration, and that doesn't necessarily reflect the value in RAM that the ECU is actually functioning off of. For instance, an address hit might indicate that a value in the spark table was requested, but that value in the table might not (read: probably doesn't) reflect the final spark that's being outputted, since the final spark takes into account spark correction, base timing setting in cal, ALDL spark, etc.
Good thinking though!
I realize it would show final calculated values, but figured it could give an idea of what's being used. I haven't used the adress tracing myself, but it seems some of the Ford guys do, I know I've read posts about Dex using it. I didn't realize it would miss that many hits.
