Ducati Data Analysis Format - Whitepaper
http://www.ducati.ms/forums/56-superbikes/98440-ducati-data-analysis-file-format-want-import-video.html
DDA Whitepaper (rev0) January 2010
Introduction and General Notes:
The following is an account of my observations after reviewing the contents of a Ducati Data Analyser (DDA) file.
The described format appears true for files generated by the Ducati 1098, 1098S and D16RR models. It may or may not apply to other Ducati models (as more files are observed so this document will be updated).
Each DDA file consists of a header followed by the recorded data. The following data is recorded; engine speed, engine temperature, throttle position, vehicle speed, distance travelled and lap interval. The gear position is derived by dividing the engine speed by the vehicle speed.
The DDA device records the data at 100 hz (or in 0.01 second intervals), and to reduce data traffic (and to save space) only the relevant data is recorded at each time interval.
The data file contains no absolute or relative information relating to time or lap count, it is therefore up to the parser to determine the time applicable to a piece of recorded data and likewise keep track of the lap count.
Regardless of the measurement units set by the motorcycle user, all data is stored as metric units; temperature is stored in degrees Celsius, speed is km/h and distance is kilometres. If an output of another unit system is desired, then it is the parser that must conduct the unit conversions.
All data is stored in “little endian” format (For example the 16 bit hexadecimal value 01A5 (or decimal 421) is stored as A5 01).
This information is provided for your interest; however since I have no input into this data format and additionally no access or insight into the actual data specification or source code I cannot guarantee the accuracy of this information. Likewise as this is a privately controlled data format, it may be changed in the future thus rendering this information as obsolete.
Header:
So far two types header information have been identified, they appear to be listed as either be either version 2 or version 3 (that’s what this will document call them).
For Version 2 and Version 3 headers, the header data itself appears to be added by the application that downloads the information from the DDA dongle since there is no evidence of this data being stored on the DDA dongle.
Version 2 Header:
In this file type, the first 22 bytes are the header. It is identified by the initial hexadecimal characters “02 00” followed by the ASCII characters “DDA” as the first five bytes of the file (or “02 00 44 44 41”). The 22 header bytes are identical for each of the listed bikes and the author has not determined what other additional information is stored therein.
Version 3 Header:
In this file type, the first 296 bytes are the header. It is identified by the initial hexadecimal characters 03 00 followed by the ASCII characters “DDA” as the first five bytes of the file (or “03 00 44 44 41”).
This file type also reserves 2 x 64 byte spaces for the user to store the recording location and the riders name in the data file. Each text entry appears to be a NULL terminated ‘C’ string of ASCII characters. The location string commences at hexadecimal 21 and the name string at hexadecimal 61.
At hexadecimal A0 a 16-byte string exists that seems to determine the file type
0x00A0 – 4 bytes unknown significance – changes between runs 0x00A4 – 2 bytes appear to be “E8 C5” for DTS and “B5 B0” for non-DTS 0x00A6 – 2 bytes “CB 88” or “CC 88”: CB for DTS and CC for non-DTS? 0x00A8 – 4 bytes odometer reading for commencement of run 0x00AC – 4 bytes unknown significance
Samples of data at 0x00A4 6A C4 CC 88 – Desmo D16RR with race ECU (no DTC) 43 17 CC 88 –848 (no DTC) EF C2 CB 88 – Streetfighter S? (DTC) F8 47 CC 88 – 1198S (DTC) B5 B0 CB 88 – 1098S (no DTC)
Speculation, does the DDA store the DTC level here?
The significance of the other characters is still undetermined.
Data Storage (Version 2 and Version 3 Non DTS files):
The following data is stored in the DDA file:
Engine Speed (Revolutions per Minute) Engine Temperature (Degrees Celsius) Vehicle Speed (km/h) Distance (km) Lap Button (100’s of a second) Throttle Position (Percentage)
The data is stored in a tight packed formation with no external time references. It is therefore up to the parser to determine (or calculate) the time for any particular data element. The base unit however is 1/100 of a second (or 100 hz).
All data is stored in metric units and it is the responsibility of the host application to modify the data to the units of measurement preferred by the user.
Data Storage (Version 3 DTS files):
The following data is stored in the DDA file:
Engine Speed (Revolutions per Minute) Engine Temperature (Degrees Celsius) Vehicle Speed (km/h) Distance (km) Lap Button (100’s of a second) Throttle Position (Percentage) DTS Value (Percentage)
The data is stored in a tight packed formation with no external time references. It is therefore up to the parser to determine (or calculate) the time for any particular data element. The base unit however is 1/100 of a second (or 100 hz).
All data is stored in metric units and it is the responsibility of the host application to modify the data to the units of measurement preferred by the user.
Data Elements:
Engine Speed:
Revolutions Per Minute (RPM) – 16 bits every 0.02 seconds
Throttle Position:
Percentage Applied (%) – 8 bits every 0.05 seconds
Engine Temperature:
Degrees Celsius (deg) – 8 bits every 1.00 seconds To calculate actual engine temperature subtract 40 from the stored value. This is the OBDII way of storing temperature such that negative temperatures can also be stored using only positive values (i.e. decimal value 74 corresponds to an engine temperature of 34 degrees Celsius).
Vehicle Speed:
Kilometres per Hour (km/h) – 16 bits every 0.10 seconds The actual vehicle speed is determined by dividing the returned value by 4. As an aside, the OBD standard uses an 8-bit value to record speed, however this gives a maximum possible recorded speed of 255km/h and since the Ducati 1098 can exceed this speed a custom means of storing the vehicle speed was needed.
Distance Travelled:
Kilometres (km) – 24 bits every 1.00 seconds Value is in whole kilometres (NB the figure could be 16 bits as every vehicle I’ve checked has had the value 00 for the final reading – however this would give a maximum odometer recording distance of 65,536 km, so a 24 bit value is logical).
Lap Button:
100ths of a second – 8 bits every 1.00 seconds If the lap button is not pressed, the value FF is recorded. If the lap button is pressed, the number of 1/100ths of a seconds following the previous second is recorded (e.g. if at the 56th second the hexadecimal number 12 is recorded for the lap byte, the lap button was pressed at 0”55’.18). NB this means a maximum of only one lap can be recorded per second.
DTS:
Percentage Applied (%) – 8 bits every 0.05 seconds
Parsing the Data:
As indicated above the data is stored in a tight byte ordered structure with no spaces, checksums or absolute markers. Therefore the synchronisation of the parser to the data is critical and any corruption of the data file will likely result in a failed parsing of the data.
The DDA data stream contains no absolute time or clock data, however the data stream always start on a whole second (i.e. X’ XX.00”) and increments in 0.01 second intervals.
It makes sense that the parser nominally allocates a time of 0’00.00” (or zero) to the start of the data stream (this is not a requirement though)
Reading data:
As the data file is read the parser needs to increment time in 0.01 second intervals in synchronisation with the reading of data stream. As indicated above; no actual time information (or effective data check points) are recorded within the file.
The closest to a data checkpoint is the hexadecimal value FF that is stored once per second (if the lap button is not pressed). Using this marker as a basis might enable a corrupted data file to be partially recovered.
The data is stored in the order:
Speed -> RPM -> Temperature -> Throttle -> Lap -> Distance
Below is an unpacked data stream followed by the packed version of the same.
Time Bytes Data Included (size in bits): 0’00.00” 10 Speed (16), RPM (16), Temperature (8), Throttle (8), Lap (8), Distance (24) 0’00.01” 0 - 0’00.02” 2 RPM (16) 0’00.03” 0 - 0’00.04” 2 RPM (16) 0’00.05” 1 Throttle (8) 0’00.06” 2 RPM (16) 0’00.07” 0 - 0’00.08” 2 RPM (16) 0’00.09” 0 - 0’00.10” 5 Speed (16), RPM (16), Throttle (8) etc. 0’00.95” 1 Throttle (8) 0’00.96” 2 RPM (16) 0’00.97” 0 - 0’00.98” 2 RPM (16) 0’00.99” 0 - 0’01.00” 10 Speed (16), RPM (16), Temperature (8), Throttle (8), Lap (8), Distance (24)
a bike travelling at 25 km/h at 3200rpm with an engine temperature of 87 deg Celsius and 4284 km on the odometer at a steady 20% throttle opening would record the following hexadecimal values in the first 0.10 seconds:
64 00 80 12 7F 14 FF BC 16 00 80 12 80 12 14 80 12 80 12 64 00 80 12 14
Last updated