Lethargic AFRgauge response

Philip Lochner · Post by **Philip Lochner** » Fri Dec 28, 2007 5:51 am

With regard to Beta 16:

I have a dual WBO installed with AFR L being the left and AFR R being the RH WBO in my datalog.

Just as "Time" in the attached datalog goes from 64.xyz to 65, the AFR L (or AFR R) datalog changes from a very "active"/noisy (and what I regard as true) trace to a much more stable trace which is rather slow to respond to AFR changes and certainly not "real time".

At the same "Time" (64 - 65) the AFRtrgt1 (the value read off the AFR table 1) changes from 14.7 (which I don't know where this value comes from) to the value it should be (13). Why does it start reading from the AFR table only after 65 seconds?

The fact that this happens just as the "time" parameter clocks from 64 - 65 (digital overflow?) makes me wonder if there is some counter/timer /memory clash somewhere. Any ideas as to what could be causing this funny behaviour please?

Post by **muythaibxr** » Fri Dec 28, 2007 8:06 am

There is a 30 second timer where "closed-loop" is not running after start. I verified that the target AFR doesn't change to the looked-up value until after this 30 second window.

As far as the signal getting smoother... it looks like if you're using the simple algorithm, it only samples the sensor if "egocount" is >= "flash4.EgoCountCmp" so after that 30 second window, it goes from sampling every time the ego function is called to sampling every 16 ignition events (in your configuration), and starts looking up AFRs in the table.

The only bug I see here is that "Ignition events per step" is grayed out, and shouldn't be.

I believe msoultan already reported that one.

As far as I can tell, this is all as Al intended it.

Ken

Philip Lochner · Post by **Philip Lochner** » Fri Dec 28, 2007 9:24 am

Thanks Ken

Is there a way I can reduce "Ignition events per step" or another solution to make my AFRgauge more responsive. Being this slow makes it impossible to tune for AE.

Just out of interest, I went and checked my last B&G 2.687 msq and those settings seem exactly the same but AFRgauge was much more responsive. Perhaps that code was not working properly?

Post by **muythaibxr** » Fri Dec 28, 2007 9:31 am

Al may have changed the way the code works in a later rev. We've not changed it since the 2.6xx code we started with.

You can set it to a different type of wideband, such as PID closed loop, and just set the RPM to like 10000 to keep it from going into closed-loop. That should make it more responsive I believe.

Otherwise I'll take a look around and see what I can do.

Ken