I am now dialing in the O2 sensor calibration and setting up lambda delay.
O2 calibration is dead on now. I built an electrical circuit that makes the NB O2 work as well as a WB O2. I am getting afr readings from 7 afr to 23 afr and is auto tuning very close to afr target with road tuning. I can get the TS O2 sensor gauge to drift across my afr target with in about 1 afr of target with the target number near the middle of the drift. 1/2 afr lean and 1/2 afr rich but near center is target afr.
This was done with the lambda delay that TS provides. It is not yet a correct delay for my motor or tune. My luck that TS delay data is close enough to work. So, the tune will get better with dead on when I get the delay working.
I now have a way of setting the lambda delay dead on for any cell of the VE table. I just drive the car on auto tune and view the data on the auto tune page then I change the delay table until the tune change hits the correct cell.
I have one issue with lambda delay at this point and I am working with TS now to resolve it.
My lambda delay table is locked up and not making the changes I ask it to. I change the delay value and it is not moving the tune to a different cell on the VE table. I did get it to work one time before it locked up. So I know it worked. Tunerstudio thought it might be a table look up issue of the firmware. If that is true what could I do about it?
I am not sure that is true. The Delay table is not in the firmware. The delay table only has an affect when the auto tune is started and tuning. It interacts to correct for lambda delay for tuning. I don’t know if lambda delay has anything to do with the firmware ????
I really do have a simple and accurate way of finding lambda delay. As soon as the bug is fixed I will finish my testing and document how to do it. No point in sharing this if we all end up being locked up on the lambda table.
Yes I have tried other ways to solve the locked up table. Two ideas left to try. Reload the firmware and reload the TS software.
I am waiting on TS to get back to me now.
As soon as I have this bug fixed I can share the info.
Any ideas on this bug will speed this up.
Yes I have used other ways of finding delay and they work but they have limitations to them. Ae can work but it is near impossible to target a specific cell. Rich trigger cells on VE do work but the rich extra fuel can and will show up on the following cells. Lean cells are better but it still shows the lean condition later on the table. There is no clean end to the rich or lean change. Using MLV to see the data helps too but MLV is only as good as the data you send it. MLV will work and I tested it the most. I liked the results but it is time consuming and it takes a few tries to zero in on the right cell on VE. Then you change your driving load and the data changes on MLV. All work but are limited.
So I spent time to find a better way and it works very well.
Help me fix this bug and we all can get lambda delay done easy.
Here are some things I did about the time it locked up.
I tested my idea on the supplied delay table and it worked on the two cells I changed.
I set load and rpm bins to work better with my tune/motor.
I exported the TS stock delay table to have a back up.
I created three delay tables and exported them so I could test different delay times.
I deleted some of the tables that did not help with delay.
Some where about this time all tables got locked up.
I imported the original delay table and it was locked up now too.
I can change the table values but it is not interacting with the VE table.
The two cells I changed are tuning in the correct cell, dead on. The others are close but not right.
The oval cursor is not moving on the delay table.
TS has expressed in interest in my set up for delay finding.
I think this will make so we will not need a wizard.
All help and advice will get this done sooner. Then we will have one more part of tuning easier and more accurate.