94 LT1 High/Low Res Pulse fluctuation at low RPM?

Hey y'all,

So recently I've been trying to hunt down a strange surge that happens sometimes in my dad's '94 Corvette. This only seemed to happen when stopped with your foot on the brake in Drive, so initially I suspected a vacuum leak or brake issue. Thankfully I managed to get it to do it while I was logging, so I was able to see what was causing it. What's apparently happening is the PCM is detecting a non-existent momentary spike in engine RPM, which causes it to wildly alter the IAC position, followed by the PCM very quickly realizing its mistake and wildly altering it back to where it was, causing an RPM surge. I was only speedlogging at the time, though, so I only had the high res pulse initially to see.

The EEHack log I've attached contains both high and low res pulse data from the Main datastream. It's from an hour-long drive along a freeway, followed by then coming to a stop when arriving into the city and hitting traffic. There does not appear to be any fluctuation in either high or low res pulses the entire time on the freeway. But the moment we slow down, the signals start getting funky. There were also a few momentary signal dropouts in the data, but I'm not sure they're related. This car has always had a "noisy" serial bus, and it could also be as simple as the cable being loose on my laptop and momentarily disconnecting. Or it could be related. I never did discover why this car's ALDL seems to cause so many packet failures.

I replaced the opti harness as a cheap hail mary but that made no change to the issue. Haven't yet inspected the entire body side harness for the opti. That it only happens at low RPM makes me wonder if it's something with a ground or voltage issue, but I'm not sure. Before I start tearing into stuff, figured I'd ask around, see if anyone here has experienced an issue similar to this one.

Thanks!

Hi
Check out the stall saver issues Steveo identified: Discussed on here if you search.

Also Brake Servo comes to mind letting air in to system. Motor revs up when I stamp on the brake while stopped, IAC tries to take up the slack.

Mitch

Quote:

---

Originally Posted by Terminal_Crazy

Hi
Check out the stall saver issues Steveo identified: Discussed on here if you search.

Also Brake Servo comes to mind letting air in to system. Motor revs up when I stamp on the brake while stopped, IAC tries to take up the slack.

Mitch

---

