'94 Corvette Dyno Run Analysis

Quote:

---

Originally Posted by 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.

---

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?

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.

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.......)

Quote:

---

Originally Posted by 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.

---

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.

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 is what you have, i guess you're still using the stock air boots. But it could still be throwing the MAF off.

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:

Attachment 14485Attachment 14486Attachment 14487

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?

Quote:

---

Originally Posted by NomakeWan

--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.

Quote:

---

Originally Posted by NomakeWan

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.

Quote:

---

Originally Posted by NomakeWan

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.

Quote:

---

Originally Posted by 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?

---

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:

Quote:

---

Originally Posted by spfautsch

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.

Attachment 14488Attachment 14489Attachment 14490

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.

Quote:

---

Originally Posted by NomakeWan

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.

Quote:

---

Originally Posted by 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.

---

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?

Quote:

---

Originally Posted by spfautsch

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.

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.

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.

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/u...27-150x150.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?

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.