Este año Specialized dio de baja la app que lo soportaba y migró a una nueva que no es compatible. Además, los servidores dejaron de responder: no se puede iniciar sesión, recuperar la contraseña ni crear una cuenta, así que estoy bloqueado de seguir usando la app vieja. Me quedé con un dispositivo útil que no puedo usar, y con una pregunta incómoda: ¿realmente era mío?

Estructura del documento

Este caso de estudio documenta el proceso completo de ingeniería inversa sobre el sensor ANGi y el desarrollo de una alternativa abierta e independiente (OpenAngi) utilizando herramientas de IA. El trabajo está organizado en 5 partes principales:

• Parte 1: Claude y la exploración BLE — Exploración inicial del hardware, enumeración de servicios BLE y descompilación estática del APK original.
• Parte 2: OpenCode y el desarrollo de las apps Android — Construcción del banco de pruebas AngiTester, desarrollo de la app final OpenAngi (100% independiente de servidores) y comparativa de código.
• Parte 3: Hardware y Firmware — Análisis Comparativo — Extracción del firmware del nRF52832, análisis en Ghidra, descubrimiento de la consola UART de producción y caracterización de consumo eléctrico.
• Parte 4: Actualización DFU — Localización del firmware oficial dentro de la APK, actualización por Bluetooth (DFU) e integración del proceso en la app.
• Parte 5: Balance del uso de herramientas de IA — Comparativa de fortalezas y limitaciones de cada modelo, escala/costos del proyecto y consideraciones legales.

Una aclaración inicial: todas las herramientas usadas son de acceso gratuito, por ello se puede ver el uso de diversas en distintos puntos. En algunos casos respondía a intentar herramientas diferentes, limitaciones propias de los modelos (por ejemplo en OpenCode muchos no soportan imágenes), y en otros al hecho de haber llegado a los límites de tokens disponibles.

Parte 1: Claude y la exploración BLE

La primera fase la hicimos enteramente en Claude (Sonnet 5) a través de la interfaz web de claude.ai. Una única sesión continua, un solo modelo, sin interrupciones.

La primera pregunta fue de viabilidad del proyecto que queríamos encarar. Claude buscó en la web y confirmó que el ANGi corre sobre un nRF52832 de Nordic Semiconductor (Cortex-M4F, 512KB flash) — un chip BLE extremadamente documentado con SDK público, identificado a partir del registro FCC del dispositivo.

Como la app oficial estaba muerta (sin login, sin recuperación de contraseña, sin altas nuevas), descartamos capturar tráfico logueado y reordenamos el plan hacia dos frentes paralelos:

1. Exploración directa del hardware con nRF Connect for Mobile (herramienta gratuita de Nordic), enumerando servicios y características BLE sin pasar por la app de Specialized.
2. Decompilación estática del APK descargado de un mirror (apkmirror.com, ya que Google Play tampoco permitía la descarga) usando jadx — el código decompilado no depende de que el backend esté vivo.

Conectamos el sensor usando nRF Connect y le pasamos las primeras capturas de pantalla para análisis. De allí salió el mapa inicial de servicios: el servicio custom afd0ffa0…afd0ffa8, Battery Service, Device Information, y un servicio de DFU “Buttonless” de Nordic.

a. Construcción incremental de scripts de exploración

Con Claude fuimos construyendo incrementalmente una serie de scripts en Python usando la librería bleak (cliente BLE multiplataforma), donde cada script respondía una pregunta concreta que dejaba abierta el anterior:

• angi_sniffer.py: se conecta al sensor, se suscribe a las características NOTIFY, y loguea todo el tráfico crudo con timestamp en pantalla y CSV.
• angi_command_sweep.py: barre automáticamente los 256 valores posibles (0x00–0xFF) en las características WRITE, comparando el registro de STATUS antes y después de cada escritura para detectar reacciones.
• angi_heartbeat_test.py: escucha pasiva sin escribir nada, diseñado específicamente para descartar la hipótesis de que ciertos paquetes observados fueran respuestas a comando. Resultado: eran un heartbeat periódico (un contador de uptime incrementando ~1/segundo).

La dinámica era siempre la misma: corríamos el script contra el sensor real → le pegábamos el log o el traceback a Claude → él ajustaba el código → repetir. Simple pero efectivo.

De esta forma avanzábamos pero el proceso era más bien lento. El salto grande vino con la descompilación. Claude nos armó un prompt específico y detallado para ejecutar en OpenCode (otra herramienta de IA, con acceso directo al filesystem), con instrucciones paso a paso: decompilación con jadx, búsqueda dirigida (grep) de los UUIDs y constantes ya identificados por BLE, identificación de clases y métodos por cada UUID, y generación de un documento de protocolo.

El resultado fue un mapa completo del protocolo extraído de las clases Java decompiladas. Con esa información se construyó el angi_client.py definitivo: un cliente BLE interactivo y completo que implementa el patrón real de comando extendido del sensor, parsers para los tres formatos de paquete de respuesta (ASCII, reporte IMU de 15 bytes, reporte de impacto de 20 bytes), comandos con nombre, modo raw <hex> para experimentación libre, y un autotest que barre los 17 opcodes conocidos × 5 variantes de parámetro con reconexión automática.

b. Identificación de hardware y sensores en placa

Otra de las líneas de investigación fue por el hardware en sí: abrimos el sensor y le sacamos fotos a la placa.

Claude identificó los chips por su marcado, cruzando contra documentación pública de los fabricantes:

• Acelerómetro ST LIS3DH: identificado por la marca “C3H”, confirmada contra un post oficial de un ingeniero de STMicroelectronics en el foro de la compañía.
• Giroscopio ST L3GD20H: identificado por la marca “3GDH”, verificado contra la misma fuente de ST.
• BLE SoC nRF52832: en encapsulado BGA bajo una capa de silicona protectora.

c. Números de la sesión con Claude

A partir de este punto, teniendo la APK original decompilada, pasamos a OpenCode para continuar el desarrollo de las aplicaciones de prueba y la solución final.

Parte 2: OpenCode y el desarrollo de las apps Android

La segunda fase —construir las apps Android funcionales— la hicimos con OpenCode, un IDE asistido por IA que corre en terminal con acceso directo al filesystem, ejecución de comandos (bash/PowerShell), y herramientas de edición de código. Todo lo que sigue sale de datos reales de la base de datos local de OpenCode (SQLite), no de estimaciones.

OpenCode usó 3 modelos distintos a lo largo de la sesión, todos del tier gratuito:

738 mensajes del asistente, 4.3 millones de tokens de entrada, 319K de salida, 351K de razonamiento. El paso por los distintos modelos respondió más a los resultados que obteníamos: en algunos casos notábamos que el modelo comenzaba a tardar más o no lograba resolver los problemas, posiblemente por un contexto elevado en la sesión, por lo que intentábamos con otro modelo.

a. Desarrollo con AngiTester

Antes de construir la app final (OpenAngi), necesitamos contar con un “banco de pruebas de laboratorio” en Android. Así nació AngiTester — una aplicación ligera de 6 archivos Kotlin cuyo único objetivo era interactuar directamente con el sensor real SHS-D33F (todos los sensores se presentan como SHS-“ultimos 4 digitos de la MAC”) y validar cada hipótesis byte a byte.

La pantalla principal de AngiTester se divide en tres zonas clave para inspeccionar el tráfico BLE en tiempo real:

• Terminal de comandos en vivo (log [HH:mm:ss.SSS]):
  • Caja tipo consola con auto-scroll inteligente (se pausa si el usuario sube a leer el historial y retoma al volver abajo).
  • Registra todo el tráfico bidireccional (TX/RX), notificaciones ASCII, respuestas de estado y lectura de batería en tiempo real cada 5 minutos.
• Gráfico custom IMU en tiempo real (ImuGraphView.kt):
  • Grafica a 5 Hz los 3 ejes del acelerómetro y la velocidad angular en modo TEST.
  • Indexado por número de muestra (sampleNumber): evita distorsiones o “saltos” horizontales cuando las notificaciones BLE llegan en ráfagas.
  • Auto-escala eje Y suavizada para prevenir que un pico repentino aplane la curva continua.
• Botonera de comandos directa y extendida:
  • Modos directos (afd0ffa1): Activate (sincroniza RTC + MODE 0x01), Normal (0x00), Test (0x40 streaming IMU).
  • Comandos extendidos (BLOCK_DATA afd0ffa4 + trigger 0x20): versión de firmware (0xC3), test de acelerómetro/giroscopio (0xC0/0xC1), control de LEDs (0xFE/0xC2), simulación de impacto (0xFB), lectura/reporte de eventos grabados (0x80/0x81), entre otros.

AngiTester no fue solo una app de prueba: fue la herramienta empírica que permitió descifrar el comportamiento real del hardware y descubrir aspectos que no estaban claros en el código decompilado:

i. Decodificación y validación de STATUS (afd0ffa2): Verificamos empíricamente la estructura del bit-field de 1 byte devuelto por el sensor:

• Bit 7 (0x80): Bit de ERROR (si es 1, los 7 bits restantes son el código de error).
• Bits 6-5 (0x60): Modo (0=NORMAL, 1=EXT_CMD, 2=TEST).
• Bit 4 (0x10): Sesión activa.
• Bit 3 (0x08): Heartbeat de conexión activo.
• Bit 0 (0x01): Último comando completado.

Catalogamos los valores de estado crudos reales observados durante la operación: 0x00 (recién conectado), 0x01 (NORMAL + sesión activa), 0x03 (sesión activa con eventos pendientes), 0x21 (modo EXT_CMD completado) y 0x82 (ACK con error/transitorio tras comandos de impacto).

ii. Descubrimiento y calibración de la escala del acelerómetro: La APK original dividía todos los datos del reporte IMU (IcedotTestReport) por 100. Sin embargo, al capturar datos en reposo con AngiTester y procesar la evidencia (angi_static.csv), descubrimos que los ejes X, Y y Z daban un vector resultante de ~1,73 g, lo cual es físicamente imposible en reposo.

Mediante pruebas cruzadas derivamos el divisor real para los ejes del acelerómetro: Divisor K = 173.2 ≈ 100 · √3 Con esta corrección, los ejes reportaron exactamente ~1,00 g en reposo (error medio de solo 9 mg), mientras que accelVector y rotation se mantuvieron con divisor 100.

iii. Confirmación del canal único del giroscopio: Confirmamos que el firmware de Specialized no transmite los 3 ejes independientes del giroscopio en el streaming BLE. En su lugar, reduce la velocidad angular a un único canal escalar (rotation) en °/s (bytes 11-12) y su aceleración angular (rotationalAccel, bytes 13-14). Determinamos que corresponde a un eje de rotación de basculación (cercano al eje X del casco).

iv. Validación del flujo de armado de sesión e impacto: Comprobamos que si el RTC de 7 bytes UTC (afd0ffa7) no se envía antes de habilitar MODE 0x01, los reportes de impacto se registran con timestamp en 0. Capturamos y validamos la notificación real de impacto en afd0ffa6 (paquete de 20 bytes: type, battery, version, timestamp, peakG, peakR, peakRA y deviceID).

