RADICAL NEW FUEL INJECTION SYSTEM NEEDED

[Guy Croft]

Any of you 'brain boxes' out there like to consider how one might design a fuel injection system that could calibrate itself?

I have some ideas on this.

GC

[kpsig]

Any of you 'brain boxes' out there like to consider how one might design a fuel injection system that could calibrate itself?

I have some ideas on this.

GC

Mr. Croft, what do you mean by calibrating itself? (sorry for my not understanding)
Kostas, Greece

[TomLouwrier]

Morning Guy,

Oof!
Most injection systems have been self learning since the wide spread adoption of lambda sensors and closed loops. This will only adjust for variances in pump fuel quality and relies on a decent base mapping, meaning it can do with the signals from the cheap standard narrow band sensor just upstream of the cat. It's self learning nevertheless.

Building you own is not that simple at all. Mapping up is not even close to building the system that uses those maps. It's like the difference between setting up carbs and constructing the entire core engine from white paper and metal billet.
You'll need intimate knowledge of electronics and real time software programming, most in assembler code. And then some about petrol engines and carburation but that won't be a problem for you.


Mr. Cliff Jefferies of Sidney, Australia did just such a thing a couple of years ago when he was fed up with the fragility and limited drivability of the Marelli M16 and P8 models on his Moto Guzzis. These are 2 cylinder bikes of course, but the ECU's come as 4 cylinder unit in many European cars as well. His kits are relatively easily adapted to other bikes that use the same injection like Ducatis and Laverdas (yes, I have one). He sells them under the name of MyECU, models MyP8, My15M and My16M. The latest versions' PCB actually fit in the Marelli OEM casing, so makes it a sort of plug'n'pray conversion. They are not even that expensive.
There is also an external module called the Optimiser, which you can use to set up a map instead of hooking up the pc (rolling road or actual road). This unit has a learning mode, which enables you to have the ECU run in full closed loop and correct the map on the fly. After a while the map is stable and you can disconnect the Optimizer and enjoy your new mapping. I think this is what you're looking for.

Cliff is a very experienced and clever electronics and software engineer, and a quite knowledgeable about engines too. More importantly he's friendly and easily contacted. It's been some years since we were in touch, but Cliff is very responsive to suggestions and ideas about how the MyECU works or what features could be added to it.
It will be interesting to see where putting your two brain boxes together can lead to.
I'll send you his details.

regards
Tom

[Guy Croft]

I want to see an aftermarket system where there we have:

1. No injection or igntion maps
2. No essential calibrating by any external operator
3. Fit for use any engine (given that the hardware will vary, injectors etc)
4. A system that totally & literally programmes itself by learning what the engine needs for optimum torque at any speed/throttle condition by monitoring the firing cycles stroke-stroke.

Not interested in the slightest in Lambda and emission targets for purely functional and technical reasons and because VERY few competition engines use catalytic converters and long may that continue.

There may be some presets in the ecu of course but simple enough that anyone can do it. I have had a couple of pms where the writers share the same idea I have that this can be done by cylinder pressure monitoring.

Hope that is clear.

G

[TomLouwrier]

hi Guy,

