NefMoto

So how do you exactly force ECU into locked WGDC mode with scaled MAF to keep load under threshold for accurate fueling?

I was able to force it into WGDC with high load but it appears that over load 191 the fueling just bombs out, it doesn't add any more fuel resulting in leaner and leaner mixture as maf flow increases... or that is my observation.

With load under 191, I just cannot hop over boost regulation and get locked in sub 23psi WGDC.

Help please... solid info or actual tune file that works on any GT turbo would be greatly appreciated.

Look at the LDRPID module for the first answer.

And 2nd answer, it goes lean because you probably max out ps_w. Log ps_w.

Let me rephrase it. All the limiters have proper high values to hump over the 23psi limit, KFLDRL table proper caps, KFLDIMX values that are way too high for tial 770 anyway... It just looks like the ECU requests the load but it doesn't want to go over some boost limit... I am at a loss.

Log ps_w

ok, I figured it out. My KFMIRL was funky and I would never hit 100%. Thanks all.

That wont fix your fuel issues..

I don't have fuel issues nyet. I just illustrated in my original post that using some of my old tunes I was able to run over 23psi but it had another problem which is ps_w/load going over the edge.

ps_w is safely under 2550 on my underscaled maf now (1.5 factor so far). AFRs are exactly what I tell ECU to use, to the dot. Which is amazing.

Now I am fighting wild timing oscillations which ride 15 -> 0 -> 18 -> -3 and so on killing whole performance. It must be ARMD based and I just made modifications to KFDMDAROS and upgraded my me7 defs and cfgs to log all of these obscure things to show me where the timing intervention comes from.

One thing for certain, 770s can really punch at 32psi even with screwed up timing and small meth nozzles running windshield washer fluid [:)]. Already ordered 10gallon nozzles (I have 5 gallon ones in now) and will fill in proper mix as I was battling bad bumper washer coupling that was leaking like a sieve.

Boost issue is fixed?

Possible, but unlikely that the torque intervention is from ARMD.

When I get home, I can give you a handful of condition bits to log that will narrow down the source if you would like.

OMFG.  can you summarize that?  I f'n hate the timing interventions so much.  They are wickedly difficult to understand, let alone track.

Agreed for big turbo/laggy setups.


I will be sure to add that list to the s4wiki :)

These bits should help identify the root of the intervention.

The torque variables that I added summarize the torque fast path.

Thanks.

Added here sans the extra carriage returns ;P

http://s4wiki.com/wiki/Tuning:torque_intervention_diagnosis

Thanks! I will log tomorrow to see what makes for a bumpy ride. I am getting quite a roller coaster for timing.

ok, now I could use expert opinion.

Car got faster, but I am still seeing it falling on its face timing wise very frequently (see jpg).

Please look at row 87, first timing drop. It shows b_zwvs set to 1 which means fast torque path intervention? How to circumvent this if I am otherwise requesting far more torque and have no limits that are even near load 180 (where the drop took place)?

Kill ARMD --> dmar_w is intervening... :) Set TMAR map to FF and it will never start ;)

Also check B_zwvz and tell me if it is set to 1, because there are more things that could set b_zwvs=1

Definitely see ARMD intervention. Also, consider using ECUxPlot :P

The problem is not ARMD.

The problem is B_llrein.

Killing dmar_w only hides the fact B_llrein is getting set.

I've updated the ecu file in my last post with a few more things to backtrack B_llrein.

B_zwvs is set only if B_llrein and B_zwvz are set or if B_llrein is set and dmar_w != 0.

That's it.

I think I know what is causing it...

In the spots where I get hit with timing penalty from ARMD, the nmot (engine speed) as logged looks weird. In these spots, it has either the same value as next/previous nmot measurement, has almost the same or jumps a lot forward if the previous measurement was overlapping... so the ECU thinks that there is a legitimate bucking involved while it is not true at all but induced by inaccurate nmot...

