Rules instead of maps?

Official FreeEMS vanilla firmware development, the heart and soul of the system!
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Rules instead of maps?

Post by Fred »

Thanks for clarifying further, reanimation! :-)

You're unlikely to come close to modeling a real system with real entropy without exacting detailed knowledge of every aspect of these systems, something which only comes with years of messing around with them. A lot of stuff is going on, and you have limited ways to parameterise it. Getting some models working nicely on a too-perfect fake engine is likely to be near useless.

O2 sensors aren't as useful as you seem to think, either.

Fred.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
User avatar
sim
LQFP112 - Up with the play
Posts: 112
Joined: Thu Jun 02, 2011 8:17 pm

Re: Rules instead of maps?

Post by sim »

Rufe0 wrote:Hmmm OK so I think I'd like to have ago at making a virtual mathematical engine which I could write control algorithms for and run on a virtual dyno to see how well the control algorithm works.

I can see this being very useful but it would have to do a decent job of replicating a real engines oddities.

Writing the simulation and the control mechanism means I could easily get into a situation where I'm setting it up to work perfectly every time which wouldn't be useful at all.

Do you think it's feasible? Would it be useful? Is there already something out there like this? Would you be willing to help?

I guess for a start I would need a detailed list of all engine parameters, what effect a high value would have and what effect a low value would have. Assume I know nothing about engines at all.

Thanks Rufe0
Is it possible? Yes.

Useful? You sure will learn a bunch.

Is there something out there? It seems that OEMs are moving
towards modeling engines. Bear in mind they can and do spend
man-years perfecting their tunes. The other end of the scale are
the early electronic systems that used potentiometers to tune the
parameters of their simple models.

Is it practical? Probably not.

First, the list of parameters is long and some of them will be
non-obvious. Those "real engines oddities" are essentially
undiscovered parameters. No model is perfect. Controlling a
"virtual engine" ignores all of the unknowns.

Second, the parameters will be hard to tune. Some (most?) of them
will have to be tuned experimentally. This will take large
amounts of time. Each parameter will take a different strategy to
tune, and changing one will have effects on others.

Third, changing the physical set-up of the engine will destroy
much of the tuning work. This is true for a table based approach
as well, to some degree.

On the other hand, a table based EMS can be tuned to a quite
acceptable level in just a few hours on a load-holding
dynamometer by a competent tuner.

My earlier reference to carbs and dizzys was a hint. They
certainly can be used to great effect to manage an engine. Tuning
them however, is a black art as compared to a modern table based
EMS.

As far as seeking help, rather than asking for a comprehensive
set of engine parameters, why not attempt to assemble a list for
yourself? In doing so, you will learn a good deal about engines,
and develop a better understanding of the needs a good control
system would satisfy. There are some smart folks here that are
usually willing to critique work that people do themselves and
post about.

There have been people who have appeared with big ideas looking
for people to implement them. Those folks are mostly still
talking about their ideas. The people that go out and do things
themselves tend to have running engines.

As far as the FreeEMS project goes, it is already headed
in a fairly well-defined direction. Reading and attempting to
understand the code is a decent way to learn about engine control
strategy. It is not all table look-ups in there.
<@TekniQue> but in the end, it's code that makes a computer useful
User avatar
Hentai
LQFP144 - On Top Of The Game
Posts: 302
Joined: Sun Jul 18, 2010 2:35 pm

Re: Rules instead of maps?

Post by Hentai »

Look up GM's Virtual VE implementation.
They take all these values in the pic to make a on the fly ve table. There is no actual ve table, its just calculating it as it goes. Even so they got it within reason that it still not exactly 100% right but pretty dang good

The table you see in the picture is not actually in the ecu, its just what that tuning interface software shows you as an output from the formula that is used to on the fly calculate a ve value for the ecu. They did this to cut down on the needed tables with variable cam timing and displacement on demand\active fuel management as well as free space in the current ecu's

