NefMoto

Hi guys,

I wanted to check if I understood some basic principles (and they are pretty basic LOL). To begin with, I don’t have an ME7 background and my learnings are pretty much restricted to what we drive at home – 2.0 TFSI (hence my interest in MED9.1). I stress this is basic stuff and has been covered before in huge detail. I found it pretty fascinating though and wanted to get it down in one convenient place that I can come back to.

1)   I began by installing the WinOLS demo version from EVC. (http://www.evc.de/en/download/down_winols.asp)
2)   I read out the stock 2048kb flash (http://nefariousmotorsports.com/forum/index.php?topic=5418.msg51165#msg51165) from the ECU of the car via ODB.
3)   MED9.1 definitions files can be found here (http://nefariousmotorsports.com/forum/index.php?topic=467.msg3369#msg3369) and here (http://nefariousmotorsports.com/forum/index.php?topic=1085.msg43772#msg43772) in the ECU Definition Files section.
4)   Now the definition files are not a perfect match to my flash, so it’s a manual process of aligning my own flash to a similar, already defined flash and transferring the maps over. Easier said than done especially if you’ve never seen it before, but this contribution (http://youtu.be/0dkuoFh2foQ) helped me.
5)   Bosch VAG MED9.1 FDEF (http://nefariousmotorsports.com/forum/index.php?topic=812.msg6906#msg6906)
6)   The S4wiki (http://s4wiki.com/wiki/Main_Page) is invaluable to getting started and explains the fundamentals very well (like load :)). I also found this write-up on the Audi TT 1.8T Bosch Motronic ME7.x (http://nefariousmotorsports.com/forum/index.php?topic=62.msg3330#msg3330) again helped me with the basics. A lot of effort in both.
7)   The MED9.1 threads here (http://nefariousmotorsports.com/forum/index.php?topic=1068.0title) and here (http://nefariousmotorsports.com/forum/index.php?topic=3104.0title) in the tuning section contain a huge amount of info. Every time I go through them I spot something new.

A big thank you to all of you who created those original posts! That's how new people like me can get started ;D

Question. Here’s the locations of the maps in my stock binary, as far as I can make out. Did I get the locations correct? They are very similar to the locations (http://nefariousmotorsports.com/forum/index.php?topic=1068.msg10263#msg10263) Rarak posted up at the start of his MED9.1 thread.

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=8472;image)

Lots of theory, let's put it into practice!

From the S4wiki:

ME7.1 doesn't really have a "boost" table. It does everything based on "specified load".

First, make sure the 100% torque request (rtlsol) row requests enough load:
KFMIRL - specified load

Specified load/boost will never exceed these limits:
LDRXN - maximum specified load
KFLDHBN - maximum requested pressure ratio

Specifically, on a full throttle pull, your boost profile will follow LDRXN

If I did get the location of those maps correct then here’s what they contain in my flash:

KFMIRL   - specified load

RPM vs Requested Torque (%)	500	700	800	1000	1240	1520	2000	2520	3000	3520	4000	4520	5000	5520	6000	6520
4.0009	11.4375	10.9453	10.7109	10.2188	9.7031	9.3047	8.8828	8.6250	8.5313	8.5078	8.5313	8.5078	8.4375	8.2734	8.0625	7.8281
5.9998	15.7266	15.2813	15.0703	14.6250	14.1094	13.6875	13.1719	12.8438	12.6563	12.5859	12.5625	12.4922	12.3516	12.1406	11.9063	11.6250
8.0002	19.9922	19.6172	19.4297	18.9844	18.5391	18.0703	17.4844	17.0391	16.8047	16.6875	16.5938	16.4531	16.2891	16.0313	15.7500	15.4219
13.9999	32.7188	32.6016	32.5547	32.3672	31.8281	31.1719	30.3047	29.6719	29.2500	28.9219	28.6641	28.3594	28.0313	27.6563	27.2813	26.8359
19.9997	45.4219	45.3047	45.2344	45.0469	44.6953	44.1094	43.1484	42.3516	41.7656	41.2031	40.7109	40.2188	39.7500	39.2578	38.7891	38.2500
30.0003	66.6563	66.3750	66.2344	66.0000	65.8594	65.3203	64.3359	63.3984	62.5313	61.4531	60.5391	59.7422	59.1563	58.6172	58.1016	57.5391
39.9994	88.1250	87.5391	87.2578	86.7422	86.2969	86.0156	85.1016	83.8359	82.5703	81.2578	80.1797	79.3359	78.7969	78.3047	77.9063	77.5313
50.0000	109.9922	109.4766	109.1953	108.7031	108.1406	107.5781	106.2891	104.4609	102.7969	101.3672	100.3359	99.5859	99.2109	99.0469	99.0703	99.3281
60.0006	132.3516	131.9766	131.8125	131.4375	130.9688	130.3125	128.8828	126.7500	124.6875	122.9531	121.7578	121.0313	120.8672	121.1719	121.8047	122.8359
69.9997	154.9453	154.7344	154.6172	154.3594	154.0313	153.5625	152.5078	150.6328	148.3828	146.1797	144.6563	143.6953	143.5781	144.1641	145.3594	147.1875
80.0003	177.6797	177.5859	177.5391	177.4219	177.2344	176.9297	176.0391	174.4688	172.3594	170.0859	168.3281	167.1563	166.9453	167.5547	168.7500	170.4375
90.0009	200.3203	200.3672	200.3906	200.4141	200.4141	200.2969	199.7109	198.4219	196.5234	194.1797	192.2109	190.8281	190.4531	191.0391	192.1875	193.6172

The last row is WOT and has plenty of demand (> 190%)

LDRXN - maximum specified load

RPM vs Load (%)	1000	1500	1750	1850	2000	2250	2500	3000	3500	4000	4500	5000	5500	6000	6600	6800
	100.0078	118.0078	125.0156	130.0078	140.0156	172.0078	172.0078	172.0078	172.0078	172.0078	175.0078	175.0078	175.0078	168.0000	158.0156	100.0078

Maximum allowed load here is going to be 172% to 175%. Even if I request 200%, I'll just get 175%.

KFLDHBN - maximum requested pressure ratio

RPM vs Temperature (°C)	2000	3000	4000	5000	5520	6000	6600	6760
-20.25	2.4063	2.4063	2.3750	2.3125	2.2188	2.0781	1.9219	1.7656
0.00	2.4063	2.4063	2.3750	2.3125	2.2188	2.0781	1.9219	1.7656
20.25	2.4063	2.4063	2.3750	2.3125	2.2188	2.0781	1.9219	1.7656
40.50	2.3594	2.3594	2.3438	2.2656	2.1719	2.0313	1.9219	1.7344
50.25	2.3281	2.3125	2.3125	2.2031	2.1094	2.0000	1.9063	1.7188
60.00	2.2813	2.2656	2.2656	2.1719	2.0781	1.9688	1.8750	1.6875
70.50	2.2344	2.2031	2.2031	2.1406	2.0469	1.9375	1.7969	1.6563
120.00	2.2188	2.1563	2.0938	2.0156	1.9219	1.7969	1.6406	1.4844

I also took some VCDS logs from the car

Timestamp	Engine Speed	Intake Air Mass	Lambda Sensor - Current Value	Sender 2 for - Acc. Pedal Pos.	Throttle Drive - Angle Sensor 1	Median - injection timing	Current - Fuel Pressure	Engine Load - (specified)	Engine Load - (actual Value)	Boost Pressure - (specified)	Boost Pressure - (actual)	Rail Pressure - (actual)
1835.3	2800	23.75	1	17.6	10.2	1.02	4.12	171.4	30.1	590	1020	67.67
1835.74	2840	37.69	0.98	24.3	14.5	1.53	4.13	171.4	42.1	820	1050	77.12
1836.16	2840	59.03	0.99	32.2	20	2.04	4.16	171.4	63.9	1040	1140	87.81
1836.6	2880	92.53	1	96.5	70.2	3.57	4.16	171.4	114.3	2040	1390	95.62
1837.03	2960	109.97	0.97	99.6	99.2	4.84	4.16	171.4	155.6	2030	1840	100.56
1837.45	3040	113.17	0.93	99.6	98.8	5.61	4.12	171.4	169.2	2020	1960	106.76
1837.89	3120	117.28	0.89	99.6	98.8	5.87	4.15	171.4	172.2	2010	1980	109.69
1838.33	3200	122.19	0.88	99.6	98.8	5.87	4.17	171.4	174.4	1990	2000	109.67
1838.75	3280	122.75	0.89	99.6	98.8	5.87	4.19	171.4	173.7	1980	1990	109.22
1839.19	3400	125.28	0.88	99.6	98.8	5.87	4.2	171.4	171.4	1970	1960	110.11
1839.62	3480	126.75	0.88	99.6	98.8	5.87	4.2	171.4	169.2	1960	1930	109.99
1840.06	3560	129.5	0.89	99.6	98.8	5.61	4.19	171.4	166.9	1950	1910	109.16
1840.5	3640	130.58	0.88	99.6	98.8	5.61	4.18	171.4	166.9	1950	1920	109.52
1840.92	3720	131.58	0.88	99.6	98.8	5.61	4.17	171.4	165.4	1950	1900	109.67
1841.35	3800	137.67	0.89	99.6	98.8	5.61	4.17	171.4	164.7	1950	1910	110.44
1841.79	3880	140.31	0.9	99.6	98.8	5.61	4.12	171.4	168.4	1960	1930	111.08
1842.22	4000	144.33	0.89	99.6	98.8	5.61	4.11	171.4	168.4	1960	1950	109.1
1842.66	4080	147.06	0.89	99.6	98.8	5.87	4.04	171.4	169.2	1980	1960	110.06
1843.1	4080	72	0.88	99.6	98.8	5.87	4.08	172.2	168.4	1160	1780	109.3
1843.52	4080	8.14	0.91	0	10.2	0.77	4.4	172.2	19.5	280	1320	88.34
1843.96	4080	12.97	0.92	0	8.6	0.51	4.6	172.2	16.5	280	1120	87.31
1844.4	4040	13.89	0.99	0	9.4	0.51	4.36	171.4	16.5	280	1060	85.61
1844.83	4000	13.97	1.99	0	9.4	0	4.15	171.4	16.5	280	1040	85.05

Putting it all together, I can see that when I put my foot down at WOT the actual engine load increases until it reaches the specified engine load LDRXN and it’s then capped at around 172% (specified engine load), exactly as predicted by the maps!

I said it was basic stuff, but it was nice to actually see it happening ;D

What did you use to read out the Ecu via OBD ? MPPS right ?

Read the FDEF.
Or if you want to know the full truth, disassemble the code when uncertain.

My advice is - forget all the digested down information on forums, wikis and other things.
They are just the way someone sees things, and you seem like a smart enough guy to just follow reference documentation and make your own mind about how things work, there should mostly be no need to read anyone else's interpretation of things.

Of course knowing German does help.

Figuring things out is easy. Writing how you understand things in a way that others can read and understand is hard.

The latter talent is rare. I would say... almost non-existent.

hey man!  Nice post!  What is your offset for KFLDHBN?  I'm working on GOLF R ecu and I've found LDRXN (x6), LDRXNZK (x6), LAMFA (x3), KFMIRL but i can't seem to find KFLDHBN.  Looks like our engines are similar since our LDRXN values/etc. are almost identical.  I'd like to try to match up your KFLDHBN values in my flash.

Thanks!
Jordan

nevermind! just took the extra 2 minutes and did the math on the values you posted lol.  Found it!

Correct. Clone version 13.02


Thank guys. LOL, I only just understood what load means :D so it will be a while before I try any disassembling! The only way I really learn something is if I try and figure it out for myself. I think that’s the same for most people. Honestly though, the wiki helps a lot.


Glad you liked it! Here’s what I’ve got so far.

I couldn’t find KFMIRLS though. Is it possible that both KFMIRL and KFMIRLS could refer to the same eeprom address?

KOMRH
	1CC9A0	KFMIRL
LDRLMX
	1CECE8	KFLDHBN
	1CED4A	LDRXN
	1CED8C	LDRXN
	1CEDCE	LDRXN
	1CEE10	LDRXNZK
	1CEE52	LDRXNZK
	1CEE94	LDRXNZK
MDFUE
	1CC9A0	KFMIRL
MDPED
	1CBBD4	KFPED_0_A
	1CBD54	KFPED_1_A
	1CBED4	KFPEDL_0_A
	1CC054	KFPEDL_1_A
	1CC1D4	KFPEDL_2_A
	1CC354	KFPEDR

Also, what definition file are you using to track down your maps? Is it one of the ones posted here? If you have another one, would you mind sharing it ;D

 

Very basic question, sorry.

Where does the scaling value come from when you look at maps in WinOLS?

The picture shows what I mean.

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=8512;image)

For example, I know the rpm ranges from 0 to 6000 and the load ranges from 0 to 200%. But all that the map contains are some hex values that are multiplied/scaled by a factor to represent these real world values? Where does that scaling value in WinOLS come from? Is it also in the hex or maybe in the FDEF or only in WinOLS?

I'm asking because if I'm comparing my flash versus a defined flash in WinOLS, I'm really reliant on that defined bin. My scaling could be different, but how could I check?

Thanks

I'm using the 8P0907115 definition posted in one of the two threads you posted. 

I also can't find KFMIRLS.  Honestly i haven't even googled stratified injection mode yet, but i don't think our engines support it, so they might not have KFMIRLS.  i THINK i found KFMIOPS though, so IDK. Seems KFMIRLS X-axis is different slightly from KFMIRL but Y-axis is the same.  I just can't locate with either.

The scaling is only contained in the definition AFAIK but doesn't change from engine to engine (AFAIK).  You have to rely on your reference definition to have the correct scaling.

I'm currently mulling over factors also..

I though maybe it was y=mx+b style equation but was unable to arrive at the same answers when I looked.

Hint: Most are multiples of 1/256 or 1/65536

also:

http://nefariousmotorsports.com/forum/index.php?topic=3392.msg52332#msg52332

That's kind of what I was getting at so FF or FFFF are the max values etc.

BUT there is a few odd factors that get me confused when I find them, for example:

(ME9 style maps here but ME7 file with DECOS and ME9 style functions)

DSVDGRAD (DSLGRAD in most other ME7 files) is part of %GGPVD and all factors that I've found in A2L's point to a factor of 0.015625.  Also in all ME7 files that I've seen, value of this map in decimal is 540.00.  It doesn't make sense for this to be to be any greater number as it's a factor for calculating v-out to pvdr_w so 4.87v * 540 = 2629.8 for example.  These calculations fall into the realm of the Bosch datasheets that I see for all of the 2500 sensors, including mine.

Now I have disassembled my file and am 100% certain that I have the correct location, if I use the factor of 0.015625 the map value for DSVDGRAD is incorrect and comes to 651.23xxx, obviously the easy method is to back calculate the factor as we know the value should be 540.  But I just can't understand WHY LOL, it's doing my head in...It can't be anything to-do with tick speed as it's not timing/tick based, it's just a factor.  So the max value must be different for some bizzare reason.

