Blog · Consumo
Por qué la radio, y no el sensor, define la autonomía
En un monitor cardíaco conectado, casi nadie optimiza la parte que más energía consume.
Cuando un equipo diseña un monitor cardíaco portátil, la conversación sobre consumo casi siempre empieza en el front-end analógico. Es comprensible: es la parte delicada, la que define la calidad de la señal, y la que más atención recibe en la hoja de datos.
Pero el presupuesto energético rara vez se decide ahí.
Dónde se va la energía
En un dispositivo que transmite, el orden de magnitud del consumo suele repartirse así: el front-end analógico y el convertidor operan en microwatts o pocos miliwatts; el procesador, en modo activo intermitente, algo por encima; y el transceptor de radio, cuando enciende, consume decenas de miliamperes.
La diferencia no está solo en la corriente instantánea, sino en el producto corriente × tiempo. Cada ventana de transmisión implica encender el radio, sincronizar, transmitir y esperar confirmación. Cuanto más grande es la carga útil, más ventanas se necesitan y más tiempo pasa el radio encendido.
La consecuencia práctica: reducir a la mitad los bytes que salen del dispositivo tiene un efecto sobre la batería que ninguna optimización del front-end puede igualar.
Por qué no basta con comprimir en firmware
La objeción evidente es que la compresión ya se puede hacer en software, en el microcontrolador que ya está ahí. Y es cierto —hasta cierto punto.
- El MCU tiene que despertar para comprimir, y despertarlo tiene un costo.
- El costo energético de la compresión pasa a depender de qué más esté ejecutando el procesador, lo que hace el presupuesto difícil de acotar.
- El tiempo de CPU dedicado a comprimir es tiempo que no está disponible para detección de arritmias, gestión del enlace o el resto de la aplicación.
Un bloque de hardware dedicado invierte esa relación. La compresión ocurre en el camino del dato, sin intervención del procesador, con un costo energético acotado y predecible. El MCU puede quedarse dormido más tiempo, no menos.
El criterio de diseño que se desprende
De aquí sale la restricción que gobierna el diseño de un bloque de compresión para este tipo de dispositivo: el núcleo tiene que consumir menos energía que la transmisión que elimina. Si no cumple eso, no importa qué tan buena sea su razón de compresión.
Es una restricción incómoda, porque acota mucho cuánta lógica puedes gastar. También es la razón por la que un algoritmo genérico de propósito general, por bueno que sea comprimiendo, casi nunca es la respuesta correcta aquí: gasta demasiado para el ahorro que consigue.
Qué medir
Si estás evaluando compresión para un dispositivo de este tipo, las preguntas útiles no son sobre la razón de compresión aislada. Son estas:
- ¿Cuántos joules cuesta comprimir un minuto de señal?
- ¿Cuántos joules ahorra esa compresión en tiempo de radio encendido?
- ¿Cuál es el saldo neto en tu perfil real de transmisión, no en el del fabricante?
- ¿Qué le pasa a ese saldo cuando el enlace se degrada y hay retransmisiones?
La cuarta suele ser la que decide, y es la que menos se mide.