MSII: PWM Converter Board w/ CL Idle on NB Miatas
 

Woot. Closed loop idle fucking works! I'm still tinkering with the PID settings, but its slowly getting there.

I finally got the PWM converter board yesterday and I assembled it this morning.

http://img217.imageshack.us/img217/7296/p1013556jp.jpg
Here is the wiring diagram. It can be used for any NB miata, whether it is using a full self-encased modified MSII (like franks former setup), or it can be used with Abe's Adapter board. Keep in mind, The wiring is for Abe's adapter board, and where the transistor is placed, there is a jumper between pin 1 and 2 on the PWN converter board. If you want, you can use the transistor that may already have, but you will require a 12V ref to the 12V pin on the board, as well as a ground to the A_GND on the side of the transistor. Using abe's adapter board will NOT REQUIRE A 12V reference AND THE A_GND CONNECTED.

On an NB miata, our valves run at close to 500Hz frequency. This is the purpose of the PWN converter board. On MSII, the frequency setting should be set at 1 for accurate and precise CL idle control. If you use anything higher than 4, your idle will suffer with closed loop, and you will have to use PWM warmup as your source of idle control.

When you assemble the board, for our cars, use the top 2 jumpers, which appear on the side of the IC chip, which is pictured here. You can see three jumper sets.
http://img266.imageshack.us/img266/8165/p1013807.jpg
It appears to be the "bottom two" but if you need to reference, jbperf.com has the diagram.

Wire it up, according to the diagram.
http://img252.imageshack.us/img252/4572/p1013806.jpg
http://img252.imageshack.us/img252/6436/p1013805.jpg

The next post will be regarding CL idle settings on your MSQ.

Here are my current settings for CL idle. If you have any suggestions or any thing to say, please post here, and I'll take a note of it.
http://img407.imageshack.us/img407/4...olsettings.jpg

This will probably be unnecessary when MSIII comes out, but hell, it works for me as of now.

OMG, I have to do the tuner studio thing. Keeping all those setting straight in your head in separate windows has always been the big hang up. Having them open at once is great.

I can only suggest to anyone - use Tuner Studio - it's way better than Megatune and you get used to it very very fast.

@ Marc - great work.Going to have to add this to the DIYPNP over the winter...

Greets

In MS3 we've made them all 1 window. We may eventually backport some of the usability stuff from there to our ms2/extra inis.

Ken

Marc D:

Just some suggestions:

1) Having the "RPM with valve closed" and "RPM with valve open" so close together is giong to make the PID gains very sensitive. It might be hard to get it to idle right without oscillation this way. Of course since your Idle open duty and closed duty are so close together, this somewhat counteracts the behavior caused by having the RPM values close together, so it might be fine.
2) I would make PID delay 3 seconds or longer. This just gives the RPM a chance to become stable before going into PID.
3) I usually like a longer crank-run taper but that's just personal preference.
4) A longer ramp to target time will give you the ability to set a larger P-term, which will catch things like the AC turning on better. I usually use 3 or 4 seconds here.
5) You could probably get away with a much shorter control interval. I use 70 ms. This will also help catch sudden load changes.
6) PID lockout rpmDOT threshold should be much much lower, or else you'll get into PID during decel. I use 50-75 here.
7) PID lockout max decel load should be set to just under the lowest load you see at idle.
8) PID disable RPMdot should be set between 100 and 200 RPM. This is for those who don't rev-match when re-engaging first from neutral while the car is moving. It turns off PID when RPMdot goes over the threshold so that the next time PID engages, it's not so low that the engine stalls.
9) I typically use as low of a TPS threshold as I can. On the 20v 4age, I'm using .5%. Having this too high will result in PID staying active while you rev the engine, and will cause the valve to close, and the engine to stall the next time you lift off the throttle.

Ken

The *ONLY* major problem people are having with TunerStudio is if you have an old computer. It runs a little slow on old computers where MT ran fine.

