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