Use WordPad to view this document; Formatting and color coding of examples is used
for clarity.
BR LogFile Structure
General description of logfile data.
In general, each data item in the logfile can have one or more lines of information.
Some of the information is numerical values, but some of it is textual messages.
Below is a discussion that may help to understand the structure.
Note that the logfile is a plain text file, so you can examine it with any text
editor such as notepad. You can also generate logfiles in the simulate mode. In
simulate mode, the OBD data is random, but the general structure of the file is
the same. The ability to quickly generate test files and see them with an editor
may help to understand the descriptions below.
File Header information:
At the beginning of each logfile, there are several lines of information which
indicate it is a valid logfile, and give the date, time, and an (optional) short
user-entered note. Here is an example.
"BR Logfile"
#2005-09-10#
#1899-12-30 14:29:34#
"A short note entered by the user"
Single line entries:
Many data items are logged as a single line of information, and this will be
discussed first. The general structure of the single line entry is as follows:
Monitor Flag , Mode Number , PID Number , "OBDII DATA"
The monitor flag is either 0 or 1, to indicate if the data was taken as a single
shot, or if it was being monitored continuously.
The Mode Number is the OBDII mode which is from 0 to 9.
The PID Number is the OBDII parameter identification number.
The data itself can be either numeric or text.
Here is an example from a logfile:
0,1,13," Vehicle Speed 68 MPH 109 Km/h"
The monitor flag (0) indicates it was a single shot sample. The Mode is 1, the
PID is 13, which is the PID for vehicle speed. The message itself is self
explanatory.
This example was taken while repetitively monitoring RPM.
1,1,12," 355"
Here, the monitor flag is 1. The mode is 1, the PID is 12, which is the PID for
RPM. The text message is simply the numerical value indicating 355 RPM. Note that
monitored data has only the value, but no extra labelling such as " Engine RPM
355".
In some cases, the text message may have imbedded carriage returns, so the data
will appear to be on more than one line when you view it with a text editor, but
the format is still the same. Here is an example of such a case, retrieving trouble
codes;
0,3,0,"MIL indicator lamp is ON
Vehicle Reports 58 Codes stored.
6 Codes were retrieved:
P3451 P2614 P2387 P1621 P2676 P3335"
The monitor flag=0, Mode is 3, which is the mode used for trouble code reading,
and the PID is 0 (mode three actually has no PIDs, so the default is 0). The data
message is actually a single quoted string, but it has imbedded carriage returns
and will appear as multiple lines when examined with text editor.
Special Entries:
Several types of data are written to logfiles which use the same structure, but
the mode and pid numbers are not the actual OBDII mode and pid. They are used only
to indicate these special cases, so they are referred to as artificial modes or
pids. Artificial modes are 256 or greater. The following are examples for each
of these special entries.
0,256,0,"Marker Number 1"
This is a file marker that the user has inserted at a particular position in the
logfile. It has an artificial mode of 256. The pid (0) is meaningless. These allow
the user to establish known reference points that can be quickly accessed during
logfile playback. Note: logfile markers for earlier versions are slightly
different.
1,257,0,#1899-12-30 08:49:31#
This is a timetag entry. Timetags can (optionally) be inserted automatically into
the logfile. They are indicated by artificial mode number 257 (the pid is
meaningless), and they are flagged as monitors.
1,258,1,56.75
1.181113
This is an entry for O2 sensor plot data points. It uses artificial mode 258. The
pid number (also artificial) can be from 0 to 3, and indicates which of four plots
the data belongs to. It uses two separate lines, and the data portions are numerical
rather than quoted strings. The data on the first line (56.75 in this example)
is the sensor voltage or current. The second line (1.181113) is the fuel trim or
lambda value.
Complex entries:
These entries are more difficult to decipher because they can contain imbedded
raw OBDII data, especially bitmapped data. A complete description is beyond the
scope of this tutorial, however, an example of each of these types are shown below
so that you may recognise them. Currently only one complex type exists.
0,7,0,""
24,150,43
"Codes stored after a driving cycle for checking repair work:
6 Codes Received
P0171 C0535 U0045 P0141 P1707 C1220"
OnBoard diagnostics. The first line indicates mode 7, but both mode 7 and mode
1 data actually comprise this multiple line entry. In addition, the second line
contains 3 bytes of bit-mapped information regarding individual tests supported
and completed.
Programming tips:
Example code that may help if you are writing a custom program to extract and process
data from logfiles. It was written in Visual Basic, but may also serve as an example
if you are using another language.
It assumes that you have opened the logfile for reading as sequential input device
#1, and that you have read the first few lines of header information (lofile
identifier string, date, time, User note).
------------------------------------------------
' Define Variables. (Other variables with % suffix are integers)
Dim ReadData1, ReadData2 ' Variant data types
Dim DataMessage as string
'Read in a record & convert to string
Input #1, MonitorFlag%, Mode%, Pid%, ReadData1
DataMessage = CStr(ReadData1)
' Read extra data for special cases
Select Case Mode%
Case 7 ' On board monitor
Input #1, Byte1%, byte2%, byte3% ' Bitmapped data
Input #1, ReadData2 ' Pending (Mode 7) codes.
Case 258 ' O2 sensor plot data
Input #2, ReadData2 ' Second Data point (fuel trim)
End Select
-------------------------------------------------