arduino based fully DIY fuel injection ECU.

Using Arduino Project Guidance
1

hello forum. i am making this topic, because, it is a project, i am planing on beginning soon, and i know many on this forum have also done simmilar things to this..
i am planing to build a module, from scratch, to control the fuel injectors,and other functions (iddle, smart boosts, etc..)
on my car. the module itself, will be based, on 1-2 atmega328 chips, and maybe 1-2 attiny.
the whole concept is to make a module that will:

know the exact cam position, so it can start pulsing the injectors on the correct time. calculate the rpm, and by that, control the iddle valve.

read MAF or map sensor (havent figured out) in order to establish an engine load.

then, using a wideband sensor, and with a tuning session, you can have the "perfect" amount of fuel, needed for each MAF/MAP on a MAF-injection time table...

if this is done, you can also add other functionality, like , accurate (not like the crapy oem) , fuel consumption
extra boost or economy, based on user demand.
some sort of diagnostics,
and even ignition, if all goes well..

the thing is, even though this kind of work has been done before, there has been little documantation about it... so, if anyone have any knowledge on the matter, it would be good, to add our expiriances here :slight_smile:

2

Have look here,

http://cajinnovations.com/

The guy makes and sells DIY fuel injection ECUs for Ducatis and Moto Guzzis.

There is loads of info and a good forum that will help you.

3

Have you looked at the Megasquirt open source project? Making a good EFI system involves a lot of complexity and a lot of data - an Arduino doesn't give you many resources to deal with any of that. You would also need to design your own I/O circuits - if you adopted the Megasquirt design, all this would be done for you. You also need to consider how much work is required to configure the ECU. There is a lot of software available to configure Megasquirt, provide logging support and do real time and post run analysis to tweak the maps.

4

yes i have look at it, but if i wanted to buy a ready ECU, i would by an OEM one. also, the project is to create an arduino Based ECU.
not convert your car to injection (otherwise this post would be on a car forum...)

so far my plan is this
first, each camshaft rotation, takes about 20ms to complete. each arduino analog read takes 0.1ms, so even with reading many analog sensors, i dont think it will have a problem. it's code stability that bothers me most..

first, you must use an analog multiplexer, or external ADC, because the analog inputs will be way more than 6... (or you can use another arduino board)

Engine speed- position : Cam position sensor :
Use a metal disk, mounted on the camshaft of the engine, with 36 holes (1 actually missing). a led behing the wheel, and a sensor on the front. every time a whole passes in front of the led, it will send a pulse to arduino. that way, by counting holes , you can know at precicce what degrees your engine cycle is. also, by looking for the missing hole, you can know, when the engine cycle starts again.on the Arduino part, you will have an attach interupt, which counts holes, and the time it took between signals, to mesure RPM.

fuel consumption - car speed :
a hall effect sensor on the rear wheel, with a magnet on the actuall wheel, will produce a signal, related to car speed. the think is, i dont want to have that signal, proceced by the main arduino, becouse, it will make the code more complicated. i plan to use an attminy that will:
Measure the car speed from that signal
also whenever the first injector is pulsed, there will be a pulse at the attminy as well, so it know how much fuel (x4) is injected.
so , every 1 second, it can calculate fuel consumption. then, it will outpout two PWM. one will be the car speed, (so the main arduino can read it as analogread() ) , and the other will be the fuel consumption gauge.

Engine Load : i still need some light shed on this matter, as i dont yet understand completly how it is determined by the MAF or MAP sensors... (any help??) ...

Wideband Lambda: there are many open source projects... willl post when i determine which one is the easier to implement

5

settra:
yes i have look at it, but if i wanted to buy a ready ECU, i would by an OEM one. also, the project is to create an arduino Based ECU.
not convert your car to injection (otherwise this post would be on a car forum...)

