1994 Corvette EEHack DataLog Review

[RISK81]

I was wondering if someone with more experience was able to review my datalog from earlier this afternoon regarding my recently rebuilt 355 LT1 with a LT4 Hot Cam kit and increased static compression (10.7:1). I have not had the PCM tuned yet but would like to possibly review before I do. I am unable to fully understand (at this point, currently learning) the data collected.

Besides the LT4 hot cam kit, everything is new (rotating assembly, heads machined, all new gaskets). The fuel injectors are stock (22lbs) and the throttle is stock, heads have been cleaned up and verified as 54.4cc.

I have put about ~100+ miles on the car since rebuilt but I feel like timing is being pulled and I am concerned about the knock counts as of now (no audible knocks from the engine (i verified with a stethoscope)).

I plan on tuning once I am able to pull the factory tune and save it on an external device.

Thanks in advance.

[steveo]

your log is a good example of a well running maf engine with really mild modifications that probably doesn't need much tuning.

load both your logs into eehack at the same time and run the analyzer with default settings (i pick really good defaults)

look at the knock scope and AFR

most of your 'knock' is just under 1000 rpm and over 50 kpa. this is either due to driver error (lugging a manual) or torque converter too small. when an engine gets towards the point that it wants to stall out, it often lugs and clatters and sets the knock sensor off regardless of ignition timing. it's really nothing to worry about from a tuning perspective. you could remove a bit of timing advance and adding some fuel in that range to see if it helps.

your cruise range AFR is really just fine, barely even worth tuning. you could play with your idle timing advance and stuff to get a better idle (not sure how smooth it is right now) and then start working on WOT tuning.

14117

14118

[steveo]

i should also mention the knock events near 20-25 map column are mostly during decel, and not much actual knock retard will occur from those

[RISK81]

your log is a good example of a well running maf engine with really mild modifications that probably doesn't need much tuning.

load both your logs into eehack at the same time and run the analyzer with default settings (i pick really good defaults)

look at the knock scope and AFR

most of your 'knock' is just under 1000 rpm and over 50 kpa. this is either due to driver error (lugging a manual) or torque converter too small. when an engine gets towards the point that it wants to stall out, it often lugs and clatters and sets the knock sensor off regardless of ignition timing. it's really nothing to worry about from a tuning perspective. you could remove a bit of timing advance and adding some fuel in that range to see if it helps.

your cruise range AFR is really just fine, barely even worth tuning. you could play with your idle timing advance and stuff to get a better idle (not sure how smooth it is right now) and then start working on WOT tuning.

14117

14118

Steveo,

Thank you for taking the time to review the data as a technical expert. I appreciate the response and suggestions.

