WM 1.6 Eprom dump

[raz]

Probably, but this definitely will not be the end of all AFR references. The O2 probe in closed loop (in fact closed loop is something different, strictly speaking) will still give good enough results to make a perfectly running bike! That's my experience at least, please no theory bashing here.

Absolutely, I just meant it's probably more correct to call it something else. It's not O2 and not AFR. If it results in proper richening when advancing ignition, it's way way better than true AFR! Of course we should probably continue to call it AFR since many others do. Maybe just with another acronym translation, like Abracadabra Feedback Reading

 

I finally got all together and ran closed-loop for just the last 100 km before ending this season. I can't wait to continue tinkering this spring. Despite all good reports I was completely stunned with the smooth operation, even with just some more or less randomly picked target lamda (which didn't even have to be rich at all, Lambda 1.0 worked just fine in terms of smoothness). Anyway I won't let that stop me from trying to push it to its very limits, and I have no problems with remaking all mistakes Cliff, you and others already did. It's great fun anyway. Also, as you probably may have figured out, I really enjoy discussing the theories and trying to understand what is happening and why.

[luhbo]

..It's great fun anyway...

 

That's the point, and that's the reason I like the My15M so much. A wide band O2 probe and running the thing closed loop was and still is such an amazing experience for me. The more as I once had a dead bike caused by a dead OEM ecu.

 

BTW, have you ever thought of retarding the advance curve? After reading here and there a bit I think the common OEM method to reach EPA requirements is to give more advance as the engine would need (is it called EPA in the US, these environmental law bureaus?)

 

Hubert

[Cliff]

Will the sensor now show a higher lambda for the previously tuned pulsewidth (final death to all references to AFR), meaning the closed loop will take advantage of the spark advance by richening the fuel? Just like that? If so, we really have to invent (or re-invent) autotune for ignition advance

The lambda will indicate the same because closed loop will make is so. With closed loop, the spark advance is what controls the power.

 

For all the shit thrown at "02 sensors" in the Ecu thread; I've not detected any abnormal behavior from WB sensors. I currently have 2 LC1s on the Sport with independent closed loop.

[Ryland3210]

That's the point, and that's the reason I like the My15M so much. A wide band O2 probe and running the thing closed loop was and still is such an amazing experience for me. The more as I once had a dead bike caused by a dead OEM ecu.

 

BTW, have you ever thought of retarding the advance curve? After reading here and there a bit I think the common OEM method to reach EPA requirements is to give more advance as the engine would need (is it called EPA in the US, these environmental law bureaus?)

 

Hubert

 

Generally, retarding the spark from optimum power output helps pass EPA requirements.

[raz]

So one method of dynoing would be to run closed loop and only care about ignition advance versus max power. I will probably never do any dynoing but it would be interesting.

 

Another approach would be auto ignition. I did some reading on knock sensors, I'm sure I'm years behind Cliff. Apparently the industry solution is still accoustic sensors (more or less a microphone) and they need to be designed for the engine so it may be hard to find one suitable for a Guzzi. They can't say "more" or "less" but rather "this is already too much" so the normal way to do it seems to be slowly advancing ignition until you detect knocks and then retard some. The ECU need to remember (long term) at what advance it knocked. False alarms seems unavoidable and will probably be an ever bigger problem on a Guzzi. The fact any false alarm will be long remembered is not encouraging.

 

Maybe we need to let the industry come up with a better solution. Or maybe I just need a ride.

[luhbo]

...Or maybe I just need a ride.

 

[dlaing]

Dave, does your software allow you to see the injector dead time table?

I don't think so. What is injector dead time?

From what I understood of the documentation, the fuel charts show the milligrams of air, and increasing the number increases the injector open duration to make the fuel proportional to the air.

But some of the charts are simply modifiers.

Total pulse time is a product of several charts.

But I don't know what dead time is.

[dlaing]

How come?

 

Hubert

I am assumed the engineers new what they were doing.

