Whats in a tune file

[Garf]

I'm not about to get into a fight - I'm to new here and really don't want to piss anyone off -

But so your telling me these companies that make these tuners work for / have worked for Ford and on these specific engines or have some kind of contract with Ford on getting the data or etc? Cause last time I checked, programming was 90% screwing around with something you don't know and figuring out how to make it work.

I'm perfectly fine with buying whatever program they use to make the tune file assuming it's not thousands of dollars - and I completely understand the risks of bricking an engine / computer.

But don't be instantly dismissive buddy - awesome stuff has been created and still is by simply screwing around and learning something new and pushing boundaries...

Hey OP, just like you I was interested in the back end of tune files. They are basically a shit ton of tables similar to a series of queries based on parameters of the running conditions. You can get a thing call Accesstuner Race from Cobb tuning if you buy their stuff and apply for the program (apply is a loose term here, just ask really). I've poked around on there for a few hours and it's interesting. Never used any of the tunes I've made (Don't wanna bet my 30k car on my own handy work with a new program). Others on here are making a big stink because they don't work in computer fields so its abstract for them. Once I started IT at my place I learned fast that its like 85% guess work, 14% google, 1% knowledge, and 3% bad math.

Perhaps try befriending one of the tuners on here and ask questions or get them to check any work you do to get a reference. They're nice guys.

Sponsored

 

[arghx7]

There's knowing the engine side and there's knowing the software/computer side.

You can know that the engine needs to be richer, but you have to figure out what to change to make it actually do that. There are feed forward and feed back elements for fueling as one example. Same with boost control, spark control, electronic throttle, etc.

In the case of the current Ford controls, there is a complicated model of engine cylinder filling to account for the variable intake and exhaust cam centerlines and the change in air temperature in the system. In the old days you could have a couple dumb look up tables, but now it's way more complicated than that.

If you can tune a carburetor and understand engines, you still need to understand software and controls to some extent to get anywhere. If you understand software and controls but don't know much about engines (air,fuel,spark), you're gonna have a bad time.

 

[Dolsvt00]

Again, for bolt on's and optimization, with some average knowledge you can optimize. Theres literally not much you can mess up if you make small changes to the stock tune and leave the knock sensors on and increase the retard values for safety while your playing.

For injectors, fuel systems, induction upgrades, cam's or any major modification to airflow or fuel you need experience, math and data.

Theres no 3d table this table that scalars bla bla in the pcm, its dbase. The interface software, cobb, SCT, HP, CMR are the ones that give you that. You can do that shit in excel too, I can create all kinds of graphs and fancy charts in 2d or 3d in excel, but you know what makes those carts? Numbers............Nothing more, nothing less.

 

[Norm Peterson]

Theres no 3d table this table that scalars bla bla in the pcm, its dbase. The interface software, cobb, SCT, HP, CMR are the ones that give you that. You can do that shit in excel too, I can create all kinds of graphs and fancy charts in 2d or 3d in excel, but you know what makes those carts? Numbers............Nothing more, nothing less.

Doesn't matter what format the maps are actually written in, the tabulated numbers themselves are your 3rd-axis offsets. Having a visual presentation of the map does help if you can't visualize what you're doing from just looking at the numbers themselves (not everybody can do that well enough). Picture vs a thousand words kind of thing.


Norm

 

[arghx7]

Ford uses ATI Vision as their tool to calibrate the PCM. It's like a really expensive commercial version of these aftermarket tools. For ATI Vision and its competing software (ETAS INCA, Dspace ControlDesk, Vector CANape), they have a sort of generic/universal interface to them, because they can be used for engine related control modules or other kinds of control modules (stability control/vehicle dynamics, transmission, etc).

You the user supply a definition file in the format .A2L . The .A2L file is basically a type of XML that defines memory addresses inside the binary which is .HEX, .S19, or others depending on processor instruction set. The .A2L files define specific scalars (single value), 2D tables, and 3D maps that are part of the program control strategy.

Here's a screenshot of a 3D calibration map from ATi Vision website:

You can see the tab "EGR_dmd1" below. That variable name is defined in the .A2L file. From the name we can guess that it is an exhaust gas recirculation demand table of some sort. This is just a generic thing from the screenshot.

Here's the description of a .A2L file from Vector's website:

Description Files for Internal ECU Parameters

Description files let the user access internal ECU parameters by symbolic names. A2L files are elementary components of every measurement and calibration operation, and it should be noted that the CCP and XCP protocols are address-oriented in their operation. The user selects objects by symbolic name, while CANape takes the associated addresses from the A2L and uses them in communication with the ECU.

Contents of the A2L database