So 0.015625 * 65536 = 1024 (max value)

Here is the maths on how to work out factors from the A2L BTW:

(VAG MED9 A2L)

    DSVDGRAD
    "Gradient für Drucksensor vor Drosselklappe"
    VALUE
    0x1C4A14
    KwUw
    1023.984 (Total swing of value)
    dgrad_uw_q0p015 (COMPU_METHOD) - can be shared etc.
    0.00 (min value)
    1023.984 (max value)

 y=mx+b equation:- (0 - 1023.984) = 1023.984 /  (0 - 65536) = 65536 (WORD) + 0 (no offset) = 0.015624755859375

So y = 0.015624755859375 = factor of DSVDGRAD for MED9/ME7 IF the min and max values are as above and the map is a WORD.


Major old edit.......... I was right, but didn't realise sensor was different :)

Sorry, I meant to attach the ASM picture but forgot.  I can't see any error (pvdr_w is definitely correct).

At some point, many things are just unitless scalars, or used in calculations where the result are some other units where the "natural" unit doesn't make sense because of another scaler (say pi or something - radians vs degrees, etc), or they are inverse units.

So in many case the "meaning" of the value in the CPU may not directly align with any sort of units or scaling that makes sense to you..

Quite, but the code can't be too different, it still ends's up as the same variable after coming from the same ad convertor and same cpu..

Added x3 LAMFA maps

BGFAWU
	1D6886	LAMFA
	1D68FE	LAMFA
	1D6976	LAMFA

I noticed that even in the defined WinOLS that I'm using as a reference, the values looked a bit strange. The Y-Axis peaks in the centre which can't be correct ???

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=8548;image)

After a bit of searching, I found a suggestion about moving an axis and table by one byte:

Increment Y-Axis Start Address by one byte (from 0x1D6879 to 0x1D687A)
Increment Map Start Address by one byte (from 0x1D6885 to 0x1D6886)

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=8550;image)

Looked a lot better after that :) Has anyone else come across this?

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=8552;image)

Is that not the infamous Winols bug that's in 'older' versions?

My advise, use DAMOS as an orientation... if you look closer you´ll find a bunch of another weird things in some maps.

Not sure, but there are a lot of DAMOS's OLS's that have 16 bit map locations that are not 16 bit aligned (and thus wrong)

Hi all,

So I finally made some changes :D Not very big ones, I'm still very new and it's more a question of changing one thing at a time and understanding the consequences. I haven't posted this in the tunes section of this forum since it's far from a tune!

This is MED9.1 on an Audi S3 2.0 TFSI (UK specification, manual gearbox).

Please bear with me, the tables are number-heavy and I've split things across several posts to make things a bit neater. I've changed just 3 maps:

KFMIRL
KFMIOP
LDRXN

Firstly, my stock values:

KFMIRL - stock

% / RPM	500	700	800	1000	1240	1520	2000	2520	3000	3520	4000	4520	5000	5520	6000	6520
4.0009	11.4375	10.9453	10.7109	10.2188	9.7031	9.3047	8.8828	8.6250	8.5313	8.5078	8.5313	8.5078	8.4375	8.2734	8.0625	7.8281
5.9998	15.7266	15.2813	15.0703	14.6250	14.1094	13.6875	13.1719	12.8438	12.6563	12.5859	12.5625	12.4922	12.3516	12.1406	11.9063	11.6250
8.0002	19.9922	19.6172	19.4297	18.9844	18.5391	18.0703	17.4844	17.0391	16.8047	16.6875	16.5938	16.4531	16.2891	16.0313	15.7500	15.4219
13.9999	32.7188	32.6016	32.5547	32.3672	31.8281	31.1719	30.3047	29.6719	29.2500	28.9219	28.6641	28.3594	28.0313	27.6563	27.2813	26.8359
19.9997	45.4219	45.3047	45.2344	45.0469	44.6953	44.1094	43.1484	42.3516	41.7656	41.2031	40.7109	40.2188	39.7500	39.2578	38.7891	38.2500
30.0003	66.6563	66.3750	66.2344	66.0000	65.8594	65.3203	64.3359	63.3984	62.5313	61.4531	60.5391	59.7422	59.1563	58.6172	58.1016	57.5391
39.9994	88.1250	87.5391	87.2578	86.7422	86.2969	86.0156	85.1016	83.8359	82.5703	81.2578	80.1797	79.3359	78.7969	78.3047	77.9063	77.5313
50.0000	109.9922	109.4766	109.1953	108.7031	108.1406	107.5781	106.2891	104.4609	102.7969	101.3672	100.3359	99.5859	99.2109	99.0469	99.0703	99.3281
60.0006	132.3516	131.9766	131.8125	131.4375	130.9688	130.3125	128.8828	126.7500	124.6875	122.9531	121.7578	121.0313	120.8672	121.1719	121.8047	122.8359
69.9997	154.9453	154.7344	154.6172	154.3594	154.0313	153.5625	152.5078	150.6328	148.3828	146.1797	144.6563	143.6953	143.5781	144.1641	145.3594	147.1875
80.0003	177.6797	177.5859	177.5391	177.4219	177.2344	176.9297	176.0391	174.4688	172.3594	170.0859	168.3281	167.1563	166.9453	167.5547	168.7500	170.4375
90.0009	200.3203	200.3672	200.3906	200.4141	200.4141	200.2969	199.7109	198.4219	196.5234	194.1797	192.2109	190.8281	190.4531	191.0391	192.1875	193.6172

KFMIOP - stock

% / RPM	500	700	800	1000	1240	1520	2000	2520	3000	3520	4000	4520	5000	5520	6000	6520
10.0078	3.3279	3.5660	3.6819	3.9017	4.1397	4.3228	4.5212	4.6539	4.7150	4.7333	4.7348	4.7516	4.8019	4.8965	5.0125	5.1498
15.0000	5.6625	5.8685	5.9708	6.1752	6.3995	6.5964	6.8466	7.0282	7.1259	7.1793	7.2113	7.2632	7.3441	7.4707	7.6111	7.7774
20.0156	8.0154	8.1833	8.2703	8.4579	8.6685	8.8852	9.1873	9.4131	9.5474	9.6359	9.7015	9.7900	9.9030	10.0571	10.2234	10.4172
35.0156	15.0833	15.1321	15.1581	15.2313	15.4663	15.7715	16.2064	16.5375	16.7740	16.9830	17.1585	17.3630	17.5674	17.7979	18.0283	18.2968
50.0156	22.1634	22.2382	22.2778	22.3740	22.5143	22.7722	23.2239	23.6282	23.9563	24.3332	24.6750	25.0076	25.2869	25.5615	25.8224	26.1215
65.0156	29.2191	29.3457	29.4083	29.5181	29.5868	29.8599	30.3360	30.7983	31.2408	31.7978	32.2876	32.6996	32.0002	33.2718	33.5144	33.7845
80.0156	36.2335	36.4670	36.5814	36.7966	36.9568	37.1140	37.5504	38.1317	38.7222	39.3753	39.9200	40.3412	40.6006	40.8249	40.9988	41.1514
100.0078	45.4575	45.7199	45.8481	46.0892	46.3287	46.5317	47.0551	47.8561	48.6252	49.3210	49.8322	50.1999	50.3677	50.4395	50.4135	50.2960
120.0000	54.4983	54.7012	54.8004	54.9927	55.2216	55.5099	56.1401	57.0435	57.9056	58.6594	59.1934	59.5367	59.6100	59.4757	59.2041	58.7906
150.0000	67.8116	67.9230	67.9810	68.0984	68.2541	68.4723	68.9545	69.7525	70.7001	71.6202	72.2885	72.7173	72.7722	72.5113	71.9894	71.2036
180.0000	81.0257	81.0577	81.0760	81.1203	81.1920	81.3187	81.6681	82.3135	83.1604	84.1156	84.8862	85.4294	85.5530	85.3043	84.7992	84.1278

LDRXN - stock

RPM	1000	1500	1750	1850	2000	2250	2500	3000	3500	4000	4500	5000	5500	6000	6600	6800
%	100.0078	118.0078	125.0156	130.0078	140.0156	172.0078	172.0078	172.0078	172.0078	172.0078	175.0078	175.0078	175.0078	168.0000	158.0156	100.0078

I used VCDS to log 4th gear pulls. What I'm mainly looking at here is specified and actual load. With the stock values in the tables above, this is the result I get. Ambient temperatures are nice and cool (about 5 degrees celsius in the evening) and this is all at sea level.

Specified load is 171. Actual load peaks at 191 (coincides with boost peak) and then settles down to follow specified load 171.

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=8653;image)

Now my changes.

Same again, here are the maps and I’ve marked what I’ve changed.

I spent much, much too much time worrying about the relationship between KFMIRL and KRMIOP. I read some amazing posts and I’m not going to go into it any further right now since it’s been covered elsewhere far better than I could do! Suffice it to say, KFMIRL values are raised slightly, KFMIOP axis is rescaled to match the increased values in KFMIRL and values in KFMIOP on the changed axis are interpolated accordingly. I believe it’s mathematically OK.

KFMIRL - v1

4.0009	11.4375	10.9453	10.7109	10.2188	9.7031	9.3047	8.8828	8.6250	8.5313	8.5078	8.5313	8.5078	8.4375	8.2734	8.0625	7.8281
5.9998	15.7266	15.2813	15.0703	14.6250	14.1094	13.6875	13.1719	12.8438	12.6563	12.5859	12.5625	12.4922	12.3516	12.1406	11.9063	11.6250
8.0002	19.9922	19.6172	19.4297	18.9844	18.5391	18.0703	17.4844	17.0391	16.8047	16.6875	16.5938	16.4531	16.2891	16.0313	15.7500	15.4219
13.9999	32.7188	32.6016	32.5547	32.3672	31.8281	31.1719	30.3047	29.6719	29.2500	28.9219	28.6641	28.3594	28.0313	27.6563	27.2813	26.8359
19.9997	45.4219	45.3047	45.2344	45.0469	44.6953	44.1094	43.1484	42.3516	41.7656	41.2031	40.7109	40.2188	39.7500	39.2578	38.7891	38.2500
30.0003	66.6563	66.3750	66.2344	66.0000	65.8594	65.3203	64.3359	63.3984	62.5313	61.4531	60.5391	59.7422	59.1563	58.6172	58.1016	57.5391
39.9994	88.1250	87.5391	87.2578	86.7422	86.2969	86.0156	85.1016	83.8359	82.5703	81.2578	80.1797	79.3359	78.7969	78.3047	77.9063	77.5313
50.0000	109.9922	109.4766	109.1953	108.7031	108.1406	107.5781	106.2891	104.4609	102.7969	101.3672	100.3359	99.5859	99.2109	99.0469	99.0703	99.3281
60.0006	132.3516	131.9766	131.8125	131.4375	130.9688	130.3125	128.8828	126.7500	124.6875	122.9531	121.7578	121.0313	120.8672	121.1719	121.8047	122.8359
69.9997	154.9453	154.7344	154.6172	154.3594	154.0313	153.5625	152.5078	150.6328	148.3828	146.1797	144.6563	143.6953	143.5781	144.1641	145.3594	147.1875
80.0003	179.6841	179.4398	179.2805	179.0032	178.9535	179.1020	178.9808	177.8739	175.6823	172.8974	170.8025	169.3654	169.1139	169.7420	171.2305	173.4012
90.0009	211.6003	212.1133	212.3823	212.7985	213.0964	212.5937	211.7293	210.0845	208.1243	205.7168	203.7935	202.5029	202.1585	203.0555	204.5441	206.2987

KFMIOP - v1

% / RPM	500	700	800	1000	1240	1520	2000	2520	3000	3520	4000	4520	5000	5520	6000	6520
10.0078	3.3279	3.5660	3.6819	3.9017	4.1397	4.3228	4.5212	4.6539	4.7150	4.7333	4.7348	4.7516	4.8019	4.8965	5.0125	5.1498
15.0000	5.6625	5.8685	5.9708	6.1752	6.3995	6.5964	6.8466	7.0282	7.1259	7.1793	7.2113	7.2632	7.3441	7.4707	7.6111	7.7774
20.0156	8.0154	8.1833	8.2703	8.4579	8.6685	8.8852	9.1873	9.4131	9.5474	9.6359	9.7015	9.7900	9.9030	10.0571	10.2234	10.4172
35.0156	15.0833	15.1321	15.1581	15.2313	15.4663	15.7715	16.2064	16.5375	16.7740	16.9830	17.1585	17.3630	17.5674	17.7979	18.0283	18.2968
50.0156	22.1634	22.2382	22.2778	22.3740	22.5143	22.7722	23.2239	23.6282	23.9563	24.3332	24.6750	25.0076	25.2869	25.5615	25.8224	26.1215
65.0156	29.2191	29.3457	29.4083	29.5181	29.5868	29.8599	30.3360	30.7983	31.2408	31.7978	32.2876	32.6996	32.0002	33.2718	33.5144	33.7845
80.0156	36.2335	36.4670	36.5814	36.7966	36.9568	37.1140	37.5504	38.1317	38.7222	39.3753	39.9200	40.3412	40.6006	40.8249	40.9988	41.1514
100.0078	45.4575	45.7199	45.8481	46.0892	46.3287	46.5317	47.0551	47.8561	48.6252	49.3210	49.8322	50.1999	50.3677	50.4395	50.4135	50.2960
120.0000	54.4983	54.7012	54.8004	54.9927	55.2216	55.5099	56.1401	57.0435	57.9056	58.6594	59.1934	59.5367	59.6100	59.4757	59.2041	58.7906
160.0000	72.0999	72.1705	72.2092	72.2989	72.3951	72.5596	72.9223	73.5772	74.4243	75.3539	76.0423	76.5123	76.5807	76.3221	75.7678	74.9619
200.0000	86.9569	87.0487	87.1186	87.2400	87.2264	87.0242	86.8844	87.1235	87.7141	88.4918	89.0605	89.4246	89.5158	89.3507	89.0238	88.5631

LDRXN - v1

RPM	1000	1500	1750	1850	2000	2250	2500	3000	3500	4000	4500	5000	5500	6000	6600	6800
%	100.0078	118.0078	125.0156	130.0078	145.0000	175.0000	198.0000	198.0000	198.0000	198.0000	198.0000	198.0000	198.0000	170.0000	158.0156	100.0078

And here are the results. Conditions pretty much the same as the stock log (same time of day, similar temperatures, same stretch of road etc).

This time the specified load is higher at 191 and the actual load stays there as well. Specified and actual boost are higher as well (and still have that little spike at the beginning, same as stock)

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=8655;image)

