[FW MOD] ms2extra 3.2.1 gslender v2.2c

[HidRo]

Well, I was thikning that I was being a numb dirk but it seems that I'm missing the Idle Advance, like it is described in page 7 of the PDF that comes with the firmware.
WHat am I doing wrong?
Enabled the PWM Closed loop, and this doesn't show up.

[gslender]

Well, I was thikning that I was being a numb dirk but it seems that I'm missing the Idle Advance, like it is described in page 7 of the PDF that comes with the firmware.
WHat am I doing wrong?
Enabled the PWM Closed loop, and this doesn't show up.

Not at the bottom of the Advanced menu? What's there then? Show a screenshot of that menu,

G

[HidRo]

AhAH! I now saw it, and it's under the Extended menu, not the Advanced.
I'll give it a go, but I'm not sure the difference will be major, and hopefully, nothing bad will happen. I have 17º of advance at idle, and once I added 10º and the idle was the same. Not even a glich. So, if I understand correctly, if the idle is supposed to be at 1000, and it drops to 650 (in my case) it might add something like 30º?

[gslender]

AhAH! I now saw it, and it's under the Extended menu, not the Advanced.
I'll give it a go, but I'm not sure the difference will be major, and hopefully, nothing bad will happen. I have 17º of advance at idle, and once I added 10º and the idle was the same. Not even a glich. So, if I understand correctly, if the idle is supposed to be at 1000, and it drops to 650 (in my case) it might add something like 30º?

Well, the idea is to keep some torque or reserved, so make stable idle at 950 adv to be 12. When it drops below 950 spark adv is added, say up to 10 deg ( so fast it catches the rpm dip) and the advance will keep rpm up. When it goes over 950, it should be now retarding, say up to -8 deg (which takes totaly spk adv below 12) and will stop rpm surges.

Produces a very stable idle.

G

[gslender]

Just flashed it in today. Initial impression- very nice!
Something is still nagging me about the dashpot action with AC. It still seems not to apply dashpot when the AC is on. The dashpot decay seems to only apply with dashpot values of >7. But it looks really promising, have to get some more data on it. Love the logging of engine status and dashpot decay

There is a bug in the ms3 code that I've fixed... so should have something soon to correct that.

G

What bug?

Ken

Alright - bug may not be the correct term. The issue is more of "working as designed" but the design might not be ideal/correct.

The issue is as follows: When free reving, the dashpot adder is applied (as expected), but when the AC is on, the dashpot adder isn't. The reason is due to the valve not closing (ie it needs to be in CLOSED state before the dashpot is added), which when the AC is on the duty is so much more significantly higher (compared to when off and duty is just above closed) - and in the time remaining, it just couldn't close the valve fast enough (as apposed to what occurs when current duty is closer to closed duty). So the inputs for the entry requirements for adding dashpot change, and result in cases where dashpot is needed, but the code won't add it as it believes the conditions are not ideal - so this is the design problem.

Where I'd like to head towards is changing the way Close Valve operates (or actually my preference is to add a new feature/option rather than change the current options) - Close Valve currently requires a certain RPM before it slowly closes the valve. My view is that it might be more appropriate to just immediately shut the valve when MAP goes beyond a certain value (of which recommednation would be anything above > 90kPa). This instant shut really wouldn't cause much of an impact (as any throttle volume allowing MAP to be > 90 kPa is probably moving a lot of air and the IAC itself is unlikely to have any noticeable impact anyway). This change would (in my eyes) make the setting up simpler and perhaps even automatic - as default configuration can be to have it set for 99kPa and in almost all cases this would be fine, but also still ensure that under boost conditions, the IAC is shut. Obviously when MAP is bouncing around 90-100 kPa the valve would be flapping - so some degree of hysteresis or dampening would be required.

G

[msegt]

i gotta tell ya, ive had a few different people in my car in the past few days and they all asked what ive done or changed...so its deffinatly not just me that its that much better...lol.. i told them all i really did was update the firmware a few times, and you deffinatly impressed them all . my cars sooo smooth its amazing...lol... it makes selling these soo much easier when you can make them do what you actually want . thanks again.......

[muythaibxr]

So that's not really a bug at all, nor would I consider it a design flaw.

The reason it was done that way was due to the following:

You don't want to close the valve immediately, because then as soon as you lift it'll open again. This is not a problem for most PWM valves, but we don't support just PWM valves, we also have to support the slower-acting steppers. I wanted to be above a particular RPM before closing the valve in case the user lifts immediately. IF they lift immediately and the valve is closed, they could stall during the time period before PID comes back on because the valve is still not open to the point where it should be yet. Clearly that is worst case, but there was also an obvious drop in RPM and increase as the valve got back to where it should be.

Now, I am willing to agree to adding the dashpot as long as the valve has *started* closing instead of requiring it to fully close, but the way it works now was done on purpose as a result of actual user issues, so that is not going to change.

