[Ovmsdev] Locations and scripts

Fri May 31 12:56:55 HKT 2019

Greg,

Perhaps we should collect a log of the GPS data from additional
Roadsters (yours?) to see if similar behavior is observed.  The log is
collected with a command like this:

    can log crtd /sd/gps.crtd 1:100

I modified the firmware in my OVMS so it only keeps the frames with
data byte 0 having the value 0x83 - 0x85, but not having that mod just
means the log file would be about 50MB per day rather than 5MB.

                                                        -- Steve

On Thu, 30 May 2019, Greg D. wrote:

> Hi Steve,
>
> 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.
>
> Greg
>
>
> Stephen Casner wrote:
>
> 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:
>
> Steve,
>
> Great work. Thanks for tracking this down.
>
> The intent of the 'flatbed' feature was to alert the user of the car moving while park
> ed. I don't think we're ever going to be able to alert early enough for the owner to b
> e able to rush out and stop the theft (even if that was a wise things to try to do); s
> o 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 t
> hat we simply increase the theft alert radius to 2,000 metres, to workaround this issu
> e.
>
> As to the GPS data itself, perhaps we can smooth out readings to reduce spikes and inv
> alid values? 200kph is 55 metres in one second. We get readings from the roadster ever
> y 10ms, and it is not reasonable to see a difference of 640m or 753m between neighbour
> ing readings. From your data, it seems that the invalid readings last for some time (s
> everal consecutive readings), so it is not trivial. Perhaps a kalman filter?
>
> https://en.wikipedia.org/wiki/Kalman_filter <https://en.wikipedia.org/wiki/Kalman_filt
> er>
> http://www.cs.unc.edu/~welch/kalman/Levy1997/index.html <http://www.cs.unc.edu/~welch/
> kalman/Levy1997/index.html>
> http://kalman.sourceforge.net/index.php <http://kalman.sourceforge.net/index.php>
> https://github.com/lacker/ikalman <https://github.com/lacker/ikalman>
>
> Some people talking about the issue here:
>
> https://stackoverflow.com/questions/1134579/smooth-gps-data <https://stackoverflow.com
> /questions/1134579/smooth-gps-data>
>
> 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.
>
> On 30 May 2019, at 8:08 AM, Stephen Casner <casner at acm.org> 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 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 eas
> iest 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 wou
> ld 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 leas
> t 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 har
> d 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