Map format details

Developer topics relating to software that provides a tuning UI to alter ECU code and data

Moderator: Freon

Map format details

Postby Kha0S » Sat Feb 11, 2006 9:02 am

I'm re-posting a link to these posts over here, since I think they're absolutely critical to what we've been doing.

http://forums.openecu.org/viewtopic.php?p=2564#2564

This "map type" field is absolutely mandatory to process in map editing tools. I've since figured out that ecuEdit isn't just occasionally using the wrong byte order, but is always using the wrong byte order. When doing two byte fields, ecuEdit is processing the number in little endian byte order, and it needs to be processed in big endian.

RPM is not * 50, but should be /512 * 100, etc. After going over all of my maps using the map type identifiers to figure out my axis and data boundaries, every single map requires the [bytex] syntax to get the right output.

Additionally, it appears that the 1D maps have some sort of axis information embedded in the bytes ahead of the type byte that may indicate the range of the axis. I'm still trying to figure it out.

Thanks to Calvin and NeverLies for pointing this format out... the vast majority of the information regarding dimensions and byte formats of the maps is stored and embedded with the map, and our tools should take advantage of this.

/Andrew
Kha0S
 
Posts: 106
Joined: Tue Jan 11, 2005 12:30 pm
Location: MY02 USDM WRX / Nashua, NH

Re: Map format details

Postby qoncept » Sat Feb 11, 2006 9:31 am

Kha0S wrote:This "map type" field is absolutely mandatory to process in map editing tools. I've since figured out that ecuEdit isn't just occasionally using the wrong byte order, but is always using the wrong byte order. When doing two byte fields, ecuEdit is processing the number in little endian byte order, and it needs to be processed in big endian.

Are you sure this is always true? I toyed around with RPM in big endian, but load and throttle position almost certainly seem to be stored in little endian.
qoncept
 
Posts: 249
Joined: Tue Oct 04, 2005 6:43 pm
Location: Montgomery, AL

Re: Map format details

Postby Kha0S » Sat Feb 11, 2006 8:24 pm

qoncept wrote:
Kha0S wrote:This "map type" field is absolutely mandatory to process in map editing tools. I've since figured out that ecuEdit isn't just occasionally using the wrong byte order, but is always using the wrong byte order. When doing two byte fields, ecuEdit is processing the number in little endian byte order, and it needs to be processed in big endian.

Are you sure this is always true? I toyed around with RPM in big endian, but load and throttle position almost certainly seem to be stored in little endian.


If you look at the ECU disassembly, they're always big endian. Load, for instance, is computed by taking the big endian value and dividing by 8192.

None of the code in the ECU appears to have any facility for handling little endian bye order.
Kha0S
 
Posts: 106
Joined: Tue Jan 11, 2005 12:30 pm
Location: MY02 USDM WRX / Nashua, NH

Postby qoncept » Sat Feb 11, 2006 8:55 pm

Doh, I got my endians confused. ::] Yeah, you're absolutely right. That's how I'd had them calculating in Enginuity, by sheer chance, though. I have RPM as x/256*50, though. ;)
qoncept
 
Posts: 249
Joined: Tue Oct 04, 2005 6:43 pm
Location: Montgomery, AL

Postby epifan » Sun Feb 12, 2006 12:37 am

I'm adding big-endian bytes support. Little-endian is by default, but you can change it to big-endian in ecuEdit <config>-tag

http://forums.openecu.org/viewtopic.php?p=2591#2591
epifan
 
Posts: 197
Joined: Sat Nov 26, 2005 1:23 am

Postby Kha0S » Sun Feb 12, 2006 9:05 am

epifan wrote:I'm adding big-endian bytes support. Little-endian is by default, but you can change it to big-endian in ecuEdit <config>-tag

http://forums.openecu.org/viewtopic.php?p=2591#2591


AWESOME!!

epifan, you're great.

I'll take advantage of my snow day today (already got around 13", and it's supposed to keep falling for a few more hours!) to make a new XML definition for the A4SG900C with all big-endian numbers.

/Andrew
Kha0S
 
Posts: 106
Joined: Tue Jan 11, 2005 12:30 pm
Location: MY02 USDM WRX / Nashua, NH

