Lambda Or Not?

[petert 549]

...... Running closed loop lambda control on aftermarket ECUs isn't as easy as it sounds to get right and can often spoil the smoothness of a good map.

 

Sandy raised a good point here. Whilst running closed loop is great for mileage and keeping the cat happy, it's really not that great in getting the best out of a well mapped engine. Below is the target AFR map for my road car. Notice how I've gradually richened the map as the load increases, from 14.7:1 at light throttle through to 13:1 at full load (WOT). If I turned on closed loop without any customization, the ECU will maintain 14.7 almost all the way to 0kPa (WOT). You can really feel it spoil the crispness of the mapping.

 

My software has the ability to set a limit for closed loop, by either MAP or TPS. Thus in the example, O2 will turn off if the load goes above -40kPa or 50% throttle. Most factory ECU's will maintain 14.7:1 all the way until you reach WOT.

 

If you're trying to get every last mpg out of your 205, then sure do it. But if your 205 is for driving pleasure, don't get hung up about having closed loop. Just make sure it's well mapped. Or at least look for custom options in your software.

[B1ack_Mi16 67]

What ECU are you running?

 

I'll have to choose an ECU setup for my 2.2 T16 405 in not too long and could need some advice on what is recommended for a turbo engine.

For example I'm not too convinced the Emerald is the right choice, even thought it seemed to be quite ideal for a TB'ed NA setup.

[petert 549]

I run a Haltech Sport 1000 in both cars. The Sprint 500 will also do custom closed loop O2 control but it won't do closed loop boost control like the 1000, which is nice on a turbo. I use to run a 500 in the 205 track car, but I wanted full data logging and oil control, so moved up to the 1000.

[brumster 135 1 Cars]

Completely agree, I tended to use the closed loop to get somewhere in the ballpark, but on the EFI ECUs you have a similar set of configuration options that limit how much the self-learn will adjust the base map (or rather, the learn map). Anyone who basically put their ECU into a configuration that gave it free reign to alter the fueling by any degree it wished will almost certainly screw up a perfectly good map - my understanding is that the lambda sensors, and the control/interfaces between them and ECU, all take a small degree of time to stabilise on a reading, so if the ECU takes any value it sees as gospel without first averaging it over a period of time (or waiting for it to stabilise) is probably going to misconfigure the adjustment?

 

In the interests of knowledge sharing the configuration options in the EFI software are horribly named and hidden away in the software compared to the likes of Emerald or your Haltech stuff. For example, there is a section called "Lambda Calibration - Self-Learn" but it's actually got nothing to do with wideband self-learn, and is only related to narrow-band lambda sensors and idle AFR!

 

The relevant settings are :-

d(TPS%) transient - this controls how much transient throttle delta (ie. change) is allowed before self-mapping is disabled. So if the throttle is changing rapidly, the ECU will not enable the self-learn strategy. You can't map on a fluctuating throttle.

 

Target error - how close to the target lambda value the actual measured lambda value needs to be before you consider it 'close enough'. Obviously a large value here is pretty pointless. The default is 0.008.

 

Integral fuel correction step (%age) - The ECU makes a correction every 100ms and it will only correct the current fueling by + or - this percentage. I use 1% for initial runs where I suspect the fueling is way out, but then typically put it down to 0.1 or 0.2 for fine-tuning... given you can hold a load-site on the road for a good few seconds, that's plenty of options for correction.

 

Maximum allowed fuel correction - this is the important one! This defines a %age limit by which no fuel adjustment will exceed, either + or -. The default appears to be 10% on the base maps I've seen. I'll admit, though, I've upped this to 20% or more on occassion when the base map has been a long way out. Other alternative is to leave it at 10% and do lots of runs, refining the map as you go.

 

Without a rolling road, it takes a long time and a lot of fettling/data logging to get the map how you like it.

 

edit: ... and then turn it off, like Peter alludes to

Edited December 10, 2013 by brumster

[welshpug 1,621]

This kind of highlights the time and money OEMs invest into ECU systems, and how sophisticated and o.e ecu is over most aftermarket ecu's.

 

just had a look how much a 207 S2000 ecu is listed at, £3800 on its own, but with the update and all the fixings etc its nearer £7.5k.

Though a 208 R2 ecu is only £1200, quite an odd difference !

Edited December 10, 2013 by welshpug

[Sandy 189]

Most systems available niow have an AFR table and the ability to limit the correction range and the rpm/load band band in which changes are accepted, along with correction tables that can temporarily or permanently adjust the main fuel map values, that's not the problem. The problem is two fold really, firstly the basic concept of aiming for rigid pre-defined AFR values and secondly the effects of the adjustment in reality. As always with issues this complex, it would take an epic amount of writing to fully explain and demonstrate my experience of this and most of it can be casually dismissed by theoretical chat and pocket science; all I'm interested in is explaining the reality (in my experience) of the issues.

 

Firstly it's important to get away from the idea that "perfect" AFR values are necessary. If you're trying to run a Cat efficiently for emissions performance, then yes they certainly are and in that there is an indication of the folly of Cats as emissions devices; since they became mandatory they have stifled progress in evolution of the efficiency of road car engines, but as long as they provide a substantial income stream for precious metal American mining industries or a new scam is dreampt up, that's unlikely to change. Fortunately most of the cars discussed here are free of that restraint, so it can be largely disregarded.