I will log with more variables phila_dot was so kind to list tomorrow but so far I think it is "nmod_w - nmot_w" calculation in ARMD that is inducing the dmar_w and consecutively timing retard to attenuate the perceived RPM jumps.

That's exactly what was happening with my car. If numbing ARMD isn't the right solution for it, i'd love to know what is.

Bad crank position sensor?

Or something in the tune?

What ps_w values are you seeing over 191 load?

Edit: back to drawing boards. Run with TMAR = 143 and thought I actually defeated ARMD intelligently.

I have correct versions of many of the things in that table... I assumed the table was right, but i'll go back and audit it.


I'm not sure ... from my reading of the FR this makes no sense. Can you explain further? Also by column I assume you mean row :)

Hold on, I need to revise what I said... Something weird with bin not saving right got me...

The problem is that idle speed control is being erroneosly activated.

dmar_w means nothing unless idle speed control is active.

The problem needs to be fixed not the symptoms.

What variables were inaccurate? I can guarantee the locations of the ones that I posted.

So b_llrein is set thorough my pull... I will try to track that. Any off the top of your head idea why though?

Clutch slip.

Negative to that on my setup. I am on conservative tune so far and twin disc clutch.. not even licking what the clutch can theoretically take. I feel no ghost of clutch slip tbh.

I had same exact interventions previously on completely different motor, k04s and different clutch which was holding NLS dump shifts at 6-7k @ 20+ psi without a problem so I am sure it could take normal torque just fine without slipping.

The whole problem is originating in inaccuracies of NMOT mesaurement.... or probably due to a fact that time measurements of NMOT are not taken frequently enough (or updated) and ARMD function pulls out the same data twice in a row or at least they are close enough to fool this module into intervention.

I look at out bible for a bit and b_llrein is always set after some conditions are met, like not in SA, warm motor, etc... I don't see how that really is a problem here. Second significant variable into setting b_zwvs (ignition retard condition) is dmar_w (page 624, module MDKOG) and that's the output of ARMD when anti-bucking is requested. I feel that suppressing dmar_w (set to 0.00) is the way to control this whole problem not some other bits unless of course it is possible to flip them somehow.

What I would really like to do is to somebody log stock S4 and see if this is happening there as well... I just fail to see how it wouldn't happening on stock motor too but the interventions would be essentially undetectable as the perceived bucking would be really small due to stock motor not really ripping through RPMs even close to what big turbo can do.

Something is off in the torque model triggering idle speed control.

B_llrein should not be getting set.

Did you consider that the inconsitency in nmot is a result of the intervention?

I added the variables to backtrack B_llrein to the ecu file on the first page btw.

And I still maintain that it's a hardware fault.
Whether the problem is with it missing a tooth on the sender or the clutch buckling.

If you can see nmot_w spikes or jumps on a 10hz or 20hz data logger, it means 100% that either ECU can't see signal properly or there are other issues...

I'm definitely leaning this way as well; some cars show very noisy rpm data, some don't... could it be that the crank position sensor hardware simply ages some and starts to get flaky?

Also, referring to another post which said altering KFDMDARO wasn't sufficient... if dmar > 50 then something really is up....

I will swap cps to a different one and see where that gets me.

