[FW MOD] ms2extra 3.2.1 gslender v2.2b

[gslender]

UPDATE : This firmware has been updated to v2.2c - see this thread >> http://www.msextra.com/forums/viewtopic.php?f=91&t=43793

G'day...

This modified firmware is based on the released MS2/Extra 3.2.1, and adds several enhancements designed to improve idle stability during load events, such as AC and other engine loads. See post http://www.msextra.com/forums/viewtopic.php?f=91&t=43370 for the prior release/s.

This v2.2b update is a release to the mods I've previously added and includes the following changes:

• Support for MS2/Extra 3.2.1 release
• Added RPM/TPS/MAP/EGO Median Sliding Window filtering/smoothing.
• Added Dynamic Dashpot (but config disabled in this release until more testing/feedback)

Docs >>

gslender.mod.application_notes.pdf

(668.18 KiB) Downloaded 383 times

Firmware >>

ms2extra_3.2.1_gslender_v2.2.zip

(222.7 KiB) Downloaded 158 times

Source >>

ms2extra_3.2.1_gslender_v2.2_source.zip

(544.87 KiB) Downloaded 86 times

Enjoy
G

[muythaibxr]

I have already implemented a "dynamic dashpot" the way I want it implemented in MS3. Please remove your implementation from here. I will give you what I did.

Same thing for the sliding window code... we told you we had some things we wanted testing on before doing anything in MS2.

We did tell you were doing those features, so in the future, if I say something like that, please talk to me privately before releasing (or rather not releasing) any firmware mod that contains conflicting features.

Ken

[tpsretard2]

is your new dash pot adder in the bata17 for ms3?
if so i must admit it works how i think a dashpot should work, nice job there..

[muythaibxr]

is your new dash pot adder in the bata17 for ms3?
if so i must admit it works how i think a dashpot should work, nice job there..

Haha, no it's not there, I just implemented the new functionality in what will be beta 18 this past weekend.

Ken

[gslender]

updated firmware.zip to include forgotten license.txt file...

[Red_Baron]

Installed this firmware.

Quick question - is it possible that a poor TPS/MAP signal that my MS was getting could contribute to decreased top-end power? It just seems that the TPS and MAP are completely flat and not jumping about, and the engine has just suddenly 'come alive' over 5000rpm, it goes like stink.

I was thinking perhaps quick changes in TPS or MAP position could cause it to use incorrect (imperfect?) timing/fuelling briefly during a wide-open-throttle pull?

RB

[Black99rt]

Did your pulsewidth used to dither on a pull? If it used to, and it doesn't anymore, your cylinder to cylinder AFRs are probably more normalized now.

Very small false trigger fueling costs me about 2 tenths at the track. Cleaning it up was a noticable difference on the street too.

[gslender]

Yup. I've noticed improved engine performance from having the MAP and TPS jitter reduced.

I'm not 100% convinced on the long term effect as there will be measurable response lag - fairly evident too!

