What is the absolute minimum number of sensors to run a 4 stroke engine?

Factual Questions
1

I am currently rebuilding a small 4 cylinder 1 liter, multi point fuel injected engine. I want to make it run, but I don’t have the ECU module, so I am thinking to use a microcontroller and some code of my own to control the injectors and spark plugs.
So what is the absolute minimum of sensors I need to hook up to the uC? All I want is to make the engine run for a while. I don’t care for ultra smooth operation or maximizing power output.

At first it will be at open loop mode with just a basic map. If it goes well I will add more sensors to make it run smoother.

2

None.

If it’s a simple carbureted non-emission-controlled job, like a lawn-mower engine.

After that, it becomes a matter of how much sophistication you want and what goals you have in mind. Maximum power? Max efficiency? Minimum emissions?

There really isn’t a single answer, other than “do the engineering.”

ETA: you’ve indicated you already know the answer:

If it “make[s] the engine run for a while”, zero sensors will work. Mission accomplished.

3

I don’t think there’s any getting around a crank or cam sensor to tell the coils when to fire (assuming it’s distributorless). Other than that, if you just made yourself a knob that changes the injector pulse width, you could basically tune it by ear to get it running nicely at a constant speed. You may even be able to vary the engine speed a little bit by cranking up the knob as you open the throttle.

Probably wouldn’t be the nicest thing to do to your nice new engine internals though!

ETA: Of course that may be cheating if you want to count your own senses as sensors.

4

You will need to know throttle position and RPM in order to inject an appropriate amount of fuel for each combustion event.

You will need to know crank position in order to achieve a suitable ignition timing.

Everything after that is refinement.

5

The engine has a distributor. Is the crankshaft position sensor really necessary?

6

A small screw up could overspeed the engine and blow it real fast. This is something I have never tried but would look forward to hearing your results.

7