If you've read down as far as here, thank you for staying with me  :D My question is, why is specified load not any higher than 191, despite there being enough headroom in the maps? I did find some information here (http://nefariousmotorsports.com/forum/index.php?topic=4441.0) which looked relevant

LDRXN is basic max specified load. There's an additive for overboost if active, then factors for knock, IAT, oil temp, and coolant temp. These can all raise or lower max specified load rlmxko_w.

Then max PR is converted to load and limits rlmxko_w.

If there are errors in EGT sensors, IAT sensor, either CTS, or oil temp, then max pressure is converted to load and limits max specified load as well.

If lde exceeds KFDLDULS for a period of time, then max specified load is also limited to LDORXN.

Finally, there's an additive for adaptation channels (lemmi).

This final max specified load, rlmax, limits the output of KFMIRL.

I've got two maps I'm thinking of changing next (LDPBN and KFLDHBN) and was wondering if they'd affect the specified load. I know KFTARX could be a factor as well but my temperatures are pretty low.

Thanks!

Lower KFLDIMX to fix boost overshoot.
Load is irrelevant at this point as it is above diagnostic limit.

It's LDPBN for sure. Stock it's 2250 across the board. This equates to a little over 18psi which would easily equate to your 191 load. I changed this to 2550 across the board

I've been told LDPBN has a slightly different meaning in med9. By definition in me7 it's max pressure under error condition or something. In med9 I think it's just max pressure.

Thanks all,

I think I've got three answers here.

1) Although the specified load value inside the ECU may indeed rise, the diagnostic protocol can only output a max value of 191.
2) Fix the boost spike by lowering KFLDIMX. I'll log the WGDC tonight and see what the steady state value converges to. I'll use that as a basis to start.
3) LDPBN. My specified boost in the logs seemed to settle around 2250, so I'll update LDPBN.

Once again, thanks for all the suggestions and replies. I could just have copied stuff but then I would not have understood what it was that I was copying :D

You changed the values in KFMIOP. Why not the axis in KFMIRL?

Hi,

The axis in KFMIRL is torque. I don’t think it you can rescale the axis past 100% since that is WOT already. You can’t get more wide open than WOT 

From the s4wiki “make sure the 100% torque request (rtlsol) row requests enough load”

So I left the axis in KFMIRL alone and changed the values in the last two rows to request more load. I changed the last two rows to ramp up smoothly.

Then I looked at KFMIOP, I changed the axis in KFMIOP to reflect the new higher numbers in KFMIRL (>202) and then recalculated the last two rows in KFMIOP so that they aligned with the new axis.

I spent ages and ages playing with linear interpolation (http://nefariousmotorsports.com/forum/index.php?topic=4919.msg49698#msg49698) in excel to fit nice curves to everything.

I probably haven’t explained very well, but this (http://nefariousmotorsports.com/forum/index.php?topic=3765.msg37834#msg37834) was pretty comprehensive.
 

I’m still struggling with that initial boost spike  :(

I’ve done some logging and the graph is below.

1)   After the initial spike, actual boost tracks requested boost very nicely
2)   Requested boost is 2350mbar and the spike reaches about 2600mbar
3)   The spike lasts for about 500 rpm (2900 rpm  – 3400 rpm)
4)   WGDC starts at 95 % before settling down around 50 %

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=8679;image)

I think I’ve misunderstood what to do with KFLDIMX.

KFLDIMX – stock

hPa / RPM		1000		1250		1500		1750		2000		2250		2500		2750		3000		3500		4000		4500		5000		5500		6000		6500
0	¦	0.0000	¦	0.0000	¦	0.0000	¦	0.0000	¦	0.0000	¦	0.0000	¦	0.0000	¦	0.0000	¦	0.0000	¦	5.0000	¦	10.0000	¦	10.0000	¦	10.0000	¦	10.0000	¦	10.0000	¦	10.0000
300	¦	19.0000	¦	19.0000	¦	19.0000	¦	19.0000	¦	19.0000	¦	19.0000	¦	16.8750	¦	15.0000	¦	14.0650	¦	17.1900	¦	21.2500	¦	21.7200	¦	22.1900	¦	23.1250	¦	25.0000	¦	26.8750
400	¦	25.3350	¦	25.3350	¦	25.3350	¦	25.3350	¦	25.3350	¦	25.3350	¦	22.5000	¦	20.0000	¦	18.7500	¦	21.2500	¦	25.0000	¦	25.6250	¦	26.2500	¦	27.5000	¦	30.0000	¦	32.5000
500	¦	31.6650	¦	31.6650	¦	31.6650	¦	31.6650	¦	31.6650	¦	31.6650	¦	28.1250	¦	25.0000	¦	23.4400	¦	25.3150	¦	28.7500	¦	29.5300	¦	30.3150	¦	31.8750	¦	35.0000	¦	38.1250
1000	¦	63.3350	¦	63.3350	¦	63.3350	¦	63.3350	¦	63.3350	¦	63.3350	¦	56.2500	¦	50.0000	¦	46.8750	¦	45.6250	¦	47.5000	¦	49.0650	¦	50.6250	¦	53.7500	¦	60.0000	¦	66.2500
1200	¦	76.0000	¦	76.0000	¦	76.0000	¦	76.0000	¦	76.0000	¦	76.0000	¦	67.5000	¦	60.0000	¦	56.2500	¦	53.7500	¦	55.0000	¦	56.8750	¦	58.7500	¦	62.5000	¦	70.0000	¦	77.5000
1500	¦	95.0000	¦	95.0000	¦	95.0000	¦	95.0000	¦	95.0000	¦	95.0000	¦	84.3750	¦	75.0000	¦	70.3150	¦	65.9400	¦	66.2500	¦	68.5950	¦	70.9400	¦	75.6250	¦	85.0000	¦	94.3750
1600	¦	95.0000	¦	95.0000	¦	95.0000	¦	95.0000	¦	95.0000	¦	95.0000	¦	90.0000	¦	80.0000	¦	75.0000	¦	70.0000	¦	70.0000	¦	72.5000	¦	75.0000	¦	80.0000	¦	90.0000	¦	95.0000

KFLDIMX – v8

hPa / RPM		1000		1250		1500		1750		2000		2250		2500		2750		3000		3500		4000		4500		5000		5500		6000		6500
0	¦	0.0000	¦	0.0000	¦	0.0000	¦	0.0000	¦	0.0000	¦	0.0000	¦	0.0000	¦	0.0000	¦	0.0000	¦	5.0000	¦	10.0000	¦	10.0000	¦	10.0000	¦	10.0000	¦	10.0000	¦	10.0000
300	¦	19.0000	¦	19.0000	¦	19.0000	¦	19.0000	¦	19.0000	¦	19.0000	¦	16.8750	¦	15.0000	¦	14.0650	¦	17.1900	¦	21.2500	¦	21.7200	¦	22.1900	¦	23.1250	¦	25.0000	¦	26.8750
400	¦	25.3350	¦	25.3350	¦	25.3350	¦	25.3350	¦	25.3350	¦	25.3350	¦	22.5000	¦	20.0000	¦	18.7500	¦	21.2500	¦	25.0000	¦	25.6250	¦	26.2500	¦	27.5000	¦	30.0000	¦	32.5000
500	¦	31.6650	¦	31.6650	¦	31.6650	¦	31.6650	¦	31.6650	¦	31.6650	¦	28.1250	¦	25.0000	¦	23.4400	¦	25.3150	¦	28.7500	¦	29.5300	¦	30.3150	¦	31.8750	¦	35.0000	¦	38.1250
1000	¦	63.3350	¦	63.3350	¦	63.3350	¦	63.3350	¦	63.3350	¦	63.3350	¦	56.2500	¦	50.0000	¦	46.8750	¦	45.6250	¦	47.5000	¦	49.0650	¦	50.6250	¦	53.7500	¦	60.0000	¦	66.2500
1200	¦	76.0000	¦	76.0000	¦	76.0000	¦	76.0000	¦	76.0000	¦	76.0000	¦	67.5000	¦	60.0000	¦	56.2500	¦	53.7500	¦	55.0000	¦	56.8750	¦	58.7500	¦	62.5000	¦	70.0000	¦	77.5000
1500	¦	95.0000	¦	95.0000	¦	95.0000	¦	95.0000	¦	95.0000	¦	76.0000	¦	67.5000	¦	60.0000	¦	56.2500	¦	56.2500	¦	66.2500	¦	68.5950	¦	70.9400	¦	75.6250	¦	85.0000	¦	94.3750
1600	¦	95.0000	¦	95.0000	¦	95.0000	¦	95.0000	¦	95.0000	¦	76.0000	¦	67.5000	¦	60.0000	¦	56.2500	¦	56.2500	¦	70.0000	¦	72.5000	¦	75.0000	¦	80.0000	¦	90.0000	¦	95.0000

In general, you want KFLDIMX to follow what you expect your WGDC to be in the steady state, so after peak boost, you should set this to where you want the WGDC to settle.

I probably haven't understood this properly.

Am I reducing it in the right place? I've reduced just a small part of it, but should I be reducing the entire row instead of just a few entries?I've also been very conservative and just made small changes. Should I be taking the whole row down to around 50? I don't have a problem when it settles down, it's just the initial spike  :-\

Nice work!

I had the best result when I logged a full throttle pull from 2250rpm to redline, then took WGDC values and more or less loaded thrm in the last row of kfldimx. I adjusted second to last row a bit to smooth out the transition. I left the values 2-3 over whqt WGDC actually was. Is rather have .5psi overshoot than undershoot!

My changes in kfldimx had to be fairly aggressive to get rid of the overshoot

Good luck!
Jordan

Thanks Jordan ;D

That’s what I’m trying to get my head around. I’ve got the log including WGDC but do I ‘load’ that like for like in KFLDIMX?

In other words, load 95% at 2000 rpm, 95% at 2500 rpm, 75% at 3000 rpm and then 50% at 3500 rpm, 50% at 4000 rpm, 50% at 5000 rpm and so on.

Or is it more a question of 50% at 2000 rpm, 50% at 2500 rpm, 50% at 3000 rpm, 50% at 4000 rpm  ???

I’m going to try reducing the 95% values (1000 rpm – 2000 rpm) but I’m guessing and would like to understand a bit more.

KFLDIMX should not be "loaded" with WGDC values, this is not correct.
It is I-limitation. Before it goes out as ldtvm, it gets looked up through KFLDRL via ldtv and nmot.
 
So if you want to backtrack the values, then you have to do a reverse lookup through KFLDRL.
That said, you guys are having issues with basic stuff that carries over from ME7.

The whole huge pain tuning MED9 comes from the high pressure fuel system, if you want to make proper power you can't leave all that stuff stock.

I really don't follow you here.

From NefMoto Wiki:

This would indicate that the values in KFLDIMX represent where you expect WGDC to settle once request meets actual.   The factory has KFLDIMX tuned in a way that allows (even promotes) overshoot.  I don't see how KFLDRL relates.  KFLDRL is a representation of how a specific model of turbo will act, no? It's not something you'd want to calibrate on an unchanged turbo, right??

Thanks
-Jordan

ALL LDR GOES THROUGH KFLDRL!

I understand that, but it doesn't mean KFLDIMX is right from the factory and it definetely doesn't work for increased boost. I get it, you can't just log WGDC and plug it in to KFLDIMX. Tommorow I'm going to look at KFLDRL and adjust my logged WGDC values based on what they would be in KFLDIMX if they weren't  impacted by KFLDRL. I'll bet you the factory isn't even close.

You may need more Q2.. you should see a short dip in wgdc to slow the boost ramp so it doesn't overshoot.

Hi all,

Thanks for the responses. I’ve been looking into this a lot and it’s really interesting to see what you are saying.

I’m sure you guys will recognize this :D

http://nefariousmotorsports.com/forum/index.php?topic=2985.msg29152#msg29152
http://nefariousmotorsports.com/forum/index.php?topic=517.msg3902#msg3902

Rightly or wrongly, here’s my observations. Comments welcomed !

Steady State (by this I mean actual matches, or is extremely close to, specified)

1)   The output of the PID controller is the sum of P, I and D . The error (difference between actual and specified) in the steady state is zero, meaning actual matches specified and the PID doesn’t need to adjust anything. Since the error is zero, the contribution to the PID from P is zero as well. But if all the contributions (P, I & D) are zero then the output of the PID is zero as well. Clearly we need the output to be more than zero otherwise we’ll have zero WGDC and no actual boost. So even in the steady state, although the contribution from P is zero the contribution from I is NOT zero, in fact it should be the exact amount to ensure enough WGDC so that error is zero, actual matches specified and the PID has very little to control.

2)   The I component is an accumulation over time, from when the loop started to the present time. We want to regulate this so it doesn’t just get bigger and bigger, leading to a larger output in the steady state, in turn leading to more WGDC, actual diverging from specified, error increasing and the PID has its work cut out to balance this.

So in the steady state I believe KFLDIMX stops I from getting bigger and bigger and also sets a sensible value for I, so that the PID does fine rather than coarse adjustments.

Initial Ramp-up
I don’t think I have an issue in the steady state. My actual tracks specified and doesn’t oscillate around it. My issue here is that initial overshoot. In the ramp-up the error is large and P, I and D will all contribute to the output of the PID. Maybe I’m looking at the wrong area of KFLDIMX and should be looking right on the left of the map, before I get to the rpm range where steady state is?

I’ll also define KFLDRL and take a look.

Ah, just looked at the picture. That's a nice set of curves lol. That's what I want to achieve. Q2 would be the differential component right?

Factory want a boost spike. Boost spike is good, it gives midrange punch and overtaking ability in a 4wd car

Rick

Excellent summary. I have simplified things in the s4wiki to make the PID easier to understand for novices, but you clearly have enough of a good idea for me to explain this a bit further.

In reality, properly functioning PIDs shouldn't actually operate at the I-Limit in steady state... like you said, it is more like a "sane" limit. Many conventional PID controllers actually depend on overshoot to bring I back into control under the I-Limit:

https://controls.engin.umich.edu/wiki/index.php/PIDDownsides#Windup
http://en.wikipedia.org/wiki/Integral_windup

Now, I dont pretend to understand what the ME designers intended with the I-limit in their PID, but if you log a stock car, you might notice that by and large, they do not run at the I-limit - they generally have some overshoot which brings I back down a tad so it can move again. Now keep in mind, that stock, they have a ton of pressure sensor overhead available, so there is a lot of room for negative I contributions.

In the 2.7t, we are all running near the pressure sensor limit (unless we're running the MAP hack), so there can NEVER be very much negative I contribution! So my solution is to never let the boost overshoot, and rather let windup let me run at the I-limit so it is somewhat "open loop" behavior in steady state.

YMMV. My approach may not be the right one, but from experience, its the only way I can get reasonable results w/o going completely open loop through numbing DRL.

I hope this makes sense!

The NefMoto Wiki is wrong. The FR is right.
Very easy. I have said it many times - do not read what someones interpretation of the documents is, read the documents.
Else it is just like usual forum cr*p. Someone says something and everyone repeats like sheep, even though it has little to do with reality.

Read LDRPID in the FR with an open mind. Forget everything you read everywhere else, most of the stuff people write on wikis and forums is just their interpretation of things, it can be wrong, omit details etc. Why rely on it when you have the functional document of the ECU telling you exactly how things are?

Also, if german's not your thing, Gonzo alerted me to this.

http://www.google.nl/patents/US6918250

1) The FR does not mention methods for tuning the PID near the MAP limit.