So as long as you have the settings below 5 (I'm using 3) it will be fine.

I was half considering changing the settings from values to discrete drop downs like Small, Medium, Large, Extreme.

I may still do that, but it depends on what Ken and James offer up.

G

[pigga]

Hi all.
I upgraded to this fw yesterday. Engine seems to run even a bit smoother due to the new filter. So far I observed no negative effects regarding (map driven) EAE. I even had the impression that the engine runs more powerful at WOT and higher RPMs now, but that could be placebo/voodo/whatever. At least TPS seems obviously less noisy.
Btw: Compliment to gslender for his documentation of the mods he made. Really good work so far!
I would just like to ask some questions about how CL Idle is gonna work:
Is the "Daspot adder" still active? That means: Will I have to add the amount of the adder to the actual value of the initial-value-table to see what the "real" initial pwm duty will be?
Further more there is the Ramp-to-target, which -as soon as PID is engaged- moves (at least to my understanding) the target RPM from Target+adder to Target RPM itself within the ramp-to-target-time...
But there is still the PID-delay, so what's before PID is engaged: Will the idle valve dynamically open/close to the actual value from the initial-table, or is there one "snapshot" of value that is captured once the idle is engaged and then the wait-timer will run (with no movement of the pwm idle valve until PID takes over)?
Thanks,
Thomas

[muythaibxr]

For the dashpot, the way I implemented it in ms3 (which will be backported) the dashpot is still added to the initial value (or last good value). It then decays based on RPMdot back to the non-dashpot value.

Ken

[pigga]

Hi Ken.
Thanks for the Info.
I did some more investigation but for some reason the code goes back to the "valve open" PW% if CL Idle is engaged.
When I revert from "use initial value table" to "use last good known value" the initial PW% is last good+adder.
See attached MSQ.
Thomas

[gslender]

Hi all.
I upgraded to this fw yesterday. Engine seems to run even a bit smoother due to the new filter. So far I observed no negative effects regarding (map driven) EAE. I even had the impression that the engine runs more powerful at WOT and higher RPMs now, but that could be placebo/voodo/whatever. At least TPS seems obviously less noisy.

Yeah, it is a side effect I wasn't prepared for, but in hindsight having a more stable rpm/map in the x/y for the VE table would ensure the PW are more consistent and I guess that must be a "good thing".

Btw: Compliment to gslender for his documentation of the mods he made. Really good work so far!

Thanks - but I can't take all the credit. Greg G helped in putting that together, and I had the time for docs because Ken was so gracious in allowing me to port back a lot of MS3 stuff (and hopefully more to come).

I would just like to ask some questions about how CL Idle is gonna work:
Is the "Daspot adder" still active? That means: Will I have to add the amount of the adder to the actual value of the initial-value-table to see what the "real" initial pwm duty will be?

It is active, but if using IVT, then I've found I can set DP to zero, and just rely on IVT being a little higher. I guess it would depend on the engine as I don't have lightened flywheel or fuel cut or anything really dropping the RPM at a great rate (and the IVT sets the duty high enough for a nice drop to idle).

Further more there is the Ramp-to-target, which -as soon as PID is engaged- moves (at least to my understanding) the target RPM from Target+adder to Target RPM itself within the ramp-to-target-time...
But there is still the PID-delay, so what's before PID is engaged: Will the idle valve dynamically open/close to the actual value from the initial-table, or is there one "snapshot" of value that is captured once the idle is engaged and then the wait-timer will run (with no movement of the pwm idle valve until PID takes over)?
Thanks,
Thomas

Umm... I suggest you log and look at PWM Idle Duty and Status2 - when status2 goes to 128 the code has entered CL PID control and before that it is either at throttle_pressed whilst TPS is > 1 or then in throttle_lifted sitting waiting for closed valve timers/rpm thresh etc to allow CL PID entry. During that waiting period it sets the valve to the IVT value plus the DP if applicable (there is a difference to applying DP depending on whether you use valve_closed or not).

G

[gslender]

Hi Ken.
Thanks for the Info.
I did some more investigation but for some reason the code goes back to the "valve open" PW% if CL Idle is engaged.
When I revert from "use initial value table" to "use last good known value" the initial PW% is last good+adder.
See attached MSQ.
Thomas

Ken didn't do the DP changes that I made in 2.2b - I was experimenting with a dynamic dp concept and may have broken DP in that mod release. Sorry about that.

I've got subsequent fixes made, but would prefer to get Ken's MS3 implementation rather than re-release a fix for a mod that won't be taken forward (as Ken's approach in MS3 sounds better )

G

[pigga]

Hi all.
Think I found it out (hopefully): The negative temperature value in the initial-value table screwed it up, so the table lookup didnt work. When I filled up all colums with identical values it seemed to work. So I finally just canged the lowest value of the temperature scale from "-20°C" to "0°C" and now the code works reproduceable. Wow, revving down seems to give really smoooth idle!? Now I am looking forward to my test drive tomorrow morning!