Flywheel tone ring was impeccable when I was installing it so I am not leaning towards that being the culprit here but my chinese $12 CPS might be. The fact is that I accidentally ripped out cables out of my original CPS when removing tranny from iengine for n-th time (my build is a streak of unlucky events), forgot to uplug it :(.

Just to illustrate what I am talking about in my car. This is during WOT pull which is fairly smooth sans the timing retard which is definitely detectable. Look at delta RPM:


nmot_w      zwout       delta rpm       b_zwvs          

4962.75     8.25        79.25           1
5019        13.5        56.25           0
5025        15          6               0
5173.25     8.25        148.25          1
5188.5      15.75       15.25           0
5312.5      7.5         124             1
5336        12.75       23.5            0
5420        8.25        84              1
5476.25     11.25       56.25           0
5605.25     7.5         129             1
5566.75     12          -38.5           0
5648.5      7.5         81.75           1
5782.5      12          134             0
5744.75     12          -37.75          0
5905.5      8.25        160.75          1
5915.75     12.75       10.25           0
6006        12.75       90.25           0
6055.5      12          49.5            0
6162.5      7.5         107             1


So yes, it is a bit messy. I will look at other peoples' logs to see if they also get that.

I don't generally see any negative delta rpm during a pull in any of my logs.

Do you have an external rpm pickup (e.g. for a wideband)? Perhaps its injecting noise?

I have zeitronix that picks the signal up from rpm feed to cluster. I am not clear if this is direct feed from sensor, but I doubt it.

When setting up zeitronix I had to specify for it to divide signal by 6, which hints at the fact that ECU basically sends a signal for each cylinder at TDC or BDC, whichever, to the cluster. So it is not a direct feed from sensor by any means.

I installed second CPS just a moment ago, unfortunately it is the same chinese knock off as previous one so I don't expect any changes.

If this doesn't help, I will buy some quality CPS (maybe used or something) and see where I am at.

Thanks.

Have you been able to log those variables that I added?

I'm curious to see the result.

This is either clutch slip or pickup issues.
Fix this before you do anything else.

Seems I'm having the same issue as julex, messy rpm.
I need to check older logfiles to see if this has always been like that.
And I have Zeitroniz Zt-2 installed with rpm signal taken from the same place as julex. Coincidence?

I'll log, most likely today. Was busy this past weekend with family, kids, etc  ;)

New CPS does the same... I can probably rule that out.

I will swap ECUs too, I am having my o2 sensor going off line occasionally not solved by swapping sensors either so I will see if ECU solves that.

So where are people without problems picking the rpms signal from? I understand that coil or injector would work... but I want to avoid tapping into engine harness or run wires into engine bay. Tach hookup is such a neat place to plug zeitronix in. I will disconnect it today (just two screws and cluster pops out, hookup is right there on cluster harness) though to see if there is any change in rpms going wild.

I analyzed elect diagrams and RPM feed to cluster is a different circuit from CPS altogether. I disconnected zeitronix just for hahas anyway, no change in rpm readouts... I guess I will get brand (bosch) cps and see where it gets me.

Anybody has one for sale cheap? [:)]

I have a good used one. Not sure if that helps you, you can borrow it for testing purposes.

Forgot to mention, my zeitronix is also connected to that RPM feed... and no problems that I can tell with RPM data.

Just so we're on the same page, I have a spare ckp, not cps.

Thanks for offer, I just bought one on ebay. $20 for a well looking and working bosch is a good deal.

What's CKP ? :)

ckp=crank sensor
cps=cam sensor

Thanks. I had them mixed up then. I always though CPS = Crankshaft Position Sensor... makes sense when you look at acronym and full name, no?

Anyway, I did some more logging and I am getting erratic RPMs all over the place but mostly visible and detectable when constantly accelerating as the RPMs should not fluctuate like this (see attachments). This is full pull from 2k to 7k with very little torque initially so I can safely eliminate clutch slip. I conditionally formatted RPM column to show in green proper RPM increase over previous cell and in red where RPM readout show less...


I am getting replacement CKP today, original Audi bosch so we will see where we are after this.

The only other variables left on the table are:
- clutch tone disc
- TDI tranny which might have different spacing of CKP sensor from tone ring than normal S4/A6/allroad tranny...

Which coils are you using?

2.0 fsi conversion and before you ask... yes ground is coming from ECU (or wherever it is coming from on original ECM module feed), not bolted to common ground on head... I will put this down as possible culprit.

Edit: I looked at electrical diagrams and in stock mode both grounds are coming from the same ground location on firewall... so I doubt it is the ground itself.

Can you post the whole log?

Here you go. TMAR = 143 on this run though as I am sick of ARMD playing yo-yo with my timing. Pull starts at row 544.

