ECU

[Cliff]

you might suspect. Except at full throttle, the ECU is addressing 4 table positions at once at any given time. That means that for a given rpm/throttle position, there is an average of the 4 values taken. You don't tune all 4 values for a given throttle position/rpm though. Instead, you only tune one of the four because the neighboring ones would otherwise be wrong. This means that you sometimes have to use fairly outrageous seeming values for one cell in order to get that average of 4 table positions to add up to the right thing. Since you have to tune from the top down because of this architecture, there is a type of domino effect that can happen in this regard. What triggers it is cells that require weird values in order to counter the effects of reversion, differences in scavenging due to exhaust, etc.

 

You have the throttle/rpm breakpoint values from the ECU don't you? What I do is set the RPM/throttle so that you are exactly over a data point. That way there is no averaging issue.

 

What about the query I had regarding decreasing pulse width and increasing throttle. Any explaination for that or is that a symptom of the 4 point averaging.

[moto]

You have the throttle/rpm breakpoint values from the ECU don't you? What I do is set the RPM/throttle so that you are exactly over a data point. That way there is no averaging issue.

It's not a matter of being at the exact breakpoint. That is no problem. It's that the ECU is adressing four cells at any given time except at full throttle, where it is adressing two at a time. There is nothing I can do to prevent that, short of using a different ECU that isn't designed that way.

What about the query I had regarding decreasing pulse width and increasing throttle. Any explaination for that or is that a symptom of the 4 point averaging.

It's likely due to the 4 cell averaging, as well as due to various wave tuning effects, how they vary in amplitude & frequency, and how they come in or out of phase at any given throttle position/rpm. This obviously includes crossover induced scavenging effects.

[Cliff]

It not a straight average of all 4 points. At least it shouldn't be.

I have a description it here http://www.jefferies-au.org/My16M/Tuning.htm

It should be a weighted average with a greater emphasis on the point you're closest to. Thats why you position as close to a point as possible. That way it predominates and the other 3 are insignificant.

 

It's likely due to the 4 cell averaging, as well as due to various wave tuning effects, how they vary in amplitude & frequency, and how they come in or out of phase at any given throttle position/rpm. This obviously includes crossover induced scavenging effects.

 

The map was doing this at constant RPM so I would not expect it to be any resonance/wave effect.

 

If it is an effect caused by averaging, then the resulting map is not optimal outside of the points you set. The dipping at low throttle/low rpm is quite significant relative to the actual pulse duration.

[moto]

It not a straight average of all 4 points.

It may or may not be, and to me it's immaterial. What is material is that the engine runs right, and I will do with the cells whatever is required to get it to do so.

At least it shouldn't be.

You could take that up with Sagem I guess...

It should be a weighted average with a greater emphasis on the point you're closest to. Thats why you position as close to a point as possible.

You position the set of four so that the cell you are working on is at the bottom right corner (presupposing that you tune from the top in terms of throttle and from the bottom in terms of rpm).

That way it predominates and the other 3 are insignificant.

Judging from the trend of radical values being required next to cells with radical values in the opposite direction, I must disagree.

[moto]

I have a description it here http://www.jefferies-au.org/My16M/Tuning.htm

What does a description of how your ECU works have to do with the Sagem ECU found on the Futura?

The map was doing this at constant RPM so I would not expect it to be any resonance/wave effect.

Why not?

If it is an effect caused by averaging, then the resulting map is not optimal outside of the points you set.

I adjusted all points, so no problem.

The dipping at low throttle/low rpm is quite significant relative to the actual pulse duration.

Exactly!

[Cliff]

What does a description of how your ECU works have to do with the Sagem ECU found on the Futura?Why not? I adjusted all points, so no problem. Exactly!

42398[/snapback]

 

It was a description of how linear interpolation is done/should be done. For obvious reasons this is also the way my ECU does it. I would expect the Sagem to do likewise. Anyway we are not talking about the sagem ECU we are talking about a map for the Futura. A map is a function of the engine not the ECU.

 