As far as not applying when the AC is on, I've tested this on MS3 and can't find a condition where this happens, so I assume the user was experiencing the same behavior you were talking about.

Ken

[muythaibxr]

So I just tested this and it reacts the way I want. I changed it so that if the valve even starts closing, we engage the dashpot.

This avoids the issue that you were seeing with the quick blip (as long as the quick blip goes over the RPM at all the valve should be marked closed), and the issue I was trying to avoid as well (the valve closing then taking too long to reopen causing odd RPM fluctuations or stalls worst case).

It was a 2-line change. Diff will be in your inbox shortly.

Ken

[gslender]

So I just tested this and it reacts the way I want. I changed it so that if the valve even starts closing, we engage the dashpot.

This avoids the issue that you were seeing with the quick blip (as long as the quick blip goes over the RPM at all the valve should be marked closed), and the issue I was trying to avoid as well (the valve closing then taking too long to reopen causing odd RPM fluctuations or stalls worst case).

It was a 2-line change. Diff will be in your inbox shortly.

Ken

Thanks Ken - that solves it and I agree presents a simple and acceptable outcome.

G

[Greg G]

OK I collected some data on the dynamic dashpot- this looks like the way to go! It does require some tuning though. Bigger decay factors will naturally impact the dashpot value more. It's a matter of "shaping" the dashpot curve in such a way that you achieve a controlled approach to idle target. The following graphs illustrate the effect of small to large values on the dashpot duty.

note: Graphs are magnified to 6x to emphasize the shape of the dashpot duty.

Dashpot 7/ decay factor 5



Dashpot 7/ decay factor 10


Dashpot 7/ decay factor 20


A side discovery- the change in RPM target on CL entry causes a blip in spark advance as AIA suddenly finds itself below the new target. This causes a minor RPM blip, kinda annoying. I think the entry conditions for AIA need to be tweaked, perhaps adding CL idle status as an optional condition.

Ended up using dashpot 6 and decay factor 35. The scatter plot shows the data from a short drive. The dashpot values decay, with the idle valve duty going from IVT value + dashpot to IVT value. Subjectively-- VERY VERY nice consistent entry into idle, almost OEM like. The split second blip from the AIA- target reset issue is hardly felt, and is just a minor annoyance.

Status 5 showing the engine state is really nice!
Red--throttle lift dashpot applied
Blue-- idle
Cyan-- throttle lift, dashpot not applied yet

[pigga]

Hi G.
Thumbs up for your research and nice to see how your ideas come together with the developers' thoughts. I like it.
I would like to ask 2 questions to hopefully better understand how it works.
1st:
With the old CL idle code the Daspot-Adder was some kind of "safety buffer" to make sure CL Idle is entered from above idle Target, right? Just something like "New_Idle_PW= old_idle_PW+adder".
The new dynamic daspot will be added to the Inital-Value duty first and be decayed depending on actual RPMdot, i.e. the more stable RPM is, the faster it will be decayed, right?
But what will happen if the PID delay timer has expired and PID takes over CL idle? I am thinking about the situatuion that the adder has not been decayed to zero and PID takes over CL Idle (which may happen). Will Daspot be decayed additional to PID control, or willl CL idle just take over the actual idle PW at that point of time (and ramp down to target etc.)?

2nd:
As you described, AC equipped cars can benefit from your code.
I equipped a Car with a MS that has an automatic gearbox. It is always hard for the old style CL idle to catch up RPM drop when it is shifted from "N" to "D" and vice versa. Do you think this can be improved with your code as well? As far as I understand it, the major advantage is that MS controls the load so it can react BEFORE the load is applied to the engine. With a automatic gearbox the RPM will drop in the same moment as MS gets the switch signal from the gearbox. Will it be an improvement anyhow? (I hope so )

Thanks a lot.
Thomas

[gslender]

Hi G.
Thumbs up for your research and nice to see how your ideas come together with the developers' thoughts. I like it.

Thanks. The developers (Ken/James/Jean) have been really good about all this and really supportive too!

1st:
With the old CL idle code the Daspot-Adder was some kind of "safety buffer" to make sure CL Idle is entered from above idle Target, right? Just something like "New_Idle_PW= old_idle_PW+adder".
The new dynamic daspot will be added to the Inital-Value duty first and be decayed depending on actual RPMdot, i.e. the more stable RPM is, the faster it will be decayed, right?
But what will happen if the PID delay timer has expired and PID takes over CL idle? I am thinking about the situatuion that the adder has not been decayed to zero and PID takes over CL Idle (which may happen). Will Daspot be decayed additional to PID control, or willl CL idle just take over the actual idle PW at that point of time (and ramp down to target etc.)?