Just a warning to those who are going to switch. If your computer is older than 3-5 years (based on the feedback I'm getting from various users and ms3 testers) old, it might be a bit sluggish with TS.

Ken

Ken,
Thanks again for all the good pointers. I still haven't even caught up with the answers to my last round of questions on the MS-IIe forums.

The biggest thing I always hear from you, and the piece of advice I ignore the most (heh), is basically not to use PID for anything except long idles.

My situation, where the car will idle 100% ok with the radio off, and idle 100% ok with the radio on (and different settings), but will stall coming into a stop.. doesn't seem like the current PID worldview supports it?

Or, if the idle valve is staying open (i.e. close is set to "never"), then it should handle that very well? Basically, you're counting on what worked last time you were idling to pick the value, as opposed to figuring out a value each time?

I'm worried I'll not be able to, since the music/fans/etc varies more even stop to stop when driving than some might expect. Guess I'll try it soon.

Great idea combining all the idle stuff in one window. :-)

For the long-idle thing, pay attention to almost any modern car and how it idles. Those turn on the PID control after the car comes to a complete stop. Since we don't have VSS, all those settings are basically there to emulate that behavior. So if you don't let it idle for long, PID should not even engage. That's how my last 3 or 4 daily drivers have worked, and that's what I set out to emulate. My RX8 idles like this, my old Vibe did, my old Alero before that did, and my wife's Vibe does.

Every time you lift off the throttle, even if you have the valve set to close while driving, it opens to last-good+dashpot adder duty.

What worked last time + the adder is the start point for PID to take over again, so really it does "figure it out" every time.

For cases where that's not good enough, I will be adding feedforward control, which will basically intercept the AC button being pushed, add an adder to the current position, and turn on the AC clutch just a bit after that. For the fan, an adder will be added when the fan kicks on. Either way the adder will be there the next time you come to idle, just as if the last good value was with the AC on.

In the meantime, a large dashpot adder works pretty well for catching everything.

I'm also going to be adding the ability to fine-tune idle speed control with a secondary I-only (or maybe PID, I have not decided yet) loop that will be able to interact with the PID controller running on the idle valve.

I'm convinced that a lot of your problems with coming to a stop, etc... are just due to settings and the fact that (unless something has changed) you're running at too high of a frequency setting causing the code to have very inaccurate valve control.

There are really plenty of people using this saying that it's as good as their factory control was the way it is now, and I intend to make it better still.

Ken

I'll give it another go. A big part of it was the philosophy difference, I was trying to force it to be the PID and not the other support settings put in.

The thing that I never got, and I have to read the other thread before getting into it, is the P-only didn't seem to work as P-only, in the limited testing I did. Will get back to all this soon. Thanks again, and for the record, I never had these kinds of loads on the car while stock, so I don't know if it would have handled it well or not.

Yeah, I responded to that on the other forum too. It will never converge on a target with P only because it's a type-C PID loop (Three Types of PID Equations). In this type of loop, the P term will only cause responses to changes in PV (RPM in this case), regardless of how much error there is. This way works better for catching large changes due to increases in load, but will never actually converge on a target by itself. For that the I term must be used.

For boost, I'm probably going to change it to a type-B controller so that P can respond to changes in set-point or process variable.

Ken

Thanks for the tips, I will definitely continue working on the settings.

I played with the settings a lot more, this time I set my open RPM to about 1800-1900, and the closed RPM to about 700.

I set the idle open duty to about 57, closed duty stayed at 27. I put the idle activation RPM adder down to 200, and TPS threshold about 0.5% like you suggested. The Dash pot adder remains at 4.

I set the PID delay to about 4, crank to run taper to 3, and PID ramp to target to about 4. PID control interval now sits at 40 instead of 200.

my PID settings are now completely different, they are set at 115 for P and 165 for I. I did al the running while my lights are on, and my fan came on occasionally. FOr the time being, the settings are just about perfect. I switched on my A/C, the idle caught slowly, but it didnt dip too low to the point where the car will stall. After it caught, it idled close to my set target RPM about +50 above what it was set. Not on target, but very close.

