AutoVE Logging

[PACougar]

I'm doing some logging for AutoVE on my 03 Silverado and I wanted to know if it matters if the MAF is unplugged or not? I have the Tune setup exactly as the tutorials says(I hope) with the exception of unplugging the MAF. After applying the BEN data to the tune my AFR is still all over the place and I just wanted to know if this is the culprit As always thanks for any help.1106611065

[Taz]

Hello PACougar,

Regarding the MAF:
Flipping the MAF high / low fail frequencies should fail the MAF within the tune - having said that - I still manually isolate the MAF when using the AutoVE tuning method. As you know trucks like yours use a 5 pin integrated MAF / IAT sensor. The IAT sensor must remain functional. The easiest (and most cost effective) means to mechanically isolate the MAF is to remove the yellow wire (should be the end wire - closest to the front of the vehicle).

To do this unplug the MAF connector. The connector has a wine / purple coloured cover over the centre - carefully "pop" this cover off using a small screwdriver. Once off, you will see that the MAF pins are retained in a similar fashion to the PCM pins. Push the yellow wire forward to release tension on the locking tab, lift the plastic locking tab with a small screwdriver, then pull the wire out of the back of the sensor. Put the wine / purple cover back on, and plug the connector back into the MAF / IAT sensor.

Add GM.MAFFREQ to your PIDs to confirm no MAF input to the PCM.


Regarding BEN and AFR:
Stoichiometric AFR is a "relative" concept - dependent on the fuel used, while stoichiometric Lambda (1.00) or Equivalent Ratio (1.00) are consistent across fuels. I would highly recommend working in Lambda or EQ. I prefer to work in EQ as it "fits" with how I think about fueling, and is what GM originally used in the OEM tunes (if you look at the PE or Lean Cruise tables in your tune these are in EQ).

A Lambda or EQ CALC PID can be written for any WBO. I use an older analogue WBO and this system works well within the voltage range of the particular sensor. The CALC BEN PID in the AutoVE method can then be rewritten to use EQ (or Lambda). This approach will provide much more consistent results.

Also, if your tune uses B4206 (O2 with open loop commanded fuel table) or similar parameter - this needs to be set to "Disable" for AutoVE tuning - I don't think this is expressly stated in the AutoVE Tuning Tutorial.

Hopefully some of this information will be of use ....


Regards,
Taz

[joecar]

+1 what Taz said.

Also, you know the MAF is failed by the presence of one of the MAF DTC's (P0101, P0102, P0103)... if you don't get one of these, then the MAF is not failed (i.e. being read and used in airmass calculations).

B4206 is not mentioned in the AutoVE tutorials because in the 1998-2002 F-body/Y-body PCM (what the tutorial was written around) it was already disabled.
B4206 has to be disabled during AutoVE.

