Skip to content

⚙️ Telematics Engine & Signal Processing ​

The core telematics pipeline in :speed-core (TelematicsEngine.kt) processes raw GPS fixes through mathematical smoothing and state-machine hysteresis to eliminate false alarms and jitter.


🔬 Mathematical Signal Pipeline ​

Raw GPS sensor hardware suffers from multipath reflections, satellite geometry variance, and momentary signal noise. The TelematicsEngine filters raw velocity through three sequential mathematical gates:


1. GPS Confidence & Accuracy Gating ​

Before any velocity reading is processed, TelematicsEngine validates the horizontal accuracy estimate (2σ precision in meters):

🎯 Confidence Validation Gate

A raw GPS fix is accepted only when:

text
horizontalAccuracy <= CONFIDENCE_THRESHOLD (meters, 2σ confidence)

If the device reports poor satellite geometry (e.g. inside tunnels or urban canyons where accuracy exceeds the threshold), the fix is discarded and the SDK emits SpeedData.LowAccuracy. This prevents inaccurate velocity spikes from sounding alarms.


2. Exponential Moving Average (EMA) Smoothing ​

To eliminate erratic velocity jitter from raw GPS sensor readings, the engine applies discrete first-order Exponential Moving Average (EMA) smoothing:

📈 Discrete EMA Equation

text
SmoothedVelocity[t] = α · RawVelocity[t] + (1 - α) · SmoothedVelocity[t - 1]

Where α (alpha) is a proprietary smoothing coefficient calibrated for optimal balance between gauge responsiveness and jitter suppression. The smoothing calculation is securely executed inside the libveg_vault.so Native C++ engine.


3. Dual Schmitt Trigger Hysteresis ​

To prevent "fluttering" alarms (where an alarm rapidly toggles on and off when driving right at the limit boundary), the SDK implements asymmetric Schmitt Trigger Hysteresis:

The SDK utilizes a proprietary, asymmetric trigger/dismissal gap to guarantee that an alarm will not flutter.

  • Activation: The over-speed alarm only sounds when smoothed speed crosses a specific delta above the legal limit.
  • Dismissal: Once active, the driver must decelerate a further delta below the limit before the alarm turns off. These exact threshold deltas are secured in the C++ Native Vault.

⚡ Dual Schmitt Trigger State Machine

Interactive state visualizer: test threshold transitions and hysteresis dampening bands.

✅In Safe Speed Corridor
Current Vehicle Speed:65 km/h
0 (Parked)Min: 40 km/hMax: 80 km/h120 km/h
🅿️
Standby / Parked
Speed ≤ MinLimit (Startup Guard)
↓
Speed > Safe Bound → Arms System
🟢
In Safe Speed Corridor
Normal cruising between 40 km/h — 80 km/h
Trigger: Speed > Upper LimitDismiss: Speed < Lower Hysteresis Bound
🚨
Over-Speed Alert
isOverLimit = true (Red Tones)
Trigger: Speed < Lower LimitDismiss: Speed > Upper Hysteresis Bound
⚠️
Under-Speed Alert
isUnderLimit = true (Amber Tones)
✅
In Safe Speed Corridor

Speed is within the safe driving window. Both alerts are inactive.

isOverLimit: false isUnderLimit: false

Minimum Speed (Under-Speed) Stationary Suppression ​

To prevent annoying false under-speed alarms when navigating stoplights, traffic, or speed breakers, the SDK employs Stationary Suppression. If the vehicle's speed drops below a proprietary crawling threshold, the under-speed alarm is aggressively suppressed. It will only fire if the vehicle is actively driving but failing to maintain the legal minimum threshold.


🚀 Non-Standard Vehicle & Advanced Applications ​

Because TelematicsEngine is pure Kotlin and decoupled from Android UI, it can be applied to non-automotive telematics domains:

1. Consumer Drones (UAVs) ​

  • Use Case: Regulations cap drone speeds (e.g., 100 mph in the US).
  • Application: Drone ground control apps running on Android can pipe UAV telemetry directly into TelematicsEngine using SpeedUnit.MILES_PER_HOUR or SpeedUnit.METERS_PER_SECOND to warn pilots if wind currents push the drone past legal airspeed.

2. Maritime & Marine (Boats & Jet Skis) ​

  • Use Case: Enforcing "No-Wake Zones" (< 5 mph) near harbors and marinas.
  • Application: Marine chartplotters or boat dashboard tablets ingest GPS velocity using SpeedUnit.MILES_PER_HOUR or SpeedUnit.KILOMETERS_PER_HOUR for auditory No-Wake compliance alarms.

3. Light Aviation & Gliders ​

  • Use Case: Low-altitude gliders and ultralights monitoring maximum airspeed limits and minimum stall speeds.
  • Application: Flight tracking tablets pipe velocity vectors into TelematicsEngine using SpeedUnit.METERS_PER_SECOND or SpeedUnit.FEET_PER_SECOND to provide visual corridor guidance.

Released under Commercial Enterprise License. Follow us on LinkedIn | Contact Us.