If you're using the moving anchor filter, its two settings define another threshold below which tpsDOT is set to zero. In my own logs, I don't see any tpsDOT other than 0 between -35 and 35, but plenty outside this range. This works well with my tpsThresh set to 40 (for reasons I've explained elsewhere). If you check your logs you may have some sort of a gap in the middle too in which case a small tpsThresh isn't having any effect.

In any event, I don't imagine there's much need for enrichment at this slow an opening rate.

robs wrote:In my own logs, I don't see any tpsDOT other than 0 between -35 and 35, but plenty outside this range. This works well with my tpsThresh set to 40 (for reasons I've explained elsewhere). If you check your logs you may have some sort of a gap in the middle too in which case a small tpsThresh isn't having any effect.

Rob, that would be a function of "tps_variation" and "tps_persistance", of which depending on the values you could get lower than 35 tpsDOT.

Can you think of any real reason why you'd want to limit the lower values of "tps_variation" and "tps_persistance" if the results continue to be free of false-AE triggers?

I can only assume eventually you'd get to the mechanical limit of your right foot - where your foot is actually producing noise in terms of slight throttle movements... but in that case, you still may want to enrich etc to smooth out the AFR? Arguably that could be done by changes in MAP via the VE tables, but I wonder what the effective cut over point is... and again does it mater?

weeblebiker wrote:Any thought of applying the idle pid control changes to the boost control?

Which specific changes?

Adaptive PID (only released for idle in 2.4.4) for boost control would probably be worth doing... assuming you had a target to aim for... whereby when the boost is on target, it would apply very little PID terms, but when outside of target, it would apply a % scale of PID terms to quickly bring the control back into line (but avoid the oscilation when on target).

gslender wrote:Rob, that would be a function of "tps_variation" and "tps_persistance", of which depending on the values you could get lower than 35 tpsDOT.

Yeah, I was too lazy to look in the ini file for what you'd called them. I wasn't meaning that nismoautoxr should see the same gap as me, just that the gap is there if you're using moving anchor. So I can be clearer now, choosing values for these variables:

tps_variation -- smaller means more sensitive to small variations, but more sensitive to noise too. Probably aim to set this to something a bit larger than the typical noise you see from TPS.

tps_persistence -- larger means more sensitive to small variations. If this value isn't large enough, slower real throttle movements will not set a tpsDOT value.

gslender wrote:Can you think of any real reason why you'd want to limit the lower values of "tps_variation" and "tps_persistance" if the results continue to be free of false-AE triggers?

I can only assume eventually you'd get to the mechanical limit of your right foot - where your foot is actually producing noise in terms of slight throttle movements... but in that case, you still may want to enrich etc to smooth out the AFR? Arguably that could be done by changes in MAP via the VE tables, but I wonder what the effective cut over point is... and again does it mater?

I think MS2/Extra's approach to TPS enrichment isn't really up to smoothing out AFRs on such small movements and it's probably better to rely on mapDOT.

weeblebiker wrote:Any thought of applying the idle pid control changes to the boost control?

Which specific changes?

Adaptive PID (only released for idle in 2.4.4) for boost control would probably be worth doing... assuming you had a target to aim for... whereby when the boost is on target, it would apply very little PID terms, but when outside of target, it would apply a % scale of PID terms to quickly bring the control back into line (but avoid the oscilation when on target).

If it wasn't for this gslender mod; I would have gone back to ms1. Working great now. The only issue I have is adaptive idle advance isn't working correctly. Only works with rpm or load no rpm delta tho.

andodo wrote:If it wasn't for this gslender mod; I would have gone back to ms1. Working great now. The only issue I have is adaptive idle advance isn't working correctly. Only works with rpm or load no rpm delta tho.

Any reasoning behind this?

you need to have a CLT idle target for the adaptive to work. Post ya MSQ if that doesn't solve it.

This uses 3.3.0b gslender 2.4.5 (prerelease version), which has another small tweak I'm testing- adaptive idle VE, which does for idle VE what adaptive idle advance did for spark. It has a much subtler effect that AIA, but works the same way. There is a VE adder vs RPM target error curve, which adds to gVE- richer when below target, leaner when above target, in tenths resolution. This gives a faster but subtle fuel response, again like AIA.