Postby crispyduck » Sun Feb 12, 2006 12:38 pm

Kha0S wrote:... to make a new XML definition for the A4SG900C with all big-endian numbers.

Let us all know the new 'to'/'frm' formulas once you've sorted it all out. Perhaps this is why I'm having trouble displaying the correct wastegate duty % value in my maps. They seem way too low (26% max) when using the existing formula:
Code: Select all
<function name="toWDuty" expr="[value]*100/246"/>

-Steve.[/code]
crispyduck
 
Posts: 186
Joined: Sun Nov 13, 2005 1:15 pm
Location: www.scoobypedia.co.uk

Postby Kha0S » Tue Feb 28, 2006 11:55 am

So, I dug up some of the 2D maps out of the A4SGD10C ROM... it appears that there are two kinds of 2D maps... "real" 2D maps with full data information for the axis, and "pseudo" 2D maps that do not.

Here's a list of pseudo-2D maps with the accompanying "map descriptor" as found in the ROM:

Code: Select all

      10 00 0F 80 (16 items @ 1b each)  (duty intake temp comp)
04 00 01 B8 05 81 (6 items @ 1b each)   (duty press comp)
08 00 01 98 0B 81 (12 items @ 1b each)  (boost press atm press comp)
00 08 53 33 04 91 (5 items @ 2b each)   (injector opening time comp)
00 10 00 00 0F 81 (16 items @ 1b each)  (ignition intake temp comp)
04 00 01 F8 04 91 (5 items @ 2b each)   (boost CEL thresh)
04 00 01 B8 05 91 (6 items @ 2b each)   (boost limit)
00 20 00 00 0F 81 (16 items @ 1b each)  (OL/CL throttle thresh)


I've determined that the map descriptor essentially fits the following format for pseudo-2D maps:

<axis step> <axis start> <number of items - 1> <type> <data>

<type> seems to indicate the following:

0x80: 1 byte for axis values, 1 byte for data values
0x81: 2 bytes for axis values, 1 byte for data values
0x91: 2 byte for axis values, 2 bytes for data values

I'll extrapolate to say that 0x90 likely indicates 1 byte axis values with 2 byte data values.

The main problem I'm having right now is that I can't figure out a reasonable means for decoding the <axis step>. It's certainly the same for maps that use the same steps, and it's definitely different for maps that don't. I'm going to try and figure this out with a disassembler, but I'm not confident that I'll be able to.

As a for instance, though... the map for duty cycle intake air temp compensation looks like this:

10 00 0F 80 4D 53 5A 66 73 7A 80 80 80 80 80 80 80 80 80 80

So, with a type descriptor of 0x80, we see that there are 0x0F + 1 (16) values in the table, and both axis and data items are 1 byte. The axis start value is 0x00, and the step is 0x10.

This results in the following table:

00 4D -> -40C, -19.9%
10 53 -> -30C, -17.6%
20 5A -> -20C, -14.8%
30 66 -> -10C, -10.2%
40 73 -> 0C, -5.1%
50 7A -> 10C, -2.3%
60 80 -> 20C, 0%
70 80 -> 30C, 0%
80 80 -> 40C, 0%
90 80 -> 50C, 0%
A0 80 -> 60C, 0%
B0 80 -> 70C, 0%
C0 80 -> 80C, 0%
D0 80 -> 90C, 0%
E0 80 -> 100C, 0%
F0 80 -> 110C, 0%

The degrees C conversion is derived from an old, barely legible D****ECU screenshot out of Sport Compact Car.

So, the step + start works fine for single-byte axis values, but the two-byte axis values don't seem to have such a straightforward relationship, other than starting properly at the "start" value.

/Andrew
Last edited by Kha0S on Tue Feb 28, 2006 1:23 pm, edited 1 time in total.
Kha0S
 
Posts: 106
Joined: Tue Jan 11, 2005 12:30 pm
Location: MY02 USDM WRX / Nashua, NH

Postby NeverLies » Tue Feb 28, 2006 12:49 pm

Regarding 0x90 type, you are right, I have some in my MAP and data values are coded on 2 bytes.

