arduino based fully DIY fuel injection ECU.

Projects General Guidance
21

settra:
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.

Unfortunately MAF sensors don't really give you that. They return a signal which has some relationship with the mass air flow, but the relationship varies depending on the conditions - just as it does with MAP or throttle angle load sensing. The advantage of MAF is that the correlation (between the actual mass air flow, and the sensor value) tends to be greater which makes the mapping easier to get right and less vulnerable to small variations in the engine characteristics, but whatever sensor you use for load you still need to map that load signal to estimate the actual amount of air being drawn in.

By the way, in terms of understanding what problems you face, I think your greatest problem is going to be the complexity of the fueling algorithm needed to run an engine well (and the amount of configuration data needed by that algorithm, and the amount of effort needed to work out what the configuration values need to be based on trial and error). If you don't have a sufficiently sophisticated algorithm then every time you try to sort out inaccurate fueling under some conditions, you'll end up making it worse under different conditions. An engine's fuel injection requirements varies according to lots of factors. Making it harder to follow, many of the effects you're trying to deal with are transient and behave differently under different operating conditions which requires an even more complex control algorithm.

Re the crank/cam angle position sensing accuracy the hardest case to deal with is probably going to be cranking/starting, because this is where you will depend most on extrapolation and estimation of the crank position/speed. I think you could use either a crank or cam sensor as long as it gives you enough resolution, obviously if your fueling algorithm needs to know the engine phase then some form of cam sensing is essential. If you're only going to manage fueling then you can get away with quite poor resolution (one pulse per ignition event is perfectly adequate) but the better resolution you have the easier it is to get right. If you were going to manage the spark as well then you need much better resolution since the spark is obviously timing-critical whereas the fuel delivery is not very timing-critical.

22

Settra, sorry, i missed the post where you described your cam trigger wheel, to that end, yes that type of wheel i think would be just fine.

now, if i can manage to continue without further ruffling your feathers....... :~

As for the .4ms interrupt timing clashing with a .1ms analog read, that does sound to me like it could cause an issue, mainly because i think you will want to read many more than just 1 analog signal.

I am just starting to learn about ATMega interrupt routines, would it be possible to simply use the majority of these pulses (interupts) to flag clock counts? and will doing this interfere with things like analog read and digital write (or better yet direct port control)?

If these interrupts will cause issues then i think maybe it would be better to use fewer of them, for instance 1 per cyl?

I am toying with the idea of trying to build a "mock up" engine, a motor with a trigger wheel, to test different code schemes.
if only i had more time.....

23

peterH. yes, i tottaly agree with you. and since the all of the sensors have almost zero documantation, it would need loads of tuning, to get the MAF transfer function correct, injector dead times, and so on... but that, you have to do, with any "system" you chose, so...

as for the trigger: the reason i would prefer 35-1 wheel, is becouse that way, you do not have to make any estimates about the position.
In sequintel , you have to have injected all the required fuel, before the intake valve opens., so you start 10degrees before that.
so, you would issue the pulse to take place, when the 15th (Etc) pulse was detected...

0.4 ms, is the worrst case scenario, ussually it will be more than 0.8, but, one solution that comes to mind
(considering analogread() will dominate the time consumption), is, you could read the sensors in turns. something like that :

void loop() {
 read MAF   // (will always be read , since its the value that changes faster) 
if  cycle = 1 read tps
if cycle = 2 read bat voltage
if cycle = 3 read coolant temp
.
.
.
look in table for desired AFR based on conditions.
determine  fuel, that is to be injected, if a pulse is issued now.


iddle cotnrol?

}

or something like this.... that way, every main loop, would cost about 0.2 - 0.3ms.... and most of the variables, change way slower (VSS, bat voltage, tps ) what do you think??

Enother think, is , i wouldent risk having any other interupts on the board... this means, that the VSS (a hall sensor on the rear wheel, that pulses once per revolution) has to be converted to analog.... i think it can be done straightforawrd with LM2907 ...

