K20 Haltech odd behavior seen in fuel trims

My k is running well on Elite 1500, but something off has appeared in my LTFTs under cruising conditions. In spite of the map being correct, I'm seeing LTFT activity near max correction at cruising revs (first attachment).

This shows up looking crazy in my LTFT map (second attachment). I suspect that this is the activity of transient correction, but I'm having trouble proving it and correcting it. I hear subtle burbles in the exhaust during these speed, like you'd hear during decel, but I'm not sure how to be positive that is it.

Is there a way I can confirm this in logs somehow (a boolean-like value I can see)? There's no way my map is off by 25% in this spot. It seems like the TPS Filter Scale or Transient Throttle Detect Duration would probably help, if it's just overacting because it sees TPS changes, but the changes aren't clearly visible in the logs and I can't confirm/deny that transient fueling is in-play. I can see numbers like 37% in the transient throttle enrich rate channel in my logs, but the description of the channel isn't clear so I'm not sure if this is merely displaying what the calibration would do or if it's an actual value.

--Matt

I can't upload a datalog here, so here's a cloud link if it helps any: https://drive.google.com/file/d/1ar-T_sS6ztnZTZ3wmMO5UHuAp4jOfHvo/view?usp=drive_link

Can you disable LTFT and verify that your fueling really is correct (and not just correct because the LTFT is actually making a difference). Take a log of a cruise and see what the O2 trend is. Perhaps you just don't have the Coolant Temp compensation correct, and you are fueled correctly when cold, but too rich when actually at operating conditions, and thus the LTFT is "fixing" this.

Are there any controls for the conditions that the LTFT will update (i.e. minimum/maximum coolant temp, steady throttle, no accel enrichment, certain MAP conditions.). Do you have any other systems that could be interacting (like Decel Fuel Cut Off).

With LTFT disabled, the same amount of correction still has to be made. STFT ends up doing it instead, though, and it ends up richer because more than the STFT max correction is needed to compensate.

The standard limits for LTFT are enabled and are being met. Tip out fuel cut and tip in enrichment are enabled, and I suspect that the latter is causing extra fuel to be injected, but I'm having a hard time confirming it.

This is a track car with solid mounts, so there's a lot of vibration and movement....

There seems to be considerable jitter on TPS-D. Small 1% changes as the car is moving result in huge TPS-D sways. I see it bouncing from 2%, to -39%, to 32% per second inside of milliseconds of time!

OK -- so it's false transient throttle fuel that is affecting the fuel trims. Seems strange, since O2 Control should be paused during transient throttle events. Perhaps the values in the O2 Control->Delay table are too small.

But it's probably best to work on minimizing the false transient throttle events.... What are your Fuel Tuning - Transient Throttle settings?

Assuming you are using Load Type = Throttle Position...

Have you tried increasing the Detect Duration (I would think 10-40 ms would be a good range). Also be sure the Load Rate Deadband is adequate (30-50%/sec). And the Load Acceleration Dead Band is large enough to taper off the extra fuel.

I would test / tune the transient throttle by Disabling the O2 Control, and observing the Lambda (and engine resposne) when you do a real transient event. Using the timings from that data to set Delay (at various RPMs) and Dead Band Values.

I mean...it certainly seems that way! I agree that it seems odd though. The delay for these revs is at the default of 1.2 seconds, which seems like an eternity!

Load type is throttle position, and and everything there is at the base map defaults (see attached).

The default detect duration is super low in the base map (1ms). The numbers you're suggesting are orders of magnitude bigger! I think I did watch a transient throttle video where this setting was mentioned, but the units are tough to quantify. Are numbers like 10-40ms low enough to avoid lean spots on tip-in?

Semi-related question, is there anyplace out on the interwebs where people commonly share their maps for posterity? Coming from the KPro world, where you can go onto any given forum and see tunes a plenty, I previously found that really helpful in cases like that. I don't really see much of anything like that for Haltech stuff. Even something from a big block would help as a reality check on something like this!

--Matt

Base maps are just a starting point -- Base Maps often only configure the necessary I/O to match the stock components on the system. The quality of the tune varies, but I wouldn't hesitate to change anything that didn't behave the way I wanted. Look at the help for each of those parameters -- it often gives a typical range.

10ms is a long time in electronic terms, but once you get into mechanical systems 10ms (1/100th of a second) is pretty fast. At 3000 RPM, on your 4-cylinder engine, 10 ms is the time between two spark plug firings. There is no need to be 10-times faster than that for good tip in performance.

That's fair. For whatever reason, they don't give typical values for that setting...just the range 🤷

1ms seems like it'd be even worse for the stock sensor, given how bad they tend to be in an environment like this. I've got mine switched for the Acuity model, which is a hall effect sensor, because of the stock one's durability issues.

Either way, like you said, 1ms sounds very low. Many base maps seem to come this way, but I see that some (like the NB MX-5 or 2JZ Supra) do at least have it at 2. The VW 1.8T files have it at 10, too. 🤷

10 seems worth a go.

--Matt

It seems like your suspicions were correct. Detect duration helped the burbles but I still had overfueling. Apparently my setup has a sizable VE dip in the 40-60kpa absolute range. Fixed that and it's much flatter now!

Here's a saying I use a lot -- "There are only three results from a change -- better, worse or the same". The whole goal of {race or development} testing is to make a change and determine which result you got. backup or undo the changes that aren't better unless you have another reason for the change.

Good job using your data to determine where the issue was, what it was related to -- and trying changes to see if they made it better, worse or the same.

The logic checks out! Thank you for the tip!

Just following up on this, since I discovered some more. Switching from the default "end of injection" timing method and injector firing agle to "start of injection" and 360 degrees across the board made the situation much better still. The prior changes improved it, but the injection timing fixed it completely.

This is really helpful stuff: https://www.hpacademy.com/previous-webinars/111-injector-timing-haltech-elite/