b. OpenAngi: la app final independiente

OpenAngi es la aplicación definitiva (30 archivos Kotlin, APK de 16.5 MB): una reescritura completa desde cero usando arquitectura moderna en Kotlin + Jetpack Compose Material 3 + MVVM + Room + DataStore + Foreground Service.

La app funciona sin servidor, sin cuentas y sin backend: el propio teléfono manda los SMS directamente mediante SmsManager.

Las pantallas de OpenAngi:

La app tiene 4 pestañas principales en una barra inferior, más dos pantallas superpuestas (Dispositivo y Alerta):

Flujo de conexión BLE

Cada operación GATT pasa por un Mutex (una a la vez, con timeout de 8 segundos). Si algún paso falla, la reconexión automática repite todo el setup desde cero, porque el sensor pierde su estado al desconectarse. El backoff crece de 2 a 60 segundos con jitter.

Flujo de impacto: de la detección al SMS

Esta es la parte central de la app — la máquina de estados del ImpactFlowController:

El flujo corre a nivel de proceso (no de UI): si la app está cerrada pero el Foreground Service está corriendo, la detección funciona igual y la notificación full-screen abre la alarma directamente.

Declarar emergencia: hay un botón dedicado en la pantalla de Dispositivo y en Ajustes que dispara exactamente el mismo flujo pero con un evento sintético (tipo DECLARADA, pico 0 g). El SMS dice “declaró una emergencia (aviso manual)” en vez de “sufrió un impacto”. Útil si necesitás pedir ayuda sin haber tenido un choque.

Robustez: el Foreground Service

El servicio AngiMonitorService es el dueño de la conexión BLE y corre con una notificación persistente que muestra el estado real:

• 🟢 Verde: conectado y vigilando (muestra batería del sensor)
• 🟡 Ámbar: reconectando (con cuenta de espera)
• 🔴 Rojo: desconectado

Si pasan 5 minutos sin conexión, la app lanza una notificación de alta prioridad: “OpenAngi perdió conexión con el sensor”. La filosofía es nunca fallar en silencio — si algo sale mal, que el usuario se entere.

El BootReceiver reconecta automáticamente al prender el teléfono, y si Android bloquea el arranque en background, al menos manda una notificación avisando que hay que abrir la app manualmente.

c. Diferencia con la app original: hechos de protocolo vs. código

Uno de los puntos más importantes de este proyecto es entender qué se tomó y qué no de la app original de Specialized, qué tanto las herramientas copiaron de la APK original y qué fue creación original. Corrimos scripts automatizados comparando las 262.495 líneas del APK decompilado contra todo el código nuevo:

Las 3 líneas “idénticas” son boilerplate idiomático de Android (if (bluetoothManager != null), if (cursor.moveToFirst())). Los únicos literales compartidos son UUIDs BLE — datos funcionales indispensables para hablar con el sensor.

De la decompilación extrajimos hechos técnicos del protocolo — la información mínima indispensable para que cualquier app pueda hablar con el sensor:

• UUIDs de las características BLE (afd0ffa0…ffa8).
• Offsets y largos de los paquetes: el reporte de impacto son 20 bytes, el RTC son 7 bytes, el reporte IMU son 15 bytes.
• Valores de byte: modos (0x00 NORMAL, 0x01 ACTIVE, 0x20 EXT_CMD, 0x40 TEST), tipos de reporte (1=LINEAR, 2=ROTATIONAL, 3=LINEARROTATIONAL), bits de STATUS.
• Códigos de error numéricos (33=SUCCESS, 64=INVALID_PARAM).
• Secuencia de activación: escribir RTC + MODE 0x01.

Todo esto está documentado y citado en los comentarios del código. Son datos funcionales —como documentar que “el puerto HTTP es el 80”—, no expresión creativa copiada.

El cambio de arquitectura más significativo es el de las alertas: la app original dependía de un backend de Specialized que recibía el evento por API y mandaba el SMS desde su servidor. Cuando Specialized dio de baja el servicio, eso dejó de funcionar. OpenAngi elimina esa dependencia por completo: el teléfono manda el SMS directamente, sin pasar por ningún servidor. Es más simple, más confiable, y no depende de que nadie mantenga un backend vivo.

En resumen: del APK original tomamos los datos del protocolo (UUIDs, formatos de paquete, secuencia de activación) —que son hechos técnicos necesarios para interoperar con el hardware— y construimos una app completamente nueva, con arquitectura distinta, UI distinta, y un mecanismo de alertas fundamentalmente diferente.

d. Balance global del desarrollo de software

Los números del proyecto completo reflejan la dimensión del trabajo asistido por IA:

En el cuadro se observa un detalle de las herramientas utilizadas en OpenCode:

Además: 720 trazas de razonamiento, 256 respuestas de texto, y 8 re-compactaciones de contexto (cuando la ventana de contexto se llena, el modelo comprime el historial y sigue).

¿Qué aprendimos del proceso?

La IA no reemplazó el trabajo — nosotros seguimos siendo los que conectábamos el sensor, corríamos los scripts, sacábamos las fotos, abríamos el dispositivo, decompilábamos el APK, y tomábamos las decisiones de diseño. Pero aceleró brutalmente cada paso intermedio: en vez de buscar datasheets, leer foros, y escribir parsers de bytes a mano, la conversación con los modelos nos permitió ir de “¿qué es este chip?” a “tenemos un APK firmado y funcionando” en 3 días.

Y es incluso una de las líneas de investigación que estamos incorporando al PID: lograr cerrar el lazo, dar acceso a los LLMs al hardware y a la interacción con herramientas físicas que permitan acelerar aún mas el proceso de experimentación.

La combinación de herramientas funcionó bien:

• Claude (chat web con visión, búsqueda y análisis de imágenes) fue ideal para la fase exploratoria: identificar chips por fotos, armar el plan de ataque y construir scripts incrementales.
• OpenCode (acceso al filesystem, ejecución de comandos en bash/PowerShell y edición de código) fue ideal para la fase de construcción: compilar, corregir errores de Gradle e iterar sobre 30 archivos Kotlin hasta tener un APK funcional.

Y todo el desarrollo de las apps Android —738 mensajes, 4.3 millones de tokens de entrada, más de mil llamadas a herramientas— costó exactamente cero dólares usando modelos gratuitos.

Parte 3: Hardware y Firmware — Análisis Comparativo (Antigravity vs. OpenCode)

Además de la ingeniería inversa sobre la app de Android y el protocolo BLE, el proyecto avanzó sobre el firmware binario extraído de la memoria flash del microcontrolador nRF52832 de Nordic Semiconductor (SoC ARM Cortex-M4F que impulsa el sensor ANGi).

Tanto en las fotos publicadas en el sitio de la FCC como en el dispositivo físico abierto, pudimos identificar un conector de debug de 6 pines del tipo TAG-Connect, específicamente el TC2030. Nos fue fácil identificar qué pines corresponden a GND y VCC ya que ambos respetaban el pinout estándar del conector, por lo que era de esperar que tanto SWCLK como SWDIO también coincidieran con la distribución estándar.

Los conectores TAG-Connect comerciales son costosos (el TC2030 ronda los 34 USD). En el laboratorio fabricamos una versión propia: piezas de FR4 maquinadas con el CNC, pogo-pins y alambre de clips para los pines de posición:

Utilizamos la herramienta de nRF Connect junto con un J-Link EDU para extraer el firmware del microcontrolador; afortunadamente no estaba bloqueada la lectura:

a. Extracción y decompilación base con Claude y Ghidra

Con el dump completo extraído (nRF_Connect_Programmer_1790785304145.hex), la primera tarea fue interpretar la estructura de la memoria flash del nRF52832 y preparar un flujo de decompilación automatizado. Esta fase se trabajó utilizando Claude (Sonnet 3.5) a través del chat web.

Claude analizó el archivo Intel HEX y mapeó con la arquitectura de memoria del dispositivo:

• 0x00000–0x00963: MBR (Master Boot Record de Nordic)
• 0x01000–0x1E73F: SoftDevice S132 v3.0.0 (stack BLE oficial de Nordic)
• 0x1F000–0x325DB: Aplicación ANGi (79.324 bytes, con punto de entrada Reset_Handler en 0x1F415)
• 0x70000–0x72B67: Datos persistentes en flash (Flash Data Storage / FDS)
• 0x73000–0x7B243: Bootloader DFU (33 KB)
• 0x7F000: Página de configuración del bootloader (donde el CRC32 0x01092589 coincidía exactamente con el hash de la app).

Para convertir este firmware binario crudo en código C navegable, se construyó junto a Claude una canalización de ingeniería inversa headless sobre Ghidra, escribiendo dos scripts en Java:

• SetupNrf52.java (Pre-script): Configura automáticamente el entorno de análisis ARM Cortex-M4F en Ghidra. Mapea la RAM (0x20000000) y las regiones de registros periféricos del nRF52 (NRF_RADIO, NRF_GPIOTE, NRF_SAADC, RTC, TIMER, etc.), analiza la tabla de vectores e instancia los handlers de interrupción (Reset_Handler, SVC_Handler, *_IRQHandler).
• DecompileAll.java (Post-script): Recorre todas las funciones identificadas por el motor de Ghidra y vuelca el código decompilado completo junto a las cadenas de texto (strings) a un único archivo C unificado.

Este proceso permitió obtener el código decompilado original base (app_decompiled.c), desentrañando las llamadas al SoftDevice (supervisión SVC 0xA0-0xAD para GATTS) y los literales del servicio BLE del sensor.

Una vez obtenido este archivo C crudo, la pregunta clave era: ¿hasta dónde puede llegar un modelo de lenguaje analizando este decompilado sin conocimiento previo del dispositivo?

Para responder esto, diseñamos un experimento comparativo entregándole exactamente el mismo prompt inicial y los mismos archivos base a dos herramientas asistidas por IA con entornos y agentes distintos: Antigravity (Gemini 3.6 Flash) y OpenCode (big-pickle). Como pistas físicas mínimas les proporcionamos:

• La presencia de conectividad BLE (stack SoftDevice de Nordic).
• Los sensores identificados en la PCB: el acelerómetro ST LIS3DH y el giroscopio ST L3GD20H.
• La presencia de dos LEDs de indicación.
• La lectura del voltaje de la batería a través de un canal del conversor analógico-digital (ADC / SAADC).

b. Resumen comparativo: Antigravity vs. OpenCode

A partir del mismo prompt de partida, las dos herramientas abordaron el desafío con filosofías y resultados marcadamente diferentes pero complementarios:

c. Logros principales de cada herramienta

Antigravity: Dominio del hardware y consola UART

El mayor éxito de Antigravity fue descifrar cómo habilitar la consola de diagnóstico de producción por UART oculta en el firmware. Para activarla determinó que era necesario forzar el pin P0.30 a GND durante el encendido, operando 9600 o 115200 baudios en 8N1 e identificando que los puntos de prueba corresponden a TXD en TP10 y RXD en TP12, junto con un repertorio de 11 comandos de diagnóstico.

OpenCode: Decompilación y arquitectura de firmware