2) The FR does not mention that the setpoint can exceed the MAP limit due to a design flaw in ME7.

3) The purpose of wikis and discussion boards are to discuss things, and to (collaboratively) come up with interpretations (for forming consensus) of existing documents whose authors are unlikely to be around to answer questions, fix errors, address limitations, or clear up misunderstandings.

If you truly think there is nothing of value outside the FR, then what is the point of any discussion of anything?

Thanks all,

Without the resources and help from this forum, I’d be stuck. I appreciate all the points of view.

I have answered one of my own questions. Referring to the logs and graphs, I always wondered why I still had 95% WGDC at 2500 rpm, even though the value in KFLDIMX was 56% at 2500 rpm. Simplistically why didn’t WGDC match KFLDIMX? Why weren’t my changes having much effect? I now understand that since the error (difference between actual and specified) was still large at 2500 rpm, not only did I have the I component (albeit limited to the value in KFLDIMX) but also the P component and D component all added together to produce the output.  KFLDIMX is just the limit of the I component.

After digesting all of this, I’m not even sure I want to eliminate the initial overshoot. The loop is nice and responsive as it is. However, since I’ve put this much effort into understanding it, I’d like to see it through since I can always change it back.

I will reduce KFLDIMX further and log the results and also try increasing KFLDRQ2 and log the results.


Even in english, it's still heavy going  :) Nice link.



Thanks you! The description about integral windup complimented the rest of the control theory I'm been looking through.

Pretty much the normal method applies, all you have to do is go really aggressive on the I-limiting.
That said, you should not run PID at MAP limit if at all avoidable.
I don't think there is nothing of value outside the FR. I think that one should at the very least read both the FR (at least the schematics) and the forum.

Finally!

It’s responding as expected :D

If you recall, I was targeting the initial overshoot. I lowered the values in KFLDIMX in the region of the initial ramp-up (decreased them a lot, but after all this I now understand why) and WGDC now tapers off a lot more as actual boost approaches requested boost.

Attached are the before and after comparisons. It’s the size of the initial boost overshoot that has diminished.

KFLDIMX – stock

hPa / RPM		1000		1250		1500		1750		2000		2250		2500		2750		3000		3500		4000		4500		5000		5500		6000		6500
0	¦	0.0000	¦	0.0000	¦	0.0000	¦	0.0000	¦	0.0000	¦	0.0000	¦	0.0000	¦	0.0000	¦	0.0000	¦	5.0000	¦	10.0000	¦	10.0000	¦	10.0000	¦	10.0000	¦	10.0000	¦	10.0000
300	¦	19.0000	¦	19.0000	¦	19.0000	¦	19.0000	¦	19.0000	¦	19.0000	¦	16.8750	¦	15.0000	¦	14.0650	¦	17.1900	¦	21.2500	¦	21.7200	¦	22.1900	¦	23.1250	¦	25.0000	¦	26.8750
400	¦	25.3350	¦	25.3350	¦	25.3350	¦	25.3350	¦	25.3350	¦	25.3350	¦	22.5000	¦	20.0000	¦	18.7500	¦	21.2500	¦	25.0000	¦	25.6250	¦	26.2500	¦	27.5000	¦	30.0000	¦	32.5000
500	¦	31.6650	¦	31.6650	¦	31.6650	¦	31.6650	¦	31.6650	¦	31.6650	¦	28.1250	¦	25.0000	¦	23.4400	¦	25.3150	¦	28.7500	¦	29.5300	¦	30.3150	¦	31.8750	¦	35.0000	¦	38.1250
1000	¦	63.3350	¦	63.3350	¦	63.3350	¦	63.3350	¦	63.3350	¦	63.3350	¦	56.2500	¦	50.0000	¦	46.8750	¦	45.6250	¦	47.5000	¦	49.0650	¦	50.6250	¦	53.7500	¦	60.0000	¦	66.2500
1200	¦	76.0000	¦	76.0000	¦	76.0000	¦	76.0000	¦	76.0000	¦	76.0000	¦	67.5000	¦	60.0000	¦	56.2500	¦	53.7500	¦	55.0000	¦	56.8750	¦	58.7500	¦	62.5000	¦	70.0000	¦	77.5000
1500	¦	95.0000	¦	95.0000	¦	95.0000	¦	95.0000	¦	95.0000	¦	95.0000	¦	84.3750	¦	75.0000	¦	70.3150	¦	65.9400	¦	66.2500	¦	68.5950	¦	70.9400	¦	75.6250	¦	85.0000	¦	94.3750
1600	¦	95.0000	¦	95.0000	¦	95.0000	¦	95.0000	¦	95.0000	¦	95.0000	¦	90.0000	¦	80.0000	¦	75.0000	¦	70.0000	¦	70.0000	¦	72.5000	¦	75.0000	¦	80.0000	¦	90.0000	¦	95.0000

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=8704;image)

KFLDIMX – v10

hPa / RPM		1000		1250		1500		1750		2000		2250		2500		2750		3000		3500		4000		4500		5000		5500		6000		6500
0	¦	0.0000	¦	0.0000	¦	0.0000	¦	0.0000	¦	0.0000	¦	0.0000	¦	0.0000	¦	0.0000	¦	0.0000	¦	5.0000	¦	10.0000	¦	10.0000	¦	10.0000	¦	10.0000	¦	10.0000	¦	10.0000
300	¦	19.0000	¦	19.0000	¦	19.0000	¦	19.0000	¦	19.0000	¦	19.0000	¦	16.8750	¦	15.0000	¦	14.0650	¦	17.1900	¦	21.2500	¦	21.7200	¦	22.1900	¦	23.1250	¦	25.0000	¦	26.8750
400	¦	25.3350	¦	25.3350	¦	25.3350	¦	25.3350	¦	25.3350	¦	25.3350	¦	22.5000	¦	20.0000	¦	18.7500	¦	21.2500	¦	25.0000	¦	25.6250	¦	26.2500	¦	27.5000	¦	30.0000	¦	32.5000
500	¦	31.6650	¦	31.6650	¦	31.6650	¦	31.6650	¦	31.6650	¦	31.6650	¦	28.1250	¦	25.0000	¦	23.4400	¦	25.3150	¦	28.7500	¦	29.5300	¦	30.3150	¦	31.8750	¦	35.0000	¦	38.1250
1000	¦	63.3350	¦	63.3350	¦	63.3350	¦	63.3350	¦	63.3350	¦	63.3350	¦	56.2500	¦	50.0000	¦	46.8750	¦	45.6250	¦	47.5000	¦	49.0650	¦	50.6250	¦	53.7500	¦	60.0000	¦	66.2500
1200	¦	76.0000	¦	76.0000	¦	76.0000	¦	76.0000	¦	76.0000	¦	63.3350	¦	56.2500	¦	56.2500	¦	56.2500	¦	53.7500	¦	55.0000	¦	56.8750	¦	58.7500	¦	62.5000	¦	70.0000	¦	77.5000
1500	¦	95.0000	¦	95.0000	¦	95.0000	¦	95.0000	¦	95.0000	¦	63.3350	¦	56.2500	¦	40.0000	¦	40.0000	¦	56.2500	¦	66.2500	¦	68.5950	¦	70.9400	¦	75.6250	¦	85.0000	¦	94.3750
1600	¦	95.0000	¦	95.0000	¦	95.0000	¦	95.0000	¦	95.0000	¦	63.3350	¦	56.2500	¦	40.0000	¦	40.0000	¦	56.2500	¦	70.0000	¦	72.5000	¦	75.0000	¦	80.0000	¦	90.0000	¦	95.0000

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=8706;image)


Thank you, exactly right.

Initially I wasn’t sure how aggressive the changes should be but after working through this with all of you, I understand what I’m changing and why it’s had this result.

I’m going to hold off tweaking the derivative. I’m really happy with this and I don’t actually want to dampen the response any further!

IMO your approach is not a good one, it only works if you are trying to kill overshoot in one specific rpm range. Don't believe me? Delay the start of your run rpm wise and see what happens when your boost peak is at 4 or 5k rpm

You need more Q2. The i limit should remain more or less rpm independent. You can tune DRL to compensate for any extra DC you need as flow/rpm go up.

Q0 is for transient response, Q1 is long term, Q2 is for pre-emptive transient response.

Do not use Q0/Q1 for doing Q2's job.

Hmmmm, I was pondering that.

Yes, I had just been looking at one scenario - a WOT pull from low down. I tried a few additional runs and went WOT at different starting rpm points (2000 rpm, 3000 rpm, 4000rpm etc)

Initial overshoot did increase (compared to the 2000 rpm point where I'd been focusing) as I moved to different starting points in the rev range.

WOT at 2500 RPM

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=8713;image)

WOT at 4000 RPM

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=8715;image)

But I'd say that very roughly, the biggest initial overshoot was low down and whilst initial overshoot still occurs higher up, it's not quite as large. Maybe. I could be fooling myself ??? I originally saw a peak boost of 2650 mbar when I went WOT at 2000 rpm and peak of 2500 mbar when I went WOT at 4000 rpm. Specified was 2350 mbar.

I did look at Q2 and likewise it's spread across the rpm range. So each point in the rpm range would need to be addressed. That's quite a task  :(

Still a bit hung up on this.

If KFLDIMX specifies the 'steady state' values, at what point is the system considered 'steady state'  :(

I actually did have a go at looking at the FR.

There are basically two distinct operating modes:

1. !B_lddy: Quasi steady-state operation with PI control which gives a relatively weak control action. Derivation of the control parameters is carried out via oscillation testing on an engine dynamometer using the Ziegler-Nichols tuning method.

2. B_lddy: Dynamic performance with PID control which gives a strong control action. Derivation of the control parameters is carried out via oscillation testing on an engine dynamometer.
 
These operating states are distinguished via the control error, i.e., a positive deviation above a threshold activates the dynamic control intervention and it is only withdrawn when the deviation changes sign (i.e. the actual value exceeds desired value). The transient is managed with the aim of not causing overshoot over the entire region in the quasi steady-state mode.
 

So if quasi steady state is only entered when actual exceeds desired, does that mean KFLDIMX (steady state) is only referred to when actual exceeds desired i.e overshoot ??? And yet changing KFLDIMX seems to affect the WGDC before the overshoot occurs?

My usage of "steady state" is for the general PID context, not FR or ME specific.

IIRC steady state is when lde < UMDYLDR

noob question, how did you scale the axis in KFMIOP?

That is "static" vs "dynamic"... also there is a hysteresis filter which prevents it from bouncing around (iirc 10 to UMDYLDR)

ME7.1 Mbox specific:

Yes exactly, D drops to zero and P drops to 2% when B_lddy is clear. This is "steady state" and I is the main control.

B_lddy is cleared if lde == 0 and set if lde > UMDYLDR.

Agreed, except I think its lde<10, not lde==0

In any case, just trying to clarify my usage of "steady state", which is for ALL conventional PIDs, including simple ones that do not have parameterized co-efficients.... that is to say, even w/o a case that explicitly turns off the D and/or P components, steady state is defined as when lde is at (or near) zero, and no longer changing, such that P and D are zero *even if they have non zero co-efficients!*

The factor for lde is 10, so lde < 10 and lde == 0 is equivalent.

I was going off the code.

Whoa, interesting!

Thank you for the clarification. Another reason to be wary about reading the FR :/

If in doubt, disassemble :(

Hi guys,

I’ve been pretty quiet for a while and haven’t really done very much more than what I’ve posted. In fact, the car is actually back to stock since it went in for a service at the main dealer and I swapped from my modified ECU back to the original unmodified ECU (no problems encountered, just unplugged, swapped and cleared any fault codes).

However, I’ve been able to spend some more time on this over the last two weeks. Using IDA and the FR, I think I’ve located the following ram variables:

0x7FD71C   pvdkds_w   BoostPressureActual
0x80255C   plsol_w   BoostPressureSpecified
0x7FD830   nmot_w   EngineSpeed
0x7FEE58   rl_w      EngineLoad
0x80252E   rlmx_w      EngineLoadSpecified
0x802554   ldtv_w      WastegateDutyCycle
0x80254E   ldrkp_w   LDR-control parameter for P component
0x80254A   ldrkd_w   LDR-control parameter for D component
0x80254C   ldrki_w      LDR-control parameter for I component
0x802546   ldptv_w   LDR, duty cycle from the P controller
0x802548   ldrdtv_w   LDR, duty cycle from the D controller
0x802544   lditv_w      LDR, duty cycle from the I controller
0x80253A   ldimn      Current value for the minimum value limit I component LDR
0x802542   ldimx      Current value for the maximum value limit I component LDR

Now even with the stock ECU, there is an initial boost overshoot as you can see in the graph.

(Sorry about the graph, I know it’s a very busy picture with a lot going on. RPM and Boost on left axis, P, I & D on right axis)

Also in the graph I’ve logged ldptv_w, ldrdtv_w and lditv_w. I wanted to see how the P, I and D components contribute.

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=9007;image)

Previously in this thread I’ve targeted KFLDIMX to clamp down on the initial overshoot. I think this is a bit unwieldy since I’m basically then running at the I limit?

What I’m going to try now is the Derivative component. In the graph I can see how it increases (gets more negative) until it reaches its most negative value just before the actual boost exceeds the specified boost. I propose to increase this so it’s larger (gets even more negative).

To accommodate the whole rpm range, I’m thinking of copying the entire row of values in KFLDRQ2 from row hPa=100 to row hPa=200 and then using new values in row hPa=100 (their value would be row hPa=200 plus 20%). Make any  sense?

As always, comments appreciated!

Yes. Adjust Q2.

Also consider using ECUxPlot.

Hello guys,

I’ve increased Q2 and logged again. Initial overshoot is still there.

ECUxPlot is a very nice utility! Very impressive :)

To keep it simple, here is just the P, I and D contributions and the WGDC.

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=9019;image)

From what I can make out, the WGDC does indeed drop off as actual boost approaches specified boost due to the negative contribution of Q2 (WGDC = I – D) So far, so good.

However, once actual boost exceeds specified boost, then D is switched off and no longer lends its negative contribution to the equation (WGDC = I only) and the WGDC shoots up again before gradually ramping down. At this point, I can see why reducing KFLDIMX would reduce the WGDC - you're limiting the I.

Bit puzzled on what to try next ??? Larger negative contribution from D (increase Q2)? Or limit the I contribution (by reducing KFLDIMX)? Perhaps a mixture of the two  :-\

