garygid
Member
I wrote a program to capture CAN data, save in log files, and load logs for
later examination. It allows one to easily graph data from bytes in the messages,
in an attempt to understand the data. The program is called CAN-DO and is
a work in progress (in Visual Basic), but a number of serious investigators
worldwide have used it to examine their CAN data.
We made a CAN capture card using the AVR-CAN board, passively listening
to the LEAF's 500k CAN bus on the OBD connector. We wanted to find a value
for "remaining fuel", which would be more helpful than the "tank fullness"
data that was displayed in 12 coarse steps on the dash.
We were successful, and we created an energy meter that was known as
the SOC-Meter, but more accurately became known as the GID-Meter.
Eventually it displayed Energy, SoC, pack Voltage, Amps, and Power,
and tire pressures, all of which were not available on the LEAF's dashboard.
We could use CAN-DO to investigate the Tesla data. See
GaryG's CAN-Do Program Page for more info.
If I had some Tesla logs, preferably in my 12-byte per message
format, I could do some testing. The 1st 2 bytes contain
second and millisecond, the next two are the msgid and
data length, and then 8 data bytes.
If you are interested, I will provide the exact format of the
SS MS MM LM D1 ... D8 bytes.
Oh well, ...
The time stamp:
MS is the low 8 bits of the 10-bit milliseconds (0 to 999 values),
and the two low bits of SS are the two high bits of the milliseconds.
The top 6 bits of SS are seconds (0 to 59) of the current minute.
The LMMM two bytes is one nibble (L) for the data length (0 to 8)
and the remaining 3 nibbles (MMM) for the hex MessageID (usually
0 through 7FF hex values).
I use MMM 800 to FFF and L > 8 for some special uses
in the log file, like a date-time message at the zero second,
zero millisecond point (so, once a minute, helpful, but optional).
Merry Christmas to all, wishing for a miracle of communication,
understanding, sharing, and peace worldwide. What is the
alternative, just continued war, and perhaps extinction.
later examination. It allows one to easily graph data from bytes in the messages,
in an attempt to understand the data. The program is called CAN-DO and is
a work in progress (in Visual Basic), but a number of serious investigators
worldwide have used it to examine their CAN data.
We made a CAN capture card using the AVR-CAN board, passively listening
to the LEAF's 500k CAN bus on the OBD connector. We wanted to find a value
for "remaining fuel", which would be more helpful than the "tank fullness"
data that was displayed in 12 coarse steps on the dash.
We were successful, and we created an energy meter that was known as
the SOC-Meter, but more accurately became known as the GID-Meter.
Eventually it displayed Energy, SoC, pack Voltage, Amps, and Power,
and tire pressures, all of which were not available on the LEAF's dashboard.
We could use CAN-DO to investigate the Tesla data. See
GaryG's CAN-Do Program Page for more info.
If I had some Tesla logs, preferably in my 12-byte per message
format, I could do some testing. The 1st 2 bytes contain
second and millisecond, the next two are the msgid and
data length, and then 8 data bytes.
If you are interested, I will provide the exact format of the
SS MS MM LM D1 ... D8 bytes.
Oh well, ...
The time stamp:
MS is the low 8 bits of the 10-bit milliseconds (0 to 999 values),
and the two low bits of SS are the two high bits of the milliseconds.
The top 6 bits of SS are seconds (0 to 59) of the current minute.
The LMMM two bytes is one nibble (L) for the data length (0 to 8)
and the remaining 3 nibbles (MMM) for the hex MessageID (usually
0 through 7FF hex values).
I use MMM 800 to FFF and L > 8 for some special uses
in the log file, like a date-time message at the zero second,
zero millisecond point (so, once a minute, helpful, but optional).
Merry Christmas to all, wishing for a miracle of communication,
understanding, sharing, and peace worldwide. What is the
alternative, just continued war, and perhaps extinction.
Last edited:
