MAF [lb/min] Pegged, But Period Keeps Decreasing, Air Load Rising?

[CCS86]

Any ideas what is going on here?

Air load keeps increasing, MAF period keeps decreasing, but MAF flow pegs at 86.69 lb/min.

MAF Limit.jpg

[mstang_man]

I dont see why you cant re-scale the MAF. Maybe graph both the TPS and the MAF sensor because they should essentially produce a plotted graph rising parallel to each other.

[CCS86]

I dont see why you cant re-scale the MAF. Maybe graph both the TPS and the MAF sensor because they should essentially produce a plotted graph rising parallel to each other.

I'm not pegging the MAF table though.

I have a ton of headroom right now and will be rescaling the table once I find out the max flow rate:

MAF Table.jpg

[decipha]

thats the maixmum airmass limit of the ecu

you have to scale the tune back

[CCS86]

thats the maixmum airmass limit of the ecu

you have to scale the tune back

Awesome, thank you!

That means I need a really big correction. Can this all be handled in the MAF table and injector slopes? 50% to all those values?

[decipha]

more than just that

everything airmass related needs to be scaled to be equal

using a scaling percentage with the high slope equating 30 lbs/hr and you wont have any limits at all

[Witt]

You don't have to scale it, lol. It's fine. That's the reporting limit of the PID.

[CCS86]

You don't have to scale it, lol. It's fine. That's the reporting limit of the PID.

I also thought that could be the case.

The only other PID I see pegged is fuel flow rate @ 7.999 lb/min. But, it's easy enough to see that is just a display issue, since injector PW and RPM both continue to rise.

I think the provided data for the MAF is just way off. I'll report back.

[murfie]

Its an SAE PID limit of 16 bit data going to the OBDii port.

https://en.wikipedia.org/wiki/OBD-II_PIDs has the math formulas and units to see the other ones. You don't want to scan SAE PIDs anyway, They are slow.

MAF PID report limit.PNG

[CCS86]

Its an SAE PID limit of 16 bit data going to the OBDii port.

https://en.wikipedia.org/wiki/OBD-II_PIDs has the math formulas and units to see the other ones. You don't want to scan SAE PIDs anyway, They are slow.

MAF PID report limit.PNG

It seems to affect the non SAE channel as well:

MAF channel.jpg

[murfie]

Can't you just scale the MAF transfer based on the period you are getting down to?

[kenand1988]

You can add a new math parameter to calculate the MAF based on air load. Murfie showed me this.Load to MAF.MathParameter.xml

[murfie]

I think CCS86 knows whats going on. 3.5 airload with 60inHg calculated MAP, hitting 86 lb/min at what I can only guess is before 4k RPMs, all with the STFT almost immediately tending to 20% lean the entire pull.
I would be more concerned about the lack of fuel supply immediatly after the pull starts, and the pull not being aborted, than the MAF lb/min. Some physical problems you just can't tune around and have to actually diagnose and fix.

[CCS86]

I think CCS86 knows whats going on. 3.5 airload with 60inHg calculated MAP, hitting 86 lb/min at what I can only guess is before 4k RPMs, all with the STFT almost immediately tending to 20% lean the entire pull.
I would be more concerned about the lack of fuel supply immediatly after the pull starts, and the pull not being aborted, than the MAF lb/min. Some physical problems you just can't tune around and have to actually diagnose and fix.

This is a remote tuning situation and we are trying to be cautious. It's a 20+ psi build, on E85 with FIC 2150 injectors (so we should have very good injector data).

This was the prior pull. Trims looked clean up to about 3800 rpm. Just a slight uptick at the end:

prior-run.jpg

I had him run to 4500 on that next one and the trims really went north quickly. It was short, just one pull and we are running very little advance. But I will be advising him to have a passenger to watch trims going forward.

Murfie, I have already started to rescale the MAF transfer function to provide more resolution in the range we are using. New minimum period is 108.

I am with you in suspecting something outside the calibration, like a drop in fuel pressure. Here's why I think that:

Here is a chart plotting logged MAF flow and injector PW. I also extended the MAF using a polynomial function (based off the transfer function), looking up via logged MAF period:

MAF-v-PW.jpg

Even if the transfer function was off, and the STFTs were responsible for keeping that injector PW duration in step with MAF flow, then why did logged EQR still go lean?

Also noteworthy: the MAF signal is pretty turbulent. This causes erratic injector PW and much worse STFT performance. I am working with him to improve this as well.

Going forward, besides giving the fuel system a thorough check, and having a passenger watch trims; I am giving him a revision that compensates the MAF curve for both the STFTs and the EQR drift. I'll have him do one pull to ~4200 just to see if the fueling deviates again.

[murfie]

