Megasquirt Support Forum (MSEXTRA)

It's been talked about as a test mode in the firmware, but it really belongs in Tunerstudio, as VEAL works AWESOME when the delay table is ~correct. A tool to do it automagically would cut tuning time dramatically in many cases.

Preferably user would just enable/disable for a short period as it would probably cause hiccups in normal running, and its not likely to change much unless the motor/exhaust/WBO2 changes drastically.

Plus, it would be a good baseline for the MS3 LTT lambda delay table.
(You could even stuff the results there, at least on MS3s)

Getting the data is probably a bit daunting for new users, even though its not really that hard to do.
(Its also not really documented that you might even need to do it, or how, anywhere)

The default values makes VEAL not work as awesome as it can on anything with long tube headers, at least...
When the delay table is sane, it works almost like magic.

That has been on the todo list for years, I would think it should finally make it into the next major release.

Lambda Delay Table generator could be VERY helpful.

Would it be possible to use the delay table to generate an "undelayed AFR" output in the datalogs, assuming the datalog is written to with a short time delay?

It'd be so much easier to look at a datalog where AFRs and AFRtargets superimposed properly. In fact, if you could have the option to simply plot the undelayed AFR as a default in MLV, then you could alter the table and check the fit visually.

kind regards
Marek

AFAIK that is currently the case for logging, and would almost certainly remain so.
The delay time is only really needed when making corrections, so you are correcting the proper cells with the corresponding data.

I wonder if we could with some sort of test mode. Picture having a TS Button that adds say 15% fuel instantly for say .75 sec. This would be abut 2 AFRs. We could have a Status code for this that sets for this .75 sec. Then just watch the AFR as reported by the O2s. You could do this at several air flows and get the Lambda delay with very little real effort. All we need is a button in the SW and look at the data.

Andy

I always just set the rev limiter (fuel cut) to a few different rpms and then hit them at a few different map values. Some engines are fairly stable some change a bit across that range.

Could someone ( Andy or Paul or whoever ) post a pic of what newbies should be looking at to help make our table up ?
Like some arrows pointing at the time and where it drops off etc. Maybe an original table and what a new table should look like after viewing the log.

Hi,

Has this been made a feature yet? i was just thinking about it.

the fuel cut idea is a good one, its something i've always thought i need to trial but havnt actually done it yet (shamefully)

It was being worked on for 3.1, but there were complications so could not be put in yet.

LT401Vette wrote:It was being worked on for 3.1, but there were complications so could not be put in yet.

Okay cool i can't imagine its a simple thing to write!!
Reckon it'll be in a future update or had to drop it?

Thanks
Andy

Am looking forward to this feature, as I seem to be having the issue myself where it is either pulling too much fuel or going to rich because the delays are off and I cannot figure out them, have been trying to set up fuel cuts, fuel dumps, all trying to figure out combustion to O2 sensor delays, and every change just seems to make things worse.

Does their happen to be a beta version to try what there is?

I have been trying to do everything I can to figure out these values (switch between normal map and a map of all 0's, or an extremely rich map, and cannot figure out any numbers that makes sense.

Have some points at ldle that seem to react in 2000 ms, other times in 70ms, switched back to the default delay that TS comes with, etc

Have a feeling that because it is always looking at the wrong delay data, is why the car is always bucking off the line with 15-16:1 afr, and then when manually add in more fuel for a lean condtion, then it wants to correct and add in a ton more fuel and then am sitting at 9:1 afr

Back when I was playing with the tune regularly, repeatedly saw that turning off all the advanced stuff than accel options that rely on the ve table while creating the ve table speeds things up and reduces headaches. I have also heard it doesn't matter, but it sure seems to.

if your engine has the sensor in short cast iron manifolds like a stock gm v8 or such, the default delays are probably reasonable, although the wbo2 controller has a big effect delay wise--- ms3 seemed at one point to also have a longer delay vs ms2e even using same engine sensor/wbo2 controller etc.

If you have long tube headers or your sensors are some distance from the exhaust valve back by the cat, its going to be much different.

best i can offer is start with a man on base...
hopefully a code block will preserve formatting... this is what seems to work very well on my engine.
you can just hit the corners and scale between them... and pick the rpm/load range that you use. I have a long tube tri-y header on an aircooled vw., sensor in the collector, about 900mm away from valve, running an ancient (but very fast reacting) JAW 1.03 wideband... ymmv a lot.

MS3 had a much higher resolution delay table, in the ecu, but I think its meant to be learned, havent looked at the code, not certain its even used.

The easiest way to do it currently is using a second ve table set leaner or richer and using an input to table switch...
. ..ideally when doing high speed sdcard logging. I was sampling at ~400hz at one point with a fast class 10 card.


The delay each way (fuel leaner or richer) may differ.

I generally use the rev limiter, set to fuel cut and set to various rpm breaks and try and hit at a few map values. Then you just need to look at the logs. The fuel cut gives a nice sharp edge for the delays.

am I looking for the moment there appears to be a change, or a certain value?

More or less afr will peg full lean as the fuel cut comes through. Difference between time when that happens and when pw is 0 is the delay.

This is why I am trying to get a better explanation as the description given of the method is very vague when it comes to looking at the datalog part.


I have a mountain road that I have been using to try to figure these values out, combined with a program called Voice Attack, that I have some inputs programmed into it. When I hit spacebar it starts, and when I hit spacebar a second time it stops. All it does is go between the two maps.

Have tried two methods
First is to switch to a map that has no fuel, then two second later, it goes back to standard map. This method sucks for trying to find high RPM because when it cuts, it cuts hard.
Second method is adding a bunch of fuel, two seconds later it removes the addition, this has side effect of you get two data points, one when adding, and one when returning, since the car is still able to run mostly normal while doing this

I have been using two seconds to just try to make the changes as separated on my datalog as I can.

If I am cruising at 14.7, and it cuts to 0 PW, (and here I ask the question again) am I looking for the moment there appears to be a change, or a certain value?

When it hits 16, 22, 14.8?

I dont get a sharp cut, it gradually goes to extreme lean.

On one cut at a specific MAP and RPM, it takes 500ms, on another it takes 3800ms, on another it takes 58ms. They jump around wildly

It is even more difficult the lower the RPM

cutting spark it will show a very sharp cutoff...
perhaps set the wbo2 lag at 100?(no lag)
My preference would still be a switch to cut injector or coil power momentarily, as you dont have to fiddle your tune to get data.

The main thing to look for is the step change in afr value.
If it looks gradual do something different.