DIYEFI.org Forum

So I'm on the way to work today, driving my MS-II powered car, and it gives a little buck as it occasionally does. It's minor, overlookable, doesn't really effect anything... But nothing a Cadillac would do. I start mentally running down the list of probably causes.

First, if could be my inputs I made (always blame yourself first?), but I haven't seen any issues yet. Next, it could be the OEM sensors I'm using, which seem marginal.

Next it could be the software dealing with it. It does strange things when it sees a tooth it doesn't expect. But more likely, it's acceleration enrichment. Or, the idle motor. Or overrun fuel cut. Or deceleration enleanent. Or

...

wait a minute, how many exceptions to "engine at speed X, air flow at speed Y, deliver Z amount of fuel" can there be?!



I started thinking about all the various fudge factors (things like heat-soak handling by misreading the IAT sensor, or barometric correction which is actually a correction on top of the correction). the lists of conditions to enable or disable various enrichments and timing mods... And I think two things:

1) It'll be a long time till this catches up with the MS, in terms of all the challenges they've met
2) How much of what the MS does with artificial limits and windowings (ignore knock below X rpm, above Y tps, etc) is because they are doing such a bad job in the first place?

As stated here:
http://www.diyefi.org/forum/viewtopic.p ... =a&start=8
(the post has some disinformation but one good insight, read with caution or better still in context)
I was thinking about the heat soak issue - at Fred's prompting. I think this is an example of a "good" fudge. It takes a problem, knows where it comes from, how it works, and fixes it with existing (but not arbitrary) information.

It's not "giving up", which I feel so much in the MS world is.

So many things (my most well known gripe is the "PID" control) seem to have more constraints than can even (apparently) be documented. And I feel that in some of those cases, if the algorithms worked better, the number of variables used to define them would be fewer, and the results better. The MS is i/o challenged, to be sure, and they are doing a lot with what they have. But even given that I feel they could do better. The barometric correction shouldn't need correction. And if I wanted to turn it off, I should be able to. If I can't edit the table, show me what it is?

So, what's my point? I'm not quite sure. But I think it centers somewhere around an idea of "can we do things well enough, and commit to doing things right, that our ".msq" equivalent files don't end up a huge hodgepodge of obscure correction factors, and instead be a few, well defined tables and variables which define the motor and it's response based on physics and reality.

A fine example is the 'points in space' fuel table. I'm not sure it'll work, practically, but the idea of nodes is a good one. If I ever get off my duff, I want to write a true PID controller for the MS's idle, and prove to myself that things can be done better.

8InchesFlacid wrote:1) It'll be a long time till this catches up with the MS, in terms of all the challenges they've met

Yes, I guess so, but...

2) How much of what the MS does with artificial limits and windowings (ignore knock below X rpm, above Y tps, etc) is because they are doing such a bad job in the first place?

Exactly, probably quite a bit? That and poor poor user installations and bending over to them instead of making the user fix their broken setup.

I was thinking about the heat soak issue - at Fred's prompting. I think this is an example of a "good" fudge. It takes a problem, knows where it comes from, how it works, and fixes it with existing (but not arbitrary) information.

There is no doubt that some things will need massaging, but I want to keep them to a bare minimum. One method for this is to include adjustability into the basic parameters and just always use that. Default it to a reasonable flat curve or something and always use it.

It's not "giving up", which I feel so much in the MS world is.

I agree. It remains to be seen how right or wrong we are though. They could be doing an excellent job of things, but I just have my doubts (mostly because the code is all but unreadable).

And I feel that in some of those cases, if the algorithms worked better, the number of variables used to define them would be fewer, and the results better.

I agree.

But even given that I feel they could do better. The barometric correction shouldn't need correction. And if I wanted to turn it off, I should be able to. If I can't edit the table, show me what it is?

Altitude!! (Barometric) correction really REALLY depends on setup. There should definitely NOT be a "standard" correction that you correct, there should just be one correction that you set either to do very little, or a lot, ie, whatever works for you. Stock standard could start out "do nothing" and maybe we later learn that the default should be a particular shape for "normal" engines.

can we do things well enough, and commit to doing things right, that our ".msq" equivalent files don't end up a huge hodgepodge of obscure correction factors, and instead be a few, well defined tables and variables which define the motor and it's response based on physics and reality.

I sincerely hope so. Check out my draft xml description of tunable variables (msq) in the releases docs dir.

Fred.

Regarding baro correction fudge factor:

Instead of using a fudge factor, one could simply make the VE table lookup based on "Percent_Ambient_Pressure vs RPM"

I'm willing to bet the fudge factor would not be needed, based on what I have read about the effect of increased altitude on airflow and VE.

Common method:
Using MAP only as the lookup, as you go up in altitude the table operating point changes vs load, falling toward the lower pressure part of the table. This reduces the calculated VE. In actual fact the VE won't drop much if at all (could increase?) due to reduced back pressure. This will result in a mixture leaner at higher altitudes.

Proposed method:
If you make the table lookup relative to %ambient, as the ambient pressure drops the operating point in the VE table shouldn't move much if at all at a given load. The mixture should stay pretty much the same. No baro correction required.

Just a hypothesis, hope someone tests it out. Come to think of it, this may be related to the "multiply map" issue/discussion?

thebigmacd wrote:Just a hypothesis, hope someone tests it out. Come to think of it, this may be related to the "multiply map" issue/discussion?

I don't think it is related to that, however I do think that you have the option of your way and the old way in both ms2e and ms2 these days. I'm not certain which is right, but if you want to do some research and post up a thread, I'd be interested to read up on it. At the least, the user should have full control of any corrections, though it would be interesting to see if you are right about not needing them.

Thinking about it now, with regards PURE VE you are probably right. So long as MAP is multiplied in, and the VE is realistic and AFR separate, I think it could work. Still, more reading = better. I look forward to seeing what you come up with if you can be bothered :-)

Fred.

Fred wrote: Check out my draft xml description of tunable variables (msq) in the releases docs dir.

Fred.

There's a docs directory? Wow. We should have a second forum for folks who pay attention. Guess I'll have to dig for it.


As to Baro, there's a discussion on MSEFI about which way to go, richer or leaner. How could you implement a correction, and not know it's sign??

Perhaps something like a post turbo/pre-muffler MAP sensor is what we need. On the one hand, this is getting a bit off topic, on the other hand, I'm not sure what there is left to say on the topic I'd suggested. Mainly the idea of having one table, fully open, that you adjust, instead of a hardcoded table that then gets multiplied by another fudge table which I wanted to avoid.

8InchesFlacid wrote:There's a docs directory? Wow. We should have a second forum for folks who pay attention. :-)

Yeah, in the release file, when you unzip it it's right there next to src/ and lib/ and bin/ ;-)
I lied, it's not in the docs directory, it's at the top level even more obvious! :-)

Mainly the idea of having one table, fully open, that you adjust, instead of a hardcoded table that then gets multiplied by another fudge table which I wanted to avoid.

Absolutely, the only exceptions to that will be where the foundations of the thing are mathematical and should be correct. If the thing is from a table in the first place, it will be adjustable.

Fred.