It's apparent from your questions that you aren't familiar with how the conventional EFI sensors work, or the algorithms needed to run an engine well. There's absolutely nothing wrong with simply getting on with your project if you want to do it for the fun of it, but you ought to be aware that doing it well is going to involve a lot more complexity than you are outlining here and the Arduino is not really a suitable platform for that. If you are fired up about making your own EFI system, the Megasquirt approach would still give you a highly flexible DIY solution but give you a decent chance of working well, rather than sort-of working. As relatively minor points compared to the other problems you're facing, it is not sensible to use an analog input to read the cam position sensor, and the pwm/analog read communication mechanism you are proposing does not make any sense at all.

6

what are u talking about dude? i know , i dont know everything, but are you sure , you know what a car is?

If you are fired up about making your own EFI system, the Megasquirt approach would still give you a highly flexible DIY solution but give you a decent chance of working well, rather than sort-of working.

first of all, i never sed i want to make an EFI system. YOU sed it, and i arledy replied to you, i want to make an engine management system to control the EFI. if i go and buy the dollarsquirt, then what exactly is the DIY?

, it is not sensible to use an analog input to read the cam position sensor

  1. where did i sed, i will read analog cam sensor?? the optical sensor, is digital, and uses attach interupt. its they same exact thing with the VR sensor, only it has a more clean signal, and is way easier to implement. in fact, even with megasquirt, its very comon to use cam triggers like that, and megasquirt supports them, but obviously you dont know what you are tallking about.

the pwm/analog read communication mechanism you are proposing does not make any sense at all.

  1. what part about it you dont understand? it is as simple as it gets. maybe you want me to expnain how you can use attach interupt to count RPM of a wheel??
    if you know the speed of the wheel, in etc 10ms, you know the distance it traveled. by the injector inpout, you know how much fuel has been injected, so you can calculate fuel consumption. why is it even hard?

i know it will be hard, or it will get complicated. But the project is as it is. if you dont like it , then you can simple not contribute... there is no need for advertisement.

1 Like
7

settra:
2) what part about it you dont understand? it is as simple as it gets. . maybe you want me to expnain how you can use attach interupt to count RPM of a wheel??

You originally wrote:

it will outpout two PWM. one will be the car speed, (so the main arduino can read it as analogread() )

That won't work unless you make up a digital-to-analog converter, but even if you did that it would still be a silly way to transfer data between two digital microcontrollers.

settra:
i know it will be hard, or it will get complicated. But the project is as it is. if you dont like it , then you can simple not contribute... there is no need for advertisement.

Let's be clear about this. I don't care whether you do the project or not; it makes absolutely no difference to me. I'm bringing up these issues to advise you about problems that you don't seem to have taken into account, probably because you don't understand them. Nothing I've written makes it any harder for you to go ahead with your project, but if you read and understand my comments there is a chance that they will save you from a lot of wasted effort. At a minimum, I suggest that before you spend any significant time on your DIY solution you look at the tuning software for Megasquirt to get a feeling for how complex the behaviour of the ECU is. This isn't complexity for the sake of it, it's complexity that is required to run the engine well. Megasquirt is a relatively crude and simple ECU, and many aftermarket ECUs are much more complicated and sophisticated. In terms of hardware costs, you would need to replicate a lot of the Megasquirt I/O circuits in your DIY solution and I doubt you will do that any better or cheaper than the Megasquirt design does, so if you're thinking of this as a cheaper route then you'd be looking at savings of tens of quid on a project that is going to cost you hundreds. I've done this four times now with different setups and I think the hardware cost typically works out in the region of £1000 by the time you include all the myriad bits of wiring and sensors and connectors and accessories and so on that inevitably need to be replaced - that excludes the main fuel/ignition hardware and engine sensors, which you would obviously aim to reuse.

If you think this will be a fun project that you want to do as a learning exercise or for the challenge of it, that's all the reason you ever need. If you're doing it because you think it's a sensible approach and will give you a good cost-effective solution, with respect I disagree.

8

settra:
if i go and buy the dollarsquirt, then what exactly is the DIY?