If I understand you correctly, what you want is:
- injection and ignition control that calculates the engine's needs every cycle (every few cycles?).
- This may be for each individual cylinder or for each engine cycle (all cylinders firing an identical load per 2 crank revolutions)
- some form of closed loop must be set up to monitor engine's output
- injection timing and amount by algorithm (to be determined)
- ignition timing by algorithm (to be determined)
Optional:
- possibility to choose injection strategy (timing and batch/sequential)
- possibility to provide different cylinders with different fuel and ignition (think of engines with a warmer and colder side like Duc's L-twins or transverse V-engines in cars)

I don't like cats any more than you do, but lambda sensors give a good means to measuring the engines running condition and thus closed loop fuel metering. Once you're in the ball park you may find a narrow band sensor is good enough to let the ECU optimise itself permanently.

I think there is nothing wrong with a using a form of base mapping, especially if
- the system is flexible enough to 'pick itself up' from a very rough estimate and refine itself once running (learn)
- the system keeps refining itself during use, compensating for changes in fuel, environment, etc
- the system can thus cope with changes in engine configuration (cams, exhaust, air filter etc)
It's a well proven strategy and saves an enormous amount of calculating effort. Also it gives a form of protection against the system going wild and lean out or enricht beyond sensible values. And it can serve as a fallback in case of sensor failure. A 'limp home' feature may very well mean a 'limp to the chequered flag', instead of DNF (Did Not Finish).
Anyway, that's a design decision you need to make when doing the layout for the software, not now.


We will need some, or all, of the following inputs:
engine revs and phase
- crank
- cam

engine load
- throttle position sensor (TPS)
- manifold air pressure sensor (MAP)
- air flow (volume)
- air flow (mass)

environment
- engine temp (water)
- engine temp (oil)
- absolute air pressure
- engine intake air temperature
- oil pressure 'OK' (else engine cutout)

engine performance
- lambda (if only to safeguard the engine from going way too lean or rich)
- exhaust temperature
- engine torque (this is the key performance indicator we're after)
- engine BMEP (how to measure that?)


The unit must give some, or all, of the following outputs:
- injectors, up to two per cylinder
- tacho signal
- 'engine running' signal (for safety fuel pump cutout and driver warning)
- ingnition
driving 1 coil and distributor, or
driving 4 coils (plug-mounted or otherwise), or
driving one or more power packs that drive coils


Hardware (housing, pcb, components, assembly) will have to be very robust (automotive or MilSpec standards).
Electronics will have to be equally robust, especially considering signal/noise ratio: wiring, shielding / earthing.


The software running this thing must be real time. At 10.000 revs/min there will be 12 milliseconds for a full set of calculations if that's one set for all cylinders or 3ms if you plan on doing each cylinder separately (assuming a 4 cylinder engine).
These calculations will be pretty complex
- algorithms for calculating injector pulse duration and timing: TBD
(include features like: cold start / running? acceleration enrichment? behaviour on engine braking? etc)
- algorithms for calculating ignition timing: TBD
- strategy for rev limiter: TBD
These will most likely have relations, it is important to determine which one is leading, the other(s) following.

You better count on a very powerful processor.
This would be not feasible in a high level programming language as far as I can see.


Talk about an interesting challenge....
Couldn't you just ask for something simple like the Holy Grail of ECU's?


regards
Tom

[Guy Croft]

The Holy Grail, that is right, Tom.

G

[robert kenney]

The learning/ self tuning ECU is very common already.
FAST (FUEL AIR SPARK TECHNOLOGY) Cutler EFI now Holley to name a few.

[Guy Croft]

We may well be behind US technology Rob. Links appreciated.

G

[Entech]

Just a view on engine calibration;

When you start it looks simple but as you go studying a bit deeper then the problems arise.
Most people start with Lambda-tuning as this is easy and a lot of aftermarket ecu,s from the last 15 years have this function.
It gives an easy basic fuel map based on a requested Lambda value, You can even let it run "real-time".
However an engine doesn't care about Lambda and each engine seems to have a little different fuel demand for delivering it's best performance.
(even CNC manufactured items)
So the next step people should make is to make some sweep runs with the computer giving the engine more or less fuel and let it search for more torque.
And that is in fact the first engine calibration.
Be aware that this is not Lambda self-calibration by the fuel controller anymore but controlled by a good dyno operator.
(However there are high level management units that are torque sensing real-time but they are not for us normal people)
This is where most fuel calibration ends, assuming that you have a basic ignition map.
When you desperately looking for more power ,you arrive at a point that you going to think about slow burning mixtures and more ignition advance or the opposite with a fast mixture and less advance to see which combination gives best torque.
That’s the point where for example cylinder-pressure measurement can give answers on both fuel and ignition questions.

That brings me, my basic answer of Guy’s question ; " How one might design a fuel injection system that could calibrate itself ".
But this bring up even more questions as , what pressure curve should it look for?
You have to think about even the most basic questions as;
should an engine with more torque over the whole curve (measured on dyno) accelerate faster then the engine with a little less?
What are we really looking for and what do we see on our dyno?
As we have good answers on those questions we can setup an self calibrating engine management.
Curious to hear your opinions.

Regards, Klaas

[TomLouwrier]

Some valid points there Klaas.

Let us separate 3 things first, so that we can agree on the sort of adaption / adjustment / self learning we're talking about. I propose:

1- adjustment of values read from existing maps whilst in closed loop, using feedback from mostly lambda as target value. This may, or may not, be written back permanently to the mapping. Adaption range is pretty small, so are sensor ranges (narrow band).

2- adaption of a 'ball park' preset mapping just to get the engine started, then 'discovering' itself and adjusting as running conditions are variated. In priciple this is the same mechanism as 1 but with wider adjustment ranges and special algotrithms to iterate quickly towards usable values.

3- complete dynamic calculation of mixture and ignition, done on the fly, using a set of as yet unknown algorithms for establishing the correct values. This needs certain rules and formulae to calculate with, a whole different ball game from 'self learning' a map.


Option 1 is done by most or all current production ECU's, as mentioned earlier. It is meant for compensating for relative small changes in fuel, environment, engine components (ie: clogged air filter).

Option 2 is currently not available as far as I know, but could be made by extending products like the FAST and MyECU. Not easy, but do-able.
It is comparable to what Guy does when you cite your engine specs and his brain comes up with a decent carb and ignition setting to get started. In computer terms that's an expert system, using artificial intelligence and fuzzy logic (no offence meant).

The FAST unit and the MyECU (plus Optimiser) do use mappings and once running they 'learn' the best values for those mappings. They can also be tuned manually on a dyno. These units are somewhere between 1 and 2.

Option 3 seems very complicated if not impossible with technology available at the moment. Or maybe the limitation is in me.
How will the ECU ever know it's environment, if only for getting the engine started? So many parameters that severely influence the amount of fuel and spark needed.

There could be a hybrid between 2 and 3 though, depending on the possibilities of extending option 2 so that it can 'pick itself up by the bootstraps' and learn from there on. Whatever it has learned can be remembered to save lots of time and maladjustment. If the situation changes it can easily be overwritten with the new 'knowledge'.


Engine torque can be measured (relative, if not absolute values) quite easily by fitting a strain gauge someplace between the block and the chassis, relying on slight engine movement to indicate torque. This is in fact the same as measuring BMEP, I've just realized.
It might be a big step forward to have an existing ECU control against torque in stead of the usual lambda value.

I think lambda should still be used as safeguard; these systems can get it wrong and spin off into way too lean or too rich ranges if running in 'full closed loop' mode (i.e. not limited at all by map data).
And we know what that will do to an engine.


regards
Tom

[TR-Spider]

interessting topic...some thoughts:

the only self-learning system I know (from reading) is the alpha-N.
There one has maps with fuel-valve opening times to start with, a lambda wishlist and a wideband lambdaprobe.
All the system does then as "learning" is altering the fuel-valve opening time in case of a deviation between lambda wish and reality.

But such a system seems rather trivial compared to Guys "holy grail" system.

First, there is no defined optimisation value, just a "maximum possible torque, please"
Second, the adjustables are fueling (resulting in lambda) and ignition timing, which, I suppose makes a reliable knock control mechanism necessary (or will torque decrease before knock starts?).
Third, I have difficulty to imagine this king of optimisation possible on a engine driven on the road. I suppose (mabe wrongly) that the time the engine "rests" on a loadpoint will be too short (also driving dynamics may effect the torque readings if by straingauge). There are two main adjustables to be moved in two directions on the search for maximum torque...on a engine teststand I could imagine that possible.

Thomas

[4v6]

This would be some leap forward if it could be achieved, but im not certain how it could be.

Obviously, the engine has to be started, so how would any proposed system "know" how much fuel to inject for how long if it has no references as in a map?
Im struggling to see how a "black box" is going to know where to start, and then it has to be able to compare what it did with what it did afterwards to know whether what it did in the firts instance was right, so a memory, even a short lived one has to be a requirement.

The only comparison i can make here is between the human brain- itd be like forgetting everything when you went to sleep and then having to re-learn it all again on waking up if you didnt have a memory, so thats really absolutely a necessary requirement.
I dont think the strain gauge idea for measuring torque is viable on its own because surely youd get alterations in output simply from the driving of the vehicle, such as in hard cornering or other external influences.
The map surely has to be retained, you have to have a place to start and be able to compare befores and afters.
Even a carburrettor has a "map" of sorts in the form of jet sizes and emulsion tubes, chokes etc that supply the program, the memory being the fixed attributes of each part.
Only other injection system i can think of that acts similarly is K jetronic and thats mostly mechanical, again its "map" is in its physical attributes, the shape of the air cone, delivery pressures and injector rates and so on.

I think a carburrettor might just be an easier option.

[Didi]

Hello Guy,

just want bring up an well established and probably well known solution from RPlabs, which might not be self adapting, but which offers quite a lot of possibilities to adapt to
different engine setups.
It works with modified IAW Weber ECU's. So first advantage is use of maybe already present and reliable Fiat hardware,
which - I'd say - makes it the most attractive alternative to aftermarket items.

It offers additionally to stock setup:
- Hybrid Alpha-N control method for normally aspirated engines (alternative to stock Speed- Density configuration).
- Progressive Anti lag system (bang-bang).
- Progressive Launch control system.
- Support for distributorless ignition system (with 2 or 4 coils in wasted spark mode).
- Up to two additional 0-5v analog inputs - one input is FREE of charge.
- Additional programmable digital output (useful for water injection, etc.).
- Closed loop fueling.
- Closed loop boost regulation.
- Software adjustable idle CO trim.
- Rev counter 5 volt drive signal - FREE of charge with distributorless ignition
*taken from http://www.rp-lab.com

I use it on a 16V na and 16V turbo engine (2L Fiat/Lancia) since 5 years and it is not as complicated as it first seemed.
On the other hand, even me as an engineer for vehicle technics, I had to learn some bits and pcs.
But as long as there are some base settings already done (e.g. na / turbo differences, firmware, aso.) it is just a question of "playing" with the maps.
I'm sure RP-Labs assists with delivering base settings already for specific engine setup.
Next advantage is, that the already existing stock maps from the ECU's memory can be used 1:1 for similar use.
So you can go from there and you don't have to start from scratch all the time. Helped me a lot.

Furthermore there is a so called "live tune" option which is useful for a first rough setting, so the engine runs about ok.
Next step is fine tuning the maps, which can be done by logging and analysing. So it may take just half a day for a semi-pro-skilled person to get an
engine running quite ok.

Wide band lambda sensor may be connected and logged as well with additional aux-input channel, which I'd recomment for radical engine conversions,
which need idle to full load adjustment without influencing the open loop ranges.

In general I'd say, that engine managment systems for any engine (race use incl.) can't be self adapting, as one would give all control away and
could never gain what is really needed (power, torque, smoothness, idle, ...) in the specific load/rpm-ranges.
So in my opinion there is no way around programming ECU's, there is just a most easy way to go.

Regards, Didi.

[Entech]

Hi Tom,
You have made your home work :-)
I think you underestimate the current level management systems.
As we look at your 3 groups, I think the first 2 are already common place and as Thomas say indeed on Alpha-N.
You know that a Dutch manufacturer build such a realtime running system on Lambda for more than 8 years ? and I think there are some more ?
However there is not much more development since, atleast not in the directions we discuss .
The step between the step 2 and 3 is in practice a bridge to far .
It needs indeed some sort of hybrid solution.

Lets take the pressure sensing idea;
It is possible to calculate the compressed mass in the combustion chamber from pressure-rise and derrive a basic fuel quantity from that.
with the same pressure data you can also calculate a basic ignition point to get the engine running.
in the following cycles you can optimize the ignition moment en the fuel quantity to get a better burn cyclus.
Thats not very difficult (well relatively speaking).
You could probably also calibrate against torque at the axle as you suppose,but this can give strange behavior in corners.
biggest problem with the pressure sensor is sensor degradation over lifetime, if you know it is defect it is good but if not? then your engine is defect :-)
so it seems you indeed have to back it up with some basis fuel and ignition map.(it could make that backup map in better times)
In practice it is to difficult but it can run! but not for longer times.
Thomas brings up some very important points on driving dynamics, I thinks that drivability could be the main reason that it is not yet used yet.
Knock problems (should they occur) where picked up by the pressure sensor and solved.