The map was doing this at constant RPM so I would not expect it to be any resonance/wave effect.

 

Why not?

 

Because resonance/wave effect are by definition frequency(RPM) dependent. Exhausts/Inlets tend to have RPMS were they workor don't, not throttle settings ( excluding incorrect mapping ).

You can not make a pendumum swing faster by pushing harder.

 

The dipping at low throttle/low rpm is quite significant relative to the actual pulse duration.

Exactly!

Which is exactly why your zigzag mapping against throttle can't be right.

 

At constant throttle one would expect to see peaks and troughs as you vary RPM due to the tuned pipe resonances of inlet and exhaust.

 

I can see no reason why at constant RPM you would get dips/peaks as you vary throttle apart from erroneous values caused by averaging. If thats the case the map is not optimal except for the exact throttle points you set. I also doubt you would see this error on dyno because you would check by do runs at the throttle values you set. To see this error you would need to hold the RPM constant and vary the throttle. Do you do that for your tests.

 

To illustrate how average can produce invalid results if we don't tune at the breakpoints, lets say we have an array of 10 numbers corresponding to a map and the perfectly tuned values are 5 5 5 5 5 5 5 5 5 5

When you start tuning the map is 4 X X X X X X X X X

Now you start to tune midway between the first two. After your first point you have 4 6 X X X X X X X X because 4 and 6 average to 5

If we tune closer to the first number the 2nd number produced is even worse.

However assuming tuning midway you will get 4 6 4 6 4 6 4 6 4 6

If you only look at it at the midway you will see 5

[moto]

I would expect the Sagem to do likewise.

I can't help if Sagem do not meet your expectations. I have to tune with what I've got, which I don't mind a bit...

Anyway we are not talking about the sagem ECU we are talking about a map for the Futura.

Apparently in this case we cannot logically discuss the map without an understanding of how the ECU adresses the table positions.

A map is a function of the engine not the ECU.

Apparently it's not that simple in this case.

Because resonance/wave effect are by definition frequency(RPM) dependent.

If your argument was valid, reversion effects would be constant for a given rpm, regardless of throttle position. This is simply not the case.

Which is exactly why your zigzag mapping against throttle can't be right.

I'm still completely at a loss as to how you are drawing this conclusion, and my dyno runs prove otherwise.

At constant throttle one would expect to see peaks and troughs as you vary RPM due to the tuned pipe resonances of inlet and exhaust.

And we're seeing those, aren't we?

I can see no reason why at constant RPM you would get dips/peaks as you vary throttle apart from erroneous values caused by averaging.

You could be right, except for the erroneous part. You might be able to find a basis to argue that your architecture is in some way superior to the Sagem architecture, but to call the averaging erroneous is problematic. If the ECU adresses four table postions at a given time it has to average. If they did not want it to average, why wouldn't they just have it adress one cell instead of fooling around with four?

If thats the case the map is not optimal except for the exact throttle points you set. I also doubt you would see this error on dyno because you would check by do runs at the throttle values you set.

The throttle positions I use are determined by the the values in the tables.

To see this error you would need to hold the RPM constant and vary the throttle.

There is no error, because there is no time that the ECU is not adressing four table positions at a time, except at full throttle. Actually, I take that back. There is no error that would not be there if the ECU was designed to access one table position instead of four and the values were not averaged by the ECU amongst those four.

Do you do that for your tests.

I don't generally do sweep tests, because they don't tell me as much as step tests, but I have another Futura in that I could do this with. I see little point in it though...

To illustrate how average can produce invalid results if we don't tune at the breakpoints,

Once again, I am tuning at the break points.

lets say we have an array of 10 numbers corresponding to a map and the perfectly tuned values are 5 5 5 5 5 5 5 5 5 5

When you start tuning the map is 4 X X X X X X X X X

Now you start to tune midway between the first two. After your first point you have 4 6 X X X X X X X X because 4 and 6 average to 5

If we tune closer to the first number the 2nd number produced is even worse.

