I'd also suggest doing this detection in the modem NMEA code already, to prevent feeding false coordinates into the metrics first place. Am 29.06.21 um 09:27 schrieb Michael Balzer:

Craig,

Am 28.06.21 um 21:07 schrieb Craig Leres:

...

Wow, this is a good bug; got another one today (see attached). Is there a reasonable strategy for suppressing these? I'm happy to share recent server logs offline (but I don't post them to the internet/list).

(hint: you should use another tool to cover private information in images…)

How about testing latitude & longitude individually for sudden peaks from their previous average, and discarding a new coordinate completely while such a peak is present?

Regards, Michael

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

The Roadster also having this bug is new to me. Does it show exactly the same bug behaviour? Regards, Michael Am 29.06.21 um 18:05 schrieb Stephen Casner:

For vehicles like the Tesla Roadster that don't use the modem's GPS, putting the detection only in the modem NMEA code would not help.

-- Steve

On Tue, 29 Jun 2021, Michael Balzer wrote:

...

I'd also suggest doing this detection in the modem NMEA code already, to prevent feeding false coordinates into the metrics first place.

Am 29.06.21 um 09:27 schrieb Michael Balzer:

...

Craig,

Am 28.06.21 um 21:07 schrieb Craig Leres:

...

Wow, this is a good bug; got another one today (see attached). Is there a reasonable strategy for suppressing these? I'm happy to share recent server logs offline (but I don't post them to the internet/list).

(hint: you should use another tool to cover private information in images...)

How about testing latitude & longitude individually for sudden peaks from their previous average, and discarding a new coordinate completely while such a peak is present?

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

_______________________________________________ OvmsDev mailing list OvmsDev@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

Steve, Am 29.06.21 um 22:01 schrieb Stephen Casner:

The symptom is false vehicle theft/flatbed alerts. Gregd send a message to ovmsdev about this in his Roadster on 2018-09-17. In May 2019 there was more discussion on the list. I did some logging and caught one of these events and reported it on 2019-05-29.

Over time, the remediations we have discussed on the list were to constrain that alert to the condition of the car being off (parked) and to increase the radius that the jump would need to exceed.

I added the general park distance smoothing on 2019-11-26 to solve this, commit: 8219d4f61cc081b73f45f52b27dd80170b2ef4bd If the issue still is present for the Roadster, new "location" debug logs including the recently added data will show what needs to be done about that. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

On 6/29/21 12:27 AM, Michael Balzer wrote:

How about testing latitude & longitude individually for sudden peaks from their previous average, and discarding a new coordinate completely while such a peak is present?

Overnight I had the idea that instead of looking for specific broken values (0.0, 0.05, etc.) maybe the way to go is to suppress values when the only the latitude or the longitude has a big jump. Maybe something like this: lat1, lon1 // previous position lat2, lon2 // new position tlat = (lat1 + lat2) / 2 delta_lat = haversine(tlat, lon1, tlat, lon2) tlon = (lon1 + lon2) / 2 delta_lon = haversine(lat1, tlon, lat2, tlon) if (delta_lat > simcombugdist && delta_lon < (simcombugdist / 10)) # toss if (delta_lon > simcombugdist && delta_lat < (simcombugdist / 10)) # toss On 6/29/21 12:31 AM, Michael Balzer wrote:

I'd also suggest doing this detection in the modem NMEA code already, to prevent feeding false coordinates into the metrics first place.

That sounds right considering it's a simcom bug we're mitigating. On 6/29/21 9:05 AM, Stephen Casner wrote:

For vehicles like the Tesla Roadster that don't use the modem's GPS, putting the detection only in the modem NMEA code would not help.

Unless the roadster's gps has the same wacky problem with latitude or longitude temporarily jumps to zero (or near zero) and back, I think the roadster should have its own code to deal with gps bugs. On 6/29/21 1:01 PM, Stephen Casner wrote:

What would qualify as exactly the same bug behavior? If it is specifically that the latitude or longitude is reported as 0, that may not be the same. What we see is a sharp deviation in the GPS position.

So both latitude and longitude temporarily jump? The kind of fix we currently have for the simcom gps (and what I'm proposing we do instead) won't help with that. 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. Craig

Craig, Am 30.06.21 um 01:44 schrieb Craig Leres:

On 6/29/21 12:27 AM, Michael Balzer wrote:

...

How about testing latitude & longitude individually for sudden peaks from their previous average, and discarding a new coordinate completely while such a peak is present?

Overnight I had the idea that instead of looking for specific broken values (0.0, 0.05, etc.) maybe the way to go is to suppress values when the only the latitude or the longitude has a big jump. Maybe something like this:

    lat1, lon1 // previous position     lat2, lon2 // new position

    tlat = (lat1 + lat2) / 2     delta_lat = haversine(tlat, lon1, tlat, lon2)

    tlon = (lon1 + lon2) / 2     delta_lon = haversine(lat1, tlon, lat2, tlon)

    if (delta_lat > simcombugdist && delta_lon < (simcombugdist / 10))         # toss     if (delta_lon > simcombugdist && delta_lat < (simcombugdist / 10))         # toss

…or maybe just testing the value deltas for m_latitude & m_longitude in their Updated…() methods. Calculating an actual distance doesn't seem to be necessary here. A sudden jump after having no GPS lock or on init should be considered OK.

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. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26

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