Very happy that the car no longer bogs with it A/C on. If I ever had A/C the car would stall, or when coming to stop it would stall if I didnt keep my foot on the pedal to let it come to a rest. CL idle FTW.

Abe, get on it, its worth the trouble.

Yeah, you *might* be able to speed up the "catch" behavior using idle advance. Just set it up so that it comes on about the same time as PID idle, and then make it so that higher loads have more timing. That will help catch the sudden load increase with AC coming on.

The feed forward control will ultimately completely get rid of the dip when AC comes on, but for now, turning on and using idle advance should help.

You could probably get it to drop all the way down to the target by slightly decreasing the RPM with valve open (and leaving the valve open duty alone). That kind of situation is exactly what the I-loop for using timing for speed control will help with though. It would just slightly lower timing to get rid of that 50 RPM error. That said, 50RPM isn't that bad.

Very glad to hear that. I put a lot of hard work into getting it to the point where it would catch AC and e-fan coming on and keep the engine from stalling.

Ken

Ok, I just came back form a long hour and a half drive on the freeway, but I noticed something pretty strange.

The idle gets "locked" at about 2300 RPM, basically, the highest "open valve" setting, which was about 57.

It would go into closed loop, and then immediately jump out of it, repeating over and over, with the RPMs remaining at 2200-2400 until I shut off the car. When I restarted the car, The idle went into CLoop, then it settled. But when I started driving and RPMs went above 3000, it repeated the same thing as I got off the freeway.


Whats up with that? Is that the "lock out" that I was reading about?


I set the Open Duty down to 50, and kept the closed duty at 27. I Increased the RPM adder to 400. I also lowered the RPM valve open setting to 1700, and changed the PID settings to 76/167/0. Didn't have time to tinker any more with it tonight, I'll see what happens tomorrow.

Ill try to get a datalog tomorrow if this continues to happen.

IT sounds like PID was engaging when it shouldn't.

Most likely the lockout settings are incorrect, and causing you to go into PID.

If you're using megatune, the CL idle indicator should be at the bottom, and will tell you if it's going into CL idle.

My suggestions number 6 and number 7 should keep this from occurring. Set the lockout RPM setting to 50-75, and set the lockout MAP setting to just below where you idle with no load.

IF you're using TS, you'll have to use the standard gauges that look like MT to see that indicator.

To explain the lockout feature:

Sometimes the code can get into a situation where you get "locked out" of PID idle... In this situation, RPM will be stuck above the RPM+adder value. The lockout settings are there to help the code detect that situation and engage PID anyway.

The RPMdot setting should be set as low as possible so that during a decel situation when you're off the throttle, the code can see that you're decelerating (even if it's a very slow decel) and avoid enabling PID. Also, if MAP is below the MAP lockout setting, it won't enable PID, so that setting should be set a few kPa under the lowest value seen during idle for MAP.

You probably didn't need to change any other settings other than the lockout ones.

Ken

Also, make sure PID disable RPMdot is set to 100-200. Setting it to 0 will make PID turn off pretty much any time RPM changes once PID is engaged.

Ken

does the board do what it's supposed to do ie solve the iac hum? I had a very annoying loud hum on mine :(
You're running 488 Hz, right?

No hum frank. Its nice and quiet. Its running at 488Hz, with the 16x multiplier set on the pWM board. The setting on MSQ is 1 as you can see, thats at 30.5Hz.

Did you try the lockout settings I suggested?

Ken

This type C thing bothers me. I just don't get calling that a "proportional" controller. It's an integral controller. Which is semantics and there's no reason to get my panties in a bunch over it, but it sure is annoying. I know you didn't invent the term. :-)

I'm very curious about getting all the lock outs working, I had this issue, too, all the time. It made NO sense, before, when I thought the controller contained a P-term... It would be impossible to get stuck at 3000 RPM with a P-term in the equation. If you were idling many times higher than the target, the valve would close. And I-term would cause... the valve to close. And D-term wouldn't come into play, except to slow the fall.

I'll have to read the other thread to get the answers about "what do you do when the closed and open idle values have nothing to do with where the engine idles with the valve closed or open.

