El desafío de la coexistencia
Cuando un módulo Bluetooth comparte una radio de 2,4 GHz con Wi-Fi en el mismo PCB, los dos protocolos compiten por el tiempo aire en canales superpuestos. Sin gestión activa de coexistencia, el rendimiento BLE puede caer un 40–70%, y la latencia Wi-Fi puede dispararse a cientos de milisegundos. No es una preocupación teórica — es el problema de integración más común en diseños de modo dual.
Este artículo cubre los mecanismos, señales de hardware y estrategias de firmware que hacen que la coexistencia funcione de forma fiable.
Superposición espectral: dónde ocurren las colisiones
Wi-Fi ocupa canales de 20 o 40 MHz en la banda ISM de 2,4 GHz. BLE usa canales de 2 MHz espaciados 1 MHz, saltando entre 37 canales de datos.
| Canal Wi-Fi | Rango de frecuencia (MHz) | Canales BLE afectados |
|---|---|---|
| Ch 1 | 2412–2432 | 0–7 |
| Ch 6 | 2437–2457 | 12–19 |
| Ch 11 | 2457–2477 | 22–27 |
Cuando Wi-Fi transmite en el Ch 6, los canales BLE 12–19 experimentan un piso de ruido elevado y pérdida de paquetes. El salto de frecuencia adaptativo (AFH) reclasifica estos canales como «malos» y los evita — pero solo después de experimentar suficientes errores para activar la reclasificación, lo cual requiere múltiples intervalos de conexión.
Señales de hardware de coexistencia
El enfoque estándar de la industria usa tres líneas GPIO dedicadas entre los chips Wi-Fi y BLE (o dentro de un chip combo):
| Señal | Dirección | Función |
|---|---|---|
| WLAN_ACTIVE (PTA_REQ) | Wi-Fi → BLE | Wi-Fi está a punto de transmitir; BLE debe posponer |
| BT_ACTIVE (PTA_PRI) | BLE → Wi-Fi | BLE tiene un evento de alta prioridad (escaneo, conexión) |
| BT_PRIORITY (PTA_STATUS) | BLE → Wi-Fi | 1 = alta prioridad (audio/HID), 0 = baja prioridad (datos) |
Esta interfaz PTA de 3 cables está definida en IEEE 802.15.2 y es soportada por la mayoría de los chips combo modernos (nRF5340 + nRF7002, ESP32, CYW43455, etc.).
El tiempo es crítico. El chip Wi-Fi activa WLAN_ACTIVE 30–50 μs antes de que comience la transmisión RF. El controlador BLE debe abortar cualquier TX pendiente dentro de esta ventana. Si la señal llega después de que la cadena RF ya está activa, el paquete se pierde.
Esquemas de prioridad de coexistencia
Prioridad Wi-Fi (predeterminada)
Wi-Fi siempre gana la arbitraje. BLE difiere cada vez que Wi-Fi está activo. Esto maximiza el rendimiento Wi-Fi pero causa caídas de conexión BLE si el tráfico Wi-Fi es sostenido (por ejemplo, durante una descarga grande).
Prioridad BLE
BLE siempre gana. Esto garantiza la latencia BLE pero degrada severamente el rendimiento Wi-Fi. Rara vez se usa en la práctica.
Arbitraje por división de tiempo (recomendado)
Ambos protocolos se alternan basándose en un horario negociado. El controlador de coexistencia otorga porciones de tiempo. BLE obtiene prioridad durante eventos de conexión y ventanas de escaneo; Wi-Fi obtiene prioridad durante recepción de baliza y TX/RX de datos. Parámetros clave:
- Intervalo de conexión BLE: Establecer en 30–100 ms. Intervalos más cortos consumen más tiempo aire pero reducen la latencia.
- Intervalo de escucha Wi-Fi: Típicamente 100 ms (DTIM = 1) a 1000 ms (DTIM = 10). Intervalos más largos liberan tiempo aire para BLE.
- Tiempo de guarda: 150 μs mínimo entre cambios de protocolo para permitir el asentamiento RF.
Antena compartida vs. antenas separadas
Antena única con conmutador SPDT
Un conmutador RF (ej. Skyworks SKY13330) conecta la antena a la ruta RF de Wi-Fi o BLE. El control del conmutador es dirigido por la lógica de coexistencia. Esto ahorra coste de BOM y área de PCB pero introduce pérdida de inserción (0,5–0,8 dB) y requiere sincronización precisa — el conmutador debe asentarse antes de que comience la transmisión RF.
Antenas duales
Cada protocolo tiene su propia antena con ≥ 20 dB de aislamiento (típicamente logrado con polarización ortogonal o separación espacial de λ/4 ≈ 3 cm a 2,45 GHz). Esto evita el conmutador y permite operación simultánea, pero requiere más área de PCB y ajuste de antena.
| Enfoque | Coste BOM | Área PCB | Aislamiento | Operación simultánea |
|---|---|---|---|---|
| Conmutador SPDT | +0,15–0,30 USD | Pequeña | N/A (conmutado) | No |
| Antenas duales | +0,30–0,50 USD | Grande | 20–30 dB | Sí |
Para la mayoría de gateways IoT y hubs de hogar inteligente, una antena única con conmutador SPDT es suficiente. Las antenas duales se justifican para aplicaciones que requieren audio BLE y streaming Wi-Fi concurrentes.
Mitigaciones a nivel de software
Cuando las señales PTA de hardware no están disponibles (por ejemplo, usando dos chips separados sin GPIOs de coexistencia), las mitigaciones de software pueden recuperar parcialmente el rendimiento:
- Lista negra AFH BLE: Incluir manualmente los canales Wi-Fi en la lista negra del host BLE. Por ejemplo, si Wi-Fi está en Ch 6, deshabilitar los canales BLE 12–19 en la inicialización. Esto evita el período de aprendizaje basado en errores.
- Ahorro de energía Wi-Fi con ajuste DTIM: Aumentar el intervalo DTIM a 3–10 para reducir la frecuencia de escucha Wi-Fi, dando más tiempo aire a BLE.
- Ventanas de escaneo escalonadas: Asegurar que las ventanas de escaneo BLE no se superpongan con las ráfagas TX de Wi-Fi. En ESP32, configurar duración de escaneo BLE a 30 ms con intervalo de 100 ms; Wi-Fi usa los huecos.
- Intervalo de conexión BLE adaptativo: Cuando Wi-Fi está activo (detectado por monitoreo RSSI), aumentar el intervalo de conexión BLE a 200+ ms. Cuando Wi-Fi está inactivo, reducir a 30 ms para capacidad de respuesta.
Estas soluciones alternativas nunca son tan efectivas como PTA de hardware, pero pueden reducir la pérdida de paquetes BLE del 30% a menos del 10% en condiciones de tráfico típicas.
Medición del rendimiento de coexistencia
Las métricas clave para validar en un diseño de coexistencia:
| Métrica | Objetivo | Método de medición |
|---|---|---|
| Tasa de pérdida de paquetes BLE | < 2% (Wi-Fi inactivo), < 10% (Wi-Fi sostenido) | Sniffer BLE + generador de tráfico Wi-Fi |
| Rendimiento Wi-Fi | > 85% del autónomo | iperf3 con BLE activo |
| Estabilidad de conexión BLE | Sin caídas en 24h | Registro de larga duración |
| Tiempo de asociación Wi-Fi | < 3 s con escaneo BLE | Tiempo desde autenticación hasta conexión |
Siempre pruebe con tráfico Wi-Fi realista — no solo monitoreo de balizas. El rendimiento TCP sostenido (por ejemplo, descarga de firmware OTA) es el peor caso para la coexistencia BLE.
Lista de verificación de diseño
- Verificar enrutamiento de señales PTA: 3 cables, longitud coincidente (< 5 mm de desviación), sin vías si es posible
- Establecer lista negra AFH BLE para coincidir con el canal Wi-Fi en el arranque
- Configurar intervalo de conexión BLE ≥ 30 ms; usar 100 ms para datos en segundo plano
- Habilitar ahorro de energía Wi-Fi; establecer DTIM ≥ 3 si el tráfico BLE es significativo
- Si usa conmutador de antena SPDT: verificar tiempo de asentamiento del conmutador < tiempo de rampa TX RF
- Si usa antenas duales: medir aislamiento con VNA; objetivo ≥ 20 dB
- Probar con carga Wi-Fi del peor caso (flujo TCP iperf3) y verificar métricas BLE
- Verificar consumo de energía: la arbitraje de coexistencia añade 1–3 mA promedio durante períodos de actividad dual
Lograr una coexistencia correcta no es opcional. En cualquier diseño de módulo Bluetooth que también ejecuta Wi-Fi, la estrategia de coexistencia debe definirse antes de finalizar el esquema — retrofitear señales PTA después del layout es exponencialmente más difícil.