$EEHack Read Failure Every Time?

[NomakeWan]

Just went out and swapped PCMs, and confirmed that when I put the '94's PCM into the '95, I get zero connection errors. I didn't start the car since I didn't know what would happen putting an automatic PCM into a manual, but I don't need to start the car to get errors randomly on the '94, so no big. So there does appear to be a problem inherent to the chassis somewhere, not inherent to the PCM. Time to tear into the ALDL harness as well as inspect all the grounds, perhaps this weekend.

Also, steveo, how does the "Transmission Perf Button Pressed" indicator work in EEHack? It shows up as "ON" constantly on mine unless I ground pin 13 on the grey connector, at which point it reads "OFF" until the ground is disconnected. From what I've read this switch is just a momentary switch with a ground connection, so perhaps it should be the other way around? Maybe it's different on an F-Body?

[steveo]

could you please try the latest beta out to see if you get any similar data corruption? i dont know anyone else getting that problem consistently enough to be a guinea pig

[NomakeWan]

Okay, tried the latest version and it works wildly differently from the old one. The error counts skyrocket (250 in 17 minutes, 500 in 34 minutes), but analyzing the resulting logs I no longer have any one-frame DTCs, BLMs over 18, insane knock events, or anything of the sort. It appears to be doing exactly what it's supposed to do--reject the bad data. :) I have attached the log of the drive to this post.

In addition, the read routine now fails every single time--but does so properly. With 4.7.0 the read routine would either successfully complete and then complain about a checksum issue or would fail partway in an unrecoverable fashion that required me to remove the ECM fuse behind the battery to get back to normal operation. I tried the read function four times with 4.8.0 and all four times it got about 25% through and then hit an unrecoverable error, the program reset the E-Side and T-Side, and dropped me back to a working state as it's supposed to do. I've attached a verbose debug log of one such read attempt for reference. This still proves that there's an underlying serial data issue on my '94, but at least now EEHack is handling these errors with grace. :)

I did notice some other bugs, but I'll go ahead and post them in the EEHack 2019 thread instead.

[steveo]

awesome thanks for that testing. you've confirmed it was definitely ignoring checksums in the last version. honestly given the drastic changes in the datastream code over the last few versions, and given then fact that I did it without a test bench or a car to try it on, i'm not surprised. glad it's fixed.

you definitely have a noisy aldl bus in that car but I wonder if it's a device that decides to keep chattering (corvettes definitely have a noisy aldl bus) i'd be curious to see if you ever find out what's up with that... if it's just a device we need to shut up, we can do that easily...

[NomakeWan]

Since I have the RPO sheets for both cars, I can say that in terms of features the only difference between the two cars electronically is that the '94 has the FX3 suspension and the 4L60E transmission. The transmission is handled by the PCM so that's not likely (right?), and the FX3 IIRC has its own communication that is separate from ALDL and has no ability to transmit serial data. Not to mention the problem existed before I knew that the FX3 module on my car had been unplugged, so I'm going to guess that's a red herring.

Both cars have passive keyless entry, automatic climate control, Bose audio, dual airbags, ABS, ASR, cruise control. The '95 has a bad alternator (it whines like a supercharger) but that doesn't seem to affect the data. The '94 has bad data even when the engine isn't running anyway.

I did go out and do testing on the grounds. Both vehicles use the OBDII-style 16-pin ALDL connector. On both vehicles, Pin 4 reads 92 ohms between pin 4 on the ALDL and the negative post of the battery. On both vehicles, Pin 5 reads a fluctuating value between 130 and 212 ohms between pin 5 of the ALDL and the negative post of the battery. This would seem to indicate to me that ground on the ALDL connector is not the issue. It could still very well be the 8192 signal wire.

On the '95, the previous owner was under the driver's side dash to replace a brake booster. He left the footwell light unplugged but otherwise it seems to all be there. On the '94 there is no real evidence that someone has been under there, but I did notice that the ALDL connectors on each car are mounted differently. On the '94 it's mounted pointing straight down, with one bolt and one plastic lug. On the '95 it's mounted on a bracket that points it towards the firewall and is held on with two bolts. I can't be sure if this was a year-to-year difference or a clue as I only have these two cars to work with.

[NomakeWan]

I apologize for the double post. I decided to try out TunerPro RT for the first time. EE_Auto.adx didn't work at all. $EE-16188051-Y-body-V3.8.adx worked perfectly...or so it seemed. It connects without issue and shows 0 errors straight through. But when you go back and look at the data, you still get a few random frames of absolute junk that the program accepted as legitimate data rather than as errors. For example, ignition voltage 19.7, engine run time 60427, knock count 18437...etc. It's clear that this is bad data, but just like EEHack used to, TunerPro RT is accepting bad frames as good for some reason.

I also tried Scan9495 v2.6.2 and it didn't want to stay connected either. It does have a verbose log generator too, so I went ahead and nabbed that. It's attached to this post. If the problem is with something on the ALDL line that won't shut up, surely there would be a way for me to listen for it and find it, right?

[steveo]

since its writing over a running datastream its hard to tell which device is misbehaving but maybe we can probe a bit. ill see what i can come up with