I was looking at disassembled code and just found same as you for 1 bytes axis definition. 2 bytes axis definition are managed in nearly the same routine (OK, this is the same routine, but since evaluated conditions did not return the same result, it executes some more code) but need to understand once again how it works ...


This means that we can't display these kinds of pseudo 2D maps in ECUEdit right now. Don't know yet what can be the best way to represent this information in XML ??
NeverLies
 
Posts: 179
Joined: Tue Apr 12, 2005 1:49 am

Postby epifan » Tue Feb 28, 2006 12:57 pm

NeverLies wrote:This means that we can't display these kinds of pseudo 2D maps in ECUEdit right now. Don't know yet what can be the best way to represent this information in XML ??

Last versions of ecuEdit support constant axis (only for viewing, built-in map description editor don't support this yet) - thats help to edit "pseudo" 2D maps like Idle speed by temp and etc...
I'm hold up now ecuEdit development BC I'm too busy...
I'm may upload this version if you want :wink:
epifan
 
Posts: 197
Joined: Sat Nov 26, 2005 1:23 am

Postby Kha0S » Tue Feb 28, 2006 1:08 pm

epifan wrote:
NeverLies wrote:This means that we can't display these kinds of pseudo 2D maps in ECUEdit right now. Don't know yet what can be the best way to represent this information in XML ??

Last versions of ecuEdit support constant axis (only for viewing, built-in map description editor don't support this yet) - thats help to edit "pseudo" 2D maps like Idle speed by temp and etc...
I'm hold up now ecuEdit development BC I'm too busy...
I'm may upload this version if you want :wink:


Please do! :D

I have a bunch of maps in my XML as 1D maps right now to get around it. :)
Kha0S
 
Posts: 106
Joined: Tue Jan 11, 2005 12:30 pm
Location: MY02 USDM WRX / Nashua, NH

Postby Kha0S » Tue Feb 28, 2006 1:11 pm

NeverLies wrote:Regarding 0x90 type, you are right, I have some in my MAP and data values are coded on 2 bytes.

I was looking at disassembled code and just found same as you for 1 bytes axis definition. 2 bytes axis definition are managed in nearly the same routine (OK, this is the same routine, but since evaluated conditions did not return the same result, it executes some more code) but need to understand once again how it works ...


Nice to see that I'm not the only one fiddling with this stuff!

Let us know if you make any headway in the disassembly of the 2-byte axis value management and figure out how the incrementor is being used.
Kha0S
 
Posts: 106
Joined: Tue Jan 11, 2005 12:30 pm
Location: MY02 USDM WRX / Nashua, NH

Postby NeverLies » Tue Feb 28, 2006 1:12 pm

Yes, please upload :D

Looking at 2 bytes axis definition and if we refer to your previous example:

05 00 01 B8 05 81 (6 items @ 1b each) (duty press comp)

01B8 is the start value

Will go on to find the relation for the first group of 2 bytes ;)
NeverLies
 
Posts: 179
Joined: Tue Apr 12, 2005 1:49 am

Postby Kha0S » Tue Feb 28, 2006 1:25 pm

Okay, first off... it appears that I had a typo on that pressure map. In going back and checking it again against the ECU data, it's 04 00 01 B8 05 81 ... which seems as if the incrementor might just right-shifted one nibble and added...
Kha0S
 
Posts: 106
Joined: Tue Jan 11, 2005 12:30 pm
Location: MY02 USDM WRX / Nashua, NH

Postby NeverLies » Thu Mar 02, 2006 12:15 pm

OK, got it ;)

Epifan, can you upload your latest release ?

16 bits axis definition is nearly as 8 bits.
First 2 bytes : data increment
Last 2 bytes : start value

Start value is not coded. Increment is : 0x10000 / inc_value

ie : 00 08 53 33 04 91 (5 items @ 2b each) (injector opening time comp)

Start is 0x5333
Increment is 0x10000 / 0x8 = 0x2000 ;)

Enjoy !
NeverLies
 
Posts: 179
Joined: Tue Apr 12, 2005 1:49 am

Next

Return to Tuning Software

Who is online

Users browsing this forum: No registered users and 6 guests