You know what, go and start another NEW THREAD, you have a record here: 412 posts and like 412 new threads. Don't forget to demand everything, all the answers. I'm done talking to you.Originally Posted by CCS86
You know what, go and start another NEW THREAD, you have a record here: 412 posts and like 412 new threads. Don't forget to demand everything, all the answers. I'm done talking to you.
v-performance.pl/
facebook.com/veee.performance/
https://www.instagram.com/v.performance.pl/
Remote tuning:
[email protected]
+48 697276579
Hahaha, who's acting like a little girl now? Take your ball and go home. I've seen nothing helpful from your posts.
This thread is a pretty funny example to throw your tantrum. This thread was started by another member. I found it using the forum search, read the entire thread, then proceeded to ask questions and post information I found, furthering the discussion. You come to the thread, read nothing and make a post anyway:
No one is forcing you to participate. If you can't even be bothered to read, then why would you post?
Last edited by CCS86; 09-11-2018 at 11:56 AM.
Personally, I would touch the MAF curve last, if at all. On my combo, the MU52 injector data on a Coyote is far less reliable than the MAF curve from a stock GT500 MAF housing/filter. I left that curve alone and focused my fuel tuning elsewhere. MAF rate is so fundamental to different ECU calculations, that you really don't want to bury unrelated corrections there.
If you feel like you have justifiable reasons to edit it, I would stick to using STFTs. With time delay well tuned STFTs respond quickly and accurately, and they account for the lag in O2 sensor signal. I also keep my LTFTs off, because more often than not, they are adding lag to the STFT reponse (adding fuel while STFT removes it and vice versa).
I would also avoid using a long log of mixed driving to edit the MAF curve. You will inevitably add in other sources of fueling error, like transient response. I would do dedicated free revs, pausing with the MAF rate at each axis value. Then composite that data with a WOT run from very low rpm and see if you have any gaps to fill.
Interesting, I'l give it a shot and get back to you.
Giving this thread a bump to see if anyone has made some knowledge gains.
I'm going to try to run some more testing and see if I can refine the method.
My car has well behaved STFTs, but a car I am tuning just switched to LTs and I am seeing a ton of STFT oscillation; even with some of these static multipliers applied.
read your post with much interest. Asked myself why the values has to be divided by 2. Maybe because the delay total PID delivers the sum of both sensors? Could be an explanation.
Anyway. Have you tested this approach further, any additional conclusions?
Last edited by nonnex; 07-10-2019 at 07:38 AM.
Interested in updates. I have found that I cannot trust my trims until the delay is learned by the ECU in mixed driving. I am emailing support to have the PID added to my calibration.
MAF and TD may not be related but absolutely, if I try and use STFT to dial in the MAF directly after a flash or relearn the data is remarkably bad. No filtering seems to help it.
Hopefully once I can log it this will clean up the car a bit so I can revisit getting the MAF calibrated 100% I am also switching out all of my 02s as I have 30k and much of it was on e85.
That makes a lot of sense.
Which specific channel did you request? "Transport delay"?
The behavior makes sense, as transport delay is critical to having accurate fuel trims. The accuracy of your flashed transport delay channel would have a big impact on the time taken before transport delay learning sorted things out.
My question is: does the normal logged "transport delay" channel just start changing as learning takes place, or is there some learned table that gets built?
A lot of trims have to be learned after KAM reset STFT as well - logging within first couple of miles is pointless.
v-performance.pl/
facebook.com/veee.performance/
https://www.instagram.com/v.performance.pl/
Remote tuning:
[email protected]
+48 697276579
What other learned trims would affect accuracy of STFTs?
Fuel pump voltage table learning?
Correct
Eric added the PID to my calibration, I wont be able to look at it until tomorrow night however. I have logged enough to know to never log right after a flash however when my values are very wrong it can take well over a couple minutes to get anything right. My fuel pressures are tied to voltages and I don't see any hint of learning in the calibration. Do you know if its possible to log these corrections?
For example - I did a 15 minute drive after a flash - Trims were all over the place and at points over 15 percent - also at times the short terms and long terms were fighting in opposite directions. Trims never settled in.
Same calibration with 20 percent across the board increase - 7.5 minutes in the trims calmed down and were within +2 -2.
I don't think I will ever try to use Trims for the MAF again and instead try steady state EQ error. They are all trailing indicators but with enough date it should be fine.
I am also considering changing the load threshold for learning from .1 to .20.
I have read elsewhere that thinner, lighter material long tubes, no cats, free flowing exhaust and low load can allow 02 sensors to reach lower temp ranges and they can perform poorly exacerbating the problem.
I have done some more testing on this lately.
I tried to test out the concept of the PCM "learning" better transport delay values and saw no evidence of this happening.
Basically, I intentionally jacked the transport delay up for a specific cell that I could easily hold at steady state ( 2500 rpm, .15 load). As I hit that condition the STFTs destabilized as expected. But even after racking up quite a few minutes of holding this exact condition steady, the trims never stabilized and the logged transport delay didn't change.
I have also shown that I can't really distinguish between transport delay too high, or too low. They both destabilize trims, but I don't see a difference between the two.
It seems like this would be an easy thing for the PCM to calibrate for: during times of relatively steady state, it could fire a very long pulse width and count until it registered on the WB. But I'm struggling to come up with a good way to calibrate accurately manually.
My car with stock cats and headers, obviously has pretty nice STFT response, but customer cars with different long tubes end up with trims chasing around more than I like.
It can't do that, as it's looking at one sensor reading four cylinders. Not firing in an order that the pulses arrive in a consistently spaced pattern. Two pulses will be close, then the next one will be farther apart, etc.
The way it works is the first cylinder on a bank will fire a little lean, the next on that bank will be a little rich and so on and so forth. The ecu looks for this switch from lean to rich to determine the transport delay. Its a modulated signal in the actual O2 reading. If all the pulses where rich it couldn't determine any distance between pulses, same if they were all lean.
The whole banks not going lean rich, lean rich, it's cylinder by cylinder that it's doing that. The O2 signal filter applied in the calibration is what's making it look like the banks going lean rich, lean rich in closed loop stoich. Wonder why at WOT the signal stops being a wave?
You would need to look at individual injector pulse width per injector. Then get raw O2 reading and look for the modulation on that signal and compare. I think it's a waste of time, if your air and fuel models are close, in the realm we are working with OBD data, it will learn/correct the transport delay, and you won't even notice a difference from when it wasn't learned. Very much like fuel trims, OAR, and the other correction loops. You don't notice them working when things are not very wrong.
So, is the logged WB EQ signal heavily filtered then? Because you can't see a bit of that rich/lean "noise".
You say "The O2 signal filter applied in the calibration is what's making it look like the banks going lean rich, lean rich in closed loop stoich", but isn't that just the commanded EQ rich/lean swing to facilitate the oxidation/reduction reactions in the catalyst?
Here is an example of a customer car, with STFTs in a chase condition that I think is driven by transport delay values that don't match up with the long tubes:
hunting.hpl
And here is a shot showing the test that I did, artificially driving down the transport delay value (on the left), vs normal value (on the right).
Over the course of a 10 minute drive with nearly 3 minutes spent holding steady at 2500 rpm 0.15 load, I saw no improvement in STFT stability:
transport-mod.jpg
Yes it is filtered, you don't see the sensor read the very rich or lean pulses,unless its out of control, you just see the trims correcting, but it needs to have happened for it to have been sensed and corrected by short term. Ford treats the wide band signal just like a narrow band signal would be doing with it going back and forth rich to lean and fuel trims try to keep it at stoich. Why not just target stoich as close as possible in a PID loop, IDK maybe its a simpler/faster calculated PI loop with the disturbance. Stoich is where the catalytic converters work best for both oxidation and reduction reactions in the catalytic converter, there no benefit going rich/lean/rich in that regard.
you TD is in the .4-.5 second range, that is zoomed in completely to 1 second time frame, about half of what you see in the chart.
at 2000 RPM you have 33 RPS. Every revolution 4 cylinders fire giving four exhaust pulses per revolution. So ~132 exhaust pulses per second. About 16 pulses per cylinder a second, Again not evenly spaced. Two consecutive pulses, short space, another pulse, long space, a pulse,a short space, then two consecutive pulses again. Find how long that pattern takes to repeat in your WB chart at 15-16hertz polling speed. It will get lost in the charts interpolation. Yet there are individual cylinder fuel mass multiplier tables, that if you follow the firing order through on a single bank, constant load and RPM, the sensor should see a rich/lean/rich individual pulse pattern modulated in the main signal, and the ECU will see that.
To me the log looks like fuel trims are following a spot in the MAF. Whether it's error in the transfer, SD, fuel system control, injector data, or one of the major things the MAF goes into I can't say, I don't know the situation well enough. I will say your WB signal bouncing around stoich, while trims are under -10% means your TD is not far off enough to loose control of fueling. The spots off of stoich in the beginning and middle further from stoich I would say it attempts to go into and come out of DFCO, so it wasn't loosing control in those spots, thats normal.
I have tried to use an analytical method like that to gut check my values, but am missing something. I definitely don't see per-cylinder pattern in that WB signal, and am getting ~15.5 Hz on that channel.
Take this example, zoomed in on a steady state:
O2 Response.jpg
Steady state:
2500 rpm
0.15 load
0.202 stock transport delay
0.217 stock TD time constant
This was with the transport delay values for this condition artificially cut in half (0.106)
0.350 logged "O2 Transport Delay Total"
0.470 observable delay from peak PW to peak rich EQ (average of 3 different peak to peak measurements)
I'm just not seeing a connection between these pieces of data.
I have drawn in what seems like an important characteristic: the time delay from the center of the peak injector PW, and the center of the rich EQ swing.
Now, I think that PW is an average across all cylinders, and there is some stagger in the commanded rich/lean swings from bank to bank. So, maybe I need to look at both bank's commanded EQ to negate that portion of the offset.
It's also interesting to see that with the highly reduced transport delay value, the STFT moves almost in synchronization with commanded EQ.
This is on my personal car, with factory headers and cats. So, I can't think of any reason I should deviate from stock values, which makes it a good test bench for relating stock values to observable data.
Here is another log with the TD value set to 0.242:
O2 Response.jpg
~0.450 observable delay from peak PW to peak rich EQ (average of 3 peak to peak). Roughly the same as above.
0.468 logged "O2 Transport Delay Total"
It clearly changes the rate at which EQ is cycled rich/lean.
The observable response delay is essentially the same (that is nice)
The "logged transport delay total" changes significantly when the TD table values are changed.
If it is repeating a per-cylinder rich lean cycle, how can it use that alone to establish a transport delay?
At 2500 rpm -> 42 rev/sec -> 21 per-bank-patterns / sec, even in the defined transport delay of 0.242, there are 5 full bank sequences (one every 0.050 sec). How does it know which one is which? To me that sounds like trying to figure out the lag between opening the throttle and rpms rising, by looking only at the crank trigger signal. It's hard coded to rotation, and can't give you transient response data. It seems like the "pattern" of adding an observably different set of pulse widths, would have to be longer than the maximum possible transport delay, to avoid ambiguity in which time difference to measure.
Last edited by CCS86; 10-17-2019 at 10:41 AM.
Reply With Quote