As an aside, I’ve noticed that actual pressure pvdkds_w maxes out at 2560 mbar. This is using my ram logger to log. But when I used VCDS to log, I got readings for actual pressure of 2620 mbar. What variable is VCDS looking at if pvdkds_w is maxed at 2560 mbar?

Nope, you've got it right! pull imx down till it is closer to what you want your steady state I to be.

Also, you might want to change your X axis to rpm when plotting.

Hi nyet,

Thank you. I appreciate you sticking with this through the five pages of this thread ;) I think I’m moving in the right direction now. KFLDIMX is decreased (I copied the values at row hPa = 1000 to rows hPa = 1200 and hPa = 1500) and I think it looks a lot better. In summary:

1)   I’m using a file where I’ve already increased LDRXN, KFMIRL, KFMIOP and LDPBN.
2)   Originally my initial boost overshoot was hitting (and passing) the limit of 2560 mbar in pvdkds_w. With these latest changes to KFLDIMX and KFLDRQ2 I don’t spike through the limit anymore  ;D
3)   I logged a drive where I go WOT at 2000rpm, 3000rpm and 4000rpm. I wanted to check that I hadn’t just ironed out one place in the rpm range (like I did a few pages ago). I think it looks OK!
4)   Picture and log attached. The log includes all the variables (P, I, D, WGDC etc) but I've only shown rpm, actual boost and specified boost on the picture to keep it simple. I used time on the x-axis for this particular picture since using rpm made it look very strange indeed  :o
5)   Bin also attached for those curious.

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=9025)

again if you use rpm as xaxis you can overlay those runs, but it has to be labled "EngineSpeed"
you'll have to use the proper aliases so ecuxplot knows which is which. see the ME7L aliases file for more info (defs/me7_alias.map)

in any case, you'll want rpm as x axis because when tuning you generally need to know rpm.

If stuff doesn't look right, you need to use the filter properly (log pedal position and throttle plate angle, and possibly gear), and make sure you have the right aliases so ecuxplot knows what to look for.

Also, that is still quite a bit of overboost...

I reduced KFLDIMX even further. In fact, at one point I had it so low that actual was not meeting specified so I increased it a bit.

How’s this one? WOT pull from 2000rpm. Actual boost overshoots specified boost by 67mbar maximum.

Got some other observations I will post up once I've got them clear in my mind :-\

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=9041)

VERY NICE work sir!

D might be a bit agressive now, it is coming on a bit early... might want to delay it a bit since you have a bit of undershoot.. but imo that is safe, and actually makes for a better track car.

if you want max accel (best fats or strip ET), you might want a bit of overshoot initially..

Thank you very much, but it's your help that got me here!

I wish there was a utility like ME7Logger for MED9.1 (perhaps MED9Logger?) Manually digging out the ram variables (with my pitiful knowledge of PowerPC assembly) is really time consuming :( I then have to add them to my home made ram logger (which I have to recompile everytime I change something and I hardcoded the memory addresses...) and massage the output into something that looks like a csv. You get the idea, it's a pain.

I'd really like to try some of the other features of ECUxPlot - Compressor Map intrigued me! What variables could I log to see the output of that?

I had to be really agressive with my changes to KFLDIMX. In fact, I honestly don't know how the factory set it up to begin with. My car certainly had an overshoot even with the stock map. I'd be interested to hear from anyone else with the 2.0 TFSI 265bhp engine about what their experience has been?

On one of my iterations of KFLDIMX, I had the values so low that actual boost never exceeded specified boost. It got very close, but never crossed over. In this scenario I noticed that D never switched off.


What is fats or strip ET ??? You'd be suprised what google thought it might be, but somehow I don't think that's what you meant ;)

I'll look at the undershoot. Likely I can adjust that by setting the penultimate row of KFLDRQ2 back to stock, leaving the changes in just the last row.

Much appreciated!

Sounds like your program just needs a bit of UI polish, where you can feed it something like the ME7L definition files.. :)


IIRC you just need boost pressure and MAF


Heh. sorry.

FATS is a 2.7t term for time to from 4200 to 6500 RPMs in 3rd gear. Generally used to compare 6sp s4s to each other. every non-s4 6sp tranny is different, of course, so it isn't a useful benchmark to compare differing cars.

strip ET is "1/4 mile drag strip elapsed time"

Does anyone know how setzi's logger parses the ram addresses?

Hello all,

I’d really appreciate your opinions and advice on MED9.1 fuelling.

I’ve logged these values and graphed them for your pleasure in ECUxPlot ;D

lamsoni_w (AirFuelRatioCurrent)
lamsbg_w (AirFuelRatioDesired)
lambts_w (LambdaPartProtection)
lamfa_w (TargetAFRDriverRequest)

I can see that Desired AFR starts by following Driver Requested AFR and then switches to follow Part Protection AFR. Actual AFR tracks Desired AFR closely. That’s very clear in the log. If anyone thinks it’ll help, I could also try and pull out DLAMBTS to get the Knock AFR contribution?

What I’d like to understand is just how rich is rich? I’m touching values of 0.71 at the end of the WOT pull. Should I be trying to go a bit leaner? I know my fuelling at this point is BTS fuelling and whilst I don’t want to melt anything, does it need to be this rich ???

Log attached (containing boost, load, EGT, fuelling, MAF etc. No Timing (yet) since I still have to dig out those ram locations). I’ve only shown fuelling in the graph, but the rest is all there in case you are curious enough to look at EGT and the like.

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=9126)

As always, comments much appreciated

sorry for the offtopic  but how did you manage to log these variables on a MED9 ? !?  ???

+1 !

I run 11.5 (0.78) from boost peak to redline using LAMFA.

That is really super duper rich and you will loose quite a bit of power with that. Why so rich? To prevent knock? Retard ignition then. To decrease EGT? Re-think your hardware setup if it is running really hot.  ;)

Are u using lamfa on med9.1? It seems the BTS threshold is very low on med9.1, so I guess you'd need to raise the bts threshold to get it to use lamfa, right?

On ME7 the stock BTS is very very rich at high load points because on a stock tune, those load areas should never be reached. I imagine the same is true of the stock MED9 BTS map(s)

I agree. MED9 seems to switch to BTS fuelling much faster than ME7.


True. MED9 BTS maps looks much like ME7.

Hi guys. I am using a RAM logger to log. If you are curious, you can follow the progress on this  thread (http://nefariousmotorsports.com/forum/index.php?topic=271.msg54019#msg54019) :)

I use an Arduino and a sparkfun CAN-BUS Shield for the hardware (pretty cheap). The software is an implementation of VW TP2.0 and KWP2000 I put together myself.

Still a work in progress, but it lets me log a bit more than VCDS. Having said that, you still need to manually pull out the ram locations you are interested in by going through the FR and disassembling in IDA to find those locations. That takes quite a while.

Thanks for the comments on the AFR!

Since this is the first time I've tuned anything, perhaps I could start gently by working on the BTS maps? I'm keen to retain the component protection since I really don't want to melt anything!

I could certainly try modifying KFLBTS and KFLBTSLBK0 in the high load areas and keep an eye on the EGT. However, should I be modifying these BTS maps directly or rather modifying some other variable that multiples the output of the BTS maps? Working my way through the FR, but would certainly benefit from your suggestions.

Sorry, I should have mentioned the setup as well:

Audi S3 8P 2.0 TFSI MY2008 manual, UK spec
Hardware is totally stock
Only maps I've changed so far are LDRXN, KFMIRL/KFMIOP, LDPBN, KFLDIMX and KFLDRQ2 (not very exciting, but I learnt a lot). All this has done is rasied the boost to around 2400mbar absolute (and at least it stays there without spiking!!)

I want to take it a bit further now, hence my interest in fuelling (and timing).

now idk if this is the "correct" way, but i modified the KFLBTSLBK0 and KFFDLBTS to get my afr where i want it

Thanks

I haven’t spent much more time on this but did adjust the fuelling somewhat:

1)   Set the maximum row of LAMFA to 0.8 across the board.
2)   KFLBTS and KFLBTSLBKO. Increased the last few cells of the maximum row slightly.

I’m sure it can be improved but it’s not as rich as previously.

I also retarded the timing (KFZW / KFZW2) somewhat as I’m running on plain old pump fuel. I’d like to take this down a bit further since CF’s are around -1.5 to -3 and I could probably do a bit better.

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=9257)

Help

I’m really struggling with rlsol_w which keeps dropping down.

I’d noticed that plsol_w (Specified Boost) kept dropping off. Originally I thought that plsol_w was being corrected by something in the LDRLMX path, so I logged plxs_w and saw that it was unaffected. Hmmm ??? Next I checked pssol_w and observed that it was dropping off as well. Now if I’m reading the FR correctly (looking at the lines that join the little blocks in the pictures lol) then rlsol_w -> pssol_w. Sure enough, logging rlsol_w showed that it was also tailing off.

rlmax_w is unaffected.

What could be affecting rlsol_w? Frustratingly, it’s not always consistent either. Sometimes it’s really apparent, sometime not  :(

Searching on rlsol_w returned some topics about KFMIRL/KFMIOP interactions but I haven't looked further into this. I am probably right at the top of these tables now since I raised LDRXN slightly as well.

Log attached.

Any ideas?

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=9260)

If it is anything like ME7.1, maxing ps_w will cause problems.

Not with desired load though.

I'm not familiar with MED9, but perhaps it is the load request from KFMIRL?

Good point. Is there a KFTARX equiv in MED9?

Yes, there is :)

Start with:

KFTARX, KFLDHBN, LDPBN, KFMIOP.

There is no problem with rlmax_w, so I think that all of those desired load limiters can be skipped.

It is either the torque request into KFMIRL or the load request out of it.

Log the input and output of KFMIRL.

LDPBN is pressure limit at engine temp
KFLDHBN is max pressure ratio

it could be?

I agree with this.

Thanks all,

I tried another iteration of KFMIRL/KFMIOP where I increased the values at the top of the range in KFMIRL (and adjusted the axis and values in KFMIOP accordingly). If anything, this resulted in even more limitation in rlsol_w, but I can’t say for definite yet and I’m just guessing. I’ll need a few more logs before I can see any definite trend.


Definitely. I think this is the most pertinent thing to log now.

For those curious, this is how I interpreted the FR:

Section FU LDRLMX 8.101.0 Berechnung LDR Maximalfuellung rlmax describes how maps like LDPBN, KFTARX etc are summed together. So rather than pick through each individual map, look at the output of the whole section. If that’s not limiting, then the individual maps aren’t limiting either. The output of the whole section is plxs_w (which in turn leads to rlmax_w in FU BGRLMXS 7.10.0 Berechnung der Maximalen Sollfüllung)

Maps in LDRLMX 8.101.0
LDORXNHDR
FKPBKISTHD
KFLDHBN
LDPBN
LDORXN
KFFLLDE
KFFWLLDE
KFFLDEO
KFFSLDE
LDRXN
LDRXNZK
KFTARX
KFTARXZK
KFTARXB

Put simply, if rlmax_w isn’t limited, then all the above maps are OK.

Log mifa_w, rlmx_w, rlmax_w

Hi all,

I logged the input and output of KFMIRL and can confirm that the input is being capped (and so the output is correspondingly capped as well). It took quite a while to find the right things to log - I don't know what it's like on ME7, but on MED9 I found that KFMIRL is re-used in the assembly code for several different modes of operation (homogeneous, homogeneous-lean, homogeneous split, stratified injection, catalytic converter heating) and each mode has it's own variables for input and output that it uses to call KFMIRL with.

Anyway, it's homogeneous mode.

By luck more than anything, I managed to get a log that contains a WOT pull without the problem and another WOT pull with the problem. Both in the same trip down the road, just a couple of minutes apart. I honestly can't see what's different ???


Here you go. mifa_w, rlmax_w and rlmx_w are fine, but pssol_w suffers from correction on the second pull.

First pull - no correction

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=9273;image)

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=9275;image)

Second pull - pssol_w being limited

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=9277;image)

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=9279;image)

So now rlmax is being limited?

Wasn't the problem yesterday intervention on rlsol only?

Aaargh, my mistake!

I got the the column names mixed up in my CSV files I was using for ECUxPlot  :-[

It's still the same as yesterday. rlsol_w is being capped, rlmax_w is fine.

I've updated the post and graphs accordingly.

Thanks for spotting it ;)

BTW - what is the relevance of mifa_w? Does it provide any clues?

Mifa is the torque request.

If mifa is greater than milsol (MED9?) then you have slow path torque intervention.

The limiting is due to to EGT model.

Rick

Thanks

I've logged and traced back as far as misol_w and ruled out miszull_w as well, which only leaves milsolv_w.

misol_w (and therefore milsolv_w) are being limited. mifa_w is not limited.

But for the life of me, I'm stuck to see how the EGT model connects here ??? I'd be very grateful if you could explain a bit more. Does the EGT model set a variable that is then referenced by milsolv_w?

I think I saw in the FR how these variables affect milsolv_w, but I didn't see EGT?

migsl_w      Interior nominal engine torque to fuel limitation in GSf
miasrl_w   Indexed desired engine torque ASR for slow intervention
miges_w      Indexed nominal motor torque for transmission protection
mivmx_w      Indexed nominal torque of the VMAX control
mibgrl_w   indexed to-moment by moment limiting air path
minmxl_w   indexed set torque for NMAX limit for air adaptation


Much appreciated

you figure this out yet?? I'm having the same issueissue. found that mdgat is the model, but no idea how that's used to limit requested boost. found limiting torque, but wouldn't that be load?

Ooh, good shout.

Just took a quick peep at that section in the FR - FU MDBGRMOT 1.60.0 Motorspezifische Momentenbegrenzungen

It describes a number of limitations:

miatbgr_w limitation due to high exhaust gas temperature
mitmbgr_w limitation dependent on engine temperature
mihdpbgr_w limitation due to low rail pressure at low temperatures
plus a few others

Then they all get added together to produce mibgrl_w (indexed to-moment by moment limiting air path) which is the output of the whole section and links very neatly to my post of how far I'd gotten.


rlsol_w -> pssol_w

There's a little diagram in FU BGMSDKS 3.40.4 Berechnung Sollmassenstrom ¨uber Drosselklappe which shows load in and pressure out. Rightly or wrongly, this is the only place pssol_w is set and thus I've assumed how load is connected to pressure. When rlsol_w is limited, so is pssol_w

Hi guys,

A puzzle and interesting answer.

I’ve been looking into the fuelling at the moment and working with these maps.

KFPRSOLHKS
KFPRSOLHMM
KFPRSOLHOM
KFPRSOLKH
KFPRSOSCH

KLPRMAX

Even though the rail maps (KFPRSOLxxx) have been increased a bit and the rail pressure limit (KLPRMAX ) increased as well, my specified rail pressure (prsoll_w) never seemed to rise to its full potential ??? Here are two logs from the same drive, a few minutes apart:

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=9397)

