[FW MOD] ms2extra 3.3.0a gslender v2.3

[gslender]

UPDATE : This firmware has been updated to v2.4.4 - see this thread >> viewtopic.php?f=91&t=44289

G'day...

This modified firmware is based on the alpha release MS2/Extra 3.3.0a firmware and brings it into alignment with the previous 2.2c mod with only a few minor additions/fixes - notably the addition of a CL_Idle enable condition for Idle Advance and several improvements to the avg/median smoothing algorithms.

Changes made from alpha release MS2/Extra 3.3.0a are as follows:

* added Dashpot Decay (adapted ms3 code, ini and valve-closed fixes)
* made changes to Idle Adaptive Advance ini to better align table axis
* added CL_Idle condition to idle adance (plus Manual added to allow old rpm/load/tps/clt method)
* fixed Median Sliding Window against rpm/tps/map/lambda (thanks Rob for point out my errors)
* improved Avg Sliding Window (thanks again Rob!) for PID and Batt smoothing
* changed pidrpm_window to function instead of inline code (to reuse code).
* added Cut Spark option to overrun fuel cut (allows super quick RPM drops).
* fixed ini bug for pwmidle_cl_initialvalues_duties (fix to 3.3.0a)
* corrected idle code to use status2_pwmidle_closedloop for status2 in code
* changed idle code to use MS3 PWMIDLE_RESET states
* dashpot decay and idle status logs to Status4 and Status5 (respectively)
* changed PID values to pointers allowing immediate effect/change
* changed idle up duty adder and pid rpm window values to pointers allowing immediate effect/change
* changed dashpot duty and dashpot decay factor values to pointers allowing immediate effect/change
* changed idle advance and IVT tables to pointers allowing immediate effect/change
* fixed IVT bug when negative & changed to pointers (fix to 3.3.0a)
* fixed bug and simplified clutch/neutral engagement (fix to 3.3.0a)

Firmware >>

Source >>

Enjoy
G

[Greg G]

Some assorted thoughts on this FW.

I think I'm getting the hang of tuning the dynamic dashpot. Here's a graph showing free rev. No load, AC, AC and headlights- all have the same slope and smooth entry to CL PID. The new option which triggers AIA only on CL idle works really well. I also found improvement from lowering the RPM adder for closed loop entry from 300 to 200. And I may try even lower values. I think the use of high values for this were needed for the old 'last known good' method for determining idle valve duty. The IVT allows a consistent response, so we can be tighter with the requirements for CL idle entry.



This scatter graph explains how the dashpot decays as (negative) RPMdot decreases and RPM approaches target:



Another thing I was playing with was the lag factor for battery voltage. Increasing the lag facto to 90 helped give a more positive response from PWM idle valve battery voltage correction. BUT the lag factor is shared by batt v with MAT and CLT. So I think those need to be separated from batt v.


Applying a sliding window to the batt v helps decrease the jitteriness at steady state idle, but too much tends to widen the 'valley' of a voltage droop. This widens the PWM idle valve response, causing a small surge. So use sparingly.

[ol boy]

I turned on the spark cut during over run fuel cut... first time I ran into over run and out of it I got a big pop out of the exhaust. Seems to be hit and miss but short over run situations would result in a exhaust back fire when fuel and spark were added back in. Cutting fuel for x time before cutting spark would make sure the intake was stripped of fuel before cutting spark. Maybe a short time delay is needed to add spark first before fuel come back in at the end of over run.

Otherwise the code as a whole is working well for me.
Thanks Ryan

[muythaibxr]

I'm not actually sure what the point of cutting spark when going into overrun would be... leaving spark running helps burn off the excess fuel...

Ken

[ol boy]

A member was suggesting cutting spark would make engine braking more consistent and give the maximum braking all at once. I believe the idea is braking comes in slow as the remaining fuel is stripped from the intake wall because spark is still present. Once all the fuel is gone you've reached max braking. So pulling fuel and spark at the same time might result in instant max engine braking.

I like the idea but it may not be for me and my app. All out race cars may benefit from this feature, need more feed back from those who asked for it.

[Greg G]

