Wacky MEMS3 ECU Table - Any Ideas?

revilla · February 24, 2020

Whilst looking at the different tables in MEMS3 ECU's this one stood out like a sore thumb!

This is the same table, from three VVC ECUs with the same firmware version:

A lot of ECUs seem to have something similar to the last one. But there seems to be little logic or pattern to the others. And here is the same table (identified because it's in about the same position in the list of tables and is the only one to have X axis values 0..5) from three non-VVC ECUs:

Again, no apparent consistency between them at all!

I have no idea what the axes are.

X axis 0..5 could be gears (with neutral) so I was thinking maybe gear shift light data, but I can't find any evidence that MGs and Rovers of the era had them, and given that Rover apparently reprogrammed the aircon to come on a set RPM for Caterham, end then drove the dash shift light off the aircon clutch solenoid output, I doubt they would have gone to those lengths if there was a shift light facility already that could have been remapped.

I thought maybe auto gearbox shift data, and maybe it was just there but without sensible data in manual ECUs, but the Rover Steptronic was continuously variable so it doesn't seem like a good fit there either.

I suspect it's not of great interest for remap purposes - if it was critical some of those cars would drive like a bag of spanners.

But it's a puzzle and I wish I knew the answer.

Any ideas?

CharlesElliott · February 25, 2020

Air con control?

CharlesElliott · February 25, 2020

And I believe the air con control was what Caterham re-purposed for the shift light.

EDIT: I see that you already had that thought.

Cooling fan control is another thing I can see in the ECU, but it doesn't appear to be gear dependent.

revilla · April 3, 2020

I think I have the answer.

I need to do some more scope tests and get the car out on the road (which isn't going to happen in the near future) to be sure that I've pinned the definition down precisely, however in the meantime the best definition I have for it is:

X Axis: RPM
Y Axis: Seconds on Overrun
Z Axis: % Fuelling

So it looks like a time sequence fuel profile on the overrun. After the period given by the Y axis range I think ORFCO (overrun fuel cutoff) kicks in and takes the fuelling down to zero. For the first few seconds it fuels on the overrun, I think to stop the manifold from drying out to prevent stumbling when picking up.

If you want to get decent pops and crackles on the overrun, as well as retarding the ignition timing at high vacuum and mid-range RPM, you need to throw some more fuel in with this table. Values around 50% seem to work well.

If you really want to go extreme I believe you can turn off ORFCO altogether; I haven't quite got the "proper" way to do this yet, still working on it - but I can think of two possible workarounds:

Extend the Y axis on this table to something extreme, so it never times out. Not sure if the ECU wil recongnise this or not.
There appear to be a couple of scalar values in the map which limit ORFCO to a minimum coolant temperature of 75°C. You can increase these to prevent ORFCO from becoming enabled. Coolant temperatures within the ECU seem to be generally limited to the range -40°C to 140°C so setting these to 140°C seems a possible solution.

Will continue to work on validating this when time and conditions allow.

rj · April 4, 2020

Andrew,

Just a daft question:

Have you any idea if your software could "easily" be adapted to cover the VAG groups ECUs?

I am currently looking into remapping of a 1.8t, and the money asked for the software to do so is horrendous. You could probably make a decent income from this if you felt like...

revilla · April 4, 2020

Hi Regin,

To be honest I don't know!

I guess a lot of the principles could transfer across but I think a lot of the details would differ. I've no experience of VAG ECUs, so I don't know anything about security models, structure etc. The first thing that would need cracking would be the seed/key algorithms and I suspect they've got rather more sophisticated since the Rover days. It was hard enough to track them down for the MEMS3, it involved trawling through disassembled machine code and various tricks which allowed me to hook my debugger into other software tools to breakpoint them just as they were about to handle the security so I could watch what they did.

I doubt it's something I'm likely to have the time for in the foreseeable future, especially not having a car to try anything out on.

Andrew

revilla · April 4, 2020

Managed to get a scope on things this morning.

So it's not quite what I thought.

It is definitely the key to getting a good overrun pop and crackle, and needs to be set in addition to the igntion retard to get an effect that lasts. I still think I was right on the X and Y axes, but it doesn't appear to be driving the fuelling.

I flashed a map that had pretty much flat fuelling at all sitesm set target AFR slightly riched that 14:7 to disable lambda control etc. to try to give as consistent an injection pulse width as possible (ended up at about 2.8ms off idle). Then I checked the pulse width on overrun (after blipping the throttle as the engine coasted down) with different values in this table. There was a partial fuel cut (to about 1.6ms pulse width) during overrun, but it wasn't affected by the changes in this table, even though the pop and crackle was.

So I know what some of its effects are and I know how to use it to get what I want but I still don't know exactly what it's doing.

I tried to see if it was a further transient ignition retard (which is about the only other thing left of that I can think of that fits) bt trying to check that in the garage on a scope was just too hard; I couldn't hold a staeady RPM on overrun and I couldn't find a sensible reference signal that allowed accurate timing measurement with a rapidly changing RPM. Really need to get it out on the road so I can do some tests coasting, maybe downhill, where I can hold a steady RPM.

Unfortunately, that's not going to happen for a while under the current restrictions. I doubt PC Plod will accept "trying to make my toy car pop and crackle" as "essential travel"

I suppose I could map in a static additional ignition retard equal to the numbers I'm using in this table just for a test and see if it brings the pops and bangs back? That would pretty much confirm it as a dynamic igntion retard.

revilla · August 28, 2023

Well three and a half years later I've mostly got an answer!

This table is indexed by engine speed and by the states of a state machine that models a combination of MAP and throttle position. That state machine effectively maps how hard the car is being driven at any given moment onto states 0-5 based on threshold values for transitioning between states.

Then, if you close the throttle, another state machine models the transition to overrun and looks up a value in this table, which is then used to delay the onset of overrun fuel cutoff in a third state machine. The table is only referenced by the ECU once per overrun episode.

So basically this table specifies how long a delay occurs between closing the throttle and fuel cutoff (oddly in units of half crankshaft rotations - the counter counts down at 0, 180, 360 and 540 crank degrees) under different driving conditions. Half crank rotations are injection events.

That's why increasing the numbers in this table allows an extended pop and crackle effect - larger numbers maintain the fuelling on the overrun for longer.

I think it was originally designed to smooth the transition to overrun, by ensuring that there was enough of a fuel charge in the inlet runners to allow it to lean off progressively as this became exhausted rather than the driver feeling a sharper cut.

revilla · August 29, 2023

For anyone interested in such geeky things ... here

is a video of my Research Engine Simulator putting the ECU through some simulated overrun cycles on the bench. I'm using the Live Dashboard in MEMS3 Mapper to monitor what the ECU is doing, with some custom parameters defined to watch internal variables.

You can see the ORFCO Countdown being set from this table when the ORFCO State transitions from 1 (Normal) to 2 (Overrun). When the countdown reaches 0 the state transitions to 3 (ORFCO) and the fuel is cut off (Inj. 1Pulse drops abruptly to 0). When the RPM drops below 1400rpm again, the Overrun state machine switches out of overrun state, the ORFCO state machine transitions briefly to 4 (Recovery) where fuelling is restored and it returns to state 1.

What you can't see in the video is that I have the MEMS3 Mapper Debugging Patch installed on the ECU, which was simultaneously producing reports showing what was happening inside the ECU like the one below.

Internal RAM variable ($044C) is counting the number of crankshaft rotations.

This was captured on the overrun and you can see internal RAM variable ($06BA) counting down by 2 per crankshaft revolution (the two breakpoints were set on the whole crank revolution processing code that handles 0 and 360 degrees).

Breakpoint List:

Breakpoint 0 Address: $119EEA, Words: 2, Pre-Execution
Breakpoint 1 Address: $119F02, Words: 2, Pre-Execution

Breakpoint Execution Summary:

Breakpoint Count: 222

Breakpoint 0 Count: 111
Breakpoint 1 Count: 111

Breakpoint Sequence: 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1,
0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1, 0, 1

Breakpoint #0:

Breakpoint: 0

ECU Uptime: 09:12:07.70573