Fehler #176
Von Julius Haman vor 8 Tagen aktualisiert
### Anlass Forum: Kettler Racer 9 über COM-Port, die Schaltung am Racer "friert" nach etwa drei Schaltvorgängen ein (in ErControl 2.5 funktionierte sie). ### Ursachen (Vermutungen, noch ohne Log des Benutzers) Ursache (Vermutung) 1. Liefert das Ergometer eine Zeile mit anderer Spaltenzahl, ergibt `KettlerErgometer.ConvertReceiveString` `null` und der Poll-Tick endet ohne Meldung (`HandlePollTickAsync`). 2.5 hätte dabei eine Exception geworfen. Ein `FormatException`/`OverflowException` bei Nicht-Zahlen wurde gar nicht abgefangen. 2. In 3 führt schon **ein einzelner** Lese-Timeout (`ReceiveDataException`) zu "Verbindung verloren" und damit zu Reconnect (Port schließen, öffnen, `CM`, Baudraten durchprobieren; währenddessen werden alle Ticks übersprungen). 2.5 hat den Tick nur abgebrochen; der nächste Tick hatte dann einen Jitter > 1000 ms und wurde als "x Timer Events verpasst" ausgeglichen (`TrainingControl.M_cTimer_Elapsed`), ohne Port-Neustart und ohne `CM`. Ein Rechner/Trainer, der mit dem 1-s-Takt gelegentlich oder regelmäßig Probleme hat, landet in 3 in einer Reconnect-Schleife. Wie das Racer auf das erneute `CM` reagiert, ist unbekannt. Hinweis: Die Antwortzeit "300-400 ms" im Code-Kommentar (`HandlePollTickAsync`) stammt von einem anderen Gerät; für das Racer 9 gibt es keine Messwerte. ### Änderung - Unlesbare Bei bestehender Verbindung wird eine unlesbare Antwort bei bestehender Verbindung: Warnung mit samt gesendetem Befehl und kompletter Rohantwort als Warnung geloggt (höchstens alle 30 s, mit Zähler der unterdrückten Meldungen). - `FormatException`/`OverflowException` führen dann ebenfalls zu `null` (Tick wird übersprungen) statt zu einer unbehandelten Exception. - Beim Verbindungsaufbau (Erkennung ST/DB) bleibt es unverändert. - Dauer jedes seriellen Austauschs ins Debug-Log (Erweiterte Protokollierung für serielle Schnittstelle); ein Timeout bei bestehender Verbindung wird mit der Wartezeit als Warnung geloggt. - Einzelne Lese-Timeouts zählen wie in 2.5 als verpasster Tick: Warnung im Log, neuer Versuch im nächsten Takt. Zum Reconnect kommt es erst, wenn seit 5 s (wie `DataStaleAfter` bei BLE/ANT+) keine gültigen Daten mehr kamen. #129 (Kabel gezogen, Gerät aus) bleibt damit erhalten. unverändert und ohne Log. ### Offen Ursache des Einfrierens selbst; hängt vom Log des Benutzers ab. Ob 5 s die richtige Schwelle sind, zeigen die Antwortzeiten aus dessen Log.