'94 Corvette Dyno Run Analysis

[NomakeWan]

Hey all,

The other day I finally had a chance to get my Corvette dynoed on a dynojet. There were six run attempts, but we lost three due to the ground cable on the dyno falling off the car and dropping signal as a result. I had my laptop plugged in and running EEHack the whole time because I was using it to lock the car in 3rd gear, but when I went to close the program it warned me about saving the log. I totally forgot it logs passively in the background as long as you're connected. So I saved the log. The dyno shop wouldn't let me have the dyno data but they did let me at least take a photo of the dyno screen, so here we go:

http://www.gearhead-efi.com/Fuel-Injection/attachment.php?attachmentid=14454&stc=1&d=1564960693

The dyno looks pretty noisy which could be the ground or could legitimately look that odd, I'm afraid I'm too new to the LT1 and 4L60E to be able to tell at a glance. My only real concern was the massive dip at the end of the first run, but it never appeared in any other runs, so I treated it as an anomaly.

I did have a crack at inspecting the EEHack log, but again my inexperience in how this engine works made it difficult to interpret since I'm not sure what "normal" looks like for this type of operation. I did notice knock retard going on a lot at WOT, but not usually tied to an actual knock count event. In fact a few knock count events coincide with supposed ECU errors that only appear for a single frame, which makes me think they're serial data glitches rather than actual events. In addition the EEHack log analyzer seems to suggest I'm dangerously lean at WOT, and yet Trimalyzer's analysis suggests reducing several VE cells by 50% which seems to suggest running the engine significantly leaner for those cells?

I understand that the experts here are pretty darn busy, and I'm not looking to be spoon-fed if no one has the time to run their own analysis of my logs and break it down for me. I'm perfectly content with being pointed in the right direction in terms of reading material and spending my own time reading up on how to interpret these logs and know what exactly I'm looking at in terms of operating parameters. That said, any help is appreciated as I'd love to become more familiar with this system and start making worthwhile changes. I do plan on going for an extended drive with EEHack connected later so that I can also have a log of "normal" driving parameters in addition to the dyno runs.

Thank you all!

[steveo]

hey glad you're enjoying my software

a preliminary glace shows something seriously wrong with your fueling or maybe you have a miss at WOT. the eehack log analyzer is not wrong here. the reason you don't see that in trimalyzer, is good ol' trimalyzer is (rightly) filtering out WOT events, you can't tune power enrichment fuel with a narrowband, but you CAN use it as an indicator if you're going lean.

in your case they are going totally nuts during power enrichment. could be a misfire (a misfire looks like a lean condition to an o2 as that cylinder just pumps air into the exhaust)

but something is fishy there, i'm not used to seeing closed loop switching-like events during power enrichment.

the only other thing i can think of is that someone or something has jacked around with the parameter controls in eehack or maybe even something in the bin so it's actually trimming during WOT which would explain the switching.

I do see the integrator going crazy which I don't seem to remember being normal.

any idea why that would be happening? ...did you force closed loop in the eehack parameter controls during the dyno run?

see attached graph of abnormal behavior

[steveo]

just fyi and so we're clear a 'normal' log would be both o2 sensors pegged @ high voltage during the green area

the reason your o2 voltage is dead low in between those events is the dyno is winding down so you're in DFCO (fuel is cut right off) (look at your MAP during that time and it's pulling heavy vacuum and inj. pw is zero)

[NomakeWan]

Hey steveo, thanks for taking the time to respond. As I've mentioned before, yeah, I really do enjoy your software!

During the dyno run, the only parameter I personally clicked was the button for 3rd gear. I left every single other "active test" parameter alone, so assuming EEHack isn't doing something odd in the background that shouldn't be it. The ROM on board is one I created based on a stock EE_16200891.bin, having brought over all the differences I deemed relevant to the old ROM. The changes, according to the difference tool in TunerPro, are to the following entries:

>VIN number
>Fan Enable Coolant Temp (Lowered to 183F/192F)
>Main Spark Advance
>Extended Spark Advance
>Max Knock Retard
>Max Knock Retard in PE
>PE AFR Correction

