Scroll To Top
Motorsport Developments. Blackpools Leading Engine Tuner.

Shopper Award

Click to read our reviews.

Motorsport Developments - What is Live mapping?

The following is an extract from a topic on My Ford Forum

Please give the pictures time to load, they are quite large but illustrate the text very nicely.


CHAPTER 1: "What happens on live map day?"

Ok, basically what will happen is as follows:

1) We will both sit down with a brew and discuss your personal requirements.

2) We will go over your mechanical engine specification on paper so I have ALL the facts.

3) I will sit down and devise a base map according to the details YOU have given to me.

4) I will check the car for basic safety and fluids. (You would be AMAZED how many cars I turn away because they have no brakes, or no TAX!!)

5) I will take the car for a drive to assess its performance / flexibility in its current state.

6) I will return and check the fuel pumps’ flow performance and the fuel lines for any kinks etc and flow check the injectors in the flow bench whether they are new or old. The whole engine intake system will be pressure tested at 2.5bar for leaks and any rectified. Then a full setup will be performed on the engine in its current state, and the car test driven again.

7) I will then return and if everything was fine on the test drive I will fit the following components into your car:

Lambda sensor boss welded into your down pipe.
Boost gauge.
Detonation sensing equipment.
Air Charge Temp monitoring equipment.
Air/Fuel ratio monitoring equipment.
Injector duty cycle monitoring equipment.
A live fault code reader for the management system.
A hardware emulator.
A DC / AC Converter.
A laptop.

8) I will then drive away in your pride and joy and two of us will start mapping it, which basically entails adjusting the fuel to the correct level for the boost we are running and then taking the spark advance to its limits and then back down again to our chosen level.

9) You will look really worried as we come back, poke around in your car and go out again.

10) We will probably come back again and poke around some more and you will say "How's it going?" "Problems??" with a really worried look on your face.

11) We will say "Its going fine" and go out again.

12) We will finally return and say, "All done for you sir!" And you will collapse with relief!

13) You will pay us lots of your hard earned money in exchange for your old chip and your car keys and wheelspin away like a lunatic leaving us with unhappy neighbours!!


Ok, the parts we need to access are within your vehicles ECU, so first of all we need to access that. They may be really really easy like a Cossie, and as such just reside within a simple plug in chip, or they may be in a chip that look's like this:

For clarity, I’ve added a chip to the left of those now, and its a Cossie chip.
The Cossie chip is 8k - the one on the right is 8mb.  

Now that chip wont be in a socket, it will be soldered on to the board and require unsoldering!!

Here are some pictures of other ECU packages and a couple of one after installation of the socket for the emulator to be fitted.


Ok, so that’s given you an idea just how much aggro it is to even get at the data within a modern car, and how easy it would be for us to wreck a £1000+ ECU at our cost.

CHAPTER 3: What do we do with that chip?

Ok we’ve got a chip now. So we put it in the EPROM reader/programmer and extract its contents:
Once loaded up into an appropriate editor, it will look like this:

The data I’ve shown us working with is Escort Cosworth P8 just for clarity’s sake and to keep it topical for Fords.
Note the slider bar in the picture to give you some idea just how much data we are talking about, even in a tiny Cosworth map file. Now it begins to get tricky.

CHAPTER 4: What does all that mean?

Ok, let’s look at that same data in graphical form.

See how it’s now represented as lines, on a graph? Almost like a spreadsheet? Still not much of any interest is there?
Let’s look at another part instead:

See anything there then? Well, I can actually, but I don’t expect you to.
Let’s look at the same part of their file in 2d graphing mode.

Ahhh... now were getting somewhere.
So we’ve found a map, what needs to be done now?
Well, first we need to ascertain exactly what that map does. There are various ways of doing this that I won’t bore you with; suffice to say we have discovered it is a fuel table.

Once we have a few more parameters deciphered such as RPM and load values, we can have the software converted to show us a more useful display, as follows:


Now were getting somewhere... that looks almost usable.
Repeat all the above and ultimately we will find and catalogue all the other maps like this one for spark advance:

We can even view them in 3d if we wish:


Ultimately, we aim to end up with a nice list, like this one:

Once we have all this data catalogued, we can start to look at mapping our never before mapped model.
**This only has to be done once per ECU data set type**


Can you define the RPM points, or are you stuck with what they give you (stops at 7000) ?

Yes, this is done by altering what we call the "Breakpoints".
The problem here is that we cannot ADD anymore. Consequently, if I was to change the end point to 8000rpm I would then have an interpolation break between 6600 & 8000 rpm. That’s not the end of the world as P8 has enough to spread out quite well, but some of the earlier 13 column stuff is much trickier to get decent set points with if you want to map right up to 8000rpm. 

CHAPTER 5: ok, smashing, great, now what?
Ok we’re prepared now and have access to the maps needed to actually do something to this beast, so what next?
Well next comes the hardware. I’m not going to directly show you the hardware I use as it’s taken a lot of trial and error of junk hard/software and a LOT of wasted cash to arrive at a package that is world-class in its field.

So first we need to hook up our hardware into YOUR car.

Det cans:


Here’s a photo of them hooked up to a YB lump:


And the other end of them with all the wire and stuff on the dash here in the same car. If you look closely you can see the channel switch This allows me to swap between any of the 4 pickups I’ve installed on the engine:

Next we need to fit something to monitor the most important aspect of a turbocharged engines survival chemistry - the fuel content, or AFR as we call it. (Air/Fuel ratio)

The one we prefer to use, look's like this at the in car end:

And will be fitted either directly into the down pipe or inserted in the tailpipe like so.
(Tailpipe option requires high quality units with oxygen sensing capability like ours)

