Rev limitter when lambda sensor is dead

[analgins]

Hello. I have noticed an bug in latest firmware, when lambda sensor is dead and reading 1.34 lambda, AFR corrections are disabled and lambda sensor is used as a gauge only in TS it still affects the tune and I had 5000k rpm limiter for no reason. Launch control was not as aggresive as it was when lambda sensor was working fine. And engine did not produce boost more than 140-150 kpa. And onlly when I disabled wbo2 controller in TS car started to work properly again. There were no engine protection enabled when I was reving the car and held tps 100% for a few seconds, stationary or driving I am using pazi m40 board with diy-efi tiny wbo2 controller and max9926 conditioneer. Engine is wired fully sequential, ignition and injectors. 60-2 trigger, trigger filter set to weak

[noisymime]

Do you have a log showing this at all? Post a log and tune to https://tunes.speeduino.com and we can take a look.

Mostly likely there is something in your tune somewhere that is set to use the O2 reading, even if it's not the closed loop control itself.

[analgins]

Here is the tune and log file when it happened. https://tunes.speeduino.com/#/t/QtiQwThQ1r/tune

After a discussion in discord, I understand that there are a lot of settings wrong in it, that might caused thiss scenario, simly because its pig rich. About the settings some one suggested to change injector battery compensation from whole pwm to open time only (here is a lack of explanation why but as i understud then the whole pwm is legacy option left there ?)

Someone suggested that required fuel in my tune might be wrong and two times too mutch.

In VE table I had enabled Multiply by ratio of AFR to Target AFR because by the description it made a lot of sense back in summer.. As it turns out, this feature works poorly? By the description I thoght it was EGO correction basicly, now I now I was wrong.. switched it off

IACV values, Warmup enrichment and Afterstart enrichment curves were wrong for cold weather I`ll upload changes and give some feedback if its bether or not.

[noisymime]

In VE table I had enabled Multiply by ratio of AFR to Target AFR because by the description it made a lot of sense back in summer.

This will be it. The feature is a very basic closed loop control, almost like just using the P element of a PID loop. Not pointless, but needs to be understood how it's working an what its limitations are.

When you turned the AFR readings off entirely, this feature gets disabled (or at least defaulted) and so your faulty lambda sensor wasn't impacting the fuel calculation any longer.

I don't think there's any issue here to be looked at

[analgins]

When I changed tuning -> afr/o2 algorithm from simple to no correction, I had no changes in engines behaviour, only when I disabled sensor i noticed changes.

Now I am thinking that the tune itself is way off, and its not a bug in firmware as i thought at the beginning. Would be really nice if documentation would explain features a bit better so no one should dig up the code to find out how something functions.

Thanks for input.

[noisymime]

When I changed tuning -> afr/o2 algorithm from simple to no correction, I had no changes in engines behaviour, only when I disabled sensor i noticed changes.

This is the expected behaviour.

Would be really nice if documentation would explain features a bit better so no one should dig up the code to find out how something functions.

This is covered on the VE Table page of the manual: https://wiki.speeduino.com/en/configuration/VE_table This states:

Multiply by ratio of AFR to Target AFR: This option is normally set to No for most setups. It allows basic close loop feedback by adjust the base fuel amount according to how far away from the target AFR the engine is currently running.

I've just added an additional clarifying line:

If the AFR/O2 Sensor type is set to Disabled then this setting will have no impact on the fuel calculation.