AS for the algorithm, i was thinking something like that :

  1. take the desired AFR ratio, based on the engine load/rpm table. something like this
    (http://www.sr20deracing.com/EVO/fuel_map.gif ) every spot would have to be tuned...

  2. read the MAF, and convert it based on transfer function to MAF= g/s.
    then , the grams of air, entering every cylinder per revolution would be :
    Airgrams = (MAF60)/(4RPM) rpm of the camshaft, and the "4" is, becouse i have 4 cylinders...

  3. based on the airgrams, and the desired AFR, determine fuel grams needed

  4. based on injector flow rate, determine the pulse width. then make corrections based on dead time and other thinks...

what do you guys think so far???

1 Like
24

Your calculations should be performed when you need them, not just calculating stuff at every iteration and using the answer when you decide to.

The process of calculating air mass flow from the MAF signal will require you to use a map because the conversion depends on speed and load. You also need to deal with transient enrichments, and compensate for injector voltage (which will affect the opening time) and fuel temp (if you're compensating for that) as well as applying coolant temp correction. I think your best bet would be to have the MAF sensor calibration map and the target AFR maps offline and crunch them together to generate the MAF-signal-to-fuel-demand map that is actually installed on the ECU.

The sequential injection algorithm you describe is not what worked for me, but in any case I don't think you want sequential injection. You will be lucky if the engine starts and runs, extraordinarily lucky if it is capable of achieving anything like the right AFR under real world driving conditions, and if you ever get to within the fractions of a percent of optimum where the tiny benefits of sequential injection might be worth while then you will have worked a small miracle. So start with the basics before you try the hard stuff.

Really, you ought to look at the Megasquirt user interface to get a feel for the complexity of the Megasquirt fuel control algorithm. Doing this well enough to be driveable requires massively more complexity than you are reflecting so far.

25

PeterH:
Your calculations should be performed when you need them, not just calculating stuff at every iteration and using the answer when you decide to.

that is true.but i think its more a matter of taste...

PeterH:
The process of calculating air mass flow from the MAF signal will require you to use a map because the conversion depends on speed and load.

assuming you do not speak about the AFR map, then, i really do not know where you get that from...
i havent seen any map like that. all the datasheets, have MAF transfer curves.

The sequential injection algorithm you describe is not what worked for me, but in any case I don't think you want sequential injection.

what worked for you then?? becouse i'm pretty sure you haven't got the slightest idea of what you are talking all this time, and you just make up stuff, about what you have understand from megasquirt..
do you even read what i post??

  1. based on injector flow rate, determine the pulse width. then make corrections based on dead time and other thinks...

all the corrections you talk about are accounted for at that step.

with reliable cam signal, sequental injection seems to me no different to acomplish than bached injection.

the above algorithm, can be of course calibrated with a tunning session based on the the O2 (As will everything else).
but i dont think it's perfect, so by all means IF you have something BETTER to CONTRIBUTE, then do so.

26

that is true.but i think its more a matter of taste...

You don't have unlimited spare computing power and you can't afford to have your processor thrashing away doing calculations that are going to be thrown away. It's not a matter of taste, it's a matter of necessity in order to achieve the desired end result with limited resources. Unless you have massively excessive resources for the problem at hand you can't afford such a crude design that tosses performance in the bin.

assuming you do not speak about the AFR map, then, i really do not know where you get that from...
i havent seen any map like that. all the datasheets, have MAF transfer curves.

Where I got it from is an understanding of what happens when an engine draws air in past a mass air flow meter, which you evidently lack. What the sensor actually measures is air velocity and air temperature. The relationship between air velocity and the sensor output is highly non-linear and the air velocity is highly non-uniform, so in order to estimate how much mass has moved into the engine you need to know how much variation there was in the speed during the period you're trying to average over. This will vary substantially with load and speed. It's exactly the same problem you face when tuning a carb. If engines were idealised devices with constant uniform air intake speed then a well designed carb would never need to be tuned, and a well designed MAF meter would also give you a result that you could directly convert to a mass flow by applying a calibration curve. But the engine isn't, and you can't.

what worked for you then?? becouse i'm pretty sure you haven't got the slightest idea of what you are talking all this time, and you just make up stuff

Your attitude makes it very difficult to bother responding. Remember that I stand to gain absolutely nothing by helping you.

What actually worked for me was injecting fuel on the back of the valve for most operating conditions, which is exactly the opposite of what you might have guessed. It works by boiling the fuel on the back of the intake valve and producing the maximum fuel evaporation and cooling of the charge waiting behind the valve so that the incoming charge had maximum density and optimal fuel./air distribution. It wasn't a huge difference, but winding the fuel phasing round the dial that was definitely the sweet spot under light and moderate load.

all the corrections you talk about are accounted for at that step.

Unfortunately you have no idea what 'all the corrections' are or how to account for them. You might as well draw in a box that says 'calculate required fuel injector pulse duration from all necessary sensor inputs'. Yes, it's accurate, but gives no indication of how you achieve that - and the answer is far more complex than you seem to appreciate.

27

What actually worked for me was injecting fuel on the back of the valve for most operating conditions, which is exactly the opposite of what you might have guessed.

dude. stop making a fool of yourself. you prove absolutly nothing but your lack of knowledge. i have arledy stated that :

In sequental , you have to have injected all the required fuel, before the intake valve opens.,

which is exactly What you suggested. so what are you crying about???

Where I got it from is an understanding of what happens when an engine draws air in past a mass air flow meter,

if you understand it so well, then why dont you tell bosch, to add enother curve in their datasheets??.
give me ONE datasheet, that has transfer functions, based on RPM.

what would you say , to stop contibuting in the post?? siriously. right from the begining, all you have done is biching. you have absolutly no desire to help, sto just stop following the post.

28

settra:
which is exactly What you suggested. so what are you crying about???

What you actually said was:

you have to have injected all the required fuel, before the intake valve opens., so you start 10degrees before that

Injecting just before the inlet valve opens is exactly wrong. Most of the time, you want to start injecting as the inlet valve closes. But it's academic since you are not going to get anywhere near enough to optimum fueling for the small benefits of sequential fueling to be relevant to you.

settra:
if you understand it so well, then why dont you tell bosch, to add enother curve in their datasheets??.
give me ONE datasheet, that has transfer functions, based on RPM.

You are misunderstanding the data sheets. The sensor essentially measures air speed and the data sheets tell you the relationship between the sensor output and the instantaneous air speed across the sensor element. What you want is the total amount of air that has been drawn in so you need to integrate the instantaneous air speed. If the sensor output was proportional to the air speed you could just average the sensor value but it isn't, so you can't. If the MAF sensor did what you think then you wouldn't need to tune your engine at all - you would just base the fueling directly off the MAF signal and the target AFRs. But the sensor doesn't give you that.

settra:
what would you say , to stop contibuting in the post?? siriously. right from the begining, all you have done is biching. you have absolutly no desire to help, sto just stop following the post.

Expressing views that you dislike is not 'bitching', but I think we can agree that you aren't going to learn anything from me so I will stop wasting my time trying to help you.

29

wow, this thread is getting ugly. Settra, i think you would do a lot better to tone it down a bit, PeterH is in fact trying to help, and, although there have been some missunderstandings, your constant acusations and over all shrill tone makes it difficult for anyone, including myself, to attemp to help.

PeterH has said nothing concerning fuel injection systems that i can dissagree with, Yet you insist on insulting him any time he says something you might dissagree with, most of your theories are somewhat on the right path, however you dont always explain them clearly, and attacking others who are trying to help due to missunderstandings or dissagrements on details is simply juvenile and rude.

I am a relative amature at programming, i will say that outright, but i have programmed quite a few arduino based projects with fairly good succsess, an engine controller would be an awesome project, but i am under no illution that it will be easy. the code required, if running on an atmega328 will need to be quite efficient, even if it is spread across several chips, there are a lot of calculations that need to be made in order to obtain the accuracy required to ensure the propper ignition timing and required fuel pulse. i am sure you are aware of this.

while i may be a novice at arduino programming, i am quite knowedgable about fuel injection systems, and tuning them. I have worked on cars for over 20 years, and spent close to 10 building, installing and tuning fuel injection systems on all different kinds of cars and engines. I now work as an electronics technition and do various R&D work on all manner of industial equiptment and computing systems. So, i think i have a lot to bring to the table when it comes to the project you are planning, but when you attack someone for saying things that i agree with i get my feathers ruffled a bit.

Everything Peter said about the timing of the fuel injection pulse is correct, in my opinion, the ideal timing for an injection pulse will be such that the end of said pulse will coenside with the closing of the intake valve, of course you already knew that im sure. or you know that i am wrong either way i am sure you will not hesitate to say so.

As i said, you seem to have a grasp on what is needed, but it seems you are also making a lot of assumptions at the same time.

since sivillity has long since been thrown to the wind, i willl echo Peters sugestion that you take a look at the megasquirt, you can purchase a MS1 kit for around $150, or buy only the stuff you need and for a bare bones board and probably get it even cheeper yet.
while i know you have a pretty strong aversion to it, think about the benifits. you would be starting from the board up, figure out how to interface with your various sensors and get usable output and data from it. Then, if you wanted, pull the motorolla chip out of the board and wire the atmega(s) to the board now you have a tried and true hardware interface with injector drivers, ignition drivers (if you want) analog input circuits etc. and, i think, after doing all of this (and reading the massive ammount of documentation) you will have a much better grasp on what will be required of the arduino.

you will have to put some time and money into a board of some sort anyway, injector drivers etc.

Somehow i doubt you will, as you seem more interested in being right than being productive, but i could be wrong.

So now that i have put myself squarley on your s4!t list along side Peter, i wish you luck, i am still interested in your project, and i still hope you find succsess, and, if asked i will still provide input, however i do not enjoy being asked a question and then having to defend my answer, so please keep that in mind.

best of luck

30

or, while it still has the cursed megasquirt associated with it, you could look here and start with code that reportedly already works

31

Couple thoughts that might help…the topic interests me but I didn’t have time to scan through everything so apologize in advance for redundancies or misunderstandings.

  1. If you’re doing sequential injection then ‘Peter H’ is correct on injecting the fuel as soon as the intake valve closes. The reason for this is giving the liquid more time to vaporize while it hovers on the intake valve before it enters the combustion chamber.

  2. Use TBW (throttle by wire). Pull something out of a salvage yard if you have to. Then you could create arrays/tables in arduino that will illuminate so many IAC headaches. Running a PWM IAC separate from a PWM throttle adds so many more variables…can’t express that enough. Especially when you get to transients and getting this thing working correctly at every temperature, altitude, cold start, hot start, etc...

  3. Most importantly with this project. Be safe and have a ‘fail-safe’ for everything. I suggest every wire in your prototype engine harness to have male/female connector so you can properly short out wires, add voltage to wires, etc… before it goes on the road. You can back probe connectors and stuff like that but it’s much more efficient to create a 3-way connector allowing you to influence a wire while in operation. It’s thousands of tests, done it, but well worth the potential consequences. Not only could a short bypass your ignition and send you into a school zone at WOT, but might even save you from your engine winding up without a load and throwing a rod. If using TBW then make sure the two internal potentiometers are sending opposite results (one 0 to 5 volts and the other 5 to 0 volts)...very important from a safety aspect.

  4. Mega squirt and many others are great for most do-it-yourselfers, but clearly he wants 100% control of the engine, therefore using a microcontroller like Arduino is a good option.

  5. Use a MAP sensor and forget the MAF. That will save many headaches. Add it later if you want.

  6. Forget the O2 in the beginning to help with engine control. You need a wideband (think I saw you have one of those) and see what the exhaust is doing but leave it out until all code writing and transients are months behind you.

  7. Make sure you have exhaust temps at each port, not just in the collecting exhaust manifold. Tap a 1/8th NPT for a type K thermocouple (or something else you might be using) as close as possible to the head. If their pipes, then pull them off and weld a fitting for them. Keep it within 1 inch of the exhaust manifold flange.

  8. May I suggest a solid foundation within your code. Create a table of MAP vs. RPM and a second table of Spark Advance vs. RPM. Within these tables are your injector open times (assuming your using peak and hold injectors). Write your entire code to ‘theoretically’ run the engine just of those tables. Then insert multipliers, constants, sensors, etc… to run your engine based off those values.

  9. Some cylinders require different fuel levels. There are many reasons for this and can get deep into thermodynamics, but an obvious one: If a cylinder is positioned between other cylinders and has the same coolant ports, it will most likely run hotter than a cylinder that has only one cylinder next to it. You might be able to control each injector in relation to intake valve closing, but are you going to be able to control the duty cycle of each injector. If so, try to create a multiplier for each cylinder based off those tables. If not then sometimes it’s better to just run the rest of the cylinders a little rich to keep things cooled down. Saves an engine from tuliped valves and other issues on hot days or higher engine loads.

  10. If your current engine has a distributor, then take it out and lock it into place so it cannot change with centrifugal force. You don’t need a crank sensor and you have your cam sensor. If your engine is using coil packs then see if there is a cap or plug blocking off where a previous version used a distributor. If so, grab it from a salvage yard. It’s going to be much easier to use a distributor instead of coil packs until you eliminate the other variables.

  11. Don’t need a speed sensor.

  12. Engines are engineered to have maximum power or most fuel efficient. If you want your engine to be most efficient but need power at certain times then that is what the multipliers are for as described above. Our pocketbooks wished we could keep the world stoichiometric with a 14.7 air/fuel ratio, but our lady friends sometimes wants us to throttle down and pass grandma so we can get to Vegas. Most engines burn 11 or 12 air/fuel ratio to get the most power (also changes with RPM), hence the multipliers.

  13. I think you were wondering how to measure load: MAP sensor and that’s where the MAP vs RPM table would be handy, as mentioned above.

Hope this helps and didn’t intent to put this much time into it or make it long and boring but maybe it will help. I applaud anyone that wants to expand their mind in the ways that works best for them. But I will not post again to anything whatsoever that includes criticism, hostility and some childish things I had to unfortunately scan through. We’re all together on this, sometimes we help and other times we get help. Good day & good luck!

32

hey cpjsparks :smiley:

thanks for the extensive reply :slight_smile:

i don't plan on controlling the ignition yet. i will leave it to the car's module, because otherwise, its too much risks to consider... :confused:
i need the VSS, because i would like to be able to have consumption ratings :slight_smile:

as for the MAF and MAP.
MAF indeed seems very hard, to tune the transfer function correctly. but if you do, then the rest seems easier to me??
for load , i was thinking of using : Load = (Airgrams/cylinder) / (engine displacement in grams)

also, MAF in general "needs" less veriables?? considering that every AnalogRead() is 0.1 ms, MAF needs only the maf signal (And battary volt and temp ofc), where MAP needs, IAT,Baro,MAP, and maybe other stuff too?

tbh, i haven't figured a way to fueling based on MAP yet... (cant find the algorithms)

unfortunately, i dont have a WO2.. i have a narrowband. but i think it would be ok, for the first parts of tunning (getting the maf transfer function correct )

P.S : i havent thought about the different temps of each cylinder! thanks for the heads up :slight_smile:

P.S2: why do you suggest exhaust temp monitoring?? (you mean something like EGT?) is it for a fail safe monitoring mechanism??

33

also, in some more "techincal" stuff:
when using analogRead() to read a voltage value, you suppose that the Vin of the arduino is 5v. butif its not 5v, then the results will be different... with a power supply that fluctates +,- 0.1v , then that error can be significant... no use reading battery voltage, if the error will dominate your readings....

so a power supply which outpouts almost constant 5v should be used... are switchers good enough on this?? ...
is there any other way to avoid this ?? (maybe with the AREF pin? although i dont yet know how..)

34

Can you get a signal from the transmission and send to the Arduino for a VSS? Does it have an output showing the current controller what gear it’s in? If so use that, your tranny specs, tire size and RPM to calculate it for you.

Your MAP sensor will know BARO the second you key on, therefore it knows your altitude. Then if you created the following tables (X vs Y):
RPM vs MAP: Will contain injector dwell cycle times in milliseconds
IAT vs MAP: Will contain multiplier values
ECT vs MAP: Will contain multiplier values
Constants vs BARO: Will contain multiplier value during key on/engine off
IAC vs ECT: Will contain desired idle when TPS is < 2%

I would think there would be a lot more variables and more inconsistent results using a MAF so I don’t know a good approach for you if using MAF.

Within those tables you can start out with results from your current running engine. Drive your vehicle and record the results from a few locations within the tables and fill in the blanks with the rest. If you don’t have an oscilloscope then use the Arduino to detect current injector times.

Once your Arduino is running the engine you’re gonna want a wideband sensor so you know your Air/Fuel ratios. Your regular O2 won’t show you that, it will only show you rich or lean and isn’t supposed to make drastic changes so leave that unplugged from the Arduino after you first hook it up.

The exhaust temps are important because if you run a cylinder really lean it’s going to get very hot and damage your engine. Since the Arduino is going to be able to control the injectors you want to make sure it’s making the right calculations. Even if you know Air/Fuel ratio you still need exhaust temps. Sometimes you have to run the cylinders a little richer then the Air/Fuel ratio you hoped for just to keep the cylinder cooled down.

If all you want to do is slew the fuel then have the Arduino control an adjustable fuel pressure regulator with a servo motor or something. Then you can just have a potentiometer adjusting the fuel pressure for more or less fuel.

Regarding your 5v question - I just ran across that problem a couple weeks ago. I have a project with 60 inputs and made voltage dividers so 5 inputs could go in on each channel and Arduino would be able to recognize the different voltage levels but the Vpp (voltage peak to peak) values were huge so I put a small capacitor and it holds my Vpp within 0.01 volts. I also put a resister on both sides of the capacitor because an input into Arduino analog pins would disturb neighboring pins. Problem solved.

Cheers!

35

If all you want to do is slew the fuel then have the Arduino control an adjustable fuel pressure regulator with a servo motor or something. Then you can just have a potentiometer adjusting the fuel pressure for more or less fuel.

Nice tip!

I haven't read and have only trouble-shot systems but I say go for it. I don't think it should be terribly difficult, if imagination and basic understanding are there, to get a running car, maybe a bit higher fuel consumption, bad cold starts ( but cj's idea is also a choke function so...). I would start with non sequential though, having continuous injection allows focus on core factors: basically load is proportional to airflow, enrichment for acceleration on carbs is mainly for the throttle transition...

It's late and I still have some things to do but I'll probably have a deeper look later, I like learning trick and I think this might be an excellent place for such. Best of outcomes to you...

36

Hi all,

I came across this thread looking for how to control one injector for a "simple" rig which switches between two fuel sources in a furnace type application. Obviously not the topic of this thread, however... I did find something which settra might find useful:

Basic Fuel Injection Principles (seems pretty comprehensive and really explains the relationships between all the components in the entire system).

I hope it is helpful to you, settra! Good luck with your project!

37

http://www.rotaryeng.net/simple-cheap-555.html
check this page
the only thing it hasnt is the acceleration enrichment

38

Is there a sketch code for basic ecu for 1 cylinder engine (simple ecu), I am interested in trying ecu from arduino.
Input from CKP, TPS
Output fuel injector and ignition.
Trims,

39

Hi All, have you seen this

https://www.monocilindro.com/fuelino/ - open
https://www.nanoefi.com/ - pre beta near

Search in google for: diy efi arduino
and also for: diy retrofit EFI motorcycle

Tons of products, videos in youtube, startups etc...
Seems to be very relevant for the topic.

I also find this matter very interesting.

Best regards.
Peace...

Lissandro

40

I did a diy efi with ignition for air cooled vw engines. It works well. Perhaps there is info that may help on small engines. I am actually thinking of using the system for a v-twin lawn mower engine. See: KitCarlsonEMS