Wow your RPM data really is a mess :(

Do your zeitronix logs show the same lumpy rpm?

Yup. Since ECU feeds cluster with pulses, the same variability is visible albeit zeitronix is not as accurate in sampling as NMOT_W.

And who is the manufacturer of the coils?

ELDOR or something like that. Supposedly original audi/vw coils.

What about your coilpack harness, is it the very first with old black corroded?
Maybe it will help to redo the wiring all the way back into the ecu.

The wires themselves are pristine and crimping job is very nice with enviro seal butt crimps.

I have a feeling pjr is on the right track. My home made coil hookup is sharing grounds which would naturally route the coil side through common ground... I will redo one side and see if the rpm fluctuations subside.

I have a small bone to pick with you :).

I was trying to use EcuX to graph my RPM fluctuations but failed. I attached a screenshot I concocted.  

.CSV file I am using with RPM data is not properly, e.g. value to value, displayed in EcuX. The RPM data points I am trying to graph are instead some averaged (I think) values. This hides the jumping RPMs which I am interested to see.

I am specifically looking for that 6446 rpm data point which is lower than previous data point, which is not showed on graph.

Is this due to EcuX Plot interpolating data? Can this interpolation/filtering/averaging be disabled as an option?

Thanks.

Julex: yes, by default the RPM signal is filtered.

I have a build where I have an unfiltered RPM, but i didn't release it :(

you can pull the sources and build your own if you want, since i did push the changes to the repo.

I have some cosmetic things i need to fix before I make it formal.

Cool, no rush on this side. I just wanted to report this as possible change for the future. I have to use excel anyway for conditional formatting and nice colors for cells to see trouble areas.

Thanks.

Original are Bosch.

Change the coils to Bosch or Beru and your problem should disappear.
BTDT.

Another thing, I recall reading in one of the original coil conversion threads that running a shared ground was causing issues that were resolved by grounding each coil individually?

And why not solder the connections to the coils rather than crimping them? I was chasing down a periodic no start with my car, turns out the PO had pulled the crank sensor wiring out of the main harness and crimped it back on. Despite the connections looking good I ended up soldering them and haven't had an issue since.

Long term, proper crimping is considered better than soldering, especially if you are using lead free solder.

Especially in a high vibration environment.

I crimped these wires and I am very confident they will last especially that I used environmental heat shrink butt splices for that. I had to undo couple of splices and I could not pull the wires using any amount of force in my hands. I had to eventually cut it.

PRJ:

Ok, I will invest in new coils... Thanks 034 for selling me junk. Are the red ones what I need or do I need to specifically look for Beru, which I think I only found for 1.8T engine which I believe is the same thing but maybe you know better?

You can get 2.0 TFSI coils.

Bosch and Beru both make them.
07K 905 715 F
Just ask specifically for Bosch or Beru. Both work.

I mean, I can't tell you with 100% certainty this will fix the problem, but I have had similar issues on multiple Audi I5 engines in the past.
Cheap italian coils causing RPM signal issues as well as giving enough interference to knock out my USB hub in my laptop (emulators connected to ECU), so that I had to reconnect everything after each pull.

Set the dwell time right as well. Hard limit should be 2.5ms and dwell at 13V should be around 2ms at peak load.

Thanks.

Redid the grounds (pin 4 to valve cover on all coils) but it didn't help any with rpm issue. Well, at least they are grounded right now so I guess I will get new coils and then address tuning (B_llrein set to 1 all the time).

After searching for quite a bit I ordered bosch 06H905115A coils which are fairly cheap too. I will keep you guys up to date on developments concerning choppy RPMs.