The altered tables look like this:
14459

I couldn't find any difference that would explain the car being in closed loop correction during PE, at least with TunerPro using the EEXTRA definition. I thought it was weird to see closed loop behavior outside of cruise as well, but like I said, I don't know anything about LT1s. Good to know I wasn't going crazy, but now I'm a little worried that my dyno session might've done something nasty. Definitely would want to get to the bottom of this.

[steveo]

well with that torque graph and intermittent lean id expect a miss under load to be causing this. an engine that is quite lean at wot is going to peg the o2 sensor low. all you know now is that theres too much oxygen in the exhaust, gotta find out why. maybe add some fuel and do some wot pulls to see if it gets better. dont need a dyno to do wot pulls.

[steveo]

you know looking at your screenshots, maybe your power enrichment table is just too lean. did you develop that table with a wideband? there's knock at WOT too. compared to stock bin you're like 7-8% leaner. the corvette calibrations aren't that rich to begin with. combined with the fact that your engine, injectors, ignition, fuel pump are probably ancient, you might have pushed it over the edge.

[NomakeWan]

The table actually came with the car, so I had left it alone. When I get home from work today I'll go ahead and flash a stock ROM back to the car minus the coolant temp and BLM Locker parameters and go for a nice long drive while logging. Will post the results then. Thank you again!

[NomakeWan]

Okay, just got back from a test run driving around some backroads and mashing the gas a bit. Starts in my garage, drives around, then as I get near to my house again I pulled off, used EEHack to lock the car in 3rd, then did some WOT pulls with it locked just like it was on the dyno for kicks. Then I put it back on auto, parked, and disconnected from the car.

Before this test run I did flash a new BIN to the car, this time EE_16200891 except with Siderail Serial, 0E14, VIN, Calibration Part Numbers and Fan Enable Temp copied from the original BIN, and BLM Locker enabled. Everything else was stock. Flashed fine with WinFlash, and passive entry worked fine afterwards this time around.

I had a look at the graph and it still looks very similar to the dyno run log. Not sure what I should attack from there. Spark plugs were last replaced in 2015, wires were last replaced...at some point, so I could get a set of wires and plugs and do that job I suppose. Not sure if that would explain what's going on, but at least now I've ruled out the tune as the culprit. EEHack wasn't on the "Control" page until the very end, so I don't think that would have anything to do with it either.

[daveosx]

Power seems pretty low

Check the wire that runs along the back side of the water pump to the opti spark.
The 1994 production had issues with the long connector that plugs into the optispark.

When these came out they pulled pretty much the same curve every time.
70HP loss may be time for overhaul.

The Knock Module in these cars should be upgraded to 16214681 and new knock sensors.

Get a set of cheap 1.6 roller rockers
ditch the cats or replace with High flow.
Get some 26LBS injectors
should bring you up over 300WHP

1995 was the sweat spot for these engines 1996 went Communist OBDII.
Most all the issues where worked out in the 1995 Model year for the LT-1 the power loss and reduction in drivability in 1996 prompted the CAC to build a late production LT-4 version to get back some of the losses.
The 94 optispark I think has the old style Timing cover however the Corvette usually had the next version from the rest of the cars.
If you are using Cats to tune you can take the 91C cop car tune an port over it will improve response an bring the torque up earlier.

10134358 valve springs
COMP Cams Magnum Steel Roller Tip Rocker Arms 1418-16

I also Have a set of 280cc Wildly ported Cast Iron heads for these engines leave me a message if interested.

[NomakeWan]

Power seems pretty low
News to me. I thought this was about what the LT1 was good for, based on some Googling I did. I have an automatic, and people say the 4L60E is good for about 18%~20% drivetrain loss, so I figured the engine was still healthy. But you guys would know better than I would.


Check the wire that runs along the back side of the water pump to the opti spark.
The 1994 production had issues with the long connector that plugs into the optispark.
Will do. The Opti has been replaced twice in the car's lifetime already, with the latest replacement being 2004.