AFAIK, it was requested for a racecar application, to speed up the drop in revs while shifting. I don't really know if it would be all that good for street cars as it is now. Perhaps some sort of decel retard would be easier to tune? And probably max out the remaining space in the ms2

[gslender]

Here is how it improved the rpm falling times...

No Spark Cut vs Spark Cut.jpg (66.33 KiB) Viewed 1195 times

[muythaibxr]

Cutting fuel sooner would have the same benefit. I used a properly tuned VE table (lean along the bottom) along with EAE to achieve a similar effect without cutting ignition (and the backfires I would expect with it). I guess if you don't mind the backfires great, but I tend to try to use the tools already available before writing code.

In this case fuel cuts almost immediately the way I have it tuned, and with EAE, it gives a good blast of fuel to rewet the walls when fuel comes back.

Ken

[tpsretard2]

Not sure if this is a turbo race car or not.

But antilag has the same effect, maybe not as drastic.
but you get a much faster drop in rpm because of the supper late spark.

[tpsretard2]

i should also mention this is why ecu's like motec and pectel will do an ignition retard + spark cut for a sequential gearbox shift cut, it makes the engine rpm drop measurably faster.

[muythaibxr]

I suppose that is valid if it is an all-out race car.

Ken

[bubba2533]

If you has a fast enough moving IAC valve could you add an option to have a set duty/steps during overrun so you can "tune" the amount of engine braking you want.

You could open it the whole way to gain fuel economy by coasting with lower pumping losses.

Or you could close it the whole way to increase engine braking.

Just a thought.

[gslender]

Cutting fuel sooner would have the same benefit. I used a properly tuned VE table (lean along the bottom) along with EAE to achieve a similar effect without cutting ignition (and the backfires I would expect with it). I guess if you don't mind the backfires great, but I tend to try to use the tools already available before writing code.

In this case fuel cuts almost immediately the way I have it tuned, and with EAE, it gives a good blast of fuel to rewet the walls when fuel comes back.

Ken

Ken, the issue is that fuel remains and is burnt by the continuing spark. Cutting spark AND fuel ensures that rpm drop is as fast as possible, as from the moment it becomes active there is ABSOLUTELY zero combustion. I'm unsure how a lean VE table on the bottom row + EAE guarantees that?

g

[jsmcortina]

It depends on what you want from over-run fuel cut. The feature is added to reduce fuel usage, not increase engine-braking.

I'd actually like _less_ engine braking during over-run and have considered bumping the idle valve open a little.

James

[bubba2533]

It depends on what you want from over-run fuel cut. The feature is added to reduce fuel usage, not increase engine-braking.

I'd actually like _less_ engine braking during over-run and have considered bumping the idle valve open a little.

James

I agree, I would like to see how large of a difference it would make with the idle valve fully open so I could coast for longer periods to same more fuel.

I'm sure there are people who would like to close it to increase engine braking though.

[muythaibxr]

Cutting fuel sooner would have the same benefit. I used a properly tuned VE table (lean along the bottom) along with EAE to achieve a similar effect without cutting ignition (and the backfires I would expect with it). I guess if you don't mind the backfires great, but I tend to try to use the tools already available before writing code.

In this case fuel cuts almost immediately the way I have it tuned, and with EAE, it gives a good blast of fuel to rewet the walls when fuel comes back.

Ken

Ken, the issue is that fuel remains and is burnt by the continuing spark. Cutting spark AND fuel ensures that rpm drop is as fast as possible, as from the moment it becomes active there is ABSOLUTELY zero combustion. I'm unsure how a lean VE table on the bottom row + EAE guarantees that?

g

If EAE cuts fuel while MAP is on its way down the table then overrun fuel cut takes over as soon as you're there, the excess fuel burns off before the throttle is all the way closed and the RPMs drop quickly. I'm not sure it's as quick as completely cutting spark, but it does have the benefit of cutting the time for RPM to drop AND avoiding backfires.

Ken

[dontz125]

i should also mention this is why ecu's like motec and pectel will do an ignition retard + spark cut for a sequential gearbox shift cut, it makes the engine rpm drop measurably faster.

Interesting - I mentioned this in the recent "Developments of MS2/Extra" thread; I've seen comments that the MS2 flat-shift doesn't work well with high-revving bikes (seq. shifters). This would make sense.