Please re-read the post. Not to be rude, but neither of those things are the issue. The stall saver isn't an issue on the 4L60E (it is on the ZF6, like my 95, but I have it disabled on my 95 already). Additionally, this isn't a vacuum issue at all. If you actually look at the data (it's right there in the log I attached), you'll see that the PCM detects a phantom spike in engine RPM (the engine isn't actually revving, and in fact it's pretty much impossible for the engine to go from 550 RPM to 4000 RPM and back to 550 RPM in 6 milliseconds), which it then reacts to by adjusting the IAC, then adjusting it back, which causes an actual surge in the engine.

a "phantom surge in rpm" on an lt1 like that could really only be a dying opti, or corruption in its signalling (bad harness/wiring/whatever or some nasty interference from a nearby arcing coil wire or something
time for a replacement soon
disclaimer did not view your log

Haven't had this problem, but looking at the log you might consider adding the possibility of a PCM fault (internal/external/wiring) to the list.

The data dropout early in the log looks real - the PCM sees it and is throwing codes when this happens. Since the dropout includes loss of opti signal(s), this could be related if it there is a rapid drop/restore that affects the apparent timing pulses. I noticed for the false rpm cases when both hi res and low res rpms are affected, both give the same false rpm. Looks like there could be something in common there.

Sorry for no solid answer, but hope this helps.

Jim

basic diagnosis technique says that when evidence points to a sensor fault, always check the sensor itself first and go backwards from there, so i guess if i had to make a diagnosis flow chart, the point where you are on that chart should involve an oscilloscope snapshot of the opti output where the problem occurs. if the scope reading stays solid when the glitch occurs you know you have an external issue.

i realize not everyone has a 'scope laying around but that'd be best

the datastream is checksummed so it's really unlikely that noise on the bus would produce a phantom false rpm reading, or cause input to the ECM that would affect how the engine runs. (...that's assuming your eehack version is current, versions from over a year ago often displayed data with bad checksums due to a bug)

also it's an LT1 so statistically it's more than 90% likely that you have a dead opti if anything like this happens. those things are just troublesome.

i did look at your log and i see the datastream does have random burps in it for sure. the dropouts vary in length a little bit which does point to random noise on the bus.

although it appears to be correlated to a few RPM events on first glance, there are tons of dropouts even without that rpm fluctuation, and no other data appears to fluctuate. this does kind of point to an underlying wiring issue although i'd keep poking at the opti anyway.

one eehack feature you might find helpful if you haven't tried it already to diagnose the datastream itself, is in the graphing window use 'show points'. each point is a log sample so it makes it super easy to visualize your datastream's dynamic sample rate vs the data itself so you can tell if a flat line is actually flat or simply a slow datastream. this works really well when you're capturing two datastreams at different rates and graphing them. just don't zoom out too far on a slow computer - the point drawing routine is not very efficient and can crash eehack if it's trying to draw millions of points.

I have no specific suggestions for this issue. I do have some experience that indicates LT1 Y ignition circuits are not to be considered independently of other circuits. A particular backyard racer's car was traded to the dealership and I had to track down a number of problems owner created. One was abs activation and RPM surge when ABS should not have been active. Ultimately I determined the previous owner had removed the tach filter capacitor from the engine and because of this the ABS module was seeing excessively high vehicle speed on the RF wheel at lower vehicle speed and idle. I was able to track this by noting on a scope the wheel speed signal was an amalgamate of wheel speed and something looking like RPM. It was actually the engine flare on 2-1 downshift that showed up first.

Based on my experience I would consider using a scope to monitor low/high res pulses as well as ignition coil trigger to look for correlations with the surge. I do not know that I would put the communications issue in the same bucket at this time but of course there's no reason to decide it shouldn't be there.

Looked at the log closely and there is3 parameters that points to failing high or low res signal.

Check high res rpm/ spark adv /low res rpm / cyl id raw

They fail at random rate or together, which discard the bad checksum gremlins that were experienced with older versions of eehack.

Cyl ID raw is the most important parameter here. It measures the high res counts between low->high low res transitions. It gives the cyl ID for the pcm. It can have predefined values with very little variations. The lowest is 46. There are numerous spikes to 20 range, which is definitely a sign of failure.

To confirm wiring issue only high res scope can do the job since even high speed pcm logging suffers to capture the events.

NomakeWan,
Since you will be doing the opti soon I think it is the perfect time to upgrade to coil on plug system.

As a side note and confirming stuff.
You can also adjust some timers to make the pcm fail on first spike.
Set 12035 to 1 or 2. or zero. It is the timer of continuous cyl id mismatch to setup a high res error.

Setting this timer to 1 or 2 will also save you from engine hard starting issue, at complete high res signal failure.

Thank you for the replies. I'll try to address a few things brought up in order.

First, this is EEHack 4.93, which IIRC is the latest version. I helped with the whole "checksum mismatch" bug in earlier versions since this very car was the one that made that particular issue clear. So yes, this version of EEHack should be the one that's resilient against bad checksum packets (and in fact the error counter was over 700 before I stopped logging). So no, I don't think any of the data is bad, nor do I blame EEHack in any way shape or form for how the engine is running. I also don't think any of the data was a result of a noisy bus. The only exception to that are the random dropouts, which I cannot be sure are a result of bad data (since I know for a fact that jostling the cable in the USB port on my laptop can cause a device disconnect, and I don't recall what happens to logged data when this occurs). I should note, however, that despite EEHack reporting several supposed DTCs during these dropout periods, no DTCs are actually stored, nor does the SES light come on. These are entirely phantoms, seen only by EEHack, which further leads me to believe that it's not real but is rather either bad data somehow making it past the checksum, or a cable disconnect causing a bug in EEHack's display.

I agree that checking the low res and high res signals with a scope is an excellent diagnostic. But as you correctly assume, I don't actually have a scope handy. I do have a logic analyzer, but I don't have a way to crank it up to the data rate I'd need to make it emulate a scope on a signal like this. I could give it a shot, but I'll probably end up trying to acquire an actual scope instead. I've been meaning to get one anyway, may be time to pony up some cash.

The tach filter circuit is present and accounted for. I actually have the full maintenance records for this car stretching all the way back to the day it was purchased from a local dealership, and it's been kept in excellent condition. That's why I found it so strange that it was the one to end up with a random unexplained surge and a noisy data bus despite being in far better overall condition than my '95 (for which I have a grand total of zero records, and which has been beaten on).

kur4o, thank you for your excellent analysis as always. I'll go ahead and make the change to the BIN on the '94 to see if it trips the high res fail. I hope I don't have to do the opti soon on the '94, that would pretty much suck. My '95 required the whole kit 'n' kaboodle last year and that's been one hell of a bit of surgery. To then turn around and have to do the same on the '94 would be pretty much awful. As for swapping to coil, I do have a single DIY-LTCC here, but I was intending it for the '95 to test with. The '94 is my dad's car so I can't really use it for prototype stuff, which means I'd have to switch to an out of box solution, and currently there isn't one. Even if I wanted to pony up the wad of cash for Torqhead, they discontinued the C4 package last year.