A less complex sytem is much nicer to work with and give less headache.
There are some nice alternatives that can work with pressure sensing and send there data to a corrrection map.

Klaas

[TomLouwrier]

hi guys,

Klaas, Thomas,
Yup, I guess my hands on experience with ECUs is already getting 'classic'. Almost all I did with them was when working on a race bike (national level) using the Marelli P8, and later on replacing those with the MyECU. So in both cases the same sort of system, Alpha-N indeed.

I guess I know the dutch firm you're mentioning, back then (2007) I found them pretty steep on price and not very willing to do anything with regard to fitting their product to a new vehicle, unless we'd hire them for more than reasonable hourly rate.

But back to the subject.
Given a basic set of parameters on the engine (number of cylinders, swept volume per cylinder, nominal flow of an injector, fuel rail pressure) you might be able to make a guesstimate of the pulse you'd need to inject something that would get the engine running. That would probably be the first setting you would want to remember in order to have a better start next time, so here comes a very rudimentary map already.
Once it's running there must be something that is used for feedback, in order to have closed loop mode. Not even thinking of engine temperature now (cold start and warming up phases).

The difficulties of having a hole in the CC with a pressure sensor in it, and keeping that sensor working under those conditions, are numerous and great. Why should we?
I can see the argument of engine torque fluctuating while driving, but so would combustion chamber pressure since those two are virtually the same thing. Of course there would need to be an averaging mechanism to dampen out the effects of those fluctuations.

If using lambda as target for optimal combustion you're going to find that that signal also needs about half a second to stabilize after changing the engine's working point (accelerate / decelerate). You need this 'steady time' when mapping up (manually or automagically) and on the road. I've seen an ECU get it wrong in 'full closed loop', running more off lambda than off the map, when the rider wanted to slow down and closed the throttle. ECU said no. In fact what it did was update its map every cycle and again and again while the signal was lagging. Shouldn't have happened but it did.
Rider hit the kill switch and coasted into the pits. We thought it was 'interesting', but that was after having a drink.

So in any case you need a data source to base your calculations on, other than the live input from the engine itself per stroke.
This would, by definition, defeat the idea of an ECU that does it all on the fly, every cycle again, without memory of what happened before.
I still see possibilities of a next generation mapped system that is able to bootstrap itself, then learn and adapt. Would be just as good.


regards
Tom