Hardware-Log: Google Fitbit Air im Parallelbetrieb mit der Pixel Watch 3 – Frequenz-Kollision oder Ecosystem-Symbiose?

Einleitung: Das Dilemma der doppelten Inferenz

Wer zwei Wearables aus demselben Ökosystem gleichzeitig am Körper trägt, erntet im Alltag meist ungläubige Blicke. Aus technischer Sicht wirft dieses Szenario jedoch hochspannende Fragen auf. Das Google Fitbit Air ist darauf ausgelegt, als federleichter, fast unsichtbarer Tracker Vitaldaten zu sammeln. Am anderen Handgelenk verrichtet jedoch die Pixel Watch 3 ihren Dienst, die dieselben Metriken erhebt, aber zusätzlich als LTE-Smartwatch das primäre Kommunikations-Gateway bildet.

Das Hauptproblem dieses Setups liegt nicht in der Optik, sondern unter der Haube: Wie reagiert das Android-Subsystem, wenn zwei Bluetooth-Low-Energy-Geräte (BLE) permanent versuchen, dieselben Health-Daten in die Cloud zu jagen? Kommt es zu Packet-Loss, doppelten Schritten oder blockieren sich die Synchronisations-Daemons gegenseitig?

Die Bluetooth-Ebene: BLE-Kanalbelegung und das Connection-Interval

Beide Wearables kommunizieren über Bluetooth Low Energy im 2,4-GHz-ISM-Band. Die Pixel Watch 3 nutzt ein aggressives Verbindungsintervall, um Benachrichtigungen in Echtzeit zu spiegeln und Sensordaten an das Smartphone zu übertragen. Das Fitbit Air hingegen versucht, die Batterie durch extrem lange Deep-Sleep-Phasen und zyklische, gebündelte Datenübertragungen (Bursts) zu schonen.

Beim ersten Testlauf heute zeigte sich eine interessante Verhaltensweise des Android-Bluetooth-Stacks: Sobald beide Geräte versuchen, gleichzeitig eine hochfrequente Verbindung aufzubauen – etwa während eines aufgezeichneten Workouts –, steigt die Latenz bei der Paket-Evaluierung im Smartphone messbar an. Der Linux-Kernel des Smartphones muss hier über den Bluetooth-HCI (Host Controller Interface) die Time-Slots für das Adaptive Frequency Hopping (AFH) präzise zuteilen, um Kollisionen auf den drei primären Advertising-Kanälen (37, 38 und 39) zu vermeiden.

Das Software-Schlachtfeld: Google Health Connect & Fitbit-Zusammenführung

Die zentrale Instanz auf dem Smartphone ist Googles Health Connect-Architektur. Diese lokale Datenbank dient als Abstraktionsschicht, über die Apps Vitaldaten austauschen. Hier schlägt das Herz des Multi-Device-Dilemmas.

Wenn die Pixel Watch 3 um 14:00 Uhr exakt 1.200 Schritte registriert, das Fitbit Air am anderen Arm aufgrund eines leicht abweichenden Beschleunigungssensors jedoch 1.240 Schritte meldet, muss das Framework entscheiden, welchem Datensatz es vertraut. Health Connect löst dies über eine strikt konfigurierbare App- und Geräte-Priorisierung. In den Standardeinstellungen führt dies jedoch im ersten Testbetrieb zu folgendem Phänomen:

• Die Fitbit-App versucht, die Daten beider Tracker zu aggregieren.
• Es entstehen temporäre «Geisterschritte» in der UI, da die Synchronisations-Zeitstempel der beiden Geräte nicht mikrosekundengenau übereinstimmen.
• Erst nach einem vollständigen Server-Side-Sync im Fitbit-Backend wird der Datensatz geglättet und dedupliziert.

Entwickler-Perspektive: Auslesen der Datenströme via Android-API

Für Entwickler, die eigene Fitness- oder System-Dashboards programmieren, ist der parallele Betrieb ein Albtraum, wenn man die Datenquellen nicht sauber trennt. Wer blind auf den globalen Schrittzähler-Inhalt zugreift, erhält verfälschte Werte. Um die Datenströme sauber zu isolieren, muss man beim Abfragen der Health-Connect-API explizit die Geräte-Metadaten (Device-Klasse) auswerten.

Hier ist ein beispielhafter, sauberer Kotlin-Auszug nach dem KISS-Prinzip für das Android-Backend, der zeigt, wie man die Schritte spezifisch nach der Hardware-Quelle filtert, anstatt den globalen, korrumpierten Gesamtstrom zu lesen:

import androidx.health.connect.client.HealthConnectClient
import androidx.health.connect.client.request.ReadRecordsRequest
import androidx.health.connect.client.records.StepsRecord
import java.time.Instant

async fun readStepsIsolated(
    healthConnectClient: HealthConnectClient,
    startTime: Instant,
    endTime: Instant
) {
    val response = healthConnectClient.readRecords(
        ReadRecordsRequest(
            recordType = StepsRecord::class,
            timeRangeFilter = androidx.health.connect.client.time.TimeRangeFilter.between(startTime, endTime)
        )
    )

    for (stepRecord in response.records) {
        val deviceModel = stepRecord.metadata.device?.model
        val deviceManufacturer = stepRecord.metadata.device?.manufacturer
        
        // Filterung nach spezifischer Hardware-ID, um Inferenz-Fehler zu vermeiden
        when (deviceModel) {
            "Pixel Watch 3" -> {
                // Logik für die Verarbeitung der Smartwatch-Daten
                println("Watch-Steps: ${stepRecord.count}")
            }
            "Fitbit Air" -> {
                // Logik für den autonomen Tracker
                println("Fitbit-Air-Steps: ${stepRecord.count}")
            }
            else -> {
                println("Unbekannte Datenquelle: $deviceModel ($deviceManufacturer)")
            }
        }
    }
}

Erstes Zwischenfazit des heutigen Testtages

Das Google Fitbit Air glänzt durch seine unaufdringliche Hardware, doch das Zusammenspiel mit der Pixel Watch 3 offenbart feine Risse in der lokalen Synchronisations-Logik von Android. Die Geräte stören sich zwar nicht auf Funk-Ebene – das Adaptive Frequency Hopping leistet hier hervorragende Arbeit und verhindert Verbindungsabbrüche –, aber sie bringen das Software-Backend ins Schwitzen.

Wer beide Geräte parallel nutzt, zwingt das Smartphone zu permanenter Deduplizierungs-Arbeit im Hintergrund. Das zerrt nicht nur am Akku des Telefons, sondern führt in Drittanbieter-Apps, die Health Connect nutzen, temporär zu fehlerhaften Metriken. In den kommenden Tagen werde ich beobachten, wie sich das System bei längeren Trainingseinheiten verhält und ob das Batterie-Management des Fitbit Air unter dem permanenten BLE-Grundrauschen der Pixel Watch leidet.

Habt ihr ähnliche Setups mit mehreren Trackern im Einsatz? Welche Erfahrungen habt ihr mit der Deduplizierung von Health Connect gemacht? Schreibt es in die Kommentare.

Quellen & API-Dokumentation

• Google Health Connect API-Referenz: https://developer.android.com/health-and-fitness/health-connect
• Bluetooth Core Specification 5.4 (AFH-Mechanismen): https://www.bluetooth.com/specifications/specs/
• DBH Systems Hardware-Zentrale: https://blake-hofer.net/shop/

GoogleFitbitAir, PixelWatch3, WearableArchitecture, AndroidDevelopment, BLEInference, HealthConnect, KotlinEngineering, HardwareTesting, TechBlog, DBHSystems