No offense intended, but that comment sounds like someone who doesn't have the first clue about what it takes to set up an ECU. I'm pretty sure if you got yourself a Megasquirt, you'd find there is P-L-E-N-T-Y of DIY in store for you. It is HARDLY turn-key.

If you attempted and succeeded in getting a Megasquirt (or any other non-OEM ECU) to run, then rolling your own might be a reasonable goal. But it takes someone with strong skills in engine mechanics, electronics, programming, and all the maths involved -- which is a pretty heavy combo. Right now, I agree with PeterH -- to a casual observer, it sounds like you're in WAY over your head. Many of us around here point these things out to people whose ideas don't seem to be aligned with reality. Not because we're jerks that like to rain on your parade, but because projects that far beyond someone's skill set never succeed, and often result in so much frustration and wasted money that the poor sap is soured on the entire hobby. Which is a shame.

So, if you're bent on doing this, well... best of luck. I would suggest you try for a few intermediate projects first though.

9

SirNickity:
Many of us around here point these things out to people whose ideas don't seem to be aligned with reality. Not because we're jerks that like to rain on your parade

and i find you guys pathetic! you dont have anything better to do, than to go aroudn pointing your opionion? no one asked you for your opinion.. the fact that this project would be way out of your league, or that you have hard time understanding the base lines, is your problem. but that dosent give you the right to come and say crap like " no you should buy megasquirt" or "its hard, don try".
when you say things like that, you just make yourself look rediculos.

and for the last time. this is not a car forum. stop propusing DIY tuning. that is what megasquirt has to offer (and allot of it) . DIY tuning. i dont want diy tuning. i want diy electronics how hard can it be to understand the difference?

10

settra:
no one asked you for your opinion

Actually, you did. You came to the Project Guidance forum and asked:

the thing is, even though this kind of work has been done before, there has been little documantation about it... so, if anyone have any knowledge on the matter, it would be good, to add our expiriances here

Since I do have some knowledge of the subject, and can answer based on the experience of having been there and done that, I can tell you that the project you're taking on is far more complex than you seem to appreciate and that if you do decide to go ahead with it the Arduino microcontrollers do not have sufficient resources to do the job properly. It ought to be possible to get something working well enough to get a specific engine running under specific conditions, assuming you can handle all the electrical, electronic and firmware design issues and then configure it correctly, but there's a massive step from that to an engine management system that runs the engine well enough to be driveable in the real world. Throwing your toys out of the pram because you don't like what you're being told is silly. If you don't want to hear people's opinions, you shouldn't have asked the question. Again: nothing being said here stops you from doing what you want or makes it any harder for you to do the project - all I'm doing is trying to save you frustration.

11

your fist post that dosent have the word "megasquirt" on it.

based on what you sed before, i doubt you have any experiance with the actuall build of the ecu electronics. Configuring an efi, with megasquirt, has nothing to do , with actually BUILDING a megasquirt.

and no, building a managment system, for the actauall word, is not so complicated OR hard either. you need to stop repeating non-sence.
if you want to have an OBD2 diagnostic system which will tell you what your engine had for breakfast AND have a system that is plug and play (or requires some configuration like megasquirt) for any car, then yes, it might get complicated.
But if you want to make a system, that works on your car's specifics, and it will make it run, just better than before (considering that no one with a new car will do experiaments on it.only in older cars) then it is reather easy.
hell. the only hard part is to make the widband o2 controller.

and i got mad with your response, becouse, if people like you did not exist, to scare other people away from REAL diy (not like the diy you BUY with megasquirt), then there would be way more projects to show for.
plus, the only people who have actuall benefit from what you say, are the ones who make money selling Megasquirt.

12

settra:
it is reather easy.

I can't say I share your optimism, but clearly you aren't going to let that stop you. I hope you'll let us know how you get on.

13

we have %^&^ up the post now, but yes, i will do :wink:

14

based on what you sed before, i doubt you have any experiance with the actuall build of the ecu electronics. Configuring an efi, with megasquirt, has nothing to do , with actually BUILDING a megasquirt.

