Dispositivos de WiFi sensing: ¿qué hardware captura CSI?

¿Qué cuenta como dispositivo de WiFi sensing?

Un dispositivo útil para WiFi sensing necesita tres capas que funcionen juntas. El hardware de radio debe producir mediciones que cambien con el canal; el firmware, driver o SDK debe hacer accesibles esas mediciones; y la aplicación debe poder guardar marcas de tiempo, contexto de paquetes y valores sin procesar o procesados. Si falta una capa, puede seguir siendo un buen router, pero no un instrumento de investigación fácil de comprobar.

La diferencia importa porque las páginas de producto usan palabras como presencia, hogar inteligente, radar o IA sin prometer acceso para desarrolladores. Trátalas como pistas, no como pruebas. Busca el chipset exacto, el firmware compatible, una API o callback local, un formato de exportación y un ejemplo reproducible con la misma revisión de hardware.

• El receptor expone CSI, mediciones del canal o un evento de sensing claramente documentado.
• El software de captura es compatible con el chip, firmware, sistema operativo y kernel exactos.
• El flujo conserva marcas de tiempo, metadatos de paquetes y contexto suficiente para validar.
• El dispositivo se puede probar en la habitación objetivo, no solo confiar por su nombre comercial.

Compara las principales rutas de dispositivos

La tabla separa el hardware de conectividad del hardware de medición. Un router puede proporcionar tráfico y un canal estable mientras otro dispositivo captura CSI. Esa separación suele ser más barata y reproducible que buscar un router de consumo que prometa todas las funciones de sensing en una sola caja.

Placas ESP32: el primer experimento más claro

Para muchas personas que empiezan, una ESP32 es el dispositivo de WiFi sensing más sencillo de evaluar porque la ruta de captura está explícita. Espressif documenta cómo activar CSI en ESP-IDF y registrar un callback de recepción, lo que permite revisar tiempos de paquetes, RSSI, datos del canal y metadatos. La placa puede escuchar mientras un router normal genera tráfico repetible.

Esta ruta sirve para aprender el ciclo completo: recoger una línea base con la habitación vacía, introducir un movimiento controlado, guardar los registros originales y comparar sesiones repetidas. No promete inferencias precisas de postura, respiración o identidad. La familia de la placa, la antena, la banda, el ancho de canal, la tasa de paquetes y la geometría de la habitación siguen afectando el resultado.

• Elige la familia ESP32 exacta y revisa el ejemplo actual de ESP-IDF antes de comprar.
• Registra canal, ancho de banda, posición de antena, fuente de paquetes y versión de firmware.
• Empieza por presencia o movimiento, no por una afirmación de postura o salud.
• Conserva CSI sin procesar y el contexto de paquetes para auditar resultados posteriores.

Raspberry Pi y Nexmon: una ruta Linux más específica

Una Raspberry Pi suele ser el ordenador de borde, no la radio de sensing. Con una radio compatible y un proyecto de captura documentado como Nexmon CSI, puede alojar el registro, filtrado, visualización y experimentos de modelos localmente. La Pi es útil para un flujo Linux, pero el nombre de la placa no demuestra por sí solo que la captura CSI vaya a funcionar.

La compatibilidad de Nexmon CSI depende de chips Broadcom o Cypress concretos, compilaciones de firmware, imágenes del sistema operativo y supuestos del kernel. Antes de comprar, revisa el soporte del proyecto para la revisión exacta y reproduce el comando de captura en una configuración conocida. Un ejemplo que funciona en una imagen de Raspberry Pi no se debe generalizar a todas las Pi, routers o adaptadores USB.

• Haz coincidir chipset de radio, revisión de placa, firmware y kernel exactos.
• Usa el ordenador de borde para guardar y procesar, pero verifica qué componente captura CSI.
• Espera mantenimiento cuando cambien Linux, el firmware o los drivers.
• Prefiere un dispositivo de referencia documentado antes de probar un modelo no listado.

