update of trace_signal_fitter.py and some doc

Reverse-Engineering CAN-Bus/HOW-TO-REVERSE.md

@@ -0,0 +1,90 @@
+# HOW-TO_REVERSE – Praxisleitfaden fürs CAN-Reverse-Engineering
+
+Dieses How-To ist dein Werkzeugkasten, um aus nackten Frames echte Signale zu destillieren. Es ist kein Orakel, sondern ein **Experimentier-Protokoll**: miss, verifiziere, falsifiziere. Nutze es zusammen mit der GUI/CLI (Splitter, Explorer, Batch-Analyzer, Range-/Unsupervised-Fit).
+
+---
+
+## 0) Vorbereitungen (Daten sammeln wie ein Ingenieur)
+- **Zustände trennen**: *Zündung an*, *Motor aus*, *Motor an Leerlauf*, *Schieben*, *aufgebockt Hinterrad drehen*, *kurze Fahrt*.
+- **Aktoren toggeln**: Blinker, Bremse, Licht, Lüfter → generiere Ground-Truth für Bits/Flags.
+- **Nur RX** analysieren, wenn deine Hardware parallel TX sendet (Störmuster vermeiden).
+
+---
+
+## 1) Frame- & ID-Ebene zuerst
+- **Repetition Rate (Hz)**: Zyklische Sensor-IDs senden stabil.
+  - *Daumenwerte*: WheelSpeed 20–100 Hz, RPM 10–50 Hz, TPS/APS 20–100 Hz, Lenkwinkel 50–100 Hz, Temperaturen 1–10 Hz.
+- **Jitter** der Periodizität: Streuung der Inter-Arrival-Times. Niedrig = sauberer Zyklus.
+- **DLC-Stabilität**: schwankende Payload-Länge → ggf. ISO-TP / Multiplex.
+- **Change-Density**: Anteil Frames mit Payload-Änderung. Zu hoch → Counter/Checksumme, zu niedrig → Status/Träge.
+
+---
+
+## 2) Byte/Bit-Signaturen
+- **Bit-Flip-Rate** pro Bit: ~50% → Flag/Event; sehr regelmäßig → Pattern/Timer.
+- **Rolling Counter**: 4/8-bit Sequenzen (0..15/255), oft konstant steigend.
+- **Checksumme**: Byte hängt deterministisch von anderen Bytes ab; häufig letzte Position.
+- **Endianness**: 16-bit LE/BE testen. Monotone Trends/kleine Deltas weisen auf richtige Byteordnung.
+- **Quantisierung**: typische Schrittweiten (z. B. 0.5 °C, 0.25 km/h).
+
+---
+
+## 3) Physik als Filter (Slew-Rate & Grenzen)
+Miss **ΔWert/Δt** robust (95-Perzentil, nicht Max):
+- **Temperaturen**: sehr träge → ΔT/s ≪ 1 °C/s.
+- **Fahrgeschwindigkeit**: 0→100 km/h < 1 s unrealistisch; grob ≤ 30–50 km/h/s (Straße).
+- **RPM**: schnelle Sprünge möglich, aber nicht teleport. 1k→8k in 1–3 s plausibel.
+- **Lenkwinkel**: schnell, aber begrenzt; **Jerk** (ΔΔ/Δt) nicht absurd.
+
+Alles, was diese Checks bricht, ist selten dein gesuchtes physikalisches Signal (oder deine Skalierung ist falsch).
+
+---
+
+## 4) Korrelation & Kausalität
+- **Cross-Korrelation**: RPM ↔ WheelSpeed (Gang drin), Brake-Bit ↔ Pressure, Blinker-Bit ↔ Blinkfrequenz (~1–2 Hz).
+- **Gang** aus Ratio (RPM/Speed) ableiten und Kandidaten validieren.
+- **Event-Marker** setzen und zeitgleichen Byte-Kipp suchen.
+
+---
+
+## 5) Protokoll & Multiplex
+- **ISO-TP**: Muster `0x10 len …` (First Frame), `0x21…` (Consecutive). Enthält selten einzelne Sensorkanäle.
+- **Multiplexer**: Ein Byte schaltet die „Seite“ der Payload um. Erkennbar am Sprungverhalten.
+
+---
+
+## 6) Statistik-Fingerabdrücke
+- **Unique-Ratio** = |unique|/n. Zu klein → Flag/Konstante; moderat → analog.
+- **Entropy** pro Byte → Daten/Checksumme vs. Status.
+- **Plateaus/Hysterese**: aktualisiert nur bei Δ≥Schwelle.
+
+---
+
+## 7) Scale/Offset systematisch schätzen
+- **Scale-Raster**: Dekaden + praxisnahe Werte (0.0625, 0.1, 0.25, 0.5, 0.75, 1, 2, 5, 10 …).
+- **Offset** via **Intervall-Überdeckung**: wähle das Offset, das die meisten Samples in [rmin, rmax] bringt.
+- **Vorzeichen prüfen**: signed/unsigned, ggf. negative Scales zulassen.
+
+---
+
+## 8) Workflow-Cookbook
+1. **Splitten** (Logs → Traces).  
+2. **ID-Explorer/Batch**: Periodizität, Change-Density, 8/16-bit Plots.  
+3. **Range-Fit** mit physikalischen Ranges *und* **Slew-Limits** (Δ/Δt) + **Rate/Jitter-Constraints**.  
+4. **Cross-Checks**: Kandidaten gegen andere Kanäle testen (RPM↔Speed, Brake↔Pressure).  
+5. **Iterieren**: Range/Constraints verfeinern, Plots sichten, Hypothesen anpassen.
+
+---
+
+## 9) Typische Fallen
+- Falsche Endianness → Teleports.  
+- Counter/Checksumme im selben 16-bit-Wort → zuerst trennen.  
+- DLC<8 → 16-bit-Kombis fehlen; keine Dummies einstreuen.  
+- ×10/×100-Skalierung: Δ/Δt wirkt absurd groß.  
+- BCD/ASCII in Diag/Odometer – nicht physikalisch.
+
+---
+
+## 10) Ziel: Berichte statt Bauchgefühl
+Automatisiere Tests & Schwellen. Lass Skripts einen **Analysebericht** schreiben: „PASS (smooth, low jitter, rate ok)“ vs. „FAIL (jitter, slope99 zu hoch, hit-ratio zu klein)“.  
+Das minimiert Confirmation Bias – und macht Ergebnisse reproduzierbar.