New wiki and manual has launched! Check it out at http://wiki.speeduino.com
Any strange behaviour, crashing issues etc, post them here! Problems compiling the firmware should go in the General support section rather than here
By Black Knight
#40802
Hello everyone.



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.


Thanks

Black Knight
Last edited by Black Knight on Mon Feb 10, 2020 11:27 pm, edited 1 time in total.
User avatar
By PSIG
#40804
Good work. I don't have an answer for your lock-up, but it would be great to have a simpler system for setting delays. As you said, there are several ways to find delay, and the clearest for me is to log and induce a misfire at the load and rpm I want to check. Using rev limiter set to your check rpm is one way, using throttle to set the target load. Reviewing the log in MLV, you can see the misfire (cut) and the time between it and the start of the blip in Lambda. That's my delay for that target.

Two thought with this, one is that older/slower WBO2 sensors may not see a single or the first misfire. Most newer sensor types and good controllers can. Second, some controllers will optionally give output averaging, which will make it difficult to see good results if set for that. I hope you find the lockup solution!

David
#40809
PSIG wrote:
Fri Feb 07, 2020 9:18 pm
Good work. I don't have an answer for your lock-up, but it would be great to have a simpler system for setting delays. As you said, there are several ways to find delay, and the clearest for me is to log and induce a misfire at the load and rpm I want to check. Using rev limiter set to your check rpm is one way, using throttle to set the target load. Reviewing the log in MLV, you can see the misfire (cut) and the time between it and the start of the blip in Lambda. That's my delay for that target.

Two thought with this, one is that older/slower WBO2 sensors may not see a single or the first misfire. Most newer sensor types and good controllers can. Second, some controllers will optionally give output averaging, which will make it difficult to see good results if set for that. I hope you find the lockup solution!

David


Good to be back here. I missed the interaction. I have been working on getting base tune as dead on as I can so auto tune can do it's job better. It works. I have done many thing to make that happen and they all work.

I have used WB and NB for testing both are good.

My circuit and NB O2 are very fast responding. So fast I had to set the O2 filter to 220 to get it to slow down. If I set it below 120 it is so reactive it will not tune right. I use normal to hard and
3 %to 4 % with 2 cell count for the set up.

The two cells I did get to change on the delay table before it locked up, are down from 200 to 150 to hit the target cell on VE.

I was fun to do a auto tune with filter at 0 and set all else to very easy and 30% and 30 cell change.
I was laughing so hard. It was like picking up a paint roller and seeing the ve table and the histogram go from white to deep blue and deep red in two passes. Not a good way to tune but fun.

I actually use this fast tune set up to wipe the VE table to get a rough tune very quick. Then I stage it down in steps to as little as 1% and hard to fine tune later with 220 filter.

So, in short I trust my NB set up. I can stall the afr gauge to any afr by hand tuning and setting the filter to 220. I can set it to swing sooo hard it becomes impossible to read. I am also using a volt meter on the O2 sensor signal wire to verify volts to afr and the O2 log on TS to compare afr to volts. All good. TS auto tune and MLV ve analize agree for the most part with the tuning and it is tuning very near AFR target on road tuning.

I know. I am messing with things that are not normal. That is Me. But It is working.
My NB controller is working and can trim both ends of the volts/afr so it will not go out of range or you can make it go from 7 afr to 24 afr if you are silly enough to think you may tune to that wide of an afr. 11 afr to 18 afr is all I need. I set one tune limit to 12.5 afr and 16.5 afr for my NA economy set up. My subaru 2.2 is getting 36 mpg and has more power when needed. All with my NB set up.

Oh, stop showing off.



So the question I have is on lambda delay.

Is there a look up from the firmware for the delay?

Or as far as I can see the only use for the delay table is for TS auto tune as there is no table or info for delay in the firmware. All it dose is change where the tune is ending up on the VE table for the delay from combustion to the time you see it on the VE table correction.

The other question is.

Will I lose one of my TS loads if I reload the TS software to try to correct what looks like a TS software glitch.

I know my delay set up works and no more logging to MLV. Just look at the info on TS auto tune page.

I just want to get it done so I can help my self first and others later after I find a way to write it down.

It is so frustrating to have this working so well and then a glitch put a stop to it. AAARRGGG

