ErControl

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)¶

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 Antwort bei bestehender Verbindung: Warnung mit gesendetem Befehl und kompletter Rohantwort (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.

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.