VVT Diagram

STP Technical Class: Connecting Functions – Closing the Loop

 Pavlotech has been truly helpful by working along with STP and letting us share his content with you through our Blog. If you want to take a look at his original post click HERE

Connecting Functions – Closing the Loop

Engine efficiency can be influenced by a number of factors now.  Not just manifold pressure, throttle position, temperatures, or other basic variables.  An engine with variable cam timing introduces significant dynamics to engine efficiency for example.  The OE ECU systems in modern cars can be very complicated in the nature of conventional mapping.  This is because of the way connected functions are layered throughout the efficiency model.  It makes deep re-calibration efforts on a factory solution extremely challenging sometimes.  It also validates the need for an aftermarket control system that has the flexibility necessary to achieve what is necessary for that situation.  On top of that, the “failure” mode for some of these functions must be thought out and planned for.  Mostly in order to meet emissions compliance at all times.  

Simplicity is a selling point for motorsport EFI solutions in the aspects that performance will be consistent and reliable.  However, now that these EFI solutions are supporting original functions like cam control, drive by wire, and more – some extra thought and effort regarding completing the calibration process isn’t a bad idea.

I had the pleasure of diagnosing a motorsport EFI system that had a control failure regarding VVT recently.  This particular car had a very aggressive system that had the ability to add a total of 100 degrees worth of extra overlap if needed (between the two cams).  The failure was from a wiring issue which was not allowing one of the camshafts to move to the commanded target.  Seems like a minor issue, but the effect it had on the engine performance was staggering.  At certain RPM points, the mapping was so far off the engine would misfire.  This was due to the mapping expecting a certain efficiency point the engine was nowhere near due to the position issue.  The system was calibrated with the camshaft control system functioning normally, which is typical when using these EFI systems.  While it was a simple problem to identify ultimately once data was reviewed, the way the problem was described initially had the team on a wild goose chase initially.  

The problem got me thinking it was a good idea to write more about developing calibrations that are dependent on these control systems ability to affect engine efficiency (similar to the OE).  While I approach every project with this kind of mentality (to truly offer a “completed” package), it is important to not over complicate as well.  Too many connected functions like an OEM ECU could arguably create situations where I, or someone else, wouldn’t be able to calibrate the package easily.  

This could defeat the purpose of the aftermarket system that is potentially replacing the original EFI system.

The EMtron ECU has the ability to write multiple tables for many functions, offset them with other tables, connect them based on other runtimes, and more.  This ECU functionality is key to the concept.  It validates the need for proper control of these systems on more modern engines as well.  

The car chose to proof the concept, in this case, was a BMW E36 M3.  The engine is very simple but it does have a rudimentary cam switch function that affects engine efficiency.  When these BMW 24 valve engines came out, the first couple of years did not have any cam switch function at all.  This made the power delivery of the engine very “peaky”.  It made the engine less flexible in the aspects of everyday use (especially with automatic transmission).  Adding the cam switch function allowed BMW to improve low-end torque by advancing the intake camshaft in the medium engine speed range.  This is commonly referred to as BMWs VANOS system.  

The Emtron ECU also supports almost every BMW trigger configuration as a predefined setting for easy use.  This allows the VVT configuration to be used (instead of cam switch if preferred) which allows much more flexibility, even stepped positioning.

** Stepped positioning  (a feature not used by the OEM on this platform) in this example was not used, as the total camshaft travel was not enough to provide an advantage.

What most people don’t know is how sloppy the actual cam position is vs the commanded switch function.  More specifically on 15-second dyno passes, the cam position is offset by almost two seconds vs the cam switch command itself.  

Cam_Switch.PNG

The top plot shows actual cam position

Center plot shows RPM

The third plot shows the switch function being commanded on (high) and off (low).  

To put it simply, it’s lazy to get to there, and lazy to return.  It is unlike other camshaft systems that have an instantaneous operation that some may be thinking about.  This presents challenges to the calibration process regarding consistency due to the fact that the switch condition is affected by the transient acceleration of the engine, oil temperature, and other factors that influence the speed of which the cam actually moves.  

Two problems that needed to be solved by connecting functions.      

Have the calibration be set up for the different efficiency situations created by the cam position.  

Have the calibration switch/blend dependent on the actual cam position, not the commanded switch function.   This would make the calibration optimal under all camshaft positions, allow for more flexibility regarding the switch conditions (not just RPM dependent), and provide a failure mode just as the OE systems do.

Closing the loop.  

I ended up with two fuel maps, two ignition maps, fancier injector timing maps, and some tables that facilitate blending the tables together.  These were based on the actual camshaft position runtime.  Because this is a “simpler” engine with a limited range of camshaft travel, there was no need to add any breakpoints (meaning more tables) to the function.  

VE1_Vanos_Off2.PNG

Cam position retarded.  You can see the peak VE (torque) comes at higher rpm.  

VE2_VanosON2.PNG

Cam position advanced.  You can see the VE is much higher and earlier in the RPM range.  You can also see the VE drop significantly at higher revs validating the need to advance the cam in the midrange, but ultimately retard it at higher RPM to achieve maximum torque and peak HP.

IGN1_Vanos_Off2.PNG

Ignition with the cam retarded.  In the medium speed range, the engine reaches MBT at higher advance due to the efficiency change.  Exploring this situation greatly improved the response of the engine during transient conditions where the VVT was switching on and off (new conditions added based on engine load).  

IGN2_Vanos_On2.PNG

Ignition with cam position advanced.  You can see MBT is reached in the medium speed range with less advance.  

** due to time constraints, the top end advance for MBT was not explored even though the efficiency drops significantly.  In any case, the advance would be slightly and safely retarded in a “failure” event.  

Z-Axis.PNG

This is the blend function for tables based on cam position (same for both ignition and fuel).  It uses the Emtron Z-Axis function that interpolates the blending of tables in between the breakpoints.  This effectively closes the loop on the map changes as the mapping is automatically switched and blended based on the live camshaft position.  The deadband added to the min/max travel of the cam position was validated with the dyno to ensure the best interpolation between the tables on this platform.   

Inj_Timing.PNG

Finally, I had a few minutes to explore some “failure” modes and attempted to get the engine to idle with the cam advanced.  Retarding injector timing helps with fueling in high overlapped conditions which helped immensely here.  The result was actually a very clean idle with the wrong position.  The factory ECU for this car will not even run at idle if the cam is stuck advanced.  

Evaluating the calibration once everything was done was very easy.  I essentially enabled the connected functions described above, chose the optimal cam switching points (which were obviously based on looking at torque logs and the dyno plots) and had to make no changes whatsoever.

Log_Cam_switch.PNG

  • Actual cam position in the top plot.  
  • RPM in the second.  
  • Throttle in the third.  
  • Cam switch activation in the fourth.
  • Lambda in the fifth.

 

You can see that generally under load the mixture is on target (closed loop disabled here, low RPM needs to be cleaned up), especially during the transient event when the cam switches off and the position “trails” off back to the retarded position.  The areas of the log where the cam is moving is where the connected function is doing its job.  The higher RPM spot is where it is difficult to maintain consistent mixture and prevent knock on this platform.  Logging ignition advance with all of the functions working was much smoother than calibrating the conventional way.  This matched the torque curve of the engine which was also smoother and consistent regardless of transitional cam position conditions.  

Torque.PNG

There is also no noticeable change in torque during the transient period, which is common without a closed loop function on this application.  

So how much more difficult was added?  Dialing in a couple more tables is not the end of the world as long as the calibrator understand the connected functions.  

 

Back to blog