<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
This seems to be a specific issue of the roadster GPS. I never had
or heard of a false alert from the modem GPS.<br>
<br>
Regards,<br>
Michael<br>
<br>
<br>
<div class="moz-cite-prefix">Am 30.05.19 um 04:37 schrieb Greg D.:<br>
</div>
<blockquote type="cite"
cite="mid:d4cb9f39-532b-3f59-fd85-32f251f84057@gmail.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
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"
moz-do-not-send="true">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" moz-do-not-send="true">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev" moz-do-not-send="true">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-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>
<pre class="moz-signature" cols="160">--
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
</pre>
</body>
</html>