Sharpening the VVC Response

[revilla]

Download Link: http://andrewrevill.co.uk/Downloads/MEMS3Tools.zip

Making the VVC mechanisms respond more quickly.

I was recently contacted by somebody with an Elise with a MEMS3 VVC 160 engine from an MGF Trophy. He was suffering from a lack of top end power. As I was on holiday at the time I couldn’t really look at much, but I did get him to use the high speed data logging facility in MEMS3 Mapper and send me the logs so I could see if anything looked obviously wrong. Something didn’t seem right. To cut a long story short, it was actually quite normal for the standard VVC engine and nothing to do with the problem at hand, but still something I wanted to look at.

THE ISSUE

The graphs below illustrates what I was seeing. The blue line represents the requested VVC inlet cam duration, that is the inlet cam duration that the ECU was trying to achieve. The orange line represents the measured VVC inlet cam duration, that is the inlet cam duration that the ECU was measuring using the signal from the cam position sensor. As you can see, when the ECU was demanding a large deployment of the VVC mechanisms, they were very sluggish in reaching their target duration. The initial response was rapid, but they then crawled slowly open to their final position over 3 to 4 seconds. Especially in the lower gears when the engine speeds and demands may change rapidly, this meant that the VVC system was lagging well behind the demand and was not delivering optimum torque.

When I got back from my holiday, I set about data-logging my own car. My engine has only done a low mileage since built with a full set of brand-new VVC mechanisms, including all of the hydraulics, so I had no reason to believe that mine would be sticking or sluggish. But the results were pretty much EXACTLY the same. In fact, the graph below is from my car. This got me thinking that this must be the built-in behaviour f the VVC ECU in some way.

INVESTIGATIONS

I set about investigating what was going on in two ways.

Firstly, I used my Research Engine Simulator. This is a big project that I still have to write up and publish, but basically it’s a box of microprocessor-controlled electronics that connect up to the ECU and simulator the behaviour of the complete engine. This includes mathematical models of the MAP and the VVC mechanisms. The ECU just doesn’t know it’s not actually running an engine, it runs completely normally without logging DTCs. Crucially it allows me to run the ECU through any scenario that I could set up on the road, but I can run the same scenario repeatedly, exactly the same every time, on the bench. I can simulate idling, misfires, rev limiter, overrun, pretty much anything. In this case I ran it through a simple scenario of ramping the throttle open to 90% over 0.5 seconds and ramping the RPM parabolically up to 7000rpm over a few seconds, holding it, then closing the throttle and dropping back to idle. The simulator monitors the ECUs solenoid drive pulse outputs (it has big load resistors to convince the ECU it’s connected to real solenoids) and models the response of the physical mechs. And guess what the results looked like?

OK so my mathematical model of the VVC mechs is not quite accurate and the slow ramp was a little less obvious in reality, but the same effect was clearly there and it was clearly being driven by the ECU rather than being an issue with the mechs.

Secondly, I started reverse-engineering all of the ECUs VVC mech control code, to see what strategies it was using to drive the mechs.

The screenshot below shows what you I had normally been seeing when forcing the VVC mechs to make a step change. The green trace is the drive to the VCC INCREASE solenoid, the yellow trace is the drive to the VVC DECREASE solenoid. In each case you get one long pulse which seems to drive the mechs most of the way, followed by one or more of short correction pulses which close in on the target:

Initially the code didn’t make a lot of sense. I found one table of time delays which seemed to drive the long pulse width, and another which seemed to drive the short pulse width, but they were the wrong way around in the code. It was using the “long” pulse widths for small errors when it was close to target and the “short” pulse width initially. I couldn’t find any fault in my logic. Eventually I realised that I was thinking about it all wrong …

THERE IS NO LONG PULSE!

It’s actually just a stream of the short pulses with no gaps between them. When I ran a more realistic scenario on the engine simulator, rather than just modifying the map to force a sudden step change to look at, I saw this, which makes it quite a bit clearer:

The way it works in code is this:

·The ECU compares the measured VVC inlet cam duration with the requested duration.

