Systems and methods for receiving sensor data from a mobile device

A source device includes various sensors, such as a GPS receiver. The source device provides operation context data to a server that indicates movement of the source device. The source device may also provide a movement context. The server also evaluates usage of data from the device by other applications or devices to determine a usage context. Based on the movement, operation, and usage contexts, the server selects a frequency at which data is collected for a sensor and a frequency at which the data is transmitted to the server. For example, where the device is not moving or is indoors, less location data is collected. Where no user is tracking the device, location data may be transmitted less frequently and may also be collected less frequently.

BACKGROUND

Field of the Invention

This invention relates to collecting GPS data from mobile devices.

Background of the Invention

Many applications enable a first device to display the movement of another device. For example, ride-hailing services such as Uber or Lyft enable a passenger to view the location of a driver on a map. Such applications require the tracked device to perform GPS (global positioning system) readings and to transmit those readings to the tracking device, such as by way of a server. However, operating a GPS receiver and the radio required for transmission of readings drains the battery on the tracked device and uses cellular data bandwidth.

The system and methods disclosed herein provide an improved approach for tracking mobile devices to reduce power and network bandwidth consumption.

DETAILED DESCRIPTION

When tracking the location of a device, each use of a sensor, such as a GPS receiver, and each transmission of an output of the sensor, such as the location of the device, is a drain on the battery of the device. Accordingly, real-time retrieval of sensor data, such as location, using prior approaches comes at the cost of shortened battery life for the device. The approach described below enables real-time retrieval of sensor data from a device while reducing battery usage.

The solution described below may be understood with respect to two principles. First, the battery cost of transmitting GPS data is about 5 to 10 times the cost of collecting the data. In short, using radio and cellular network on the phone is much more battery intensive than using the GPS receiver. This was established by performing a wide array of experiments on variety of devices and operating systems under different network conditions, and geographies in over a hundred countries.

The second principle is that active tracking sessions are sparse. In a typical tracking session, a user tracking a driver actually looks at the tracking screen less than 20% of the time. This intuitively makes sense as well—if one is tracking a friend on an hour long journey, one might pull out the phone 3-4 times for couple of minutes each. Real time transmission (active-mode) of GPS data is required only during those short periods when someone is actively tracking the device, e.g. a driver. In the remaining time, only enough GPS data need be collected to accurately meter the traveled distance and draw the route taken (passive-mode).

