ElanScan file format

[Giniw]

Hello Everyone,
Lately I have reversed the ElanScan file format; most bytes were not too hard to guess but I am puzzled about the last 4 bytes I don't know: offset 4 to 7 (first byte being at offset 0), which is to say the second four bytes integer (?) which value seems always equals to 1.
As the following bytes are about the comment, I wonder whether it could be related to it and just be a sizeof(char) of something like that but that is just a wild guess (it could be a file format version too, or just about anything )
Of course I may ignore that value but when I change it to anything other than 1 Elanscan is crashing, so it is actually used.
Any hint would be much appreciated
Thanks in advance!!

[GeoffSmith]

Quick check of my notes Julien:

Header is 273 bytes:-
0x0000-0x0003: Data size (bytes)
0x0004: Always 0x01 and used by ES
0x010A: Always 0x47?

To help with my hardware development etc., I also save raw data (minus the 273 byte header) and use .est (ElanScan Turbo).

I keep meaning to ask ESM about the 5th byte as I foresee it being useful if, for example, sat nav coordinate data is tagged onto the end of each row it could be set to 0x02.

[Giniw]

0x0004: Always 0x01 and used by ES

Thank you, so at least your observations are the same than mines.

To help with my hardware development etc., I also save raw data (minus the 273 byte header) and use .est (ElanScan Turbo).

Would you need a .est import/export too? I can add that to my todo list.

I keep meaning to ask ESM about the 5th byte as I foresee it being useful if, for example, sat nav coordinate data is tagged onto the end of each row it could be set to 0x02.

Maybe, it's hard to guess :/
Actually my last attempt was to look at the ElanScan file opening routine disassembly but it's not that easy for me

PS: as for 0x010A I don't remember but I probably found what it is used for because I only missed that 1 integer.
I will tell you what I think it is when I have my notes.

[Giniw]

0x010A: Always 0x47?

PS: as for 0x010A I don't remember but I probably found what it is used for because I only missed that 1 integer.
I will tell you what I think it is when I have my notes.

I just had a look in my notes and 0x47 is (?) the size of one "packet" stored by ElanScan (the data from the ECU minus the header and checksum, plus the timestamp)
So indeed it's probably a constant in a given version of ElanScan.

[Hogflash]

I am also working on reversing the ElanScan file format and think I have the header figured out - I have seen two versions of the header, one without comments (old) and one with a 256-byte null-padded comment field.

What is driving me crazy is figuring out how all the (apparent) 8-byte records are interpreted. Looks to me like there are three record types: 0x00, 0x39, and 0x40.

Does anyone have any hints on how to extract the actual data from these?

Thanks,

Gary

[Giniw]

Hello and welcome Hogflash!
I don't have any infos with me here and can't remember all the details but apart from the header the rest is more or less just the frames transmitted from the ECU along with a timestamp (I think it's just a double but that is just from my memories)

PS: I would be interested if you can upload a file with a different header ^^ (on the other hand I believe old versions of elanscan are still available anyway. Thanks for the hint!)

[Hogflash]

OK, after a bit more work I have identified three header types. Type1 and Type2 are probably obsolete, but the files are loaded just fine by ElanScan. Type3 is much more directly useful and contains the raw ECM data. I am attaching a few of the older files (circa 2003) for you to examine. One is original, one has a comment added and resaved, and the third has the comment removed and saved. Take a look at the binary for these!

Here is how the formatting looks to me:

File Headers:
I have identified three types of file headers:
Type1 is 24 (0x0018) bytes long and contains no comment. The frame size byte is at index 0x17.
Type2 is 280 (0x0118) bytes long and includes a 256 byte null-padded field. The frame size byte is at index 0x117.
-- The header is prefixed by Uint32 DataByteCount and Uint32 FileID (unknown usage)
-- The DataByteCount must be multiplied by 8 and have the header length added (0x0011 or 0x0111) to equal the file size
-- The last byte of the header is the frame size identifier byte.
-- The Type2 comment size byte is at index 0x08, and the (256-byte null padded) comment text field immediately follows
-- Type1 has the sequence 0x00, 0x40, 0x00, 0x00 at index 8. I use this to seperate type 1 and 2 altho DataByteCount could also be used.
-- The data frame is composed of multiple 8-byte chunks of (currently) unknown format.
-- Each 8-byte chunk apparently represents one byte with the exception of the timestamp.

Type3 is 273 (0x0111) bytes long, and is prefixed by Uint32 DataByteCount and Uint32 FileID (assigned == 0001;)
-- The frame size byte is at index 0x109.
-- The comment size byte is at index 0x08, and the (256-byte null padded) comment text field immediately follows

If a Type1 file with no existing comment is edited to add comments is then saved in ElanScan, it is converted to type2.
If a Type2 or Type3 file is edited by ElanScan and the comments zero'd out and the file saved, the comments
still exist in the file but the length specifier is set to zero and they no longer display in ElanScan!
It seems that Type1 files are always converted to Type2 when resaved with current software versions

--For Type3, the data frame is the raw ALDL bytes minus its 3-byte header and checksum PLUS an 8-byte timestamp at the end. The timestamp is a little-endian IEEE double containing the time in seconds.
For the Elan, the ALDL data payload size is 63 bytes. The timestamp is an additional 8 bytes for a total frame size of 71 (0x47) bytes.

Gary

edited 07-feb-2018: corrected type3 frame timestamp information and a few typos

Drive home log 2.zip