·If the absolute error is less than 2° (set by a scalar in the map), it regards it as acceptable and does nothing. This prevents it hunting backwards and forward over tiny errors.

·If the error is greater than a certain threshold, which is 10° when hot but set according to oil temperature by this table …



… then the ECU immediately drives the relevant solenoid, and sets a countdown timer to the relevant pulse width, which is typically 13ms when hot but set according to oil temperature by this table:



Nothing further happens until the countdown timer expires.

 

·If the error is between these values, the ECU sets a delay countdown timer to a delay period, typically 170ms when hot but set according to oil temperature by this table:



Only once the delay period has expired will it allow another solenoid pulse.

Armed with this understanding, it was clear what was happening. I’ve repeated the original log chart below and annotated it with what’s going on. You can clearly see that when the demand increases, the mechs are driven by a series of closely spaced pulses which drive them open rapidly, but once the 10° error threshold is release the ECU slows the drive down by inserting delays between the pulses. Once the 2° error threshold is release the ECU stops driving the mechs.

IMPROVEMENTS

From the above, this behaviour is clearly by design. I think the idea is to ensure that under the worst-case conditions, the VVC mechs don’t start overshooting the target duration and oscillating backwards and forwards, hunting to find the target. Within 10° duration of the target, the ECU makes a change and then allows a pause for the mechs to settle before measuring again and making a further change if necessary.

From the testing I’ve done (which has now involved a grand total of three engines – and a simulator), the mech response programmed does seem to be extremely conservative and there does appear to be considerable scope to tighten it up without causing any problems.

On my car, I made the following map changes:

·I increased the pulse width slightly. Given that it would take a lot of testing to verify the behaviour at all temperatures, and given that we shouldn’t be pushing these engines too hard until warmed up, I decided to only adjust numbers at the higher end of the temperature scale. If it's driving out a pulse every 183 milliseconds (13ms pulse width pulse 170ms delay) and closing the 10° gap over 2.1 seconds that's 11 or 12 pulses, so just under 1 degree adjustment per pulse (my guess is they were targeting 1° per pulse). That sort of sounds reasonable to avoid overshoot with a 2° tolerance deadland either side (4° total), but it could probably afford to drive a bit faster and still avoid hunting. I therefore increase the pulse with above 50°C to ramp it back up from 15ms to 17ms instead of decaying it further to 13ms. This is a 30% increase in the pulse width and step size on a hot engine. This should still leave 2 or 3 step positions withing the desired deadband.


 

·I reduced the “small error” threshold from 10° duration to 5° duration when the engine was hot:

THE RESULTS

Below is a data log from my car with the above changes. As you can see, the tracking of the requested VVC inlet cam duration is much more accurate. There is much less time spent with the mechanisms deployed significantly below the position for optimum performance specified in the map. There’s nothing to suggest tat it’s hunting or misbehaving. What you can see is that at maximum deployment, the VVC mechanisms have a slight tendency to drift open with the engine rotation over a period of about 4 second and so the ECU gives an occasion downward pulse to keep them in place. You don’t see that on the original log because the mechs were not pinned at maximum deployment for long enough, but I’ve since verified (by loading it up for longer periods in higher gears) that this does happen with the standard settings and isn’t an effect of the changes made.

On the road it’s always hard to be sure what you can feel, especially when you’re expecting particular changes. But I’m fairly sure that especially in the lower gears it feels sharper and more responsive, with a more immediate shove in the back when you floor it – and more wheelspin!

[ECR]

You've done it again !

impressive....

[PROBE2]

Nothing but admiration (and maybe slight envy of his problem solving skill and technical knowledge!) for Andrew

Keeping the K Series alive and kicking.

I met another club member today who spoke of how Andrew traveled to resolve an electrical issue for him. 

A real credit to the club.

Back to responses on Andrew's VVC analysis and performance 

 

[john milner]

Could different oil grades affect the responses? I am guessing that 5W50 might get to target quicker than 10W40.

[BigCol]

just !

[SM25T]