The systems and methods described below provide a variable frequency (VF) model for retrieval of sensor data, such as GPS data. Using this approach, one does not collect and transmit sensor data at a single static frequency. Instead, the system receives an operating context of the device, a movement context of the device, and a usage context of the sensor data. The system then pushes corresponding commands to code executing on the tracked device to collect and transmit sensor data at different frequencies at different points in time. For example, the code executing on the tracked device may be a SDK (software developer's toolkit) integrated into a client application on the tracked device.

For example, in one implementation, when a driver is being actively tracked the system instructs the tracked device to collect movement data (as measured by GPS, WI-FI, BLUETOOTH cellular tower triangulation, etc.) every few meters and transmit it every other second. When active tracking stops, the system changes movement data collection to every 50 meters, for example, and changes transmission to a batch of data every two minutes. This change in transmission frequency from every two seconds to every two minutes has tremendous positive impact on battery life. The benefit is amplified by the fact that the tracked device naturally operates in passive-mode for most of the tracking session.

By decoupling collection and transmission frequency one gains more fine grained control over how the code executing on the tracked device uses resources (battery, network, etc.). By making both these frequencies dynamic, one can harness that control to provide a real time tracking experience to customers with reduced battery usage.

In another example, the operating context of the tracked device includes a percentage of energy capacity available in a battery of the tracked device and whether the tracked device is charging. In this example, a rules engine may periodically evaluate these parameters and selects the frequency values (collection and transmission) corresponding to the current values for these parameters and communicates the frequency values down to the code executing on the tracked device.

The rules engine may take into account other aspects of the operating context of the tracked device or the usage context of the data provided by the tracked device. For example, the identity of the user using the sensor data stream from the tracked device, what activity is the tracked device experiencing during a trip, what latency does a tracking user expect during the trip. Any number of these or other factors may be considered when selecting either of the collection frequency and the transmission frequency.

Referring toFIG. 1, the methods disclosed herein may be performed using the illustrated system100. A mobile device102aincludes a GPS (global positioning system) receiver and possibly other sensors such as a set of accelerometers (e.g.,3axis accelerometer set), gyroscope, magnetometer, pedometer, light sensor, or the like. The mobile device102amay also include antennas and transmitting and receiving circuits for communicating over various wireless communication protocols such as WI-FI, cellular data communication (4G, 5G, LTE (Long Term Evolution), etc.), BLUETOOTH, and the like.

The systems and methods disclosed herein are particularly suitable for tracking of a device102a, accordingly the device102awill most often be a mobile device. However, any device with sensors may be used in accordance with the methods disclosed herein. The methods disclosed herein provide examples regarding the collection of GPS data from a GPS receiver of the device102a. However, the methods disclosed herein may be used to set the collection and transmission frequencies of outputs of any of the sensors of the device102a.

A representation of the outputs of one or more of the sensors may be provided to another device102b, that may be a mobile device, laptop computer, desktop computer, or any other computing device. Accordingly, in the examples disclosed herein, the device102ais referred to as the source device102aand the device102bis referred to as the consumer device102b.

In one example, source device102ais carried by a driver and consumer device102bis viewed by a supervisor of the driver, a customer who requested delivery by the driver, a recipient of an item to be delivered by the driver, or a passenger to be picked up by the driver.

The consumer device102bmay be in communication with a server104providing an API (application programming interface). For example, a client application on the consumer device may issue function calls to the API server104and receive responses that may then be rendered on the consumer device102bor otherwise processed by the client application. The client application may likewise receive and execute function calls from the API server104.

Sensor data from the source device102amay be received by a sensor data broker106. The sensor data broker106may be implemented as an ECLIPSE MOSQUITO (MQTT) broker. The sensor data broker may open a bidirectional TCP (transmission control protocol) connection between the source device102aand the broker106to send and receive data. The protocol used for communication may be MQTT, which is a lightweight protocol that is designed to reduce battery and data usage. The messages may be using QoS (quality of service)1according to the MQTT protocol, which guarantees message delivery. The connection also uses sessions so that messages sent to and from the device102aare not lost in case the device102agoes offline.

The sensor data broker106may both receive sensor data from the source device102aand transmit instructions to the source device102aindicating a frequency that sensor readings are to be collected and a frequency that collected readings are to be transmitted to the sensor data broker106. The server104and broker106may reside on the same server computer or be hosted by different server computers.

A single source device102amay generate a large amount of sensor data. Naturally, the server104and broker106will interface with many source and consumer devices102a,102b. Accordingly, sensor data may be stored in and accessed from a storage solution, such as a database. In the illustrated embodiment, sensor data is stored in an AWS IoT (Amazon Web Services Internet of Things) cloud108(herein after “the cloud108”). The cloud108may also perform data processing as instructed by the API server104in order to offload computationally intensive tasks to the cloud108. As known in the art, the AWS IoT implements “Lambda,” which allows for the execution of code without prior provisioning of computational or storage resources.

An example use of the system100is described below:

1. A driver is on a trip and an SDK (software development kit) programmed to interface with the sensor data broker106is active on the driver's source device102a. At some point in the trip a user (consumer) wishes to track the driver. Accordingly, at step110, the consumer device102bpolls the API server104for location data about the driver as instructed by the consumer.2. In response to this request, the API server104may return the most current location data available to the server for the source device102a. The API server may also push112a message to the sensor data broker106to invoke more frequent collection and transmission of location data by the source device102a.3. The sensor data broker106transmits114a message to an SDK executing on the source device102aincluding an instruction to increase the collection frequency and transmission frequency. For example, the message may be of the format:{“tracking_rules”: {“predicates”: [ ], “default_rule”: {“auto”: true}}, “collection_rules”: {“predicates”: [{“eq,activity.type,stop”: {“result”:{“location.displacement”: 10, “activity.collection_frequency”: 5, “location.collection_frequency”: 5}}}, {“eq,activity.type,walk”: {“result”:{“location.displacement”: 5, “activity.collection_frequency”: 5, “location.collection_frequency”: 5}}}, {“eq,activity.type,drive”: {“result”:{“location.displacement”: 50, “activity.collection_frequency”: 5, “location.collection_frequency”: 5}}}, {“eq,activity.type,run”: {“result”:{“location.displacement”: 10, “activity.collection_frequency”: 5, “location.collection_frequency”: 5}}}, {“eq,activity.type,cycle”: {“result”:{“location.displacement”: 20, “activity.collection_frequency”: 5, “location.collection_frequency”: 5}}}], “default_rule”:{“location.displacement”: 50, “activity.collection_frequency”: 5, “location.collection_frequency”: 5}}, “transmission_rules”: {“predicates”:[{“eq,server.state,consumption”: {“result”: {“ttl”: 300, “flush”: false, “batch_size”: 50, “batch_duration”: 50, “preferred_channel”: “http”}}}, {“and,eq,health.power.charging_status,charging,gte,health.power.battery, 80”: {“result”: {“ttl”: −1, “flush”: false, “batch_size”: 50, “batch_duration”: 5, “preferred_channel”: “http”}}}, {“eq,action.state,assigned”: {“result”: {“ttl”: −1, “flush”: false, “batch_size”: 50, “batch_duration”: 5, “preferred_channel”: “http”}}}, {“eq,action.state,arrived”: {“result”: {“ttl”: −1, “flush”: false, “batch_size”: 50, “batch_duration”: 5, “preferred_channel”: “http”}}}, {“eq,action.state,completed”: {“result”: {“ttl”: −1, “flush”: false, “batch_size”: 50, “batch_duration”: 5, “preferred_channel”: “http”}}}], “default_rule”: {“ttl”: −1, “flush”: false, “batch_size”: 50, “batch_duration”: 300, “preferred_channel”: “http”}}}’”4. In response to receiving the message, the SDK on the source device102astarts collecting and transmitting116location data more frequently at the increased collection and transmission frequencies instructed by the sensor data broker106.5. The sensor data broker106may be bridged to the cloud108and transmit118sensor data received from the source device102ato the cloud108for storage and possibly processing.6. In some embodiments, code executing on the cloud108may respond to messages from broker106with sensor data by generating a call120to the API server104. For example, the call to the API server104may include the sensor data a result of processing of the sensor data by the cloud108(e.g., filtering, ETA calculation, logging, etc., see discussion ofFIG. 4).7. The API server104may then transmit122the result of processing to the consumer device102beither with or without additional processing or modification. The API server104may also store the sensor data received from the cloud108.

Steps116,118,120, and122may be performed repeatedly to enable the consumer device102bto receive updates on the location of the source device102aover time. The API server104or sensor data broker106may also monitor operation of the source device102aand usage of the sensor data (e.g. movement measurements) by the source device102bas reported by the API server104in order to adjust the frequency of collection and transmission. The method by which the frequency of collection and the frequency of transmission are determined is described below with respect toFIG. 3.

Referring toFIG. 2, the API server104, sensor data broker106, and source and consumer devices102a,102bof the system100may operate as part of the illustrated architecture200. For example, the API server104may be programmed to perform functions using sensor data, which may include using services provided by one or more other server systems or on the API server104. These services may include: an ELK server (Elastic Stack)202, Dynamo DB (non-SQL database with document or key-value storage scheme)204, a dashboard206(e.g., interface for viewing key metrics of server performance and operation), RabbitMQ208(a message broker software implementing AMQP (advanced message queueing protocol)), PostgreSQL210or some other SQL (standard query language) database, Redis212or other in-memory database system storage scheme, and one or more worker threads214(“workers214”).

The API server104may also interface with client applications216that request access to interfaces and data exposed by the API server. The client applications216may execute on consumer devices102bor other computing devices.

The API server104may expose a REST (representational state transfer) API over a network, such as the Internet. This REST API may implement an authentication and authorization layer and control a request-response lifecycle. The methods disclosed herein for controlling the collection and transmission frequencies of sensor data may be implemented by this REST API. The REST API may define data structures that map to entities like trips and tasks. The REST API may therefore act as a gateway for retrieving all stored data, which may be stored in a PostgreSQL database210for persistence. The REST API may further define executable code for taking actions described herein. The REST API may be written in Python/Django or other programming language and may run on a uWSGI (Web Server Gateway Interface) or other type of application server. Each application server may run on a single logical instance. The application server may be configured through environment variables and be otherwise stateless. This allows for easy horizontal scaling of instances behind a load balancer.

Workers214may be invoked by the API server104to process sensor data and also take as an input map data218. In particular, location data from a source device102amay be evaluated with respect to map data to determine its movement context as described below with respect toFIG. 3.

The worker threads214may generate events220based on processing of the sensor data. For example, worker threads214may evaluate the operating context of a source device102aaccording to the sensor data and map data218and generate events220to be processed by the API server104or sensor data broker106. For example, events220may indicate that a device102ais within a structure (home, store, etc.) or a public transportation vehicle (ferry, train, bus, etc.). The API server104or sensor data broker106implementing the logic described below with respect toFIG. 3may then process these events220in order to determine an appropriate collection and transmission frequency for one or more sensors of a source device102a.

The workers214may operate in the background to process asynchronous jobs that can be offloaded from the request-response lifecycle. These are jobs that are typically either long running, CPU intensive or not time sensitive. This allows the operator to reduce time spent in processing a request and handle more requests instead. The jobs are put on queue (e.g., RabbitMQ208) and picked up by workers214. Workers214can either be multiprocessing based or event based. The event-based workers214are ideal to handle IO-bound jobs (like pushing webhooks or updating ETAs (estimated times of arrival)) and the multiprocessing workers are ideal for CPU-bound jobs (like filtering location data). CELERY is a python based job processing framework that may be used to implement the workers214.

FIG. 3illustrates a method300that may be executed using the system100, such as using the architecture shown inFIG. 2. The method300may be executed periodically by the API server104or other component of the system100in order to adjust one or both of the frequency and collection and frequency of transmission of data for one or more sensors of the source device102a. For example, the method300may be executed in response to change in one or both of the operating context of the source device102aand the usage context for sensor data from the source device102a.

The method300may include collecting302operating context data received from the source device102. The operating context may include raw sensor data or data characterizing attributes of outputs of one or more sensors of the source device102a. For example, operating context data may include some or all of:measurements from a GPS receiver (e.g., location, altitude, speed, bearing, etc.);Acceleration measurements from a set of accelerometers;A step count from a pedometer;Readings from a gyroscope;Readings from a light sensor;Outputs of a magnetometer; andOutputs of a light sensor.

Any of these outputs may be a series of measurements over time. For example, outputs of sensors that define the operating context may be collected over time for each sensor and then sent as batch according to a transmission interval, upon determination that the sensor outputs indicate a change of sufficient magnitude, or upon receiving a request from the API server104.

Other measurements that may define the operating context may include operational parameters of radios and antennas for communicating according to one or more wireless protocols. For example, usage and signal strength for a cellular antenna and corresponding radio, a WI-FI antenna and corresponding radio, or the like.

The operating context of the source device may include other aspects of the health of the device, such as battery state (percentage of charge remaining), whether the device is charging, available network bandwidth, current processor usage, or other values describing the state of operation of the source device102a.

The collection of operation context302may therefore be considered to include collecting two types of context data (1) activity of the user or carrier of the source device102aand (2) data characterizing the state and health of the device102aas a computing and electronic device.

The method300may include collecting304a movement context of the source device102a. For example, using the GPS location measurements received from the source device102aand map data, step304may include identifying structures, routes, roads, or other entities referend in map data that coincide with the location measurements. For example, a set of GPS locations that lie along a road, train track, ferry route, or the like indicates a movement context of traveling along that road, riding a train on that track, or riding a ferry on that ferry route, respectively. A GPS location within (or within some margin of error from) of a structure such as a store, office, house, sporting venue, or other structure indicate that the movement context is likely the interior of that structure. An output of a light sensor may indicate that the source device102ais indoors or outdoors based on intensity and color of detected light.

The method300may further include collecting306usage context. In particular, the usage context may include whether a representation of the location of the source device102ais currently being requested by or displayed on the consumer device102b. In one example, the usage context may include whether a process executing on the API server104is currently processing data from a particular sensor. In yet another example, access to output of a sensor for the source device102amay be performed by issuing an API call to the API server104(see step110,FIG. 1). Accordingly, the usage context may be whether such as call has been received, the number of such calls during a time window (e.g., the last 1-5 seconds or some other interval), or some other descriptor of API calls requesting sensor data or a representation of sensor data for a particular sensor of the source device102a.

The method300may further include setting308a collection frequency and setting310a transmission frequency for one or more sensors of the source device102aaccording to the operating context, movement context, and usage context. An instruction may be pushed312to the source device102athat instructs the source device102ato collect and transmit data according to the values selected at steps308and310. For example, the instruction may list for each sensor for which a collection frequency and transmission frequency was set (e.g., changed relative to previous values), the new values for the collection frequency and transmission frequency for the each sensor.

The manner in which the collection frequency and transmission frequency are set may be determined by a rules engine that is programmed to handle particular scenarios for the contexts of steps302-306. Table 1, below, summarizes the various sensors and other components of the source device102athat may be used to establish the operating context of the source device102a. Note that some devices are used directly to define the operating context whereas others indicate the operating context only indirectly.

Table 2 summarizes how a rules engine would adjust the collection and transmission frequency for a particular operating context and movement context of the source device102a. Table 2 applies to the usage context of another application tracking the source device102a, e.g. a user on a consumer device102brequesting tracking of the source device10a. Table 3 provides example of how the collection and transmission frequencies may be adjusted based on the operating context and movement context where the usage context is that no application is currently tracking the source device102a.

The values for frequencies and other values in Tables 2 and 3 are exemplary only. The frequencies and values for each scenario (operation, movement, and usage contexts) may be understood to illustrate the relative magnitude of frequencies relative to other scenarios listed. Unless otherwise noted herein the word “about” shall be understood to indicate within 25% of the following value.

TABLE 1Sources for Operating ContextType of Use(directly/indirectly/Sensor nameintended)DescriptionGPSdirectlyFor collecting locationAccelerometerdirectlyFor detecting current activity likewalking, running, cycling andstopping of a userGyroscopedirectlyFor detecting current activityPedometerdirectlyFor detecting if current activityof user is walking or runningMagnetometerintendedFor detecting whether a user isindoors or outdoorsWi-Fidirectly +Directly: for detecting whether aindirectly +user is connected to the Internet.intendedIndirectly: for getting locationsthrough hotspots location usingfused location API provided byOS.Intended: Use Wi-Fi hotspot tofind out whether a user isindoor/outdoorCellulardirectly + indirectlyDirectly: for detecting whether auser is connected to the InternetIndirectly: for getting locationsthrough cell tower triangulationusing fused location APIprovided by OS.Light sensorintendedFor detecting whether a person isindoor or outdoor or vehicle typeif he/she is moving (car/bike)

TABLE 2Rules for Selecting Collection and Transmission Frequencies During TrackingDataOperatingtransmissionContextruleData collection ruleDescriptionUser isNoGPS data is collected atSince the device is notstopped at atransmissiona very low frequencymoving there is no needplace. GPS(e.g., about every 30 min).to transmit any data.locationsUser's activityGPS data collection iswithin timedata is collected todone at a very lowperiod (e.g.,check if the user hasfrequency (e.g., aboutabout everystarted walking orevery 30 min).30 seconds)driving. If yes then theHowever, data fromare separatefrequency of GPS dataother sensors likeby less than acollection is increasedaccelerometer etc. isthreshold(e.g., when there is acollected withoutdistance (e.g.,change of, for example,transmission to find outabout 2about 50 meter in user'swhen the user hasmeters)location or about everystarted moving, so that10 seconds, whicheverthe GPS data collectionis earlier),can again be started ifIn other embodiments,required.an exponential backoffmay be implemented,e.g., keep lowering thefrequency (subject tosome minimum) untilmovement is detectedUser isThe frequencyOS on source deviceHelps to collect andmovingof data102a is instructed totransmit data in real(condition fortransmission isperform collectiontime.user beingvery high (e.g.,based on distancestopped is notabout every 5moved (e.g., when theremet)seconds)is a change greater thanabout 50 m or afterabout 5 seconds,whichever is earlier).User isThe frequencyOS on source deviceIf a user is walking andwalking andof data102a is instructed totheir walking speedthe adjacenttransmission isperform collectioncomes out to be moredata points arevery high (e.g.,based on distancethan the speed a normalfar from eachabout every 5moved (e.g., when therehuman can walk, thenother (theseconds)is a change greater thanthere was likely an errorcalculatedabout 20 m or afterin data. It makes sensespeed ofabout 5 seconds,then to increase the datawalking basedwhichever is earlier),collection frequency soon this data isas to improve accuracy.greater thanabout10 Km/h).User isThe frequencyOS on source deviceIf the location points aremoving,of data102a is instructed tobeing mapped to twohowever thetransmission isperform collectiondifferent roads, thenlocation pointsvery high (e.g.,based on distancethere is somethingare beingabout every 5moved (e.g., when therewrong with the locationincorrectlyseconds)is a change greater thantracking. It makes sensemapped toabout 20 m or afterthen to increase the datatwo differentabout 5 seconds,collection frequency soroads.whichever is earlier),as to improve accuracy.User isThe frequencyOS on source deviceSince the user is movingdriving at aof data102a is instructed toat a very high speed on avery hightransmission isperform collectionroad, it is likely that thespeed (greaterhigh (aboutbased on distanceuser will keep onthan about 60 mph)every 20moved (e.g., when theremoving on that road forseconds).is a change greater thana while (next 30-60about 200 m or afterseconds). So theabout 20 seconds,transmission speed andwhichever is earlier).the collection frequencycan be marginallylowered