Mark, what do you idle at with the valve closed? What do you idle at with the valve open?

Ken,

I tried the settings you suggested, it seems to be working ok, but I still get "locked" out occasionally, if thats what you call it. It would idle the highest setting for "open valve" and it wouldn't settle, but idle would oscillate at that idle speed. Its getting annoying.

It was worse when I had set my RPM adder to about 200, so I set it to 400 and it wont do it often, but it will till occasionally lock out.

Another thing I noticed, the target RPM is never really "reached." I have it set at 850 for fully warmed up, but it always idles around 1000-900. I've stopped messing around with the PID's but I will try to work on them some more.

One more thing that bugged me is when I came to a stop, the idle didnt directly "drop" to the right RPM i specified, It always drops about 100-200 rpm higher, goes up a little bit, then finally rests. Sometimes after very heavy load changes, the idle oscillates quite a bit. I guess I gotta keep working on those PID terms.

Abe,

If you're referring to settings in the MSQ, I set my closed idle to 700, and my open idle to 1700-1800, cant recall (on my mac right now). With my bleeder set, I idle at 750-800 with the valve completely closed. My DC on the idle is always around 32-35% DC. I may loosen the bleeder valve a bit 'til the idle settles at 800-850 with my DC at 28%

Ah, makes sense. My car is controlled entirely by the idle valve, i.e. closed valve is stalled, and open valve is ~5,000+ rpm. I think you just have to pick arbitrary numbers.

How bad is the buzz, frank? I run it at a multiplier of 8, and it doesn't bother me at all.

Can you post a datalog of this occurring? I want to see specifically what's happening, and see if it's PID engaging while you're in overrun, or if it's PID not engaging when it should. Either way, I should be able to suggest good settings for the lockout stuff if I have a datalog that shows the bad behavior.

If you have the min and max RPMs reasonably close (500 and 1800 are the settings I use for most engines), you should be able to get very close to the target by increasing the I term. I would not mess with the D term at all as it tends to dampen the P and I term and make them less sensitive. I don't use D term at all on any of the engines I tune.

It's not going to drop directly... that is what the PID delay setting is for, and as I was telling Abe, the behavior I was going for here was to match most OEM setups. Those do not go immediately back to the idle RPM either. They sit a little high for a few seconds, then slowly drop back to the target. This is to "catch" the engine when it's decelerating and keep it from stalling.

If a very heavy load change is causing a lot of oscillation, you may want to use the idle advance setting to help add timing when load increases or take out timing when load decreases. This can help the idle code not have to change the valve position as much, allowing you to tune a slightly lower P term to get rid of oscillation.

Also, You can get into oscillation if the area that you idle in is not "boxed in" both for timing and fuel. When the load goes up does the AFR go leaner? richer? After it starts oscillating does the AFR bounce around? IF you answer yes to either of those questions, then you have some fuel table tuning around idle to do. Otherwise the idle code will start fighting with the changes to AFR that the extra load causes and you'll get into an oscillation. Running a lean AFR around idle can make this worse, as can running too much advance at idle.

The code tends to work a bit better if you set your idle screw so that the engine idles 200-300 RPM lower than the your lowest target RPM. Changing the bleeder to give more air may hurt.

Also, an exercise that will help get better response is to see at what duty does the valve actually start affecting RPM. The way I figured this out on my rx7 was to purposely open my idle screw a bit so that it would idle at 900 rpm (100 above my target) with the idle valve all the way closed. I then turn on something that drops the idle below the target (headlights in my case) and watch the idle valve duty and RPM. I then make a note of the duty where RPM starts to go up again. That is the lowest duty you should ever let PID go to. This test is best done with cool IATs.

Ken

With a multiplier of 8, PID idle will be nearly impossible to tune correctly. Having Jean's frequency multiplier is a must if you have to set the frequency that high.

Ken

Pretty bad actually, I tried different numbers, but it would always be there. That and the slow starting were the key factors to remove the MS. Does an NB start better on full sequential injection?

