NVH Spectro — L'instrument NVH dans votre poche

202

tests JVM, joués à chaque push

≥ 90 %

couverture du moteur, imposée par la CI

0

erreur lint, sans baseline

9

gates d'hygiène qui cassent la build

Fonctionnalités

Une chaîne de mesure complète

Du microphone du téléphone au rapport client, chaque étape est outillée — et chaque nombre sait d'où il vient.

🌈

Spectrogramme temps réel

FFT 512→4096, calibration Hann exacte (0 dBFS lu 0 dBFS). Deux vues : niveau absolu et indice d'émergence NVH. Fenêtre, plage dB et plage fréquence réglables en direct.

⚙️

Suivi d'ordres GMPe

Cinématique V1000, rapport global ou chaîne détaillée (réducteur × pont × pneu). Projection H1/Hn, étiquetage des harmoniques émergentes, rapport d'émergence accumulé.

🛰️

Vitesse GNSS par Kalman

Vitesse Doppler du GPS interne, filtre Kalman [vitesse, accélération] avec covariance, rejet des fixes aberrants. Chaque estimation porte son âge, son σ et sa validité.

📂

Analyse WAV & vidéo

Import WAV (parser RIFF complet) et extraction audio des vidéos locales, analysés à leur propre fréquence d'échantillonnage. Télémétrie rejouée par lissage RTS.

📄

Rapports traçables

Enregistrement 30 s audio + télémétrie, mode rapport manuel avec tracé assisté, export PNG et PDF avec cartouche : date, build, source, route micro, paramètres, statut de vitesse.

♿

Conçu pour le terrain

Thème sombre calibré habitacle, contrastes WCAG testés par la CI, TalkBack, cibles 48 dp, dégradation par permission annoncée à l'écran.

Spectrogramme complet d'un fichier de 5 minutes en mode émergence NVH — Vue émergence NVH d'un fichier de 5 minutes — curseur fréquence, balises d'harmoniques, axe temporel complet. Les sous-30 Hz sont masqués à l'affichage ; les données restent vraies.

Comment ça marche

Deux capteurs, une projection

Le téléphone capte deux signaux : le son habitacle (microphone non traité) et la vitesse (Doppler GNSS). La physique du véhicule relie les deux.

Le budget d'erreur, pas un simple curseur

L'incertitude de vitesse σv se propage en RPM puis en fréquence : σf(Hₙ) = n · σv · 1000 / (60 · V1000). La fenêtre de recherche du pic vaut k·σf + Δf — assez large pour contenir la vraie raie, bornée à mi-distance de l'ordre voisin : au-delà, le suivi s'affiche « non identifiable » plutôt que d'inventer une valeur.

Le temps, pris au sérieux

La vitesse est évaluée à l'instant de capture du buffer audio (horloge BOOTTIME matérielle d'AudioRecord), pas à l'instant du calcul. Un fix périmé rend la vitesse indisponible : l'écran affiche "--" plutôt qu'un dernier chiffre figé.

Une mesure qui connaît ses limites

La confiance se construit en disant non

Un instrument crédible refuse de répondre quand il ne peut pas répondre. NVH Spectro applique cette règle partout.

🔒 Zéro réseau, par construction

La permission INTERNET n'est pas déclarée — et la CI échoue la build si elle réapparaît, comme toute surface WebView/JS. Enregistrements, télémétrie et journaux ne quittent l'appareil que par un export explicite.

📉 "--" plutôt qu'un chiffre mensonger

Vitesse périmée, GNSS désactivé, fix simulé : la vitesse devient indisponible au lieu d'être figée. Un 0,0 km/h réel est affiché tel quel — l'absence de mesure et l'arrêt du véhicule sont deux informations différentes.

🏷️ Des métriques nommées honnêtement

L'indice d'émergence NVH est un indicateur maison, pas un TTNR ECMA-74 : le rapport PDF le dit en toutes lettres en bas de page. Aucun libellé normatif ne couvre un calcul non conforme.

🧾 Chaque rapport dit comment il a été fait

Cartouche de traçabilité : date, version, source, route micro réellement obtenue (UNPROCESSED / VOICE_RECOGNITION), estimateur de vitesse et ses paramètres, statut « causale » ou « lissée (RTS) », niveau de confiance k.

Transparence totale : le projet porte ses propres audits — un audit d'origine à 74 constats, un audit GNSS dédié, et un audit courant à 31 constats, tous publics dans le dépôt, constats cités en fichier:ligne.

Sous le capot

Deux modules, une séparation vérifiée

Le moteur de mesure est du Kotlin pur, testé sur JVM à chaque push. La couche Android ne fait que l'interface et les capteurs.

:core — Kotlin pur, zéro import Android

FFTProcessor · OrderTrackingEngine · OrderSearchPolicy
KalmanSpeedEstimator · GnssSpeedSession
MeasurementSession · WavAnalysis · TelemetryCodec

≥ 90 % de couverture de ligne, imposée par la CI. Un import Android qui réapparaît casse la build.

:app — Android & Compose

CaptureEngine (un seul propriétaire du micro) · SpeedProvider
LiveViewModel · AnalyzerViewModel · ReportViewModel
RecordingStore · SettingsStore · export/ (PNG, PDF)

202 tests JVM, snapshot doré DSP (tolérance 1e-9), zéro erreur lint sans baseline.

Architecture détaillée → Référence API complète (128 types) →

Documentation

Tout est écrit, tout est public

Le projet est piloté par des documents versionnés : audit → plan → journal d'exécution avec preuves. Rien n'est déclaré fait sans preuve d'appareil.

🔬 Méthodes DSP & émergence

Calibration FFT, modèle d'émergence, suivi d'ordres — les maths, avec leurs limites assumées.

🛰️ Chaîne de vitesse GNSS

Qualification des fixes, Kalman à covariance, fenêtres σ, reconstruction RTS.

🏗️ Architecture & flux de données

Modules, session partagée, threads, cycle de vie des ressources.

✅ Qualité, CI & audits

Les gates, les 202 tests, les audits publics et les notes affichées.

Démarrer

Compiler en 3 commandes

Prérequis : JDK 17 et le SDK Android (compileSdk 36, minSdk 24).

# cloner
git clone https://github.com/Luigi-BARTH/NVHSpectro.git && cd NVHSpectro

# vérifier (tests, couverture ≥ 90 % :core, lint, gates d'hygiène)
./gradlew :core:test :app:testDebugUnitTest :core:koverVerify :app:lintDebug

# installer sur l'appareil connecté
./gradlew :app:installDebug

Ouvrir le dépôt GitHub ↗ Premiers pas dans l'app →

Au premier lancement, accordez micro et localisation précise : le micro devient la source de mesure, le GPS alimente la projection d'ordres. Sans eux, l'app reste utilisable en analyse de fichiers — et elle l'explique à l'écran.