(http://c1552172.r72.cf0.rackcdn.com/168327_x600.jpg)

latest release adds "RPM - raw" and "Calc acceleration - raw"

Awesome!

Update:

Installed BOsch coils and the rpm dance still continues... If this is hardware then it must be tone ring... which is pristine and positioned as it should... I am at a loss. I would like to see others' pull logs with nmot_w (preferably 400whp+) to convince myself that I am special here.

I am off to try figuring out why b_llrein is set to 1 everywhere. I look and look and look at page 742 and can't figure out what would set it. Specifically section with dmllri_w merging with mill_w with a symbol between them that I cannot find definition for at the beginning of book.

Anybody has any insight?

That symbol is addition.

If you log all of the variables that I added to the ecu file, then we can backtrack it.

I do have them but they don't make sense to me. Here is the log. Intervention can be seen during actual pull 3000+ rpms where  B_zwvs is set to 1.

Edit: log is from few days ago as I logged wrong .cfg today but nothing changed since then in ARMD intervention so it still applies.

Well I had mistt incorrectly defined as 16 bit.

I'll grab a log today to compare.

I don't see why you are guys logging intervention variables and so on, when the RPM jumps around.
What does it matter? Once the problem is fixed, it is likely much of the intervention will be gone as well.

There are no problems with RPM even at 700 whp.
And in fact the amount of power you run has absolutely nothing to do with you getting trigger errors.
You can uninstall your turbos, and guess what, you will still have the exact same problem.

Okay, it weren't the coils, so next step is to take a close look at your wiring loom and your flywheel setup.
Be happy that it even runs - an aftermarket ECU would've screwed up long ago.

This thread seems like a perfect example of people forgetting the basics.

Wiring appears ok. I have OEM bosch CPS in now too to rule out chinese pos I had in there, no change.

I don't have any kind of drivability issues whatsoever except for this odd RPM readouts...

So... that leaves tone ring... Any idea how to verify if it is ok? are there any specs at to where the tone ring and its gaps should be located in respect to inspection/vent holes in bell housing/sensor hole?

Thanks.

That's because the ECU is so good...

Try looking at the signal with a scope and checking what you see. My guess is that will be either really noisy or the peak to peak will be insufficient (sender too far or offset from teeth).
The reason for your RPM jumping up and down is because some teeth edges are not detected by the ECU.

So here goes the question then which might solve my problem. The car is an allroad. CPS sensor came with this between itself and bell housing hole from factory, or at least that's what I found there:

(http://dus72.users.photofile.ru/photo/dus72/96281351/large/127317497.jpg)

Is this a standard part for S4 transmission (I have TDI now)? I know that supposedly all 01e housings are identical but you never now.

Mine has one.

Cool. I ordered chinese special nano oscilloscope and we will see. In the meantime, I will inspect tone ring placement via sensor hole and try lowering it in by removal of spacer to see what the effect might be.

If you remove that spacer the ckp will hit the tone ring before it bottoms out.

I'll verify that. Since I am having possible problems with properly detecting teeth (well, the are really gaps), one possible culprit is sensor being too far from ring. If I remove the spacer and still don't hit the ring... right there.

My clutch is older model clutchmasters Fx700 so who knows what kind of teething problems I might have on my hands here. I am lucky in that I still have my old tranny in my garage as well as couple of engine blocks and clutches so can look up things and see what the hell is going on.

Another option would be to put a piece of felt on the ckp and rotate the engine. Mill the spacer down a little at a time until the felt peels off after a revolution. That'll get you as close as possible to the tone ring without interference.

good idea.

Did some logging and wanted to report that I was wrong.

B_llrein was set during the entire drive. I suspected it would be after having another look at the code today because once set, B_llrein can only be cleared if B_nmot is clear. From my log, mistt remained zero throughout the entire log (B_llrein was set the whole time - see %STMD) and mill_w + dmllri_w was never <= zero.

Conclusion, dmar != 0 triggers instant torque intervention on ignition angle. B_zwvs is set which clears B_nozwe causing a switch from zwbas to zwsol.

Sorry if I "forgot the basics", but I don't discount anything when troubleshooting. That's how things get overlooked.

Ok, so the conclusion is that intervention is a result of a perceived bucking of a car which is caused by errorneous rpm signal which Maes it look like rpms are fluctuating around.

I am going to inspect hardware and report back.

And I just don't see how various torque related things are going to cause nmot_w to go for a zigzag walk.
It is one of the base inputs of the ECU. If it's wrong, any calculation in the ECU relying on it is going to be wrong.

I would look at GGDPG and try to find exactly what the problem is.
There are a a few flags that get set if a tooth is missed (because the gap is in the wrong spot) and so on.

I inspected the alignment of ring in sensor hole and it is as centered as it is possible. The sensor hit the ring once this little 2mm spacer is removed so the distance is right too...

This leaves, I think, the wiring... Which might be damaged since as I mentioned before, I forgot to remove original CPS when separating tranny from engine and as a result the CPS wiring got ripped apart right at the sensor... This certainly had to put tons of pressure on at the connector and the wires behind it though and possibly damage them.

I ordered oscilloscope too. I think I will scope the signal first before I go ahead and rip harness apart though.

I don't think this is a hardware problem.
People call the Crank Sensor an Engine Speed Sensor but it's not just speed... it's the fundamental timing of the engine. That 60-2 tells the ecu exactly where it is. It's also used for missfire calculations.
If the signal is wrong or inaccurate you would have all sorts of issues.
You would also likely get fault codes for the cam sensor timing. The ECU compares the cam sensors to the crank sensor at all times right?

I suspect that teeth miscount would create timing problems and codes for cam shaft position sensor so you might be right. One tooth off on crank would probably throw everything off enough to register a code... But who knows. I just put TMAR to 143 deg for now.

I put 530 calc whp down today on my way to work, weee.

I dont think it will not log anything for one or two teeth missed, it will correct, look at the FR.
If it's "not a hardware problem", what are you suggesting then? A bug in ME7? That's pretty bold.
Have you looked at GGPDG at all before writing this? Do you know where nmot_w comes from and how it gets calculated?

It's really not normal to have a noisy nmot_w. And there are very very few things that affect how nmot_w is set up in the first place in ME7.
If it's oscillating like that, it means that either the actual revs are oscillating like that as well, which would indicate pre-ignition, but I think OP's engine would have been melted by now in that case or a problem with the crank trigger pickup.

Sorry I miss spoke... what I meant was I don't think it's a hardware issue with the crank sensor... I didn't mean to imply that it was a software issue...
I'm not sure what the problem is, I'm just throwing out there I would expect to have other side effects if it was the crank sensor.

/bows to prj.

Last night's update:

Used borescope and planted it just above the ckp hole, spun the crank two revolutions tooth by tooth (that took a while) while watching the screen, they were all good, no sight of any damage whatsoever. Everything aligned perfctly, etc.

So I moved onto the electrical components and what do you know. Remember the cable rip at ckp that prompted me to get a new one? It also almost killed one of the wires at sensor plug but it the damage was invisible since mine has actual weather boot. The wire was literally hanging on 1 strand of copper which separated upon light pull once I wiggled it.

So I spliced connector from different harness using enviro heat shrink splices, then topped it off with two layers of heat shrink tube. Preliminary light throttle pulls 2-7k show no more of the rpm wobble but I will confirm today after doing couple of WOT pulls once I get out of town, so to speak.

My idle rpms seem more stable too. Previously they would be dancing a bit without any corresponding engine sound changes.

Awesome! Glad you got it figured out.
I guess I was wrong about it not being the crank sensor haha. It happens.

Ok, and NOW do pulls, and log what phila_dot suggested.
Sorry for getting you to buy unneeded coils, but I did not have the car here, etc ;)

Best news ever. Glad you got it sorted!

hmmmm,

Still got ARMD intervention but the RPMs don't dance around anymore. There is a tiny bit of non-linearity in the RPM slope though which I can only associate with timing changes (due to retard) and my flexible shaft in TDI tranny and possible intermittent traction loss (but not likely in third, in second gear though I was all over the road :))

I can't describe it but the flexible shaft makes me feel sometimes like driving with big rubber shaft especially in shifts/load transitions. I also have an unforgiving LWFW twin disc unsprung clutch which has zero cushioning so any changes in load, road condition etc get directly conducted to flywheel/ckp.

At this point I am REALLY interested in dampening ARMD response to high load "bucking" of car as I feel that any possible hardware shortcomings got addresses here.

Since my previous experiments wit KFDMDARO resulted in null results, what else can one touch to tell ARMD to ignore jerking at high load condition? KFDMDAROS?

can you post logs including dmar and the various armd variables?

Still chasing it, so far I suspect that the KFDMDARO table we know to exist @ 0x1DE1C is not really the one in use, I wonder if similarly to ME 7.1.1 ECU (which has three variants of this map), M-box also has more versions... When logging KFMDMARO output via out_KFDMDARO_w @ 0x3828E6 (word, unsig, 0.00305176 factor) I am getting flat "5" output even if I put all "FFFF" ("100" in table) in all fields in KFDMDARO. It must be pulling from othjer variant of this table as my changes don't affect output at all.

Can somebody with assembly know-how check where the heck is that table really located? Unless I am wrong again ofc....

Thank you.

I posted every variable from the entire function in that ecu file.

Now that you mention it though, I think I do remember that some of the map addresses floating around where wrong.

I'll check when I get home and verify the map locations.

Stumbled upon something...

Locations:
0x1DE1C
0x1DE7C


hold the values for two *DARO* tables. I am fairly certain that what we defined as KFDMDARO table @  0x1DE1C is really KFDMDADP and real KFDMDARO is next up, at 0x1DE7C.

This would make sense as my logging to date showed no apparent change in KFDMDARO output while (now I noticed while posting!) KFDMDADP output was indeed at a 50 (improper conversion factor for the variable I listed in previous post, it should be 100).

I will confirm shortly after logging session but I think I found the way to attenuate the ARMD for any torque request you want, stock 50% and up is more than enough to remove ARMD intervention while in WOT.

Definitely looking forward to a simple description of this and exactly what tables to modify when you have reached a conclusion of your work.

Julex thanks for your work (and phila, as usual)

let me know and i will release a new XDF as soon as I get the right locations.

As it's gear related have you tried leaving 3rd gear stock and 4th setting the 50+ row up at 100% to override the intervention and see if that helps your issue? 

I can't say I've had the same issue as you but I have set KFDMDADP on all gears 2 and above and the 42&50 rows to 100.

I don't have KFDMDARO or KFDMDAROS on my file so only ran with this.

KFDMDARO
0x1DE7C

KFDMDAROS
0x1DEDC

KFDMDADP
0x1DE1C

SMK08MDSW (mkar_w axis)
0x1DF8E

DMARMX
0x19B9D - tmot axis @0x19B97

My ARMD interventions are over!

Solution:

1) inspect xdf pack. If KFDMDARO is at 0x1DE1C, change it to 0x1DE7C
2) alter KFDMDARO at column "50" (% of torque engine is generationg, this is NOT load!) and put in 100% for all gears, or however you feel it should be appropriate.

