FS - Handling of GPS Drift

Introduction
Device Model
Current Platform Handling
0 lat / long
Satellite count <= 3
Handling In Platform
Condition : Distance
Action : Back-fill
Exceptions / Assumptions
Implementation Notes
Effect of processing on various features
Implementation modifications (22/10)
Reference

Introduction
Sometime abnormal trip distance is getting reported on AerTrak. This occurs only once in a while. And this condition cannot be replicated. We
have seen rare occurrence of this event, in the range of 0-1% w.r.t overall trips reported.

The main cause of this issue is - device has not been able to fix the GPS and hence send lat/long that are far away from actual location of the
vehicle (sometime upto 1000 km away). Due to this the trip lengths get elongated and customer who relies on trip data to bill their end customer
may end of billing with wrong data

This document captures action that can be taken to mitigate this problem.

JIRA - AERTRAK-13696 - Getting issue details... STATUS

Device Model
This issue has been primarily reported on -

Concox/ Mackk devices

CalAmp devices - it is reported only in one specific condition (i.e. when ‘0’ Lat/Long)
Teltonika & Volty devices - not reported yet

Current Platform Handling

Following cases are already handled at platform level -

0 lat / long

Device Model : All TCP and UDP devices as check is implemented at the Adpater level and in both TCP and UDP Adapter

Handling : Last known GPS payload Lat/Long Coordinates are back-filled in current GPS payload

Satellite count <= 3

Device Model : Concox devices (check is implemented in mackk-lmu parser)

Handling : Last known GPS payload Lat/Long Coordinates are back-filled in current GPS payload

Note:

Analysis of 15 days of data was done to assess the quality of this check -

Drop due to satellite count

Env Total Pkts 3 2 1 0

India 6,94,46,757 12,06,581 5,888 348 0

 Singapore 7,21,45,356 16,98,526 646 292 0

The 0 satellite packets that are being dropped are from other than Mackk devices where 0 lat/long is coming along with satellite count as 0.

Packets that are being dropped (back-filled) due to satellite count=3 makes about ~2% of the traffic. 2% looks higher and some sampling should
be done to evaluate if these are really the packets that have lat/long which indicates drift or correct packets

Handling In Platform

Condition : Distance

Whenever a new packet arrives at adapter level, it shall compute distance between current packet and last saved location except -

If it is first packet from device (distance is 0)

If the time difference between current packet and last saved packet is more than a threshold (say 24 hours - to be defined as an env
parameter - ADAPTER_GPS_DRIFT_TIMECHECK_IN_SEC)

Two distance threshold are defined -

1. ADAPTER_GPS_DRIFT_DISTANCE_LIMIT_IN_KM_LOW = 2 km
2. ADAPTER_GPS_DRIFT_DISTANCE_LIMIT_IN_KM_HIGH = 10 km

These threshold will get applied on the basis of ignition transition based on following table

Previous ignition state Current ignition state Remarks Threshold to use

OFF OFF Parking state ADAPTER_GPS_DRIFT_DISTANCE_LIMIT_IN_KM_LOW

OFF ON Start of a new trip ADAPTER_GPS_DRIFT_DISTANCE_LIMIT_IN_KM_LOW

ON ON On going trip ADAPTER_GPS_DRIFT_DISTANCE_LIMIT_IN_KM_HIGH

ON OFF End of trip ADAPTER_GPS_DRIFT_DISTANCE_LIMIT_IN_KM_HIGH

Action : Back-fill

It has been noticed that speed reported in the packet is incorrect along with lat/log, so -

Back-fill current GPS payload Lat/Long values with last saved Lat/Long (which may not be from previous packet as this GPS drift
condition can last for more than 1 packet)
Back-fill speed value from last saved value
Back-filling is done only for Lat/Long and speed, rest of the values are persevered, e.g.,
ignition ON / OFF value - so it will not affect the start and stop of the trip

Exceptions / Assumptions