I'm not sure i understand what it is you are saying here, the " DIY EFI system that shall NOT be named " (as it appears to irritate you) can be built and configured for a mostly diy experience. You can get ( or even build your own ) PCB, order the parts , and build the hardware, and even buy a blank chip to program. So the only part of this experience that would not be truly "diy" would be the code loaded onto the micro controller and the GUI used for interfacing with it.
So, to that end, if it is the code you are interested in developing, and if i understand you correctly, you want this code to be specific to your car, then I whole heartedly support your effort and i hope you are able to get it working, as i too would love to see an arduino based efi system developed.

As for the atmega 328 not having the resources required, i'm not sure i agree. the motorolla micro used on the origional (and still available i think ) " DIY EFI system that shall NOT be named " ( the MC68HC908GP32 ) has been around for a while, and i don't think it would be considered a powerhouse chip, lets compare a few specs:

Micro controller Speed Program Memory EEProm RAM I/O A/D
MC68HC908GP32 8MHz 32K (32x8) none 512x8 33 8 (8bit)
ATMega 328 (32TQFP) 20MHz 32K (16Kx16) 1K x 8 2K x8 23 8 (10 bit)

So, looking at nothing else but the banner specs, it would appear that the only thing the MC68 has to offer over the ATmega is total number of I/O, however one only had to look at the ATMega1280 to get all the I/O pins you would need for a basic fuel injection system, though i think it could be done even with a 328. The original " DIY EFI system that shall NOT be named " did not use all of the available I/O pins anyway.

I like your idea of multiple arduino boards too, there are many things related to controlling an engine that are not particularly time sensitive and would probably be easier to control with separate boards, rather than trying to write code that does everything all on one chip.

i personally have nothing against the " DIY EFI system that shall NOT be named ", I was one of the first guys to build one way, way back in the day when it was much more diy, and it only controlled fuel and had a very crude fast idle. These days you can buy a kit, and dont have to spend an hour or two putting together a digikey order, or just buy on assembled.

If i were to start trying to build an arduino based efi controller, i dont think i would use the 328, i would start with something like the DUE or perhaps a teensy 3.1, start with way more overhead than needed.

15

f i go and buy the dollarsquirt, then what exactly is the DIY?

You get to build up the PCB, even order most of the components to populate the PCB if you want, decide what version of the system you want, put it in a box, wire it into your existing EFI system, then start the glorious process of setting it up for your engine and then tuning it. That's a fair amount of DIY, trust me, i have done it a few times.
You could also design and build your own PCB if you simply had to, even modify the schematics if your adventurous.

read MAF or map sensor (havent figured out) in order to establish an engine load.
** then, using a wideband sensor, and with a tuning session, you can have the "perfect" amount of fuel, needed for each MAF/MAP on a MAF-injection time table...**

I think this question, and subsequent statement, have a lot to do with why other members are thinking that you may not understand the complexity of the task you are undertaking. Simply put, and with all due respect, it appears that you do not know what you do not know, so to speak.
but, to move the ball forward....

MAF stands for Mass Air Flow. It is generically used to describe a sensor that measures the mass of air being pulled into the engine.
Most modern MAF sensors employ a "heated wire" technique, a current is passed through a wire (usually platinum) to heat it to a specific temperature, the current required to maintain that temp increases as the airflow through it cools the wire. that current is usually converted into a 0-5 volt signal. If you know the Mass vs Vout then calculating fuel injector pulse width is fairly straight for ward, assuming you know the flow rate of the injector.

MAP stands for Manifold Absolute Pressure, and is generally a 3 wire sensor that measures the pressure inside the intake manifold, ideally relative to the atmospheric pressure. Using this type of sensor is called speed density, because it requires the ECU to calculate the Mass of the air going into the engine based on the engines speed (rpm) and the density of the air it is injecting (manifold pressure). All engines are not the same, but MAP sensor signals from a 600cc 4 cyl and a 8000cc V12 could be identical.
So the ECU needs to know how big the injectors are (flow rate), how big the engine is, Volumetric efficiency at different rpms as well ad desired air fuel ratio among other things. Generally though, there is an x-y look up table, RPM vs MAP, that the ecu uses to calculate required duty cycle.

