⚙️ 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:
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
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.
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
TelematicsEngineusingSpeedUnit.MILES_PER_HOURorSpeedUnit.METERS_PER_SECONDto 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_HOURorSpeedUnit.KILOMETERS_PER_HOURfor 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
TelematicsEngineusingSpeedUnit.METERS_PER_SECONDorSpeedUnit.FEET_PER_SECONDto provide visual corridor guidance.