ECU

[Cliff]

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.

This is not strictly correct. Full throttle is a mechanical limit and would provide a certain signal ( say 4.7V ).

Where this sits in the map depends purely on where the breakpoints are set.

The top of the map may be set at 4.5V in which case anything above that is only using 2 points. Or the top of the map may be set to 5V in which case it is still doing 4 points averaging.

 

Ideally the top breakpoint would be set to around 4.7 and the bottom breakpoint at the idle value. You don't want to waste those valuable breakpoints on throttle values that are not achievable. Similarly you would spread your RPM breakpoints. No point having RPM in the map going to 10000 if your motor redlines at 8000. If there is a bit of peaking/dipping in the MAP you would bucnh your break points around the peak to get the most accurate modelling.

 

Once again, I am tuning at the break points.

 

Then you would not be getting significant averaging errors.

 

The ECU is doing a weighted average. This is not a static weighted average but a weighting based on the position in the square. This is the only way you can transition a map and not have discontinuities. If you are near a breakpoint the average would be about 90% from the closest point and 10% from the other 3.

[moto]

This is not strictly correct. Full throttle is a mechanical limit and would provide a certain signal ( say 4.7V ).

Where this sits in the map depends purely on where the breakpoints are set.

The top of the map may be set at 4.5V in which case anything above that is only using 2 points. Or the top of the map may be set to 5V in which case it is still doing 4 points averaging.

Fine by me. I don't have any control over where these points are in the map (I'm certain Wayne does though, as he's provided me with base maps where these points are in different places), so all I can talk about is how the ECU behaves. However, I have not yet seen a Sagem ECU that is set up to adress more than two cells at a time at full throttle.

If there is a bit of peaking/dipping in the MAP you would bucnh your break points around the peak to get the most accurate modelling.

I have definitely lamented the fact that I cannot control where these points are. I could trouble Wayne to change them for me, but he is often very busy and the points have seemed close enough together not to bother. To that comes that you can't easily decide where they should be closer together without tuning first. If you then changed where the points are you would have to start tuning all over again. Most people have trouble affording my services as it is...

Then you would not be getting significant averaging errors.

Exactly!

The ECU is doing a weighted average. This is not a static weighted average but a weighting based on the position in the square.

Do you mean which cell I'm in of the four, or which end of the range I'm at for a given lower right cell of the four that are highlighted and therefore active?

This is the only way you can transition a map and not have discontinuities.

If there are always four cells active and the ECU only moved by one row or column at a time (rather than two), why would there be discontinuities?

If you are near a breakpoint the average would be about 90% from the closest point and 10% from the other 3.

Could be. I'm still not sure what you are basing this assumption on. Even so it's fairly inconsequential, as it just means that the ECU is averaging less than I think and that it actually wants pulsewidths that might seem strange. It's an interesting discussion, but really I'm just concerned that the engine runs right. As far as that goes, it's somewhat irrelevant if the ECU is doing weighted or unweighted averaging, or whether the engine has strange seeming pulsewidth requirements because of crossover scavenging effects, or if it's a combination of these effects.

[Cliff]

There are probably implementation differences about what cells are. For me the breakpoints define grid lines in the map. The map datapoints (cells?? )correspond to the intersection points of these grids. My base throttle breakpoint is the idle TPS value and my base RPM breakpoint is 1000RPM. So at 1000RPM idle it sits right on entry[0,0] If my next RPM breakpoint is 1500RPM and the bike idled high at say 1250RPM both cells [0,0] and [1,0] would be averaged fairly evenly. At 1050RPM cell [0,0] would predominate.

 

The map is basically a 3D object defined by a set of points. If there is no averaging the map is like a bunch houses of different roof heights ( mediterranean style ). You would have to jump up or down to get from one house to another. This is a discontinuity.

 

The averaging ( interpolation ) is basically the blanket you throw over the points to produce a " "smooth" surface. This surface is not unique and can actually take on many shapes depending on how the interpolation is done. 4 points do not define a plane.

 

