NefMoto

In the e85 thread, I asked bob about these timing oscillations:

(http://mattdanger.net/s4/logs/e85-v15/image008.png)

His response:


ZUE says:

(http://nyet.org/cars/images/zue-zue.png)

And MDZW is:

(http://nyet.org/cars/images/mdzw-mdzw.png)

comments?

simply:
Die Werte in DMAUFN sind so vorzubelegen, daß sich für alle Drehzahlen eine Steigung von ca. 5%/sec ergibt.

 ;D

Apologies, but my german is terrible..

Let me try

The values in DMAUFN are set such that for all RPMs, there is a slope of 5%/sec?

Don't get too lost in this. Log the two variables that I have mentioned in the other thread first before wasting time for nothing.

I have seen this situation if you have more air than requested for the requested torque and the ECU tries to reduce torque with ignition angle. As I have already said this interventions on the fast path are usually not allowed on full load.

Bob, thanks for the info. This isn't for a current car; this is just behavior i've seen in many, many other cars that nobody has ever been able to explain (across many forums). If I see it again, I will log.

Out of curiosity, what was the fix? Reduce MAF readings (via MLHFM or KFKHFM)? or something else? Also, what do you mean by full load?

my german is perfect but my me7 knowledge should be better ;)

I think it will not make too much sense to analyze a jumping ignition log when there is so much going wrong with the air and fuel path.

I haven't had this problem on my S4, but I have seen this on other cars I have calibrated.
General fix is that the actual values meet the requested and not to allow ignition interventions in that situations  ;)

To describe the situation in a few words:

The ECU has a driver requested torque value it wants to meet. It sets a torque setpoint for the slow (air) and fast (ignition) path. If air is too much, because of poor boost control calibration for example, the ECU tries to reduce torque on a other way (ignition angle) if it's allowed to. But these interventions through ignition angle are liked to certain enable conditions (BBMDEIN).

The key to understand what the ECU is doing, is to understand the torque structure.
Start from section MSF in the Funktionsrahmen and elaborate from there. ;D
As I've said I will do a short write up as well.

I could be wrong, but I'm pretty sure that I saw a condition byte for "full load" that could be logged.

I know how frustrating it is to explain the *general* case w/o discussing a specific problem/log, but please bear with me! I appreciate your help.


I.E. large neg deviation? (req<actual ps)

What about incorrect MAF calibration (e.g. MAF readings higher than actual air)?


Got it. Question is, what rules of thumb do you follow when you decide when to fix the REASON for the intervention, or whether or not to allow intervention. Again, I realize this is a general question, but bear with me :)


Got it. I have been trying to, but my German (especially technical) isn't so hot, so you'll have to be patient if I ask very dumb questions.


Thanks in advance :)

Keep in mind my goal is to continue to elaborate on the s4 tuning wiki page, which is far too simplistic and is missing many many important troubleshooting tips. So I would also appreciate some honest criticism of that information. I know a lot (most?) of it is probably misleading or incorrect, but I am committed to making it right, since it is the only single, open, easily accessible place that i know of for a top level summary of the most critical maps.

I've seen this if optimal torque is too far off of actual.

By off, do you mean higher, or lower.

Seems to me requested is almost always below opt... or should be?

In 3rd my timing logs look pretty smooth, but in second gear starting from low rpm (like 2k), my timing is crazy!! up and down, essentially the same path as in 3rd, but the variation is amplified 3x...

Not sure why, especially since load values are essentially the same from 5k RPM and up.

Yea, it seems to be "rate of change" related, either to MAF or RPM

I'll take another stab: if KFMIRL is modified, but KFMIOP is not set up properly to reflect those changes, is the result timing oscillations?

Why not to test it?
Just reset both to stock values...

I think u are on the right track... I've been browsing the fs but I need to do a little more digging before I test out some changes.

misol seems well about miist, and zwbas STILL shows the same occilations. IRL/IOP are near stock.