Plenty of people who are smarter than I am are using it. If it works for them it works for me. It's not an integral controller, it's proportional. It only makes a difference if the conditions change where an integral controller would continue making a change as long as the target doesn't match.

There are only 2 lockout settings. The RPM one and the MAP one. All the other settings are for controlling when it gets into idle in more normal situations. If the lockout settings are causing a problem, you'll never even get into PID, which means that PID has nothing to do with the problems you had. It was never engaging! Please read the thread over at msextra about what each of the settings do.

The controller DOES contain a P-term. It only affects the valve position when the RPM changes. This is exactly the same way that the kind of standard P controller that you are talking about works, except that its response becomes smaller the closer that you get to the target. I chose the type-C controller so that things like AC coming on would result in a large response from the controller, keeping the engine from stalling. Did you read the page I linked about the different types of loop? All of it?

I could easily give the P term the behavior you're looking for but then the response to sudden load increases would be bad. For boost I'm going to switch to a type-B loop to more quickly account for target changes, but in idle the target does not change often or quickly, so there's no need.

I labeled them that because for 90% of the cars out there, setting them that way works fine. That said, they really just bound the conversion to unitless percent, and therefore affect the sensitivity of the algorithm.

Marc D:

Have you had a chance to get me a datalog yet?

Ken

Just a couple more tips for tuning PID:

1) Tune I first with no load on the engine. Set it as high as you can without getting oscillation. Do this with P and D set to 0. This should get you very close to your desired target.
2) Set P between 50 and 100, and turn on your air conditioning. If it stalls, set P higher, if it catches the idle and keeps it from stalling, but oscillates a lot, set it lower. Repeat until the behavior is what you want.

It's really that simple. Sometimes setting the control interval too low can make tuning a bit more difficult, I usually recommend using a setting between 50 and 100 (I use 70).

Make sure that the CL idle indicator is coming on in the tuning software. This will help a lot in telling what is causing whatever issues you're having.

Ken

You're right, it would continue to change, and an integral would be proportional to the amount of error. It's a D-term, I did the math once a long time ago, about what your D-term really was (not an attack, calling it "yours", I just mean the one you are implementing)....

But traditionally, a derivative term is something which reacts to the instantaneous change in RPM from sample to sample. At first glance, when RPM makes a rapid change (a drop, let's say) it looks like you respond proportional to the rate that the RPM changed in a fixed amount of time, i.e. d(pv)/dt.
Which tells us that the equation should reduce the the difference between the current RPM and the original RPM, and the valve position should be the valve position it started at plus a difference proportional to this initial RPM.

Which makes me think that to really do this right, you would want to seed R0 with the target RPM, and C(0) with the baseline valve position (I'd recommend the PWM-warmup positions, or some other number to be supplied by the user)... Then you would have a system which is a P-controller when used in P-only. It sure looks weird, but it would work. The only issue is not taking the RPM from when the PID loop first gets activated to seed this R(0), but to use the target RPM, and the best guess (i.e. the previous valve opening, minus the adder - which you could add in but not in the equation, let the controller recover that difference)....

Then I bet the thing would behave better.

Of course, lockouts (Again, Kudos for the CL indicator!) are more my problem than the rest, still, I think this would help it to behave. Its a bit counter intuitive, but the math doesn't lie. As I said, the only weird issues is coming in and out of PID, which I think means reseeding the R(0) each time.

Does it do this? Could you make it? Maybe I'll upgrade to the latest beta and try it, but I'd much rather you wrote it, Ken, since you actually are good at that sorta thing and I just scribble on whiteboards a lot.

Ah, here's what I was always wondering (and if it's just a label, fine!)... Do those have to be the limits? If I could just give you two points (or even just have the computer grab it like setting the TPS), but allow the valve to go further? Can I set "what valve position gives me 1800 RPM", but allow the valve to go further than that?


Yeah, that's one thing - you often don't notice how something works (i.e. a stock car) until you have messed with it, then you think how it SHOULD work, not how you've seen it work.

Certainly that catching is the biggest issue I've seen.

Ken,
Can you use this even with PWM warmup mode? I'm sure I could lose 800 rpm that way. I've sort of built that into my fuel/timing maps... Actually, its based only on MAP? Then is there a difference between that and tuning your ign maps...? Just curious.


So you DO want a flat response down there? For my non-CL idle, richening and advancing down low keeps it from stalling, but I could run a flatter map in order to make the CL work better.


I'm sure I have way too little...


Is this what the (as I understand it, broken but will work) idle valve test mode does, so you could do it more slowly?



That's something that never made sense, probably a question for the MS forums. Certainly I've had the motor catch and run for a revolution or two if there's fuel in the runners, then stall (being run by the starter), then fully start, telling me the MS knows when to spark (I'm in banked mode), but is choosing not to fuel. It's very strange and seems eminently fixable.

