Deutsch
Beta, Runde 5: abgelehntes Timeout-Experiment entfernt, schnelleres Aufräumen nach fehlgeschlagener Verschlüsselung, neue Diagnose-Logs (Issue #79)
Reine Firmware-Änderung an der experimentellen Zwei-Bike-Bridge (bosch_ebike_ldi_dual, factory-dual.yaml). Die einfache Bridge (bosch_ebike_ldi) ist nicht betroffen.
PEPITO82s Log aus Runde 4 klärt zwei Dinge endgültig: Das Rad lehnt die Anfrage nach einem längeren Supervision-Timeout jedes Mal explizit ab (HCI-Fehler „Unacceptable Connection Parameters", kein Zufall). Gleichzeitig verrät das Log den bisher unbekannten Standardwert: Das Rad handelt von sich aus 4,0 Sekunden aus — exakt das Zeitfenster, in dem in jedem bisherigen Testlauf die Verbindung abgerissen ist.
Das abgelehnte Experiment wurde entfernt und durch reines Logging der tatsächlich ausgehandelten Verbindungsparameter (Intervall, Latenz, Timeout) bei jedem Connect ersetzt — genau die Daten, die PEPITO82s neue Theorie (kollidierende Verbindungs-Anker-Punkte zweier Räder auf demselben Funkmodul) prüfbar machen.
Außerdem neu gefunden: Nach einem Verbindungsabbruch kann ein erneuter Verbindungsversuch stecken bleiben, bevor er überhaupt verschlüsselt wird — und blockiert dann bis zu 40 Sekunden lang jeden weiteren Verbindungsversuch, bis NimBLEs eigener, fest einprogrammierter 30-Sekunden-Timeout (nicht konfigurierbar, im Quellcode verifiziert) abläuft. Die zusätzlichen rund 10 Sekunden danach werden jetzt eingespart, indem die Bridge diese Verbindung selbst sofort beendet, statt passiv zu warten. Die 30 Sekunden selbst bleiben bestehen — ehrliche Einordnung: keine Wunderlösung, nur ein Teilstück gekürzt.
Wieder Compile-geprüft, noch nicht an echter Hardware bestätigt.
English
Beta, round 5: removed a rejected timeout experiment, faster cleanup after failed encryption, new diagnostic logging (issue #79)
Firmware only change to the experimental two bike bridge (bosch_ebike_ldi_dual, factory-dual.yaml). The single bike bridge (bosch_ebike_ldi) is unaffected.
PEPITO82's round 4 log settles two things conclusively. The bike explicitly rejects the longer supervision timeout request every single time (HCI error "Unacceptable Connection Parameters", not a fluke). At the same time the log reveals the previously unknown default: the bike negotiates 4.0 seconds on its own, exactly the window every prior test run's drop has landed in.
The rejected experiment was removed and replaced with plain logging of the actually negotiated connection parameters (interval, latency, timeout) on every connect, exactly the data needed to test PEPITO82's new theory of two bikes' connection anchor points colliding on the same radio.
Also newly found: after a drop, a reconnect attempt can stall before it ever reaches encryption, blocking any further connection attempt for up to 40 seconds until NimBLE's own hardcoded 30 second timeout (not configurable, verified against the source) finally gives up. The roughly 10 additional seconds after that are now saved by having the bridge terminate that connection itself right away instead of waiting passively. The 30 seconds themselves remain, worth being honest that this is not a full fix, just one part of it trimmed.
Compile checked again, not yet confirmed on real hardware.
Nederlands
Beta, ronde 5: afgewezen timeout-experiment verwijderd, sneller opruimen na mislukte versleuteling, nieuwe diagnostische logging (issue #79)
Alleen een firmwarewijziging voor de experimentele bridge voor twee fietsen (bosch_ebike_ldi_dual, factory-dual.yaml). De bridge voor één fiets (bosch_ebike_ldi) is niet geraakt.
Het log van PEPITO82 uit ronde 4 maakt twee dingen definitief duidelijk. De fiets wijst het verzoek om een langere supervision timeout elke keer expliciet af (HCI-fout "Unacceptable Connection Parameters", geen toeval). Tegelijkertijd onthult het log de tot nu toe onbekende standaardwaarde: de fiets onderhandelt zelf 4,0 seconden, precies het venster waarin elke eerdere testrun is uitgevallen.
Het afgewezen experiment is verwijderd en vervangen door eenvoudige logging van de daadwerkelijk onderhandelde verbindingsparameters (interval, latentie, timeout) bij elke verbinding, precies de gegevens die nodig zijn om PEPITO82's nieuwe theorie te toetsen dat de verbindingsankerpunten van twee fietsen op dezelfde radio botsen.
Ook nieuw ontdekt: na een storing kan een nieuwe verbindingspoging vastlopen voordat versleuteling ooit begint, waardoor elke verdere verbindingspoging tot 40 seconden wordt geblokkeerd totdat NimBLE's eigen vast ingebouwde timeout van 30 seconden (niet instelbaar, geverifieerd aan de broncode) eindelijk opgeeft. De ongeveer 10 extra seconden daarna worden nu bespaard doordat de bridge die verbinding zelf meteen beëindigt in plaats van passief te wachten. De 30 seconden zelf blijven bestaan, eerlijkheidshalve is dit geen volledige oplossing, slechts een deel ervan ingekort.
Opnieuw compilatie gecontroleerd, nog niet bevestigd op echte hardware.