Anyway, thank you all for the replies. It looks like I'll need to get myself a scope and start digging through some wiring if I want to get to the bottom of this mystery without throwing more random parts at it.

even a really crappy ebay scope is fine for most automotive work for guys like us. i have a real professional tube scope and a hantek that i think was about 50 bucks on ebay, i usually use the hantek. the software is really bad but since there are so few controls and so few options, trying to figure out why your waveform isnt showing up doesn't feel like flying the space shuttle. they're really fun to have, even just for measuring dc stuff, you can measure the quality and stability of your voltage, not just its value

as far as the checksums go, it's totally possible for random noise to break such a simple checksum and a few bad bits would slip through, but pretty unlikely as it would have to coincidently add/subtract the exact value from both the data payload and the checksum, but i would also expect noise extreme enough to fuzz that math to also cause millions of times more bad checksum events

is it possible there's a bug in eehack where the packet right before a bad checksum can slip in there? yes but i would expect other bytes to be glitching out too

is it possible that total fuzz or even occasional bit flipping in your datastream would coincidently fool the checksum so incorrect data gets through (by adding exactly the same value to one thing as it subtracts to another)? yeah, but the odds are insanely low

i actually didn't see the phantom DTC codes pop up but i also didn't really dig through the log much, what timestamp do they occur at?

oddly enough i remember seeing logs in tts datamaster with noise in the datastream, odd nonsensical DTCs would pop up and then disappear right away with no other effect in those areas as well. it could be a bug in EE itself as i've never observed that with another mask. i don't think we've ever had a proper reverse engineering of the ALDL code with regards to the checksum, and i think i remember kur4o theorizing that it's done in a chip

Quote:

---

Originally Posted by steveo

even a really crappy ebay scope is fine for most automotive work for guys like us. i have a real professional tube scope and a hantek that i think was about 50 bucks on ebay, i usually use the hantek. the software is really bad but since there are so few controls and so few options, trying to figure out why your waveform isnt showing up doesn't feel like flying the space shuttle. they're really fun to have, even just for measuring dc stuff, you can measure the quality and stability of your voltage, not just its value

as far as the checksums go, it's totally possible for random noise to break such a simple checksum and a few bad bits would slip through, but pretty unlikely as it would have to coincidently add/subtract the exact value from both the data payload and the checksum, but i would also expect noise extreme enough to fuzz that math to also cause millions of times more bad checksum events

is it possible there's a bug in eehack where the packet right before a bad checksum can slip in there? yes but i would expect other bytes to be glitching out too

is it possible that total fuzz or even occasional bit flipping in your datastream would coincidently fool the checksum so incorrect data gets through (by adding exactly the same value to one thing as it subtracts to another)? yeah, but the odds are insanely low

i actually didn't see the phantom DTC codes pop up but i also didn't really dig through the log much, what timestamp do they occur at?

oddly enough i remember seeing logs in tts datamaster with noise in the datastream, odd nonsensical DTCs would pop up and then disappear right away with no other effect in those areas as well. it could be a bug in EE itself as i've never observed that with another mask. i don't think we've ever had a proper reverse engineering of the ALDL code with regards to the checksum, and i think i remember kur4o theorizing that it's done in a chip

---

Hey, thanks for the response! My dad is actually wanting a scope to do some network diagnostics, so I left it to him to figure out the minimum spec he requires for one before we go buying one. Or yeah, I'd just get a cheapie scope off eBay same as you did. I'd freaking love one that can do RF hacking and EMF testing, but GHz scopes are really freaking expensive...

Anyway, the timestamp with the phantom DTCs is the same as the signal dropouts. So for example, #13488 @ 1341.4. The signal drops out completely, and the ECM Trouble Codes suddenly report a bunch of DTCs that don't actually exist. Then in the very next frame all is back to normal. None of the data in that frame is real. Same with the dropout at #18875 @ 1879.8, though that one lasted two frames instead of one.

Like I said, I'm not sure whether these things are actually related. I don't recall there being signal dropouts on previous logs with this car, but again, I cannot be certain that this isn't a result of the USB cable having a poor connection on my laptop. Yes, it could be some sort of random error unaccounted for on the ALDL bus. Yes, it could also be an error with the ALDL cable's USB connector. I don't know which, and that's where I'm probably gonna need a scope.