[War-story smiley] Historically, fast-shifters on (carb'd) bikes have worked by cutting the spark for some teeny period of time, not retarding it; if you had to stand on the shifter (not enough drop in revs), you increased duration. If the bike lurched (too much drop), you reduced duration.

What are the limits of spark retarding in the current code(s)? I don't particularly see a difference from the engine's perspective between a 'cut' spark and one that is retarded 180 deg (or some other value that won't support ignition). Is it possible to add a 'duration of cut' variable? (if there isn't one ... ?)

[gslender]

Is it possible to add a 'duration of cut' variable? (if there isn't one ... ?)

Would be simple and small in terms of code to do that.

[pigga]

Hi.
I ran into problems with your latest code. For some reason the engine tended to start "hunting" at idle. You gave me the very helpful hint that the "old" and the "new" averaging are still active at the same time (seems logical but never had thought about that )
Now I re-loaded your latest code, changed the old smoothing factors to "100" and voilá, seems as if the hunting has gone.
Map-avg sliding window I had to decrease to "2" because throttle seems not responsive enough otherwise (maybe related to high compression, lumpy cam etc).
I am still impressed about the really smooth idle of the engine and the easy tunability of CL idle.
By the way: Is the temp.-scale of initial Idle value MAT based right now? I remember that I could choose between MAT and CLT in last code version. But that's no problem: If I rise target idle RPM at lower CLT, initial PW will rise anyhow.
Will give an update later on.
Thomas

[Ligerzero]

I am the one who requested this addition and yes this is on a turbocharged car that requires the quickest shifting possible short of causing physical damage and/or decreasing reliability. I played with closing the IACV during shifts, high enleanment of the VE table at low load, decel fuel enrichment, ignition retarding, fuel cut on over run and any combination in between. None of them combined gave me what I wanted in terms of RPM deceleration rate and I was determined to maximize the electronic side of the deceleration rate. The problem that I was finding was when shifting from high load and high RPM conditions; by comparison to none, a lot of fuel was still entering the cylinders and being ignited. By engaging ignition cut, I noticed a ~.1 second reduction in shifting time under normal driving but under high load and high RPM conditions that increased almost .5 of a second reduction.

I turned on the spark cut during over run fuel cut... first time I ran into over run and out of it I got a big pop out of the exhaust. Seems to be hit and miss but short over run situations would result in a exhaust back fire when fuel and spark were added back in.

Sounds like you need to adjust your enrichments and lower VE values. I only experience moderate pops when shifting at higher RPM from high load situations.

If EAE cuts fuel while MAP is on its way down the table then overrun fuel cut takes over as soon as you're there, the excess fuel burns off before the throttle is all the way closed and the RPMs drop quickly. I'm not sure it's as quick as completely cutting spark, but it does have the benefit of cutting the time for RPM to drop AND avoiding backfires.

Ken

I had already leaned my lower VE tables to the edge of driveability and it only had a small impact on RPM decel when changing gears quickly from a high load condition. I have played with the decel fuel enleanment but this feature is not triggered correctly to be reliably used and causes a loss in throttle response under various conditions. Regardless, complete ignition cut is necessary to maximize RPM deceleration. A properly tuned VE table and enrichment set will prevent most backfires to begin with.

Not sure if this is a turbo race car or not.

But antilag has the same effect, maybe not as drastic.
but you get a much faster drop in rpm because of the supper late spark.

Anti-lag moves combustion into the turbo manifold and turbine housing. It will increase RPM deceleration rates but not to the level that I require and I do not want to erode my turbine and valves. A faster shift with a correctly setup turbocharger system can net very little, if any, pressure drop between shifts.

I suppose that is valid if it is an all-out race car.

Ken

Full ignition cut is done on OEM cars as well, although primarily on exotics (both with and without sequential gearboxes) which require high RPM deceleration rates. The difference is that their ECU’s have better enrichment control which eliminates the exhaust backfiring. Even still, there is nothing preventing a person from using this on a street car. As I mentioned previously, I experience no exhaust backfiring under normal driving conditions; you have to correctly tune the enrichments and VE table.