[Persian Whisperjet]

Originally Posted by DWR

Mik is most interested in gaining mpg, so the tests are in D (Mik correct me if I'm in error)

Mik I just got 42.2 mpg on a tank mostly highway -- post-DPF but I have not even attended to the EGR yet. I'd say 5-10 percent improvement easily.

[DWR]

OK team, I'm putting this out for knowledgeable folks to gander and comment. Here's a map that is in every cal file. I have a theory what it does, but looking for confirmation. What do you say? Particularly interested in thoughts on the lookup axis. Thanks.

[Hoooper]

Torque on x axis (nm)? Km/h on y axis? Minimum lockup rpm lookup?

[Mik325tds]

Originally Posted by Hoooper

Torque on x axis (nm)? Km/h on y axis? Minimum lockup rpm lookup?

Wow. That would be something! So there would be one of those maps for every gear, right? This one must be one of the higher gears... But no, how can you do 200 even in 6 gear with 150 to 1160 rpm?

[DWR]

OK, so that is one of the interesting aspects. There is only one of those 12X12 maps and it is in every calibration file that I have looked at. Therefore, it is not likely to be gear dependent. BTW, Mik shared a cal from an E53 and it had approximately 1/2 the number of maps. But it still had that one.

I'm really starting to see patterns across the cals. Here's another common map structure, typically 32 of these in a cal.

[Mik325tds]

He's decoding the Matrix!!!

[gtp900]

Originally Posted by Mik325tds

He's decoding the Matrix!!!

He will have to change his name to Neo

[DWR]

Originally Posted by gtp900

He will have to change his name to Neo

If we don't get a breakthru in a bit, you might be calling me ZERO, lol.

[DWR]

Originally Posted by Mik325tds

He's decoding the Matrix!!!

Oh no, just giving you your lucky lottery numbers!

But ... I don't do fortunes!

[DWR]

Originally Posted by DWR

OK team, I'm putting this out for knowledgeable folks to gander and comment. Here's a map that is in every cal file. I have a theory what it does, but looking for confirmation. What do you say? Particularly interested in thoughts on the lookup axis. Thanks.

After looking at many calibrations, I've seen that this map does not change. That is regardless of the engine or vehicle it goes in. Must be something specific to the transmission. At any rate, it won't be something we will be 'tuning'. So, that's 1 down, another 50 or so to go.

[Yozh]

May be we need this tool for simulation?

http://www.qtronic.com/doc/VirtualTC...ic_ZF_2014.pdf
http://www.qtronic.com/en/silver.html

[DWR]

Originally Posted by Yozh

May be we need this tool for simulation?

http://www.qtronic.com/doc/VirtualTC...ic_ZF_2014.pdf
http://www.qtronic.com/en/silver.html

I'll take a look. Thanks.

[Mik325tds]

Originally Posted by Yozh

May be we need this tool for simulation?

http://www.qtronic.com/doc/VirtualTC...ic_ZF_2014.pdf
http://www.qtronic.com/en/silver.html

Thanks for the post. Nice paper. But rather then using silver for simulating our transmission, we should try to get our hands on the calibration tools mentioned in the paper: INCA (ETAS) and CANape (Vector).
The Vector tools are usually very expensive but I haven't heard of INCA yet. The interpretation of the numbers in the cal files is critical. I fear that they are normalized values that'll have to be translated to real word values using a multiplicator and offset.

[Yozh]

I've been reading a lot recently. I think the calibration file interpretation is much more complicated than what we allow it to be. For example, the latest tables that were posted. The column headings: 17, 26, 34, 42, 51, 67, 84, 101 are the bit numbers, as in a 101-bit data stream. Or so I think.

[DWR]

Originally Posted by Yozh

I've been reading a lot recently. I think the calibration file interpretation is much more complicated than what we allow it to be. For example, the latest tables that were posted. The column headings: 17, 26, 34, 42, 51, 67, 84, 101 are the bit numbers, as in a 101-bit data stream. Or so I think.

Sorry Yozh, I'm not following. Sounds like you are saying we have the wrong data format. The numbers are, after all, the result of 16 bit conversion. So they are the conversion of a conversion? Again, admit I am not understanding. Please clarify.

[Yozh]

I of course did not look at all of the details and may be completely out of my league here, but I thought that those headings are bit locators/references. #101 may refer to let's say TPS sensor or anything else. I'm probably wrong on the size of the data stream as any byte reference may refer to a different size for that byte reference. So, 101 may be in 2 byte size, etc. Hope I'm not confusing anything.

[DWR]

We all may be out of our league, on this one. If the calibration files are indeed as suggested, I am over my head. The truth is we do need a leg up. However, if we have to build the leg ourselves I'm not sure that helps. I am not in disagreement that a simulator would speed this up. It would allow us to do experiements that would be improper in the real transmission. But when the simulator cost more than a transmission ...

[Mik325tds]

We all are out of our league here, otherwise we'd exactly know what to do.
But we are smart (and wyse) and capable of learning and that's why we are doing this.
If I understand Yozh correctly, you're are thinking that the numbers are not numbers but addresses (or services in the diagnostic world), right?
I'm pretty sure thats not the case because the maps have specific patterns that WinOLS is looking for, the numbers and axis values are a strict conversion from hex to decimal. It has the ability to apply factors and offsets in the maps (double click on the axis). For instance, let's say we are looking at the throttle signal. The value range is 0-100% and would easily fit in a byte (0-255 dec, 0x0-0xFF hex). But in order to gain precision, ZF might have choosen to use the full range of a byte and have 200 (or 0xC8) represent 100%. So the factor would be 0.5*EEprom value. Now the throttle resolution is 0.5% instead of 1%.

I'm wondering if pheno might know the conversion rules as it is very likely that Ediabas just spits out the raw values for signals as well.

[Mik325tds]

The other day I looked up how the EGS transmits its signals on the CAN bus. My thinking was that it most likely uses the same conversion rules there. So, for throttle it is actually using a 12bit value (0-4095 or 0x0-0xFFF). In order to get from the signal to real the factor of 0.025 has to be applied, meaning in the cal file we'd most likely find 0xFA0 as the maximum value for Throttle = 100%.

For RPM the factor is 0.25 and 16bit (2 byte) signal.

For Torque it is even more complicated. In order to get negative values (for coasting or engine brake) they have choosen a factor of 0.5 and a 12bit signal shifted by -1023.5. So 0x000 in the signal would represent -1023.5 Nm.
A maximum torque of 1023.5 Nm would convert to 4094 or 0xFFE.
Makes sense or confusing?

[DWR]

Originally Posted by Mik325tds

I'm wondering if pheno might know the conversion rules as it is very likely that Ediabas just spits out the raw values for signals as well.

I think those would be the same conversion rules that are applied to OBDII PIDs. They can be seen in Tool32 and Testo. In addition, that information can be found on the web. However, if you are not sure what the parameter in question is, then blindly applying conversions can be disconcerting (been there, done that). Generally speaking, the list of potential inputs is 3 rpms, load/torque and 2 temperatures. There could be a great amount of 'aliasing'. Outputs are duty cycle, binary on/off and torque reduction (maybe I have forgotten something). I believe we will be most successful if we know the map shapes we are looking for, then matching variables will be easier (not easy, just easier).

[DWR]

Does anyone think the data in the image looks like maps? They do to me, but WinOLS does not recognize any of these. Is there a better tool?

[Hoooper]

So here are some charts that I have from another tune. I think these charts represent what some of those charts could be, or maybe just an idea of what kinds of variables might be used for the tables. When I tried to post this the first time my tablet froze up a bit and I panicked since screen captures and such are not the strength of tablets and just getting here took a while, so I'm going to post this now and hopefully add a couple more later. Having seen some of the data already posted here I suspect that this tuning program takes the data from these user friendly charts and converts it to the entirely unfriendly charts already posted.