TABLE 3Rules for Selecting Collection and Transmission Frequencies Without TrackingOperatingData transmissionData collectionContextruleruleDescriptionUser isthe frequency of dataOS on source deviceTo save on battery, wemovingtransmission is very102a is instructed tosend this data in bulklow (e.g., aboutperform collectionwith very lowevery 30 min)based on distancefrequency (about everymoved (e.g., when30 mins)there is a changegreater than about50 m or after about10 seconds,whichever is earlier).GeofenceVariable frequencyVariable frequencySince the user is notexpected closedepending on howdepending on howbeing tracked live,to user'sclose the user is to aclose the user is to adata transmission canlocationgeofencegeofence. If the userbe done at a muchIf the user is moreis more than 500 mlower frequency.than 500 m awayfrom the geofence,However, there arefrom the geofence orthen collect dataevents which need tomoving away fromwhen there is abe triggered which canthe geofence thenchange greater thanbe missed if thekeep theabout 50 m or sayfrequency is low.transmissionafter 10 seconds,Therefore, increase orfrequency low (e.g.,whichever is earlier,decrease the frequencyabout every 1 min).If the user is lessbased on user'sIf the user is lessthan about 500 mproximity to thethan 500 m from thefrom the geofencegeofence location.geofence andthen collect dataGeofence locationmoving towards thewhen there is acould be a structuregeofence thenchange greater than(home, office, store) orincrease theabout 20 m or aboutany area of interest.transmissionevery 5 seconds,frequency to verywhichever is earlier.high (e.g., aboutevery 5 seconds)