#4 ..... The VVC mechs were originally designed and calibrated using 10W40 oil

[john milner]

Powertrain said 10W40 but Rover recommended 5W50. I would expect a thinner oil to require fewer pulses than a thicker one. 5W50 may also run a bit cooler. There are the other set of tests by revilla from a few years ago that showed 10W40 requiring less correction than 5W50. Somehow all of this is probably related.

[john milner]

To clarify my point about Rover recommending 5W50 as it is only partly accurate. In various workshop manuals 5W50 is shown in a table as having the greatest temperature operating range but in my MGTF Workshop Manual the how to do an oil change text says 10W40.

[revilla]

Rover recommended 10W40 semi-synthetic for the VVC even when 5W50 synthetic was being used for other K Series.

Yes the VVC system is calibrated for 10W40, but that calibration is in the form of the tables we are talking about here, so it's possible to remap it all.

There are however a couple of issues.

Firstly, Rover specifically recommended a semi-synthetic oil. A 5W50 will be fully synthetic to achieve the viscosity spread. I was told that the odd sliding blocks in the VVC mechs have very specific lubrication needs and tend to wear using fully synthetic oils. I once tried a 10W40 fully synthetic oil and my VVC mechs did sound very rattly. When I switched back to 10W40 Magnatec they were quiet again. It may have been just not such a good oil, I may have imagined it - but I won't be in a rush to put a fully synthetic oil in a VVC again.

Secondly, a 5W50 is going to be a lot thinner when cold. The oil temperature measured at the VVC HCU is about 20° cooler than the oil being fed to the bearings, so the cold viscosity is more relevant than may be expected. You can see that the pulse width tables numbers increase dramatically for colder oil, and there a danger that a 5W50 is going to over-drive the mechs unless that is all recalibrated.

You need to be very careful to ensure that the step response of the mechs does not risk driving them further than the "acceptable error" deadband specified in the map, which is 2° by default. If it does, you get into a hunting situation where the mechs repeatedly overshoot in both directions, never quite hitting the target duration. Having seen how badly the cross-shaft teeth get chewed up over time in normal use (very small radius pinion gears) you definitely don't want the mechs hunting excessively. It will prematurely wear the HCU rack, pinions, HCU piston seal etc. It will also not do the solenoids any good at all, they're only designed to operate at low duty cycles. They draw about 1.5 Amps and the driver chips in the ECU are already prone to failure under load, so they would again be more stressed.

If you did want to try to recalibrate for 5W50, a good starting point would be to get viscosity tables for both grades and cross-reference them, then use the numbers for the temperature at which the 10W40 viscosity matches the viscosity of the 5W50 at each temperature point. I'd still want to see a lot of testing at different temperatures before I was happy in to run it though. I think they were targeting about a 1° duration step response to a single isolated solenoid pulse, so that's what I'd aim for.

As an aside, the Elise VVC that had the original issue that triggered some of this research came to see me yesterday. Using logging, live dash display and modified maps we proved that the VVC mechs were just barely responding to the short pulses but responded OK to longer pulses. We checked oil pressure and electrical drive to the solenoids, all OK. He'd rebuilt the mechs which moved freely and this had no effect. In desperation we swapped the HCU spool valve and it was fixed! The old spool valve looked absolutely fine. No idea why it wasn't happy. He's going to cut it open and check for sediment or damage. It clearly wasn't able to switch to the increase position as quickly as it should have.

[john milner]

I tried this yesterday and it made a noticeable difference. Much sharper and faster to respond, a bit like dropping half a gear for a second or two . Out of all the "Hints" this one I noticed the most.

The Retard changes may have been worthwhile to me but could have been my wishful thinking as I only felt anything after a few miles, A milder version of the pulse changes.

The Inlet Duration changes (reverted to standard) I did not notice at all which is most likely down to my not driving aggressively enough to gain any benefit.

Not tried Pops & Bangs as the car looks enough like Chitty Chitty Bang Bang without having the sound effects.

I noticed that there are a few Air Con settings. With no shift light is there any benefit in turning something off?