Well, you’ll need something to tell the injectors when to fire. I suppose you could use RPM and a timer and then just have a continuous sequence of very short injection events, i.e. many tiny injection events per cycle. That way you wouldn’t need to synchronize the injection events with the crank in order to assure roughly the same amount of fuel per cycle (if you just had one big injection event per cycle and it was synchronized by a clock instead of the crank, then you could conceivably end up with a situation where you have one engine cycle with no fuel injection event, and the next engine cycle receives two injection events.

If you have a distributor, then you can use that as a cam sensor, and then trigger your injection events from it; all you need then is a throttle position sensor or an intake manifold pressure sensor to gauge mass air flow rate into the engine.

8

Which kind of distributor? Is there a switch that does ignition timing, or just the distribution part, which sends the juice to the correct sparkplug?

If the former, you’re good. If the latter, you have some nontrivial work to do.

In order to answer the question, we’d need to know more about the engine. List all the sensors and actuators and we can give you a better idea.

I worked on engine control at Ford Scientific Research Lab in Dearborn, and learned a lot about it. One of the simplest aspects in theory is scheduling spark, but it’s trickier than you might think. For example, the coil has to be charging for at least 1.5 ms to deliver a spark, but must not be allowed to charge for more than say 4 ms or you’ll burn it out. (Those numbers are from memory from 1978 and are subject to significant error!) Hopefully you already know that the spark happens when the coil is turned off. (If not, chances are slim you’ll have a clue about the rest of the stuff.)

Unless you have a good resource for a “strategy” (the set of equations relating the inputs to the outputs) you have quite a bit of work to do before you even begin at the part where my expertise begins, which is how to code it.

The simplest strategy I remember was a single handwritten page with about a dozen equations, some of them fairly long. That was for an 8-cylinder pickup. The number of cylinders doesn’t affect the math or coding much. I transformed that into a Pascal (variant) program that ran the truck. I don’t remember how long that program was, but I’d guess it was on the order of 50K characters. Most of the code revolved around scheduling. One complication was that it used fixed point arithmetic; today you’d use floating point and save a lot of trouble.

I wonder whether an Arduino could handle it. At 5000 RPM on a 4-banger, that’s only about 1600 spark and fuel events per second. The trick is spark timing, which has to be accurate to about a degree of crank angle. That’s 1/30,000 sec, or 33 microseconds, at 5000 RPM. Using much cruder hardware we got higher accuracy, but special-purpose hardware and a bit of software engineering went into it.

BTW, you don’t need a “crankshaft position” sensor as much as a “top dead center” signal. Back in the day, they used hall effect sensors for TDC.

9

:dubious:

I get 333 per second:

5000 RPM = 2500 cycles per minute = 41.6 cycles per second

4 cylinders, each gets spark plus fuel, so 8 events per cycle

8 * 41.6 = 333 spark/fuel events per second

10

I was thinking about an Arduino too, but they are relatively slow. Maybe a car engine is pushing its limits. Also there will be latency issues that have to be accounted for in the code.

11

I would argue with that. Floating point is still not a good idea for controlling programs. Sure, with today’s faster processors and bigger memories, throughput and size are not as much of an issue. But, I’m old and kinda set in my ways. :slight_smile:

12

Could you use one per cylinder? Then each Arduino only has to manage 83 events per second.

13

I should have shown my work, and hopefully would have seen my boneheaded mistake! Thanks for the correction. Also, I forgot about 4-stroke correction! (doh). You neglected to take into account that each spark or fuel firing requires two events (turn it on, turn it off). So, 16 events per cycle. Regardless, you win! If the processor can handle all the high priority stuff in under a millisecond, it’s fast enough. The math can take longer, in background.

Slow compared to what? The microprocessors we were using back in the late 70’s / early 80’s had clock speeds like 1 MHz. I wouldn’t be surprised if the Arduino is considerably faster. Latencies have to be very carefully managed, regardless of the processor.

Why is floating point not a good idea? I’d bet dollars to donuts that’s what car companies use today (though I’ve been out of the biz since 83). Fixed point is the source of an incredible number of bugs. It was used due to the slowness of the processors and lack of memory (one processor, the EEC-III, had a grand total of 255 bytes of RAM, total).

For example, NTP used to be specified (up to version 3) using fixed point. The NTP4 spec uses floating point and is dramatically simpler, yet just as accurate. (The accuracy is still tracked by the protocol, and the source of inaccuracy is not the floating point math, but the reality – mostly, variations in delays between peers, which generally dwarfs the inaccuracy in the top strata clock.)

Admittedly, floating point can cause some curious issues, but mostly when the math isn’t properly broken down so you don’t have near-infinites divided by near-infinites (or infinitesimals, etc). Or when someone out of ignorance tries to compare a floating point value for equality with something.

14

Oh, I was just anecdotely whining as much as anything.

On one processor that I’m most familiar with, an integer add takes three clocks. A floating point add takes 14. The people that abuse floating point the most are the ones complaining the loudest about throughput.

I recently spent a couple of hours debugging someone else’s controller where they added three floating points together and then used that number as a divisor and then got an underflow exception – and somehow it was my fault.

Other than throughput, there’s nothing inherently wrong with floating point math in a controller. It’s just that I find that developers that complain the most about not being “abstracted from the hardware” are often the ones that practice the least rigor and discipline in their system design, so they’re more likely to get into trouble with things like floating point numbers.

The “out out ignorance” part is way more common than it should be.

15

MPFI requires considerable feedback and control, as much of the above demonstrates. What you’re trying to do, basically, is reinvent the ECU - you’re tossing the optimized computer that controls this process and does so reliably and nearly indestructibly, and trying to reverse engineer it using fragile, finicky bench tech.

I really do fail to see the point, even as a hobbyist endeavor.

16

Modern FI systems coordinate the fuel injectors with the engine cycle, but on older FI systems there’s no reason why you need a separate injector signal for all four injectors, nor does your number of injection pulse signals have to necessarily correspond with the engine speed.

17

I thought about doing this once-upon-a-time. I was thinking about pulling a 4-cylinder Nissan engine out of a wrecked pickup, along with the ECU. I was pondering a similar question as the OP, how many inputs would I have to supply to the ECU to keep it happy. I was thinking of a box with four or five (or however many) analog outputs controlled by sliding pots. I knew I would that to supply throttle position, airflow, and exhaust gas temperature. After that, I didn’t know.

It would be a fun hobby project.

18

Which older injector systems are you talking about? Ones from the 60’s? Maybe even 70’s?

The only way direct computer-controlled injection systems that I was familiar with (in the late 70’s, early 80’s) worked was that the computer switched each injector on and off. This is unlike spark, where it turned the coil on and off, but the distributor selected which spark plug to send the juice to (when the coil’s primary is turned off). Today we may have direct solid-state ignition, I suppose (that’d make sense).

That contrasted with central fuel injection (CFI) systems where fuel was injected into a throttle body upstream of the intake manifold. For CFI, you just need to meter the flow using a duty cycle, and the timing isn’t important. I don’t know of any DFI systems where timing isn’t (somewhat) important. It isn’t critical like spark; it just has to happen at the right phase of the cycle. You don’t want to inject fuel into a cylinder that’s in its exhaust phase. I don’t know much about the details, but I also suspect you don’t want to inject while the cylinder is firing.

Please tell us more about these DFI systems that are different. Can you cite any specific examples?

19

The sensors are integral to the engine. Pull engine, install mechanically, mount ECU, connect. Where’s the fun in reinventing the engine controls? Reprogramming, re-chipping or otherwise tweaking, sure. But… I dunno, it’s still a lot like “I want to put a Ford big-block in my VW… but I want to hand carve a new crankshaft for it!”

20

Pretty much all the first generation (i.e. mostly 1980’s vintage) EFI systems worked like I described. The reason why car makers started touting their “sequential” EFI systems around the early 90’s was to contrast them with the earlier batch fire versions.