The scenarios of Tables 2 and 3 are exemplary only and various other scenarios are contemplated. For example, the movement context may indicate that the user is within an area such as a building, public transit vehicle (bus, train, ferry, airplane), or other defined area. Movements of the user within that area may be of little concern for tracking purposes. Accordingly, the movement context may be determined by evaluating the location of the source device102aas reported to the API server104with respect to a geofence or other boundary defined for the area.

Whether the source device102ais indoors may also be determined by evaluating relative strength of Wi-Fi and cellular signals received by the source device102a. Where Wi-Fi signals are above a pre-defined Wi-Fi threshold and the cellular signal is below a pre-defined cellular threshold, the source device102amay be determined to be indoors. Likewise, an output of the light sensor of the source device102amay be consistent with being indoors. Where the location of the source device102atravels at a speed and route corresponding to a train track or ferry route, the source device102amay be determined to be on a train or in a ferry. Where the route, speed, and location of the device102acorrespond to the route, speed, and expected location of a bus or other public transit vehicle according to transit schedule, the device102amay be inferred to be on that public transit vehicle.

Upon determining that the source device102ais in a defined area having a rule associated with it by the rules engine, the API server104may instruct the source device102ato collect data at a collection frequency and transmit data at a transmission frequency while the source device is within the area as defined by the rule for the defined area. In general, this collection frequency and transmission frequency will be lower than the collection frequency and transmission frequency when the source device102ais not within an area having a rule associated with it by the rules engine.

