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
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
Last edited by dave w; 11-13-2012 at 12:37 AM.
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
Last edited by dave w; 11-13-2012 at 03:42 AM.
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
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.
1990 Chevy Suburban 5.7L Auto ECM 1227747 $42!
1998 Chevy Silverado 5.7L Vortec 0411 Swap to RoadRunner!
-= =-
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.
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.
Bookmarks