[Ovmsdev] Locations and scripts

[Michael Balzer]

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 at 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 at 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 at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at 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