Note that the above rules relate primarily to collection of GPS data. However, the collection frequency and transmission frequency of any of the other sensors described herein may be controlled according to operation, movement, and usage contexts in the same manner as desired by a developer. For example, a pedometer output may be collected and transmitted at high frequencies when the operation context indicates the source device102ais indoors whereas the collection and transmission of GPS data is performed at relatively lower frequencies when the source device is indoors.

Referring toFIG. 4, the illustrated method400may be used to filter sensor data received from a source device102a, such as data collected and transmitted at frequencies determined according to the methods described above.

The sensor data that is received on the API server104may be written to a database such as one or both of Redis212and PostgreSQL210. A job may be queued to process the sensor data. One of the workers214may then pick up the job from the queue and read the data from the database, such as from the Redis212. Redis212may also store all pre-context for the data just received. Pre-context may be defined as context data (operation, usage, movement context data as defined above) that was received from the source device102aprior to receiving collected and transmitted sensor data. Storing all of this data on Redis allows for fast reads that speeds up execution time significantly.

The sensor data may be filtered according to the steps of the method400. These steps may be performed in the order shown or may be reordered in other embodiments.

The method400may include filtering402the data points in the sensor data according to accuracy. For example, in the case of a GPS point, the signal strength as received from the GPS satellites may be recorded and transmitted with the data points. Accordingly, in periods where there are not a minimum number of satellites with signal strengths above a signal strength threshold, GPS readings during those periods may be discarded