Page 638 diagram explains how it works. Input dmarv_w is compared to output of several tables and appropriate bits are set. KFDMDARO gets %torque (x-axis) and gear (y-axis) and resulting threshold is returned. If dmarv_w is larger than table value, you get intervention in torque % amount via fast path timing change.

Setting a cell to 100 causes the condition to be no longer valid and rpm deviation is ignored.

Can I just check your not setting KFDMDADP? To 100.

I ask as I have 4 KFDMDARO maps 0-1-2-3.. 3 are the same and 1 is very slightly different..

I'll try setting them all to 100 on the 50 line...

Also I set DMARMX to 1 across the map.

I don't have the PDF in front of me but for kfdmdadp to be active for comparison, b_dashv or whatever the bit is must be which is not in my case. Having said that, I set kfdmdadp to 100 too as I don't attenuation with neither increasing nor falling while being over 50% torque request.

I know the kfdmdadp alone doesnt work as to date everyone had bad set pack with kfdmdaro actually pointing to kfdmdadp map location and changes weren't in effect when going wot.

SGA06MDUB is not correctly defined based on this information.

The axis reads:  3, 4, 5, 6, 255, 6
Should read:  1, 2, 3, 4, 5, 6

right?

DMARMX as defined here is defaulted to 0.00 for the entire table.  Is this correct?

