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.......)
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.Originally Posted by kur4o
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.
Last edited by spfautsch; 08-09-2019 at 09:40 PM.
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!
IMG_4564.jpgIMG_4565.jpgIMG_4567.jpg
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?
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.
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.
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.
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.
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.
IMG_4578.jpgIMG_4579.jpgIMG_4583.jpg
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.
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.
Posting Permissions
Reply With Quote
Bookmarks