Good to be back.

I have much more to share that helps installation and tuning.


I can find real:

Inj dead time
I have a fixed voltage to all inj and ign out set to 14.23v
No table voltage correction now
I can fine base tune with inj CCs
I can get O2 calibration dead on
I can find lambda delay dead on if this bug was gone.

These are the holy grail of tuning. The more you get them right the better the tune.

Almost time to share.


Black Knight
#40877
All is working perfect now.

I just needed to find a new set of procedures to get it to do what I wanted.
I missed a step because this is new and has no instructions. Now it dose.

I also found out my O2 NB sensor with my controller is so fast that I needed to lower the values on the delay table more than I expected. A value 0f 250ms in one cell ended up being 125ms for me.


Lambda delay is easy to see and change with my new set up.
I just need to find a way of sharing it with words. I may need a vid to show it.

My NB O2 sensor controller and NB O2 sensor set up is also working very well now.
I set the motor to 3000 rpm, set the afr tble to 15 to 1 for the cells I was using and looked to see what auto tune did with it.
It ended up drifting from about 14.5 to 1 to 15.5 to 1 using just auto tune.
Good enough for me.
Next is road testing and tuning to see how well it works on the road.

This should be done now.

I can set O2 calibration and lambda delay from the same data almost at the same time.

Two big important thing with tuning.

Done

Black Knight
#41043
Road testing and calibration is done now.

I have calibrated the O2 sensor up and down .1 of an afr and can see the shift in tuning from slightly lean to slightly rich. Yes, with one tenth afr change on the calibration table. This has made it much easier to hit AFR target.

The lambda delay set up works great and it is sooooo important to the tune. We can set it with in 20 ms and see the change in tune. Now when we tune I can also look at the VE table 3d and see where I am off with lambda delay. I found that if the table is tuning with little or no odd rich or lean peaks or valleys (this is possible with good O2 calibration) that a low area is an indication of too many ms delay and a high section on the VE is an indication of too small of ms for delay.

So, with the more dead on delay and O2 calibration, auto tune works very well with normal driving.
On the high load area of VE it is now auto tuning to target of 12.5 to 1 and 13.5 to 1 for my NA economy tune. The auto tune hit target AFR close enough. I am happy.


We are now setting up an EGT to verify the afr in combination with the O2. I can also see some of the ign timing faults with EGT. Next bit of fun today. EGT.

Both EGT and O2 will be logging on TS and MLV so I can tune and review from the logged data.

Thanks again for all the help getting here.

Black Knight
#41109
EGT is working on the bench test set up better that I was expecting. I like it.

I have tuned with EGT for many years in combo with O2. Both help each other to do a better job.
If you know how to use EGT you know this is true.

EGT is now recording data to TS and MLV. It is calibrated so temps are dead on from
900 deg f to 1500 degf . I can set it for higher and lower but why. I may use 1600 degf if I find I need it.

It will be fun to see what a change in AFR will do for EGT temp on a log. I will see a temp changes most likely as an AFR change happens. I have seen this on volt meters but logging is so much better.

I think EGT will also help me understand if my O2 is staying hot enough to tune correct.
Then I can insulate the exhaust and the O2 to help get more even O2 temps. This will help the O2 do it's job better. For wide band and narrow band it should help reduce the over use of the heater
circuit so they will fail less often. Get the exhaust to do most of the heating and use the O2 heater for back up. I have done this before and it works.

I have bench tested O2 heaters before and as the O2 is heated by the electric circuit or by the exhaust the amps and volt to the heater drop off quickly. Less stress to the heater.

I will be finding the best location for the O2 by using the EGT to find a exhaust temp that is just below the temp best for that O2 so as not to over heat the O2 and kill it. There is another use for EGT.

I will be starting another thread on the EGT soon as it is now working and I can see it will be of good use for tuning with an ECU.

Thanks again to all here. With out speeduino I would not be having this much fun.

It is fun until it is frustrating.

Black Knight

which is why it is only a temporary solution unti[…]

Where to buy all the components? lcsc half of ever[…]

Thanks for the input looks like NO2C is the way fo[…]

Very low VE values on idle

Is the fuel pressure ok? Could it be leaky Injecto[…]

Still can't find what you're looking for?