I really should formally document the CRTD format
properly somewhere. Anyway, here are my old notes on it, and
an example:
+++++
CRTD Example:
1320724293.000 CXX
OVMS Tesla Roadster cando2crtd converted log
1320724293.000 CXX
OVMS Tesla roadster log: trip.20111108.csv
1320724294.072 R11
420 00 96 96
1320724294.073 R11 588 00 00 86
1320724294.073 R11 280 00 00 03 00 00 00 00 00
1320724294.073 R11 001 00 00 00 00
1320724294.073 R11 590 01 00 00 00 00 00 00 00
1320724294.113 R11 400 01 01 00 00 00 00 4C 1D
Generators should use whatever line termination the
host system uses. For Unix and embedded systems that is
LF. Parsers should support all CR, LF, and CRLF variants.
Generators should output hex fields in upper-case and
front zero padded (for clarity). Parsers should support
both upper and lower case, as well as variable length.
By convention, the .crtd extension is used for these
files. It is suggested that generators prefix all crtd
files with CXX lines documenting the generator, comment
and source of log file.
Space-separated fields are:
- Timestamp (can be seconds, milliseconds, or
microseconds - zero prefixed and full length padded
for ms and us).
- Type:
- C*: comment
- CXX: general comment (rest of line is a
comment)
- CEV: user-generated event (rest of line
is event description)
- R11: rx standard frame
- R29: rx extended frame
- T11: tx standard frame
- T29: tx extended frame
Other field notes:
- For the R?? and T?? types, the rest of the
line is hex ID followed by hex data bytes (up to 8).
- In the case of systems supporting multiple
CAN buses, the type can be prefixed with the bus
number (eg; 1R11, 2T29, etc). Messages from different
CAN bus captures can be written to one shared crtd
file, or individual files for each bus - entirely up
to the generator.
+++++
Regards, Mark.
Mark,
I'll add the logging support along with the TX
queue.
Regards,
Michael
Am 10.01.2018 um 01:27 schrieb Mark Webb-Johnson:
Probably best to split this off as a separate
eMail thread.
I think the implementation would be
relatively simple.
- Create a canlog class with a
FILE* m_log member variable, and a virtual
function Log() that is called with a
direction (tx/rx) and frame to log.
- The constructor should be
passed the vfs file path to log to. It
should fopen the m_log file to that.
- The destructor should fclose
the m_log file.
- Create a canlog_crtd class,
derived from canlog, that supports Log() to
log to m_log in CRTD format.
- Optionally create other canlog_*
classes, for other logging formats that we
want to support.
- Add a canlog* m_log member
variable in canbus.
- Initialise m_log to NULL in the
constructor.
- In the destructor, if m_log is
not null, delete it’s object and set it to
NULL.
- Have a command ‘can log’ like
‘can trace’ that specifies a vfs file path
(remember to check it with
OvmsConfig ProtectedPath) and logging
format. It will then ’new’ a canlog_*
style object (depending on logging
format).
- In can::IncomingFrame, log
incoming CAN messages with m_log->Log(),
in the same way as m_trace is handled.
- In canbus::Write, log outgoing
CAN messages with m_log->Log(), in the
same way as m_trace is handled.
Volunteer?
Regards, Mark.
Now SD CARD support is coming,
anybody want to step forward and extend
components/can to support CAN bus
logging to a file (in crtd format, or
perhaps support one or two popular
formats)? Implementation would be in
class canbus, very similar to m_trace;
just need to have a FILE* m_log and
appropriate commands / logging of packet
write/read in the same place that trace
does it.
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________
OvmsDev mailing list
OvmsDev@lists.teslaclub.hk
http://lists.teslaclub.hk/mailman/listinfo/ovmsdev