Tuning AFR vs BLM

[dave w]

I think most everyone agrees using a WBO2 sensor for tuning is more accurate than using the BLM. I've posted a summary screen shot of a recent data log $OD, BLM VS. WBO2. The data supports WBO2 and BLM contradict each other at times.

dave w

[91ss]

I wouldn't be too sure about that statement. A narrowband sensor is very accurate when it comes to targeting a lambda of 1. Once I dial in the injectors and MAF curve with it, I then move to using the WB for fine tuning of open loop.

[dave w]

I wouldn't be too sure about that statement. A narrowband sensor is very accurate when it comes to targeting a lambda of 1. Once I dial in the injectors and MAF curve with it, I then move to using the WB for fine tuning of open loop.

I think I was meaning to ask a question "I think most everyone agrees using a WBO2 sensor for tuning is more accurate than BLM?" Dang it, I hate it when I make a punctuation error.

Anyway, I think once the VE Table is adjusted by the WBO2, the BLM's will be much closer (+/- 5 or 123 ~ 133) to the WBO2 readings? I think there will be less contradiction between BLM vs. WBO2 data, with one showing lean while the other shows rich when the VE table is adjusted by WBO2 data?

dave w

[RobertISaar]

i think a lot of the discrepency you see is due to reaction speed.

wideband sensors can react and display an AFR almost instantly.

BLM has to wait around for the INT to operate out of it's window long enough to start moving, and even then has a delay between steps...

so while a wideband can give you a consistent and accurate AFR within 2 data samples, it could take up to 30 or 40 to do it via narrowband/BLM, depending on a lot of factors.

[dave w]

i think a lot of the discrepency you see is due to reaction speed.

wideband sensors can react and display an AFR almost instantly.

BLM has to wait around for the INT to operate out of it's window long enough to start moving, and even then has a delay between steps...

so while a wideband can give you a consistent and accurate AFR within 2 data samples, it could take up to 30 or 40 to do it via narrowband/BLM, depending on a lot of factors.

I find the BLM update delay very interesting! I think the most important thing to know / understand is if the MAP / RPM are instantly displayed? I'm relying on the WBO2 data, MAP data, and RPM data to all be accurate at the same sample instance! I'm working with an 8192 baud PCM, so I'm thinking the data stream sample rate is fast enough to be accurate +/- 2 samples?

So with some of the data I posted, a BLM delay, of say 10 samples, could significantly effect the MAP / RPM / BLM cell with very few hits. A rule of thumb has been to reject MAP / RPM / BLM cells with less than 5 hits. Maybe a better rule of thumb is to reject the first 5 hits in a MAP / RPM / BLM cell to allow the BLM to catch up?

dave w

[RobertISaar]

MAP and RPM update at 80 times per second for a lot of the stuff i deal with, i imagine the PCM you're playing with will be similar/identical, so it updates around 8-10 times faster than the datastream will even display it, so i wouldn't consider them slow at all.

for me tuning fuel, i'll either disable BLM entirely by setting min/max to 128 and doing it via INT(due to the MUCH higher reaction speed) or i'll hold the engine in one specific condition long enough for the BLM to noticably "settle" on one or two numbers.

doing it via # of hits in a cell....... i did it for a while, but ended up with a rocky looking VE table and BLMs that were never quite where i wanted them.

[EagleMark]

I find the BLM update delay very interesting!
dave w

It's not a delay, like in $42 BLM Update is 450. msec, so fast.

Problem is "BLM - Intergrator Delta To Move BLM" is 4, so until INT moves 4 there is no BLM movement. And when it moves by 4 the BLM only moves 1.

Now at idle there is a INT delay of 9 seconds.

[RobertISaar]

that delay at idle keeps the idle smooth..... i've adjusted the delay at lower airflow enough to get an oscillating idle due to fueling.... it's a pain to deal with.

450mSec is almost half a second..... not sure how $42 is setup, but with A1/similar, BLM update delay is based on how far away INT is from 128. a window of 4 isn't bad at all, since INT can jump that amount in almost a single ALDL packet. BLM delay is much slower.

[brianko]

I think this is a true statement with a qualification: Trying to use AFR for idle tuning on a cam of any signficance is rather pointless, precisely because the AFR changes are (practically) instantaneous. On a loping cam, the wideband readings at idle will be all over the map, while the BLMs will give you a better picture of long-term fueling. Again, I'm only talking about an aggressive cam at idle.