So which is it Abe? A D-term or an I-term (like you said before).

Abe, there's nothing wrong with how it behaves now. In all your explanation, you're leaving out the fact that I add the output of the PID loop to the current valve position (or rather you gloss it over), which means you have to take the derivative of the actual PID math. The derivative(integral(x)) gives you x in this case. If I was using my current math without adding to the current position, then yes, what is now my P term would be a D term, the I term would be the P term, and the D term would be a 2nd derivative term. But since I'm already integrating the whole equation by adding the output of the previous time through to the current output, I had to take the derivative. This is exactly what is detailed in the typeABC link I provided (by someone who has a very large amount of experience in the industry working with control theory). If I switched the loop to a typeA loop (still taking the derivative of the entire thing, esentially change 2 lines of code), it would behave exactly as you think it should. The problem is that the behavior you're looking for is undesirable because it would make it difficult to actually catch the idle when the AC or other load is added.

The code is always seeded with the current RPM when going into the PID loop so that you have a smooth transition into it.

You're right, the math does not lie. Because I'm adding the previous position to the current PID output, it is necessary to take the derivative of the entire equation in order for it to be a proper PID loop. It is further modified to make the P term respond equally to changes in PV (RPM) regardless of how close to the target you are. I made the decision to do this in order make response to sudden load changes faster.

No, It's actually better to take the current RPM as the position because then you don't get a violent response when PID is enabled. You get a nice smooth ramp to target. The current code also has a ramp-to-target feature that will take whatever rpm you're at when the code is engaged and make that the target, then slowly ramp the target down to the final target. This allows you to set a very large P-term, which makes catching idle speed decreases much faster.

Again, the numbers are just the bounds for the conversion to unitless percent. You can go above (or below) these numbers without hurting anything. I labeled them this way because in most cases setting them the way they're labeled provides a good balance of tunability and sensitivity. The actual affects to the PID loop are that making the closed and open duties further apart makes the code more sensitive. Making the rpms closer together makes the code more sensitive. Setting the two so that the lower RPM matches the lower valve setting and the upper RPM value matches the upper valve setting makes them usually makes one balance the other out. You can change either of them further apart or closer together arbitrarily in order to help response.

Why should it work differently? The way the factory does it is best for catching the engine when RPM is falling (push in the clutch for example), and is best for catching situations when load or IAT increased since the last time their "learning" (in our case PID) algorithm was active. This also saves time on the ECU since the PID algorithm does not have to be active when RPM goes up and accuracy on other parts of the system are of utmost importance. The factories know what they're doing, they spend millions of dollars and man-hours figuring it out. We modify our cars because we like to tinker, or we want more power, but that does not invalidate the algorithms the factories use to control their engines. Therefore, I believe the right way to go is to emulate what they did. There are reasons for what they did.

You don't want stalls, so it's best to catch the RPM a little high, and slowly drop to the target.

Try it out, idle advance is completely independent from closed loop idle speed control.

You don't want to have differences in AFR that can make RPM change on their own. Otherwise the PID code will fight with the changes that the varying AFR are causing, and create unrecoverable oscillation.

I'm not sure what you mean here. Idle valve test mode is fixed in the latest 2.1.1 beta (which we're not going to update any further) and in the latest 3.0.x alpha.