My Mistral mufflers are not very different than the Ti mufflers.

I assumed the Ti ECU SHOULD better match my setup, but you say they are nearly identical.

I don't recollect that from reading your analysis, but that was a long time ago.

[raz]

I don't think so. What is injector dead time?

Injector dead time is the delay from the moment you powerize the injector until it's actually open. It's in the order of one millisecond. To be really picky you will have a (somewhat shorter) delay on close too.

 

Many ECU's (including MyECU now) have a table that specifies this time at different battery voltages, as it will vary. Here's a table from a car:

 

Volts			   6	  7	  8	  9	 10	11	12	13	14	15	16
Dead Time usec   2080   1760   1440   1270   1100   990   880   795   710   650   590

Here's why it's important to separate it from the map:

The altitude problem with the PCIII is a design flaw in the code. Example. A harley is tuned at sea level with a PCIII then taken to Sturgess, the owner complains it is running rich.

The reason for this is in the way DynoJet calculate trims. (I have tested this with a scope and an ECU running at a fixed RPM on a test bench).

Say you have a 2 m/s pulse.

The PCIII would add .2 m/s for a 10% trim. this is because they disregard the time it takes to turn the injector on. This time is about .8 m/s.

This means the true fuel flow time is 1.2 m/s. So .2 m/s is a 16% trim.

Now take that bike up in altitude and the pulse width drops to 1.5 m/s.

PCIII will add .15 m/s (It's 10%).

The injector dead time is constant (based on battery voltage) so the turn on time is still .8 m/s making the true fuel flow time .7 m/s.

.15 m/s as a percentage of .7 is 21%.

This means at sea level the trim was 16% and at altitude the trim is 21%.

This flaw is reduced at larger throttle openings so it mostly effects low throttle response.

[luhbo]

....

Here's why it's important to separate it from the map:

 

Read again and carefully: Wayne explains here why a PC cannot work as expected under certain conditions. This does not explain why dead time should be separated from the injection table.

 

Hubert

[raz]

Read again and carefully: Wayne explains here why a PC cannot work as expected under certain conditions. This does not explain why dead time should be separated from the injection table.

I read it again and I don't see what you mean. An ECU that does not separate dead time from the fuel map will have the exact same problem. The map value for 10 ms will read 11 ms to include a dead time. A 10% correction (for temp and pressure) applied to that will result in 12.1 ms instead of 12 ms.

[luhbo]

Ok, "rethought", the point is your's.

 

Hubert

[Phil A]

This is just a general reply to get you thinking.

With this system, ie 2d, (ie two reference points on a pre-written map) you will never get even close to ideal ignition timings. A very rough generalisation will tell you that there are two main issues that conspire to keep you in the dark.

 

One is that you need a 3d system to give you a load reading to give you anything like a reasonable figure for timing settings for any given set of circumstances.

 

The other thing is that compression ratios are a dynamic situation, ie changing with load, speed, air temp, atmospheric pressure etc, etc. and as far as i have seen there is no system which even looks at dynamic compression figures.

 

Fuel injection systems at the moment are about where carbies were in the early 1900s so do yourselves a favour, buy one of Cliffs computers, so at least you have a learning tool to have some fun with, and ride, ride, ride.

 

Regards,

 

Phil A.

[dlaing]

I read it again and I don't see what you mean. An ECU that does not separate dead time from the fuel map will have the exact same problem. The map value for 10 ms will read 11 ms to include a dead time. A 10% correction (for temp and pressure) applied to that will result in 12.1 ms instead of 12 ms.

Very good explanation.

I did not understand or agree until you explained it that way.

I don't know if the 15M has such compensation.

Wayne might know?

[luhbo]

...

I don't know if the 15M has such compensation.

Wayne might know?

 

Didn't you find his documentation helpfull, lately?

 

Look at the single maps. Pulsewidth is the sum of all of them. No multiplying of factors, so no % mistakes or arithmetical overcompensation. This way also negative compensation numbers are possible.

 

Hubert