MegaSquirtSanta - Custom Modifications / Firmware
 

Ho ho ho...

It is nearly Xmas time and MegaSquirtSanta needs to know what you boys and girls would like in your Megasquirt 2 for Xmas. ;)

I've already added and freely released firmware mods for:

• AC Idle Up (both duty and rpm)
• Battery Volt Idle Correction (duty up/down)

*coming soon* I'm busy putting the final touches on this set...

• Graceful Off for AC Idle up - keep RPM spike to a minimum!
• MAT correction for Idle
• Clutch/Neutral PE0 switch to lockout PID

What else should I be looking at to enhance this mod?

PS - so far nothing has been removed or harmed in the making of this mod !!

G (aka MegaSquirtSanta)

I hope this isn't an xmas only thing and come easter you'll be the xmas easter bunny etc etc.

As for feature request, how about a proper non-linear injector compensation table a-la MS3 rather than the static value we get in MS2 that's then adjusted linearly via voltage.

:)

MegaSquirtSanta gives many times a year!

I'll look into that "non-linear injector compensation table" feature, but may require some thinking behind what is broken in the MS2 version and why the MS3 option is that much better.

(Posting from my phone.)

Ms3 uses a table ms2 static x change per voltage change.

i.e. linear vs non linear.

No injectors that I know of are linear in operation, particularly at low PW/DC.

I'm all for anything that smoothens idle! Anyone got a screenshot of the injector compensation table? :)

https://www.miataturbo.net/attachmen...ine=1319801430

based on this

https://www.miataturbo.net/attachmen...ine=1319801430

Cheers frank.

Merry Christmas gslender ;)

Hey frank are those rx8 injector settings there? :)

Edit: d'oh! Typed before I looked :)

I suppose if it were done, just a single table for all 4 injectors (to save space) would be acceptable. No need for individual injector trim. Right?

The latest 3.1.4 beta MS2 code uses a default injector battery voltage correction curve with a scale factor, instead of the linear correction in 3.1.1 and older code versions. Just wanted to mention that one's already been improved a bit, although it's not as sophisticated as MS3.

To expand a bit on Matt's post, the new non-linear correction seems to be able to match published data for dead time for most (all?) injectors. It requires adjusting the 2 parameters (dead time @ 13.2V and correction factor) but it's not very difficult using a worksheet.

What MS2/Extra doesn't have that MS3 does have is a small pulse width curve which is where the non-linearity of injectors needs to be corrected for when using large injectors. This is what will affect idle quality under normal conditions.

This is also not something you can guess and it must be measured to be of any use. So having the option available is only a small part. Being able to characterize the injectors is the major part which may not be accessible to most users.

Jean

Another possible candidate is robs' tps dot smoothing. Might be applicable to mapdot as well.

http://www.msextra.com/forums/viewto...p?f=91&t=42233

True, but for this community at least there's not a large range of injectors used.

They only need to be measured once and the community benefits as a whole :)

What do you guys think of MAT based pwm idle duty correction? When my engine is hot, I notice the idle valve duty is higher, by about 1 duty point per 5 degrees F. This is because the air is less dense at higher temperatures. Yes the closed loop duty will make up for it, but I figure if we already correct it (by a user definable factor), it will leave the closed loop code less to do, and allow us to run lower pid values.

My question is, what will the baseline value be? I suppose it's normal operating temp. Shall we say 100F? Duty would be added above the temp at a user definable rate. Below that, no correction is applied.

Idle valve duty hystersis, based on RPM. Should hopefully be a simple tweak to the current PID code and would be very useful.

The MAT based idle valve correction would also probably help address the hot restart issue...

Map / EMap fueling strategy ( Exhaust Manifold air pressure )

VSS input

I'd like to see this as well. On my setup it seems like there isn't enough granularity to hit the targets the code is trying for. I'd rather it be "good enough" and stable than oscillating back and forth and causing transients,

