[FW MOD] ms2extra 3.3.0a gslender v2.3

[ol boy]

I noticed if I blip the throttle just after the motor starts I cancel out the crank to run time and it defaults to the initial CLT table value. Is there a way for the crank to run time to have priority over any other situation regardless of what the throttle does during those few seconds? I'm still chasing my tune during cranking and start-up and some times need to add a bit of throttle to help things out.

[muythaibxr]

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.

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.

IF you didn't do it with EAE, then you didn't do the same thing I'm talking about, so your results of course won't have been what I was referring to.

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.

Better enrichment control than what? As I said before, if you use EAE in conjunction here, you won't get backfires, AND you'll reduce the amount of time it takes for RPM to drop (though as I already said once, it probably won't be as much of an improvement as also cutting spark).

Ken

[fixmann]

Mr.gslender

I have been asking this question before on the forum but told it couldnt be done.
So i wanna ask you since you know the code/software wery good.
Can the code be changed in one way or another to accept primingpulsewith bigger than 43ms?

My injectors are rather small, if i prime 3 times the engine fires on the first stroke.
But if i dont prime several times, i must crank some more.
Dont seem to help much making crankpulsewith bigger.


Best regards
Fixmann

[muythaibxr]

The priming PW should be able to go up to 65ms. However, that still isn't enough for you if you need 43ms * 3.

Ken

[muythaibxr]

Actually I must correct myself. 43 ms IS actually the maximum due to the fact that our timers tick in 2/3rds usec units... that's the number of ticks that can fit in the output compare timers we use.

Ken

[fixmann]

Hi
Thanks fo answer, now i understand what causes the limit.
But is it possible for me to change the code a little so lets say that the cpu runs the code until the priming are done,
and then return to the beginning of the code like 3 times before it goes past the primingstage in the code.

Like setting up a variable like "loop until start=3"

Fixmann

[muythaibxr]

It doesn't really work that way. We set a timer to handle the length of the squirt, and that happens asynchronously from the main code... There may be a way to do what you want, but I don't think that is the way.

Ken

[Monzsta]

Had a conflict when I loaded this into my LS1. (Map angle must be less than 90 degrees) Found the setting in "Basic Setup--> General, Lags" and changed Map Sampling Angle to 89 degrees.

Runs very smooth otherwise. Love the spark cut!

[dontz125]

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.

How hard would it be to add the option of varying the cut time according to a knob / pot, allowing the rider to tune this on the fly?

[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.

How hard would it be to add the option of varying the cut time according to a knob / pot, allowing the rider to tune this on the fly?

Given that the number of inputs are limited, I'd say difficult...

[pigga]

By the way: Is there a chance to monitor the Status of PE0 for idleUp in the actual firmware? (Just to ensure the input circuit works as intended)

[gslender]

By the way: Is there a chance to monitor the Status of PE0 for idleUp in the actual firmware? (Just to ensure the input circuit works as intended)

Yes, but you can see that by the fact that idleupcnt (logged) starts counting... so really if the input is correctly wired it will work (and you will need to at least add some nominal duty in the idleup configuration - like 0.1% or 1 step is enough)

G

[Hahns5.2]

* fixed Median Sliding Window against rpm/tps/map/lambda (thanks Rob for point out my errors)

What was fixed? Does this code offer even better noise filtering over the 3.2.1 V2.2c?

[gslender]

* fixed Median Sliding Window against rpm/tps/map/lambda (thanks Rob for point out my errors)

What was fixed? Does this code offer even better noise filtering over the 3.2.1 V2.2c?

The original implementation wasn't a true Median Sliding Window - even still, it was a mater of choice as to whether you'd call the change better or not (in terms of noise filtering) - but thanks to Rob it is now a correct implementation of Median Sliding (with the difference being one of how it handled discarded values in terms of window history).

More to the point, the 3.3.0b alpha release has a MAP Averaging implementation, and this oversamples the sensor to provide nearly a noise free input with zero response lag.

G

[pigga]

More to the point, the 3.3.0b alpha release has a MAP Averaging implementation, and this oversamples the sensor to provide nearly a noise free input with zero response lag.

Hi G., are there plans to port this averaging map sampling strategy into your modified firmware?
BTW: Put "your" FW on a car with automatic transmission few days ago. I had no chance to wire the gearstick-switch to PE0 yet, but even without hardware mods it gives very stable and reproducible idle RPMs (no lock out/overshooting when putting into "N" or similar).
One thing I noticed on 2 engines with lumpy cams: A MAP median sliding window of "3" in combination with a MAP lag factor of "100" seems to be the limit where you can get things running with map-based EAE.
Has anyone experience about what combination of Lag factor and sliding window may work well?
However, engines seem to run smoother, above all at idle. So median sliding window makes a difference.

[gslender]

More to the point, the 3.3.0b alpha release has a MAP Averaging implementation, and this oversamples the sensor to provide nearly a noise free input with zero response lag.

Hi G., are there plans to port this averaging map sampling strategy into your modified firmware?

The latest 3.3.0b alpha has taken almost everything fwd. Ken and the gang have been extremely open minded about including features (most of which is MS3 ported back down anyway) and so this release has everything accept the median filters, of which the new map averaging removes the need for any median filter. I'd encourage you to try it and confirm this.

I'm still working on some new ideas (some of which haven't helped) and hope to have something further out soon.

G

[pigga]

Hi G.
I just followed your advice and flashed 3.3.0b on my MS.
Will give feedback tomorrow. I must agree I was astonished as well that all those settings are in this version. I like that.
Actually, I am a bit stumped about two settings at the moment:

unknown_setting.JPG (38.98 KiB) Viewed 369 times

Will a sliding window algorithm smooth the output of the CL idle loop (and what would be the effect? Can I increase "P" for instance, then?).
And what´s behind this Idle Voltage Compensation? Will the PWM idle voltage compensation only be active if this option is "on"?
Again, thanks a lot for your Help ex ante!

[Greg G]

Will a sliding window algorithm smooth the output of the CL idle loop (and what would be the effect? Can I increase "P" for instance, then?).
And what´s behind this Idle Voltage Compensation? Will the PWM idle voltage compensation only be active if this option is "on"?
Again, thanks a lot for your Help ex ante!

The other G will answer ;)

The PID RPM window smoothing adds extra smoothing to rpm when in closed loop idle- theoretically damping down the pid action on the idle valve duty. The goal was to make the valve move less when in steady state idle. It's like a second median window. Use values from 3-7. Or leave it off, working on a better solution

Idle Voltage Compensation- the adaptive baseline option is an attempt to compensate for the fact that the average batt v will change with heat. A voltage baseline or "battery target" is calculated using a heavily lagged batt v. So the battery compensation curve is calculated vs a delta from the baseline, instead of absolute voltage value. Worked well in theory, but it's not producing the desired results. Leave it off for the moment, working on something hopefully better. ;)

Greg

[gslender]

The PID RPM window smoothing - Use values from 3-7. Or leave it off, working on a better solution

Idle Voltage Compensation - worked well in theory, but it's not producing the desired results. Leave it off for the moment, working on something hopefully better. ;)

The "better G" will also respond...

Both were attempts to further improve idle performance (one for when electrical load is applied, the other to reduce unwanted PID oscilation noise). Neither are proving to be 100% effective in all situations.

I've got assembled some new approaches to both that are so far proving to 1) be easy to tune and 2) produce significantly better results.

I hope to be able to release this soon and will be keen for feedback when I do.

G