Image
Image
Image
Rufe0
TO220 - Visibile
Posts: 13
Joined: Fri Jul 17, 2015 11:54 pm

Re: Rules instead of maps?

Post by Rufe0 »

Hmm well thanks guys I probably would have wasted a lot of time on that. I might still do a basic one just for something to do but not put any serious time into it.
Rufe0
TO220 - Visibile
Posts: 13
Joined: Fri Jul 17, 2015 11:54 pm

Re: Rules instead of maps?

Post by Rufe0 »

OK now I'm thinking of making my own ECU from scratch with or without maps doesn't really matter I'm just trying to get the methods and operation completely figured out in my head. All numbers are plucked out of thin air, I'm just getting at the method involved. Oh and I'm thinking about my 600cc motorbike thats why the RPM etc ranges are what they are.


First we have the fuel map which is best done as an A/F ratio with Throttle Position % vs RPM. Which would look something like this.
af
af
If the RPM or Throttle Position are in-between positions on the map we can calculate them as follows.

For 1671.8 RPM 20% Throttle

Get the % difference between the actual RPM and Upper/Lower Map values
2000-1000=1000 / 100 = 10 //1%
1671.8-1000=671.8 / 10 = 67.18 //1671.8 is 67.18% of the difference between 2000 and 1000

Get 67.18% of the difference between Upper/Lower A/F values
13.17-13.2=0.5 / 100 = 0.01 //1% of the difference
0.01 * 67.18 = 0.3359 //67.18% of the difference
13.2 + 0.3359 = 13.5359 //13.5359 A/F ratio at 1671.8 RPM 20% Throttle

A lot of aftermarket ECU's are using a 16x16 maps, It seems to me that you could go a lot bigger, do you think there would be any advantage going bigger or is 16 fine?

Not every cylinder is exactly the same, maybe slightly different compression ratio or whatever so we need to adjust each cylinder individually. We can measure this by the exhaust header temperature. Is it OK to have static values like;
Cylinder 1 : 0.1
Cylinder 2 : 0.03
Cylinder 3 : 0
Cylinder 4 : -0.2
Which would be added onto the A/F map no matter what or possibly a scaling value based on either A/F or RPM like
PerCylinder.png
Or would it be best to have a full blown fuel map for each cylinder? I would imagine simple fixed values would be easiest for the tuner but a full map would be most efficient, maybe a scaling value is a good happy medium?

In addition to this we have an engine coolant temperature sensor that we need to richen the mixture for start and warm up. This can be a simple list that would be degrees C vs additional A/F.

Once we have sorted the A/F ratio we need for each cylinder we can calculate our fuel injection. First we need to know how much air we have so we take the MAF sensor and air temperature sensor and do whatever math is needed to calculate the air mass according to manufacturer datasheet. When we have the total air mass we divide by RPM, then divide by 2 (2 intakes per revolution on a 4 cylinder) this gives us the mass of air for this individual cylinder. With this and the A/F ratio we can calculate the milliliters of fuel needed. We can then lookup how long our injector needs to be activated to deliver that amount of fuel, in a Time vs Milliliters list, from the manufacturer datasheet. Then we start the injection based on the cam shaft position sensors and RPM calculation to coincide with valve opening +/- any offset we maybe want to add. No Map is needed to time the injection to valve opening.

Next we need ignition timing which we do with an A/F ratio vs RPM map measured in angular degrees BTDC.
ig
ig
For each cylinder we can lookup the A/F and RPM to get a degree BTDC timing, with this we can calculate the timing based on the RPM and cam shaft position sensors. For example

*assume cam shaft sensor at TDC of each cylinder 1-3-2-4 firing order

1000 RPM * 360 = 360000 //degree per min
360000 / 60 = 6000 //degrees per second
6000 / 1000000 = 0.006 //degree per milliseconds

180 - 30 = 160 // 30degree BTDC for example
160 / 0.006 = 26666.7 // 26666.7milliseconds after cylinder 4 TDC sensor = 30 degree BTDC cylinder 1