Unfortunately I was unable to pull the factory tune from the PCM using EEHack (I tried changing the latency on the cable driver, attempted to use WinFlash (no luck with the application, didn't load correctly on two different machines with WIN7 & WIN10 - only was able to "uninstall the application")).

I believe I need to look into building my own cable with the mentioned andriono FTDI board (Happen to have a suggested wiring pin-out for the OBD1 16 pin connector?). Even with the latency changes I keep receiving a "Check sum error" with EEHack. I was able to data-log though which is the confusing part..

In the end I recently sent my PCM to http://www.lt1pcmtuning.com/ for a quick turnaround, and will continue to look into the PCM read issues once the PCM is back up online with the new tune.

Thanks again

[spfautsch]

I believe I need to look into building my own cable with the mentioned andriono FTDI board (Happen to have a suggested wiring pin-out for the OBD1 16 pin connector?).

I was under the impression the 94s came with the rectangular 12 pin ALDL connector.

If yours is a 16 pin OBD2 style connector this is what you want.



ALDL PIN USB>Serial
9--------------------rx
|------tx

4--------------------gnd

It really is as simple as connecting the rx and tx lines together. I've been using this exact setup since 2016. I have so much faith in it that I hardwired it to the harness so it frees up the ALDL connector.

I will attempt to read mine this evening just to verify there's no issues with the current version of eehack. I did find a read I'd made from 2016 so it did work, but I suspect it still does and the cable is the problem.

Getting winflash installed on an OS newer than XP may be a bit of a kludge. I think it uses mscomm.ocx which would probably need to be registered manually. I'm looking to see if I have a virtual with it installed that I can just send you the files and you can try installing manually.

14135

[RISK81]

spfautsch,

Thanks for the wiring diagram. What usb to serial device is recommend? Something like listed below?

USB to TTL Adapter, USB to Serial Converter for Development Projects - Featuring Genuine FTDI USB UART IC ‘FT232RL’ https://www.amazon.com/dp/B075N82CDL/ref=cm_sw_r_cp_apa_i_2rsTCbKGXVEY1

[spfautsch]

That wouldn't be my first choice but it may work. It has a different pinout from the ones I've used with arduino type stuff.

Something similar to this would be my first choice.

https://github.com/adafruit/Adafruit_FTDI-Friend-PCB

I think DigiKey may sell those, but you can probably find "clones" on eBay for much less. I believe DigiKey also sells a cable with the same pinouts but with the circuit board enclosed in the USB connector shell. It has a 6 pin female connector on the other end (commonly referred to as a DuPont connector).

Well after 15 or so attempts I've been unable to read my flash. Mine fails with "unable to retrieve key seed (mode 13)... try key off etc." Are you sure that's not the error you're getting? I've seen this once or twice attempting to flash, but not in a while. I even re-flashed twice - once without patches with the same outcome when attempting to read. I'll give it another shot in the morning to see if anything changes. I vaguely recall having this problem attempting to read in the past but since I have a good read from before any tuning it's never been a "real problem".

Still haven't found a windows virtual with winflash on it.

Edit: You may want to ask Solomon to send you a copy of the original bin.

[steveo]

that sucks, maybe i broke flash read at some point, but i don't remember changing it. i don't think many people use it

your original bin will probably be in here, no need to read it

http://fbodytech.com/bin-files-2/bin-files/

[kur4o]

I have done hundreds of reads and never had an issue. Could it be a vette specific bug. Interesting how pcm gets unlocked for a flash but fails to unlock for a read. A log will help. Maybe some unexpected response, gets picked. You might try removing battery on next fail to read, just to be sure.

I just remeber there are some timers with mode 13. Before it expires the pcm can`t be unlocked. It might be a good idea to wait some time after ignition is on, before starting a read. There are also different responses if an error occurs.

The best dyi boards have that designhttps://www.ebay.com/itm/FT232RL-3-3V-5-5V-FTDI-USB-to-TTL-Serial-Adapter-Module-for-Arduino-Mini-Port/312519296714?hash=item48c39a06ca:g:mFUAAOSwxDxcnsj k.

I have tried other with mixed results.

[spfautsch]

kur4o-

I highly doubt it's a Y body specific bug, but would you elaborate a bit on the timers you speak of?

It's highly possible some amount of key on time would help - it takes far less time to initiate a read sequence because there's no bin to select, and no "are you sure" warning nag to answer as there is with flashing. I've flashed hundreds of times without a single issue, and it only seems to cause me difficulty when I'm in a hurry (or in this case testing a read).

[steveo]

the only difference between getting ready for read or write is we don't upload the code to set VPP voltage for read (since it's not necessary), i can't imagine that has any effect

[spfautsch]

It has worked for me, I have a file named 'vette-eehack-read-0521.bin' in my 2016 logs and bins folder. I had no other reason to do a read other than to test eehack's read function.

If there's some timer that needs to expire in the ecu it may be possible to wait a few seconds after launching the flash window before enabling any of those functions so the key seed issue doesn't happen to others.

[kur4o]

The timer is set at pcm reset and until it expires, the pcm can`t access mode 13. It is also reloaded at some point, maybe to prevent mode 13 at engine running.

I suspect it to be 8-10 seconds timout after reset is done, before you can access security mode. Rearmed on wrong key.

There are some other timers too. One of it is the time between seed response and key recieved. The purpose of the others is not so clear.

[steveo]

kur4o could we get around that? dump the timer ram to see if its active and wait if it is? whats its location?

[spfautsch]

Thanks kur4o - that was it. Seemed to be about 10s from key on. Three reads in a row, no problems. As I mentioned steveo if we disabled all the buttons on the flash window for 10s after initialization that would take care of it. Or even easier just make the error message more descriptive along the lines of waiting longer. Had I known about the timers, well I can follow directions. Those who cannot will ask questions regardless.

RISK81 -

I feel confident your issue will be resolved with a diy cable.

[RISK81]

Edit: You may want to ask Solomon to send you a copy of the original bin.

Already did. Hopefully I'll be receiving the PCM this week.

[RISK81]

Thanks kur4o - that was it. Seemed to be about 10s from key on. Three reads in a row, no problems. As I mentioned steveo if we disabled all the buttons on the flash window for 10s after initialization that would take care of it. Or even easier just make the error message more descriptive along the lines of waiting longer. Had I known about the timers, well I can follow directions. Those who cannot will ask questions regardless.

RISK81 -

I feel confident your issue will be resolved with a diy cable.

Guys, Thanks for investigating the READ issue. As of now I have placed an order for the Adafruit IC bridge USB-UART Module (PN_1528-2591-ND) and also the Adafruit FTDI Serial TTL-232 USB Cable (PN_1528-1644-ND) through Digi-Key. Once the units are received, I'll construct a basic temporary cable and terminate to the mentioned pins listed above and post the results regarding the read function after a 10 sec delay from key-on.

If this checks-out I like the idea of terminating a permanent cable to the back-side of the ALDL connector at the specified pins with appropriate strain-relief for future flashing / data-logging.

Thanks again for everyone looking into this matter.

[RISK81]

All systems go!! I have successfully downloaded my PCM tune without an error via EEHack. It was the adapter all along (thanks to everyone). First attempt was with the FTDI serial TTL-232 USB cable - no success... Second attempt was with the AdaFruit board (PN-P284B) and a dedicated OBD2 blank connector with pins 4 & 9. Thanks again to everyone! 14188
14189
14190

[steveo]

nice, i love it when it isn't my code's fault.

[In-Tech]

Hello, and congrats on getting your communication fixed. I am curious what the difference was between what you were using verses the AdaFruit. I apologize if you already said, I must have missed it.