(http://nyet.org/cars/images/misol-miist-zwbasar.png)

If zwbas is already osscillating simply log all the inputs in zwbas to identify which one causes it.

I'm here.... timing seems to be coming from kfzwop, as kfzw is only set to 36 max at full load while i'm getting 42*  which is what i have in kfzwop... first time i've seen this.  I'll report back when i get it all smoothed out and figure out the cause.   this is e85 +meth rs6 turboed s4...  42 is too much.
 (http://i714.photobucket.com/albums/ww142/judeisnotobscure/timing.png)

I have seen in my logs sometimes zwout will exceed zwbas and sometimes even appear to follow zwopt. This doesn't make sense though. zwsol is capped by zwbas. As far as I can tell, zwout should only exceed zwbas with the influence of wphg and zwdllprt.

I'm considering changing phase response, wphn.

i made adjustments to wphn (phase response), waiting for logs tomorrow morning.  I first tried scaling back both kfzw(2) kfzwop(2) yeilding the same results, just slower.
wphn map changes right where oscillations get bad in rpm range and is an input to zwbas.

Are you logging zwist? zwbas? zwgru? You need to trace it back from the output to the cause. wphn is added to zwbas before zwist and it only adds a little timing as RPMs rise.

Does zwgru oscillate? If not kfzw2 has nothing to do with it. Are you logging fnwue?

I think this problem comes from rapid switching between zwsol and zwbas. Also, KR is only active if zwist == zwbas. What do your CF's look like?

cf's are 0  so not KR... i'm thinking the answer is inside of MDZW somewhere.
i think whpn is part of my issue, i want 36* and i'm getting 42*.
i have not logged these yet, as i don't have the car on hand.  i will see if we can get the me7logger going.

MDZW has a lot of talk about torque influence on timing angle... recovery of angle, which outputs to zwsol.
i'm gonna do some more staring at this.

You can disable zwsol by setting CWMDAPP = 1. If that fixes it then you know MDZW is the source of your problem.

wphn won't fluctuate like that. It follows NMOT.

yeah, you are right. 
I'm waiting to see how underscaling the maf works, then i will try turning off zwsol

mdzw suspicions confirmed.  When i narrow down exactly which map(s) to change i will post it up.
uderscaling did nothing.

Have you done any rescaling/changing of IOP?

Seems strange that the timing is just soo agressive

i have made changes to iop for the tune, but none in diagnosing the oscillations.   like i mentioned earlier, timing was being increased to greater than my kfzw values through whpn and possibly something else.  i disabled mdzw entirely and no more oscillations. I've narrowed down the specific map which i'm testing tonight... i'll post up my findings.   
 

while i'm not sure this is the best way to fix the oscillations yet
dzweta has fixed them... you must tune the map, you can't just zero it or you will have other issues.
it is a percentage map for timing shift under zwsol.

after making progressive changes to only dzweta this is what happened to timing

(http://i714.photobucket.com/albums/ww142/judeisnotobscure/timingdzweta.png)

You are not actually fixing the problem using this method. DZWETA is not the problem, etazws is. My guess is the root of the issue is in MDBAS.

Edit: What "other" problems are you seeing when you zero out DZWETA? By zeroing it out you are isolating zwsol to zwopt (basically KFZWOP).

idle bounces and revs hang during shifts if u zero dzweta

I agree that this isn't a fix but a workaround.  that's why i said it's not the best way to fix it.

Yea... that makes sense. I wasn't thinking about everything that would bypass.

Just got a car in that's doing this, looking forward to having a play.  You guys get anywhere?

Rick

I didn't. The car mysteriously drops 6+ degrees of timing for a short moment without it being reflected in cylinder retardation column. I logged several ram variables and flags mentioned in this thread to no avail of any unusual activity.

Looking forward to your own findings.

Did you look at thw wkrdy_n adaptation values for each cylinder?

Is the timing relatively smooth apart from the reduction?

Rick

To illustrate, here is ecuX graph. I know I get torque intervention at least above 6k since I am boosting more than requested there, but the wild ride starts much sooner than that. Look at the severe timing dips and recoveries through the pull.

One notable thing to add is that I wasn't getting this behavior before when my MAF was running underscaled by about 20% and never hitting req load, at least in logs that is.

Now this got me thinking. Could be that if you OVERSCALE your MAF accidentally you always hit overload condition since internal ECU calculations for air intake show higher load than in reality?

Log zwgru, dwkrz, wkrdy, zwbas, zwsol, zwist, and zwout.

Feel like a broken record here, but have you tried setting CWMDAPP to 1?

zwgru - check
dwkrz - I can only find dwkrz_0,dwkrz_1,dwkrz_2,dwkrz_3,dwkrz_4,dwkrz_5 - should I log this?
wkrdy - check
zwbas - what's the address and data type?
zwsol - what's the address and data type?
zwist - check
zwout -check


I haven't run with CWMDAPP set to 1 but could... just afraid to disable this. I'd rather try other approaches. By setting to "1", do you mean "FF" or "01" hex?

Thanks.

zwbasar_0       , {}                                , 0x380D8B,  1,  0x0000, {°KW}     , 1, 0,         0.75,      0, {Basiszündwinkelarray}
zwbasar_1       , {}                                , 0x380D8C,  1,  0x0000, {°KW}     , 1, 0,         0.75,      0, {Basiszündwinkelarray}
zwbasar_2       , {}                                , 0x380D8D,  1,  0x0000, {°KW}     , 1, 0,         0.75,      0, {Basiszündwinkelarray}
zwbasar_3       , {}                                , 0x380D8E,  1,  0x0000, {°KW}     , 1, 0,         0.75,      0, {Basiszündwinkelarray}
zwbasar_4       , {}                                , 0x380D8F,  1,  0x0000, {°KW}     , 1, 0,         0.75,      0, {Basiszündwinkelarray}
zwbasar_5       , {}                                , 0x380D90,  1,  0x0000, {°KW}     , 1, 0,         0.75,      0, {Basiszündwinkelarray}

zwsol           , {}                                , 0x380D97,  1,  0x0000, {°KW}     , 1, 0,         0.75,      0, {}

Sorry.  

Dwkrz is a cylinder specific array, zwbas is a four member array that you should have, and use the wkrdy listed below.

wkrdy 0xF9B4 byte unsigned degrees 0.75
etazws 0x380D96 Percent byte unsigned 0.5
dzws 0x380D95 Degrees byte signed 0.75
zwopt 0x380CB6 Degrees byte signed 0.75
zwsol 0x380D97 Degrees byte signed 0.75

Set CWMDAPP to 01.

Everything that I have looked at shows that zwbas is not cylinder specific and is only a four member array.

http://nefariousmotorsports.com/forum/index.php/topic,1127.0title,.html

Let me know what you guys think.

There are quite a few drastic timing reductions in high rev range... I also exceed load quite a bit. Combined with the log, does that mean torque intervention?

I have NOT disabled it via CWMDAPP just yet. That will be tomorrow's logging session.

Yep,

torque intervention is your issue.  ZWGRU is nice and smooth, ZWSOL is causing the mess.

Rick

Well on this car, oscilaltions were an easy fix, it was simply poorly calibrated torque model.  I've attached the fixed screenshot.  There are some knock corrections but they can be smoothed out. 

What is interesting on this log, is that ZWBAS is higher than ZWGRU.  Only addition I can think of is down to warmup which had well finished.  Need to take a look at KR. 

Rick

PLEASE details! :)

In for details as well. KFMIOP?


My guess is DZWWL or possible that was not the current array member of ZWBAS. It would be really nice to log the ouput ZWBAS rather than the array members.

Yes,

Load was hitting 210, and IOP was untouched hence the intervention.

Rick

I'm starting to think this is why tuners started with heinously underscaled MAFs (see also GIAC's hilarious 100mm MAF)

Its just easier. You run into less issues with the torque monitoring.
Its not proper but it works.

I think I found the source of my timing oscillations. KFZWOP and KFZWOP2 maps. Once my timing would get close enough to touch the value in respective map for RPMs/NWS, it would get knocked down near the basic timing in KFZW and KFZW2 maps.

On your case zwist was following zwsol, so yes the OP would play a part.  You need to stop it following zwsol,

Rick

I made kfmiop and kfmirl jive a little better and presto, intervention is gone.

the source of my oscillations isn't op/op2 related, it seems its ARMD related

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