The method400may further include removing404indoor points. Whether a point is indoors may be determined using geofencing, detected Wi-Fi and cellular signal strengths, GPS signal strengths, proximity of GPS points to a structure, or any other approach for determining whether a device is located indoors. Indoor points tend to have a lot of noise and are therefore typically not useful for tracking.

The method400may further include de-clustering406points. This step removes points that are located close to one another, e.g. within a predetermined distance threshold, causing a line connecting them to zigzag.

The method400may include removing408distance anomalies. In particular, this may include removing points that are located a predetermined maximum distance from a trace defined by other points in a stream of points from the source device102a.

The method400may further include applying410a map-based filter that attempts to match points to the nearest road, route, or other trace that can be traversed by a vehicle or pedestrian. For example, this may include applying the OSM (Open Street Map) filter to the GPS points.

Once all the filters are run, the filtered data may be stored412in PostgreSQL and may be used as the accurate location stream for any purpose. For example, recalculating estimated times of arrival (ETAs), generating live polylines, and generating events based on the location of the source device102a.

For example, an ETA model may calculate an ETA based on 3 values:1. Checkout time—time taken from start to get on the road2. Transit time—time taken on the road3. Checkin time—time taken to get off the road and complete the task

At the start of a task, all three values are estimated and an initial ETA is calculated. For 1 and 3, a simple statistical average is used and for 2, maps services are used (Google maps or OSM setup).