The Knock Module in these cars should be upgraded to 16214681 and new knock sensors.
Noted, will put that on the short list since that shouldn't be too expensive.


Get a set of cheap 1.6 roller rockers...10134358 valve springs...COMP Cams Magnum Steel Roller Tip Rocker Arms 1418-16

I also Have a set of 280cc Wildly ported Cast Iron heads for these engines leave me a message if interested.
No head work is going to be done until my dad and I make a decision. We're not going to do small things with the heads; if we're doing heads, we're gonna really tear into them and do the whole shebang, plus a cam. So that's not going to happen short-term. In addition we're sticking with aluminum heads and shooting for a stock idle that doesn't ruin emissions, so I'm afraid we won't be needing those.


ditch the cats or replace with High flow.
Already a full Magnaflow exhaust including Magnaflow catalytic converters.


Get some 26LBS injectors
I'll do that if I notice duty cycles getting over 80% or so. Until then it doesn't make much sense to upgrade injectors.


1995 was the sweat spot for these engines 1996 went Communist OBDII.
Most all the issues where worked out in the 1995 Model year for the LT-1 the power loss and reduction in drivability in 1996 prompted the CAC to build a late production LT-4 version to get back some of the losses.
The 94 optispark I think has the old style Timing cover however the Corvette usually had the next version from the rest of the cars.
If you are using Cats to tune you can take the 91C cop car tune an port over it will improve response an bring the torque up earlier.
I'm using TunerPro to tune, WinFlash to flash, and EEHack to do realtime stuff. Until I figure out what's going on with the tune that's on the car, which is stock as stock can be and should be running fine, I won't be adapting any other tunes. Thank you for the tip, though, I may look into it later.

[daveosx]

1994-95
Typical brand new would run closer to 290-300 RWHP
In house the LT1 is known to make 1hp per cube at flywheel open headers.
The 18-20% is about right.
In 1996 the commiepinko and his hag signed a tax in I think it was anything less than 11lbs for 1hp so THEY DETUNED.