Specified rail pressure is the green line. The first (solid lines in the plot) is a good one, specified rail pressure is reasonable and actual lambda follows requested lambda. The second (dotted lines in the plot) is not so good. Actual lambda struggles to keep up with specified lambda. Bu this time specified rail pressure was lower as well. Now I’m hardly an expert, but surely if specified rail pressure was higher, then actual rail pressure would be higher as well and then actual lambda may be able to keep up with specified lambda? So I started digging into specified rail pressure.

Months ago, when I first began, I built a spare ECU to use for all these mods. I didn't want to open my original ECU to BDM-read it, instead I read my original flash via ODB (obviously only the flash). I then combined the flash of my original ecu with the e2p from the ebay donor ECU, immo-off'd the flash and e2p and wrote them both to the spare ECU with BDM.

I checked the coding, but I never thought to do any adaptations...

Fast forward to now and I've learnt that all the adaptations  and other non-volatile variables, are stored in the e2p. I don't know why I didn't think about this before :-[ So I did all the adaptations (throttle body, fuel pump and intake manifold runner) described in the VCDS wiki - http://wiki.ross-tech.com/wiki/index.php/2.0l_TFSI_(AXX/BGB/BPJ/BPY/BWA) and  I also cleared the fault codes which resets the LTFT and STFT.

You can see the difference in the graph. The green line is the specified rail pressure (prsoll_w).

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=9399)

P.S. One of the coil packs died during the last run, so I need to fix that before any more fun. But's that's a story for another day  :)

KLLFPRSG
FNGPRS

well i think i figured out the limiting pressure deal for my car. i was doing my fueling through the BTS maps, and i guess that will somehow limit the requested boost. so i changed those back to stock, and have been adjusting the LAMFA map to try and stay out of the BTS via EGT. it seems to be working better, but at the higher rpm i think bts is still intervening. could just be the stock hpfp dip sending it into BTS, but idk.  i also changed a little in the I-limit map too.

Hello Team Nefmoto,

If anyone has an idle moment, have a peep at my little puzzle below :D

I haven’t done anything new on my tune in ages, but I had some time recently and was looking through some of my logs when I spotted this one.

Very straightforward, I'm sure. Actual Boost diverging from Requested Boost.

This is where my lack of experience lets me down :(

Have a look at the area I've circled in green on the plot. What could be causing this divergence from around 5000rpm onwards?

1) Some kind of thermodynamic limit? Is my K04 turning into a big hairdryer?
2) Perhaps the wastegate actuator spring? Could the gas flowing through the turbo be forcing open the wastegate against the spring?
3) I didn't think it was the wastegate duty cycle since this is going in the right direction (upwards). Note that it's duty cycle before linearization in the picture. Sorry, forgot to log post linearization  :-[
4) Something daft I've overlooked...

Curious to hear your opinions  ;D

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=9854)

What's your I-limit look like?

If boost drops off that badly even while increasing DC, i'd say your linearization needs to be a lot more aggressive (assuming this isn't a wastegate problem).

Hi dd,

Do you mean KFLDIMX i.e. what I've set the map to?  Or is there another variable/s I could be logging specifically for that (I-limit)?

I can have a go at logging these, if that's what you're refering to:

ldimn_w
ldimx_w         
ldrki_w         
lditv_w         

Hi nyet,

KFLDRL?

I haven't touched that one yet on the assumption that since I hadn't changed any hardware (turbo or wastegate), the factory values were a good starting point.

Maybe that wasn't such a good assumption!

ldtv is post linearization.

What does ldimxak_w look like?

That notch in DC at the end of the run looks like a changing adaptation range.

Post ldimxr, ldimxak, ldimx, lditv, ldptv, and ldtvr.

Does it always underboost like that?

yep. For a given pre-lin DC, boost should be flat (e.g. post-lin DC rising, in your case). this is completely independent of I max etc! one thing at a time..


I don't know that the behavior you are seeing is expected... so i'd hate to tell you it is a software issue.

Aaargh, my mistake. You are absolutely correct, ldtv_w is definitely post lin! That'll teach me to concerntrate.


Yes, it's very consistent like that. Well-behaved underboosting!

I added some more variables from LDRPID (including all you mentioned) into the ram logger and captured a run this morning.

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=9859;image)

The red, dark blue and light blue lines are the contributions from the P, I and D terms. In the graph, all the waste gate duty cycle (yellow) comes from the I term at the rpm range I’m interested in (5000 rpm upwards)

P – ldptv_w
I – lditv_w
D – ldrdtv_w
W/G – ldtvr_w

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=9861;image)

The red and blue lines are desired and actual boost, showing the deviation from 5000 rpm upwards. The green and purple lines are the waste gate duty cycle pre and post linearization (KFLDRL).

Desired Boost – plsol_w
Actual Boost – pvdkds_w
W/G duty cycle pre lin – ldtvr_w
W/G duty cycle post lin – ldtv_w

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=9863;image)

The red and blue lines are the I-limit (from KFLDIMX) and the actual I value being used by the PID.

I-limit – ldimx_w
Actual I value – lditv_w

Looking at the data and speculating out loud, I’d make these observations (but I’m no expert. I haven’t done this before and I make mistakes all the time. If I’m wrong, don’t be shy to tell me!)

•   No issue with KFLDIMX. I ride the I limit during spool and midrange, but from 3500 rpm upwards, the ceiling is well above the actual I value.
•   KFLDRL (pre and post lin) isn’t doing very much, especially at the range that I am interested in.
•   All the duty cycle is coming from the I term


The attached csv log is pretty comprehensive and has got all those other variables you mentioned. But I didn’t graph them so as to keep things clearer. I’m happy to pull them out if you ask.

Is B_lddy clear?

What values do you have for Q1 in that range?

Did you log ldimxak?

Is KFLDRL 1:1?

Hello,

I didn't log B_lddy itself, but looking at the logs I think I can derive what it was anyway.

The logged components of the PID (in that range 5000 rpm upwards) have values consistent with:

LDRQ1ST for the I term
LDRQ0S  for the P term
and 0 for the D term

This is the steady state then?

LDRQ1ST is set to 0.4 from 2200 rpm to 6500 rpm.


Here's ldimxak_w:

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=9869;image)

And screenshot of KFLDRL. For all intents and purposes, in that range (around 5000 rpm) it's practically 1:1.

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=9871;image)

Is the bump up in ldimx related to LDDIMXN  values?

I would make Q1ST slightly more aggressive (increase) and see if it tracks better. If you go too aggressive it will become unstable.

I would also raise dynamic Q0 slightly in the spool region and Q2, but it might be best to save that until after you get this sorted.

Thanks phila_dot


Sorry, not too sure what you mean by that ??? I haven't made any changes to LDDIMXN.

I can certainly add a bit to LDRQ1ST (say increase from 0.4 to 0.5).

Also, what about modifying KFLDRL somewhat? Along these lines @5000rpm upwards, input 60 -> output 65, input 70 -> output 75 and so forth?

Just curious where that odd jump in ldimx is coming from. I'm guessing it was done like that to keep spikes in check down low. Do you spike harder when boosting above 4k RPM?

It may actually be better to start by raising KFLDRL as the response is clearly not linear.

Ah, I understand now. You're curious about why ldimx_w seems to ramp upwards from 4000 rpm...

Actually, that was me  :-[

When I first started looking into this boost deviation, I tried raising KFLDIMX from 4000 rpm upwards to see if it was limiting the duty cycle too much. Previously I'd lowered KFLDIMX to stop spikes lower down and I wanted to see if this was overdone at the top end (it wasn't).

Sorry for the confusion.

IMO for a constant boost req your pre-lin DC should not be moving much... I should not be moving, unless your req boost is tapering significantly, in which case you should be losing I, not gaining.

let KFLDRL bring up DC, let your PID stay mostly inactive

increasing I generally means your DRL isn't calibrated correctly, unless your req boost is increasing!

I do agree that he should be addressing this via KFLDRL.

However, I'm not sure what you mean that I should not be moving. There is boost error present so I needs to be moving to correct it.

The reason why this issue should corrected with DRL is because boost error is increasing even with an increasing I. The PID is responding but the wastegate response isn't adequate.

I would need to be increased if the response is too fast or too slow, but I don't think that is the case here.

Just saying that if DRL is calibrated correctly, a constant boost req should not require the PID to do anything (or much)... pre->post lin correction should be sufficient to (mostly) maintain boost, and lde should remain near zero.

Conpletely accurate, but that's also assuming P, I, and D are doing their job. I should still track back to the setpoint in steady state if it needs to.

I get what you're saying though that I shouldn't have to do much after it accumulates.

Yep. But remember, P is out of the gain schedule if lde is anywhere remotely near zero. And D should be basically zero, since nothing should be moving if req boost is steady and DRL is calibrated correctly.

Did you mean D is zero in steady state and P is near zero based on current error?

Yes and yes. And when P is near zero, it is out of the gain sched..

Hi!

Interesting comments, borne out by what I saw in the logs. D is zero in the steady state.

I increased KFLDRL and logged again this morning.

A bit surprised by the result...

As far as I can make out, the post-linearization duty cycle remains the same, but less pre-linearization duty cycle is needed to achieve this. And the boost curve stays the same.

It's like the actual boost is has reached some other set point and the PID is maintaining it.

Love to hear what you make of this ;D

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=9873)

There are two plot's overlaid in the chart, before and after the KFLDRL changes.

Purple line is pre-lin duty cycle (ldtvr_w)
Green line is post-lin duty cycle (ldtvm or ldtv_w, they are the same in value)
Red line is specified boost
Blue line is actual boost

Could someone help me on the rev & speed limiters on the attached (stock) file?

For some reason changing the NMAX (1C9982h), NMAXGA (1DB368h) and NMAXOGGA (1DB380h) have no effect what so ever.
The engine still cuts at the stock limit (6800rpm). The GA and OGGA tables shouldn't be even altered but I tried that too just to be sure.

Also all of the VMAX related limiters seem to be set either to 255km/h or 511km/h but yet the actual VMAX seems to be limited to around 230km/h.
At that speed the engine starts cutting power.

You need to open your eyes a bit more for Nmax :) it's VERY easy.

Keep going! Add more DRL until the pre-lin is flat where req boost is flat. Near steady state, the shape of pre-lin should roughly match req boost.

I'm guessing you're near the turbo's limit, which means no matter how much DRL you add, you may never see req boost. At that operating point, boost is likely almost unresponsive to DC.

Forgot to say that I already adjusted NMAXDV and NMAXDZ too, zero effect.
Unless the rpm limit set by NMAXTO is active even below the lowest oil temperature I am pretty much out of ideas ;)
There's NMAXDVG too I see.

Behold, the masterpiece...

Well not quite, but I have an answer!


Spot on. I've just logged one more iteration of KFLDRL where I jump straight to 95%. No half-measures, just 95% output for any input greater than 20% from 5500 rpm upwards.

And yes, actual boost still tails off. Why am I so pleased? - because now I understand I've run into a physical limitation of my KO4!

I'll work on tidying up KFLDRL ;D

(http://nefariousmotorsports.com/forum/index.php?action=dlattach;topic=5525.0;attach=9883;image)

could something else be causing the issue? aren't those limiters "without errors"?? I'm just guessing as I haven't even bothered raising those as my engine didn't seem to make anymore power past 6200rpm as it is

Regarding the VMAX I'm no longer sure what to believe.
ECUSafe shows that one of the several VMAX limiters is set to 225km/h, which is within the range of the actual top speed achieavable.
This 225km/h limiter (7080h) however is defined as NMAXF, which equals 7200rpm with the 0.25 factor. With the factor used for VMAX (1/128, 0.007813) the value
is 225km/h. I assume the same value cannot have two different meanings?

which probably means you are probably way off the reservation efficiency wise, and likely near the overspin boundary.

Consider consulting the K04 compressor map...

Regarding the fuelling, please correct me if I am wrong:

The stock injectors on 200hp (e.g. AXX & BWA) engines seem to flow 1027cm³/min @ 110bar based on the KRKATE (34.25 / 0.03333).
When I swapped the S3 injectors I used the flow difference of 13% stated by APR as a ballpark value.
Based on the logs I made the actual difference in the flow is pretty exactly 15%. With KRKATE scaled down by 13% the LTFT has settled to -2%.

However if I raise the fuel pressure for example from 110bar to 120bar the KRKATE needs to be scaled again?
(1027 * 1.15) * ((120/110) SQRT) = ~ 1233cm³/min <> (34.25 / 1233) =  0.02777ms (KRKATE)

Few more basic questions:

The relationship between the different "cylinder charges" (relative luftfüllung) between the different maps.

The KFMIRL/S & KFMIOP/S maps are permanently linked together, but do the other (KFZW/2, KFZWOP/2, KFZWOPL/2, etc) "cylinder charge" axises relate each other?
The range of the axises between the different maps vary between 150-171% on a 200hp engine variants.
The default KFMIRL on these engines goes up to 177%.

The main question is that if the KFMIRL charge axis is increased to reach up to 220% instead of the 177%, is it necessary to reflect the change in KFMIRL to every other map with a "cylinder charge" axis?
Even at stock there seem to be a slight discrepancy (up to 20% in charge) between the maps, but what happens if the load axises on other maps remains at stock (up to 171%) while KFMIRL requests up to 220% (KFMIOP recalculated of course)?
Torque intervention?

What about the KFLBTS and KFFDLBTS then?
Currently my fuelling is quite ok, however it tends to run slightly richer than I would like to (and have specified in KFLBTS).
I have understood that unless KFFDLBTS is other than 0.0000 (disabled?) it functions as an offset for KFLBTS.
On the stock maps at 155.25% CC/LF and 3520rpm the KFLBTS specifies 0.7188 LAMBDA, while the KFFDLBTS specifies 1.2032.
This would mean the effective LAMBDA value would be 0.7188 * 1.2032 = 0.865.

At higher rpms the KFFDLBTS is decreased to below one which would result richer mixture than requested by KFLBTS.
This would make sense as the stock software seems to dump as much fuel as possible at high rpms to keep the EGTs down.

So in case the above assumption is correct, will setting the whole table to 1.0000 make the LAMBDA to follow KFLBTS better?
I've read that disabling (setting to 0) it might have an effect on timings too, but is the logical 1 just basically a zero offset?

   

;)

Stock S3 Turbo is part number 5304 988 0064

Think I've managed to find a corresponding compressor map (attached).

I'll have a go at the compressor map feature in ECUxPlot. Anyone happen to know the 2.0 TFSI maf diameter (and maf offset)?

Many thanks.


Hi Nottingham,

I'm pretty sure I've used the MED9.1 information you put up in previous posts to help me!

1) KRKATE. For what it's worth, I've attached my stock S3 bin. I've had a look and I think stock S3 KRKATE is 0.030000

