garygid
Well-known member
Logging with the SOC-Meter:
1. Typically is done via a good RS232-to-USB adapter
2. often connected to a laptop (or similar computer)
3. using a Win Operating System (for example XP, Vista, Win7)
4. running our free CAN-Do (or some compatible) program
5. which reads binary "Messages" sent by the SOC-Meter firmware
6. that runs on our SOC-Meter's AVR-CAN board.
7. The CAN-Do program adds time stamps,
8. and accumulates the Messages into memory.
9. There, the captured CAN-data can be:
a) examined and graphed
b) written to a CAN-Log Binary-Output file.
10. Later, these Log files can be
a) shared with others, or
b) read back into CAN-Do for further investigation.
Although the CAN-data is usually written to a Binary CAN-Log file
so that the data can be accessed later for further analysis,
it might just be used to display a real-time "Dashboard".
(For now, the following is from memory, so corrections might be needed.)
Format of CAN-Do's One-CAN Binary-Output Log file:
1. The one-CAN files contain data from just ONE of the CAN buses
2. are given the following extensions:
a) EV-CAN messages: ".evc"
b) AV-CAN messages: ".avc"
c) CAR-CAN messages: ".can"
d) QC-CAN messages: ".qcc"
These all have 12-byte binary records with the following format:
1. Two bytes of Time-Stamp (SS mm), seconds and milliseconds:
a. The high 6 bits of the first byte (SS) are the seconds, 0 to 59.
b. The low order 2 bits of the first byte (SS) , followed by the whole
second byte (mm), form a 10-bit value, a 0 to 999 count of milliseconds.
Note: In a few older Log files, these two Time-Stamp bytes might be zero.
2. Two bytes of Message ID (HMM) and Data Count (N): (as MM, then NH)
a. The high nibble (4 bits) of the second byte is the Data Count (N = 0 to 8).
Note: Other values of N (like 0xF) may occur for Special Messages.
b. The Low nibble of the second byte (H), followed by the whole first byte (MM)
form the 3-nibble Message ID, 0xHMM, usually between 0x100 (or 0x000) and 0x7FF.
Note: Our special pseudo-messages typically have IDs of 0xF00 to 0xFFF.
In new formats, Messages received with errors might have 0x800 added to
the Message 0xHMM value, to better separate the errors from the good data.
3. Eight bytes of Data:
There are always 8 bytes in the Log file, to make fixed-length "records".
If the data count (N above) is less than 8, the actual data bytes
have 0xFF bytes appended to form a full 8 bytes for the Log record.
CAN-Do refers to these bytes as D1 through D8, but others use the
"computer-talk" designations of D0 through D7. Yes, confusing.
This forcing of the unused bytes to 0xFF should be done where the
messages are collected, so that non-FF values can be used
by CAN-Do to help detect communication and buffering errors.
Format of CAN-Do's Multiple-CAN Binary-Output Log file:
The multiple-CAN Log files:
a) have the ".alc" (all-CAN) extension
b) have 13-byte binary records, a one byte prefix on the
standard one-CAN format described above.
1. One byte prefix for the CAN-Bus (Source) type:
(as I recall ... need to check)
The types are 0 to 4, with:
a) 1 = EV,
b) 2 = CAR,
c) 3 = AV,
d) 4 = QC,
e) 0 = All (messages or time stamps that apply to all types).
f) other values: Reserved
Note: The values 5, 6, 7, and 8 are now used, recalling roughly
as SC and XX for the Tesla S, and GPS (I need to check).
2. The 12 bytes of the One-Can format (see above).
SOC-Meter Message Format (from the AVR-CAN firmware):
Data from the SOC-Meter's Logging Port is an RS232
data stream (8, N, 1) at 115,200 baud, with no flow control.
NOTE: A GOOD RS232-to-USB adapter is needed to handle this data.
An adapter with a "real" FTDI chip is usually a candidate.
(See the "Good RS232-to-USB ..." thread in this sub-forum.)
These are usually 11-byte binary "records" with no specific delimiter, but
now a 13-byte version might be used if a Time-Stamp (SS MM) is included:
1. One Sync Byte to prefix the normal 12-byte message:
which is the EOR (Exclusive OR) of 0x53 with the two following bytes.
To decode, EOR the three sequential bytes, looking for 0x53 as the result.
2. Two bytes (the Message ID and Data Count (MM NH) as described above)
3. Eight bytes of Data (D1 to DN, with 0xFF padding, as described above)
Multi-CAN Message Format (serial incoming to CAN-Do):
Data from some multi-CAN Logging source is a stream of binary
bytes, usually a data stream through a Virtual Comm Port.
These are 14-byte binary "records" with no specific delimiter:
1. One Sync Byte (as described above):
T his is the EOR (Exclusive OR) of 0x53 with the two following bytes.
To decode, EOR three sequential bytes, looking for 0x53.
2. Two bytes (the Message ID and Data Count as described above)
3. Eight bytes of Data (0xFF padded, as described above)
4. Two Time-Stamp bytes, SS MM as described above.
5. One Source-byte, as described above.
Special Messages:
1. Date and Time Messages:
a) These have the 0xFFF message ID, with Data Length = 0xF,
so the "Two bytes of Message ID and Data Count" = 0xFF 0xFF
b) The 8 data bytes include the date and time.
Probably as an 8-byte seconds (and fraction?) past midnight the morning of Jan 1, 1970 ...
(but, at the moment, I do not remember the exact format.)
2. Event Message:
a) These have the 0xFFE message ID, with Data Length = 0xF,
so the "Two bytes of Message ID and Data Count" = 0xFE 0xFF
b) The 8 data bytes are an 8-character ASCII message,
that might have an "Continuation Message" preceeding it.
3. Continuation Message:
a) These have the 0xFFC message ID, with Data Length = 0xF,
so the "Two bytes of Message ID and Data Count" = 0xFC 0xFF
b) The 8 data bytes are an 8-character ASCII message,
that might have another "Continuation Message" preceeding it.
Note: There is a maximum of 2 continuation messages, sent
BEFORE the Event Message.
4. Special-Data Messages:
These usuallu have the 0xFFn message ID, with Data Length = 0xF,
so the "Two bytes of Message ID and Data Count" = 0xFn 0xFF
(where n = 0 through 9, with A, B, and D Reserved)
b) The 8 data bytes will be described later.
Although usually ASCII characters, there MIGHT be binary data.
1. Typically is done via a good RS232-to-USB adapter
2. often connected to a laptop (or similar computer)
3. using a Win Operating System (for example XP, Vista, Win7)
4. running our free CAN-Do (or some compatible) program
5. which reads binary "Messages" sent by the SOC-Meter firmware
6. that runs on our SOC-Meter's AVR-CAN board.
7. The CAN-Do program adds time stamps,
8. and accumulates the Messages into memory.
9. There, the captured CAN-data can be:
a) examined and graphed
b) written to a CAN-Log Binary-Output file.
10. Later, these Log files can be
a) shared with others, or
b) read back into CAN-Do for further investigation.
Although the CAN-data is usually written to a Binary CAN-Log file
so that the data can be accessed later for further analysis,
it might just be used to display a real-time "Dashboard".
(For now, the following is from memory, so corrections might be needed.)
Format of CAN-Do's One-CAN Binary-Output Log file:
1. The one-CAN files contain data from just ONE of the CAN buses
2. are given the following extensions:
a) EV-CAN messages: ".evc"
b) AV-CAN messages: ".avc"
c) CAR-CAN messages: ".can"
d) QC-CAN messages: ".qcc"
These all have 12-byte binary records with the following format:
1. Two bytes of Time-Stamp (SS mm), seconds and milliseconds:
a. The high 6 bits of the first byte (SS) are the seconds, 0 to 59.
b. The low order 2 bits of the first byte (SS) , followed by the whole
second byte (mm), form a 10-bit value, a 0 to 999 count of milliseconds.
Note: In a few older Log files, these two Time-Stamp bytes might be zero.
2. Two bytes of Message ID (HMM) and Data Count (N): (as MM, then NH)
a. The high nibble (4 bits) of the second byte is the Data Count (N = 0 to 8).
Note: Other values of N (like 0xF) may occur for Special Messages.
b. The Low nibble of the second byte (H), followed by the whole first byte (MM)
form the 3-nibble Message ID, 0xHMM, usually between 0x100 (or 0x000) and 0x7FF.
Note: Our special pseudo-messages typically have IDs of 0xF00 to 0xFFF.
In new formats, Messages received with errors might have 0x800 added to
the Message 0xHMM value, to better separate the errors from the good data.
3. Eight bytes of Data:
There are always 8 bytes in the Log file, to make fixed-length "records".
If the data count (N above) is less than 8, the actual data bytes
have 0xFF bytes appended to form a full 8 bytes for the Log record.
CAN-Do refers to these bytes as D1 through D8, but others use the
"computer-talk" designations of D0 through D7. Yes, confusing.
This forcing of the unused bytes to 0xFF should be done where the
messages are collected, so that non-FF values can be used
by CAN-Do to help detect communication and buffering errors.
Format of CAN-Do's Multiple-CAN Binary-Output Log file:
The multiple-CAN Log files:
a) have the ".alc" (all-CAN) extension
b) have 13-byte binary records, a one byte prefix on the
standard one-CAN format described above.
1. One byte prefix for the CAN-Bus (Source) type:
(as I recall ... need to check)
The types are 0 to 4, with:
a) 1 = EV,
b) 2 = CAR,
c) 3 = AV,
d) 4 = QC,
e) 0 = All (messages or time stamps that apply to all types).
f) other values: Reserved
Note: The values 5, 6, 7, and 8 are now used, recalling roughly
as SC and XX for the Tesla S, and GPS (I need to check).
2. The 12 bytes of the One-Can format (see above).
SOC-Meter Message Format (from the AVR-CAN firmware):
Data from the SOC-Meter's Logging Port is an RS232
data stream (8, N, 1) at 115,200 baud, with no flow control.
NOTE: A GOOD RS232-to-USB adapter is needed to handle this data.
An adapter with a "real" FTDI chip is usually a candidate.
(See the "Good RS232-to-USB ..." thread in this sub-forum.)
These are usually 11-byte binary "records" with no specific delimiter, but
now a 13-byte version might be used if a Time-Stamp (SS MM) is included:
1. One Sync Byte to prefix the normal 12-byte message:
which is the EOR (Exclusive OR) of 0x53 with the two following bytes.
To decode, EOR the three sequential bytes, looking for 0x53 as the result.
2. Two bytes (the Message ID and Data Count (MM NH) as described above)
3. Eight bytes of Data (D1 to DN, with 0xFF padding, as described above)
Multi-CAN Message Format (serial incoming to CAN-Do):
Data from some multi-CAN Logging source is a stream of binary
bytes, usually a data stream through a Virtual Comm Port.
These are 14-byte binary "records" with no specific delimiter:
1. One Sync Byte (as described above):
T his is the EOR (Exclusive OR) of 0x53 with the two following bytes.
To decode, EOR three sequential bytes, looking for 0x53.
2. Two bytes (the Message ID and Data Count as described above)
3. Eight bytes of Data (0xFF padded, as described above)
4. Two Time-Stamp bytes, SS MM as described above.
5. One Source-byte, as described above.
Special Messages:
1. Date and Time Messages:
a) These have the 0xFFF message ID, with Data Length = 0xF,
so the "Two bytes of Message ID and Data Count" = 0xFF 0xFF
b) The 8 data bytes include the date and time.
Probably as an 8-byte seconds (and fraction?) past midnight the morning of Jan 1, 1970 ...
(but, at the moment, I do not remember the exact format.)
2. Event Message:
a) These have the 0xFFE message ID, with Data Length = 0xF,
so the "Two bytes of Message ID and Data Count" = 0xFE 0xFF
b) The 8 data bytes are an 8-character ASCII message,
that might have an "Continuation Message" preceeding it.
3. Continuation Message:
a) These have the 0xFFC message ID, with Data Length = 0xF,
so the "Two bytes of Message ID and Data Count" = 0xFC 0xFF
b) The 8 data bytes are an 8-character ASCII message,
that might have another "Continuation Message" preceeding it.
Note: There is a maximum of 2 continuation messages, sent
BEFORE the Event Message.
4. Special-Data Messages:
These usuallu have the 0xFFn message ID, with Data Length = 0xF,
so the "Two bytes of Message ID and Data Count" = 0xFn 0xFF
(where n = 0 through 9, with A, B, and D Reserved)
b) The 8 data bytes will be described later.
Although usually ASCII characters, there MIGHT be binary data.