[Ovmsdev] CAN BUS logging to flash storage
mark at webb-johnson.net
Fri Jan 12 08:44:46 HKT 2018
I really should formally document the CRTD format properly somewhere. Anyway, here are my old notes on it, and an 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).
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.
> On 11 Jan 2018, at 8:59 PM, Michael Balzer <dexter at expeedo.de> wrote:
> I'll add the logging support along with the TX queue.
> 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.
>> Regards, Mark.
>>> On 10 Jan 2018, at 8:07 AM, Mark Webb-Johnson <mark at webb-johnson.net <mailto:mark at webb-johnson.net>> wrote:
>>> 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 at lists.teslaclub.hk <mailto:OvmsDev at lists.teslaclub.hk>
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev <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 at lists.teslaclub.hk
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OvmsDev