Map format details
Posted: 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
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