Retroactively we can come back and offset the A/F ratio map according to readings from our 02 sensor given the RPM and Throttle are within an allowed range.


*all numbers are plucked out of thin air, I'm just getting at the method involved.

Excluding small functions like rev limiter, is this an accurate description of the methods and operation of an ECU?

Thanks Rufe0
User avatar
Fred
Moderator
Posts: 15431
Joined: Tue Jan 15, 2008 2:31 pm
Location: Home sweet home!
Contact:

Re: Rules instead of maps?

Post by Fred »

Rufe0 wrote:A lot of aftermarket ECU's are using a 16x16 maps, It seems to me that you could go a lot bigger, do you think there would be any advantage going bigger or is 16 fine?
That really depends on the engine in question. A screaming cammed up NA engine that revs to 20k will want maximum cells RPM-wise, and 8 or so will be fine load wise. And a heavily (30+psi) boosted low revving engine (5 or 6k) will be fine with 8 or so in the RPM direction, and need upwards of 20 in the load direction.
DIYEFI.org - where Open Source means Open Source, and Free means Freedom
FreeEMS.org - the open source engine management system
FreeEMS dev diary and its comments thread and my turbo truck!
n00bs, do NOT PM or email tech questions! Use the forum!
The ever growing list of FreeEMS success stories!
Rufe0
TO220 - Visibile
Posts: 13
Joined: Fri Jul 17, 2015 11:54 pm

Re: Rules instead of maps?

Post by Rufe0 »

Fred wrote: That really depends on the engine in question. A screaming cammed up NA engine that revs to 20k will want maximum cells RPM-wise, and 8 or so will be fine load wise. And a heavily (30+psi) boosted low revving engine (5 or 6k) will be fine with 8 or so in the RPM direction, and need upwards of 20 in the load direction.
OK yeah that makes a lot of sense, still within a reasonable range. I don't see any reason to fix it so it couldn't be changed, within limits of course. Assuming your hardware has the capacity to store it.
tpsretard
QFP80 - Contributor
Posts: 99
Joined: Thu Mar 19, 2009 3:05 am

Re: Rules instead of maps?

Post by tpsretard »

And then you have idiots like me that daily drive a 30psi engine that revs to 9k and has a miserable time with all but the most expensive ecu's :(
User avatar
Hentai
LQFP144 - On Top Of The Game
Posts: 302
Joined: Sun Jul 18, 2010 2:35 pm

Re: Rules instead of maps?

Post by Hentai »

Rufe0 wrote:Not every cylinder is exactly the same, maybe slightly different compression ratio or whatever so we need to adjust each cylinder individually. We can measure this by the exhaust header temperature. Is it OK to have static values like;
Cylinder 1 : 0.1
Cylinder 2 : 0.03
Cylinder 3 : 0
Cylinder 4 : -0.2
Which would be added onto the A/F map no matter what or possibly a scaling value based on either A/F or RPM like
PerCylinder.png
Or would it be best to have a full blown fuel map for each cylinder? I would imagine simple fixed values would be easiest for the tuner but a full map would be most efficient, maybe a scaling value is a good happy medium?
on a stock setup car so far I've seen it down to differences at different load levels and rpm areas. I don't like the idea of single values like up top. Best to have a map for each cylinder imo.
Part of this issue will be down to the fuel injector the other part due to airflow issues
In addition to this we have an engine coolant temperature sensor that we need to richen the mixture for start and warm up. This can be a simple list that would be degrees C vs additional A/F.
Really needs a 3d map or a way to add fuel based on load as well as clt temp. You can get a stable warmup at idle and near cruise but trying to accelerate will show lean conditions due to the cold intake valve. I believe this causes an inefficent burn compared to warm up parts and goes lean when you try to accelerate \ increase load.
Once we have sorted the A/F ratio we need for each cylinder we can calculate our fuel injection. First we need to know how much air we have so we take the MAF sensor and air temperature sensor and do whatever math is needed to calculate the air mass according to manufacturer datasheet. When we have the total air mass we divide by RPM, then divide by 2 (2 intakes per revolution on a 4 cylinder) this gives us the mass of air for this individual cylinder. With this and the A/F ratio we can calculate the milliliters of fuel needed. We can then lookup how long our injector needs to be activated to deliver that amount of fuel, in a Time vs Milliliters list, from the manufacturer datasheet. Then we start the injection based on the cam shaft position sensors and RPM calculation to coincide with valve opening +/- any offset we maybe want to add. No Map is needed to time the injection to valve opening.
Don't need an air temp sensor if you use a MAF to figure out load.
why do you think no map is needed to time injection to valve opening?
for the fuel injector yeah you will need a lot of data to properly implement what you are talking about, much more data on a returnless system that is static fuel pressure.
Next we need ignition timing which we do with an A/F ratio vs RPM map measured in angular degrees BTDC.
Ignition.png
For each cylinder we can lookup the A/F and RPM to get a degree BTDC timing, with this we can calculate the timing based on the RPM and cam shaft position sensors. For example