Por su parte, OpenCode generó el análisis más profundo de la estructura interna del código binario. Produjo 77.793 líneas de C en app_decompiled_annotated.c, asignando firmas y parámetros documentados a 83 funciones clave. Asimismo, descubrió la máquina de estados central basada en banderas de eventos (evt_set / evt_clear), tareas consumidoras y un bus de mensajes de 24 bytes. Finalmente, trazó el mapa completo de la memoria Flash (MBR, SoftDevice BLE, código de aplicación, Bootloader y UICR), fechando la compilación original del firmware en el 6 de octubre de 2021.

d. Descubrimiento de la consola UART y validación en placa real

La identificación de los test points (TP) en la PCB fue un proceso mucho más artesanal: con tester y osciloscopio fuimos identificando las señales físicas. GND y VCC resultaron fáciles de ubicar a partir del holder de la pila.

Una vez confirmada la existencia de la UART y del pin de consola, la tarea fue encontrarlos en la PCB. Para ello observamos la actividad de todos los TP al energizar el dispositivo e identificamos seis TP con señales de pulsos (posiblemente comunicación con los sensores), otros seis con señal en bajo y un único TP con señal en alto (3V).

En un principio esperábamos identificar al menos dos TP en alto, correspondientes a la UART en estado de reposo (idle). Al consultar con Antigravity, el modelo explicó que en modo normal la UART no se configura para no consumir energía, y solo se habilita al arrancar con nivel bajo en P0.30. Esto nos llevó a pensar que el único TP en alto debería ser el pin de modo test (P0.30) con una pull-up.

Le planteamos este escenario al modelo:

👤 Usuario (step 258):

“Otra pregunta de los Test Points: hay uno solo a VCC, hay 6 en los que se ve algún tipo de señal/pulsos, y otros 6 que se ve señal bajo a GND. ¿Puede ser que la UART no se configure si no está en modo test? ¿Por qué esperaría ver dos pines más con Idle en 3V de la UART?”

🤖 Antigravity (step 259):

*“¡Exactamente! Tu deducción es 100% correcta.

1. ¿Por qué no ves la UART en 3V (Idle) en modo normal?
En los microcontroladores Nordic nRF52, la UART no está asignada permanentemente a pines fijos por hardware….

2. Explicación de las señales que estás midiendo actualmente (Modo Normal)

• 1 Test Point en VCC (3V): Alimentación principal de la batería / VDD.
• 6 Test Points con pulsos/señales: Bus de comunicación por bit-banging de los sensores MEMS (LIS3DH + Giroscopio): Clock, MOSI, MISO, Chip Selects (CS). Interrupciones de impacto/movimiento (INT1 / INT2).
• 6 Test Points en GND: Pines deshabilitados, entradas no usadas o pads de tierra del PCB (GND).”*

👤 Usuario (step 260):

“No tengo acceso a los pines, el nRF52 es BGA. ¿Sería esperable que entonces el test point a VCC sea ese pin con una pull up?”

🤖 Antigravity (step 261):

“¡Sí, es ALTAMENTE probable! Esa es la arquitectura estándar de test de fábrica en placas con encapsulado BGA.”

Esta respuesta nos descolocó un poco, porque no logramos identificar qué fundamento había detrás de la relación entre el encapsulado BGA del nRF52 y la conclusión de que ese test point correspondía a una pull-up. Si bien le habíamos dado algunas pistas para evaluar si podía llegar al mismo razonamiento al que habíamos llegado nosotros, la conclusión del modelo parecía ir más allá de lo que permitían inferir el contexto disponible en ese momento.

Para probar la teoría, forzamos el estado bajo en P0.30 durante el encendido: los LEDs titilaron con una secuencia diferente, confirmando el modo test. Al medir nuevamente con osciloscopio, dos test points que antes estaban en bajo pasaron a estar en nivel alto (idle de la UART).

👤 Usuario (step 262):

“Lo puse a masa, al encender titilaron rojo y verde, y TP10 y TP12 ahora pasaron a VCC. ¿Deben ser TX y RX, no?”

🤖 Antigravity (step 263):

“¡EXCELENTE NOTICIA! 🎉 ¡Ingresaste con éxito al Modo Test de Fábrica!”

Paso siguiente, conectamos un conversor serie-USB a ambos pines. Mediante prueba y error determinamos cuál de los TP era RX y cuál TX, y verificamos el baudrate real de 38.400 baudios:

Con Realterm configurado a 38.400 baudios y el dispositivo en modo test, pudimos interactuar con la consola de producción y verificar el repertorio de comandos:

El modo de testeo permite modificar el modo de trabajo del dispositivo desde el punto de vista de RF para procesos de certificación. Esto se alinea exactamente con la documentación fotográfica del sitio de la FCC: el dispositivo alimentado por fuente y tres cables saliendo por un costado (UART TX/RX y GND):

e. Modos de funcionamiento BLE

El firmware alterna entre cuatro estados para equilibrar consumo y disponibilidad de conexión. En reposo profundo (DeepSleep), la radio está apagada y el acelerómetro puede despertar el sistema al detectar movimiento. Entonces comienza una ventana de publicidad rápida (FastAdvertising, aproximadamente 20–100 ms entre anuncios) para que la app pueda conectarse; si no hay conexión tras unos 30 segundos, vuelve al reposo.

Al establecerse el enlace BLE, el sensor queda en modo conectado y monitorea impactos. Si se pierde la conexión, pasa a publicidad lenta (SlowAdvertising, aproximadamente 1,28–2,56 s entre anuncios), que permite reconectar sin mover el dispositivo. Si la desconexión y la inactividad se prolongan, vuelve al reposo profundo. Los intervalos y tiempos son aproximados.

f. Algoritmo de detección de caídas

Para entender cómo decide el ANGi que ocurrió una caída, consultamos distintos modelos y contrastamos sus respuestas con el firmware. Gemini (Gemini 3.6 Flash), ChatGPT (GPT 5.6 Luna) y Copilot coincidieron en señalar dos partes relevantes: la configuración de impacto del acelerómetro LIS3DH y el análisis triaxial del giroscopio L3GD20H. Sin embargo, sus explicaciones no tenían el mismo nivel de cautela. ChatGPT reconoció varias incógnitas; Gemini propuso una secuencia más completa, pero presentó como hechos algunas hipótesis que el código disponible no demostraba. Por ejemplo, interpretó un búfer como circular y previo al impacto, y los conteos 8 y 2 como muestras de confirmación.

La revisión posterior del C mostró que esas interpretaciones iban más allá de la evidencia: el código escribe muestras, pero eso no prueba que luego se lean para decidir si hubo una caída; los valores 8 y 2 aparecen como parámetros, pero no se localizó quién los consume ni qué significado temporal tienen. OpenCode aportó una lectura más detallada de las dos ramas. En su análisis, impact_detector_config (0x2F60C) asigna por defecto un umbral de 16000 y 8 cuentas; un segundo configurador, impact_detector_config_b (0x2F6BC), usa 2 cuentas. También reportó que un umbral explícito se multiplica por 10 y que la reconfiguración escribe el registro 0x32 del LIS3DH. OpenCode ubicó el callback, el umbral y las cuentas en los offsets +0x0C, +0x10 y +0x54 del estado del detector, respectivamente, pero no encontró el consumidor que permita confirmar cómo se aplican las cuentas para decidir un impacto.

Para la inicialización del LIS3DH, OpenCode (Big Pickle) anotó una secuencia de parámetros 2000, 2500, 3000, callback, 16000, 1000, 10, 10, 30, 60, 60, 60, 60, 5, 2, 3, 4, 5, 7; interpretó los valores grandes como umbrales y los últimos como tiempos o duraciones. También describió una tabla de cinco escalas por eje, generada con transformaciones del tipo sqrt(x*c) y sqrt(x²*c), y señaló que esta última se usa en la comparación de magnitudes. Para el giroscopio reportó umbrales 0x4F5 (1269), 0x9D4 (2516) y 0x23D (573), elevados al cuadrado y limitados por un mínimo de 0x800 antes de escribirse en los registros 0x32–0x37. Estos datos sirven como pistas para recorrer la configuración; la interpretación de sus unidades y tiempos no queda demostrada por los valores por sí solos.

En la rama del L3GD20H, OpenCode describió axis_history_task (0x28188) leyendo los tres ejes de 16 bits y calculando una magnitud cuadrática y otra basada en las diferencias entre muestras. Según ese análisis, la tarea rastrea mínimos durante el movimiento, distingue reposo de actividad y descarta ciertos candidatos si el contador no llega a 3 o el acumulador a 20. También identificó escrituras de X, Y, Z seguidas del centinela 0xAAAA en un búfer de hasta 996 entradas (249 muestras completas). El almacenamiento de esas palabras aparece en el código; que el búfer se use como historial circular previo al impacto y que su contenido se lea para confirmar una caída sigue siendo una interpretación no verificada.

OpenCode reportó además códigos de autotest del LIS3DH: 0x21 para la prueba satisfactoria y 0x42, 0x43 y 0x44 para fallas en los ejes X, Y y Z. También atribuyó el callback del detector a 0x1388; el contraste posterior con el HEX mostró que esa dirección pertenece al SoftDevice y calcula disponibilidad de recursos, no es una función de callback de impacto de la aplicación. Todavía no se encontró la ruta que consume el umbral y las cuentas para invocar un callback.

En el análisis final con Copilot, comparamos el decompilado de Ghidra con el HEX original, en vez de tomar las anotaciones realizadas por los otros LLMs del código como prueba. Esa comparación permitió encontrar código Thumb en 0x27AD4 que Ghidra no había identificado como función. Al seguir la inicialización de la placa, se pudo relacionar ese handler con la configuración de GPIO 9 y observar que compara el pin y su modo. El hallazgo amplía lo que se sabe sobre las interrupciones, pero no identifica qué componente está conectado a esa entrada ni demuestra que participe en la detección de caídas.

Con la evidencia disponible, la reconstrucción más sólida sigue siendo parcial y comprende dos ramas observables:

• LIS3DH: se verifica WHO_AM_I = 0x33; hay configuradores que guardan un umbral predeterminado de 16000, conteos 8 o 2 y un puntero asociado. En cierta ruta también se escribe el registro 0x32. No se localizó el consumidor que indique cómo esos parámetros confirman un impacto.
• Giroscopio L3GD20H: una rutina lee sus tres ejes de 16 bits, calcula la suma de cuadrados y la suma de cuadrados de las diferencias entre muestras, y compara los resultados con variables globales y límites visibles de 3 y 20. También actualiza contadores y mínimos, puede almacenar X, Y, Z, 0xAAAA y señalizar un evento. La identidad del sensor está confirmada; lo que no se ha resuelto son las unidades y el significado físico de estos valores. “Energía” y jerk son analogías, no conclusiones verificadas.

Una tarea del LIS3DH publica telemetría mientras la rutina del giroscopio L3GD20H analiza muestras. Esto confirma que hay actividad en paralelo, pero no que ambas ramas converjan en una única decisión. Todavía no logramos reconstruir el criterio que transforma esas señales en una caída confirmada ni la ruta que genera una alarma.

