Mark, when implementing the can log framework I introduced the CAN_LogMsg_t specifically to capture the original timestamp of the frame, so it wouldn't get lost if the logging task gets behind, and to transport other log data types than just frames to the loggers. I would also expect the RE tools stream to produce event info & statistics entries like can log does, as that is very helpful in analysing. Maybe rebasing candump on can log would be better? Regards, Michael Am 11.06.19 um 08:37 schrieb Mark Webb-Johnson:
This really should be unified, and probably not too hard to do. Crazy to have two so similar frameworks. I think we can just have one virtual class for converting CAN frames to/from other formats, and then implementations for CRTD, PCAP, etc.
I do remember that last time I looked at this, canlog used CAN_LogMsg_t, and candump used CAN_frame_t (with CAN_LogMsg_t having some other fields for logging statistics, etc), and that made it non-trivial. Perhaps canlog should be built on top of candump?
I will have a look at it.
Regards, Mark.
On 6 Jun 2019, at 4:06 PM, Michael Balzer <dexter@expeedo.de> wrote:
Steve,
Mark quoted from the RE tools candump_crtd class, which has its own crtd formatter.
For the canlog framework I currently get the timestamp from esp_log_timestamp(). Should be easy to change that to gettimeofday().
Regards, Michael
Am 05.06.19 um 18:39 schrieb Stephen Casner:
Mark,
If by "unix julian time" you mean a timestamp like 1559751698 (the time as I write this), than that is not what Greg and I have observed in the CRTD logs. Here are the first lines in our files:
151766.574 CXX Info Type:crtd; Path:'/sd/gps.crtd'; Filter:1:100-100; Vehicle:TR2N;
383603.293 CXX Info Type:crtd; Path:'/sd/location.crtd'; Filter:1:100-100; Vehicle:TR1N;
Yet OVMS does have the current time from NTP:
OVMS# time Time Zone: UTC Time: 2019-06-05 16:35:45 UTC Local Time: 2019-06-05 16:35:45 GMT Provider: ntp
PROVIDER STRATUM UPDATE TIME *ntp 1 57 Wed Jun 5 16:35:44 2019
Who calls candump_crtd::get() with the timeval that goes into the sprintf() you mention?
-- Steve
On Wed, 5 Jun 2019, Mark Webb-Johnson wrote:
The CRTD timestamps should be unix julian time (not uptime). Produced by this:
sprintf(m_buf,"%ld.%06ld %sR%s %0*X", time->tv_sec, time->tv_usec, busnumber, (frame->FIR.B.FF == CAN_frame_std) ? "11":"29", (frame->FIR.B.FF == CAN_frame_std) ? 3 : 8, frame->MsgID);
Once module gets time from the vehicle (or gps), it should show the correct timestamps.
Regards, Mark.
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/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.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26