However assuming tuning midway you will get 4 6 4 6 4 6 4 6 4 6

If you only look at it at the midway you will  see 5

Ok, I think I understand where the problem is. If I were to tune out of sequence, i.e. tune two places and then tune in between, you would be absolutely right. I would then have a mess. But as explained before, I'm tuning sequentially top down in terms of throttle position and bottom up in terms of rpm (or left to right, depending on how you're looking at it), and I can't really go in and "touch up" anything afterwards (not a problem, no need to).

[JuhaV]

If you are asking if I would have the same looking map tuning on a different occasion, the answer is very likely no ...

 

... This means that you sometimes have to use fairly outrageous seeming values for one cell in order to get that average of 4 table positions to add up to the right thing.  Since you have to tune from the top down because of this architecture, there is a type of domino effect that can happen in this regard. What triggers it is cells that require weird values in order to counter the effects of reversion, differences in scavenging due to exhaust, etc.

 

As far as the map only being good for the conditions on that day, I assure you that runs are quite repeatable from one day to another...

42391[/snapback]

 

Yes, that was my question. I have some difficulty understanding that having those "outrageous " values in the map is really an acceptable thing, because as Cliff has pointed out, the ECU is most propably doing some weighted interpolation whenever defining values between the breakpoints.

 

Another thing is that you say that you would not achieve "a same looking map tuning on a different occasion". It sounds a bit peculiar to me to see that even if you are claiming to tune with very high accuracy for power, then the actual final outcome, the map, will be different in different tuning occasions.

 

br, JuhaV

[dlaing]

So to deal with the averaging and to get the output to match a non averaging map of say 123454321

His map would have to look like 023454320 which is not an exact match, but close enough.

A more complicated example might be to match say 2 8 7 3 2 5 5 9 he would have to enter -4 6 14 -6 Oh, I give up, this is too hard and this is only the wide open throttle averaging.

I think Cliff should make Sagem replacements!

For the third time, does anyone want to comment on my 'Moto Guzzi's' tuning link map?

It too, has many spikes, and as far as I know, averaging does not take place. Also it does not seem to match the A:F readout.

[dlaing]

again here is the data, not as pretty as MOTOLABS 3d graphs:

0 2 5 10 20 40 60 80 100

500 0 0 0 0 0 0 0 0 0

1000 0 0 0 0 0 0 0 0 0

1500 0 26 23 14 27 11 17 20 20

2000 0 0 17 0 5 -3 -2 -12 2

2500 0 0 15 17 -2 2 9 3 17

3000 0 0 0 20 1 17 15 21 29

3500 0 0 0 11 5 3 15 11 15

4000 0 0 0 17 7 1 14 22 24

4500 0 0 0 18 13 4 9 15 4

5000 0 0 0 18 20 4 -3 -6 -1

5500 0 0 0 0 24 1 -6 -7 -4

6000 0 0 0 0 0 1 -8 -6 -7

7000 0 0 0 0 0 -2 -2 -13 -10

8000 0 0 0 0 0 0 -3 -14 -17

[moto]

Yes, that was my question. I have some difficulty understanding that having those "outrageous " values in the map is really an acceptable thing, because as Cliff has pointed out, the ECU is most propably doing some weighted interpolation whenever defining values between the breakpoints.

I think I'm beginning to understand another part of the misunderstanding here. At full throttle, the ECU adresses and averages between two horizontally adjacent cells. If you were tuning from low rpm to high rpm, out of the two, you would always be tuning the one to the right. You would never tune one that did not have an active cell next to it that you had not already tuned (except for the very first one). At any other throttle position besides full, the ECU is always adressing and averaging between four adjacent cells, but this is four in a square, not in a row. If you were tuning from the top down in terms of throttle position and, as before, from the bottom up in terms of rpm, you would always have one active cell above, one to the left, and one diagonally above and to the left that you had already tuned for any cell you were currently tuning. Therefore, whether or not the ECU "weights" any of the cells is irrelevant.