2) Charge axis. I have wondered about this myself ??? I've also got KFMIRL/KFMIOP raised but haven't touched the axis in any other maps. I haven't noticed anything untoward but I would be interested in this as well.

3) KFLBTS and KFFDLBTS. I made changes to KFLBTS, but it was more trial and error - make a small change, log, make another small change, log and so on. I did also take a look at the FR and I can see the influence of KFFDLBTS you describe.

4) Curious about the rev limiter you are working on. Is it stock hardware on the engine? My recent experience show the turbo pretty much running out of puff even before the factory rev limit. I didn't think there was anything to be gained by going further, but obviously I don't know your scenario. Just curious though ;D

Happy to help where I can. Always nice to meet others also working on MED9.1

A couple things:

1) the MAF stuff in ECUxPlot is only there to assist in files where the MAF values are underscaled. If you are confident your MAF readings are 1:1 with reality, you shouldn't have to touch it.

2) the pressure drop model leaves a lot to be desired, so don't necessarily trust the calc P/R numbers, they're only a ball park.

ME will simply use all of the 171% cells at that operating point. In general, it isn't a problem, but you may find various maps where you want things to vary depending on load past 171% (or 190, or whatever).

It is worth to enable second rev limiter , as we can make 2 step rev limiter (launch control) like in GTI or golf R DSG if we have manual gearbox.

I also working on this limiter, but till now without success.

PS. What variable ram logger do You use to log variables ?

http://nefariousmotorsports.com/forum/index.php?topic=5941.0

It seems that following maps need to be checked or recalculated in case the KFMIRL/S is heavily increased from default calibrations.
Thats just theoretical of course, but all of these maps use rl_w in either axis.

KFDWSZ
KFDZK
KFDZWAGL
KFDZWAGR
KFDZWHKS
KFDZWHMM
KFDZWHMML
KFDZWHSP
KFDZWKGAGL
KFDZWKGAGR
KFFRKHK2K1
KFLADMXHMM
KFLADXHMMA
KFLAHMM
KFLASDSLS
KFLASKH
KFLMSKH
KFLRSG1
KFLRSG12
KFLRSG2
KFLRSG22
KFLRSG3
KFLRSG32
KFLRSG4
KFLRSG42
KFLRSP1
KFLRSP12
KFLRSP2
KFLRSP22
KFLRSP3
KFLRSP32
KFLRSP4
KFLRSP42
KFLRSPHI
KFLRST
KFLRST2
KFLRSZ
KFLRSZ2
KFMDS
KFMIOP
KFMIOPS
KFSWKFZK
KFSWKFZKR
KFTOSPMVRL
KFTVLBTS
KFWBHK2S1
KFWBHP2S1
KFWEHK2K1
KFWEHP2K1
KFZW
KFZW2
KFZW2OUT
KFZWKEVABZ
KFZWLB1
KFZWLB1OUT
KFZWLB2
KFZWLB2OUT
KFZWMN
KFZWMNGS
KFZWMNHSP
KFZWMNKH
KFZWMNLB
KFZWMNST
KFZWMNUM
KFZWMS
KFZWMSLB
KFZWOP
KFZWOP2
KFZWOPA
KFZWOPA2
KFZWOPL
KFZWOPL2
KFZWOPLA
KFZWOPLA2
KFZWOUT
SRL07OPUW
SRL08LSUW
SRL08ZHKUW
SRL08ZHKUW
SRL08ZHKUW
SRL08ZHKUW
SRL08ZHPUW
SRL08ZHPUW
SRL08ZHPUW
SRL08ZUUW
SRL11OPUW
SRL11OPUW
SRL12ZUUW
SRL12ZUUW

+1 to this. My understanding is if you have a max charge load of say 190%, once you reach 190% the car will hold the value in that line (Torque % for example) Most people change the axis in KFMIOP to "reflect" the change in KFMIRL but i dont think its needed. It will hold the value at the 190% or anything above that. Unless you are doing something weird and want to change the axis's in 50 other maps i dont think its really needed to change the axis.

It is going to be FAR more than 50 maps IMO.

Nottingham: you are in for a WORLD of hurt if you think you have to adjust all maps to be able to handle rl_w > 171

Thats why I said: in theory ;)

An embarrassing question as the answer should be clear at this point: The ECU does not either inter- or extrapolate?

E.G.

Actual RPM = 4500

Map:

4000 RPM = 100
5000 RPM = 125

Value at 4500rpm = 125 (?)

Interpolate, yes.

Extrapolate, no.

so using his example 4500rpm = 112.5?

that's how i have been thinking it works. would like to know if I'm putting too much thought into it!

Typically, the lower row columns are interpolated, the higher row columns are interpolated, then the interpolated values from each row are interpolated together.

	100	150
4000	10	20
5000	20	40

Load 125
RPM 4500

Lower row interpolated would be 15
Second row interpolated would be 30

Output value would be 22.5

After fitting K04 turbo of an Audi S3 2.0TFSI on my BWA engine MK5 GTI. I want to move on and exchange to S3 injectors too. I read that S3 have arround 13% more flow capacity. I guess adjusting KRKATE will be enough. Looking and comparing files, I found that my value is 3330 whereas S3 has 2880 value. This also shows that the value is arround 13% different. Will this adaptation be enough? I read that S3 has also fitted 3 bar MAP sensor whereas BWA only has 2.55 bar one. What will it help when I exchange to 3 bar sensor? Will be adjusting DSVDGRAD and DSVDGRAD enough after fitting the 3 bar MAP? BWA engine has DSVDGRAD=541 / DSVDGRAD=5103,59 whereas S3 values are 658,83 and 5056,48. Are these values OK? Thanks for your tips and help.

Setting the KRKATE to 0,029000 gave me -0,2 LTFT on the S3 injectors, indicating the actual flow in 15,2% higher than on the stock injectors ;)

Could someone with a better understanding please explain me how the ECU uses the specified rail pressure (KFPRSOLxxx)?

Lets say the stock map of an 200hp TFSI engine has 0,0333ms KRKATE, meaning the stock flow is around 1027cm³/min.
At this point I have to assume that the resulting cm³/min is at the stock fuel pressure which peaks at 110bar.

However since the stock KFPRSOLxxx maps specify a variable rail pressure based on different torque requests and rpms, how does the ECU handle the variations?
Does the ECU expect that the injector flow indicated by KRKATE is at the highest pressure value indicated by KFPRSOLxxx maps and then calculate the actual injector
flow based on that with following formula (e.g. specified rail pressure 90bar)?: KRKATE / SQRT(110/90)

So when the peak requested rail pressure is raised from 110 to 130bar the KRKATE must be correctly adjusted once again?

Let's say I would need 130bar fuel pressure instead of the original up to 110bar.
Should I leave the lower load and rpm lines in the KFPRSOLxx maps as stock and only raise the requested pressure where it is actually needed?
Also any preference should the changes to the normal operation fuel pressure be made to KFPRSOLHOM (normal operation) map directly or is it preferred to use the KFPRSOLOFF (offset) map?

Apologies, I feel like a leech :(


 

I think RP increase after fitting HPFP will not effect KRKATE. Actually it will give some extra flow capacity to your injectors to get more fuel into the engine. Anyone experiences with 3 bar MAP sensors? What are benefits in doing this exchange fitting 3 bar MAP?

You can read/log more boost but you can't request more.

Rick

Thanks for reply. Guessed it will be like that. "Will be adjusting DSVDGRAD and DSVDGRAD enough after fitting the 3 bar MAP?" What about this question..

Changing DSVDGRAD and DSVDOFS will do when changing MAP sensor. Currently running a 3bar on my BWA engine. You can see how they are calculated in the FR doc on page 802 (or copy the values from an ECU with the same MAP sensor).

As part number found: 0281 002 401/038 906 051 C. Are these OK? Also comparing maps: DSVDGRAD=34624 vs 42165 (GTI vs S3), DSVDOFS= 65326 vs 64723 (GTI vs S3). Can you pls confirm these values? Thanks...

Anybody can confirm pls?

Yeah. they are correct.

0 281 002 401 or 038906051C (VAG).

200hPa (0.2bar) @ 0.2V
3000hPa (3bar) @ 4.65V

DSVDRGRAD = (3000 - 200) / (4.65 - 0.4) = 658.828125 (42165 or A4B5h)
DSVDROFS = 200 - (658.828125 * 0.4) = -63.53125 (64723 or FCD3h) - Signed

What is the right factor for DSVDROFS ?

I tried to appy this to my me7.5 and my factor was 0,039063.
But with FCD3h @ OFS i had to double the factor to 0.078126 to read -63.5164

factor for DSVDROFS is 0.078125

Anything obvious I am missing:

The pull-back is significantly greater and the lambda is significantly richer, during 4th and 5th gear pulls than during 3rd gear pulls.
The IATs are good and they are even lower at higher gears due the greater speed.

Any ideas which maps could affect both the ignition timing and fueling, depending on gear?

How do your EGT's look for 3rd vs 4th/5th pulls?

Haven´t checked really, as I´ve been under the impression that the catalyst / lambda calculated EGTs aren´t too realiable anyway.

I saw higher EGT’s with a 4th gear WOT pull than I did in 3rd  (I assume since the time duration of the pull in 4th gear is greater than 3rd gear and heat builds up…)

Component protection fuelling?

KFDLATRNL
KLTATRS
KPATRDT
TATRIHKS
TATRVHKS

Mind you, my own experience is based on an S3 8P. I'm not sure which TFSI motors have/don't have EGT sensors  ???

The EGT is calculated as there is no sensor.

The enrichment and increased pull-back definitely correlates with the EGTs.
Despite running mixtures more on the rich side (11.76 at high torque and 12.2 at higher revs) the block 112 peaks (999°C) already at 4500rpm and stays there.
The boost is pretty low (1.2bar) as I am just beginning to tune the low end.

In the longer runs the ECU starts to intervene and makes the mixture even richer (low 11 AFR) and the pull-back starts to increase (still moderate <4.5°)

I´ll think I´ll do as the grand master recommends and disable KFLBTS fuelling all together and use purely LAMFA instead.
According to Fotis this provides better control and overall results than using KFLBTS.

Does anyone here have the MED9.1 documents?
I need 1 chapter from it, if someone could help me with that!?

Perfect way to melt engines. Better control? Maybe for those who are not able to calibrate the ECU correctly.
Tune the timing map properly, why the hell do you have 4.5 deg retard? This is not normal, it should be 0 or close to it.
Calibrate BTS fueling maps with correct targets. Make it so that BTS kicks in only if something is actually wrong (crap fuel etc). Instead of all the time.

If you are unable to do this, you should not be tuning Motronic... Turning every safety off is NOT the way to go.

That´s my thoughs too...

Keep using KFLBTS, just lower KFFDLBTS as it will make corrections on what is on KFLBTS

from what i have read on timing on these is that you want up to 3deg pull?? otherwise you're leaving power on the table. i def read that on here somewhere from a seemingly credible source, but cant recall exactly who.
as for me i adjusted LAMFA and then scaled back KFFDLBTS/KFLBTS so it does'nt go crazy rich if bts does come into play, but is still safe if something goes wrong

You do want to see corrections, but not on EVERY cylinder, and not for the entire log. Considering most files pull 3 degrees by default for a single knock event, assuming you haven't changed that you're fine.

As for the rest, he was referring to disabling BTS. That'd be foolish as ME7's calculated EGT's are very accurate, and additional enrichment will save the engine long before load reduction will.

i was assuming that MED9's EGT calculations weren't very accurate. also, what would i log with VCDS for calculated EGTs? there are at least 2 diff options, but one is something like "median exhaust temp" any idea which one is the more accurate?

and i meant i changed KFLBTSLBKO and KFLBTS, btw. i left KFFDLBTS alone

So you´re saying disabling KFLBTS is wrong and shouldn´t be done?
Basically the activation threshold for BTS is so low that LAMFA get´s never used while WOT.
That´s was the case when the car was fully stock too.

Currently I´m using KFLBTS to control the fuelling and have it´s pretty much exactly where I want  it to be.

I calibrated the ignition maps basically from the scratch (due different turbo characteristics and higher grade fuel).
My pull-back peaks at 4.5 degrees in the longer runs at high gears, however it varies significantly between the cylinders (as usual on TFSI).

I basically have all the mods installed, so I can add more fuel to lower the EGTs at high revs.

Using BTS as primary fueling is foolish. You basically eliminate an entire layer of protection. Raise the threshold for BTS, use LAMFA for prevention, and BTS for protection..

BTS should set to kick in only when it actually gets hot, not all the time.
That means either you've been flooring it for a long time and EGT is going up OR you have a batch of bad fuel with lots of knock retard so that EGT's are high as well.

Why would you disable KFFDLBTS? This is the OCTANE protection map. If you get bad fuel and KFFDLBTS is disabled, you will melt your engine.

Any idea then why VAG is using BTS all the time at stock?
Initially I tuned by using LAMFA as the main fuelling map, however it kept falling back to BTS so tuning it that way was pretty futile.
Also TAVVKBTS defaults to 1268.5°C (FFFFh) which sounds fishy as FR specifies 900°C for it.

"Bad quality fuel" doesn´t exist where I live (98 RON is bare minimum), so the protection isn´t absolutely mandatory.

Because it's not tuned how Bosch intended it to.
There is only a handful of models where this is the case though.
Let me guess, you can cure cancer too?
What happens if one day you fill up with a bad batch of fuel? Octane rating has little to do with it... you don't always win the lottery, and the quality of fuel is not always consistent.
Just because it says 98 RON on the station does not mean that the crap they poured in actually is.

Anyway, tune how you like, just don't advocate bad practices.
As for BTS there are plenty of temperature triggers. Look at the FR how it works. Why you pick a random one is beyond me.

I skip that, how KFFDLBTS is involved with octane issues ?

My german is ZERO, but my "google translate" portuguese FR make me believe that it was only enrichment based on EGT (KFLBTS enrich past threshold, and KFFDLBTS increase enrich as high as EGT goes up) and as said before EGT is not read, but calculated, so a bad fuel will not make EGT diferent for ECU.

I though knock enrichment was only thing I will be diferent for bad octane fuel.

KFFDLBTS is enrichment based on ignition retard, or more correctly spark efficiency.

Rick

UHm... make a lot of sense,

I tried some experiencies with ME7 (don´t know if it aplies here too), with stock KFFDLBTS it was allways richer than KFLBTS even without any knock event (KFZWOP and KFZW stock too, with Petrobrás Podium fuel - 95 oct RON and little more load/boost), after that I make KFFDLBTS all "0" and lambda follows KFLBTS (as I wanted)... in MED9 would I expect some other behavior ?

Some ECU's are coded to work on the difference between basic ignition angle efficiency and retarded ignition angle efficiency.  In this case with no retard DLBTS and KFFLDBTS will not kick in.  Some ECU's look at ignition angle efficiency in absolute terms, i.e difference in efficiency from KFZWOP and zwout.  Here you will get an AFR of KFLBTS multiplied by the relvant values in KFFDLBTS and DLBTS.   

Correctly tuned, you will have your targeted AFR in normal conditions, and a richer AFR if ignition timing retards from your basic ignition angle.

Rick

Great, how is it coded?

some relation with wideband/narrowband or those with/without EGT sensor?

I had TAIKRBTS at 800°c stock. I raised that up to 850. I also assume u knocked the LAMFA delay down to 0 too??

TAIKRBTS and TAVROBTS are the only two values which are not set to maximum by default.
TAIKRBTS default to 800°C while TAVROBTS default to 1200°C. All the other values are 1263°C (FFFFh), which I assume means disabled.
TLAFA you mean? Haven´t touched it (2.7 seconds).

ya, if you leave it stock LAMFA isn't used until the time has passed, i was using bts as main fueling too until I adjusted the LAMFA and removed the timer

Great, thanks for the info :)