I'll be seeing Wayne in a few days. He's testing one of my ECUs on a mate's Duke at the moment. I'll find out about the movable breakpoints for you. Ideally when you move breakpoints around the software should automatically recompute the map by interpolating the original map.

[dlaing]

snip, I just editted some misleading ideas

 

Does the four cell averaging work like this.

desired output for middle cell is 5 and x = does not matter:

 

x 4 x

4 5 6

x 6 x

 

or doe it work like this where the modifiers are offset rather than surrounding

5 6 x

4 5 x

x x x

 

In that case I think I now understand how it could work

[dlaing]

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

42429[/snapback]

Thanks for taking a shot at it.

Last I heard, the exact meaning of the numbers is rumored to be a secret.

Which does not help the home tuner.

In any case the bigger the number, the richer it is.

and there are some inconsistencies between the numbers and the A:F ratio.

This was what I was looking for an opinion on.

Perhaps I did not make it clear that the base map in the PCIII was all zeros.

I'll just assume the dyno operator messed up.

[dlaing]

The other thing that I still don't get is why anyone would bother to tune 2000RPMs and 100% throttle.

[Cliff]

snip, I just editted some misleading ideas

 

Does the four cell averaging work like this.

desired output for middle cell is 5 and x = does not matter:

 

x 4 x

4 5 6

x 6 x

 

or doe it work like this where the modifiers are offset rather than surrounding

5 6 x

4 5 x

x x x

 

In that case I think I now understand how it could work

42457[/snapback]

 

No its more like

 

6----5

 

..X

 

4----3

 

You have the numbers for the corners, but the engine operating in between.

The left side may be 2000RPM, the right 3000. The bottom 20% throttle, the top 30%. The engine is actually running at 2300 and 23% throttle. What should we use for X

[dlaing]

No its more like

6----5

 

..X

 

4----3

42463[/snapback]

Oh! Okay, that makes more sense, especially if it averages at varying percentage, as this really adds fuzz to the rigid logic!

Each number represents a point, not a square area.

The four points represent a square area, with effect based on proximity to the points.

Do Marelli and PCIII do the same?

[JuhaV]

Last I heard, the exact meaning of the numbers is rumored to be a secret.

42458[/snapback]

 

That's too bad, because it would certainly help people to dial in and try out corrections by themselves.

 

Perhaps I did not make it clear that the base map in the PCIII was all zeros.

42458[/snapback]

 

Yes, but with the base map I was referring to the original map in the ECU. As I understand PC does not change that map but only finetunes the control signals going to the fuel injectors. So, the control signals are always affected both by the original ECU base map and the "overlaying" PC correction map. If the PC map is all zeros, the fuel injection is solely by the ECU base map.

 

If one would know both the original ECU map and the scale of the PC map, then we could calculate the injection values in milliseconds to make them more comparable with other bikes (assuming same injection pressure and injector size).

 

Therefore it is very hard to say how reasonable the PC correction map looks if we don't know how "spiky" the original ECU map is. We can only see where the original map needed some correction, but we cannot say in absolute terms how big that correction has been.

 

br, JuhaV

[luhbo]

.... As I understand PC does not change that map but only finetunes the control signals going to the fuel injectors. So, the control signals are always affected both by the original ECU base map and the "overlaying" PC correction map. If the PC map is all zeros, the fuel injection is solely by the ECU base map....

 

42468[/snapback]

 

Some time ago Todd said here in this thread, that actual PCIII Usb's wouldn't try to fool the ecus any longer. He confirmed, that an actual PC would use the injector signal, that comes from the ecu, only for triggering its own map.

After struggling hard to stay at ball height in this thread this mentioned PC behaviour makes sense in my eyes. If a given value in the PC map would stand for a procentual enrichement, the PC would have to wait for the signal turning high, start injection, wait until the ecu signal goes low again, then add some time as given in its map and finally end the injection. While doing this it would have to interpolate between its own breakpoints also. But a PC can do more, it can also lean out the mixture. If it does not know how long the ecu injects, how should the PC subtract 3% e.g.? 3% from what time?

 