I thought hysterisis was already in? or am I confusing it with the mariob code mods?

Mariob put it in, but it never made it into the mainstream releases. It helped when I was using his code but the lean spike fix and AC idle up improvements were better. If I could get one release with both that would be awesome, though.

Ok, so this "Idle valve duty hystersis, based on RPM" has got Santa intrigued... tell me more... how do you see this working.... what do you want changed?

Cheers,
MegaSquirtSanta

PS - as you've all been good boys/girls, I've worked some magic on a release that has Clutch/Neutral input PE0 PID lockout so you can dribble along in gear and when you drop the clutch, only then it jumps into PID... Very Niiiiiccceee !!

Any more features you want to copy off my own firmware?

I've added a few things to the 1st post regarding what is in testing, in works or planning to be released soon!!

Depends, what are you willing to share?

The way I remember it what helped before was a user-defined deadband around the RPM target, so once an RPM within the band was achieved it stop changing the idle valve duty until the rpm fell out of the band. If you had an idle target of 900 RPM set up and a +- 50 band at 30% it wouldn't move from 30% until you went over 950 RPM or below 850. I'm not sure how that was implemented exactly (maybe a floor on the instantaneous error term) but when mariob did it it prevented some of the oscillation some of us experienced in (what should have been) steady-state.

Awesome. Can this be combined with a clutch launch control input on FLEX/PE0? I think a bunch of us may be wired up this way already.

Ok, got it, and will re-look at this for a future release. Wouldn't just less D help here?

Greg - do you need this mod or is this a tuning issue with too much D?


Yep, it will continue to allow Launch control (if enabled) to work. I've actually also got a way to enable/disable launch based on clutch activation duty (I'll explain how later) so you can still disable launch, rev to 7,200 rpm (for whatever reason you need to do that) and then enable launch via the clutch with the launch retard to 4,500 etc... best of both worlds!!

Cheers,
MegaSquirtSanta :yippee:

Yes the RPM target hysteresis/deadband as implemented in the mario code will delay PID action. In my case, I eventually turned it off because it made droops so much worse. Of course with the AC idle up, it may not be so bad anymore.

Anyway I have suggestions which I think will make it much better, IMHO.

1. Make the deadband individually configurable above and below the target, instead of equally added to both sides of the target. That way, we avoid delayed action vs droop, but still get some benefit of a fatter target. Or if the user wants it equal, he can do so.

2. Change the output of the closed loop PID within the deadband by a user defined damping factor! If you want no reaction within the deadband, use a 100% damping factor. If you want PID to just be less jumpy, use 50% or whatever factor you wish. :idea:


Oh, and the antistall feature was pretty nice, as a failsafe feature. Below a set rpm (say <400), the idle valve would open up to prevent a stall. Did wonders for your peace of mind knowing that you couldn't stall (most of the time).

The advantage of having the dead zone is that you can run aggressive PID settings to drive the idle duty quickly, but once you're close enough to your idle target the PID stops moving the valve which helps stop oscillation, which would make idle tuning a lot easier. It'd also make it a lot easier to get a car running on MS2 and functional faster, which can only be a good thing.

It was in the mariob tweaks but license terms couldn't be agreed so it never made it into the release code.

I'm not 100% sure how the current PID code works, if I'm right then it just loops constantly whilst watching the PID parameters. If so then a simple If, Then, Else based on a Min Idle RPM < current RPM < Max Idle RPM should be enough.

Hmmm. Perhaps another condition for activation of the dead zone is a minimum RPMdot value. That way, the dead zone activates to stabilize idle when near target, but does not impede the action against fast changes (sudden droops).

I think there's a better way to implement hysteresis.

More later.....

I discussed this with Jason, and his idea seems better! It's a moving hysteresis window, applied to the valve, not the rpm target. Basically it smoothness the signal by not allowing it to jumps of far from a set-width window, which constantly adjusts based on the input. I'll let him do the explaining. Basically, it calms the jittery valve duty but does not affect pid action.

