tune it in SD first, then back it up with MAF tuning. This will at least get you sane numbers...
tune it in SD first, then back it up with MAF tuning. This will at least get you sane numbers...
Yes, but use CALC.WO2BEN as the BEN pid... keep PE enabled, disable MAF (make sure DTC shows up), disable CL/LTFT/STFT.
Yes, I agree MAF is reading high, this is what caused CALC.VEN to calculate high, and is what causes CYLAIR (defined as {SAE.MAF.gps}*15/{SAE.RPM}) to calculate high; DYNAIR is based on current VE.
Wideband waveform has to be more "definite" than what I saw in your log... try setting the filtering to 1/3 using the LM-programmer.
Test your wideband using brake cleaner in a rag (did you see the YouTube vid)...
Also when in CL trimming, wideband should ripple tightly around stoich coinciding with the NBO2 switching.
Last edited by joecar; September 26th, 2015 at 08:26 AM.
Your wideband waveform is not very definite... it maybe is sluggish.
Dang. Okay, after many many hours of reading, re-reading Calc.Vet , summary notes, AutoVE...etc... I think I found the issue.
Can someone please correct me if this statement is wrong: Calc.Vet uses the MAF sensor value to determine how much air the engine is ingesting.
In my newb days(last year), I started off with AutoVE...which has you disable the MAF-sets freq fail to 1Hz, turns off mil lights..etc. MAf is still failed in my tune. But I also have B0120 (RPM Threshold for Airflow Calculation) set to 400 instead of the original 4000(no VE table contribution).
So, I the way it's set up is: Ignore MAF..Ignore VE...make up a magical number and drive around till engine explodes....
I dunno. So if I un-fail the MAF I think I should be back in the game right?
It doesn't work that way. When you set B0120 to 400, it means that it will ignore the VE table above 400rpm and only use the MAF sensor... but that only applies if the MAF sensor is deemed to be working properly. If you fail the MAF (PCM thinks that the MAF sensor is not working properly), then it will revert to speed density (VE table) regardless of what value you've set in B0120.
Yes, if MAF DTC is present then PCM uses VE only...
If there is no MAF DTC and no MAF, then PCM does calculate what MAF could have been (and is usually wrong) and uses it.
Nah, I'm pretty sure I just need to find the right table to display "magical air number". Seriously though thanks, that response was very well worded and further confirmed that my air values were coming from my current VE tables instead of MAF sensor.
I didn't realize that either. I guess that's why Auto.VE make ssuch a point of ensuring the MAF DTC's are flagged before doing the procedure.
I will try to get some seat time the next couple days to confirm, but to wrap this one up, the reason my CALC.VET procedure was displaying unreasonably high values is because it relies on the MAF sensor to calculate how much air was used and my MAF sensor was intentionally failed(a leftover from starting AUTO.VE that I never turned back off). The PCM then uses the current loaded VE table to determine air. In this particular case, my LS3 Maf sensor was displaying g/s numbers nearly double what they should be...which is a different issue that I will have to figure out.
Thanks for helping out everyone. I feel like this forced me to really understand the calcs behind the CALC.VET procedure that Joecar and Weatherman developed for us.