As for a WBO2 being used to determine the "perfect" amount of fuel, this is possible, in theory but generally not in practice.
The O2 sensor is reactionary, its signal only indicates whether or not previous fuel calculations were high or low. The ECU can use this to adjust upcoming fuel calculations, but it is a moving target, so to get an exact error compensation is a rather tall order. Yes, it can be done but would require a lot of computing power as well as knowing little things like, for instance, how long it takes the exhaust gas from each cylinder to reach the O2 sensor at different RPMs, the response time of the O2 sensor etc. It is much easier to simply make small adjustments over time. The constants, the numbers programmed into the ECU, are used to try and get as close as possible to the "perfect" fuel delivery, the O2 sensor is used for fine tuning those numbers.

Here is what i would consider a minimalistic blue print for an ECU main processor:

Crank sensor input (RPM) 1 digital I/O // preferably on a hardware interrupt pin
Camshaft sensor input 1 digital I/O // same as above, however either one of these could be used alone, or both paired
Fuel injector(s) 1 to 2 digital I/O // 2 should be considered minimum, but up to 16 would be ideal
ignition coil(s) 1 to 2 digital I/O // again, 2 would be a good minimum, however 4-8 would be ideal
Fuel pump 1 digital I/O
Idle control 2 digital I/O // 1 minimum (PWM motor) but 2 recommended ( stepper motor )
Cooling fan 1 digital I/O // completely optional but recomended
coolant temperature 1 analog
air temp 1 analog
throttle position 1 analog
MAF/MAP 1 analog // some sensors are digital though, but not many
system voltage 1 analog // for measuring voltage available to injectors and coils, NOT optional
O2 1 analog
BARO 1 analog // measuring barometric pressure, optional

So by my reckoning, for a bare bones system, a uno could do it, but a pro mini might be a better choice as it would allow a baro sensor and one extra analog. if you had to you could multiplex the coolant, air temp and baro, but i wouldn't want to do that on any of the others.

However, I think it would be much smarter to start with a MEGA board, or better yet a DUE or even a Tensy3.1.
The Mega has pins to spare, but the DUE and teensy3.x offer more pins and more speed and computing power, the extra speed might well compensate for less than ideal coding.

I highly recommend ( as much as it will hurt ) that you find the online manual for the " DIY EFI system that shall NOT be named "
and study it, its very comprehensive, free, and to my knowledge the best resource for learning and understanding what is required to control an engine with an embedded computer.

1 Like
16

joey120373, thanks for the extensive reply :wink:

even though i understand it might not seem to, i DO know what i am speaking off... and i DO have studied the "DIY efi system that shall not be named " .. although i agree i didint knew about the pcb part :smiley:

FUEL DELIVERY:
everything u sed about MAP and MAF, I Have in mind. that is why i would prefer to use MAF sensor. it has less valuables to account for, and is supposed to be more accurate in low power cars.
if you had MAF in g/s then (MAF/4)/(CAMrpm/60) = air grams/rev*cylinder, so you would know exactly how much fuel was needed on each cylinder, based on your desired AFR.

THE problem is, that they have extremely low documentation, so even though it sounds easy , "converting volt to air mass" is rather hard... you would have to start with a bit random transfer function, and then using the lambda sensor, try to tune it all the way to "correct". i think that finding a MAF with given curve, or finding a method to build the Curve, is one of the hard parts...

also, for open loop i would need the engine load
engine load = Massin/Massmax
where Massin= MAF*60 / caMRPM.
Massmax = engine displacment g/cc or something.