Here's his explanation (he discusses tps dot but it will be applied in our case to idle valve duty output):

Man I love collaborative efforts like this.

Great job guys!

Pls. read my posts in this thread:

http://www.msextra.com/forums/viewto...301785#p301785

The hysteretic window is good for filtering the *output* of a feedback loop, such as the PWM signal that goes to the idle solenoid. It greatly reduces any "shivering" or hunting around of the solenoid. It is a bad idea to use it for the input signal such as RPM. Greg found this out firsthand.

The appropriate filter for an *input* signal, such as the RPM signal for the idle control loop, or the MAP signal, is a "Bessel" lopass filter.
I gave a sample in the above msextra link.

That sounds great. My question as a code outsider is can that be coded in such a way as to not use a whole heap of CPU time and also to fit into the remaining flash space?

Ooooh I like it. My valve duty graph looks exactly like that! Smoothening the output might just be the ticket to a calm yet reactive steady state idle.

Reposting the explanation:
See pictures explain it so much better :)

Santa,

If I may suggest ... the whole idle strategy needs to be re-architected.

The main changes I suggest are these:
- the idle_duty% is: lookup table values + feedforward values + PID

- PID always turned off if the wheels are connected to engine, but all lookup tables and feedforward *always* active in determining duty%

- TPS > 0 exits PID

- Whenever PID (closed loop) exits, I is *always* reset to zero

- the output of I has to have a + and a - limit. That is, e.g. it can never add mroe than say, 15%, or remove more than 10% from the output.

- Whenever closed loop is re-entered, I *always* has to be reset to zero

- Whenever closed loop is re-entered there should be a "closed loop re-entry target RPM adder". This stays for like 1 sec, and then the target ramps down to the normal target over say, 3 sec. For example, target will initially be 1200 RPM upon re-entry. This target will stay for 1 sec, then ramp down to 850 over 3 seconds. This will solve the stopping-at-a-stop-sign idle dip, and it will also work well for stepping on the clutch when lugging the engine at 600 RPM.

- having a good set of feedforward setups is critical: a/c, voltage, IAT, etc.

Jason and I had a long discussion last night about this. Mainly because my supercharger belt had broken on the dyno, so I had to drive home through a major traffic jam with no AC. So I had a good hour's data of crawling through stop and go traffic to observe the low speed stop and go behavior of the pid code. My car has no radio, so all I could do to entertain myself was watch the idle duty (how sad is that)

So yes I agree that:

1. The conditions for closed loop entry are a big factor. Having it active while in gear, especially in 'parking lot' driving conditions- say you are decelerating slowly driving up a slight slope, and enter closed loop. You slip the clutch to maintain a slow speed going up that slope. That drives the pid crazy and it drives the idle valve duty higher and higher. Then you let up the clutch to stop, bam! Idle shoots up to 1,600 or something like that.

The reverse is true if youre cruising down to a stop and you enter closed loop early- the pid code wants to close the valve so drops it to minumum value. When you clutch in, you get a droop.

These actions are mainly driven by the I term, and is called "integral windup". Since it never seems to get to target, it keeps adding and adding or subtracting and subtracting. This is solved in 3 ways- put a maximum limit on the I output, reset I on closed loop exit, and modify the entry to closed loop with a hardware mod. This can be a vss input(ms3), or a clutch neutral switch condition for closed loop entry (great mod pioneered by reverant).

2. The calculation of the idle valve duty must be improved over the current 'last known good' value, and correlated to the clt table (like warmup only mode) plus the feedforward factors like battery voltage correction, mat correction, AC input. You want to enter closed loop idle at a duty value spot on for the conditions, to get smooth entry. Presently it's something like "get it in the ballpark and let pid deal with it". Perhaps just a straight clt table lookup modified by the various feedforward adders will give a better consistent value. Like the best of both world between warmup only and close loop idle modes...

