<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi Steve,<br>
<br>
Any chance that your car's GPS might have a bad antenna connection,
or some other such issue causing a reduction in GPS accuracy? I'd
rather "suffer" with a false positive once every few years, than
numb the system to the point that I wouldn't be warned of something
amiss until the car is long gone. Your car is clearly "crying
wolf", but I'm wondering if it's the anomaly.<br>
<br>
Greg<br>
<br>
<br>
<div class="moz-cite-prefix">Stephen Casner wrote:<br>
</div>
<blockquote type="cite"
cite="mid:alpine.OSX.2.21.9999.1905301632090.98351@auge.attlocal.net">
<pre wrap="">I let the can log run for another day and this time captured a
deviation of 836 meters. We might need to use 2 km to fix this just
by an increased threshold.
Given that these disturbances may last for several minutes, the filter
would need a fairly long time constant, which would also preclude
running out to stop the theft.
Another approach might be to calculate the velocity of a transition
and block any trigger until the position returned to a value close to
normal. Of course, this depends upon "normal" being determined
correctly. Right now it is the value at the time the car is parked,
which could happen while there is a deviation. It might be better to
use a filter with a long time constant applied to all the readings to
get the true parked position.
-- Steve
On Thu, 30 May 2019, Mark Webb-Johnson wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Steve,
Great work. Thanks for tracking this down.
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.
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?
<a class="moz-txt-link-freetext" href="https://en.wikipedia.org/wiki/Kalman_filter">https://en.wikipedia.org/wiki/Kalman_filter</a> <a class="moz-txt-link-rfc2396E" href="https://en.wikipedia.org/wiki/Kalman_filter"><https://en.wikipedia.org/wiki/Kalman_filter></a>
<a class="moz-txt-link-freetext" href="http://www.cs.unc.edu/~welch/kalman/Levy1997/index.html">http://www.cs.unc.edu/~welch/kalman/Levy1997/index.html</a> <a class="moz-txt-link-rfc2396E" href="http://www.cs.unc.edu/~welch/kalman/Levy1997/index.html"><http://www.cs.unc.edu/~welch/kalman/Levy1997/index.html></a>
<a class="moz-txt-link-freetext" href="http://kalman.sourceforge.net/index.php">http://kalman.sourceforge.net/index.php</a> <a class="moz-txt-link-rfc2396E" href="http://kalman.sourceforge.net/index.php"><http://kalman.sourceforge.net/index.php></a>
<a class="moz-txt-link-freetext" href="https://github.com/lacker/ikalman">https://github.com/lacker/ikalman</a> <a class="moz-txt-link-rfc2396E" href="https://github.com/lacker/ikalman"><https://github.com/lacker/ikalman></a>
Some people talking about the issue here:
<a class="moz-txt-link-freetext" href="https://stackoverflow.com/questions/1134579/smooth-gps-data">https://stackoverflow.com/questions/1134579/smooth-gps-data</a> <a class="moz-txt-link-rfc2396E" href="https://stackoverflow.com/questions/1134579/smooth-gps-data"><https://stackoverflow.com/questions/1134579/smooth-gps-data></a>
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.
Regards, Mark.
</pre>
<blockquote type="cite">
<pre wrap="">On 30 May 2019, at 8:08 AM, Stephen Casner <a class="moz-txt-link-rfc2396E" href="mailto:casner@acm.org"><casner@acm.org></a> wrote:
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 <a class="moz-txt-link-freetext" href="https://github.com/kernelsid/graf">https://github.com/kernelsid/graf</a>
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:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">On 2 Apr 2019, at 2:53 PM, Stephen Casner <a class="moz-txt-link-rfc2396E" href="mailto:casner@acm.org"><casner@acm.org></a> 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:
</pre>
<blockquote type="cite">
<pre wrap="">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:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">On 2 Apr 2019, at 10:28 AM, Stephen Casner <a class="moz-txt-link-rfc2396E" href="mailto:casner@acm.org"><casner@acm.org></a> 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:
</pre>
<blockquote type="cite">
<pre wrap="">Steve,
</pre>
<blockquote type="cite">
<pre wrap="">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?
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">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.)
</pre>
</blockquote>
<pre wrap="">Just click on the screen, away from the keyboard.
Regards, Mark.
</pre>
<blockquote type="cite">
<pre wrap="">On 2 Apr 2019, at 5:47 AM, Stephen Casner <a class="moz-txt-link-rfc2396E" href="mailto:casner@acm.org"><casner@acm.org></a> 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:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">On 31 Mar 2019, at 11:12 PM, Stephen Casner <a class="moz-txt-link-rfc2396E" href="mailto:casner@acm.org"><casner@acm.org></a> 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</pre>
<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>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<br>
</body>
</html>