Advanced configurations

Custom stop timeout

A trip being analyzed is automatically terminated after a period of inactivity (which begins when the vehicle has stopped). The DriveQuant SDK allows to set the end-of-trip duration.

By default, the trip analysis is stopped after 240 seconds. This value can be tuned according to your need and you can choose any integer values between 120 and 480 seconds by calling the following method:

DriveKitTripAnalysis.setStopTimeOut(180)

If a value greater than 480 is set, the value will be forced to 480.

If a value lower than 120 is set, the value will be forced to 120.

Sharing data during the trip

The Trip Analysis component records the trip locally while it is in progress. The data are recorded with a period of one point per second. At the end of the trip, the SDK requests the driving analysis service and then retrieves the driving indicators.

In addition to this feature, the SDK is also able to share data with the server before the trip is completed. The data is transmitted at a lower frequency with a time interval of one point per minute.

The system for sharing information during the trip can be used in a vehicle fleet management system. This feature requires access to specific APIs. For more information, contact DriveQuant.

Sharing information with the server allows you to store the trip data even if it has been interrupted, and if the data post at the end of the trip could not be performed. This can happen in very rare cases such as the destruction of the mobile phone.

By default, this setting is disabled but you can enable it by calling the following method:

DriveKitTripAnalysis.enableSharePosition(true)

To disable this setting, call the same method with the parameter set to false

DriveKitTripAnalysis.enableSharePosition(false)

Here is the list of data shared every minute by the SDK:

  • Date of trip start.

  • Duration of the trip in seconds.

  • Distance traveled in km.

  • Longitude of the current location.

  • Latitude of the current location.

  • Smartphone battery level.

  • StartMode of the trip recording: manual, GPS-based or beacon-based.

  • Beacon parameters: uuid, major, minor.

Access the trip trigger events

Why use trip triggers?

DriveKit's automatic start mode detects a trip and launches its recording immediately. This operating mode may not be appropriate for all use cases.

Your application may require other information or business logic before enabling the trip recording. For example, it may be appropriate to check that:

  • A connected device is near to the smartphone.

  • The trip recording is acceptable in a given time slot.

In this case, you may want to subscribe to the events that are indicative of the trip start but not necessarily launch the GPS sensor and the trip analysis.

This is why DriveKit allows you to subscribe to trigger events that indicate that a trip has probably started.

How does it work?

By default, this feature is disabled.

To enable this feature, DriveKit Trip Analysis should not be configured in automatic mode but in manual mode.

If DriveKit Trip Analysis is set to automatic mode, the trip will be recorded.

If DriveKit Trip Analysis is set to manual mode and you follow the instructions below, you will be able to listen for trip start trigger events but the trip analysis will not be started automatically.

To listen to trigger events that indicate a start of trip, even if the autostart is disabled, you can call the following method:

DriveKitTripAnalysis.monitorPotentialTripStart = true

Once the feature is enabled, events will be available in the TripListener potentialTripStart() where you initialize the TripAnalysis component:

DriveKitTripAnalysis.initialize(createForegroundNotification(), object: TripListener {
   (...)

   override fun potentialTripStart(startMode: StartMode) {
      
   }
})

The potentialTripStart() method can return all StartMode values ; except MANUAL.

Indeed, a trip manually started is considered as confirmed.

Filter the beacon trigger to start trip recording

In very rare cases, it may be useful to avoid trip detection using the beacon but still need to validate the trip recording only if the beacon is near the smartphone during the trip.

In this case, the beacon is used in trip validation mode but not in trip detection mode.

If this advanced configuration is not used correctly, it may result in poor trip detection performance.

Please never use this feature without contacting DriveQuant to explain your use case and ensure that this particular mode is mandatory.

How does it work?

By default, if you have configured a beacon, its detection by the SDK will start a trip analysis.

In very rare cases (e.g. beacon in a vehicle and parked in close proximity to a living area), it might be useful to avoid the SDK to start a trip when a beacon is detected to reduce smartphone battery consumption.

Please note that beacon scans checks are always performed during the trip analysis, even if the configuration is called.

To disable the ability to start a trip analysis when a beacon is detected by DriveKit, you can call the following method:

DriveKitTripAnalysis.allowBeaconTripStart = false

This feature has no effect if the automatic trip detection mode is disabled.

Configure more than one TripListener

By default, a trip listener can be configured during DriveKitTripAnalysis module initialization using its initialize method.

In certain circumstances, it may not be appropriate to setup it here or it may be necessary for another part of your app to also have access to the TripListener methods.

In this case, you can pass null to the initialize method and/or use the following method to register one or more listeners:

DriveKitTripAnalysis.addTripListener(additionalTripListener)

Then, you can manage your listeners using the following methods:

DriveKitTripAnalysis.removeTripListener(tripListener)
DriveKitTripAnalysis.removeAllTripListeners()

If you remove all your trip listeners or forget to add one, your app will not received any feedback from the trip analysis module. It will not prevent the analysis from working but your code will not be able to execute its own logic (UI updates, notification, etc.).

Do not forget to remove your TripListener when you don't need it anymore to prevent memory leaks.

Last updated