The code is pretty good already, but I think these improvements will have a real tangible effect and bring it to near oem level. :)

Found some good reading here:
http://chriswilson.tv/PID.pdf

Another thing that the mariob code did was to use the open loop idle duty table to provide a known good value. The use of that table in conjunction with some pre-determined adders for A/C, headlights, etc may be a good place to start, and uses something that's already in the code

Note the following:

"Last known good value" alludes the last 'I' value be used. This is a mistake, it should be reset to zero.

"Last known value" alludes to "remembering" some kind of last value. Not really any different.

Here is why freezing or remembering the I value is bad.
For example, I is at -10% for some reason idling at a light, then you drive off.
You then encounter traffic and crawl the car in 1st gear with foot off of clutch, and let RPM drop to 700 RPM. You then push in the clutch. If you use I=-10%, the engine will die. You are better off with I=0. When PID is re-entered with RPM=700, the P will instantly add lots of duty cycle to get the RPM to rise rapidly.

Or if RPM is dropping very rapidly because you put it in neutral with RPM=2000. When it re-enters closed loop at say 1200, the D sees the dropping RPM and will output lots of additional duty in order to slow the RPM descent.


The correct approach is to use the various lookup tables all the time, even when not in idle. This replaces the phrase "last known value". This way the extra duty is there when a/c is on, etc.


If you want to get real fancy, you want an adaptive control scheme. This is like auto-tuning, where said lookup values and lookup tables are adjusted slowly over time.

I was playing around with the scatter plot feature in MLV, and I think I figured out how to demonstrate the need for MAT idle valve duty correction!

Same data, presented 2 ways.
Attachment 186608

As you can see, at > ~128 MAT, the idle valve is not a happy camper. At that temp I suppose the air is significantly less dense that the valve has to open wider to maintain the RPM. If we put a feedforward mechanism to add a user defined amount of duty above a user defined base RPM, we automatically compensate for the lower air density and keep the PID happier/less involved. Proaction is better than reaction. Which hopefully leads to a stabler idle. A lot like the battery voltage correction, and the AC idle up.

Why MAT? Why not CLT? Here's why:
Attachment 186609

Once the engine is at operating temp, you can't see any clear change in idle valve duty based on CLT.

So yes please, to MAT based idle valve duty correction as a feedforward mechanism :)

Good stuff!

OK I have the early beta of the Santa release, which includes all the features of the AC Idle up release plus MAT correction! Initial results look promising, but they do require careful tuning, because it changes the balance for the closed loop PID.

A picture of the settings menu:
https://www.miataturbo.net/attachmen...ine=1320749806

Initial semituned results here:
http://img.photobucket.com/albums/v6...correction.png

The idle duty will really rise with increased MAT, but I noticed that the range of valve motion stayed more or less the same. Meaning PID is not exerting more effort at higher temps, and that the MAT correction is actually correcting for the less dense air.

Subjectively, the idle felt more stable at high temps. I turned off the A/W intercooler pump and let it heatsoak to 160F, but idling was rock solid. Killed the engine, started it up, no heatsoak starting issues. I still need to tune it because at high temp, the correction was a bit too much for the no-AC idle, and dragged the idle 50 higher than the target. But honestly, I couldn't really tell, it only came up in the scatter graph.

Great job Santa! ;)

No problems. Santa always like to please ;-)

I'm keen to work with someone who is in the colder climates (Greg is near the equator) so that we can tune/review impact to what happens when apply this firmware in those locations - any volunteers??

G

Just wanted to add that this works a charm. It was the only way we could get a stable idle on a FS-car (supercharged single.cyl, no flywheel).
We also mapped the VE curve from start to finish and positioned our idle rpm targets in the middle of downward VE slopes. If the idle valve overshoots target-rpm the VE drops away, adding a natural tendency to return to the target RPM. Lower then target RPM->VE increases. We would let it hop between a couple of these set points instead instead of ramping it down smoothly.

