[Ovmsdev] Locations and scripts

Tue Apr 2 15:43:04 HKT 2019

The ‘can log crtd …’ would be fine. That logs directly to disk, and would be the easiest for a replay (to try to recreate the problem).

I don’t think there is any easy way to pre-filter for B1, so the whole of ID 0x100 would be fine.

If we can get a full crtd trace around the time of the problem, then get told ‘I got a text notification of vehicle on flatbed at 7:50pm on 4th’, we can narrow it down and replay just that part.

Regards, Mark.

> On 2 Apr 2019, at 2:53 PM, Stephen Casner <casner at acm.org> wrote:
> 
> I think Mark is requesting "can log trace" rather than "can log
> crtd".  For the former you have already implemented rotation of
> the log files based on max size as configurable in the web UI, right?
> 
>                                                        -- Steve
> 
> On Tue, 2 Apr 2019, Michael Balzer wrote:
> 
>> I've used the trace command to log high volume CAN traffic, that's no problem (at least with a recent module having the SD speed fix).
>> 
>> The tracing just lacks a file rotation, but that shouldn't be hard to add.
>> 
>> Regards,
>> Michael
>> 
>> 
>> Am 02.04.19 um 04:58 schrieb Mark Webb-Johnson:
>>> I am not sure if the SD is fast enough to store can log files. It would not be too hard to start/stop logging in javascript (without code changes).
>>> 
>>> Regards, Mark.
>>> 
>>>> On 2 Apr 2019, at 10:28 AM, Stephen Casner <casner at acm.org> wrote:
>>>> 
>>>> Well, for my car this event has occurred twice in a few months, so the
>>>> idea of running a CAN bus dump in a wifi session all the time is not
>>>> practical.  What we would need would be a CAN bus dump to rotating
>>>> files, like the error message logging can do.
>>>> 
>>>>                                                       -- Steve
>>>> 
>>>> On Tue, 2 Apr 2019, Mark Webb-Johnson wrote:
>>>> 
>>>>> Steve,
>>>>> 
>>>>>> What should I look for when this false alarm occurs?  Is it likely
>>>>>> that the alarm is issued when stable GPS operation is restored, so
>>>>>> what I really would need to see is a log of conditions before the
>>>>>> alarm?
>>>>> What we would ideally need would be at the time of the issue:
>>>>> 
>>>>> metric list v.p
>>>>> CAN bus dump (can1) ID #100, B1=0x83,0x84,0x85
>>>>> 
>>>>> I appreciate that is hard. Perhaps just leave a CAN bus dump running
>>>>> over wifi throughout the event? You could leave that running for
>>>>> hours. We could then replay that back through a box to recreate the
>>>>> issue.
>>>>> 
>>>>>> And now that I have issued some messages in the app, how do I switch
>>>>>> back to other functions?  Is there a way to make the keyboard drop and
>>>>>> then find the buttons at the bottom of the screen?  (I realize that
>>>>>> restarting the app would be a solution.)
>>>>> Just click on the screen, away from the keyboard.
>>>>> 
>>>>> Regards, Mark.
>>>>> 
>>>>>> On 2 Apr 2019, at 5:47 AM, Stephen Casner <casner at acm.org> wrote:
>>>>>> 
>>>>>> Mark,
>>>>>> 
>>>>>> The false alarm occured again a few minutes ago.  I wanted to use the
>>>>>> web shell UI to check some status, but using the new messages feature
>>>>>> of the iPhone app I found the wifi was wedged again.  After I turned
>>>>>> wifi off and then back to client mode I would log in from the web
>>>>>> again.  I issued a location status command that indicated good lock.
>>>>>> 
>>>>>> What should I look for when this false alarm occurs?  Is it likely
>>>>>> that the alarm is issued when stable GPS operation is restored, so
>>>>>> what I really would need to see is a log of conditions before the
>>>>>> alarm?
>>>>>> 
>>>>>> And now that I have issued some messages in the app, how do I switch
>>>>>> back to other functions?  Is there a way to make the keyboard drop and
>>>>>> then find the buttons at the bottom of the screen?  (I realize that
>>>>>> restarting the app would be a solution.)
>>>>>> 
>>>>>>                                                      -- Steve
>>>>>> 
>>>>>> On Mon, 1 Apr 2019, Mark Webb-Johnson wrote:
>>>>>> 
>>>>>>> I don't see this on the Model S vehicle.
>>>>>>> 
>>>>>>> I suspect the issue is not handling GPS lock indicator correctly
>>>>>>> in the vehicle modules. For the roadster, we use ID#100, B1=0x85
>>>>>>> (GPS direction and altitude), B2==1 to control this, but that was
>>>>>>> always a 'best guess' without much data to back it up.
>>>>>>> 
>>>>>>> Regards, Mark.
>>>>>>> 
>>>>>>>> On 31 Mar 2019, at 11:12 PM, Stephen Casner <casner at acm.org> wrote:
>>>>>>>> 
>>>>>>>> Mark,
>>>>>>>> 
>>>>>>>> This message reminds me to mention that both Timothy Rodgers and I
>>>>>>>> have received false alarm car-theft notifications from OVMS.  Have
>>>>>>>> you?  I presume these are caused by temporary inaccuracy in the GPS
>>>>>>>> signal.
>>>>>>>> 
>>>>>>>>                                                     -- Steve
>>>> _______________________________________________
>>>> 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
>> 
>> _______________________________________________
>> 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