Comment Claude a aidé à rétro-concevoir les protocoles BLE de Garmin pour simuler un capteur de course natif

Un utilisateur de Reddit a raconté comment il a utilisé Claude pour résoudre deux problèmes d'intégration Garmin difficiles : faire apparaître un capteur thoracique non Garmin comme une ceinture native sur une montre Fenix, et faire en sorte qu'une seule puce BLE se présente comme deux appareils simultanément. Le post source détaille le processus, les forces et faiblesses de l'IA, et renvoie à deux articles de blog approfondis.

Problème 1 : Simuler la dynamique de course sur une montre Garmin

Garmin verrouille les métriques de dynamique de course (oscillation verticale, temps de contact au sol) à ses propres ceintures via des protocoles non documentés. Le développeur a utilisé Claude pour rétro-concevoir le protocole en :

• Installant un renifleur Bluetooth et des cartes ESP32 qu'il possédait déjà
• Reniflant une vraie ceinture Garmin HRM, puis l'émulant avec un ESP32
• Différenciant des centaines de lignes de logs pour trouver le seul octet de différence entre les états fonctionnel et non fonctionnel
• Portant le code de checksum et de tramage de Gadgetbridge
• Grepant à travers 57 000 fichiers décompilés pour trouver le numéro de champ qui a craqué le protocole

Claude a écrit le code et effectué l'analyse, mais l'utilisateur a dû corriger la direction lorsque Claude a inversé le protocole (qui envoie quoi) et a poursuivi de mauvaises hypothèses pendant des jours. Le résultat : un ESP32 nu avec des données aléatoires fait afficher à une Fenix la dynamique de course comme si elle venait d'une ceinture native.

Problème 2 : Double identité BLE

Sur les montres Garmin, un seul capteur BLE ne peut souvent pas servir à la fois l'application native HRM et Garmin Connect IQ simultanément — les connexions se battent et basculent. Claude a suggéré une astuce issue des normes BLE : présenter deux adresses MAC différentes depuis la même puce en changeant d'adresse en cours de connexion. L'article de blog du développeur explique comment il a fait alterner un nRF52832 entre deux identités sans perdre la liaison active, malgré les avertissements de la documentation de la puce. Cela a résolu un problème récurrent pour de nombreux développeurs Connect IQ.

Rôle de Claude : forces et faiblesses

L'utilisateur note que Claude a excellé dans deux domaines :

• Agrégation de recherche : Il connaissait la commutation de double identité même si l'utilisateur l'ignorait, et a suggéré la technique.
• Tâches de fond : Effectuer le diff, porter le code et greper les fichiers décompilés.

Mais il a eu du mal avec la direction — il avait le protocole à l'envers et s'est basé sur de mauvaises hypothèses pendant des jours. L'utilisateur souligne que les tests, les données statiques et la validation étaient essentiels pour détecter les hallucinations.

En savoir plus

L'utilisateur a publié deux articles détaillés avec les protocoles complets et les détails d'implémentation :

• Commutation d'identité BLE : Two BLE identities, one nRF52832
• Rétro-ingénierie de la dynamique de course Garmin : Reverse-engineering Garmin HRM600 running dynamics