P.S.: I have tuned engines where PW idle value could be constant no matter what CLT temperature. That means you can drive-off with 20°C CLT and get to the next stop with warmed up engine and RPM at idle is nearly dead on target. My engine seems to be "different" and needs more air when cold (this effect becomes extreme from 30°C downward). Probably thats the main reason why I was unhappy with the last good known value strategy, at least at cold days. The new strategy seems way more easy to tune btw?
Thomas

[Greg G]

And very reproducible! You just need to spend a few days tuning, because you can only tune the cold range once a day (well at least where I am located.). I am excited to see Ken's tpsdot based dashpot- combined with the IVT, should make for a very nice consistent entry to idle from throttle lift!

[muythaibxr]

Hi Ken.
Thanks for the Info.
I did some more investigation but for some reason the code goes back to the "valve open" PW% if CL Idle is engaged.
When I revert from "use initial value table" to "use last good known value" the initial PW% is last good+adder.
See attached MSQ.
Thomas

Can't speak to that, just saying what it *will* do once my changes are backported.

Ken

[Red_Baron]

Can we use the AIA on Alpha-N only yet? That would sort out idle on throttle bodies with no idle valve and heavy cams a treat!

Otherwise, I'm fooling the ECU with an SD primary table full of value "100", Alpha-N as secondary on multiply, closed loop idle on IAC setup (obviously no idle valve!!!) and settings set so its ALWAYS in closed loop, and AIA set accordingly

It's a workaround that I feel should not be necessary if at all possible??

RB

[gslender]

Can we use the AIA on Alpha-N only yet?

My mod still allows idle advance regardless.

If CL idle target wasn't available, where would you get it's idle target from?

G

[Red_Baron]

Can "Idle target" not just be a table that can be populated by the mapper and referenced by various other parts of the code?

Idle target table values could be available *always* and you just turn on Idle valve control algorithm if you have an idle control valve, or you turn on AIA algorithm and configure that if you haven't got an idle valve, or both if you want to?

AIA helps throttle bodied cars to idle when they have no idle valve, that much is certain, especially when they have hairy camshafts!!

RB

[pmbrunelle]

Can "Idle target" not just be a table that can be populated by the mapper and referenced by various other parts of the code?

Idle target table values could be available *always* and you just turn on Idle valve control algorithm if you have an idle control valve, or you turn on AIA algorithm and configure that if you haven't got an idle valve, or both if you want to?

AIA helps throttle bodied cars to idle when they have no idle valve, that much is certain, especially when they have hairy camshafts!!

RB

That's sounding half-decent.

For the CL idle crowd, there should be an additional condition on AIA entry. AIA should only kick in once the car is in CL idle close to the target, not come on early while we're still ramping down from i-v-t.
Then, AIA must stay on until we're not idling anymore. AIA is for fine adjustments once we're near target.

some pseudocode to explain:

Code: Select all

if ((outpc.status2 & 0x80) && (outpc.rpm - outpc.cl_idle_targ_rpm < engage_AIA_adder_RPM)) {
   AIA_enable = 1;
}
if (!(outpc.status2 & 0x80)) {
   AIA_enable = 0;
}


It makes no sense to separate spark RPM targets from idle valve RPM targets. If the values are different, spark and IAC will fight each other. If you're only using one of the features, then having two tables is just wasting space.
Those who run CL idle can set the other AIA conditions so that they would always be met.

Also, AIA should be separate from idle advance maps.

AIA is a correction (spark adder) to meet desired idle speed.

Idle advance timing (absolute) is timing you want off-throttle at low speed. You may want it with or without AIA.

It makes sense, so that your main spark table, including around the idle area, can be tuned close to MBT. Then, off-throttle at low speed, you go to the retarded idle advance, so that you have a torque reserve so that AIA can kick up the spark if needed.

And rather than selectable separate RPM and Load based spark advance tables, it could be a single 4x4 or so 3D table, for simplicity, and anyone with the load only table could still run the same settings.