I have built a couple 9 of these motors for various reasons one that I ran for 8 years 200K was 600 hp at 6800 rpm and tacked out to 9000.
The bottom end was 4340 crower and balanced two bolt with girdle.
TRW 1157 old fashioned pistons.
Zero Gap secondary rings (Now available from Total Seal by phone)
MH55V pump 80psi spring
GMPP Hot Cam from parts catalog #6
Timing chain tensioner https://www.ebay.com/itm/New-SBC-Small-Block-Chevy-350-Tru-Cam-Correct-Timing-Chain-Tensioner-Kit-/261872111036
1.6 rockers self aligning no guide plates Hard pushrods
The orange valve springs
Crower Rev kit https://www.crower.com/valve-train-components/hi-rev-kit-sbc-series-ii-18-deg-11x-12-offset.html
Extremely ported stock heads 2.02x1.6 (the web beweencylinder almost complete removed only .07 thick. The whole head wedged 5 degrees and intake side cut back to allow LT-4 manifold to fit.
Under cut valves with sodium filled exhaust
44lbs EV-1 5 hole injectors 42PSI
True Try -Y headers and crossover at 52 inch from valve
MSD optispark with Jacobs Electronics Module and Coil.
TCI megaRaptor 1800rpm stall.
This motor sounded like a bike engine when out of gear.

The chain stretches at HIGH Rpm most guys use heavy spring and get shitty throttle response.
Let it stretch just take up the slack. The lighter spring makes the throttle really crisp the crower rev kit takes care of the bulk of the Mass so no valve float.
When these springs where introduced in @1990 they where engineered for NASCAR they are a low moment of inertia Alloy of Chromium Silicon.
When you compress a spring and release the alloy has a period that it takes to react to the change.
Guys use heavier valve springs to lower the length of period.
The cheap price of the orange spring is intentionally misleading so that it can be used on claimer engines in racing as well.
GMPP stocks them as part of their racing support.

From 91 on We would put the rockers and springs on every vette when the owner complained of lack of power.
Stock cam stock tune wakes engine up.
rockers are available for @130 the springs for @80 <<<Do this you'll love the throttle response change
The injectors will also make a big jump I used Ford Eco boost 26lbs on one of my LT1 not the latest direct port but the yellow ones EV1 style they FOG instead of squirt.

I have two sets of Speedmaster 220cc heads in my office now.
1 set going on my truck with an LT-4 cam.
The other set I am modifying slightly to fit one of my LT1 blocks.
After close examination all that is necessary to convert these heads is to the reverse flow is to pipe plug or weld over the oil drain back hole and notch the deck at the front and rear steam hole.
I have used three sets of these heads they make power.

[steveo]

why are we talking about performance mods for an engine that is obviously broken or mis-tuned in some way?

just fix the thing

also i dont care what the dyno reads vs some other dyno.. huge variations are possible. the modulation on the torque output graph is the only thing i'm concerned with there

[Fast355]

why are we talking about performance mods for an engine that is obviously broken or mis-tuned in some way?

just fix the thing

also i dont care what the dyno reads vs some other dyno.. huge variations are possible. the modulation on the torque output graph is the only thing i'm concerned with there

My Express van was doing something similar. The valve springs had about 50 lbs on the seat and 110 @ .480. It was floating the valves so bad it lost 40 rwhp between 5,150 and 5,300.

[NomakeWan]

why are we talking about performance mods for an engine that is obviously broken or mis-tuned in some way?

just fix the thing
My thoughts exactly, but as I'm new to V8s in general and the LT1 in specific, I would like help in figuring out where to look. I did upload a new log, and the "closed-loop-like" O2 operation during PE was still present across the board. Since this is clearly not normal operation, but since the tune now on the car is 100% stock save for the fans kicking in sooner and the BLMs locked at WOT, what exactly would this indicate?

Thank you again.

[kur4o]

With the blm locker the blm and INt must read 128 in any PE event. If it reads something else the locker might not be applied properly.

[NomakeWan]

With the blm locker the blm and INt must read 128 in any PE event. If it reads something else the locker might not be applied properly.
According to the log, BLMs read +0% (which is 128, I believe) in all PE events, but INT continues to fluctuate. The patch was applied by loading the OEM BIN into TunerPro, using the EEXtra definition, going to the "Patches" section, opening "Lock BLM to 128 at WOT," selecting "Apply Patch," then "Apply." Afterwards, the window reads "Patch Applied," and indeed, BLM does seem to be locked to 128 as expected. I wasn't aware INTs were also locked--perhaps EEXtra has a bug in its definition for the BLM Locker? Can someone confirm?

[kur4o]

The MAF reads really low on the Wot pulls. It might be not accurate enough on high airflow, fouling the pcm that less air is entering the engine, which results to less fuel than needed.

Try unplugging the MAF and do some WOT pulls, the pcm will enter Speed density mode and will calculate fueling based on VE tables.


That blm locker is not good, or at least not acting as it should. The INT must be 128 also and not moving at all unless the vette calibration have some different settings.

[steveo]

i've never tested the blm locker on corvette bins but the code around BLM stuff seems the same.

try without the BLM locker (it's not THAT important, i'd rather have it not trimming to stoich at WOT.......)

[NomakeWan]

The MAF reads really low on the Wot pulls. It might be not accurate enough on high airflow, fouling the pcm that less air is entering the engine, which results to less fuel than needed.

Try unplugging the MAF and do some WOT pulls, the pcm will enter Speed density mode and will calculate fueling based on VE tables.

That blm locker is not good, or at least not acting as it should. The INT must be 128 also and not moving at all unless the vette calibration have some different settings.
Ohohoho, you nailed it! I went ahead and made a calibration that had the BLM Locker disabled and also disabled the MAF error code and flashed that to the car. Then I unplugged the MAF and went for a drive. It didn't seem to be happy, but I kind of figured it wouldn't be since it was relying on VE tables for a stock car, but my LT1 has an SLP Blackwing intake and Magnaflow exhaust, so those tables probably aren't accurate anymore. Did some WOT pulls, came back home, checked the logs and the PE modes looked normal this time! I couldn't believe it so I ran back, plugged the MAF back in, then went for another drive just to be sure it wasn't disabling the BLM Locker that did it. Nope--the MAF run had the same erratic O2 output as before.

So yeah, bad MAF feeding bad data. Gonna grab another one of those in addition to the spark plugs and wires. Thank you for the assistance, everyone! I hope to have more good news soon!

I've attached the two logs from today so everyone can inspect them for themselves.

[spfautsch]

When you remove your MAF sensor from the housing post up a pic of it pls.

I bought a cheapo aftermarket replacement a few years ago because I thought my original was dead. This was $80 I'd have gotten more satisfaction out of if I'd have burned it. It reported really low airflows at WOT and I was running incredibly lean because of it.

Another possibility is the aftermarket cold air kit. MAF transfer curves are built by calibrators using ridiculously expensive flow benches, and the entire intake tract of the vehicle being tuned. The transfer curve (maf calibration) could be completely meaningless and wrong for your intake tract.

Edit: the oscillations could be caused by buffeting of air in your intake tract. The ribs in the stock air boots may be doing more than just providing vibration resistance.

Edit: if this (https://www.hawksmotorsports.com/1992-1996-corvette-lt1-and-1990-1995-zr1-cold-air-intake-slp/) is what you have, i guess you're still using the stock air boots. But it could still be throwing the MAF off.

[NomakeWan]

Okay, had some time to drive around and do some SD-mode tuning, as well as got a new MAF and went ahead and swapped that in afterwards. Will do some more driving around, adjust some MAF-related stuff, then go in for another dyno run and see what happens now that it's actually running. I've attached the log from right after swapping in the MAF, as you can see the O2 sensors are now doing what they're supposed to.

I do notice that EEHack has some serious communications issues while logging long periods--over 200 errors logged in under an hour--and tends to indicate false knock events when these communication errors happen. I'm not sure how to make that communication any better, or even if it's possible to do so. Honestly I wouldn't mind that much except I have a feeling that the analysis tools in EEHack and Trimalyzer actually think that the parts of the log where data dropout occurs are actually relevant to the analysis, which of course they aren't because they're junk data.

I also attached photos of the old MAF, per request. The new MAF is a Walker unit, and it went in without a hitch. I look forward to seeing what the car will do now that the sensors aren't lying to it! :rockon:

144851448614487

[steveo]

large amounts of comm errors definitely aren't normal affair for datalogging but corvettes do have a lot on the aldl bus, maybe a device is waking up and interfering with communications.

if it rejects a data packet it wont record it in the datastream...

there are some instances where the checksum isn't checked, that'll be fixed in the next version, but nobody has even really noticed since usually the datastream is really reliable.

it also rejects packets that are the wrong size, and most of the time, a garbled packet will be the wrong size.

when you see your knock counts go up during communication error events, do they go down again (to where they were before the error) right after the errors stop, and is there any other erroneous information displayed?

[spfautsch]

--over 200 errors logged in under an hour--and tends to indicate false knock events when these communication errors happen.

That seems really high. I always notice a lot of errors when logging but I don't recall seeing anything of that magnitude. I'll pay attention the next time I get to do some extended logging.

steveo do you have the checksum thing fixed in your branch? I'd love to test and see if it does anything to reduce the knock events you describe in your question, and the trouble codes that I'll see appear for one frame and then disappear.


I also attached photos of the old MAF, per request.

Well that's definitely an old Delco unit. The question is, is it the right one. Can you look for any part #s on the sensor element? What kind of clamps were holding the air boots to the housing? I ask because the factory installed these with permanent crimp type clamps like are used on power steering rack boots. If it's been replaced at some point by a previous owner it's possible it's off an early vortec and may not be equivalent to OE.

If you remove the bolts holding the housing together you can closely inspect the wires and beads. If there's a visible buildup of crap on them it would explain low flow numbers. It could just need cleaning.


The new MAF is a Walker unit, and it went in without a hitch. I look forward to seeing what the car will do now that the sensors aren't lying to it!

I wouldn't make any assumptions that what you have is equivalent to OE. This MAF housing was used on several different applications, and there could be multiple variants of the sensor element that are physically of the same size.

[NomakeWan]

large amounts of comm errors definitely aren't normal affair for datalogging but corvettes do have a lot on the aldl bus, maybe a device is waking up and interfering with communications. if it rejects a data packet it wont record it in the datastream...

there are some instances where the checksum isn't checked, that'll be fixed in the next version, but nobody has even really noticed since usually the datastream is really reliable.

it also rejects packets that are the wrong size, and most of the time, a garbled packet will be the wrong size.

when you see your knock counts go up during communication error events, do they go down again (to where they were before the error) right after the errors stop, and is there any other erroneous information displayed?
They don't seem to go down. Erroneous information includes random MIL codes, sensor data that makes zero sense in context, etc. It's interesting that the program doesn't record the data when the packet gets rejected. I think I see this behavior in the logs, but it doesn't get indicated as "no data," it gets indicated as "data is exactly the same as previous data for (total time of data loss)." This is why I was wondering if the analysis tool within EEHack and Trimalyzer were looking at those "empty" parts where the data was unchanging for long periods and assuming that the unchanging O2 readings were relevant to the analysis. I've attached three logs from my really long drive prior to installing the new MAF to this post so you can see an example of what I mean by these crazy errors. The first log was with "silence extra modules" unchecked. When the error counter hit 200 I disconnected, checked the box, then reconnected to see if that would help. It didn't. The third log was a short one from after we had pulled into a parking lot and shut down to check a map before stopping for lunch. Thank you again for your tool, regardless of the niggles I still prefer using it to any of the other available options. It reminds me a lot of the program I use for Nissans, and that's a good thing. :thumbsup:


Well that's definitely an old Delco unit. The question is, is it the right one. Can you look for any part #s on the sensor element? What kind of clamps were holding the air boots to the housing? I ask because the factory installed these with permanent crimp type clamps like are used on power steering rack boots. If it's been replaced at some point by a previous owner it's possible it's off an early vortec and may not be equivalent to OE.

If you remove the bolts holding the housing together you can closely inspect the wires and beads. If there's a visible buildup of crap on them it would explain low flow numbers. It could just need cleaning.
It was attached with the proper-width Oetiker clamp on both sides with the OEM bellows--doesn't look like it had ever been touched. Sadly I didn't know about these clamps--never had them on any other car before--so I had to go with too-wide worm clamps when I put the new MAF in. I'll have to find the proper clamps and figure out how to crimp them later. Or preferably find a modern clamp in the proper width for the grooves on the bellows, that would be swell.

I've gone ahead and removed the MAF itself from the housing as requested. New photos below.

144881448914490

[spfautsch]

I've never even taken it into consideration, but I have to wonder if the CCM is being jarred out of "silenced" mode by the PKE or doors being opened and / or closed. I know when everything is off and I open a door the leds on my usb adapter board start flashing away.


Sadly I didn't know about these clamps--never had them on any other car before--so I had to go with too-wide worm clamps when I put the new MAF in.

So did you buy another aluminum "sandwich" body type or the plastic body that takes a newer cartridge type sensor?

I'll try to find pics of my original sensor tomorrow to compare P/Ns.

[NomakeWan]

I've never even taken it into consideration, but I have to wonder if the CCM is being jarred out of "silenced" mode by the PKE or doors being opened and / or closed. I know when everything is off and I open a door the leds on my usb adapter board start flashing away.
I wouldn't be surprised. The climate control system also seems to "recover" from silenced mode after a few minutes. But the PKE shouldn't be what's affecting these logs since the engine was on and we were driving, so PKE should have been disabled. Same goes for flashing where the ignition is in the run position, PKE shouldn't be doing anything. Still, the Corvette does have a ton of stuff talking on that ALDL, and ALDL is doing that weird RX/TX on a single wire thing. I'm constantly amazed at the sheer level of remarkable engineering GM's engineers put into this car, followed by...ALDL. Why?


So did you buy another aluminum "sandwich" body type or the plastic body that takes a newer cartridge type sensor?
I bought a sandwich. I know ACDelco changed to the cartridge and says it works just fine, but I wanted something that looked original and the new one has that ugly pigtail dangling around. I'm sure it works just fine, heck it might even be more reliable, but it's just plain ugly. I'd rather try to revive the old one. Heck I have to stop by the auto parts store tomorrow anyway, so I'll just pick up some MAF cleaner and go to town.

[steveo]

8192 baud ALDL was pretty good for its time compared to some other stuff out there

it's all about the tools and transitions. automakers dont want every auto shop to have to buy a new tool every year, they have to roll out new tech at intervals. the tech in your car came out in the really early 90s when computers were still slow, laptops weren't really shop-worthy, and people used very expensive diagnostic scanners.

early generations of the protocol did both 160 and 8192 baud so they were compatible with existing tools. by the time that backwards compatibility went away, shops had already invested in the 8192 baud stuff but also saw OBD-II stuff on the horizon, so to put another protocol in the mix just for a few years would have been a dick move

of course they could have done a separate bus for the body modules, and it seems odd they didn't, but having everything speak the same language and allow it to use the same tech diagnostic tool plugged into the same port is nice too

try to remember that robust high speed datalogging isn't a function that consumers use. it's just for shops to grab a bit of data to identify a problem or to reset something. tuners have always been an edge case and thats why we're constantly working around odd gm design choices.

[NomakeWan]

Fair, but I'm coming from Japanese vehicles which have had dedicated RX/TX serial communications as far back as 1989, like Subaru's Subaru Select Monitor interface and Nissan's CONSULT interface. It's not that these interfaces don't have their own issues--they do--but both handle 5+ computers on the exact same bus with orders of magnitude more grace than ALDL does, because in those instances there is a dedicated line for scan tool TX, and modules don't start communicating until they receive the proper initialization command. No need to shout "EVERYBODY SHUT UP!" first like on ALDL.

I understand keeping the 160 Baud single-wire stuff for backwards-compatibility, I'm just sad the 8192 Baud protocol wasn't a little more robust like its Japanese counterparts.

[spfautsch]

I've been unable to find a picture of my original MAF - it was likley lost when the neighbor kid found my phone and factory reset it for me. It's on the car so kind of a pain to get a pic of but I'd say yours is probably original. And it looks like you definitely have some crap built up on the beads. Non-chlorinated brake cleaner should be essentially the same thing as what's in a can of MAF cleaner.

I'd be interested to see what your replacement unit does. If memory serves, mine wouldn't read much higher than 9khz or about 220g/s. This made for really lean WOT operation. I suspect the sensor I got was intended for smaller displacement LT-1s and Vortec V6s even though Rock Auto listed it for the LT-1 Vette application.

http://www.pfautsch.com/wp-content/uploads/0812191327-150x150.jpg (http://www.pfautsch.com/wp-content/uploads/0812191327.jpg)

steveo I wonder if it's worth experimenting with re-sending the CCM silence command periodically (assuming this is what's happening). Unfortunately I suspect this would slow down logging somewhat?

[spfautsch]

I wanted to respond before I forgot about it - did a bit of logging a couple days ago and I don't think the electronic climate control thing you mentioned is a sign the CCM has started broadcasting. I was able to log error free for several minutes after the 'OFF' led on the climate control stopped flashing.

It seems like the majority of my connection errors coincided with the car hitting bumps / rough pavement. I didn't pay much attention to opening / closing the doors, but I know there is something wrong somewhere with my CCM - I suspect some loose grounds. It's always been a little screwy - I've seen the PKE light come on for no apparent reason while cruising along leisurely at 70mph. It has been relatively silent for a year or two, but ironically when I got in the car to roll the windows up the other day the power lock motor on the passenger side started making noise like the system was trying to unlock it but was already unlocked. I toggled the door lock control switch and nothing happened. Confused, I put the key in and turned it to run. This stopped the power lock motor but then PKE light illuminated and the rear hatch popped open. I've been waiting until I strip the interior to replace the carpets and seat covers to check for loose / bare wires, but I might dig into that now that it's showing signs of demonic possession again.

Just something to consider.

[steveo]

thing is.... the knock counts are refreshed many times per second second. if it was in fact a datastream error the knock counts should go right back down. if it was interference on the bus you'd see tons of other data gone bad.

if the ccm or some other module is in fact injecting garbage despite the fact that you're bus master and they're supposed to stay quiet, the checksum will certainly be incorrect and that event --should-- be rejected but again the knock counts wouldn't stay up like that

i can (in the next few days) slip you a new beta version of eehack that in theory should reject all those events. although i intended to design eehack to reject anything but a perfect datastream, i seem to remember i found a few bugs concerning rejecting packets with bad lengths or bad checksums.

[spfautsch]

steveo - my post was merely aimed at explaining one cause of the extensive error count he's been seeing. Obviously if the knock counter isn't jumping back to what it was in the frame prior to the error that's a sure sign it's not garbage data.

I just had a thought though, would it be difficult to add the error count from the main window to the log data?

[NomakeWan]

Since this thread is active I'll reiterate it here, but I just got a 6-speed '95 and EEHack works flawlessly with it. Zero errors during operation, read operation worked perfectly first try, the whole shebang. Completely different from my automatic '94. There is clearly something different that is causing the operation to be different but I don't know enough to say what that would be. I'll check the FSM to see where my grounds are and make absolutely sure they're all good, but beyond that I'm not sure what to check. Figure I'll toss that in.

Will be interesting to try that beta version, looking forward to the experiment.

[steveo]

steveo - my post was merely aimed at explaining one cause of the extensive error count he's been seeing. Obviously if the knock counter isn't jumping back to what it was in the frame prior to the error that's a sure sign it's not garbage data.

I just had a thought though, would it be difficult to add the error count from the main window to the log data?

yeah would need a new log format, the log was never designed to hold anything but real datastream packets in their entirety. plus that'd be a really weird thing to add to the recorded datastream as the erroneous events aren't recorded so knowing an error happened there would be mostly useless information


Since this thread is active I'll reiterate it here, but I just got a 6-speed '95 and EEHack works flawlessly with it. Zero errors during operation, read operation worked perfectly first try, the whole shebang. Completely different from my automatic '94. There is clearly something different that is causing the operation to be different but I don't know enough to say what that would be. I'll check the FSM to see where my grounds are and make absolutely sure they're all good, but beyond that I'm not sure what to check. Figure I'll toss that in.

Will be interesting to try that beta version, looking forward to the experiment.

well at least we cant' blame the cable if it works on another vehicle...

i really never tested this on a 'vette, other people did that. the 'silence extra modules' setting is supposed to send the 'be quiet' command to every module we know about. it shouldn't be necessary since without the heartbeat from the bus master the auxiliary modules shouldn't really do anything. i just figured silence every device we know about to be safe..maybe we missed one?

if we did, we could find it by keeping the bus quiet (just send a shut up packet every few seconds) and run a serial logger until it decides to speak..

a bad ground is a possibility, ya'd figure those crop up all the time on a vehicle that's mostly non-conductive ??

[NomakeWan]

Attached is a log from my '95. In about 40 minutes' worth of driving, the car only had three disconnect/reconnect events, each one pushing the error counter by 8. Absolutely phenomenal.

The disconnect/reconnect events didn't seem to be associated with anything in particular, so not sure what happened there, but yeah. Figure I'll toss that up.

Gonna make some changes to the ROM tomorrow and see how that goes.