Ok we’re getting there... now we have to get the laptop to run your car. This is the expensive bit!

CHAPTER 6: Running the car from a laptop.
Ok you’ve got a very basic grasp now of what goes into getting the car to a mappable scenario. All we have to do now is hook our emulator into the setup and fire her up.

Here’s the emulator :- (note how we have fitted a socket where the chip used to be, and then that socket is cabled across to the emulator)

And here you can see it connected to a Marelli ECU:

So that brings us to: “What does an Emulator do ?”

Basically, as the ECU requires information, it accesses a lookup table in the control maps and then, based on various parameters, draws a result from the software and applies that result to the engine.

What we want to do is change that result whilst it’s happening. That’s where the emulator comes in. It loads the software required into its very fast flash memory and addresses it correctly so that the ECU thinks it is still a chip. Now whilst the ECU needs info, its taking it from the same control maps, only it’s being taken from its storage area within my Emulator, and not from an EPROM as normal!

“So why is this good?”

This is good because now I have the ECU on one side of my Emulator, but I have my Laptop on the other side doing two VERY useful things:
1) Showing me what data the ECU is asking for and at what time
2) Allowing me to change it

Remember at 6000rpm, the ECU will access for the same data 50 times per second so its not like I will miss anything if that’s what you think.

So: We’re hooked up now, the engines running; we will now get a screen something like these:



Note the difference between these and previous screenshots is the addition of a red box, covering 4 separate values? That is the live “trace” and its position, and is the exact data the ECU is using to run the engine at that time… so we can now alter the data in these boxes, whilst the engine is running……at 200mph if we like!

The following, are questions asked by forum members after reading the above information:

Supposing you wanted to increase the fuel at 6000rpm, and retard the ignition, would you have to alter the lookup values in the tables to do that? Or can you  drag/adjust something on the graph to do that? Would you, for example, make the 255 to 256 if it was in that particular region?

I would literally increase the number in the fuel map that corresponded to the area I was running lean at. 255 is the maximum, so if we were already at 255, we have problems, but none that cant be worked around.

The advance would be done last and again, I would simply do it from the advance screen you have seen already and adjust the number highlighted when the problem arose.


How do you implement the functionality - say a high ACT retardation, or a low ECT enrichment.

Are they separate lookup tables, or are they simple parameters in an equation already implemented in the ECU (dependant upon ECU type)?

We have separate tables completely, for example

Advance with ACT
Fuel with ACT

Take fuel for example:
It’s usually a simple 16x1 map with each point a temperature.

Each of the separate temperature plots will either add, or in the case of excessive ACT's subtract, a degree of fuel from the main map. The same goes for spark, and same again for coolant temperatures.


Cars fitted with a lambda sensor as standard : how much of a bearing and how does the lambda effect the fuelling? Is it just for safety (extremes) or is it a function to enable efficient running? like a closed loop system.

99% of cars fitted with closed loop fuel term control, utilize it only under part load conditions, and also only with a hot engine.

This is simply because if the sensor drifted from cal, under Wide Open Throttle conditions it would cause an expansive meltdown. WOT is not seen as an emissions issue as most engines spend a VERY small percentage of their life there.


What happens when things go wrong with boost? I know some have got over-boost protection in the chip, but is that always there?

Depends which application it is, but we will choose Marelli.
The 3bar can have a boost limit up to and including 28.5psi that’s still reliable. If you want to run more boost than around 26.5 held, then the boost limit must be removed completely. The alternative is to fit an alternative method of boost limiter, such as a pressure cut-off switch or a blow off valve.


Escort RS Turbo’s - what stops you from 'live mapping' the ignition on these for example?

Bosch KE's Spark control map is part of a Motorola "processor" and is not stored on an "EPROM" as per other designs. Processors cannot be emulated live by conventional emulation methods.


Changing Map Sensors : what happens when you change to a different map sensor, and if the map sensor is limited to 1 bar positive - how would you get around this for running say 18-20psi?

The map sensor doesn’t really "limit" anything. If you look at this fuel map:


The left hand column is map sensor output voltage, so obviously, should we change the sensor, the column meaning will change, yet fuelling remain the same.

For example: Top line is 4.9volts. That on the standard FRST OFAB sensor is 1bar positive or 2bar absolute. If we change to a 3bar, that line now equates to 2bar positive or 3bar absolute.  The result = very lean everywhere. This effect obviously happens to every map that is pressure related.

As for the upper limit of the sensor, once we hit the 4.9volt line, we can run all the boost we like, we will never get anymore fuel, hence when your tuner says: "set it to 28psi" you don’t set it to 34psi and presume it will be ok.


How do you map past the boost limitations of the map sensor you are using? For example, how do you map for 34psi when using a 3bar map sensor?

When the map reaches 4.9Volts it still has RPM factors etc it can read to keep RPM based fuelling correct for RPM. And we can still increase the values and duration it puts out at that level, but we cannot change the fact it is no longer scalable against pressure.

What has to be done is map at perfectly at the maximum boost, then anything below this will simply be a bit rich.

I’ve highlighted the lines which I am talking about in blue.
Next to the lines, in the map sensor pressure boxes, I have written in a boost pressure example.

The top line will be hit at 28psi and above so at 28psi we are on the top line and at 34psi we are STILL on the top line.
Now if we are running 20psi we will be fuelling from the 2nd line.

So: If the top line is mapped to fuel perfectly well at 34psi and we drop the boost to 29psi we will be slightly rich. But if we drop to 22psi we will be fine.

The topic continues @

This page was kindly constructed by Nigel Burroughs (Sketch) after i "mentioned" that I may cut this useful discussion from the forum page and reproduce it on my website. This must have taken a couple of hours or more, so Nige, THANKS!!