A mildly cammed and generally standard engine will likely generate very stable and consistent ideal fuelling requirements throughout the map, with no dramatic changes needed from site to site and a stable transient fuelling response. In this case, it's really pretty easy to map the ECU, you may even be able see a budget/DIY type ECU being able to smoothly manage it and making the closed loop Lambda control work shouldn't be too tough. Move towards a more performance orientated engine, with nastier cam choices, the rapid rise and fall of air delivery from ITBs, fuel drop out from outboard injector locations and hugely irrational crests and troughs in fuelling requirements both steady state and transient; the mapping becomes alot more difficult to resolve well, simple AFR values do not apply consistently with speed and/or load, so it's impossible really to target it.

 

The second part of the problem as I said at the top, is the manifestation of applying closed loop control in reality. With a mild smooth engine spec, you can with some care about the settings, get it to work pretty well with most systems, but not always, so assumptions about that shouldn't be made. Even then, as I found with my "Eco spec" 1.1 road 205 a few years back, don't expect it to outperform a well configured open loop map in terms of economy, I saw no improvement in economy on that running closed loop and ditched it because it affected the smoothness of the driveability as it created holes in my very well honed map, I went all around the houses with it and the only way I could make it work reasonably well, was by making the main maps and transient settings slightly richer to compensate, how perverse is that?! The problems I've encountered with doing this on race engines have been alot more severe and whilst a few moments of overly lean or rich fuelling on a road engine might be tolerable, on a race engine, it's more likely to mean destruction.

The saved corrections will turn a smooth bed of silk fuel map into the Himalayas. Even with good interpolation and progressive, nicely written site by site values; as the ECU moves accross the sites, the fuelling error will vary, because the changing fuelling requirement will be not match the ECUs injector time perfectly. The idea is obviously that the closed loop control will check the disparity between the Lambda target and the Lambda feedback, make an adjustment, re-check, make a finer adjustment and so on, by PID loop control. In a steady state condition, this operation is near ideal and it's a simple maths problem, which is what computers do best. Even when this is working ideally, the correction required will vary across each site horizontally, vertically and therefore logically diagonally. So the correction needed on each site varies across the site. When a good mapper is writing the map open loop, he will be able to observe this variation and judge what a good mean value is for the site, singly and as part of the group of the eight sites that surround it. The closed loop control however can't have that vision and will have to correct what it sees, which is ok if it lands on the site the same way each time, but it won't so the window for adjustment needs to be narrowed, hence a band of say 10% speed and load from the site's assigned values needs to be set to consistently record corrections. That band unfortunately in turn relies on the speed load site assignment being well staggered to work with the areas in which the engines largest air/fuel requirement changes occur, back to the quality of the original map again. Errors will occur in all of this, because we don't have the months of testing manufacturers employ to get it right, so the saved corrections are inevitably spiky and as they're applied, they affect how the sites around are corrected due to the wander from the time interval and the effects can become very exagerrated. I've seen some spectacularly bad examples of this. The problem exists in the steady state condition, but is usually masked, ironically, by the closed loop control and might not be that apparent while cruising, but try to map this way and you'll end up with a right hotch potch.

The problems get much worse in transient conditions. Transient fuelling compensation with ITB engines usually needs to be quite coarse and you have to be pragmatic about it in most cases, ie accept that the AFR won't be perfect and this is a good point to raise the problem of when should you trust the Lambda reading? All a Lambda basically does is measure the oxygen content of the exhaust and from that a theoretical AFR value is calculated. I say theoretical, because it's not measuring the actual AFR value when you account for unburnt fuel, soot or oil consumption or even added water mist in some cases. When a Lambda value appears to go lean, what it actually means is it's seeing a high unburnt oxygen level, which can be for a range of reasons beyond insufficent fuel being injected. The transient problem is based on the fact that the fuel injection will not keep pace with the air delivery into each cycle as it changes with speed and throttle movement. The basic theory is that if the ECU detect rapid throttle opening, it responds immediately by adding injector time to cover the expected increase in air delivery. The reality of this in a tuned engine, is that the fuelling will not faithfully match the air delivery, either because of the accuracy in the values or more significantly because fuel is dropping out (condensing), getting thrown straight out the exhaust on overlap, there is a difference between cylinders in the change of air delivery (but fuel is being injected equally) and it can appear that the engine is lean overall, when the fuelling on one or two cylinders may be actually too rich to burn properly and show a sensible Lambda value. This is a good example of when mapping by feel and experience is way more sensible than trying to stick to a rigid Lambda reading. The problem for correction is, if it's too sensitive, it will over-compensate, most likely in the wrong direction! To work around this, the control will rely on sample rate and the PID sensitivity to ignore such conditions, but the more you dial that out, the laggier and more pointless the correction becomes. Unless it's very well resolved, you'll often get lean flatspots created by the Lambda control. The first few degrees of throttle movement presents similar problems and is often set to run open loop as a result.

 

As you can gather I'm highly sceptical of the value of running closed loop Lambda control, through experience and not without extensive attempts to get it right. I could go on to explain the frightening situations we had on the engine dyno with a very expensive Duratec (largely a management demonstration by a specialist), trying to show us how we could simplify mapping with more expensive management and closed loop control; also the absolute insistence by the EFI supplier, that I didn't need manual live adjustment when mapping, "this is 20 years ago...", my manually written open loop map on that particular race car knocked over a second and a half off his best ever Castle Combe lap time and dropped his race fuel consumption from 1.2 litres/lap to 0.7litres/lap.