Finally:  Please confirm:

KFDMDADP:    0x1DE1C           6x8
KFDMDARO:    0x1DE7C           6x8
KFDMDAROS:  0x1DEDC           6x8

All three share the two axis you showed before.


If I get some clarity on all of this, and of course I'll continue researching, then I have a good XDF for the community ready to go / fully updated.

Yes SGA06MDUB should be 1-2-3-4-5-6 relating to gangi

Dmarmx in my case goes from 1.17 @-9 to 2.89 @110, its not linear though, more weight to higher temps. I've set this to 1.17 from the whole table.

The other 3 do share the same axis, gangi and ???

can you clarify the address / details on your working SGA06MDUB?

Can you please clarify your details on DMARMX too?

It's all in my post on the previous page...

The gangi axis doesn't exist...the stutzstellen variable is created from gangi and then just used to calculate the map location. Just label it in your definition.

As for axis length, it's identified in the hex just before the axis.

OK, well give what was shown before, here is the XDF:
DMARMX and SGA06MDUB require fixing.
SGA06MDUB is just an axis, so it just shows the axis values wrong, that's simply ugly, but non consequential.
DMARMX is totally wrong.   Somebody should take a screen shot of their exact settings in tuner-pro, because there isn't enough information as described so far.

Here is the entire DMARMX setup.  Please tell me what's wrong so I can correct this for the XDF.

