[Ovmsdev] GPS location glitch (flatbed theft false alert)

[Michael Balzer]

On the e-Up / Mii / Go, we still occasionally (seldom) get a false 
flatbed alert.

I've tracked this down to our "vehicle is on" heuristic, which is 
currently taking the 12V level as an indicator. That turns out to be 
unreliable: in the cases of the false alerts, the DC converter output 
did not rise above 13.1V, which is normal "awake" level.

The "vehicle.on" event is necessary for the GPS logic to recognize the 
car is about to drive, i.e. leaving the parking position. Without the 
event, the location module sees movement while still assuming parking.

So in case you still get these false alerts, enable event logging and 
check if your car reliably emits "vehicle.on".

Regards,
Michael

PS: @UpMiiGo crew: I'll test some other options for our vehicle.on logic.


Am 30.06.21 um 19:39 schrieb Craig Leres:
> On 6/30/21 1:05 AM, Michael Balzer wrote:
>>> Another (possibly far fetched) idea I had was is it possible we' 
>>> seeing corruption transferring the gps location from the simcom to 
>>> the esp32? A race condition where the latitude or the longitude gets 
>>> clobbered while reading it? I don't have a good idea of what other 
>>> symptoms that kind of problem would have.
>>
>> Actually… not far fetched at all, as we continuously see multiplex 
>> frame errors in the logs -- see my previous posts on this. We don't 
>> have flow control on the ESP-SIMCOM serial line, and the handler may 
>> not catch all losses.
>>
>> You can test that theory by enabling the verbose log on "gsm-nmea". 
>> Be aware that's a lot of log messages.
>>
>> Better option: I already do some consistency checks in 
>> GsmNMEA::IncomingLine(), but I didn't implement the NMEA checksum. 
>> You might give that a try first.
>
> Ooooh NMEA... Yeah, if we're getting errors there I can guess where 
> the 0.0's are coming from; gps2latlon() uses atof() so if the field it 
> tries to parse is empty or is a non-numeric, it'll return 0.0.
>
> I'll spend some time looking at that module, at a minimum implementing 
> the checksum is worth doing.
>
>         Craig

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20210817/b4e869c7/attachment.sig>