The MS starts fueling at the same time it starts sparking. There are other factors, like how much fuel does the engine need to actually fire for example that can cause issues. When I've seen the behavior you describe, increasing the cranking PW at that CLT has helped.

If you want to continue to argue about the PID code, please take it to msextra.com. There are people in this forum who just want it to work and don't necessarily care what we think about whether it's correct or not. I'd like to stop cluttering this thread with our argument and get back to helping the users get their closed loop idle working.

Ken

Sure, and I'm not trying to bash, but to better understand and suggest what improvements I think will genuinely help. I'm learning a lot. :-)

Just to be clear, to understand how to set it up (I'm sure many of my problems come from this).. The valve will or will not go outside those bounds? If I set a valve position that idles at, say, 1,500 RPM (call it 30%), I'll never see the PID code set the valve to 31%?


That's what I was getting at, if poorly. The average person doesn't try to understand how something works until it becomes a problem. These behaviors (not rushing directly to target) are there in the factory control, but people don't notice it, so they expect your code to do something else - i.e. how they think the factory behaves, not how it actually behaves.

Most certainly will. Is it more than advance verses MAP?

Makes sense, though I'm a bit confused - how do I determine an AFR change that makes RPM change? I increase load to get RPM to drop, then they do, and if AFR goes up, or down, how do I know what's wrong?

Could you try to explain that in more detail?


So there will be no V2.x release version as the final? Pardon my ignorance, will the V3 code run on MS-II?

That qualifies as fixable. If that's really the case, awesome! I will definitely be looking at this, I've had to crank two rotations all the time.

That's all well and good, but many of the changes you are suggesting will not actually improve things, but instead will make them worse. For example, I already tried the ideal PID (I had a curve of "start values" and pid always modified the start value) and had several people test it. It didn't work. It wouldn't respond well to large changes in load, and as MAT climbed, the values needed changed.

I switched to the current method of adding the PID output to the last known position but with type A, and it had less problems, but still would not respond well to the AC coming on. I settled on a type C loop after finding that it essentially does exactly what is needed.

Your suggestion to change the "seed" of the P term is also not good. I tried it the way you are suggestion in my development, and had a user report that every time PID engaged, the valve would open before closing... RPM would go up every time it engaged. The fix I added was to seed the P term with the current RPM.

That's the last I'll say of it here. If you want to continue, we'll continue in the proper forum for such things (and anyone who is interested can come look).

The upper and lower bounds for the valve position are just that, upper and lower bounds, the valve will not go above or below those values. However, the upper and lower RPM are not hard limits. They are used only for the conversion to unitless percents. If your valve opens to a point that takes it to 2000 rpm, and your upper RPM setting is 1500, the code will not stop the RPM from going to 2000 rpm.

OK, I misunderstood what you were saying there.

That's how I usually set it up, although you have to be careful here too, getting the AFR steady all around will help. You can get into oscillations due to idle advance as well as AFR changing.

I can usually tell by fixing the AFR change while the oscillation is happening. If by fixing the AFR change the oscillation goes away, it was the AFR change that was causing the issue. Generally you can tell this is happening by just looking at the AFR and valve duty in a datalog. You'll get a situation where both change in a sine wave fashion but opposite to each other (AFR goes up, rpm goes down, PID corrects by increasing the valve duty, AFR goes down, rpm increases more, PID corrects by decreasing valve position... oscillation).

The final official release of ms2/extra 2.1.x is 2.1.0b. I had originally planned a 2.1.1 release with a bunch of stuff backported from the ms3 1.0 firmware, but decided that in the interest of time, I would not do that. So now all ms3 1.0 changes that I'm going to backport are backported to ms2/extra 3.0.3.

I recently saw issues like this on my rx7 as it got colder. I fixed them by increasing the cranking PW. Be careful not to go too high though. Increasing the cranking RPM to 100-200 above where you actually crank can help too, as well as tinkering with skip pulses (making it lower usually helps).

Ken

Marc,
Any updates from the Real World? :-) Very interested in this.

Ken,
Er, where is the beta? I can only find the release? My old links might have broken when the board was down....