Interesting! I try to maintain downward spark slope and keep the VE pretty flat. Won't leaning it out above target create a tip in lean spot?

im in buffalo, new york (snow belt) area we'll be cold here pretty soon. ill try it out in the colder temps . where do i get the firmware? ive got all the time in the world to try it out...lol.. is it the same 3.1.4 on msextra?

Finally got to try the clutch/neutral closed loop lockout option today... wow, very nice! Much more stable feeling during low speed "parking lot/traffic light" conditions. It does however highlight the need for accurate calculation of the idle valve value during CL idle entry. "Last known good value plus dashpot" needs to be improved...once that is licked and you start closed loop idle with the correct idle duty...we will be very close to seamless...

http://img.photobucket.com/albums/v6...llockout-1.png

Crap.. that should have been VE dips.
The VE dips were not tuned in, we just used the normal intake and exhaust resonances. Spent quite of bit of time building the VE curve by mapping the engine every 100rpm or so to a constant Lamdba. The end effect is similar to building fueling and spark slopes but more effective.

explain to me this clutch/neutral lockout.

I'm intrigued. Are you saying that the motor has VE peaks and dips if you zoom in from say, 700-1500 RPM?

You can plod along in gear and it won't enter CL idle at all, never, no mater even if you go off throttle completely and essential the idle is pulling the car along - great for traffic cruise etc.

Avoids the rpm climb when you slam the clutch in, as the pid hasn't been fighting the load, it just casually enters CL pid and continues to idle normally.

A very simple od that took no time for me to code and make work.

You need to wire the clutch switch to pe0 / flex input.

G

PS - I sent you a PM and you've flatly ignored me, wassup with that?

isnt this what the RPMdot part of the lock settings are for? or is this another part of the code that ms2 doesnt have? MS3 has an adder to change the RPMdot lockout setting when the a/c is on.

if anything when this happens there would be an idle droop not a climb, as your chugging along at say 1200 rpm in 5th gear, then CL would activate and would want to lower the idle to your target and start closing the valve. Then when you hit the clutch you send the rpms to stalling range...I fought this until i tuned my settings correctly. It took no time at all to make it work :)

Jup.

No, RPMdot lockout exists, but obviously there is nothing related to a/c idle up as that is my code - and I could add that if needed. From what I've heard and seen myself, this RPMdot lockout doesn't solve for all problems.

No, the scenario without this mod is ... you are in 1st gear, idling along, you come to a slight incline and the idle is dragged down to 800rpm, the PID code responds and opens the valve more to compensate and in turn raises idle due to the load, and cycle repeats - with the valve opening all the time to compensate.... eventually, bang you slam down the clutch (to avoid hitting the car in front, or stall) and boom the rpm spikes until the PID catches it etc.

With this mod, none of the above happens.

G

Could you describe roughly how it looked - i.e. like how many peaks and dips you saw from 700-1500, and how tall/deep they were?

actually it does in the code, but no idle up adder that you havent added yet. ;)

can never think of a time i'd ever need this code function. Correct me if I'm wrong but this is just preventing an idle spike if you happen to be costing without throttle while the idle code is enabled up a hill for some reason and then hit the clutch in?

Hmmm now you have me interested. Could you post a new thread regarding the tuning process you went through to map your idle area? I'm sure it'll be quite an interesting discussion and deserves its own thread. Right now I do try to make a valley but to be honest the methodology is kind of hit and miss. :facepalm:

Spot on! If that's never happened or the spike doesn't bother you, than sure this mod isn't for you... but a few folks have asked for it and I too see how ti keeps idle silky smooth.... and it costs nothing to wire up and enable.

Also, I think it makes tuning a little easier (I guess)....

G

does it utilize the same input as launch control, or do you have the split the input?

Uses the same but doesn't impact each other.... Never used against each other anyway....

G