A zero map would work anyway, just putting the original signals through to the nozzles.

 

Hubert

[JuhaV]

After struggling hard to stay at ball height in this thread this mentioned PC behaviour makes sense in my eyes. If a given value in the PC map would stand for a procentual enrichement, the PC would have to wait for the signal turning high, start injection, wait until the ecu signal goes low again, then add some time as given in its map and finally end the injection. While doing this it would have to interpolate between its own breakpoints also. But a PC can do more, it can also lean out the mixture. If it does not know how long the ecu injects, how should the PC subtract 3% e.g.? 3% from what time? A zero map would work anyway, just putting the original signals through to the nozzles.

42471[/snapback]

 

Hubert,

 

I really don't have any deeper insight how the newer usb PC's work, so they may work precisely the way you describe. It makes a lot of sense. Then, the PC needs to have its own base map that is bike model specific. Dynojet needs to have some way of extracting/recording this info from some individual bike or to get it from the manufacturer.

 

br, JuhaV

[dlaing]

. If it does not know how long the ecu injects, how should the PC subtract 3% e.g.? 3% from what time?

42471[/snapback]

That concept may corroborate Wayne's contention of the PCIII losing accuracy as air pressure changes, ie. at altitude.

I believe the PCIII only subtracts or adds time, not percentage of time.

I don't know HOW it does this if it does not already know the injector duration from the ECU.

Perhaps that is the beauty of high speed electronics, it can adapt within the time frame of the injector pulse, and perhaps it need to delay the pulse a little to do this.

[JuhaV]

 

 

Attempting to find out how Dynojet stuff is really working, I took a quick look into patent databases and found these public documents that might be of some interest to some of you. US6745620 seems to disclose how Tuning Link Dynos operate. US6681752 deals with the use of wideband lambda sensors.

 

Those attachments should contain full pdf-versions of these documents.

 

Enjoy, JuhaV

 

US6745620 B2 Automatic tuning of fuel injected engines

 

Abstract:

A method and apparatus for automatic tuning of fuel injected engines includes an air-fuel ratio sensor, a load device for controlling engine RPM, a digital computer and a display device. The digital computer displays a plurality of throttle positions to an operator who sets the throttle of said engine to correspond to said display of throttle position. The digital computer varies the engine RPM over the operating range of the engine to determine corresponding map values for storage in an injector signal modifier.

 

US6681752 B1 Fuel injection system method and apparatus using oxygen sensor signal conditioning to modify air/fuel ratio

 

Abstract:

A method and apparatus for externally modifying the operation of a closed loop electronic fuel injection control system that is normally used with a standard oxygen sensor, which method and apparatus includes replacing the standard oxygen sensor with a wide band oxygen sensor. The signal from the wide band oxygen sensor is processed in a first signal- conditioning module and coupled to the input of the electronic fuel injection control system. The first signal-conditioning module simulates the appearance of a standard oxygen sensor to the electronic fuel injection control system. In a second embodiment, a method and apparatus for externally modifying the operation of a closed loop electronic fuel injection control system that is normally used with a wide band oxygen sensor, includes intercepting the signal from the wide band oxygen sensor in a second signal-conditioning module. The second signal-conditioning module receives a first current from the wide band oxygen sensor and provides a second current to the electronic fuel injection control system.

[Cliff]

I don't think the PC has its own map. How would it do the barometric compensations for altitude? Perhaps it also store the original ECU values so it see the adjustments the ECU makes.

 

I think it is % trimming. The timing issues you mention can be got around simply be using the previous cycles data.

[dlaing]

Great find Juha!

I guess they can't keep it a complete secret

And sure enough, I was wrong about it not being percentage based:

They say,"A positive value placed in a cell of the injector signal modifier 5 represents a percentage increase of the nominal value of fuel flow from the engine control unit"

But how do they determine the nominal value of fuel flow from the ECU? and what does it represent?

I suppose they use the previous cycle's data as Cliff suggested could be done, or they could store a map of the nominal injector durations from the ECU.

If they used the previous cycle, they probably would not have the altitude issue.