El salto de frecuencia adaptativo (AFH) permite que Bluetooth y Bluetooth Low Energy cambien de canal para esquivar interferencias en la banda de 2.4 GHz. Aquí te explico el principio, el mapa de canales, las especificaciones y cómo se implementa en la práctica.
¿Qué es el adaptive frequency hopping y por qué importa?
El adaptive frequency hopping (AFH), o salto de frecuencia adaptativo, es una técnica de espectro ensanchado que usan Bluetooth y otros sistemas inalámbricos para esquivar interferencias: la frecuencia de transmisión va cambiando muy rápido y los canales ruidosos simplemente se dejan fuera. La diferencia clave es que no siempre se salta sobre la misma secuencia fija; el radio va observando su entorno y ajusta sobre la marcha la lista de canales que puede usar. Llevado a la vida diaria, esto es lo que permite que unos audífonos, un mouse o un sensor industrial convivan con el Wi-Fi de tu casa sin cortarse a cada rato.
La relevancia es enorme porque la banda de 2.4 GHz está saturada: routers Wi-Fi, microondas, cámaras y hasta otros dispositivos Bluetooth compiten por el mismo espacio. Según el Bluetooth Special Interest Group (SIG), tan solo en 2020 se produjeron más de 4 mil millones de dispositivos Bluetooth, y cada uno de ellos necesita coexistir con los demás. El AFH es, básicamente, el mecanismo que hace posible esa convivencia ordenada. Si no existiera, el rendimiento se vendría abajo en oficinas, casas y plantas industriales donde hay una alta densidad de radios.
Más que nada, hay que dejar claro que el AFH no es un protocolo independiente, sino una función que ya viene integrada en el enlace de radio. Tanto el transmisor como el receptor mantienen sincronía en frecuencia y van siguiendo una misma secuencia de saltos. Si un canal empieza a dar problemas, se marca y se deja de usar; y si después se limpia, puede volver a incluirse. Justo esa retroalimentación constante es lo que hace la diferencia entre el AFH y el salto de frecuencia fijo de toda la vida, al que también le dicen FHSS.
¿Cómo funciona el AFH: mapas de canales, saltos y detección de interferencia?
En Bluetooth, cada que hay un evento de conexión se escoge un canal de manera determinista entre los que están disponibles, y esto se hace con un algoritmo de selección de canal. Los dispositivos se mueven a ese canal y se comunican mediante una serie de frecuencias que va cambiando todo el tiempo a lo largo de la banda de 2.4 GHz. Por su parte, el dispositivo primario (al que antes se le llamaba maestro o central) lleva un mapa de canales donde clasifica cada uno como usado o no usado, y luego lo comparte con el dispositivo secundario a través de un procedimiento de capa de enlace.
Para detectar interferencia, cada implementación usa sus propios métodos, aunque los dos más mencionados son el RSSI (Received Signal Strength Indication) y el PER (Packet Error Rate). Cuando un canal que venía funcionando bien empieza a degradarse, el mapa se actualiza; y al revés, si un canal que estaba malo mejora, también se actualiza su estado. De esta forma, la comunicación se va repartiendo a lo largo de la banda y se dejan de lado las frecuencias más afectadas por el ruido.
El FHSS clásico funciona más o menos igual, pero sin adaptarse: parte la comunicación en pedacitos y los manda sobre una secuencia repetitiva de frecuencias que tanto el transmisor como el receptor comparten, casi siempre generada a partir de un plan pseudoaleatorio. La diferencia clave está en que el AFH detecta las fuentes fijas de interferencia y las saca de la lista de canales, mientras que el salto no adaptativo no tiene forma de esquivar los choques con otras tecnologías inalámbricas. Justo esa capacidad de exclusión es la que le da al AFH su ventaja práctica en entornos donde hay muchísimos dispositivos compitiendo por el mismo espectro.
¿AFH en Bluetooth clásico vs Bluetooth Low Energy: canales y especificaciones?
Bluetooth parte la banda de 2.4 GHz en 40 canales, y de esos, 37 son de propósito general y quedan disponibles para la comunicación conectada en Bluetooth Low Energy. Ahora bien, el Bluetooth clásico de antes del AFH ocupaba 79 de los 83.5 canales de la banda y brincaba 1600 veces por segundo. Con AFH la cosa cambia: la especificación de Bluetooth pide como mínimo veinte canales, y además el AFH es obligatorio si quieres transmitir con una potencia mayor a +10 dBm.
En BLE, Bluetooth LE utiliza el Channel Selection Algorithm #2 para las PDUs BIS, según lo que marca el Vol. 6 Parte B de la especificación central. Ahora bien, la actualización del mapa de canales viene desde la especificación Bluetooth 4.0, y aquí hay un detalle clave: únicamente el dispositivo central o maestro puede iniciarla. Esto le importa bastante a quien desarrolla, porque en la práctica significa que el nodo periférico no puede forzar por su cuenta un cambio de mapa, ni aunque esté detectando interferencia.
Para que todo quede más claro, va un resumen de los parámetros clave:
| Parámetro | Bluetooth clásico | Bluetooth Low Energy |
|---|---|---|
| Canales totales | 79 (pre-AFH) | 40 |
| Canales de datos | 79 | 37 |
| Saltos por segundo | 1600 | Variable según conexión |
| Mínimo de canales con AFH | 20 | 20 |
| Potencia que exige AFH | Más de +10 dBm | Más de +10 dBm |
Piensa en el audio Bluetooth: genera 300 kbit/s y transmite datos cada 15 ms, así que necesita un enlace que no falle. Ahí es donde el AFH se vuelve clave. Basta con que un solo canal se contamine para que empiecen los cortes que todos notamos en unos audífonos o una bocina. En BLE la historia cambia, porque el tráfico típico viene de sensores y equipos de bajo consumo; en ese caso el AFH ayuda a conservar la fiabilidad sin castigar la batería.
¿Cómo se implementa el AFH: intervalos de escaneo, bloqueo y APIs para desarrolladores?
Silicon Labs ofrece una implementación concreta que sirve de referencia. Su AFH hace un barrido de canales cada afh_scan_interval, cuyo valor por defecto es 1 segundo. El barrido de los 40 canales tarda alrededor de 10 ms y consume aproximadamente 240 uW adicionales. Si la potencia medida supera los -71 dBm, el canal se bloquea durante al menos 8 intervalos de escaneo; para desbloquearlo se necesitan 8 mediciones consecutivas sin interferencia.
La unidad de afh_scan_interval es de 10 ms y puede cambiarse mediante AFH_SCAN_INTERVAL_CONFIG_KEY 7 y las funciones sl_bt_system_linklayer_configure o gecko_cmd_system_linklayer_configure. Para habilitar el AFH en el SDK de Silicon Labs se instala el componente de software correspondiente; sl_bt_init_afh() se llama automáticamente dentro de sl_bt_init() por el generador de código, o bien se puede llamar gecko_init_afh() después de gecko_init(&config) en SDK más antiguos.
Nordic Semiconductor también documenta el tema en su chip nRF5340 y en Nordic DevZone. Zebra, con productos como el TC57 y el PS30, y Honeywell SPS incluyen guías de referencia donde el AFH aparece como parte del comportamiento esperado del radio. Texas Instruments publica la nota swra487, y Ericsson Technology Licensing ya describía estos mecanismos desde mayo de 2003 con Charles Hodgdon. La investigación eAFH, de Valentin Poirot y Olaf Landsiedel (Universidad de Kiel y Universidad Tecnológica de Chalmers, arXiv:2112.03046v1, 6 de diciembre de 2021), propone exploración informada para decidir qué canales reincorporar.
eAFH reporta 98-99.5% de fiabilidad en capa de enlace con interferencia Wi-Fi dinámica, 1% de sobrecarga de control y 40% más diversidad de canales que los enfoques del estado del arte. Es un buen ejemplo de hacia dónde va la investigación: no solo excluir canales ruidosos, sino decidir con datos cuáles merecen volver.
¿Cuáles son los beneficios y limitaciones del AFH?
Los beneficios del AFH son varios: mejora la resistencia a interferencias, refuerza la seguridad porque los cambios pseudoaleatorios de frecuencia dificultan la interceptación, optimiza el uso del espectro y permite asignación dinámica de frecuencias. Frente al bloqueo de canales no adaptativo, que exige deshabilitar canales manualmente, el AFH bloquea dinámicamente los canales de baja calidad sin intervención humana.
Las limitaciones también existen y conviene conocerlas. No hay AFH durante la conexión ni el descubrimiento de dispositivos, todos los dispositivos de la piconet deben ser compatibles con AFH, y la reincorporación de canales es difícil en entornos dinámicos. Además, el barrido de AFH tiene la prioridad más alta y puede bloquear otras operaciones si varias ocurren dentro de los 10 ms del barrido.
En el balance general, el FHSS tiene como contrapartida un rendimiento menor que algunos métodos de banda ancha. Sin embargo, para Bluetooth el AFH sigue siendo el mejor compromiso entre simplicidad, consumo y robustez. La coexistencia con Wi-Fi es el caso de uso estrella: ambos comparten la banda de 2.4 GHz, y el AFH permite que Bluetooth ceda los canales más castigados por el router.
Aquí un resumen comparativo para decidir cuándo conviene cada enfoque:
| Criterio | AFH | Bloqueo no adaptativo |
|---|---|---|
| Bloqueo de canales | Dinámico y automático | Manual |
| Resistencia a interferencia | Alta | Media |
| Seguridad | Mayor por saltos pseudoaleatorios | Limitada |
| Reincorporación de canales | Difícil en entornos dinámicos | No aplica |
| Compatibilidad requerida | Todos los dispositivos de la piconet | No aplica |
¿AFH en LE Audio, IoT y sistemas inalámbricos futuros?
Según una discusión en Nordic DevZone, el término AFH se usa en el contexto del modo de soporte BR/EDR. Para la difusión de LE Audio, la especificación central describe la clasificación de canales y el Channel Selection Algorithm #2 en la capa de enlace LE, pero la clasificación de canales por parte del host no era compatible con el stack Bluetooth de Zephyr en ese momento. Esto muestra que la implementación real depende mucho del stack y del SDK que uses.
En IoT, el AFH es especialmente valioso porque los dispositivos suelen operar en entornos con muchos radios y poca intervención humana. Un sensor industrial que pierde paquetes puede generar alarmas falsas o datos incompletos; el AFH reduce ese riesgo al excluir canales contaminados. La investigación eAFH apunta justamente a mejorar la diversidad de canales y la fiabilidad en escenarios con interferencia Wi-Fi dinámica.
De cara al futuro, la tendencia es combinar el AFH con clasificación de canales más inteligente y aprendizaje a partir de mediciones pasadas. El AFH seguirá siendo una pieza central de la coexistencia inalámbrica, sobre todo conforme crezca el número de dispositivos conectados en hogares, fábricas y ciudades. Para quien desarrolla, entender el mapa de canales, los intervalos de escaneo y las APIs disponibles no es opcional: es la base para construir productos Bluetooth estables.
¿Cuál es la diferencia entre AFH y salto de frecuencia fijo?
El salto de frecuencia fijo usa una secuencia fija de saltos de canal, mientras que el AFH adapta dinámicamente su secuencia de saltos al entorno cambiante. El AFH identifica fuentes fijas de interferencia y las excluye de la lista de canales disponibles, mientras que el salto no adaptativo no puede evitar conflictos con otras tecnologías inalámbricas. Esa es la diferencia esencial: adaptación contra rigidez.
En términos prácticos, un sistema con salto fijo puede seguir usando un canal aunque esté siendo golpeado por un router Wi-Fi cercano, lo que se traduce en retransmisiones y latencia. El AFH, en cambio, detecta ese canal ruidoso, lo bloquea temporalmente y redirige el tráfico a frecuencias más limpias. Por eso el AFH es hoy el comportamiento por defecto en la mayoría de los dispositivos Bluetooth modernos.
Si estás evaluando un chip o un SDK, revisa si el AFH viene habilitado por defecto y qué parámetros puedes ajustar. En Silicon Labs, por ejemplo, el intervalo de escaneo y el umbral de potencia son configurables, lo que permite afinar el comportamiento según el producto. Esa flexibilidad es la que separa una implementación básica de una realmente robusta.
¿Cómo habilitar AFH paso a paso en un SDK?
Para habilitar el AFH en el SDK de Silicon Labs, primero instala el componente de software de AFH. Después, sl_bt_init_afh() se llama automáticamente dentro de sl_bt_init() por el generador de código, así que en muchos proyectos no necesitas escribir nada adicional. Si trabajas con un SDK más antiguo, llama gecko_init_afh() después de gecko_init(&config).
Si quieres cambiar el intervalo de escaneo, define AFH_SCAN_INTERVAL_CONFIG_KEY 7, ajusta el valor de afh_scan_interval y llama a sl_bt_system_linklayer_configure o gecko_cmd_system_linklayer_configure. Recuerda que la unidad es de 10 ms, así que un valor de 100 equivale a 1 segundo, el valor por defecto.
Para verificar que el AFH está funcionando, monitorea el mapa de canales y observa si los canales castigados se bloquean y se reincorporan con el tiempo. Un buen punto de partida es medir el PER y el RSSI antes y después de habilitar el AFH en un entorno con Wi-Fi activo. La mejora suele notarse en menos retransmisiones y una conexión más estable.
Estos pasos aplican sobre todo a desarrolladores que trabajan con hardware EFR de Silicon Labs y SDK v2.9, v2.10, v2.11 o v3.x. En otras plataformas, como Nordic o Texas Instruments, el concepto es el mismo pero las funciones cambian; consulta siempre la documentación oficial del fabricante antes de asumir que el AFH está activo.
¿Qué significa el AFH para la experiencia del usuario final?
Para el usuario final, el AFH se traduce en menos cortes de audio, menos desconexiones y una respuesta más fluida en periféricos como mouse y teclado. Cuando usas audífonos Bluetooth en una oficina llena de redes Wi-Fi, el AFH es lo que evita que la música se entrecorte. Es una tecnología invisible, pero su ausencia se nota de inmediato en forma de glitches y latencia.
En dispositivos IoT, el impacto se mide en fiabilidad de datos. Un sensor que reporta cada pocos segundos necesita que sus paquetes lleguen completos; el AFH ayuda a que eso ocurra incluso cuando el espectro está congestionado. Por eso los fabricantes lo incluyen como parte del comportamiento esperado del radio, no como un extra opcional.
Si eres usuario, no hay mucho que configurar: el AFH opera en segundo plano. Si eres desarrollador o integrador, en cambio, conviene revisar la documentación del chip, habilitar el componente correspondiente y ajustar los parámetros de escaneo según el caso de uso. El resultado se mide en estabilidad, y en un mundo cada vez más inalámbrico, esa estabilidad vale oro.
Preguntas frecuentes sobre adaptive frequency hopping
Estas son las dudas más comunes que surgen al estudiar el AFH en Bluetooth y BLE, con respuestas directas para quienes buscan implementarlo o entenderlo a fondo.
El AFH es una técnica de espectro ensanchado que mejora la resistencia a la interferencia de radiofrecuencia cambiando rápidamente la frecuencia portadora y evitando los canales congestionados. En Bluetooth, los dispositivos conectados monitorean continuamente su entorno y actualizan un mapa de canales para excluir los canales ruidosos y usar solo los que se sabe que están limpios.
En Bluetooth Low Energy, en cada evento de conexión los dispositivos eligen un canal mediante un algoritmo de selección y saltan a él. El dispositivo primario mantiene un mapa de canales que clasifica cada uno como usado o no usado, lo comparte con el secundario y lo actualiza conforme cambia la interferencia, de modo que la comunicación se reparte por la banda de 2.4 GHz.
Según una discusión en Nordic DevZone, el AFH es un término usado en el contexto del modo de soporte BR/EDR. Para la difusión de LE Audio, la especificación central describe la clasificación de canales y el Channel Selection Algorithm #2 en la capa de enlace LE, pero la clasificación de canales por parte del host no era compatible con el stack Bluetooth de Zephyr en ese momento.
El salto de frecuencia fijo usa una secuencia fija de saltos de canal, mientras que el AFH adapta dinámicamente su secuencia al entorno cambiante. El AFH identifica fuentes fijas de interferencia y las excluye de la lista de canales disponibles, mientras que el salto no adaptativo no puede evitar conflictos con otras tecnologías inalámbricas.
Preguntas frecuentes sobre adaptive frequency hopping
¿Qué es el adaptive frequency hopping (AFH)?
El AFH es una técnica de espectro ensanchado que mejora la resistencia a la interferencia de radiofrecuencia cambiando rápidamente la frecuencia portadora y evitando los canales congestionados. En Bluetooth, los dispositivos conectados monitorean continuamente su entorno y actualizan un mapa de canales para excluir los canales ruidosos y usar solo los que se sabe que están limpios.
¿Cómo funciona el adaptive frequency hopping en Bluetooth Low Energy?
En cada evento de conexión, los dispositivos conectados eligen un canal mediante un algoritmo de selección y saltan a él. El dispositivo primario mantiene un mapa de canales que clasifica cada uno como usado o no usado, lo comparte con el secundario y lo actualiza conforme cambia la interferencia, de modo que la comunicación se reparte por la banda de 2.4 GHz.
¿El LE Audio de Bluetooth soporta adaptive frequency hopping?
Según una discusión en Nordic DevZone, el AFH es un término usado en el contexto del modo de soporte BR/EDR. Para la difusión de LE Audio, la especificación central describe la clasificación de canales y el Channel Selection Algorithm #2 en la capa de enlace LE, pero la clasificación de canales por parte del host no era compatible con el stack Bluetooth de Zephyr en ese momento.
¿Cuál es la diferencia entre AFH y el salto de frecuencia fijo?
El salto de frecuencia fijo usa una secuencia fija de saltos de canal, mientras que el AFH adapta dinámicamente su secuencia al entorno cambiante. El AFH identifica fuentes fijas de interferencia y las excluye de la lista de canales disponibles, mientras que el salto no adaptativo no puede evitar conflictos con otras tecnologías inalámbricas.
¿Qué es el Adaptive Frequency Hopping (AFH) y para qué sirve?
El Adaptive Frequency Hopping (AFH) es una técnica de espectro ensanchado que usan Bluetooth y Bluetooth Low Energy para cambiar dinámicamente de canal y evitar interferencias en la banda de 2.4 GHz. En lugar de saltar siempre por una secuencia fija, el radio observa su entorno, marca los canales ruidosos como no usados y adapta la lista de frecuencias disponibles. Así mejora la fiabilidad, la resistencia a interferencias y la coexistencia con Wi-Fi, microondas y otros radios.
¿Cuál es la diferencia entre AFH y el salto de frecuencia fijo (FHSS)?
El salto de frecuencia fijo (FHSS) usa una secuencia repetitiva de canales sin adaptación, por lo que no puede evitar chocar con fuentes de interferencia como un router Wi-Fi cercano. El AFH, en cambio, identifica esas fuentes fijas de interferencia y las excluye temporalmente de la lista de canales disponibles. Esa capacidad de adaptación dinámica es la diferencia esencial: el AFH reacciona al entorno, mientras que el FHSS clásico permanece rígido.