Log GM.EQIVRATIO this is the commanded fuel.
Log wideband lambda (if analog, then divide the wideband AFR by the wideband's assumed stoich AFR; if serial, use WO2LAM1).
The BEN would now be commanded_eqr*wideband_lambda, which for serial wideband is {GM.EQIVRATIO}*{EXT.WO2LAM1}.

Let us know if yo need help with the calc pids.

Do you have V1 or V2...?

Which wideband do you have...?

[PACougar]

Wow, this forum is one of the best I ever used, you guys are very helpful and I really appreciate it. I'm using V2 and the AEM x-wifi WBO2. I believe I have the calc pids setup correctly. I've verified the AFR it's reading in EFILive with the AFR reading from AEM's software. I'll attach it just in case. 11067

[Mr. P.]

Your custom PIDs look fine; however I might have some thought that might help explain the inconsistent AutoVE results you are getting -

You are following the AutoVE tutorial correctly in that you are calculating a fueling adjustment by comparing the observed AFR against the commanded AFR - this math approach only works *IF* you are using pure gasoline (E0) in the tank -and- the PCM's stoich is defined as 14.7:1 -and- the formula in your custom PID "({EXT.AD1} * 2.375) + 7.3125" also assumes a stoich AFR value of 14.7:1 in the exhaust stream it is measuring; years ago, this would have worked fine but now almost all fuel in the USA is 'gasahol' with ethanol content ranging from 6-20% and you cannot assume anymore that you are fueling with 'pure' E0 gasoline. The EPA under the Obama administration passed a law years back that makes it a federal requirement that all pump gas now be at least E10 by 2012, and some regions will be E15 as well. The stoich value of the fuel that you are using will vary greatly depending on the ethanol content, and that HAS to be considered in how you setup your tune, your wideband, and your PIDs *before* you start logging; this also means that the practice of trying to dial-in your VE table using AFRs must be replaced by using EQRs (my preferred) or Lambdas instead - it is the same math approach, but using EQR instead of AFR in your BENS formula. You need to AutoVE with EQRs, not AFRs.

Like you I also observed that when using the AutoVE method of tuning my BENs would be 'hunting' over the course of a few rounds of logging; i.e. on the first logging, the BEN correction would be really big in one direction, then on subsequent logging/adjustments the BEN would over-correct in the opposite direction, and over the whole time of logging & following the AutoVE process my BENs were always 'drifting', 'seeking', and 'overcorrecting' etc. I suspected at the time this was because of the interpolation the PCM uses between VE cells, and what I did to eliminate this was to abandon the AutoVE process entirely and create my own tools to process logging data and from that time since I have never had 'drifting' BENs. This does not mean the AutoVE process is flawed - what it means is that you must log exactly as close to the "center" of the VE table cell as possible and get 'very clean data' - I.E. drive exactly at 1600-RPM at a MAP of 65Kpa for 5-seconds to get a stable read of exhaust gasses at that engine condition, if you drive at 1700-RPM or 63Kpa then the logging you are doing is not going to apply exactly to that single cell in the VE table (it actually is applied to those 4 cells, in various weights).

I'm getting deep :( My point is - how you test drive, the data you log, and how you filter that data is critical to the AutoVE process, it is pretty unforgiving that way in that you need very 'clean' data from a very 'clean' test drive, in that you drive for a few seconds in the 'center' of each VE table cell. The 'dirtier' your test drive is, the more your BEN will be an 'estimate' rather than an authoritative value for any given VE table cell, and it will be close but not quite right and it will require multiple follow-up rounds of VE test driving until the BENs "settle-down" in their under/over corrections.

Other helpful hints - don't apply any BENs adjustments to cells under 35Kpa (to begin with), and I only use automated analysis of data in the 800-3000 RPM range, between 40 and 115Kpa; outside those areas, I will study my log file for areas with those extreme conditions and make manual adjustments. Another suggestion is, do not make big VE table changes, even if your BENs say you need to make a 10% correction, I would only do 2-3% at a time. Do smooth your VE table after each round of logfile/data analysis, do not flash a tune that has a 'ragged' VE table because when the PCM sees a big jump in expected incoming airflow it will do freaky things with timing (more KR, etc).

Mr. P. :)

[PACougar]

Thanks Mr. P, I'll try and apply that to my approach.

[joecar]

Yes, avoid AFR at all cost.

Does the AEM wideband support serial output...? Because if it does, then V2 supports serial input.

[Mr. P.]

Yes, avoid AFR at all cost.

Does the AEM wideband support serial output...? Because if it does, then V2 supports serial input.

According to the website, the serial connection is USB - so that won't plug into the V2. I would continue using the analog inputs to the V2, and also log the EGTs as well, you just need to add two more custom PIDs, one returning the EQR value as seen at the wideband (rather than AFR), and the BENs value as calculated from the wideband EQR; that way you will never have to worry about your BENs being inaccurate because of the change of fuel in the tank (you will still need to type the right stoich value into your EFILive calibration though).

Mr. P. :)

[PACougar]

Ok, I understand the principal of why I need to go off of EQR, but I'm not sure how to create the 2 custom pids for that?

[macca33]

Mate, I had the same queries and had some assistance in this thread, regarding the 'calc.pids.' Maybe something in it will benefit you.

http://forum.efilive.com/showthread.php?15977-Commanded-AFR-not-equal-to-WBo2-AFR-at-idle.

cheers

[Mr. P.]

I would call AEM and ask them what the mathematical formula for Lambda is on that wideband product (they will have this at hand, I'm sure); then use these formulas:

CALC.BENS = [PCM's commanded EQR (GM.EQIVRATIO)] * [observed wideband Lambda]
CALC.WB_EQR = 1 / [observed wideband Lambda]

Equivalency Ratio (EQR) is how rich or lean the PCM wants the motor to run, compared to stoich - if the EQR is 1.00, then the PCM desires the motor to run at the fuel's stochiometric ratio (it doesn't matter what fuel is used!); if the EQR is greater than 1, then the PCM wants the motor to run rich, if the EQR is 1.25 then the PCM desires the motor to be fueled 25% richer than stochiometric. The advantage is that you do not have to care anymore about exactly what fuel you are using and it's stochiometric ratio, the disadvantage (a small one) is that you need to learn exactly what EQRs are necessary at cruise, WOT, boost, etc.

On my dashboard/chart display, I find it very revealing to plot wideband EQR on top of commanded EQR.

Mr. P. :)

ps - I need to add a clarification, you DO need to know what the stochiometric AFR of the fuel in the gas tank, because you have to enter that value in the {B3601} table - but that's the only place you ever use or define an AFR of any sort.

[PACougar]

Mr. P I really appreciate the explanation, it helps put everything into a better perspective. This weekend I'm gonna go back at it, I'll let you know how it turns out.