[Ovmsdev] Locations and scripts

[Michael Balzer]

I've had my first false alert last night, from the log it seems caused by a single false GPS reading.

I've added smoothing over 5 samples to the distance check, that should eliminate the false alerts unless the GPS errors are huge or persistent.

I've also added the coordinates to the notification so we can see how large the error can become if it still occurs.

Regards,
Michael


Am 21.08.19 um 23:43 schrieb Greg D.:
> Hmmpf.
>
> Precession of the GPS constellation, perhaps?  Folks in northern Nevada
> or Idaho should be next...
>
> Greg
>
>
> Stephen Casner wrote:
>> Greg,
>>
>> Mine has been quiet for the past couple of months without increasing
>> the alarm distance beyond the default 500 meters.
>>
>>                                                         -- Steve
>>
>> On Wed, 21 Aug 2019, Greg D. wrote:
>>
>>> A quick follow-up to this thread...
>>>
>>> I've noticed that since this past spring that the number of false alerts regarding the
>>> flatbedding of my Roadster have taken a sharp spike upward. Neither my car's normal
>>> parking spot in the garage, nor the location of my house / garage have changed. The
>>> difference in frequency did not appear to coincide with a firmware update, so I'm at a
>>> bit of a loss to explain it.
>>>
>>> Has anyone else noticed this?
>>>
>>> Did the Government make a change to the GPS satellite fleet?
>>>
>>> Not an issue, really, but definitely something odd going on.
>>>
>>> Greg
>>>
>>>
>>> Stephen Casner wrote:
>>>
>>> Greg,
>>>
>>> Attached are graphs of your data.  gregd.all.png shows all of the
>>> data, and gregd.peak.png is the highest distance deviation of 369
>>> meters, which is less than the default 500 meter threshold.
>>>
>>> It looks like there is a diurnal pattern to the data with increased
>>> deviations around midnight local time (the X axis times are UTC).
>>>
>>> It also looks like your home elevation must be about 380 meters since
>>> the altitude variable drops down to negative that amount frequently,
>>> which would occur when that value is taken as zero (there is a special
>>> case in the code to treat some values as zero).
>>>
>>> I tried overlaying my data and yours, but there seems to be no
>>> correlation between the peaks in my data and the peaks in yours.
>>> Interestingly, my data does not show a similar diurnal pattern.
>>>
>>>                                                         -- Steve
>>>
>>> On Tue, 4 Jun 2019, Greg D. wrote:
>>>
>>> 200mb of logs sent to Steve for analysis....
>>>
>>> Greg
>>>
>>>
>>> Stephen Casner wrote:
>>>
>>> Thanks.  For me, today's log was much quieter.  The maximum excursion
>>> was 115 meters and it was roughly coincident with loss of lock.
>>>
>>>                                                         -- Steve
>>>
>>> On Fri, 31 May 2019, Greg D wrote:
>>>
>>> Ok.  I'll let it run for a few days and see what happens. Not planning to drive the ca
>>> r until next week.
>>>
>>> Greg
>>>
>>>
>>> On May 31, 2019 2:11:31 PM PDT, Stephen Casner <casner at acm.org> wrote:
>>>
>>> On Fri, 31 May 2019, Greg D. wrote:
>>>
>>> Tried this, and am not getting anything written to the file system
>>>
>>> (vfs
>>>
>>> ls /sd shows zero bytes in gps.crtd).  Did I miss some sort of setup
>>>
>>> step?
>>>
>>> Nothing gets written (or at least the file size as reported is not
>>> updated) until the recording is stopped with "can log off".
>>>
>>>                                                        -- Steve
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-- 
Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
Fon 02333 / 833 5735 * Handy 0176 / 206 989 26