After device data from the source device102ais filtered, such as according to the method400, a job is queued to recalculate the ETA to take into account the latest known information, i.e. ignoring 1 if the source device102ais traversing the route and calculating the transit time of 2 from the last known position of the source device102ain the filtered data. The ETA may be recalculated and stored in PostgreSQL as the current ETA. This is the ETA may be displayed on a dashboard206and provided to the consumer device102bthat is tracking the source device120a.

Other values that may be of interest based on GPS data may include a status (on time, delayed, detoured), mileage traveled by a driver, or any other application for GPS location data.

In another example, the API server104may generate events220in response to filtering or based on calculation of an ETA. For example, these events may denote a deviation from previous state (like task is delayed or the source device102ais moving away from destination). Once an event is created for an account, the event may be queued, such as on RabbitMQ208, to be sent as a webhook. If the account has configured webhooks, these events may be delivered to the configured endpoint (e.g., a consumer device102b) for that webhook by a worker214. In some embodiments, webhooks wait for a delay (e.g., about 2 seconds) for the endpoint to receive the data and send an acknowledgment of successful receipt. In some embodiments, if a webhook cannot be delivered successfully, it's retried a specified number of times (e.g., three) until it can be delivered with an exponential back off.

In another example, metrics may be collected from the source device102a, such as battery usage and data usage by the source device102a. Code executing on the source device102a, e.g. an SDK, may send device battery information in request headers with every request. The data usage may be estimated by the API server104based on the payload size of the requests. These metrics may be collected by the API server104for every request coming from the source device102aand stored in a database. For example, the DynamoDB204may be used, which is a low latency, high throughput, NoSQL db which allows easily querying aggregate metrics.