Sums it up well with one sentence.

Everyone who disables BTS or uses it for fuel all the time is not tuning correctly as the ECU manufacturer intended, as simple as that.
You can always treat the ECU as garbage-in, garbage-out, but you will have better (safer) results if you use the intended mechanisms correctly.

Incorrect, calculated EGT (of course) depends on ignition angle efficiency, just as actual EGT.

So is this correct:

Calculated EGT < TAIKRBTS = LAMFA is used
Calculated EGT > TAIKRBTS = KFLBTS is used to enrich the mixture

If so should the TAIKRBTS be increased and TLAFA set to zero in order to stay in LAMFA for fueling?
And BTS maps are kept as a safety measure in case the EGTs or the timing retardation increases to dangerous levels (because of crappy fuel for example)?

Also what are the most common reasons for high EGTs on these engines?
The EGTs are high despite the 0.8 lambda, moderate boost and non-restrictive exhaust.
Obviously the EGT calculations have been knocked off by the downpipe alone, however the difference shouldn´t be too big.

No absolutely not. They are calculated separately. The lower one wins. PLEASE review the FR and the s4 tuning page again

I am just trying to find out what triggers the change from LAMFA to KFLBTS for fuelling?
I assume it´s TAIKRBTS since KFLBTS is used all the time even when fully stock.

There are ~10 different temperature triggers. If any temperature goes over it's temperature trigger, BTS is activated.

Again, this is the wrong way of looking at how BTS works.

Ok so basically you´re saying:

- Using any BTS map for fuelling is wrong
- Changing BTS activation thresholds is wrong

So please do explain how the hell one does one force the ECU to use LAMFA then?
I could set the LAMFA map to 0.6 and still the ECU won´t use it.

Calculated EGT below TABGBTS and TLAFA limit met = LAMFA
Calculated EGT above TABGBTS = KFLBTS + the scalars

Final lambda is affected (KFLBTS + (DLBTS * KFFDLBTS)) by DLBTS and KFFDLBTS which are both scalar (delta) values.

TAIKRBTS = 800°C
TANHKSAO = 1263°C
TANVKBTS = 1263°C
TAVHKBTS = 1263°C
TAVHKSAO = 1263°C
TAVROBTS = 1200°C
TAVVKBTS = 1263°C
TAVVKBTSH = 1263°C
TAVVKBTSP = 1263°C
TAVVKBTSW = 1263°C
TAVVKSAO = 1263°C
TKIHKSAO = 1263°C
TKIVKBTS = 1263°C
TKIVKSAO = 1263°C

TAIKRBTS appears to be the EGT threshold here as the other limits besides TAVROBTS are disabled.

But still, if increasing the limits is wrong there is no way that the EGT limit won´t be reached and KFLBTS used for fuelling ???

No, I am mostly just making an almost semantic argument.

Requested lambda is the lowest of lamfa, lamfawk, and lambts.

The correct question is: "how do prevent lambts from dropping below lamfa, until I want it lower than lamfa".


you're not looking to disable BTS. You're looking to make it do what you want to do to keep EGTs under control, but not at the cost of going too rich too soon.

it won't be reached right away if u lower LAMFA and remove the timer on it. in my experience it can still be reached on a long pull, or sometimes in spirited driving with a lot of WOT pulls. not always tho, like I said, I raised my TAIKRBTS to 850°c, but I have a 3" cat-less downpipe

Of course it will. READ THE FR.
LAMKO module. Stop posting until you know this by heart.

Ok, we have two diferent ways to code, as I usually see lambda lower than KFLBTS and it disapers after "0"ed KFFDLBTS I assume that I´m in the second way ( KFZWOP different than zwout triggering DLBTS), considering I have no knock at all RPM ranges and loads :

1 - Can I assume KFZWOP is lower than it could be ? (perhaps 25% ethanol in blend here in Brasil)

2 - To achieve better behavior I should

a - code to "first way" ( "difference between basic ignition angle efficiency and retarded ignition angle efficiency") (if it´s possible, and HOW to make it ?)

b - decrease DLBTS / KFFDLBTS to keep lambda as it should be (don´t look too smart to me at now, but it work very good indeed)

c - increase KFZWOP and keep DLBTS as an ultimate defense for knock (fuel quality)?


3 - I allways though KFLAMKRL was the enrichment related to knock, used to think DLBTS/KFFDLBTS was only to increase enrichment as EGT rises beyond the trigger

this is med9, don't forget, so there is also a bts map with the flapper open

I was looking for the maps reponsible for timing retardation at high EGTs but couldn´t find any.
Looked through "ATM" but the only even remotely similar map was KFATZWMS/2 (Kennfeld Zündwinkelkorrektur für Krümmerabgastemperatur).

I would like to temporarily disable the EGT retardation in order to get my ignition maps in the best possible order.

Timing retardation at high EGT? What?
Why would you retard timing at high EGT? To grenade the engine?
This is also why it does not exist in the ECU, it is absurd.

So, that was a doubt mine too...  ECU takes no action related to EGT x advance ?

I don't know about MED9 but there is certainly no timing intervention from EGT in ME7.

Make sense as advance make huge difference in EGT, what part of MED9.1 FR it would be (if there is obvioulsy)

Too much timing or too little timing BOTH cause high EGTs.... However, the ECU will already never add too much timing; it will only pull timing (for KR, torque intervention, etc), but why would it try to RE-ADVANCE timing to prevent high EGTs if it is already running at the knock or torque limit?

I have a simple suggestion. Before tackling a difficult to tune ECU that is calibrated by many engineers at the factory at least get the basic concepts of an internal combustion engine straight. Such as timing effect on EGT, fuel effect on EGT, fuel effect on power and so on.

Small steps...

Could someone post TLAFA offset for some binary, so I could look for reference?
I thought I already had it, but it´s incorrect.

I agree, and these threads lately are starting to get frustrating. I'm not sure where to go from here, but I feel that it detracts from the site to have a bunch of people that don't understand the fundamentals of what they're doing representing our community.

Spent five hours in IDA trying to find TLAFA for my software ::)
Most definition files don´t have it defined and the Damos files which have it are otherwise completely different in that region, making it impossible to find it through pattern comparison.
The assembly code didn´t produce any matches either.

The only definition file for a SW with matching layout (from majorahole) had TLAFA defined, however according to IDA it´s wrong too.
The TLAFA defined in his file was part of a 16-bit value according to IDA.

Anyone want to lend a hand?

Stock SW as attachment.
According to majorahole definition, TLAFA in that file would be at 1D470Ch address.
However it appears to be part of 16-bit value, according to IDA.

That was a misunderstanding, my native language is portuguese, for us translation of advance is the same of timing, sometimes i forget and just change things.

My point (doubt) was: EGT changes with TIMING (not the term advance, my bad) the calculated EGT beeing different when ECU is running without any knock or with severe knock (torque intervation togheter) would trigger some corretion ?  you answer NO, and makes sense.

Real and modeled EGT will change dependent on timing, so yes, that may trigger other corrections - in this case, fueling, not timing.

I'll look at mine and see, if I can figure that out. I've made some changes since my last upload of my map pack.

Could it have been superceded by a map - KFTLAFA, in later sw versions?

Axis are gear and rpm and map values are in seconds, like TLAFA. In fact, the multiple values in KFTLAFA are the same as the single value in TLAFA (0.2 seconds)

That´s probably the case as beyond the expected point of TLAFA there are significant differences.
I checked the TLAFA code at assembly level and in my software there are no matches in function wise.

The 1D4634h (without TLAFA) and 1D43BEh (with TLAFA) offsets are the first ones which match beyond this point.
There are identical values in this region, however their functions are completely different.

Isn´t lambts KFLBTS + (DLBTS * KFFDLBTS) during enrichment active on MED9.1?
Ever since I tried to do the fuelling with LAMFA, I haven´t been able to control the fuelling at all.
LAMFA and KFLBTS are were I want them to be, however the effective AFR is significantly richer than requested by either of these maps.

I already zeroed DLBTS values to disable the negative offset from the DLBTS * KFFDLBTS, however it made no difference what so ever to the output.
The fueling is switched from LAMFA to KFLBTS when the EGT exceeds the TAIKRBTS limit, however during the enrichment the fuelling is all over the place.

Also can someone explain what detazwbs exactly is?
It is delta of something, but what?

http://nefariousmotorsports.com/forum/index.php?topic=141.msg58997#msg58997

Thanks, thats what I thought based on FR.

However it still puzzles me, which scalars still are making the modifications to KFLBTS if DLBTS is all zeroed.
Obviously KFFDLBTS contents become irrelevant with zeroed DLBTS (0 * x = 0), unless there are other scalars.
DLBTSGANG was zero to begin with.

Currently the actual lambda undershoots by 0.05 - 0.09 compared to what is specified via KFLBTS.

Based on the things I had to do in order to get back into control, I´d think it is safe to say that lambts in fact isn´t just KFLBTS/LBKO + (DLBTS * KFFDLBTS).

In order to get back in control I had to disable KFFDLBTS completely, by setting the whole map to zero.
Eventhou setting either of DLBTS or KFFDLBTS to zero should do exactly the same thing, it clearly doesn´t.
Setting the DLBTS scalar to zero made no difference what so ever, but disabling KFFDLBTS meanwhile did.

In addition I made another change to KFLBTSLBKO (KFLBTS while charge flaps are open).
Since I couldn´t think any reason to have two different KFLBTS maps for different situation, I simply copied the contents of the KFLBTS map to the KFLBTSLBKO map.
By default the KFLBTSLBKO map is even richer than the already extremely rich KFLBTS map. Based VAG documents the charge flaps on these engines stay closed between 1000-5000rpm
and the map itself pretty much confirms that. Below 5000rpm the KFLBTSLBKO map is leaner than the KFLBTS map, however exactly from 5000rpm and beyond the KFLBTSLBKO becomes much richer.

By default VAG basically has used KFLBTS for fueling on this ECU (8P0907115, 2.0TFSI AXX).
They have set the LAMFA map so lean (>= 0.9063 at all rpms) and the chamber EGT limit to so low (800°C) that it ensures that KFLBTS is used at all times ::)
BW K03 / K04 on TFSI engines should be rated to 1025°C continuous (1050°C peak) temperature, so based on that the stock EGT limit is ridiculous eventhou the two temperatures are not exactly the same.

The changes I´ve made:

- Calibrated LAMFA for optimal AFR at all rpms (best performance, but still perfectly safe to run)
- Calibrated KFLBTS in similar manner but with around ~0.06 lower lambda than in LAMFA map, to lower the EGT in case the safety limit is reached for whatever reason
- Copied KFLBTS over KFLBTSLBKO to disable the enrichment map changing at 5000rpm when the charge flaps open
- Set KFFDLBTS map to zero (to disable it)
- Set DLBTS map to zero (to disable it)
- Raised TAIKRBTS from 800°C to 950°C.

Eventhou disabling the two scalar maps may sound harsh, that´s what Bosch specifies in the FR (for DLBTS).

 

I do something similar in ME7.1, even if prj hates numbing BTS.

It's not a good solution. Instead it's better to decrease these factors in desired areas but leave them unchanged for very bad conditions (when ignition efficiency is very low).

I thought that numbing in tuners world is something more intelligent than just disabling :)

I agree about disabling the KFFDLBTS and DLBTS, I don´t like the idea either but that´s the only method I could regain control :(
I tried to calculate the expected lambts output with with KFFDLBTS and DLBTS taken into account, however the official formula of "lambts = KFLBTS + (DLBTS * KFFDLBTS)" didn´t produce the readings I was seeing.
Even with DLBTS set to zero I saw constantly 0.69 - 0.72 AFR even when KFLBTS/LBKO specified 0.82 at that point.

If lambts would be calculated with "KFLBTS + (DLBTS * KFFDLBTS)" formula then setting either (DLBTS or KFFDLBTS) to zero would disable the scalars completely.

I think I´ll try to look the software with disassembler to see how the KFLBTS, DLBTS and KFFDLBTS are used for lambts.
Since ME9 FR suggests that DLBTS defaults to 0.0 at all deltas, I don´t think the currently known formula is the whole truth.
Unless Bosch disables KFFDLBTS too, which is not the case.

Added 21 new RAM variables in my software yesterday, with the help of Basano´s great tutorial.

Since I have had several issues in controlling the EGT activated enrichment, I decided to log taikr_w to see how high it goes in a diagnostic run.
Currently I´ve turned down the settings significantly for diagnostic purposes and the peak boost is 1.2bar at 5000rpm.

At 6760rpm (1.03bar @ 0.79 lambda) the raw taikr_w value was 58484, which was the highest value recorded during the 3rd gear pull from 1700rpm.
taikr_w scale is 0.0234375 and it´s range is -273.15 - 1262.827.

Since the scale starts from 0°K I need to substract 273.15 from the value: (58484 * 0.0234375) - 273,15 = 1097.56875°C.

I also logged tabgkrm_w, tabgm_w, tabg_w and they all gave significantly lower values at lower loads, but exactly the same peak value.
tabgkrm_w & tabgm_w are exactly the same based on the output, so that doesn´t tell too much.

Any idea which else EGT related variables should I log?

Obviously these kind of EGTs shouldn´t be possible with these settings.
The turbo, DP and the rest of the exhaust have been swapped, however can it really throw the calculations out of order by this much?

Ignition angle is very influential on EGT's. Have you retarded timing much?

You mean do I have too much advance? ;)
Didn´t log ignition this time, but generally my ignition is rather conservative compared to logs I´ve seen.
I guess I could try to reduce the advance slightly, however I don´t think a few steps (1.5 - 2.25°) would make much a difference.

Please correct me if I´m getting it wrong, but

Too much advance = higher EGTs
Too little advance = lower EGTs

The IATs are low, the fuel quality is great >99 RON, the boost is conservative and the AFR is rich 11.9 - 11.6.

Little advance can also contribute to very high EGTS, since still burning fuel can exit the exhaust ports into the manifold.

This is what I meant.