I think the point would be to ensure that rpm has a slow decent into just above idle... it should drop down to say 1000 and then gently ramp down to 900 idle condition. The dynamic dashpot applies just the needed dampening to ensure a nice drop from high rpm into a place above idle where CL pid can ramp down to stable idle... with the next release I've fixed the AIA spike and should ensure that when CL PID comes on, AIA activates and IAC work together to both bring down the idle in a very stable oem like way.

2nd:
As you described, AC equipped cars can benefit from your code.
I equipped a Car with a MS that has an automatic gearbox. It is always hard for the old style CL idle to catch up RPM drop when it is shifted from "N" to "D" and vice versa. Do you think this can be improved with your code as well? As far as I understand it, the major advantage is that MS controls the load so it can react BEFORE the load is applied to the engine. With a automatic gearbox the RPM will drop in the same moment as MS gets the switch signal from the gearbox. Will it be an improvement anyhow? (I hope so )

Absolutely! If you have an input that can drive the cpu pins then yep you could have it raise rpm and duty to match. should work nicely. I'd be keen to hear how that goes, and get a log so that I can update docs to show how an Auto or AC can be used.

G

[Greg G]

Hi Thomas,

Yes you have the right idea regarding the dynamic dashpot. The smaller the RPMdot value, the faster the decay will be. Or to be absolutely correct, the larger the subtract or will be, as the rate is fixed.

Ideally, it will decay to zero before CL idle entry. If it hasn't yet, then the pid code will just take over from where the valve position is when CL is entered. Remember the pid delay was designed to let the engine rpms settle down before closed loop entry. The dynamic dashpot should allow it to settle down immediately, so we can minimize the pid delay.

I'm not sure about the automatic gearbox issue. I suppose you could set it up to use the feedforward idle up feature currently used for the AC. Perhaps a second feedforward could be set up, if you still have an available input. Are you using AIA? That would help too.

Greg

[Perkele]

Here is the msq and log for gslender and everything seems to work well with the 2.2c.

2012-02-01_18.59.28.msq

(93.39 KiB) Downloaded 28 times

2012-02-01_18.59.47.zip

(189.28 KiB) Downloaded 26 times

It now works fine even with negative temp values on the IVT and with the same RPM value on the left than on the lowest RPM in the warmup target table.
In earlier version I had some problems with different temp and RPM values on the IVT.

But now everything seems to work as it should.
Great job.


Now I can fine tune the table and the dashpot adders, but this week the weather isn't the best possible for tuning, it's -25C outside.

[ol boy]

I got this code loaded today and I have to say... This has improved my steady idle state both on and off load.

Now alpha 3.3.0a has be dropped on us. It does not have the median sliding window which has smoothed out all my inputs and makes the engine more stable. Does it share all the same code as v2.2c, or slight improvements on the new features? Is there going to be any v2.2d.e.f.g's or will the 3.3.0 take over from here?

Thanks Ryan

[muythaibxr]

We'll be backporting filters from ms3. If gslender wants his changes in the official code he'll have to base his changes on that. The code in 3.3.0a is what he gave me a few weeks ago plus some other fixes from myself and Jean.

Ken

[ianferrell]

I just had a terrible day yesterday... I don't think I missed anything, but hopefully that's the case. I've been in love with the idle advance code in my car (94 miata, turbo ms3, running alpha 18). And my brothers DIYPNP'd supercharged miata (93 w/ 94 1.8 swap, brp mp62, TDR intercooler) with a non-functional IACV has a shitty idle (set to idle at 1100 rpm or so). Seemed like we'd get some improvement from this code...
So, I downloaded it, noticed it didn't have the firmware loader so I extracted it on top of the latest release code (so that the gslender ini and s19 files would overwrite the 'stock' ones). I disconnected the ignitor, and proceeded to burn the firmware, like I've done many times before in other cars, and even this one. Needless to say we were quite baffled when the starter made a clank and was unable to budge the motor at all... (followed by much head scratching and battery charging) Pulled the plugs, blipped the starter and it was like we were in vegas at the Bellagio.... Gas everywhere. All 4 cylindars were flooded. What the hell happened? This is a diypnp 1.5 board built with the seqmod running sequential, how in the world did burning the firmware turn all 4 injectors on? Is disconnecting the injectors before a firmware upgrade a necessary precaution that I just haven't heard about?

[Black99rt]

I am not sure if it is strictly required, but I have always disconnected the 12v to my fuel injectors and coil.

[gslender]

If you turned on and off the ecu many times before starting it might look like flooding due to the repeated priming.

G

[ianferrell]

If you turned on and off the ecu many times before starting it might look like flooding due to the repeated priming.

G

That was definitely not the problem, power cycled maybe 2-4x before starting it back up... No way priming pulse would flood the cylinders to the point of hydro-lock from that.

Also of note, the car drove an hour to my house, started fine yesterday morning after sitting for 2 months. It was less than an hour after that that I flashed it. We changed the oil after the bellagio experience (plugs too, car already needed both anyway)