|
nyet
|
 |
« Reply #15 on: January 11, 2013, 10:09:21 AM »
|
|
|
Definitely see ARMD intervention. Also, consider using ECUxPlot  |
|
|
|
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #16 on: January 11, 2013, 04:09:56 PM »
|
|
|
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.
|
|
|
|
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #17 on: January 11, 2013, 04:21:22 PM »
|
|
|
Also check B_zwvz and tell me if it is set to 1, because there are more things that could set b_zwvs=1
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. |
|
|
|
|
Logged
|
|
|
|
|
julex
|
|
« Reply #18 on: January 11, 2013, 06:19:48 PM »
|
|
|
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.
|
|
|
|
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #19 on: January 11, 2013, 06:22:40 PM »
|
|
|
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...
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? |
|
|
|
|
Logged
|
|
|
|
|
IamwhoIam
|
|
« Reply #20 on: January 12, 2013, 04:00:28 AM »
|
|
|
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.
What ps_w values are you seeing over 191 load? |
|
|
|
|
Logged
|
I have no logs because I have a boost gauge (makes things easier)
|
|
|
|
julex
|
|
« Reply #21 on: January 12, 2013, 11:01:13 AM »
|
|
|
Edit: back to drawing boards. Run with TMAR = 143 and thought I actually defeated ARMD intelligently.
|
|
|
|
« Last Edit: January 12, 2013, 12:12:57 PM by julex »
|
Logged
|
|
|
|
|
nyet
|
|
« Reply #22 on: January 12, 2013, 11:15:24 AM »
|
|
|
I appreciate you guys sharing the info on variables but most appear inaccurate (signed vs non-signed) or even have wrong addresses (nothing logs) so I was stabbing a bit in the dark...
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. Changes I made were to KFDMDARO table. Last column brought to 100 for all gears so that it never sets b_TVARSS for torque (not load!) over 50%.
NOTE: During my fight with ARMD I set KFDMDARO last column to 50 as advised in other thread... that didn't help much if at all. Apparently input compare exceeds 50 so 50 coming back from KFDMDARO was not enough to leave b_TVARS false.
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  |
|
|
|
|
Logged
|
|
|
|
|
julex
|
|
« Reply #23 on: January 12, 2013, 11:24:40 AM »
|
|
|
Hold on, I need to revise what I said... Something weird with bin not saving right got me...
|
|
|
|
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #24 on: January 12, 2013, 12:09:44 PM »
|
|
|
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.
|
|
|
|
|
Logged
|
|
|
|
|
julex
|
|
« Reply #25 on: January 12, 2013, 01:46:05 PM »
|
|
|
So b_llrein is set thorough my pull... I will try to track that. Any off the top of your head idea why though?
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #26 on: January 12, 2013, 05:01:28 PM »
|
|
|
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?
Clutch slip. |
|
|
|
|
Logged
|
|
|
|
|
julex
|
|
« Reply #27 on: January 12, 2013, 05:40:38 PM »
|
|
|
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. |
|
|
|
« Last Edit: January 12, 2013, 05:44:04 PM by julex »
|
Logged
|
|
|
|
|
phila_dot
|
|
« Reply #28 on: January 12, 2013, 06:35:04 PM »
|
|
|
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.
|
|
|
|
|
Logged
|
|
|
|
|
prj
|
|
« Reply #29 on: January 12, 2013, 06:55:40 PM »
|
|
|
The whole problem is originating in inaccuracies of NMOT mesaurement.... 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... |
|
|
|
« Last Edit: January 12, 2013, 06:57:17 PM by prj »
|
Logged
|
|
|
|
|