Heh I found it but closed the window and lost the link. Will post the firmware in the first post of the baseline MSQ thread once there is one. It's really confusing because "version 2.1.0" can actually refer to several incompatible versions, so you have to have the date code.

Still trying to figure it out.

Im getting a datalog of it tonight. Didnt really have time to lug around my laptop with me, but its friday night, and theirs plenty of time.

@Abe - here you go:

MS3EFI • View topic - Firmware

he original link was lost at the big crash at msextra.com.

Greets

PMing you my phone number in case you have any questions.

I'll be out of service on and off tomorrow (doing a little rock-climbing in an area with a bad signal tomorrow for part of the day), but if it rings, I'll answer, and I'll be back home in the afternoon (EST).

Ken

Awesome, thanks, that's a big help. A very handy thread.

Beware the "latest" beta is not the latest, and it actually has a bug. There's a 10/27 (that is, october) release which I think is the real latest. If it wouldn't step on any toes, I'd rename it "2.1.2" and post it on there so the world has a "go to" version. :-)

Ok, I was able to grab a datalog of the "lockouts" ive been getting, ive also included my MSQ.

Hopefully we can figure something out.

Alright, whatever is going on during "strange idle" is not the idle code... That's due to your overrun fuel cut settings. You have it set to 0 seconds delay, above 90 degrees, below 24kPa, and your engine is actually hitting those conditions. So you need to retune that for sure, and it has nothing to do with the idle code. You could probably avoid getting into that situation as well by setting the cranking duty table to a lower duty at the temperatures you're talking about.

The idle after settling bouncing around a bit also isn't the idle code... if you look at the PWM duty it's stable and not moving around. However, your AFR is in the 15's close to 16, and oscillates in time with the engine RPM... I would suggest making the idle a bit richer (14.7 at the leanest, maybe a bit richer).

This will make it easier for the idle to recover from sudden load increases, as well as making it harder to get into a state where it's oscillating. The fact that the PID code isn't responding to the change in RPM is because you've had to set your P term very low to keep it from fighting with the AFR and timing changes. If you can get rid of those AFR and timing changes and richen it up a bit, you should be able to lower the idle a bit and dramatically increase the P term to help it respond to sudden load changes.

On my rx7 (granted, it's a rotary so I have to run a lot richer than a piston engine) I run 12:1 and 5 atdc timing at the lowest loads that I see during idle. The rotary likes to idle at those settings, and it's super smooth. I have my P-term almost at 100.

On the corolla, I idle about 13.8-14.1 and have similar PID settings to the rx7. On that engine the largest sudden load occurs when the fan comes on, and even then the engine drops from 800 rpm to 650 then recovers in about a second.

If I run the rx7 leaner on idle, it starts misfiring and oscillating and then the idle code starts trying to correct for the oscillations.

If I run leaner on the corolla, I have to run about 15-15.5:1 before I have major issues maintaining stability, but anywhere above about 14.5 starts causing small oscillations unless I'm REALLY careful about getting the idle AFRs to be stable all around the idle load and RPM ranges.

Ken

any news Marc? I am really looking forward to see some updates.

I had my DIYPNP board with the PWM converter up and running - it was idling quite low @ ~675 rpm.

Zaph, you're using the closed loop idle? Mine will idle anywhere (pull up a hill in 2nd at 600 rpm), but no close loop and no multiplier.

Trying to use CL idle - but I can't tune it at the moment because the car is in winter sleeper mode...

I'm waiting for my PWM board too; I'll let you know when it arrives.

Jim

ive been real busy to do any real changes and fixes, and it seems my motor may really be on its way out. Ill keep you updated

I have a PWM board, but until customs decide to release my MS kit, I can't do much with it :(

Customs decided to release the kit and charge me $76 in the process. How they came up with the number is a mystery, but I'm glad it's here so I can start building :).

Pretty similar to mine. I think I just use 12k, which actually gives you BETTER noise reduction.

I have the 2 13K resistors on order from Mouser, so I better use them. They're in Paris right now.