In another example, logs of device data from multiple applications may be sent to the ELK server202for processing according to an ELK stack. The logs may be indexed and stored by the ELK stack. For example, the ELK stack may include the following logical units:1. Logstash—Processes log messages and converts them to a structured JSON (JavaScript Object Notation). The Logstash may also hosts the different input methods for different sources. For example, API server logs and Mosquitto broker logs may be sent over rsyslog and app logs may be sent over MQTT.2. Elasticsearch—Logstash produces a structured JSON output which is stored by Elasticsearch. All the logs are indexed to be searchable.3. Kibana—Kibana is the frontend for Elasticsearch on the web. It hosts the web interface to search the log data stored in Elasticsearch. It also allows visualizations on top of log data.4. Curator—Curator is a daily cron job that deletes indexes older than 10 days on Elasticsearch. This keeps Elasticsearch lean and fast.

FIG. 5is a block diagram illustrating an example computing device500. Computing device500may be used to perform various procedures, such as those discussed herein. A computing device500may be used to implement the source device102a, consumer device102b, API server104. The services in the architecture ofFIG. 2may also be implemented by a server having some or all of the attributes of the computing device500.

Computing device500includes one or more processor(s)502, one or more memory device(s)504, one or more interface(s)506, one or more mass storage device(s)508, one or more input/output (I/O) device(s)511, and a display device530all of which are coupled to a bus512. Processor(s)502include one or more processors or controllers that execute instructions stored in memory device(s)504and/or mass storage device(s)508. Processor(s)502may also include various types of computer-readable media, such as cache memory.

Memory device(s)504include various computer-readable media, such as volatile memory (e.g., random access memory (RAM)514) and/or nonvolatile memory (e.g., read-only memory (ROM)516). Memory device(s)504may also include rewritable ROM, such as Flash memory.

Mass storage device(s)508include various computer readable media, such as magnetic tapes, magnetic disks, optical disks, solid-state memory (e.g., Flash memory), and so forth. As shown inFIG. 5, a particular mass storage device is a hard disk drive524. Various drives may also be included in mass storage device(s)508to enable reading from and/or writing to the various computer readable media. Mass storage device(s)508include removable media526and/or non-removable media.

I/O device(s)510include various devices that allow data and/or other information to be input to or retrieved from computing device500. Example I/O device(s)510include cursor control devices, keyboards, keypads, microphones, monitors or other display devices, speakers, printers, network interface cards, modems, lenses, CCDs or other image capture devices, and the like.

Display device530includes any type of device capable of displaying information to one or more users of computing device500. Examples of display device530include a monitor, display terminal, video projection device, and the like.

Interface(s)506include various interfaces that allow computing device500to interact with other systems, devices, or computing environments. Example interface(s)506include any number of different network interfaces520, such as interfaces to local area networks (LANs), wide area networks (WANs), wireless networks, and the Internet. Other interface(s) include user interface518and peripheral device interface522. The interface(s)506may also include one or more peripheral interfaces such as interfaces for printers, pointing devices (mice, track pad, etc.), keyboards, and the like.

Bus512allows processor(s)502, memory device(s)504, interface(s)506, mass storage device(s)508, I/O device(s)510, and display device530to communicate with one another, as well as other devices or components coupled to bus512. Bus512represents one or more of several types of bus structures, such as a system bus, PCI bus, IEEE 1394 bus, USB bus, and so forth.