algorithm development

Free Open Source Firmware project discussion forum. Post your Free Open Source firmware projects here!
Post Reply
spyghost
TO220 - Visibile
Posts: 10
Joined: Wed Jul 28, 2010 6:18 am

algorithm development

Post by spyghost »

hi there,

sorry if i made this thread in the wrong section, the admin/mod may relocate when necessary :?

anyway, here's what i got...

i have a 16v dohc engine that i would like to work on my own ecu - mitsubishi 4g15 dohc 16v mpi (multiport injection)

it is distributor based but does not have a crank angle sensor.

here is a shot of what's inside my dizzy
Image

as you can see, there are 4 vanes inside that represent the 4 cylinders of the engine. at this position, cylinder 1 is at tdc on the compression stroke. if you'll look closely, the vane "just passed" the center of the sensor.

another thing worth mentioning about my dizzy are its signals.
- the idea here is that the ecu gives a pulse to the dizzy to tell it to send a spark. this spark is sent to the cap to where the rotor points. without the corresponding ecu signal, no spark is produced.
- the dizzy gives the ecu the "camshaft" position based on the vanes.
- the dizzy gives the ecu the engine rpm as well.
- the rest of the inputs are just supply to the power transistor, primary coil, and camshaft position sensor.
Image

given this hardware, it seems that injection is primary controlled by these 4 vanes. as for the spark, its ecu controlled, but distributor based.

with this regard, i'd like to skip first the involvement of the other sensors such as tps, o2 sensor, manifold pressure, etc... i believe these other sensors are just for compensation of how long the pulse on the injector should be. i'd like to focus first on achieving the basic alo for these:
- multiport injection
--- cold start (batch injection)
--- idling (sequential injection)
--- high rpm's or heavy load (combination of sequential injection and/or batch firing)
- spark advance

any help would be highly appreciated here.

from the algorithm, i'll be able to choose the platform that i will be intending to use. and after that, i'd be definitely adding up the inputs of the other sensors for compensation.
User avatar
EssEss
LQFP112 - Up with the play
Posts: 244
Joined: Thu Sep 10, 2009 9:23 am
Location: Dayton, OH

Re: algorithm development

Post by EssEss »

Anything should work for your algorithms .. your time would be better spent on picking something to handle all your planned i/o. It may be that I'm not understanding what your specific algorithmic goal is here. I think you're wondering about how you would 'schedule' fuel and/or spark under those conditions without concentrating on the specific of mass/transient calcs ?

So instead of giving you the answer, I'll just leave a few hints to get you started:

1) what is going to be your reference input for these algorithms ?
2) Your cps is optical, not analog.
3) are you sure you understand how to decode and condition the primary reference input ?

I'd rather teach you to fish than do the fishing for you. If you don't want to play that game, please let me know.
spyghost
TO220 - Visibile
Posts: 10
Joined: Wed Jul 28, 2010 6:18 am

Re: algorithm development

Post by spyghost »

EssEss wrote:It may be that I'm not understanding what your specific algorithmic goal is here. I think you're wondering about how you would 'schedule' fuel and/or spark under those conditions without concentrating on the specific of mass/transient calcs ?
it could be that i just asked the wrong way though... :roll: and i think you rephrased my inquiry correctly :lol: and yes, my current path as of this moment is how the "phasing" or scheduling of spark and sequential injection would take place - that is given just the distributor sensor or cam sensor that i have. no transient calculations inolved yet.
EssEss wrote: 1) what is going to be your reference input for these algorithms ?
2) Your cps is optical, not analog.
3) are you sure you understand how to decode and condition the primary reference input ?

I'd rather teach you to fish than do the fishing for you. If you don't want to play that game, please let me know.
1 - reference input would primarily be the camshaft position sensor - the 4 vanes representing each cylinder (no transients as of now).
2 - that i can't tell yet if its optical or hall. but fromthe looks of it, i think its hall because of the presence of metallic squares inside that don't look like an optical receiver/sender.
3 - given that it is hall, just cmiiw, its a square wave output.

i haven't had much experience with hall's yet, but from my readings (generally speaking), the "beginning" of the vane passing through the sensor signifies a rising edge, while the end of the vane that "just passed" the sensor indicases a falling edge.

what i don't have yet is the angle of each vane. from the looks of it, it seems that all 4 have the same angles, nevertheless, i need to measure still.

it seems that a degree wheel on the crank end would help me determine how much degrees btdc on compression each piston would be with respect to the "vanes" on the distributor.

as for the spark advance (which is directly proportional to the engine rpm @ operating temp), i could use a sort of "embeded spreadsheet" with an input of engine rpm. what's expected of the spreadsheet is a "countdown before spark value" with respect to the rising edge of the vane. as rpm increases, this countdown value decreases thereby simulating an advancing spark.

as for the sequential injection, i think i might use this theory...
in a firing order of 1 3 4 2,
- cylinder 1 compression going to power = cylinder 4 exhaust going to intake
- cylinder 3 compression going to power = cylinder 2 exhaust going to intake
- cylinder 4 compression going to power = cylinder 1 exhaust going to intake
- cylinder 2 compression going to power = cylinder 3 exhaust going to intake

given these, "i could" inject a cylinder, when its partner is "btdc." e.g. 1 is btdc to compression, before the intake valve of 4 opens, i should have injected fuel already on that.

comments on these? :? :oops:

i'd like to think things out first, but if i really can't phatom it, i'll ask anyway. :oops:
User avatar
EssEss
LQFP112 - Up with the play
Posts: 244
Joined: Thu Sep 10, 2009 9:23 am
Location: Dayton, OH

Re: algorithm development

Post by EssEss »

you're all over it 8-) ... just need to continue sorting your thoughts.

if you're interested, there is 4g63 ecu source code out there .. it's all in assembly. maybe there is some 'logic gold' in there which is very relevant to your motor.
Post Reply