Retroactively we can come back and offset the A/F ratio map according to readings from our 02 sensor given the RPM and Throttle are within an allowed range.

Excluding small functions like rev limiter, is this an accurate description of the methods and operation of an ECU?

Thanks Rufe0
not sure the idea on timing there, trying to wrap my mind around what you are trying to do
Rufe0
TO220 - Visibile
Posts: 13
Joined: Fri Jul 17, 2015 11:54 pm

Re: Rules instead of maps?

Post by Rufe0 »

Hentai wrote: on a stock setup car so far I've seen it down to differences at different load levels and rpm areas. I don't like the idea of single values like up top. Best to have a map for each cylinder imo.
Part of this issue will be down to the fuel injector the other part due to airflow issues
Hmmm OK I see what your saying but I just don't like the idea of a map for each cylinder, from a tuning point of view your effectively tuning four single cylinder engines which is obviously a pain. What about one proper full fuel map, then a modifier map for each cylinder which would just be +-1% or whatever in a 3d table? That way you still have a central table where 99% of your tuning is going to take place for ease of use.
Hentai wrote: Really needs a 3d map or a way to add fuel based on load as well as clt temp. You can get a stable warmup at idle and near cruise but trying to accelerate will show lean conditions due to the cold intake valve. I believe this causes an inefficent burn compared to warm up parts and goes lean when you try to accelerate \ increase load.
OK yeah thats reasonable. Just wondering if the same thing could be achieved with a percentage modifier? For instance at X degrees C add 10% extra fuel. That way it's not a fixed amount like "add 1ml extra" it will scale up with load and RPM.
Hentai wrote: Don't need an air temp sensor if you use a MAF to figure out load.
why do you think no map is needed to time injection to valve opening?
for the fuel injector yeah you will need a lot of data to properly implement what you are talking about, much more data on a returnless system that is static fuel pressure.
A MAF needs an air temp sensor, your thinking of a MAP sensor.
I don't predict needing a map to time the fuel to valve opening, I plan to modify my engine with a unique intake system that will basically negate sequential injections benefits(and make a MAP sensor useless), regardless it's no trouble to program a basic version in. I Plan on making a few different versions just for the hell of it. Directly after valve closure, maximum time for evaporation, perhaps enable this on start and warmup. Directly before valve opening, injector would just finish as the valve was just opening. On valve opening. And some others, maybe switch between different modes for different conditions. Of course these would be offset-able, probably setup a scaling offset with RPM. All this assuming the injector pulse is short enough in the first place.
Hentai wrote: not sure the idea on timing there, trying to wrap my mind around what you are trying to do
Once I've calculated the A/F ratio and injected the fuel I then need to time the ignition. To do this I will lookup the degrees BTDC in a A/F vs RPM map, calculate the time in milliseconds or clock cycles after the relevant cam position sensor using the RPM and set an interrupt.
Post Reply