Do you have a LTFT cell, that STFTs are not happy with, that it's hitting right there? I don't expect you to. Basically the fuel trims conflicting with each other and not controlling properly.

The lambda has to go lean, then the feedback loop error calculated, and adjusted for the next combustion event by the fuel trim, then repeat. This is relatively slow, but usually happens fast enough the WB does not deviate from commanded by much. With proper control data and correctly functioning hardware, actual rich/lean conditions don't last very long. 15% lean in the log, means some amount of combustion events were that lean, wether actual lambda reports that or not. If you have fuel trims correcting, and actual lambda still is not responding to it, you have really far off data (not likely), a major fuel delivery problem, exhaust leak, or a sensor giving a false reading.

Its an absurd amount of air flow for the RPM's, and to still be going crazy lean is the give away to me. Fuel has lots of time to flow in, at those RPM's, higher RPM's the window starts to close.

The other thing to conside would be the pressure differential between the manifold and the fuel rail, but I would expect this to be using a 1:1 regulator, and reaching 80+ psi in the rail minimum.

[veeefour]

Well this seems like a fuel system is not keeping up...to me.

[CCS86]

Do you have a LTFT cell, that STFTs are not happy with, that it's hitting right there? I don't expect you to. Basically the fuel trims conflicting with each other and not controlling properly.

The lambda has to go lean, then the feedback loop error calculated, and adjusted for the next combustion event by the fuel trim, then repeat. This is relatively slow, but usually happens fast enough the WB does not deviate from commanded by much. With proper control data and correctly functioning hardware, actual rich/lean conditions don't last very long. 15% lean in the log, means some amount of combustion events were that lean, wether actual lambda reports that or not. If you have fuel trims correcting, and actual lambda still is not responding to it, you have really far off data (not likely), a major fuel delivery problem, exhaust leak, or a sensor giving a false reading.

Its an absurd amount of air flow for the RPM's, and to still be going crazy lean is the give away to me. Fuel has lots of time to flow in, at those RPM's, higher RPM's the window starts to close.

The other thing to conside would be the pressure differential between the manifold and the fuel rail, but I would expect this to be using a 1:1 regulator, and reaching 80+ psi in the rail minimum.

I always keep LTFT off during this phase of tuning, so no confounding there.

Fuel is baselined at 45 psi and verified up to 70+ in boost. Dual DW400 pumps.

We are thinking along the same lines. My latest theory is that he is losing spark and dumping a lot of air into the exhaust. I told him to pull plugs for evaluation. They were NGK 6510s gapped at .028". So, they are getting swapped for RR10S gapped at .018". I think this will make a big difference. Hopefully I can roll back a lot of this MAF table increase. The table has become unrealistically steep in this range. Just look at the knee around 150us:

MAF-Table.jpg

[Plimmer]

I have a post somewhere in the forum about changing the air charge multiplier.

My issue was that as boost when above 12psi or so my lambda would drift lean even though I had plenty fuel and I could see the fuel trims where not trying to add fuel, so something else was factoring into it. Turns out it was the air charge multiplier.

So for the mapped points I use under power, I made all the multiplier flat line, instead of how they are stock where they increase with rpm if I remember correctly.

Now my lambda follows commanded perfectly all the way past 18psi. I haven’t boost higher than that because my ID1050x are running around 90% dc, but lambda still perfect

[CCS86]

I have a post somewhere in the forum about changing the air charge multiplier.

My issue was that as boost when above 12psi or so my lambda would drift lean even though I had plenty fuel and I could see the fuel trims where not trying to add fuel, so something else was factoring into it. Turns out it was the air charge multiplier.

So for the mapped points I use under power, I made all the multiplier flat line, instead of how they are stock where they increase with rpm if I remember correctly.

Now my lambda follows commanded perfectly all the way past 18psi. I haven’t boost higher than that because my ID1050x are running around 90% dc, but lambda still perfect

What did you set those values to?

The description reads like a "fudge factor": [ECM] 2597 - Aircharge Multiplier vs. RPM: This is a multiplier to the calculated aircharge, that is used to correct for ramming effects. If the aircharge is calculated correctly, I don't know why you would change this table.

[Plimmer]

What did you set those values to?

The description reads like a "fudge factor": [ECM] 2597 - Aircharge Multiplier vs. RPM: This is a multiplier to the calculated aircharge, that is used to correct for ramming effects. If the aircharge is calculated correctly, I don't know why you would change this table.

I had the same issue as you, above 4,500rpm and as boost increased the lambda started drifting lean, so what ever the multiplier is for the 3,000rpm range I made it the same for all higher rpm’s in the table.

Don’t have my laptop with me, so can’t open my tune to give the exact number. At worst just make them 1 (one) at all rpm’s