Trip recording lifecycle
Last updated
Last updated
Before you start, we recommend that you install the DriveKit Demo App and perform some testing to get familiar with the SDK's behavior and features.
The DriveKit Demo App integrates all components of the DriveKit SDK and you can refer to the code before installing the Trip Analysis component in your mobile application.
You can find all resources on Github.
In order to understand how the smartphone telematics SDK works and how it will transform your app into a powerful sensor, take the time to read the following section that explains briefly the expected behavior.
The DriveKit SDK (TRIP ANALYSIS component) has the ability to automatically detect and record a trip when your application runs in background.
Before integrating the Trip Analysis component into your application, it is recommended that you understand how it works. This section explains the main states of the SDK during a trip as well as the events that trigger the transitions between states.
The diagram below shows, from top to bottom:
Events that trigger the transition from one state to another,
Main SDK states,
Accessible callbacks that your application can use to implement your own business logic.
Here is a brief description of the sequence of trip analysis from A to Z. Beneath the braces, the list contains all the methods that can be called at each stage of a trip's recording.
Trip Detection: the SDK does not start instantly at the beginning of the trip. There is a variable delay during which the application identifies that a trip might be in progress. If the probability is high enough, the application turns on the GPS sensor and starts to analyze the vehicle's speed.
Trip confirmation: the trip is not validated immediately. Beforehand, the SDK checks if the trip speed is consistent with that of a motor vehicle. If this is not the case, the trip will be canceled naturally and no data will be stored locally (and no data will be transmitted to the DriveQuant's server).
Trip Recording: if the trip is confirmed by the SDK, then the data are recorded locally for the entire trip.
End of Trip Detection: the SDK can determine if the trip is completed. Each time the vehicle stops, a timer starts to check whether the stop is definitive or not. Depending on your needs, it is possible to set a time delay for stopping a trip. The default timeout value is 4 minutes. You can adjust this value between 2 and 8 minutes.
Trip Analysis: once the trip has been completed, the SDKs automate the request to the trip analysis API. If the smartphone is not connected to a mobile network, the request will be retried later.
The use of the DriveQuant SDK has a minimal impact on the driver's smartphone data plan. Data consumption is a topic that users of your application may be concerned about, so we have done our best to limit the amount of data used by the SDK.
The trip data are recorded with a frequency of 1Hz and are transmitted in text format. The volume of data recorded is about 5 kb per minute of driving:
50 kb of data are used for the analysis of a short 10-minute trip,
150 kb of data are used for the analysis of a 30-minute trip,
A 2-hour long trip uses 600 kb of data.
The average data usage for a commuter working 30 minutes from home will be in the range of 10 Mb to 12 Mb per month.
The DriveKit SDK measures data from smartphone sensors while minimizing the impact on the battery. It automatically detects the start and end of a motorized trip and does not use the GPS sensor outside of the trip.
This helps to avoid draining the phone's battery and protects the user's privacy. Location data from the phone are not collected outside of the phases where the user is driving.
