My techie thoughts on changing carbs for EFI

[bhowden]

No, what's that?

Do a google search on megasquirt AVR. It is a spin off group that built an AVR based megasquirt that is programmable in C. Lots more memory and some more io ports. Lots of common setup with megasquirt.

Brian

[HotStreetVw]

megasquirt 2 will be a 'piggy back' type for the megasquirt, all the software is coded in C.

No, what's that?

Do a google search on megasquirt AVR. It is a spin off group that built an AVR based megasquirt that is programmable in C. Lots more memory and some more io ports. Lots of common setup with megasquirt.

Brian

[davygrvy]

No, what's that?

Do a google search on megasquirt AVR. It is a spin off group that built an AVR based megasquirt that is programmable in C. Lots more memory and some more io ports. Lots of common setup with megasquirt.

Brian

http://cvs.sourceforge.net/viewcvs.py/m ... /firmware/
Whoa.. That's cool.
Feed me, feed me..

[davygrvy]

For instance....lets say that MS has room for 3 temp sensors in its matrix (I have no idea so I'm just speculating here)...but you are only using one. Say you want an overspeed sensor. Ok...install the sensor....and convert what comes out of it to the same form of signal in the same range as temp sensor. Then...yes...you will get into the issue of what value in reference to output...the ECU gives that input signal.....but in the dumb eyes of the ECU...its simply another input to add weight to its decision at any given time. It doesn't know hot or cold. Its just a parameter to add into the matrix. If the ECU allows to much wight to the signal....limit the signal. Its simpler than reprogramming...and a lot more linear.

Ray, thank you, I value your opinions. I read about fuzzy math years ago, and feel I want to give this a shot in a fuzzy modeler. For some reason, I'd much rather start from scratch.. maybe it's the journey for me rather than the destination. Most likely I'll probably get stuck and not complete it, but I got this itching vision I can't shake.

I hear you when you mention the control parts being the 3D inputs, with tweaks following it such as O2 lean-off for steady state and enrichment for cold, but what I was saying is that there are more inputs to consider than three. I'll have to hit the theory docs, but I'm thinking seven for this moment.

1. engine speed
2. throttle position
3. MAP or MAF
4. head temp
5. exhaust gas temp
6. oxygen sensor
7. steady state (cruise)

to derive the output for injector "on time". And why not try putting that all into one big fuzzification rather than a lookup table? Fuzzy math is good at modeling very non-linear systems at least from what I remember.

I just had this crazy idea of using the inverse of what the tach meter ballistics are and digitally process the analog meter errors out of it

[R2.0]

I think you may have your inputs mixed up for the control scheme you want.

1. engine speed
2. throttle position
3. MAP or MAF
4. head temp
5. exhaust gas temp
6. oxygen sensor
7. steady state (cruise)

If you are using an alpha-N control, all you need for primary control is throttle position and engine speed.

If you are using speed density then you need engine speed, (MAP and inlet air temp) or MAF.

Head temp/engine temp is used for startup enrichment. I don't think that it affects combustion too much once the engine is in operating temperature range.

Exhaust gas temp and/or O2 sensors are for on the fly correction.

What's missing from here is volumetric efficiency. Here is where the table comes in, as I don't think VE can be easily characterized as a function. It follows the torque curve (I think), and could be approximated by a cubic or higher order spline fit. But you would have to get experimental data, and then every time you twaek something, it's back to the dyno and another spline fit.

What am I missing here for inputs?

[davygrvy]

I think you may have your inputs mixed up for the control scheme you want.

1. engine speed
2. throttle position
3. MAP or MAF
4. head temp
5. exhaust gas temp
6. oxygen sensor
7. steady state (cruise)

If you are using an alpha-N control, all you need for primary control is throttle position and engine speed.

If you are using speed density then you need engine speed, (MAP and inlet air temp) or MAF.

Head temp/engine temp is used for startup enrichment. I don't think that it affects combustion too much once the engine is in operating temperature range.

Exhaust gas temp and/or O2 sensors are for on the fly correction.

Yes, now you see where I'm going.. rather than use O2 and head temp as extra tweaks after the fact of a lookup, I'm going to try to model the whole thing in 7-dimentional learned fuzzification. There's a number of papers written about it and I'm still reading

What's missing from here is volumetric efficiency. Here is where the table comes in, as I don't think VE can be easily characterized as a function. It follows the torque curve (I think), and could be approximated by a cubic or higher order spline fit. But you would have to get experimental data, and then every time you twaek something, it's back to the dyno and another spline fit.

What am I missing here for inputs?

Lots missing esspecially regarding constants... still reading..

[raygreenwood]

No....head temp is NOT just used for start up. Where did you get that idea? Just wondering. It may be relegated to a start up feature in some systems....but not in most. You may be making the assumption that CHT is not "useful" for anything other than start up....simply because of its too slow rate of change for active second to second control of pulse width. Assuming that...would be a huge mistake. CHT....is an accurate relative reflection of what heat "zone" the entire engine is in. Yes...it runs you rich at start up on most factory systems.......but very quickly drops your entire baseline fuel mixture down into a leaner range. It is not designed as a high speed mixture change input. It is background, baseline fuel mixture data...same as ambient air temp. It gives baseline counter weighting to the whole equation...and is vitally important. It is he one sensor that can lean or enrich...in orders of magnitude.
Study the systems that exist...and see what and why they use the CHT and ambient temp sensor for. It makes the rest of the system NOT have to do so much work to get you into much leaner...or much richer ranges. Therefore....it makes the system not so peaky and over sensitive to minor changes.
This is one of the greatest flaws I see in aftermarket systems. They ignore slow moving sensors like ambient and CHT...and try to have the fuel mixture constantly changing to match engine conditions...by sheer computing power alone. It seems more accurate on paper.....but is not. There are to many variables caused by heat of the combustion chamber alone....to make a decision without knowing the baseline heat range.

Just using MAP and throttle position tells you only a fraction of what you need to know. If you were only using those inputs.....how will they know that enrichment is needed for a combustion chamber whose efficency level and gas speed is now higher due to radiant heat?

Also....the CHT would be more beneficial if it could be more "realtime"....but for the most part...once heatsoak and saturation is accomplished....it only needs to know the basic range...give or take a little. Ray

[R2.0]

I think we may be talking about the CHT sensor doing the same thing, but I didn't express myself very well. My understanding of the role of engine temp sensors is that the proportionately richen the mixture proportionate to the degrees below operating temp. Using teh word "starting" wasn't quire accurrate