I caught one! (An instance of a "vehicle on
flatbed" alert while
recording a CAN log of the GPS data.)
What I see is a sharp deviation in the GPS position at
the time of the
alert. So it may just be that I should set the alert
threshold to a
larger value, or perhaps that the default value should
be increased.
We might also make the trigger more robust by
considering the rate of
change to be consistent with moving the car rather than
a shift in GPS
position calculation.
The deviation that triggered the alarm was followed by a
deviation of
larger magnitude about an hour later, but repeat alarms
are disabled
until the car is turned on and then parked again. The
duration of my
recording was approximately one day; I should probably
gather more
data to see if I get any deviations that are even
larger.
I've attached the data and my analysis for others to
view. It is a
zip file containing four files:
location.crtd is the recording of CAN bus 1 with a
filter for ID
0x100 and a hack to keep only records with data.u8[0]
= 83, 84 or
85.
location.graf is the output of an awk script I wrote
to graph the
deviations in the GPS latitude, longitude and
altitude values.
These are output as a sequence of three X,Y
timeseries with the X
values being GMT timestamps and the Y values being
the difference
in the GPS coordinate values relative to the first
sample in the
recording. The latitude and longitude values are in
degrees; the
altitude values are in megameters to make them
similar in scale to
the lat/lon. A fourth timeseries shows the
calculated distance
relative to the first sample, again in megameters. A
fifth
timeseries shows artificial values to mark GPS lock
transitions;
there was no transition near the time of the alert.
I translated
the CRTD timestamps to absolute time by equating the
last log
timestamp with the log file write time, so there may
be some
inaccuracy. The notification I received on my phone
was at 21:30
GMT and in the data the spike begins at
1559079188.763 = 21:33:08.
wander.png is a large screenshot of the graph
presented by a
little graphing tool named graf that runs under X on
*nix and is
good for data exploration. If you are interested you
can find the
source at
https://github.com/kernelsid/graf
zoomed.png is a screenshot of the same graf session
zoomed in on
the spike that triggered the warning.
The distance that triggered the warning was 640 meters,
greater than
the 500 meter default threshold. The larger distance
that occurred
about an hour later was 753 meters.
-- Steve
On Thu, 23 May 2019, Stephen Casner wrote:
Finally, after some
travel and other delays, getting back to this
question of the false flatbed alarms. I've started
logging with:
OVMS# can log crtd /sd/location.crtd 1:100
Plus I've hacked the filter function in canlog to save
only those
frames with data.u8[0] = 83, 84 or 85, so the total is
about 5MB per
day. I can leave that running for a while.
-- Steve
On Tue, 2 Apr 2019, Mark Webb-Johnson wrote:
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@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@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@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@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
<gps.zip>_______________________________________________
OvmsDev mailing list
OvmsDev@lists.openvehicles.com
http://lists.openvehicles.com/mailman/listinfo/ovmsdev