Le défi de la coexistence
Lorsqu’un module Bluetooth partage une radio 2,4 GHz avec le Wi-Fi sur le même PCB, les deux protocoles se disputent le temps d’antenne sur des canaux qui se chevauchent. Sans gestion active de la coexistence, le débit BLE peut chuter de 40 à 70 % et la latence Wi-Fi peut exploser à des centaines de millisecondes. Ce n’est pas une préoccupation théorique — c’est le problème d’intégration le plus courant dans les conceptions double mode.
Cet article couvre les mécanismes, signaux matériels et stratégies de firmware qui rendent la coexistence fiable.
Chevauchement spectral : où se produisent les collisions
Le Wi-Fi occupe des canaux de 20 ou 40 MHz dans la bande ISM 2,4 GHz. Le BLE utilise des canaux de 2 MHz espacés de 1 MHz, sautant parmi 37 canaux de données.
| Canal Wi-Fi | Plage de fréquence (MHz) | Canaux BLE affectés |
|---|---|---|
| Ch 1 | 2412–2432 | 0–7 |
| Ch 6 | 2437–2457 | 12–19 |
| Ch 11 | 2457–2477 | 22–27 |
Quand le Wi-Fi transmet sur le canal 6, les canaux BLE 12–19 subissent un plancher de bruit élevé et des pertes de paquets. Le saut de fréquence adaptatif (AFH) reclasse ces canaux comme « mauvais » et les évite — mais seulement après avoir subi suffisamment d’erreurs pour déclencher le reclassement, ce qui nécessite plusieurs intervalles de connexion.
Signaux matériels de coexistence
L’approche standard de l’industrie utilise trois lignes GPIO dédiées entre les puces Wi-Fi et BLE (ou au sein d’une puce combo) :
| Signal | Direction | Fonction |
|---|---|---|
| WLAN_ACTIVE (PTA_REQ) | Wi-Fi → BLE | Le Wi-Fi va transmettre ; le BLE doit différer |
| BT_ACTIVE (PTA_PRI) | BLE → Wi-Fi | Le BLE a un événement haute priorité (scan, connexion) |
| BT_PRIORITY (PTA_STATUS) | BLE → Wi-Fi | 1 = haute priorité (audio/HID), 0 = basse priorité (données) |
Cette interface PTA (Packet Traffic Arbitration) 3 fils est définie dans IEEE 802.15.2 et prise en charge par la plupart des puces combo modernes (nRF5340 + nRF7002, ESP32, CYW43455, etc.).
Le timing est critique. La puce Wi-Fi active WLAN_ACTIVE 30–50 μs avant le début de l’émission RF. Le contrôleur BLE doit avorter toute TX en attente dans cette fenêtre. Si le signal arrive après que la chaîne RF est déjà active, le paquet est perdu.
Schémas de priorité de coexistence
Priorité Wi-Fi (par défaut)
Le Wi-Fi gagne toujours l’arbitrage. Le BLE diffère chaque fois que le Wi-Fi est actif. Cela maximise le débit Wi-Fi mais provoque des pertes de connexion BLE si le trafic Wi-Fi est soutenu (par exemple, pendant un téléchargement important).
Priorité BLE
Le BLE gagne toujours. Cela garantit la latence BLE mais dégrade sévèrement le débit Wi-Fi. Rarement utilisé en pratique.
Arbitrage par division du temps (recommandé)
Les deux protocoles alternent selon un calendrier négocié. Le contrôleur de coexistence accorde des tranches de temps. Le BLE obtient la priorité pendant les événements de connexion et les fenêtres de scan ; le Wi-Fi obtient la priorité pendant la réception de balise et les TX/RX de données. Paramètres clés :
- Intervalle de connexion BLE : Régler à 30–100 ms. Des intervalles plus courts consomment plus de temps d’antenne mais réduisent la latence.
- Intervalle d’écoute Wi-Fi : Typiquement 100 ms (DTIM = 1) à 1000 ms (DTIM = 10). Des intervalles plus longs libèrent du temps d’antenne pour le BLE.
- Temps de garde : 150 μs minimum entre les changements de protocole pour permettre la stabilisation RF.
Antenne partagée vs. antennes séparées
Antenne unique avec commutateur SPDT
Un commutateur RF (ex. Skyworks SKY13330) connecte l’antenne au chemin RF Wi-Fi ou BLE. La commande du commutateur est pilotée par la logique de coexistence. Cela économise le coût BOM et la surface PCB mais introduit des pertes d’insertion (0,5–0,8 dB) et nécessite un timing précis — le commutateur doit se stabiliser avant le début de l’émission RF.
Antennes doubles
Chaque protocole dispose de sa propre antenne avec ≥ 20 dB d’isolation (typiquement obtenue par polarisation orthogonale ou séparation spatiale de λ/4 ≈ 3 cm à 2,45 GHz). Cela évite le commutateur et permet le fonctionnement simultané, mais nécessite plus de surface PCB et d’accord d’antenne.
| Approche | Coût BOM | Surface PCB | Isolation | Fonctionnement simultané |
|---|---|---|---|---|
| Commutateur SPDT | +0,15–0,30 USD | Petite | N/A (commuté) | Non |
| Antennes doubles | +0,30–0,50 USD | Grande | 20–30 dB | Oui |
Pour la plupart des passerelles IoT et des hubs domotiques, une antenne unique avec commutateur SPDT suffit. Les antennes doubles se justifient pour les applications nécessitant l’audio BLE et le streaming Wi-Fi simultanés.
Atténuations au niveau logiciel
Lorsque les signaux PTA matériels ne sont pas disponibles (par exemple, en utilisant deux puces séparées sans GPIO de coexistence), les atténuations logicielles peuvent récupérer partiellement les performances :
- Liste noire AFH BLE : Ajouter manuellement les canaux Wi-Fi à la liste noire de l’hôte BLE. Par exemple, si le Wi-Fi est sur le canal 6, désactiver les canaux BLE 12–19 à l’initialisation. Cela évite la période d’apprentissage basée sur les erreurs.
- Économie d’énergie Wi-Fi avec ajustement DTIM : Augmenter l’intervalle DTIM à 3–10 pour réduire la fréquence d’écoute Wi-Fi, donnant plus de temps d’antenne au BLE.
- Fenêtres de scan décalées : S’assurer que les fenêtres de scan BLE ne chevauchent pas les rafales TX Wi-Fi. Sur ESP32, configurer la durée de scan BLE à 30 ms avec un intervalle de 100 ms ; le Wi-Fi utilise les intervalles.
- Intervalle de connexion BLE adaptatif : Quand le Wi-Fi est actif (détecté par surveillance RSSI), augmenter l’intervalle de connexion BLE à 200+ ms. Quand le Wi-Fi est inactif, réduire à 30 ms pour la réactivité.
Ces solutions de contournement ne sont jamais aussi efficaces que le PTA matériel, mais elles peuvent réduire la perte de paquets BLE de 30 % à moins de 10 % dans des conditions de trafic typiques.
Mesure des performances de coexistence
Les métriques clés à valider dans un design de coexistence :
| Métrique | Cible | Méthode de mesure |
|---|---|---|
| Taux de perte de paquets BLE | < 2 % (Wi-Fi inactif), < 10 % (Wi-Fi soutenu) | Sniffer BLE + générateur de trafic Wi-Fi |
| Débit Wi-Fi | > 85 % du débit autonome | iperf3 avec BLE actif |
| Stabilité de connexion BLE | Aucune perte en 24 h | Journalisation longue durée |
| Temps d’association Wi-Fi | < 3 s avec scan BLE | Temps de l’auth à la connexion |
Toujours tester avec un trafic Wi-Fi réaliste — pas seulement la surveillance de balises. Le débit TCP soutenu (par exemple, téléchargement de firmware OTA) est le pire cas pour la coexistence BLE.
Liste de contrôle de conception
- Vérifier le routage des signaux PTA : 3 fils, longueur appariée (< 5 mm de décalage), pas de vias si possible
- Définir la liste noire AFH BLE pour correspondre au canal Wi-Fi au démarrage
- Configurer l’intervalle de connexion BLE ≥ 30 ms ; utiliser 100 ms pour les données en arrière-plan
- Activer l’économie d’énergie Wi-Fi ; régler DTIM ≥ 3 si le trafic BLE est significatif
- Si utilisation d’un commutateur d’antenne SPDT : vérifier que le temps de stabilisation du commutateur < temps de montée TX RF
- Si antennes doubles : mesurer l’isolation avec un VNA ; cible ≥ 20 dB
- Tester avec la charge Wi-Fi du pire cas (flux TCP iperf3) et valider les métriques BLE
- Vérifier la consommation : l’arbitrage de coexistence ajoute 1–3 mA en moyenne pendant les périodes double-actives
Obtenir une coexistence correcte n’est pas optionnel. Dans tout design de module Bluetooth qui fait aussi tourner le Wi-Fi, la stratégie de coexistence doit être définie avant que le schéma ne soit finalisé — rajouter des signaux PTA après le routage est exponentiellement plus difficile.