Another thing is that you say that you would not achieve "a same looking map tuning on a different occasion". It sounds a bit peculiar to me to see that even if you are claiming to tune with very high accuracy for power, then the actual final outcome, the map, will be different in different tuning occasions.

It's not so peculiar when one considers that the ECU is adressing and averaging between 2 and 4 cells at any given time. Think about how many different combinations of values in four cells can provide the same pulsewidth. If you started with a slightly different value in the first cell you tuned, the adjacent cells would have to be different in order to end up with the same pulsewidths as before. This would result in a cascading effect throughout the table.

[JuhaV]

For the third time, does anyone want to comment on my 'Moto Guzzi's' tuning link map?

It too, has many spikes, and as far as I know, averaging does not take place. Also it does not seem to match the A:F readout.

42422[/snapback]

 

Well, I am not familiar with Power Commanders, but I think that we would need to see both the original map from the ECU together with this PC map in order to know what the "effective" map really is. As I understand this PC map somehow multiplies or adds with the original map point by point ?

 

So if we have in the original map at 5000 rpm & 50 % throttle value x and the PC map has in the same spot value y, the effective fuel injection value is x +y, or more propably something like x + x*y/c.

 

If those PC map values are %-values (c=100) which would make some sense, then if y = 10 we would have simply x + 0.1x., i.e. 10 % enrichment. If y=0, there is no change. With negative y-values we would lean the mixture in similar manner.

 

What comes to averaging, I think that there needs to (or should ) be some interpolation because the PC map seems rather coarse. There are not so many breakpoints in the throttle or rpm values.

 

If you know the "scale" of those PC map values it would help to understand does a value, for example, 26 in the map mean 26 % enrichment (sounds like too much) or only 2.6 % enrichment (sounds actually somewhat more reasonable).

 

Maybe this info is available somewhere in PC www-sites.

 

br, JuhaV

[JuhaV]

At any other throttle position besides full, the ECU is always adressing and averaging between four adjacent cells, but this is four in a square, not in a row.

42425[/snapback]

 

This is the way I have been thinking all the time. This is also very clearly explained at Cliff's www-site.

 

Therefore, whether or not the ECU "weights" any of the cells is irrelevant.

42425[/snapback]

 

Nope. This is important because to get it correct you need to move along the breakpoint lines when tuning. Breakpoint lines are going vertically and horizontally via the corners of that square those four adjacent cells are forming.

 

If you don't do that and you tune somewhere inside that square, then you will change one of the four corner cell values in excess to get the average at your tuning point somewhere inside the cell correct. When you then move within that square in a different location, you will get an incorrect average value.

 

It depends then on the amount of rpm and throttle breakpoints how big error there will be.

 

br, JuhaV

[moto]

Nope. This is important because to get it correct you need to move along the breakpoint lines when tuning.  Breakpoint lines are going vertically and horizontally via the corners of that square those four adjacent cells are forming.

I am moving along the breakpoint lines.

If you don't do that and you tune somewhere inside that square, then you will change one of the four corner cell values in excess to get the average at your tuning point  somewhere inside the cell correct. When you then move within that square in a different location, you will get an incorrect average value.

As explained earlier, I'm not tuning the cells in the square at random, but tuning sequentially, always the one of the four I have not tuned beforeand always the cell in the bottom right corner of the square.

It depends then on the amount of rpm and throttle breakpoints how big error there will be.

There could only be an error if I was not tuning strictly sequentially, skipping cells, and/or the ECU was advancing through the table at more than one cell at a time per breakpoint while adressing the four it is averaging. I wish I could explain it so it could be more easily understood. If it still doesn't make sense, maybe some screen shots would help?

[Cliff]

I think Cliff should make Sagem replacements!

I actually do have an ECU that I made for an Aprillia twin. Couldn't tell you which one as they all look the same to me. Had twin sparks. Got it to the stage where it would run for about 5-10 seconds. When I get some more free time I'll finish it off.