ErControl

BleFtmsTester 1.3.0: Neuer Diagnosemodus --alle, der alle BLE-Geräte in Reichweite mit Name, Service-UUIDs und Hersteller-ID auflistet (ohne zu verbinden). Anlass: Ein Tacx-Ergometer wird vom Tester nicht erkannt. Ursache offen, die Auswertung des Diagnoselogs steht aus.

Problem¶

Ein externer Tester (Logs bleftmstester-20260916.log und bleftmstester-20261008.log, nicht von uns erzeugt) findet mit dem BleFtmsTester 1.2.0 nur den Pulsmesser "H6M 55065". Ein angeblich eingeschaltetes Tacx-Ergometer (Modell unbekannt) taucht nie auf. Wir haben selbst kein Tacx und können es nicht nachstellen.

Die Suche war in der Umgebung des Testers außerdem langsam: Am 08.10. fand der erste Lauf in 79 s gar nichts (abgebrochen), im zweiten kam der H6M erst nach 109 s. Ob das am Tester oder an der Umgebung liegt (Entfernung, Adapter), ist nicht geklärt.

Hintergrund¶

Der Tester wertet nur Advertisements aus, in denen die Service-UUID 0x1826 (FTMS) oder 0x180D (Herzfrequenz) steht. Alle anderen Geräte werden still ignoriert. "Nicht erkannt" kann daher bedeuten:

• Das Tacx sendet nicht (zum Beispiel an einer anderen Zentrale wie Uhr, Zwift oder Handy verbunden, oder außer Reichweite).
• Es sendet kein FTMS im Advertisement: Ältere Tacx-Modelle bieten nur ANT+ FE-C oder ein eigenes Tacx-BLE-Protokoll.
• Die FTMS-UUID steht nicht im Advertisement, sondern wird erst nach dem Verbinden sichtbar.
  Das lässt sich aus den Logs nicht unterscheiden.

Technische Details¶

• BleFtmsTester --alle: Loggt jede Kombination aus Adresse, Name, Service-UUIDs und Hersteller-ID einmal, mit Signalstärke und Paketart (Advertisement oder Scan Response). Standard-UUIDs kurz (0x180D), herstellerspezifische vollständig. Kein Verbinden.
• Versionsstand in BleFtmsTester.csproj und im Kommentar in Directory.Build.props auf 1.3.0.

Nächste Schritte¶

Lauf mit --alle bei eingeschaltetem Tacx, das mit nichts anderem verbunden ist. Danach je nach Ergebnis:

• Tacx mit 0x1826 sichtbar: Fehler im Scan-Code (auch die lange Suchdauer) suchen und beheben.
• Tacx ohne 0x1826 sichtbar: Prüfen, welche Schnittstelle das Modell bietet. Bei eigenem Tacx-Protokoll ist ANT+ FE-C der Weg.
• Tacx nicht sichtbar: Aufbau prüfen (Verbindung zu anderer Zentrale, Abstand, Gerätezustand), kein Fehler im Code.

Hinweis zum Test¶

• --alle lief am 08.10.2026 auf dem Entwicklungsrechner: Der Modus listet alle Geräte, darunter den BLE-Pulsgurt HRM200 (Name "HRM200:560741", Service 0x180D, Hersteller-ID 0x0087) sowie mehrere unbenannte Fremdgeräte ohne Services. Der Modus funktioniert also.
• Ein externer Tester mit einem Tacx Vortex hat --alle (Version 1.3.0) ausgeführt, siehe Ergebnis unten.

Ergebnis mit dem Tacx Vortex (externer Tester, 08.10.2026)¶

--alle listet ein "Tacx Vortex 02869" (Adresse DEA636F33D3B, -66 dBm, verbindbar). In der Scan Response stehen:

• 0x1818 (Cycling Power) und 0x1816 (Cycling Speed and Cadence),
• zwei Tacx-eigene 128-Bit-Dienste: 6e40fec1-b5a3-f393-e0a9-e50e24dcca9e und 669aa305-0c08-969e-e211-86ad5062675f.

Es steht kein FTMS (0x1826) im Advertisement. Der Tester ignoriert das Gerät deshalb zu Recht (Filter auf die Kennung im Advertisement). Die in den Logs davor beobachtete lange Suche (79 bis 109 s) trat mit 1.3.0 nicht mehr auf: Der Pulsgurt H6M wurde nach 4 s gefunden. Ob das Vortex FTMS im Gerät hat, ohne es zu bewerben, klärt der Dienstabruf nach dem Verbinden. Dafür: #141 (--dienste, BleFtmsTester 1.3.1).

Hinweis für den externen Tester¶

BleFtmsTester.exe --alle mit eingeschaltetem Tacx, das mit nichts anderem (Handy, Uhr, Zwift) verbunden ist, nach kurzem Treten 30 bis 60 Sekunden laufen lassen und die Logdatei zurückschicken.