moto

Even spending less than that, I think an O2 sensor-based improvement is highly unlikely. What reasoning is this statement based on? In my opinion, if a tuner worth his salt (with access to proper equipment of course) does a half decent job tuning (say by hitting a CO target via one to three iterations per cell) for either horsepower or fuel economy, or a balance of both, closed loop operation stands a very slim chance of improving anything. Remember that the varying conditions such as altitude are adressed by other ECU inputs, which means that an O2 sensor is redundant for this purpose. Maybe they have, but that's not why I don't think they are a good idea. I strongly disagree. Well, if it's economy you are after, you really need to look at BSFC, for which the use an O2 sensor is not a substitute. Why would Cliff's optimizer produce better results than a tuning link map? A couple of points to remember: A/F ratios are at best only loosely related to O2 content. If you use either of these as a target for tuning, the target must be decided upon by some method. The result will only be as good as the viability of the target. You can hit the target while having stagger and/or retarded ignition timing problems. In the case of a stagger problem, the ECU/tuner/autotuning software will add fuel, which will result in one cylinder being sort of in the ballpark and the other one being rich, loosing more power and economy than one cylinder slightly rich and the other one slightly lean would have resulted in. In the case of ignition timing, the O2 will be high, while the mixture could be perfect. The ECU/tuner/autotuning software will add fuel, loosing more power and economy than the retarded timing alone would have resulted in. You can hit a reasonable looking O2 target with a CO percentage ranging from ~2 to ~11% (without stagger or timing issues). Regards, Derek

I noticed that there don't seem to be separate left and right fuel tables. Is it possible that "offset" is to correct left/right stagger problems? I'm wondering if this might be the case because in Tunedit for Triumph and Aprilia, the preferred table for tweaking fuel is called a "trim" table and then there is a function under "tools" called "commit trims to main tables" (except when in realtime mode). Regards, Derek

If you are going to do that, one side of the nut should have a radius matching to the pipe's O.D. machined on it. There should be no gaps to fill or bridge with rod. The thickness should be such that if you take the sensor out and install a plug, the plug's inside face sits tangent to the inside of the pipe. It's a good idea to use stainless steel so the bung and weld seam do not corrode. Regards, Derek

The 10mm bungs are designed for use with an EGA. Regards, Derek

Why would you want to go and louse up a perfectly good map with closed loop? Regards, Derek

I disagree with Cliff that you can rely on closed loop operation via an O2 sensor to properly tune the maps. Rather than buying another ECU which still ultimately needs optimization on a proper eddy current brake equipped with a 4 gas EGA, I recommend tuning the existing ECU via TuneBoy or TechnoResearch software. Regards, Derek

I charge $150 for a TechnoResearch hardware key (which I stock), and $17 to load a pre-existing map. The tuning cost depends on how many throttle positions are tuned, whether the left and right are tuned individually, whether I tune the spark advance, whether I tune to best HP or to a CO target, and to what resolution I tune/how many iterations I am allowed. Regards, Derek

Your dyno people have fuel and air flow meters? I suppose these are connected to a data logger and a computer calculates the A/F ratio as you go? Regards, Derek

Im am happy to announce that I am now able to tune MM-IAW15M ECUs via Direct-Link and have keys for Moto Guzzis in stock at $150.00 each. Regards, Derek

Why would you go back if they won't even deign to communicate with you? Except that I'm not convinced that the amount of time required for a stable reading is the same at every throttle position/rpm. Not by merits of being an inertia run per se, but certainly by merits of being a DynoJet inertia run.

Sorry it took me until now to respond. If we assume the "A/F ratio" graph actually shows mixture strength, as well as that the graph should be relatively uniform for proper running, then, at first glance, the mixture strength in the graph appears to be "all over the place". Contrary to my earlier speculation, the DynoJet patents for "Autotuning" imply that all tuning is done in steady state and that the computer either hunts around until the correct "A/F ratio" is achieved at a given throttle position/rpm, or, it records the "A/F ratio" and performs a calculation that will yield the theoretical offset required to hit the desired "A/F ratio" target. The chart you posted looks like an inertia run. The first thing I wonder is why, if the tuning is done steady state, is the graph you have not from a steady state run? Is it possible that a steady state run would show the desired "A/F ratio" across the board, and that we are simply looking at some type of response time related issue? Or maybe the "Autotuning" was done by the latter method, and that offset the computer calculated simply didn't translate to the real world? Maybe the operator knew that the engine runs better at what , in places, seems to be an unreasonable "A/F ratio"? Can you asked him/her about any of this? I would be curious...

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. 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... Exactly! 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? 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? 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.

I am moving along the breakpoint lines. 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. 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?

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. 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.

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... Apparently in this case we cannot logically discuss the map without an understanding of how the ECU adresses the table positions. Apparently it's not that simple in this case. If your argument was valid, reversion effects would be constant for a given rpm, regardless of throttle position. This is simply not the case. I'm still completely at a loss as to how you are drawing this conclusion, and my dyno runs prove otherwise. And we're seeing those, aren't we? 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? The throttle positions I use are determined by the the values in the tables. 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. 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... Once again, I am tuning at the break points. 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).

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!

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. You could take that up with Sagem I guess... 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). Judging from the trend of radical values being required next to cells with radical values in the opposite direction, I must disagree.

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. 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.

Hmm, I'm not sure how the values stored in the ECU would change from day to day, nor do I have any idea how I would tell, besides copying the tables out of the ECU and having a look at them. If I did that, I assure you they would be the same, as the corrections for ambient conditions do not alter the original values. If you are asking if I would have the same looking map tuning on a different occasion, the answer is very likely no, but not for the reasons 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. 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. If you need further convincing, look at the CO numbers again. They are quite reasonable regardless of the ambient conditions they might be measured in and will not change radically from one type of conditions to another. Radically different CO numbers are also not required for varying conditions. Whatever slight variation is required, I'm sure the ECU handles just fine, as otherwise my runs would not be as repeatable as they are.

Certainly they are repeatable, as they refer to the pulsewidth at that throttle position/rpm and not to a measured exhaust gas content. However, the resultant upper and lower CO limits throughout the map are ~ 2.5 to 5%.

One of the problems with two into one systems and most systems with crossovers on uneven firing engines is that you inevitably have to map the two cylinders independently to get good results. If this is not done, it could contribute to the vibration you are noticing. The Futura with its AF1 h-pipe had very different requirements front to rear. Check out the final maps here:front and rear to see what I mean.

I'm not sure I understand how the Vern's richer chart negates my point. Can you explain further?

Differences in pressures on the tops of the pistons are essentially immaterial when compared to the inertial forces exerted by the reciprocating and rotating masses. With a two into one or a system with a crossover on a v-twin, one cylinder will always be scavenging better than the other at any given time. I should have said not "whether or not", but "how much" in my previous reply.

Check the second chart down between 4750 & 5200, 6500 & 6700, and 7200 & 8500 rpm. In these areas, the engines make exactly the same power with fairly divergent "A/F ratios". Then in the first chart, the same HP is shown in the same areas with the same "A/F ratios". This does reinforce the apparent problems with "A/F ratios", unless one were to argue that the one graph in the second chart was lean while the other was rich and by an amount that coincidentally produced the same power.

That's not really a mistaken belief, because whether or not an assymetrical flow is created depends on the length, placement, and diameter of the crossover. Sometimes this is done deliberately in order to broaden the powerband. Agreed in general terms, but on a vee twin, secondary pipe diameter is critical with two into ones due to the uneven firing.