An ASAP2 description file (also called A2L) contains all information on the relevant data objects in the ECU such as characteristics (parameters, characteristic curves and maps), real and virtual measurement variables and variant dependencies. Information is needed for each of these objects, such as memory address, storage structure, data type and conversion rules for converting them into physical units. In addition, an A2L also contains the parameters for communication between CANape and the ECU.

The .A2L file is generated by whoever wrote the controls. Again, modern ECUs are pretty much all running controls from Matlab Simulink. So somebody in Ford or one of their suppliers will dump the .A2L and the block diagrams. Then somebody has to know what to do with it.

So here's an example of a controls block diagram with special "bypass" algorithm inserted, using another uber expensive tool by ATi (other companies have similar tools). When you get an aftermarket "race ROM" or other such special feature, they are basically doing what's shown in this diagram: they are inserting special controls to bypass internal PCM calculations.

For example, Cobb has a special simplified Speed Density mode for the 2.3 Ecoboost. You can find it if you poke around the website from my previous post. What this special mode does is partialy bypass the complex model in Ford's calculations, because when your engine is heavily modified it is very difficult to modify the existing Ford tables and have the engine run right. So you sort of dumb it down to make it more manageable.

But Cobb probably wrote their own interface to do these bypass controls, just like they have their own interface for data acquisition and calibration tables. They aren't going to pay one of these commercial vendors a gazillion dollars. And since Cobb or HP Tuners or whoever doesn't have access to a .A2L file from Ford, the memory addresses have to be reverse engineered. So when Ford releases a new PCM update which changes the controls, the memory addresses move around and somebody has to figure out where the spark tables are now.

So that's more details on the back end.

When you the end user have an aftermarket tool, it's actually easier to understand than these expensive generic interfaces from commercial vendors. In most cases the functionality is the same, but there are situations where the commercial tools are more powerful. For example, the commercial tools, with the right equipment, can sample data at much faster rates. They can also change all PCM variables live, without having to reflash a module, because they use expensive prototype memory modules. But for the cost, you get a very large portion of the functionality in these aftermarket tools, and better ease of use.

As I pointed out above though, even if you had access to absolutely all the software information and all the expensive tools (the software side), you still have to know what to do with it (the engine side).

 

[Dolsvt00]

Doesn't matter what format the maps are actually written in, the tabulated numbers themselves are your 3rd-axis offsets. Having a visual presentation of the map does help if you can't visualize what you're doing from just looking at the numbers themselves (not everybody can do that well enough). Picture vs a thousand words kind of thing.


Norm

Going with the original intent of the discussion again, all that stuff is software biased. The tune file itself is raw data, the software gives you the visual's.

To go open source (which is what my interpretation of the OP's question is) or create a program that would show you the trees, the graphs and scales are add ons, what happens when you change a graph by point and click on the interface software out there? It changes the numbers on the x and y axis its just a visual representation of the numbers, you could accomplish the same by physically changing the numbers, because the numbers themselves are what the graphs visually represent.

The tuning software companies have physical interfaces be it handheld or cable they pull the base file off the pcm, this is converted to a dbase file https://en.wikipedia.org/wiki/DBase. The software itself that you load those tree's into is what gives you the interface, graphs and fancy tabs to modify the raw data. the data is saved back to raw form then loaded back to the pcm via one of the mentioned interfaces.

 

[Dolsvt00]

I've had to send some of these raw files to sct before to convert so that their software would access, they then take this raw converted file and send it out as an internet update for all the users with that package. When you have hundreds of tuners doing that it doesn't take long when cars are out and on the road to eventually have a collection of all PCM codes for all years.

The newer stuff is more complicated, as the pcm is tied to the equizzer and PATS. Back in the older days 95-04 you used to be able to take say a 2000 pcm and flash a 2004 tune and strategy in them if the vehicle was the same make model engine and transmission. Sometimes this was better because the layout was better and the way things were scaled, the car would even run better and some of the limits of the original strategy were removed.


In the old foxbody days you could take a 5.0 bronco PCM and flash an A9L (foxbody mustang) strategy in from a mustang, this was actually quite popular for swaps.

 

[Norm Peterson]

Going with the original intent of the discussion again, all that stuff is software biased. The tune file itself is raw data, the software gives you the visual's.

Understood.

But as long as the engine does not actually need random abrupt discontinuities in any of the maps, having a more readily visualized presentation can only help most people actually work with those numbers.


You'd have to see the fueling map that came with my Accel/DFI system - you might wonder how I was even able to drive it to the EMIC representative just to get the WOT fueling somewhere near right. And you'd understand why he was more than willing to hand the drivability tuning after that over to me.

I could (did) work with just the numbers, had to until I figured out how to present it in Excel. So I get what you're saying.


Norm

Sponsored