IDDLE :
if one uno can control the IDDLE or not, depends on the the type of the valve u Have. some require 1 PWM, some require 4inputs (not pwm at all, but rather stepper motor's or something). if the main atmega cant do that, then an ATTiny, could as well help.
MUX:
yes i will be using a multiplexer. you think i shoudlen't? why? :slight_smile: the atmega does not have enough inputs on its own to do the job. and i "Cant" use another chip, cause its hard to find where i leave ++ i anyway prefer the many boards method, since its way more easier to maintain.. (or it just seems easier to me )

WBO2.
the wideband O2 sensor, seems to be the hardest part. i find it hardest than the ECU itselft... buying a controller is like 100euro , which is way more than what the rest of the electronics will cost.... i wanted to build one, but it seems reather hard, and i dont want to over complicate the project, so i will start with a 4 wire sensor, that is just capable to point when you are near stoich...

in the meantime, i dont think i need to use Crank position, OR map sensor..
my search has returned, that cars use both crank and cam, basically for diagnostic reasons, and that any given time, only one gives the required input (same for map? )

17

I your goal is to be able to tune your car correct?

or do you want to build a fully functioning system to replace the existing one?

As i stated before, i think a uno would have enough I/O pins to do the job, though just enough. I would avoid muxing the analog inputs because some of them, like TPS , MAP/MAF, EGO are time sensitive.

If your car uses both a crank and a cam sensor, it is not simply "for diagnostics" I am not sure where you are getting your info, but generally the crankshaft position sensor is used for the timing input of the crankshaft, and is the main reference input to the ECM. the camshaft sensor is used to tell the ecu whether the cylinder is on a compression stroke or exhaust stroke.

in any case, if your goal is simply to be able to tune your car, you might consider an alternate method. using an arduino to alter the main load signal, and possibly the timing reference as well. this would give you the ability to tune fairly easy compared to building a complete system, and would be far easier to implement.

18

joey120373:
I your goal is to be able to tune your car correct?

or do you want to build a fully functioning system to replace the existing one?

my car only has ignition module. so , i want a fully functioning, as far as injection goes.

joey120373:
As i stated before, i think a uno would have enough I/O pins to do the job, though just enough. I would avoid muxing the analog inputs because some of them, like TPS , MAP/MAF, EGO are time sensitive.

yes but MUX brake and make, is way too short. around ns i think, where analogread() is anyway near 0.1ms.... the time of each cam rotation in 8000rpm is anyway 15ms, so you have plenty of time to read them exactly when needed??

joey120373:
If your car uses both a crank and a cam sensor, it is not simply "for diagnostics" I am not sure where you are getting your info, but generally the crankshaft position sensor is used for the timing input of the crankshaft, and is the main reference input to the ECM. the camshaft sensor is used to tell the ecu whether the cylinder is on a compression stroke or exhaust stroke.

there is a difference between "they generally use" , and "this is needed in order to work good".
my info comes from many resources, and my research has shown, that most of the resources one can find, just reproduce what they hear, without really knowing why....

cam and crank, are connected to 1/2 ratio. ASSUMING your car is running okey, then there is absolutly no need for crank position.Since the crank position sensor alone, cannot provide you with the start of the cycle, then its uslesses without cam position sensor. The cam sensor on the other hand, is more than enough to run injection on its own...

if you have cam position sensor, and you know any given point (etc, at TDC of cylinder 1 , there is a teeth missing) , then by counting teeth, you can know exactly where are you are , at any point of the cycle, without any need for the crank position.
so, all is left for crank sensor is diagnostics, and the "Return me home" mode. (if cam sensor brakes ).

(btw, i had seen somewhere that crank signal is used for Ignition, since ignition is way more time depended, and has to have more accuracy. the source suggested that cam, can not be so accurate. i find this hard to trust)

i spended many hours, trying to figure out all this rumors about the "importance" of the crank signal, so if you believe i am missing some major point, please go ahead and tell me :slight_smile: after all, this procedure is supposed to help someone learn :wink:

19

if you have cam position sensor, and you know any given point (etc, at TDC of cylinder 1 , there is a teeth missing) , then by counting teeth, you can know exactly where are you are , at any point of the cycle, without any need for the crank position.
so, all is left for crank sensor is diagnostics, and the "Return me home" mode. (if cam sensor brakes ).

I wish i knew what kind of car you were working on, as it seems to be quite different from any that i have ever worked on.

what you say is true, a cam sensor will indicate what stroke the engine is on, but at what resolution? how many "teeth" or timing references does your cam sensor have?

As far as i know, and i have spent the vast majority of my professional carrier working on cars, engines that have both a crank, and a cam sensor, the camshaft sensor usually has 1 pulse per 720 degrees of engine rotation, not exactly enough info for the ECM to make accurate timing calculations. Some are different though so who knows?

Loads of engines use a crank sensor only, because in the big scheme of things, it does not matter if the ECM knows what stroke the cylinder is actually on. Waisted spark ignition and batch fire fuel injection have been around for years and work just fine, and the ECM controlling these never has a clue what stroke a particular cylinder is on, this is not a "limp home mode", but rather a perfectly viable way to controll an engine.

I am telling you this, because you seem to be assuming that because your car has a cam sensor it will provide your would be arduino engine controller with all the info it needs, and i am guessing that it will not. if you insist on using only one of them, i think you would be better off with the crank, as i would be willing to bet that it has more "teeth" or pulses per revolution.

You said my car only has ignition module. so , i want a fully functioning, as far as injection goes.
So it it a carberated car? i was under the impression that it had a fuel injection system as well.....
to say your car has an ignition module is like saying that it has 4 wheels, most all cars have ignition modules, like most all cars have 4 wheels, i'm not sure how this fact relates to your plans for an engine controller, outside of how to interface with it, witch is generally a simple digital signal.

The ignition module on most cars has one main function, to fire the ignition coil(s), this keeps all the high voltage noise seperated from the ECU, in some instances, the ignition module also serves as a crank and or camshaft sensor interface and can provide a base timing referance and spark during cranking.

I am not trying to be rude, but the more you post on the subject, the more apparent it is that you may not fully understand how ECMs and fuel injection systems work. I realize that there is also a language issue here, and i may not understand what it is you are actually saying. So to remedy this, lets start with some basics, what kind of car is it? how many cylinders? Crank sensor, what kind ( VR, or hall effect) and how many teeth? how many missing teeth? same for the cam sensor, what kind and how many teeth?

First thing to do is to get the arduino to figure out what rpm the engine is turning and how to calculate the timing of events based on these signals.

20

what you say is true, a cam sensor will indicate what stroke the engine is on, but at what resolution? how many "teeth" or timing references does your cam sensor have?

and the low resolution does not apply to Crank sensor becouse??...
all distributor based injection systems, take their signal from the distributor, which is 1/1 ratio WITH THE CAM. not the crank. if you want to run bached injection, then crank signal might be usefull. and if u want to just random squirt fuel, crank is usefull. But in sequental, its nothing but useless.
I am not going to repeat my self over and over, over cam and crank. if you really think that arguing about that, is "contribution" , then provide some links that say "crank is usefull on sequental injection and THIS is why" ...

now, to the resolution part. if you look at my 2nd post, you will see that i describe the cam sensor i will be using....
its an optical sensor, with 35 holes, something like this : http://triggerdisc.com/images/DSM_24tooth.jpg, mounted on the camshaft pulley. (see post for details)

meaning, a resolution of 10 degrees. far more than what injection needs...
i was thinking of using attach interupt to count how many holes have passed, so 20 holes, means 200deg.
if you know that the start of the cycle, then you can know that tdc1 happens at 20deg, tdc2 at 70 , ..tdc4 at 250
(completly random)...

now, if you are indeed willing to contribute, here is the deal :
worst case senario : 8000rpm of crank, = 4000rpm of cam. <=>
1rev = 15ms. if you have 35 interupts, in 15ms, this means that you have an interupt every 0.4ms...
so : considering that every analogread() takes 0.1ms, do you think that there is going to be a significant timming issue if i use 35 holes??

(i could ofcourse make a wheel, that dosent have 35 holes, but less, secrefacing resolution, for program timing,) what do you think???