Routers, plataformas y 802.11bf

Un router sigue siendo útil aunque no exporte CSI sin procesar. Puede proporcionar tráfico estable, un canal conocido y un entorno controlable para una ESP32 o un receptor CSI compatible. Si un producto expone eventos de presencia procesados mediante un SDK local o una API cloud documentada, evalúa esa interfaz por separado de la investigación basada en CSI crudo.

IEEE 802.11bf mejora el contexto de estandarización del sensing WLAN, pero un estándar publicado no desbloquea automáticamente un router instalado. La capacidad real depende del chipset, firmware, implementación del producto, permisos y acceso de los desarrolladores a las mediciones. Verifica la interfaz concreta del producto en vez de comprar solo por el número de generación WiFi.

• Pregunta si el acceso es CSI crudo, eventos procesados, API local, API cloud o ninguno.
• Comprueba bandas, anchos de canal, campos de antena/núcleo, marcas de tiempo y formato.
• Separa una afirmación comercial de una ruta de captura reproducible e independiente.
• En espacios ocupados, obtén consentimiento y define retención, acceso y borrado.

Cinco comprobaciones antes de elegir

Una comprobación corta de compatibilidad puede evitar un desvío largo de hardware. Empieza por la tarea que quieres medir y trabaja hacia atrás hasta la señal y la ruta de captura. Si un dispositivo no puede responder a estas preguntas, trátalo como un experimento no verificado y no como un componente fiable.

• Define la primera tarea medible: presencia, movimiento, ocupación, localización o una función de investigación.
• Nombra la medición necesaria y confirma que el dispositivo la exporta a tu software.
• Fija hardware, firmware, sistema, kernel, canal, ancho de banda y antena para una línea base.
• Planifica registros con marcas de tiempo, contexto, condiciones de sala, etiquetas y archivos originales.
• Prepara una alternativa: una placa ESP32 de referencia, un equipo Nexmon compatible o un router normal con receptor.

Valida el dispositivo antes de confiar en el resultado

Después de la primera captura, prueba la habitación vacía, una persona quieta, recorridos repetidos, una puerta, cambios de muebles, cambios de tráfico y un reinicio. Cambia una sola variable cada vez y guarda la configuración junto con cada registro. El objetivo no es una visualización espectacular, sino demostrar que una característica se repite en las condiciones donde se usará.

Compara sesiones de días diferentes e informa de falsos positivos, pérdida de paquetes, deriva e incertidumbre. Un modelo o demo puede parecer convincente y aun así fallar cuando cambia el router, el canal, la distribución de la habitación o la persona. Trata el resultado como una estimación de investigación hasta que el hardware y el protocolo respalden una afirmación más fuerte.

• Conserva una línea base de la habitación y repite el mismo movimiento varias veces.
• Registra cadencia de paquetes, muestras faltantes, deriva de RSSI y cambios de canal.
• Prueba casos negativos como ventiladores, puertas, mascotas y muebles en movimiento.
• No describas una visualización como imagen de cámara, lectura médica o prueba de identidad.
• Documenta consentimiento y controles de acceso cuando los registros revelen ocupación o actividad.

Cómo encaja esta guía en RuView Blog

Esta página responde a la pregunta de selección: ¿qué ruta de hardware puede exponer mediciones para un experimento de WiFi sensing? Usa la guía ESP32 para configurar el callback, la guía Nexmon para captura Broadcom y Raspberry Pi, la guía CSI para los conceptos de señal y la guía de routers para compatibilidad y compras. Los artículos de datasets y proyectos open source son más útiles después de estabilizar la captura.

Esta frontera evita confundir keywords y lectores. Una lista de routers no debe prometer CSI crudo, una guía de Raspberry Pi no debe insinuar que la Pi crea las mediciones por sí sola y una visualización de RuView no debe tratarse como prueba de precisión en producción.

Referencias técnicas oficiales

Preguntas sobre dispositivos de WiFi sensing