Podríamos continuar con un análisis más exhaustivo, pero consideramos que lo realizado era suficiente para los objetivos y las actividades del proyecto. Lo que si es seguro,y lo confirma el análisis de la apk, es que el dispositivo informa 3 clases de eventos o alarmas, Linear, Rotational y Linear+Rotanional.

g. Revisión crítica de los archivos C y alucinaciones detectadas

La auditoría minuciosa de los archivos .c entregados reveló fortalezas pero también inconsistencias y alucinaciones típicas de los LLMs:

app_annotated.c (Antigravity) Aunque su informe en Markdown era muy preciso respecto a la consola UART, el archivo C entregado (630 líneas) fue incompleto:

• Falta de código decompilado: Solo contiene prototipos de funciones, tablas de registros y comentarios; no incluye el cuerpo de ninguna función.
• Inconsistencias técnicas:
  • Declaró que los sensores utilizaban buses periféricos SPI0/TWI0 y SPI1/TWI1 por hardware, cuando el firmware en realidad implementa bit-banging por software.
  • Identificó el giroscopio como un L3GD20 con registro WHO_AM_I de 0xD4 o 0xD7 (en realidad 0xD7 corresponde al L3GD20H).
  • Describió UART0 como simple “logging SEGGER RTT”, omitiendo que era la consola de comandos de producción.
  • Omitió en el archivo C los datos de P0.30, baudrate y Test Points.

app_decompiled_annotated.c (OpenCode) Con 1,9 MB y 77.793 líneas de código decompilado desde Ghidra, fue una entrega masiva pero con fallas de formato:

• Cuerpos de funciones duplicados: De las 134 funciones renombradas, aproximadamente 79 contenían el cuerpo anotado nuevo y, justo debajo, el cuerpo original de Ghidra sin borrar con una llave { suelta, impidiendo compilar directamente.
• Confusión en el trigger de la UART: El código de main() chequea si P0.30 está en nivel bajo para parpadear 3 veces e ingresar a rf_test_console_poll(). OpenCode interpretó erróneamente este chequeo como “detección de botón / contacto de carga”.
• Errores de mapa de registros: Interpretó que el nRF52832 tenía un puerto de pines “P1” (solo posee el puerto P0 con 32 GPIOs), confundió la base de registros GPIO 0x50000500 y descartó la respuesta 0xD7 del sensor por desconocer que correspondía al L3GD20H.

Veredicto final y flujo de trabajo óptimo

Ninguna herramienta por sí sola entregó el resultado perfecto, pero juntas se complementaron: Antigravity ganó en la verificación física y de hardware; OpenCode ganó en amplitud de decompilación y arquitectura. El flujo óptimo consistió en tomar la base decompilada de OpenCode, limpiarla de duplicados mediante un script, e incorporar los parámetros de hardware descubiertos por Antigravity.

h. Mediciones de consumo y caracterización eléctrica

Para finalizar la parte de hardware, realizamos mediciones de consumo con el dispositivo en diferentes estados utilizando el Power Profiler Kit II (PPK2) de Nordic Semiconductor.

La herramienta permite medir corrientes desde 200 nA hasta 1 A con frecuencia de muestreo de 100 ksps. Conectamos el ANGi al PPK2 alimentándolo a 3.0 V (simulando la pila botón CR2032) y ensayamos tres modos de funcionamiento representativos del ciclo de vida del dispositivo:

i. Actividad normal conectado (Vigilancia en ruta)

Una vez que el sensor despierta (por movimiento) y se conecta exitosamente al teléfono, entra en su régimen de operación normal: el procesador se mantiene vigilando el acelerómetro/giroscopio y emite un latido (heartbeat) periódico por BLE:

Analizando el intervalo estable (a partir de los 20 segundos de captura en adelante, duración 41.86 s):

• Corriente promedio: 0.062 mA (62.1 µA)
• Corriente máxima: 21.64 mA (picos de radio BLE)
• Corriente mínima: 0.004 mA (3.9 µA en sleep inter-eventos)
• Carga consumida: 0.000722 mAh
• Vida útil estimada (CR2032 continua): 3.706,6 horas (~154.4 días)

ii. Búsqueda de conexión y Bajo Consumo (Sleep / Standby)

Cuando el sensor se enciende o detecta movimiento, intenta conectar durante una ventana inicial (15 a 38 segundos). Si no encuentra ningún teléfono autorizado, cancela la transmisión y entra en modo de bajo consumo profundo a partir del segundo 40:

Analizando el periodo de bajo consumo (de 40 a 90.8 segundos, duración 50.85 s):

• Corriente promedio: 0.021 mA (21.0 µA)
• Corriente máxima: 0.024 mA (24.1 µA)
• Corriente mínima: 0.019 mA (18.8 µA)
• Carga consumida: 0.000297 mAh
• Vida útil estimada (CR2032 continua): 10.949,6 horas (~456.2 días / 1.25 años)

iii. Secuencia de búsqueda intensa tras desconexión

Si el sensor pierde la conexión BLE con el teléfono durante un trayecto (por ejemplo, al alejarse o perder señal), inicia una secuencia intensa de reintentos repetidos (aproximadamente 15 intentos en un intervalo de 180 a 900 segundos) para intentar restablecer la sesión:

Analizando el periodo de ráfaga de búsqueda (segundos 180 a 900, duración 720 s):

• Corriente promedio: 1.878 mA (1877.8 µA)
• Corriente máxima: 23.73 mA (picos continuos de publicidad y escaneo RF)
• Corriente mínima: 0.004 mA (3.7 µA)
• Carga consumida: 0.375561 mAh
• Vida útil estimada (si estuviese 100% del tiempo buscando): 122.5 horas (~5.1 días)

Tabla resumen de consumo y vida útil estimada

El manual de Specialized especifica una autonomía típica de 6 meses con salidas de 6 a 8 horas semanales. Con los datos empíricos medidos en el PPK2, podemos realizar la validación técnica:

• En un uso de 7 horas semanales conectado (pedaleando a 62.1 µA):
  7 h × 0.0621 mA = 0.435 mAh/semana
• En el tiempo restante (161 horas semanales) en Standby (a 21.0 µA):
  161 h × 0.0210 mA = 3.381 mAh/semana
• Consumo total estimado: ~3,816 mAh/semana.

Para una pila botón CR2032 con una capacidad nominal utilizable de 225 mAh:
Autonomía Teórica = 225 mAh / 3.816 mAh/semana ≈ 58,9 semanas (~13,5 meses)

Considerando la autodescarga natural de la pila CR2032, las caídas de tensión provocadas por los picos repetidos de radio BLE a 21–23 mA, la variación de temperatura al aire libre y las eventuales búsquedas por desconexión, la estimación del fabricante de 6 meses es un valor sumamente realista y conservador desde la perspectiva de la ingeniería de hardware.

Parte 4: Actualización DFU

El proceso de desaramado del sensor original no fue particularmetne inocuo, la PCB quedó con problemas, ademas de que la apertura del gabinete no fue nada delicada, perdiendose la junta de sellado (IP67), así que me compré un par de sensores nuevos. Resulta que los sensores venían con un firmware más viejo y eran demasiado sensibles a los golpes, y con la app oficial dada de baja no había forma de actualizarlos. La idea inicial fue tratar de usar el firmware que había extraído con el J-Link y subírselo por Bluetooth, esta vez sin romper el sensor.

a. Armado del paquete y primer intento con Claude

Le pasamos el dump a Claude (Sonnet 5.5, en claude.ai) y en pocas iteraciones ordenamos el mapa de memoria: MBR, SoftDevice S132 v3.0.0, una aplicación de unos 79 KB, un bootloader Secure DFU de Nordic y una página de settings cuyo CRC coincidía con el de la app. Armamos un paquete DFU con nRF Util y un cliente en Python con bleak que reinicia el sensor en el bootloader, sube el paquete y deja un log de cada paso. Claude lo probó contra un bootloader simulado, pero el hardware real lo fue corrigiendo: buscó un UUID de DFU que no era (el sensor usa el servicio experimental de Nordic SDK 12.x, 8E400001) y el log mostró el correcto.

Con esa corrección el bootloader recibió bien el init packet (el CRC coincidía), pero lo rechazó al validarlo con un error genérico (INVALID_OBJECT) que, en ese bootloader, cubre firma, versión o formato sin decir cuál.

b. Lectura de la APK con Antigravity y hallazgo del firmware embebido

Ahí cambiamos de herramienta. Con Antigravity (Claude Sonnet 4.6 en modo Thinking y, brevemente, Gemini 3.1 Pro en Low) recorrimos nuevamente la APK descompilada.. Encontramos el código con el que la app oficial arma el DFU y, mejor todavía, el firmware oficial embebido en sus recursos: shs_v2_6_13.zip, la misma versión 2.6.13 que había aparecido en los strings del dump. El análisis de los logs anteriores apuntó a una validación de versión del firmware. Con eso se reescribió el script y se documentó el procedimiento en un README_DFU.md, y la actualización por fin funcionó: el sensor aceptó el paquete, completó la transferencia y arrancó con la versión nueva.

Un detalle que nos dolió descubrir: sacar el firmware con el J-Link fue innecesario. El binario estuvo siempre ahí, dentro de la APK, empaquetado como un recurso más de la app. Esperábamos lo contrario: que el firmware se descargara de los servidores del fabricante según las actualizaciones que fueran saliendo, y no que viajara adentro de la app. Con esa suposición ni se nos ocurrió mirar los recursos de la APK antes de abrir el sensor y conectarle el programador. Además, el .zip de la APK trae algo que nuestro dump no tenía: el init packet ya armado por el fabricante, que es lo que el bootloader valida. El dump sirvió para entender cómo está organizado el firmware, pero para actualizar el sensor alcanzaba con revisar la APK primero.

c. Integración del DFU en OpenAngi

Con la actualización ya funcionando desde el script de Python, el paso siguiente fue llevarla a la propia app. Le pedimos a OpenCode (con mimo-v2.6-flash-free, un modelo del tier gratuito) que revisara la carpeta del DFU (el README, el .zip, el script y el log de la actualización exitosa) y que agregara a OpenAngi un aviso y la actualización por DFU cuando detecte un firmware viejo. El resultado fue una detección por versión contra la 2.6.13, una fila “Firmware (desactualizado)” en la pantalla del dispositivo y una serie de diálogos: actualización requerida, batería baja, progreso, reinicio y error con botón de reintentar. Por debajo usa la librería DFU de Nordic, con el .zip oficial embebido y los parámetros que había usado la app original.

La prueba final, verificada en hardware, fue un sensor (SHS-E6F5) que pasó de la 2.5.22 a la 2.6.13: se envió el comando, el sensor confirmó, apareció como DfuTarg, la transferencia tardó 47 s y, al reconectar, la app leyó la versión nueva y la sesión volvió a activarse. Esa ventana de unas 2 h 10 min fue un único modelo, sin subagentes: 213 mensajes del asistente contra 13 nuestros, 291 llamadas a herramientas (125 de bash, 61 ediciones y 59 lecturas), unos 1,05 millones de tokens de entrada, 65 mil de salida y 243 mil de razonamiento, a costo cero.

Parte 5: Balance del uso de herramientas de IA

Cada parte de este proyecto usó herramientas de IA de forma diferente. A modo de cierre, vale la pena ver el panorama completo y extraer algunas conclusiones sobre cómo se repartieron las tareas entre modelos y qué funcionó mejor en cada contexto.

a. Qué hizo cada herramienta

Los detalles de uso de cada sesión están documentados en las partes anteriores (Parte 1, Parte 2, Parte 3, Parte 4). A grandes rasgos, la división fue:

Ninguna herramienta reemplazó el trabajo de campo: cada hipótesis pasó por medición o ejecución real sobre el sensor. Lo que los modelos aceleraron fue el triage del binario crudo, la escritura y corrección de herramientas, y la lectura de miles de líneas de Java decompilado. Pero no pueden tocar el hardware, y algunas de sus interpretaciones estaban equivocadas.

b. Escala del proyecto y costo

El volumen de trabajo procesado por los modelos fue considerable. Los números exactos de OpenCode provienen de su base de datos SQLite; los de Claude y Antigravity son estimaciones basadas en los registros de sesión:

El grueso del desarrollo —apps Android, decompilado del firmware, actualización DFU— corrió íntegramente en tiers gratuitos, a costo cero.

c. Especialización observada y limitaciones

La selección de herramienta no fue aleatoria: cada una mostró ventajas claras según la tarea.

• Claude (interfaz web con visión) fue óptimo para la fase exploratoria: identificar chips por foto, analizar capturas de pantalla de nRF Connect y construir scripts incrementales sin acceso al filesystem.
• OpenCode (terminal con bash, edición de archivos y compilación) fue la herramienta natural para construir y depurar aplicaciones reales: compilar con Gradle, corregir errores y mantener coherencia en más de 30 archivos Kotlin a la vez.
• Antigravity (agente con acceso al filesystem y modo Thinking) resultó eficaz cuando la tarea requería razonamiento sobre código Java decompilado complejo y depurar errores de protocolo no documentados.

Todas las herramientas mostraron alucinaciones o errores en alguna instancia — detallados en la sección g de la Parte 3 y en la sección f sobre el algoritmo de detección de caídas. La regla de trabajo fue la misma en todos los casos: verificar cada resultado contra el hardware o el binario original antes de tomar decisiones.

Como ya mencionamos, esta es también una de las líneas de investigación que estamos incorporando al PID del Laboratorio: lograr cerrar el lazo, dar acceso a los LLMs al hardware y a la interacción con herramientas físicas que permitan eliminar la necesidad de un usuario presente al menos en la mayor parte del desarrollo.

Conclusiones y consideraciones legales

El proceso estuvo condicionado por el nivel de protección que presentaba el dispositivo y su software. La APK analizada no utilizaba ofuscación o cifrado que impidiera examinar su lógica, y el protocolo de comunicación con el ANGi podía ser observado y caracterizado sin necesidad de romper mecanismos criptográficos. Además, durante el análisis del hardware encontramos que el firmware del nRF52 era accesible en las condiciones en las que se encontraba el dispositivo, cuando técnicamente podría haber estado protegido mediante los mecanismos de bloqueo disponibles en el microcontrolador. Todo esto nos facilitó considerablemente el trabajo y nos permitió llevar adelante la ingeniería inversa con herramientas relativamente convencionales de análisis de software, comunicaciones y firmware. Es importante aclarar que estos elementos describen las condiciones encontradas en el dispositivo analizado y no implican que el fabricante haya diseñado deliberadamente el producto para facilitar su ingeniería inversa.

¿Qué tan legal es hacer ingeniería inversa?

Llegado este punto apareció otra pregunta: si el dispositivo es nuestro, ¿qué ocurre con la ingeniería inversa que hicimos para volver a utilizarlo? Para este punto recurrimos a ChatGPT (OpenAI, GPT-5.6 Luna) para consultar sobre los aspectos legales del proceso, particularmente en el contexto argentino. La conclusión general fue que hay una diferencia importante entre analizar un software para descubrir la información funcional necesaria para interoperar con un dispositivo propio y copiar, modificar o redistribuir el software propietario original. En este trabajo se utilizó la APK de Ride como objeto de análisis para descubrir el protocolo de comunicación, pero las aplicaciones desarrolladas posteriormente fueron escritas desde cero y no incorporan código, recursos ni layouts de la aplicación original. Del mismo modo, el firmware original del dispositivo no forma parte del desarrollo de OpenAngi; fue utilizado únicamente como material de análisis y, posteriormente, para validar experimentalmente el mecanismo de actualización DFU. De hecho, ni siquiera fue necesario analizar el firmware para implementar OpenAngi: terminó siendo más bien una excusa para explorar el uso de herramientas de IA en el proceso de ingeniería inversa aplicado a firmware.

La cuestión resulta especialmente interesante al pensar en una eventual publicación del proyecto. Una posibilidad, la que se presenta en esta página, sería publicar únicamente el proceso y las conclusiones de la ingeniería inversa; otra, documentar además el protocolo descubierto; y una tercera, eventualmente publicar el código fuente o una APK de una implementación independiente como OpenAngi. En cambio, la publicación del APK original, del código decompilado de Ride o del firmware propietario plantea cuestiones de propiedad intelectual diferentes y, por ese motivo, esos materiales no forman parte de lo que se plantea publicar. En todos los casos, se trata de una evaluación preliminar y no de asesoramiento jurídico profesional: si el proyecto avanzara hacia una distribución pública o comercial, sería necesario revisar específicamente las licencias, la propiedad intelectual y las marcas involucradas.

Hay una excepción interesante dentro del propio desarrollo. Durante las pruebas implementamos también la posibilidad de actualizar el firmware del ANGi mediante DFU. Para realizar esta prueba utilizamos el archivo binario de firmware que se encontraba incluido dentro de la APK original. Esto nos permitió comprobar experimentalmente el proceso de actualización y verificar que era posible implementar el mecanismo de DFU de forma independiente. Sin embargo, el binario utilizado no es código desarrollado por nosotros, sino un componente propietario que provenía de la aplicación original. Por ese motivo, no consideramos apropiado redistribuirlo como parte de una aplicación propia sin analizar previamente sus derechos y condiciones de uso. La solución que estamos evaluando es mantener una aplicación experimental que incluya ese archivo únicamente para las pruebas de DFU y, por separado, una versión de OpenAngi sin el firmware propietario. Esta última sería la candidata para una eventual distribución pública.

En el laboratorio hemos realizado diversos proyectos utilizando modulos inalámbricos, ya sea ESP32 en sus diversas variantes, o el nrf52840 de Nordic. Siempre solemos seguir las guías de diseño que recomiendan los fabricantes, lo que involucra habitualmente colocar el módulo sobre un borde de la placa, dejando un área libre alrededor de la antena, para optimizar el rendimiento de la misma. Sin embargo en mas de una oportunidad hemos visto proyectos que no siguen estos lineamientos, lo que nos generó la duda de que tanto es una recomendación y que tanto una obligación.

Espressif explica bastante bien cómo ubicar el módulo con antena PCB en sus Hardware Design Guidelines.

Sin embargo, queríamos saber cuánto cambia la señal de un ESP32 con antena en la placa según dónde se coloque. Si la diferencia era de unos pocos decibeles, o si implicaba la imposibilidad de establecer la comunicación.

El experimento

Para llevar adelante una serie de experimentos armamos una placa base de prueba (un PCB simple faz sobre otro para simular doble faz con plano de masa continuo) con 6 posiciones de montaje posibles para el mismo módulo físico. No usamos seis módulos distintos, sino exactamente el mismo que fuimos reubicando y sosteniendo con pines soldados como soporte mecánico y conexion eléctrica con el plano de masa. Para la posicion central removimos el cobre de lo que sería la zona de “keepout” debajo de la antena, como lo recomienda el fabricante. Esta zona suele estar definida en el footprint del modulo, lo que hace que esa recomendacion en particular se cumpla a pesar que la de la posicion no.

La placa se conecta a un Notebook corriendo una app que envía comandos por puerto serie, para la configuración de los experimentos y recolección de datos.

Ésta se comunica también con una segunda placa con un ESP32, que se mantiene fijo en una posición. Medimos RSSI y throughput en tres protocolos distintos (ESPNOW, BLE y Bluetooth Classic) inicialmente con tandas de 200 paquetes de 100 bytes cada 100 ms por corrida, una tasa baja de 8 kbps como para no saturar el enlace de entrada. En total juntamos 70 sesiones y unas 800 muestras de RSSI por posición y protocolo.

Resultado 1: la posición del footprint sí importa, y bastante

La tabla de resultados lo dice bastante claro:

Son 11 a 12 dB de diferencia simplemente por correr el chip unos centímetros dentro de la misma placa. Mismo módulo, misma distancia, misma antena. Perder 6 dB ya es recibir la mitad de la potencia. Acá se perdió casi el doble de eso solo por elegir un mal lugar.

Resultado 2: el ranking es consistente entre los tres protocolos

Los mejores y peores lugares salieron exactamente iguales en ESPNOW, BLE y Bluetooth Classic. Tres protocolos con stacks de radio distintos operando en 2.4 GHz, y todos coincidieron:

La posición 3 arrasó: fue la mejor siempre, en los tres protocolos, sacándole entre 4.1 y 7.9 dB a la segunda. La 1 quedó segunda fija. Las posiciones 4, 6 y 2 quedaron ahí en el medio, muy pegaditas entre sí. Y la posición 5, la del centro, fue por lejos la peor (o empatada abajo del todo en ESPNOW).

Por qué posición 3 gana y posición 5 pierde: la explicación de RF

Esto encaja perfecto con lo que remarca Espressif. La antena necesita despeje de cobre alrededor (sin planos de masa ni componentes metálicos cerca) para no desintonizarse, y el feed tiene que apuntar hacia un borde libre de la placa.

La posición 3 está justo en una esquina, apuntando hacia afuera y sin nada al lado que la ahogue. La posición 5 es todo lo contrario: quedó encerrada entre las otras posiciones y rodeada de cobre por los cuatro lados, el ejemplo perfecto de antena descalibrada (detuning) por falta de despeje (keepout).

Para visualizar los resultados de una forma más intuitiva que un boxplot, armamos un script que genera imágenes estilo “larga exposición con LEDs sintéticos”: superpone puntos de luz coloreados sobre la foto de la placa, uno por cada muestra de RSSI, con un glow gaussiano suave y un blend tipo screen (la luz se acumula y aclara, sin tapar lo que hay debajo). El resultado es algo más parecido a una foto de larga exposición real que a una gráfica, y permite ver de un vistazo dónde concentra cada posición su nivel de señal y cuánto varía.

Un resultado que no cierra del todo: posiciones 3 y 6

Según las guías del fabricante, las posiciones 3 y 6 deberían ser las dos mejores: ambas tienen la antena fuera del base board y el feed point cerca del borde, que es exactamente lo que recomienda Espressif. La 3 cumplió siempre, pero la 6 no anduvo tan bien. En una tanda la 4 le ganaba a la 6 y en la siguiente se daba vuelta. La 3 y la 5 fueron súper estables siempre, pero la posición 6 en particular mostró bastante variación entre repeticiones.

No tenemos una respuesta definitiva todavía, manejamos algunas hipótesis.Como retiramos y acomodamos el módulo a mano para cada sesión, una mínima variación en el ángulo de apoyo pueda modificar la medición. Además, en 2.4 GHz las paredes y objetos del entorno generan rebotes (multipath) que cambian con diferencias milimétricas de distancia, que el entorno del ensayo haya perjudicado a esa posición en particular.

Lo que el throughput NO mostró en la primera tanda

Con los 8 kbps de entrada, la velocidad de transferencia dio exactamente igual en todas las posiciones y protocolos (8.00 kbps clavados).

Eso no quiere decir que la ubicación del módulo no afecte la velocidad. A esa tasa baja el enlace trabaja súper cómodo incluso en el peor escenario: estar a -70 dBm todavía queda lejísimos del límite de sensibilidad de estos chips. Hacía falta empujar la prueba al límite.

Segunda tanda: subiendo la velocidad de transferencia

Armamos una segunda tanda de ensayos. Mismas posiciones, misma distancia, mismos tres protocolos, pero exigiendo la red con paquetes más grandes y tiempos más apretados. Llevamos ESPNOW a unos 160 kbps, BLE a 200 kbps y Bluetooth Classic a 410 kbps (entre 20 y 50 veces más rápido que antes).

El RSSI volvió a mostrar la misma diferencia marcada:

El ranking se acomodó un poco. Acá la posición 6 levantó cabeza:

La posición 3 volvió a salir primera sin despeinarse, ganando en las dos tandas y en todas las mediciones. La 6 quedó segunda en los tres protocolos, algo que en la primera tanda no se notaba tan claro y que ahora sí responde a lo que sugiere Espressif (feed mirando hacia afuera). El resto de los puestos intermedios varió un poco: en esa zona del medio las diferencias son chicas y muy sensibles al entorno.

Y el dato más curioso de la segunda tanda: a pesar de exigir la red al máximo, el throughput apenas se enteró. Se veían caídas puntuales de rendimiento por ráfagas de paquetes perdidos, pero aparecían salpicadas en todas las posiciones por igual. Hace falta degradar muchísimo más la señal para que el rendimiento caiga de forma sistemática. El RSSI acusa la mala ubicación del módulo mucho antes de que lo notes en la velocidad de transmisión.

Permutación Transmisor/Receptor: enlace bidireccional (A → B vs B → A)

Para esta tercera ronda aumentamos la distancia entre placas a 350 cm (frente a los 230 cm anteriores) y permutamos transmisor y receptor en la segunda mitad de cada ensayo. Queríamos ver si la conexión de ida (A → B) y la de vuelta (B → A) dan simétrico en RSSI y throughput, o si el sentido del enlace introduce alguna diferencia.

Ranking de posiciones a 350 cm

Con la distancia mayor, la brecha entre mejor y peor posición se mantuvo amplia (entre 14.4 y 15.8 dB):

El ranking varió un poco respecto a las tandas anteriores:

La posición 3 volvió a quedar primera en todo. Esta vez la 2 subió al segundo puesto y la 4 al tercero, bastante parejas en los tres modos. La 5 (centro) siguió última en BLE y BT Classic, cayendo hasta -81 dBm en BLE. En ESPNOW la 6 fue la que se hundió al último lugar, probablemente porque esa orientación sufre más a 3.5 metros.

Throughput y simetría del enlace

El throughput dio prácticamente idéntico en ambas direcciones (A → B vs B → A):

• BLE: 7.80 kbps en A → B vs 7.91 kbps en B → A (p = 0.2494, no significativo).
• BT Classic: 7.87 kbps en A → B vs 7.89 kbps en B → A (p = 0.7621, no significativo).
• ESP-NOW: 7.84 kbps en A → B vs 7.89 kbps en B → A (p = 0.5612, no significativo).

El sentido del enlace puede meter asimetrías de RSSI chicas, del orden de 0.3 a 1.7 dB, probablemente por pequeñas diferencias de sensibilidad o emisión entre los dos módulos concretos que usamos. Pero el throughput no se entera, y la ubicación del módulo en el PCB sigue siendo lo que realmente importa.

Visualización de campo cercano

Las visualizaciones sintéticas estaban bien, pero nos dejaron con ganas de hacer la versión real: montar un LED WS2812B físico en la placa, moverlo en el espacio con la habitación a oscuras y capturar el recorrido con una cámara. Y la hicimos, o al menos lo intentamos.

Al principio probamos mover la placa con el led con la mano por encima de la placa de prueba. Se notaban cambios de color, pero como la trayectoria no era muy pareja que digamos, no se llegaba a apreciar un patrón limpio.

Usamos entonces una impresora 3D (una Artillery Sidewinder X1). Un script en Python generaba el G-code con un recorrido sistemático en el plano XZ, montamos la placa sobre el extrusor y dejamos que la máquina hiciera el barrido con el módulo en distintas posiciones. Los resultados:

Se puede ver una significativa cantidad de “rojo” para el caso de la posición 5, lo que indica una mala recepción de la señal.

Qué nos llevamos de esto para diseñar un PCB

Mover el módulo unos centímetros dentro de la misma placa cambia el RSSI entre 11 y 15 dB. No da lo mismo cualquier rincón.

Encerrar la antena en plano de masa es lo peor que podés hacer. El módulo en el centro, rodeado de cobre, dio los peores resultados en casi todas las pruebas. El feed apuntando hacia un borde libre es el camino seguro: la posición 3 (esquina con salida despejada) ganó en las seis pruebas que hicimos, y la 6 (mismo criterio: antena fuera y feed point en el borde) también rindió muy bien en la tanda rápida. La teoría del fabricante se cumple.

Dicho esto, perder 11 dB no es lo mismo que perder la comunicación. En todas las pruebas, incluso la posición 5 (la peor) mantuvo el enlace activo y el throughput no se desplomó hasta que forzamos tasas muy altas. Si el dispositivo va a operar a distancias cortas, en un entorno con buena propagación, o con un margen de enlace generoso, una ubicación subóptima puede ser perfectamente aceptable. El problema aparece cuando el presupuesto de señal es ajustado: mayor distancia, paredes, interferencia, o módulos de baja potencia. En esos escenarios, esos 11 dB que se “regalan” por una mala posición pueden ser la diferencia entre un enlace estable y uno que se cae.

Si solo medís velocidad de transferencia no vas a notar ninguna diferencia a corta distancia, aunque la señal esté 12 dB más abajo. El RSSI es la única métrica que te canta al toque si la posición es mala. Y ojo con las posiciones intermedias: el primer y el último puesto quedaron clarísimos, pero los del medio cambiaron un poco según la prueba. Si vas a tomar una decisión de diseño basándote en una posición intermedia, medí un par de veces más.

Nota sobre el RSSI en Bluetooth Classic: en este modo el firmware no lee un RSSI absoluto en dBm como en WiFi/ESP-NOW o BLE. El controlador de Bluetooth Classic del ESP32 sólo expone esp_bt_gap_read_rssi_delta(), que devuelve un valor relativo al “Golden Receive Power Range” — el rango de potencia que el propio chip considera ideal para su algoritmo interno de control de potencia. Un valor de 0 significa “la señal está dentro del rango ideal”, negativo significa “más débil de lo ideal” y positivo “más fuerte de lo ideal”, pero no es una medida de potencia absoluta ni comparable en dB directo contra el RSSI de WiFi o BLE. Por eso en los gráficos de BT Classic vas a ver una escala relativa (por ejemplo -16 a -28) en vez de valores típicos de dBm: no representan la misma magnitud física, y no hay que compararlos número contra número con los otros dos protocolos, solo la tendencia entre posiciones dentro del propio modo BT Classic.

A mediados de 2024 surgió, dentro del Laboratorio, la idea de desarrollar un generador de señales de ECG. La inquietud fue planteada por Eduardo Filomena, uno de los integrantes del Laboratorio, con un objetivo bastante concreto: contar con una herramienta que permitiera probar equipos de electrocardiografía, pero que al mismo tiempo pudiera utilizarse con fines didácticos y demostrativos.

Para ese momento, nosotros ya llevábamos un tiempo trabajando en el desarrollo de un electrocardiógrafo inalámbrico de 12 derivaciones. Como parte de ese trabajo necesitábamos probar el equipo y, hasta entonces, las pruebas las realizábamos generalmente utilizando un generador de funciones que incorporaba algunas señales biológicas. El problema era que este equipo estaba limitado a un único canal de ECG.

Contar con un generador capaz de producir múltiples derivaciones y, además, permitirnos personalizar las señales generadas nos resultaba especialmente atractivo. No solo nos permitiría hacer pruebas más completas sobre el electrocardiógrafo, sino también generar distintas condiciones y señales para evaluar su comportamiento, y la posibilidad de automatizar sesiones de testeo.

A partir de esa necesidad comenzó el proyecto que vamos a documentar en esta serie de posts. La intención es recorrer el camino que seguimos durante el desarrollo: desde la recreación del diseño original, iniciado por Eduardo Filomena, pasando por las pruebas y los problemas que fuimos encontrando, hasta las modificaciones y mejoras que finalmente fuimos incorporando.

El punto de partida era una Raspberry Pi Pico (RP2040) programada en Arduino. El microcontrolador tenía almacenados los datos de las señales y, a partir de ellos, generaba mediante PWM las señales correspondientes a las 10 derivaciones convencionales del ECG. Como la salida del microcontrolador era una señal PWM, esta debía ser acondicionada para obtener una señal analógica. Para ello, las salidas pasaban por una serie de filtros pasa-bajos pasivos, encargados de atenuar la componente de alta frecuencia del PWM y reconstruir la forma de onda del ECG. Luego un divisor resistivo atenuaba la amplitud a valores de milivoltios.

Nuestro primer paso fue, entonces, recrear este dispositivo. Antes de modificarlo o pensar en una nueva versión, queríamos entender cómo estaba construido, cómo se generaban las señales y, sobre todo, comprobar qué tan bien funcionaba en la práctica.

Ese primer prototipo resulto de utilidad para realizar las primeras pruebas de adquisión de señales con el prototipo del electrocardiógrafo que estábamos desarrollando.

Inmediatamente después de recrear el dispositivo original, nos pusimos a trabajar en mejorar sus capacidades. Uno de los primeros cambios fue migrar el código a C. A partir de ese momento, todo el desarrollo posterior lo realizamos en Visual Studio Code, utilizando el SDK oficial de Raspberry Pi para la Pico. Como ocurre cada vez más en nuestros proyectos, buena parte del desarrollo y de las tareas de programación fue asistida por distintas herramientas de inteligencia artificial, que utilizamos como apoyo durante el proceso. Pero no queríamos quedarnos solamente con una mejora del software. A medida que empezamos a utilizar el generador, también fueron apareciendo nuevas necesidades.

Nos parecía mucho más útil contar con un dispositivo que pudiera transportarse fácilmente y utilizarse de manera independiente, sin depender de una computadora durante las pruebas. Por eso decidimos incorporar una batería (18650 LiPo) como fuente de alimentación, junto con una placa para gestionar su carga. Esto, además de hacerlo portátil, tenía otra ventaja interesante para nuestro caso: permitía trabajar con la referencia de masa flotante respecto de otros equipos durante los ensayos.

También incorporamos una interfaz de usuario propia, basada en una pantalla OLED y un encoder rotativo. De esta manera, podíamos seleccionar las señales y configurar el generador directamente desde el dispositivo, sin necesidad de conectarlo a una PC.

Todo el diseño del gabiente lo fuimos realizando en Fusion360, pasando por varias versiones.

El diseño electrónico

El diseño del circuito también fue pasando por varias etapas. A medida que avanzábamos con el desarrollo y entendíamos mejor qué necesitábamos del dispositivo, fuimos modificando tanto la electrónica como la forma de acondicionar las señales. En primera medida cambiamos por una Raspberry Pi Pico 2 (RP2350), para poder mejorar el rendimiento del dispositivo. Si bien el microcontrolador no era el cuello de botella del sistema, si nos permitía contar con más memoria y un procesador mas rápido.

La implementación final cuenta con filtros pasa-bajos activos, específicamente Sallen-Key, diseñados para reconstruir las señales analógicas a partir de las salidas PWM de la Raspberry Pi Pico. El diseño estuvo bastante influenciado por el uso de componentes que ya teníamos disponibles en el laboratorio. Los operacionales son OPA2335 de Texas Instruments, amplificadores operacionales cuya principal caracteristicas que nos interesaba es el hecho qde que son “rail-to-rail”, lo que significa que pueden manejar voltajes de entrada y salida que se acercan mucho a los de alimentación. Buscando que componentes pasivos teniamos a disponibilidad, llegamos a una combinacion que nos permitia tener una fc de 256Hz, adecuada para la aplicación.

Antes de llevar el circuito a la placa, realizamos distintas simulaciones para verificar su comportamiento y ajustar los componentes. Esto nos permitió evaluar la respuesta en frecuencia, la atenuación de la componente de alta frecuencia del PWM y la forma de onda obtenida a la salida.

Simulación

Como se puede ver en la imágen, la simulación se llevó a cabo utilizando LTspice, un simulador de circuitos electrónicos gratuito desarrollado por Analog Devices.

La salida de los filtros pasa por un divisor resistivo que reduce la señal, un segundo operacional configurado como seguidor emisor desacopla el divisor de una resistencia de salida de 470 ohm, que pretende simular la impedancia de tejido.

Además, por ese mismo momento estábamos a punto de comenzar en el Laboratorio un nuevo proyecto: el desarrollo de un marcapasos externo. Esto nos llevó a agregar una funcionalidad que, si bien no era necesaria para el funcionamiento del generador de ECG, podía resultar muy útil a futuro. Incorporamos tres circuitos de entrada conectados al ADC de la Raspberry Pi Pico, destinados a detectar los pulsos generados por un marcapasos.

La idea detrás de esta incorporación era ir un paso más allá de simplemente generar señales de ECG. A futuro, queríamos utilizar este hardware como parte de un sistema capaz de simular la interacción entre un corazón y un marcapasos, avanzando eventualmente hacia la implementación de un modelo in silico del corazón. En ese momento todavía era una idea a futuro, pero nos pareció interesante dejar preparada la plataforma para que el mismo dispositivo pudiera formar parte de ese desarrollo.

Generación y procesamiento de las señales

Otra de las mejoras que incorporamos fue ampliar las posibilidades de generación de señales. Además de las señales de ECG, agregamos señales de prueba básicas —senoidales, cuadradas y triangulares— con la posibilidad de modificar directamente su amplitud, offset y frecuencia. Estas señales fueron particularmente útiles durante el desarrollo, ya que nos permitieron probar cada etapa del sistema utilizando formas de onda conocidas y fácilmente parametrizables. De esta manera podíamos verificar por separado la generación mediante PWM, el funcionamiento de los filtros y la respuesta de las salidas antes de pasar a señales más complejas. Pero la parte más interesante vino al trabajar con señales de ECG reales. Para esto utilizamos la Lobachevsky University Electrocardiography Database (LUDB), una base de datos que contiene registros de ECG de 12 derivaciones. Desarrollamos un notebook en Python encargado de tomar estos registros y transformarlos en datos que pudieran ser utilizados directamente por el firmware de la Raspberry Pi Pico. El primer paso es leer el registro y obtener las 12 derivaciones. A partir de una de ellas se detectan los picos correspondientes a los complejos QRS, que utilizamos como referencia para identificar los distintos ciclos cardíacos presentes en el registro.

En lugar de seleccionar simplemente un latido cualquiera, buscamos aquel que pudiera repetirse de manera continua. Para cada ciclo posible calculamos la diferencia entre su valor inicial y final, considerando todas las derivaciones, y seleccionamos el que presenta la menor diferencia. De esta manera obtenemos un latido que, al comenzar nuevamente después de finalizar, genera una transición lo más suave posible entre ciclos.

Una vez seleccionado el ciclo, extraemos las muestras correspondientes a las nueve derivaciones que utilizamos en el generador y las llevamos a una escala adecuada para su representación como valores enteros. En nuestro caso, los datos son reescalados mediante la operación 2000 + 30000, quedando centrados alrededor del valor 30000.

Este centrado a media escala responde al funcionamiento de la Raspberry Pi Pico: al alimentarse con una fuente única (0V a 3.3V) y operar con una resolución de PWM de 16 bits (0 a 65535), el valor 30000 establece un nivel de continua o masa virtual de aproximadamente 1.51V (45.7 de ciclo de trabajo). De este modo, se dispone del margen necesario para representar tanto las deflexiones positivas (ondas P, R, T) como las negativas (ondas Q, S) de la señal del ECG sin recortes en 0V.

Finalmente, todas estas muestras se convierten en enteros y se empaquetan automáticamente en un archivo de cabecera .h. El archivo contiene el array con las muestras del latido, junto con una estructura que almacena información adicional del registro, como el ritmo y las características asociadas a la señal. El resultado es, entonces, un latido de ECG real convertido en un formato directamente utilizable por el firmware. La Raspberry Pi Pico no necesita procesar la señal original ni acceder a la base de datos: simplemente dispone en memoria de las muestras del ciclo y puede reproducirlas de manera repetitiva a través de las salidas PWM. Este procesamiento también nos permitió algo que buscábamos desde el comienzo: poder incorporar nuevas señales al generador sin tener que modificar manualmente el firmware. A partir de un registro de la base de datos, el notebook se encarga de seleccionar y preparar el latido y generar el archivo que posteriormente incorporamos al proyecto. De esta manera, el generador pasó a contar con dos grandes grupos de señales: por un lado, señales sintéticas y parametrizables para las pruebas del hardware; y por otro, señales fisiológicas reales, procesadas y preparadas para su reproducción en el dispositivo.

Comunicación y CLI

Para facilitar y automatizar testeo decidimos tambien agregar una CLI al dispositivo, para poder modificar mediante comandos el comportamiento del mismo, por ejemplo el tipo de señal (sintética o real) y sus parámetros. Luego creeamos una pequeña App en Python con una interfaz grafica para controlar el dispositivo de manera mas amigable. Otra funcionalidad importante de esta app es que nos permite ver en tiempo real las senales que se están generando. Esto permitiria en un futuro comparar la señal generada con una hipotetica señal adquirida y evaluar la perfimrance del sistema de adquisicion, una manera de “cerrar el lazo”.

Una limitación y el próximo paso

A pesar de todas estas mejoras, el generador todavía tenía una limitación importante: las señales que podía reproducir estaban definidas de antemano y almacenadas en memoria. Podíamos elegir entre distintos registros y reproducir señales reales, pero no teníamos una forma sencilla de modificar su morfología o su frecuencia cardíaca en tiempo real. Esto empezó a resultar cada vez más evidente a medida que utilizábamos el dispositivo para hacer pruebas. Si queríamos cambiar la frecuencia cardíaca, modificar alguna característica de la morfología o generar una condición determinada, necesitábamos preparar previamente una nueva señal y volver a incorporarla al firmware. La pregunta que apareció entonces fue bastante natural: ¿podíamos generar el ECG en tiempo real, en lugar de limitarnos a reproducir señales previamente almacenadas? A partir de esta pregunta, en los próximos posts vamos a explorar el uso de modelos matemáticos para la generación de señales de ECG. La idea es pasar de un sistema basado principalmente en la reproducción de registros almacenados a uno en el que podamos controlar de manera mucho más precisa las características de la señal, modificándolas en tiempo real según lo que necesitemos probar. Esto abre una nueva etapa del proyecto, en la que ya no solo nos interesa reproducir un ECG, sino también entender cómo podemos modelarlo y generarlo. Pero había además una limitación que no era solamente técnica. Al repetir indefinidamente un mismo registro, también estábamos perdiendo parte de la dinámica propia de un corazón real. Cada ciclo era exactamente igual al anterior: el intervalo RR se repetía, la morfología de las ondas permanecía constante y no existía una variación natural de la frecuencia cardíaca. Tampoco teníamos una dinámica de la línea de base, ni pequeñas variaciones latido a latido en la amplitud y duración de las distintas componentes. En otras palabras, podíamos reproducir muy bien una determinada señal, pero no estábamos reproduciendo el comportamiento dinámico que hay detrás de esa señal. Esto empezó a ser especialmente evidente cuando pensamos en lo que queríamos hacer con el generador. No nos alcanzaba con tener un ECG que “se pareciera” a un registro real; queríamos poder modificar su frecuencia cardíaca, introducir variabilidad, cambiar su morfología y simular distintas condiciones sin tener que buscar y almacenar un nuevo registro para cada caso. La primera versión seguía siendo muy útil para probar la electrónica y verificar la adquisición de señales reales, pero tenía un límite bastante claro: no estábamos simulando un corazón, estábamos reproduciendo una grabación de un corazón. Y justamente esa diferencia fue la que nos llevó a buscar una forma de generar el ECG a partir de un modelo matemático.

Por lo pronto, los archivos necesarios para la implementación de esta primer versión del generador están disponibles en GitHub, en el repo del Laboratorio.

Hace unos años se acercó al Laboratorio de Prototipado un médico con la inquietud de poder medir la presión arterial utilizando un tonómetro de pulso. Un tonómetro de pulso es un dispositivo que mide la presión sanguínea y las características de la onda de pulso directamente sobre una arteria superficial, generalmente en la muñeca. El sensor aplana la arteria radial contra el hueso y mide la presión necesaria para mantenerla colapsada. La idea era poder incorporar esta funcionalidad al BioAmp, de manera de poder medir simultáneamente la presión arterial y la actividad eléctrica del corazón. La medición simultánea de ECG y presión permite estimar parámetros como el tiempo de tránsito de pulso (PTT), correlacionado con la rigidez arterial y utilizado como indicador temprano de riesgo cardiovascular.

Inicialmente se intentó replicar un sistema, con el que ya estaban trabajando, que implicaba el uso de un sensor de presión invasivo. Este es un dispositivo médico diseñado para la monitorización continua y precisa de la presión arterial y otros parámetros fisiológicos. Funciona mediante la inserción de un catéter directamente en un vaso sanguíneo (habitualmente una arteria), el cual transmite la presión a un transductor externo que convierte la señal mecánica en una señal eléctrica. Las tubuladuras del sensor se llenaban con agua, el extremo del catéter era modificado con una membrana flexible (dedo de guante de látex o un globo) y se colocaba en la muñeca del paciente. La presión arterial movía la membrana y con ella la columna de agua, permitiendo medir la presión arterial. El sensor se conectaba a uno de los canales diferenciales del BioAmp, la salida tipo puente de Wheatstone generaba una diferencia de potencial proporcional a la presión ejercida que podía ser monitoreada junto con la señal de ECG. Este sistema no resultó muy efectivo, al menos en nuestra implementación, con dificultades para el llenado de las tubuladuras y problemas para evitar burbujas de aire dentro de las mismas. Además, desde el punto de vista dinámico, el sistema hidráulico introducía una compliancia elevada y un comportamiento fuertemente amortiguado, lo que degradaba la fidelidad de la forma de onda de presión y reducía la sensibilidad del sensor.

Rediseño

Decidimos rediseñar el sistema desde cero, modificando el transductor, buscando algo más fácil de utilizar. Durante la investigación bibliográfica que emprendemos cuando llevamos adelante un proyecto, una de las fuentes de búsqueda son patentes. Una que nos resultó particularmente interesante es la patente US20050177047A1; “Device for, and a method of, transcutaneous pressure waveform sensing of an artery and a related target apparatus”.

En la imagen del dispositivo se podía observar el sensor de presión, una suerte de cono de gel que transmitía la presión arterial desde la superficie exterior al sensor. Ya estábamos en la búsqueda de sensores de presión invasiva para evaluar su reutilización, y de la imagen nos pareció reconocer el encapsulado del sensor utilizado, si bien no estamos 100% seguros se parece mucho al MPX2300DT1 de NXP.

Este sensor es un transductor de presión de silicio de 0 a 2.3 MPa (0 a 23 bar) con salida de voltaje compensada en temperatura, utilizado en dispositivos de monitoreo de presión invasiva.

Modelado CAD

Comenzamos el modelado CAD del dispositivo con el objetivo de reproducir la geometría descrita en la patente. Para el cono de gel se optó por utilizar silicona, diseñando y fabricando previamente un molde en PLA mediante impresión 3D. El molde se fijaba en una morsa para asegurar estabilidad durante el proceso de colado.

En lugar de emplear silicona líquida convencional (RTV), se utilizó una pistola termofusible. Aunque coloquialmente se las denomina “pistolas de silicona”, las barras empleadas están compuestas en realidad por polímeros termoplásticos (habitualmente EVA u otros copolímeros). No obstante, debido a la similitud en la consistencia final del material solidificado y su facilidad de procesamiento, se decidió evaluar esta alternativa como solución práctica y de bajo costo.

Fueron necesarios múltiples prototipos, tanto del molde como del cono de gel, para optimizar la geometría y lograr un buen “colado”. La estructura del resto del dispositivo también pasó por varias iteraciones, buscando una geometría que permitiera sujetar el sensor de forma segura y que a la vez fuera cómoda de utilizar.

Pruebas

En el video podemos ver la utilización del prototipo conectado al BioAmp y visualizando la señal de presión en el software BrainBay. Dada la versatilidad de este software es posible armar un diagrama de flujo para procesar la señal y obtener la presión arterial directamente en mmHg.

Si además se suma la captura de la señal de ECG, se obtienen registros como el siguiente:

El rediseño permitió obtener una señal de presión con morfología compatible con una onda de pulso radial fisiológica, evitando las limitaciones dinámicas del sistema hidráulico inicial. La integración con el BioAmp demostró la viabilidad de registrar simultáneamente ECG y presión arterial mediante un transductor no invasivo de bajo costo.

Si bien el sistema aún requiere calibración formal contra un método clínico de referencia, los resultados preliminares validan el concepto de tonometría radial integrada y abren la puerta al desarrollo de herramientas para la estimación de rigidez arterial y parámetros hemodinámicos derivados.

Parte de las actividades del Laboratorio de Prototipado involucra brindar soluciones tecnológicas a otros laboratorios de la Facultad de Ingeniería de la UNER. Dentro de esas actividades, comenzamos hace un tiempo a trabajar con el Centro de Ingeniería en Rehabilitación e Investigaciones Neuromusculares y Snsoriales (CIRINS), apoyando en una de las ramas de investigación que llevan adelante, la que tiene que ver con el estudio del dolor. En una primera etapa nos pidieron el desarrollo de un algómetro, un dispositivo que permite medir el umbral de dolor de un paciente. El dispositivo completo involucraba una suerte de sistema robótico con un actuador lineal que ejercía presión sobre la piel del paciente, un sensor de fuerza para medir la presión ejercida y un sistema de control del actuador.

En una segunda etapa nos pidieron el desarrollo de un algómetro de mano, que permitiera medir el umbral de dolor de un paciente de forma manual, simplificando significativamente el sistema.

Rediseño

El sistema de control original contaba con 3 fuentes de alimentación: una para el actuador lineal, otra para un motor de pasos y otra para el sistema de control. En el sistema manual buscamos simplificar este esquema, y gracias a la reducción de componentes, logramos alimentar todo el dispositivo con una sola fuente. En la versión original utilizábamos un ESP32 DevKit, pero al no encontrarse en stock al momento de la compra, optamos por un FireBeetle 2 ESP32-E. Esta placa incluye un cargador de batería LiPo, lo que nos simplificaría la incorporación de una batería en el futuro para hacerlo totalmente portátil. La interfaz de usuario está compuesta por una pantalla OLED de 128x64 píxeles y un encoder rotatorio con pulsador; también dejamos disponibles los pulsadores de la placa FireBeetle para un uso rápido. La placa FireBeetle 2 ESP32-E cuenta ademas con una serie de leds que se utilizaron para indicar el estado del dispositivo. El sensor de fuerza utilizado es el mismo que usamos en el sistema original, el FMAMSDXX005WC2C3 de Honeywell. También le agregamos un conector BNC para utilizar como entrada con un pulsador (para indicar eventos desde el exterior) o como salida para sincronizar con otros dispositivos.

Modelado CAD

Basamos el diseño físico en el sistema original, pero simplificamos la estructura para hacerlo significativamente más compacto y liviano. Formamos la estructura general con un stack de piezas impresas en 3D sostenidas por 3 tornillos M3x35mm. Elegimos esta estrategia porque nos permitía una rápida iteración en el rediseño de sectores particulares, además de facilitarnos la mejor orientación de las piezas a la hora de imprimirlas.

Colocamos el sensor en una suerte de “cuna” diseñada en la pieza plástica que sostiene el sensor y soldamos los cables directamente a sus pads, evadiendo así la necesidad de integrar una PCB adicional.

Realizamos la transmisión de fuerza (desde el punto de contacto exterior hacia el sensor interno) mediante una varilla de acero de 2.5mm de diámetro, de deslizamiento suave por estar colocada dentro de una camisa de bronce y sostenida por una pieza plástica. Un resorte se encarga de ejercer fuerza sobre la varilla, manteniéndola siempre en contacto con el sensor con una precarga constante cercana a los 120 gramos.

A la pieza plástica que sostiene la varilla le diseñamos además un pequeño mango para permitirnos separar la varilla del sensor temporalmente y trabarla. De esta manera, podemos proteger de sobrecargas al delicado sensor mientras le estamos cambiando el efector de estimulación al paciente (que puede ser punzante, una hoja sin filo, entre otros).

Fabricamos además un capuchón que se acopla en la parte frontal para proteger tanto el efector como las piezas internas cuando estamos trasladando el dispositivo. En la parte trasera incluimos también un sujetacables, compuesto de una suerte de cuña impresa en material blando (TPU) y una tuerca de roscado rápido, lo cual nos posibilitó fijar firmemente el cable al cuerpo del dispositivo, evitando tirones.

Por último, el gabinete para el módulo de control lo estructuramos en dos grandes partes encastradas, unidas por 3 tornillos M3.

Para poder utilizar cómodamente los botones táctiles de la placa FireBeetle, diseñamos e imprimimos unas pequeñas estructuras plásticas flexibles que, una vez presionadas externamente, permiten accionar los botones en placa. Si bien usamos iteraciones de este estilo de soluciones previamente, en esta oportunidad los botones de la FireBeetle estaban soldados a 90 grados. Esta orientación nos requirió un análisis más detallado asegurando que la rotación natural de la pieza impresa lograra el desplazamiento lineal óptimo para disparar el “clic” interno mecánico del pulsador sin dañarlo.

El efector final con el que se ejerce dolor, en este caso particular, es una aguja hipodermica a la cual se le removió el bisel para evitar cortes y la posibilidad de penetrar la piel. Evaluamos la posibilidad de imprimir una traba tipo Luer para la colocación de la aguja, pero dado el tamaño y complejidad de la pieza, optamos por reutilizar una traba plástica de una jeringa.

Pruebas

Para probar el dispositivo, decidimos imprimir unas piezas adicionales de amarre que nos permitían, por un lado, montar con firmeza el estimulador en una morsa, y por otro lado, apoyar sobre el actuador una pesa estándar de 100 gramos.

Realizamos capturas de datos en vacío y con la pesa sobre el sensor, tanto a 10Hz (frecuencia de uso normal con visualización en tiempo real) como a 500Hz (frecuencia máxima durante la realización de mediciones).

Al analizar las mediciones del sensor, lo primero que aparece es que los valores están bien en promedio: cuando se aplican 100 g, el sistema mide muy cerca de ese valor. Sin embargo, si uno mira la señal en detalle durante largos períodos, aparecen pequeñas variaciones y “corrimientos” lentos que no son ruido al azar, sino efectos propios del sensor, como cambios con la temperatura o acomodamientos mecánicos internos. Esto también se ve en los histogramas, donde la distribución no es perfectamente limpia, y en el análisis en frecuencia, que muestra que casi toda la variación ocurre muy despacio, cerca de cero Hz.

Ahora bien, en el uso real esto cambia bastante. Si el sensor se calibra en cero justo antes de medir y se utiliza solo durante unos pocos segundos, todos esos efectos lentos dejan de ser un problema importante. En ese corto intervalo, el sistema se comporta de manera mucho más estable, y lo que domina es simplemente un poco de ruido eléctrico en la señal. En la práctica, esto significa que el sensor funciona bien para mediciones rápidas, siempre que se haga una calibración previa. Incluso se puede mejorar aún más promediando unos pocos valores para suavizar la lectura. En resumen, aunque no es ideal para mediciones prolongadas sin recalibrar, sí es perfectamente usable y confiable en escenarios cortos y controlados, que es donde mejor rinde.