In case of GSP drift, only lat/long & speed values are incorrect, i.e.,
Ignition ON / OFF is reported correctly
From the data analysis it has been inferred that drift condition does not last long, i.e., number of drifts packets are few (single digit)
Hence to take care of false positive detection of GPS drift - a check SHOULD be put to not back-fill after n packets (n has been set to 30)
Assuming that first detection of condition is faulty.
The packets that are coming are healthy and does not belong to GPS drift condition

Implementation Notes

1. These checks should be implemented in a common library and shall be used by all the adapters so that same behavior is applied to all
types of devices (device agnostics).
2. ENV variables are platform specific - no account specific thresholds
3. Remove the Satellite Count (<=3) check
Effect of processing on various features

This section list impact analysis of the proposed change on the existing features of AERTRAK -

S. Feature Impac Remarks

No ted

Trips Yes The movement from previous point A to point B will not be added in the distance - so if there are multiple points in a trip it can
affect the trip distance.

Since packets are preserved (back-filled with previous location) so addition of time to compute trip duration will not be
impacted.

Vehicle Yes Vehicle will continue to stay at previous location but last updated time will change
Status

Alerting Yes All Alerts will be generated based on the previous LAT/LONG instead of location

Speed Alert Yes As previous packet speed is preserved in the new packet so speeding alert will get impacted.

Tow Alert Yes A drifted packet during Tow Alert Calculation will get replaced by same lat/long thus resetting the condition for Tow Alert - so
we may miss Tow alert in this case

Store n No In case of Concox devices it has been seen that Alert packets come out of sequence with respect to GPS data so it can affect
forward the distance calculations

LIFO / NA Since we are considering this for FIFO devices so effect of this computation on LIFO packets is not evaluated / considered
FIFO

Implementation modifications (22/10)

1. As per the Oct'MW implementation, certain false positive cases got reported.
2. We re-looked and performed more data analysis.
a. Packet Delivery Span
i. ~93% of data packets comes within 1 min time intervals
1. Maximum Distance in the range of 2-7km
ii. ~3% of data packets comes within 1 -2 min time intervals
1. One case of 165km Drift
iii. ~2% of data packets comes within 2-10 min time intervals
1. One case of 165km Drift
iv. ~2% of data packets comes > 10 min time interval
1. Maximum Distance in the range of 2-10km in IGN ON
2. Maximum Distance in the range of 19km in IGN OFF
3. Final Recommendation
a. Delta Distance Threshold: 20 km this has been further reduced to 10 km as per request from SE / Operation and GSOC team
for reducing drift cases for Godawari
b. Virtual Speed Threshold: 150 kmph
i. Assuming this is the maximum speed of our vehicle on our Platform
c. Maximum of Backfilled Data Points: 30
i. In general drift is in 1-5 packets, only in one case we have seen in 17 packets, so keeping it 30 as conservative number
d. We will keep single threshold both for IGN ON & OFF
e. Check with the Delta Distance between 2 Contiguous payloads
i. Delta Distance < 20km, it is normal packet, No Drift.
ii. Delta Distance > 20km,calculate Delta Time & Delta Speed based on Delta Distance & Time.
1. If Delta Speed > 150kmph , then it is Drift,
2. If Delta Speed < 150kmph , then it is No Drift
f. This means error threshold for our system is 20km
4. Attached below are the Excel files for reference purposes (GPSDrift_2210, GPSDriftData_Oct14_16_BigQuery,
GPSDriftData_Oct14_16_BigQuery_DeviceSpecific

Reference
1. Mail-1 from @ Rakesh Gupta (Deactivated) - GPS Drift_ Abnormal Trip Distance Issue .msg
2. GPS Drift Data Analysis for 28 vehicles, GPS Drift_Abnormal_Trip_Data Analysis.xlsx
3. Mail-2 from @ Rakesh Gupta (Deactivated) for Threshold recommendation, RE GPS Drift Abnormal Trip Distance Issue .msg
4.
4. GPSDrift_2210.xlsx
5. GPSDriftData_Oct14_16_BigQuery.xlsx
6. GPSDriftData_Oct14_16_BigQuery_DeviceSpecific.xlsx
7. 12/Jul/2021 - Device and Operation team has initiated a new page - Drift Handling Requirements