I know, it does add yet another layer of complexity, but the data does support it. This is a scatter graph without AIV:

With AIV turned on, note that the RPM clusters around target more. There is a mild trend showing AIV working, with the AFRs richer below target. Very subtle.

I also found AIV has a beneficial effect on WUE, correcting for less than optimal WUE curves.

I do suggest not having EGO correction on for the idle area. Needless to say the basic spark, VE tables and PID should be tuned before even attempting to mess with the advanced idle modifications

This uses 3.3.0b gslender 2.4.5 (prerelease version), which has another small tweak I'm testing- adaptive idle VE, which does for idle VE what adaptive idle advance did for spark. It has a much subtler effect that AIA, but works the same way. There is a VE adder vs RPM target error curve, which adds to gVE- richer when below target, leaner when above target, in tenths resolution. This gives a faster but subtle fuel response, again like AIA.

I know, it does add a layer of complexity, but the data does support it. Needless to say the basic spark, VE tables and PID should be tuned before even attempting to mess with the advanced idle modifications

Note also that whilst some may think "but I can easily get very stable idle with my car without this mod", we are getting these results on 1.6l 4cyl engine with a single throttle body (pre SC), with a hot-side supercharger and water intercooler, and agressive cams, plus factory AC thrown in to just mix things up

Normally with the standard base ms2 code you'd struggle to get such a stable and well behaved idle. Greg's results is testament to the continued research and testing he has done in trying to extend and expand the capabilities of what can be done with managing fuel & spark during idle conditions.

Very interested to hear from other folks who have had previously difficult to tune idle and what has contributed to making it stable when using this latest mod.

I'm having trouble with the AE on my car, trying to get it nailed down from a 2k stab (don't laugh its a 2.7l 325E and the tach only goes to 5K) has been driving me nuts. I'm having trouble understanding how it works when you go WOT real fast. Does MS just use the first value that triggers AE or does it update if it sees a higher value? I seem to get varying amounts of enrichment when I stab the throttle and the duration doesn't seem to last as long as I have it set for. The enrichment amount also varies a lot right when I stab the throttle (sort of like its tapering off right away. In the attached log you can see the what i'm talking about. First there is a spot where I go WOT from ~2k in second gear and just after that MAP AE gets triggered and the duration is longer and more even then when I went WOT. Just trying to understand this so I can get it figured out of course but also so I can get it nailed down better when I get the MS3 on my mustang and running. Also, part throttle AE seems to be alright.

nitrousdave wrote:I'm having trouble with the AE on my car, trying to get it nailed down from a 2k stab ....

...is there a reason why hijacking this thread here makes you think you'll get help? if you are having problems with AE then you really should move back to another non-mod firmware first, and perhaps have a read of this Forum Etiquette guide... https://wiki.archlinux.org/index.php/Fo ... _Hijacking

sorry for being so harsh, but just posting a "help me with my AE" seems a little pointless given the current topic and discussion??

Well excuse me I figured since I'm running your firmware that this was the best place to ask this question and avoid getting told to post here since this is the firmware I'm running. Since there is no specific title to this thread other it being your firmware I figured it was the best place to post it, apparently I was wrong.

nitrousdave wrote:Well excuse me I figured since I'm running your firmware that this was the best place to ask this question and avoid getting told to post here since this is the firmware I'm running. Since there is no specific title to this thread other it being your firmware I figured it was the best place to post it, apparently I was wrong.

take it easy - no need to get all twisted about this - i'm simply asking for a little thought when posting into an existing thread with a random topic as disconnected as you have.

if you have issues with the specific changes in this mod, then yes post away. if you have problems with tuning standard things like AE then please don't upgrade to this mod and then ask how to fix them. nobody wants to troubleshoot your problems when maybe the issue is the mod. conversely, I'm not interested (nor able) in solving everybody's tuning issues just because they decided to try this mod.

i think it is reasonable to ask that you first get your tune working reasonably first - and if you having issues, be prepared to downgrade back to a supported release (which actually would be 3.2.1) so that others (including the ms2extra devs) can possibly help you.

please remember that this isn't a paid support forum. people are donating their time freely for nothing in return, so a little respect for those helping goes a long way.