<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Given Steve's data, a filter would seem to be the best answer to the
sporadic Flatbed alerts. If we're forced to use a distance
threshold, 2km seems a bit large to be a GPS error. Even 1km is
big, but again given the data, that should be sufficient. I think
I've only gotten the alert twice in the over 4 years that I've owned
the car. It's parked in a garage with a second story overhead, and
a metal sectional door to the outside.<br>
<br>
Greg<br>
<br>
<br>
<div class="moz-cite-prefix">Mark Webb-Johnson wrote:<br>
</div>
<blockquote type="cite"
cite="mid:5D84DF04-B73D-45DF-A784-07FFE089664B@webb-johnson.net">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
Steve,
<div class=""><br class="">
</div>
<div class="">Great work. Thanks for tracking this down.</div>
<div class=""><br class="">
</div>
<div class="">The intent of the ‘flatbed’ feature was to alert the
user of the car moving while parked. I don’t think we’re ever
going to be able to alert early enough for the owner to be able
to rush out and stop the theft (even if that was a wise things
to try to do); so perhaps the solution is to simply increase the
threshold. The difference between 500 metres and 2,000 metres,
for example, would not impact the use case much. I suggest that
we simply increase the theft alert radius to 2,000 metres, to
workaround this issue.</div>
<div class=""><br class="">
</div>
<div class="">As to the GPS data itself, perhaps we can smooth out
readings to reduce spikes and invalid values? 200kph is 55
metres in one second. We get readings from the roadster every
10ms, and it is not reasonable to see a difference of 640m or
753m between neighbouring readings. From your data, it seems
that the invalid readings last for some time (several
consecutive readings), so it is not trivial. Perhaps a kalman
filter?</div>
<div class=""><br class="">
</div>
<blockquote style="margin: 0 0 0 40px; border: none; padding:
0px;" class="">
<div class=""><a
href="https://en.wikipedia.org/wiki/Kalman_filter" class=""
moz-do-not-send="true">https://en.wikipedia.org/wiki/Kalman_filter</a></div>
<div class=""><a
href="http://www.cs.unc.edu/%7Ewelch/kalman/Levy1997/index.html"
class="" moz-do-not-send="true">http://www.cs.unc.edu/~welch/kalman/Levy1997/index.html</a></div>
<div class=""><a href="http://kalman.sourceforge.net/index.php"
class="" moz-do-not-send="true">http://kalman.sourceforge.net/index.php</a></div>
<div class=""><a href="https://github.com/lacker/ikalman"
class="" moz-do-not-send="true">https://github.com/lacker/ikalman</a></div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">Some people talking about the issue here:</div>
<div class=""><br class="">
</div>
<blockquote style="margin: 0 0 0 40px; border: none; padding:
0px;" class="">
<div class=""><a
href="https://stackoverflow.com/questions/1134579/smooth-gps-data"
class="" moz-do-not-send="true">https://stackoverflow.com/questions/1134579/smooth-gps-data</a></div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">I suspect that when the Roadster is in motion, the
GPS uses velocity to smooth out its location. But when the car
is parked, it doesn’t have that capability.</div>
<div class=""><br class="">
</div>
<div class="">Regards, Mark.<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On 30 May 2019, at 8:08 AM, Stephen Casner
<<a href="mailto:casner@acm.org" class=""
moz-do-not-send="true">casner@acm.org</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="">I caught one! (An instance of a "vehicle on
flatbed" alert while<br class="">
recording a CAN log of the GPS data.)<br class="">
<br class="">
What I see is a sharp deviation in the GPS position at
the time of the<br class="">
alert. So it may just be that I should set the alert
threshold to a<br class="">
larger value, or perhaps that the default value should
be increased.<br class="">
We might also make the trigger more robust by
considering the rate of<br class="">
change to be consistent with moving the car rather than
a shift in GPS<br class="">
position calculation.<br class="">
<br class="">
The deviation that triggered the alarm was followed by a
deviation of<br class="">
larger magnitude about an hour later, but repeat alarms
are disabled<br class="">
until the car is turned on and then parked again. The
duration of my<br class="">
recording was approximately one day; I should probably
gather more<br class="">
data to see if I get any deviations that are even
larger.<br class="">
<br class="">
I've attached the data and my analysis for others to
view. It is a<br class="">
zip file containing four files:<br class="">
<br class="">
location.crtd is the recording of CAN bus 1 with a
filter for ID<br class="">
0x100 and a hack to keep only records with data.u8[0]
= 83, 84 or<br class="">
85.<br class="">
<br class="">
location.graf is the output of an awk script I wrote
to graph the<br class="">
deviations in the GPS latitude, longitude and
altitude values.<br class="">
These are output as a sequence of three X,Y
timeseries with the X<br class="">
values being GMT timestamps and the Y values being
the difference<br class="">
in the GPS coordinate values relative to the first
sample in the<br class="">
recording. The latitude and longitude values are in
degrees; the<br class="">
altitude values are in megameters to make them
similar in scale to<br class="">
the lat/lon. A fourth timeseries shows the
calculated distance<br class="">
relative to the first sample, again in megameters. A
fifth<br class="">
timeseries shows artificial values to mark GPS lock
transitions;<br class="">
there was no transition near the time of the alert.
I translated<br class="">
the CRTD timestamps to absolute time by equating the
last log<br class="">
timestamp with the log file write time, so there may
be some<br class="">
inaccuracy. The notification I received on my phone
was at 21:30<br class="">
GMT and in the data the spike begins at
1559079188.763 = 21:33:08.<br class="">
<br class="">
wander.png is a large screenshot of the graph
presented by a<br class="">
little graphing tool named graf that runs under X on
*nix and is<br class="">
good for data exploration. If you are interested you
can find the<br class="">
source at <a
href="https://github.com/kernelsid/graf" class=""
moz-do-not-send="true">https://github.com/kernelsid/graf</a><br
class="">
<br class="">
zoomed.png is a screenshot of the same graf session
zoomed in on<br class="">
the spike that triggered the warning.<br class="">
<br class="">
The distance that triggered the warning was 640 meters,
greater than<br class="">
the 500 meter default threshold. The larger distance
that occurred<br class="">
about an hour later was 753 meters.<br class="">
<br class="">
-- Steve<br
class="">
<br class="">
On Thu, 23 May 2019, Stephen Casner wrote:<br class="">
<br class="">
<blockquote type="cite" class="">Finally, after some
travel and other delays, getting back to this<br
class="">
question of the false flatbed alarms. I've started
logging with:<br class="">
<br class="">
OVMS# can log crtd /sd/location.crtd 1:100<br class="">
<br class="">
Plus I've hacked the filter function in canlog to save
only those<br class="">
frames with data.u8[0] = 83, 84 or 85, so the total is
about 5MB per<br class="">
day. I can leave that running for a while.<br
class="">
<br class="">
-- Steve<br
class="">
<br class="">
On Tue, 2 Apr 2019, Mark Webb-Johnson wrote:<br
class="">
<br class="">
<blockquote type="cite" class="">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).<br class="">
<br class="">
I don't think there is any easy way to pre-filter
for B1, so the whole of ID 0x100 would be fine.<br
class="">
<br class="">
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.<br class="">
<br class="">
Regards, Mark.<br class="">
<br class="">
<blockquote type="cite" class="">On 2 Apr 2019, at
2:53 PM, Stephen Casner <<a
href="mailto:casner@acm.org" class=""
moz-do-not-send="true">casner@acm.org</a>>
wrote:<br class="">
<br class="">
I think Mark is requesting "can log trace" rather
than "can log<br class="">
crtd". For the former you have already
implemented rotation of<br class="">
the log files based on max size as configurable in
the web UI, right?<br class="">
<br class="">
-- Steve<br
class="">
<br class="">
On Tue, 2 Apr 2019, Michael Balzer wrote:<br
class="">
<br class="">
<blockquote type="cite" class="">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).<br class="">
<br class="">
The tracing just lacks a file rotation, but that
shouldn't be hard to add.<br class="">
<br class="">
Regards,<br class="">
Michael<br class="">
<br class="">
<br class="">
Am 02.04.19 um 04:58 schrieb Mark Webb-Johnson:<br
class="">
<blockquote type="cite" class="">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).<br
class="">
<br class="">
Regards, Mark.<br class="">
<br class="">
<blockquote type="cite" class="">On 2 Apr
2019, at 10:28 AM, Stephen Casner <<a
href="mailto:casner@acm.org" class=""
moz-do-not-send="true">casner@acm.org</a>>
wrote:<br class="">
<br class="">
Well, for my car this event has occurred
twice in a few months, so the<br class="">
idea of running a CAN bus dump in a wifi
session all the time is not<br class="">
practical. What we would need would be a
CAN bus dump to rotating<br class="">
files, like the error message logging can
do.<br class="">
<br class="">
-- Steve<br
class="">
<br class="">
On Tue, 2 Apr 2019, Mark Webb-Johnson wrote:<br
class="">
<br class="">
<blockquote type="cite" class="">Steve,<br
class="">
<br class="">
<blockquote type="cite" class="">What
should I look for when this false alarm
occurs? Is it likely<br class="">
that the alarm is issued when stable GPS
operation is restored, so<br class="">
what I really would need to see is a log
of conditions before the<br class="">
alarm?<br class="">
</blockquote>
What we would ideally need would be at the
time of the issue:<br class="">
<br class="">
metric list v.p<br class="">
CAN bus dump (can1) ID #100,
B1=0x83,0x84,0x85<br class="">
<br class="">
I appreciate that is hard. Perhaps just
leave a CAN bus dump running<br class="">
over wifi throughout the event? You could
leave that running for<br class="">
hours. We could then replay that back
through a box to recreate the<br class="">
issue.<br class="">
<br class="">
<blockquote type="cite" class="">And now
that I have issued some messages in the
app, how do I switch<br class="">
back to other functions? Is there a way
to make the keyboard drop and<br
class="">
then find the buttons at the bottom of
the screen? (I realize that<br class="">
restarting the app would be a solution.)<br
class="">
</blockquote>
Just click on the screen, away from the
keyboard.<br class="">
<br class="">
Regards, Mark.<br class="">
<br class="">
<blockquote type="cite" class="">On 2 Apr
2019, at 5:47 AM, Stephen Casner <<a
href="mailto:casner@acm.org" class=""
moz-do-not-send="true">casner@acm.org</a>>
wrote:<br class="">
<br class="">
Mark,<br class="">
<br class="">
The false alarm occured again a few
minutes ago. I wanted to use the<br
class="">
web shell UI to check some status, but
using the new messages feature<br
class="">
of the iPhone app I found the wifi was
wedged again. After I turned<br
class="">
wifi off and then back to client mode I
would log in from the web<br class="">
again. I issued a location status
command that indicated good lock.<br
class="">
<br class="">
What should I look for when this false
alarm occurs? Is it likely<br class="">
that the alarm is issued when stable GPS
operation is restored, so<br class="">
what I really would need to see is a log
of conditions before the<br class="">
alarm?<br class="">
<br class="">
And now that I have issued some messages
in the app, how do I switch<br class="">
back to other functions? Is there a way
to make the keyboard drop and<br
class="">
then find the buttons at the bottom of
the screen? (I realize that<br class="">
restarting the app would be a solution.)<br
class="">
<br class="">
-- Steve<br class="">
<br class="">
On Mon, 1 Apr 2019, Mark Webb-Johnson
wrote:<br class="">
<br class="">
<blockquote type="cite" class="">I don't
see this on the Model S vehicle.<br
class="">
<br class="">
I suspect the issue is not handling
GPS lock indicator correctly<br
class="">
in the vehicle modules. For the
roadster, we use ID#100, B1=0x85<br
class="">
(GPS direction and altitude), B2==1 to
control this, but that was<br class="">
always a 'best guess' without much
data to back it up.<br class="">
<br class="">
Regards, Mark.<br class="">
<br class="">
<blockquote type="cite" class="">On 31
Mar 2019, at 11:12 PM, Stephen
Casner <<a
href="mailto:casner@acm.org"
class="" moz-do-not-send="true">casner@acm.org</a>>
wrote:<br class="">
<br class="">
Mark,<br class="">
<br class="">
This message reminds me to mention
that both Timothy Rodgers and I<br
class="">
have received false alarm car-theft
notifications from OVMS. Have<br
class="">
you? I presume these are caused by
temporary inaccuracy in the GPS<br
class="">
signal.<br class="">
<br class="">
-- Steve</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<span id="cid:A646F299-E0C9-43A2-9D31-BE5A0C3A690E"><gps.zip></span>_______________________________________________<br
class="">
OvmsDev mailing list<br class="">
<a href="mailto:OvmsDev@lists.openvehicles.com" class=""
moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a><br
class="">
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a><br
class="">
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
</body>
</html>