The_Gimp
Newbie
Karma: +2/-0
 Offline
Posts: 11
|
 |
« Reply #15 on: April 15, 2013, 06:07:27 AM »
|
|
|
hey you tubes! lol, i do MAF table revisions real gerd.
ok, so on subject. what do you think of this LAMFA table? please note the revised RPM and load points.
obv would like input from el trooperino from near cupertino on this table:
I would only modify the last two columns. Beyond that, your requested should be richest around peak torque. (B5S4: ~3500-5000) and taper off to ~12.5:1 as the curve gets furthest from that point. There's probably no need to be at .8 at 7000RPM. |
|
|
|
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #16 on: April 24, 2013, 08:05:21 PM »
|
|
|
I am using 0.001525902 as the conversion for ZKLAMFAW. It is (sorta) the percentage of change per cycle (0-100). Better understanding here: current value +- ((|new value - current value|)*constant)
I am currently using a value of 50 for rapid change. |
|
|
|
|
Logged
|
|
|
|
automan001
Full Member
Karma: +47/-0
Offline
Posts: 153
|
|
« Reply #17 on: June 30, 2013, 01:29:40 AM »
|
|
|
Has anybody tried to configure ZKWLAFWL (Time constant weighting offset engine target lambda)?
What influence does it have on target lambda? I guess it's related to KFLAFWL (Offset engine target lambda)
It's currently defined as a byte with value FF = 255 s
And i doubt it's correct definition.
I thought it should have been similar to ZKLAMFAW.
In FR LAMFAW 7.100 (Driver's Requested Lambda) it's default value is similar to
ZKLAMFAW
:
ZKLAMFAW: 2 s
ZKWLAFWL: 2 s
|
|
|
|
« Last Edit: June 30, 2013, 01:34:34 AM by automan001 »
|
Logged
|
|
|
|
automan001
Full Member
Karma: +47/-0
Offline
Posts: 153
|
|
« Reply #18 on: July 03, 2013, 07:59:20 AM »
|
|
|
I halfed it and there is still a slight delay, but I haven't had a chance to really play with it further.
I am using 0.001525902 as the conversion for ZKLAMFAW.
It is (sorta) the percentage of change per cycle (0-100). Better understanding here:
I am currently using a value of 50 for rapid change.
To increase the speed of change, the value has to be increased? FFFF is fastest change? |
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #19 on: July 03, 2013, 11:32:21 AM »
|
|
|
No, it is a time constant, so decreasing it makes the response faster.
|
|
|
|
|
Logged
|
ME7.1 tuning guideECUx PlotME7Sum checksumTrim heatmap toolPlease do not ask me for tunes. I'm here to help people make their own. Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your ex
|
|
|
|
julex
|
|
« Reply #20 on: July 03, 2013, 11:41:20 AM »
|
|
|
Are you sure? The formula above would indicate that the value would actually make faster change the higher the number is and what phila_dot states above, along with his set up for this value, would make sense in that light.
|
|
|
|
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #21 on: July 03, 2013, 12:57:39 PM »
|
|
|
The formula that I posted is directly from the code and is exactly how it works.
The conversion is my device and how I prefer to realize it.
|
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #22 on: July 03, 2013, 01:40:01 PM »
|
|
|
The formula that I posted is directly from the code and is exactly how it works.
So to confirm: the FR is incorrect, and it is not a time constant? |
|
|
|
|
Logged
|
ME7.1 tuning guideECUx PlotME7Sum checksumTrim heatmap toolPlease do not ask me for tunes. I'm here to help people make their own. Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your ex
|
|
|
|
nyet
|
|
« Reply #23 on: July 03, 2013, 01:48:38 PM »
|
|
|
$ grep ZKLAMFAW *.csv
4Z7907551R.csv:"ZKLAMFAW","0x1edac","Zeitkonstante Filterung Anfettung durch Fahrerwunsch","1x1","16 Bit (LoHi)","-","s","-","-","1.0","1.0","1.0","13107.0","13107.0","0x3333","0x3333"
8D0907551F.csv:"ZKLAMFAW","0x1ca4c","Zeitkonstante Filterung Anfettung durch Fahrerwunsch","1x1","16 Bit (LoHi)","-","s","-","-","1.0","1.0","1.0","65535.0","65535.0","0xffff","0xffff"
8D0907551G.csv:"ZKLAMFAW","0x1c3f0","Zeitkonstante Filterung Anfettung durch Fahrerwunsch","1x1","16 Bit (LoHi)","-","s","-","-","1.0","1.0","1.0","65535.0","65535.0","0xffff","0xffff"
so 2.7t F and G box (stock) values seem to be zklamfaw = 0xffff (100%), and R box 0x3333 (20%) phila: does this jibe with your understanding? |
|
|
|
« Last Edit: July 03, 2013, 01:50:14 PM by nyet »
|
Logged
|
ME7.1 tuning guideECUx PlotME7Sum checksumTrim heatmap toolPlease do not ask me for tunes. I'm here to help people make their own. Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your ex
|
|
|
|
phila_dot
|
|
« Reply #24 on: July 04, 2013, 10:22:54 PM »
|
|
|
So to confirm: the FR is incorrect, and it is not a time constant? Yes, at least that is the case in our ECU's. so 2.7t F and G box (stock) values seem to be zklamfaw = 0xffff (100%), and R box 0x3333 (20%)
phila: does this jibe with your understanding?
Yes, 100 (0xFFFF) would be no filtering. The value will jump to the desired value in the same cycle. 50 (0x8000), will take 11 cycles to reach the desired value going 50% of the difference each cycle. Stock value of 20 (0x3333) would take (alot of) cycles to reach the desired value. 0, becomes 1 IIRC to avoid preventing change. Edit: corrected error in number of cycles |
|
|
|
« Last Edit: July 05, 2013, 08:58:09 AM by phila_dot »
|
Logged
|
|
|
|
|
julex
|
|
« Reply #25 on: July 05, 2013, 07:17:42 AM »
|
|
|
Yes, at least that is the case in our ECU's.
Yes, 100 (0xFFFF) would be no filtering. The value will jump to the desired value in the same cycle.
50 (0x8000), will take two cycles to reach the desired value going 50% each cycle.
Stock value of 20 (0x3333) would take 5 cycles to reach the desired value.
0, becomes 1 IIRC to avoid preventing change.
Any idea what the "cycle" is then? On the side note, I see that LAMKR is also filtered via this which has huge ramifications to anybody using map KFLAMKRL for enrichment on knock. This explains my experience with delay in fueling enrichment on knock I was experiencing to date which I always attributed to interpolation in the map itself, not the filter. It would make sense to me to switch filter to "100%" - no filtering. |
|
|
|
« Last Edit: July 05, 2013, 07:26:28 AM by julex »
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #26 on: July 05, 2013, 08:30:55 AM »
|
|
|
Ecu cycle
This occurs everytime the code is run. The output filtered value is adjusted towards the input desired value whethers it's toward enrichment or enleanment.
Yes, this is applied at the end of LAMFAW and will effect desired lambda from the entire function.
|
|
|
|
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #27 on: July 05, 2013, 08:50:56 AM »
|
|
|
Ok, so I'm slightly an idiot.
It will take alot more ECU cycles because it recalculates everytime.
So with ZKLAMFAW set to 50%, enriching from lambda 1 to 0.80:
1st cycle : lamfa_w - 0.90
2nd cycle : lamfa_w - 0.85
3rd cycle : lamfa_w - 0.825
4th cycle .....
|
|
|
|
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #28 on: July 05, 2013, 09:27:49 AM »
|
|
|
I should add that I was also running DLAMFAW at 0.008 to get back to lambda 1 and closed loop faster, but that might not be necessary if you FFFF ZKLAMFAW.
|
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #29 on: July 09, 2013, 09:51:41 PM »
|
|
|
BTW i don't see that anybody posted the ME7.1 m-box location... i am using 0x1c3ee (hopefully I have it right)
|
|
|
|
|
Logged
|
ME7.1 tuning guideECUx PlotME7Sum checksumTrim heatmap toolPlease do not ask me for tunes. I'm here to help people make their own. Do not PM me technical questions! Please, ask all questions on the forums! Doing so will ensure the next person with the same issue gets the opportunity to learn from your ex
|
|
|
|