SGA06MDUB is repaired.  The address is 0x1A603 not 0x1A605.

Just need a response on correct changes for DMARMX.

How does this look for DMARMX?  Is this correct?  Randomly searched up and down from wrong address.

Nope, first one's correct.

0x19B9D

It's all zero. I would do one row and six columns though.

This axis doesn't exist.


I just use external (manual) for the label source and punch in the values.

Interesting. I've always had the right value. Not sure where the wrong value came from

"KFDMDADP","0x1de1c","Upper threshold for torque intervention under dashpot","8x6","16 Bit (LoHi)","-","%","%","-","0.001526","0.003052","1.0","1.001056","20.002808","0x290","0x3334"
"KFDMDARO","0x1de7c","Upper threshold for torque intervention","8x6","16 Bit (LoHi)","-","%","%","-","0.001526","0.003052","1.0","1.001056","20.002808","0x290","0x3334"

I got my XDF when NYET posted it and all my locations are right.

I am running a different flash version namely the 018CB

but here's a copy of the stock DMARMX from the file and the tunerpro definition

DMARMX has the axis TMOT,

Also WPEDU is the lower threshold limit for Bucking. This is set to 100% on mine. Have you tried setting it to 90% so WOT the bucking isn't active?

I am not sure, It was either inherited from a very old XDF pack or I picked it from PRJ's auto generated XDF which has wrong location since KFDMDARO and KFDMDADP are identical and what his auto generator hit first and marked as table's location.

Anyway, I am happy this enigma (on my end) is sorted out after all the time I spent trying to fix hardware problems which are still there.

Here's the XDF reflecting all of the changes including the suggestions above.
Has KIFZGHG, DMARMX, KFDMDADP, KFDMDARO, KFDMDAROS, and most of the relevant axis tables.
Please look in section ARMD:  10.50 Antiruckel of this tunerpro xdf.

Back from dead just to point out one thing.

Albeit my ARMD interventions went away after fixing harness, I still have large RPM/S fluctuations as pointed out earlier in the thread... I thought it is not normal so I grabbed several third party logs from forum and what do you know... Looks like everyone has wild fluctuations in RPM/S graph so it is just the way ECU calculates this stuff that is not very accurate. That puts and end to my OCD on this subject.


My chart (mbox_large) actually looks pretty good considering how other do.

rpm/sec has noise because of time data quantization jitter..

a HUGE problem when numerically differentiating... which is why ecuxplot has such a heavy rpm and rpm/sec filter...