¿Alguna vez te has preguntado qué pasa realmente dentro del monitor que cuelga sobre una cama de hospital, ese que dibuja una línea verde con cada latido mientras un número parpadea en la esquina?
Detrás de esa pantalla hay una cadena de sensores, amplificadores, filtros y decisiones de diseño muy deliberadas. Puedes construir tú mismo una versión simplificada de esa cadena, y al terminar vas a entender cómo funciona un monitor de cabecera de una forma que ninguna clase ni ninguna hoja de datos te puede enseñar.
Para eso es esta guía. Vas a adquirir tres señales fisiológicas al mismo tiempo (electrocardiograma, fotopletismografía y temperatura), acondicionar cada una en el dominio analógico y dibujar las tres en vivo en una sola pantalla TFT-LCD, tal como lo hace un monitor real. Muchos proyectos de salud con Arduino se apoyan en módulos ya armados que esconden todo el trabajo analógico. Este no: la etapa frontal está hecha con componentes discretos, así que cada ganancia, cada frecuencia de corte y cada offset son decisiones que tú tomas y que puedes defender.
Yo construí esta versión para BI3014.1, el Laboratorio de Tecnologías Biomédicas del Tecnológico de Monterrey, Campus Ciudad de México. Todo lo que sigue es el diseño que terminó funcionando, incluyendo los obstáculos que lo fueron moldeando.
Una aclaración importa más que cualquier circuito de este post: esto es un prototipo didáctico construido para una práctica universitaria, no un dispositivo médico. Nunca se diseñó, probó ni certificó para diagnosticar o monitorear pacientes, y no debe usarse con ese fin. Para lo que sí sirve, y muy bien, es para entender de forma práctica cómo está construido un monitor de signos vitales.
Qué hace en realidad un monitor de signos vitales#
Antes de diseñar cualquier cosa, conviene saber qué estás imitando.
El CENETEC (Centro Nacional de Excelencia Tecnológica en Salud) define un monitor de signos vitales como un dispositivo que permite detectar, procesar y desplegar de forma continua los parámetros fisiológicos de un paciente. En la práctica, un monitor adquiere una señal del cuerpo, la amplifica, la acondiciona y la despliega en pantalla.
La mayoría de los monitores clínicos son modulares, para que el médico elija qué variables seguir: ECG, frecuencia respiratoria, presión arterial no invasiva o invasiva, temperatura, saturación de oxígeno (SpO2), saturación venosa de oxígeno, gasto cardiaco, dióxido de carbono, presión intracraneal o presión de gases en la vía aérea durante anestesia. Según su movilidad se dividen en monitores fijos (anestesia, adultos, neonatales) y monitores de transporte, ya sea intrahospitalario, interhospitalario o en ambulancia.
En su estructura, sin embargo, todos se reducen a cuatro piezas: una fuente de alimentación, una unidad de procesamiento de información, una pantalla y un módulo de adquisición por cada parámetro. Esa estructura es justo el plano que vas a escalar a algo que un Arduino pueda manejar.
La arquitectura: cinco bloques, no un solo circuito enredado#
Organiza el proyecto en cinco bloques: tres bloques de adquisición de señal (ECG, PLETH y temperatura), un bloque de integración construido alrededor de un Arduino MEGA 2560 y un bloque de visualización, una pantalla TFT-LCD.
Los bloques de ECG y PLETH pasan por tres etapas cada uno: adquisición de la señal, filtrado y acondicionamiento analógico, y conversión analógico-digital. La temperatura se salta la etapa intermedia por completo y va directo del sensor al ADC, porque el LM35 ya entrega una señal limpia y lineal que no necesita acondicionamiento.
Pensar en bloques, y no en un solo diagrama enredado, fue la decisión de ingeniería más útil que tomé, y es la que más te recomiendo. Te permite diseñar, construir y depurar cada cadena de adquisición por separado antes de preocuparte por cómo van a compartir un mismo Arduino y una misma pantalla.
Los bloques tampoco pasaron directo al protoboard. Primero simulé los circuitos en Proteus y Tinkercad, y una vez armados los verifiqué en la mesa de trabajo con osciloscopio y multímetro. Simular antes de armar y medir después de armar es una costumbre que vale la pena conservar en cualquier proyecto analógico: la simulación es barata de iterar, y los instrumentos son los que te dicen qué está haciendo de verdad tu circuito y no lo que supusiste que haría.
Qué necesitas#
- Arduino MEGA 2560, el bloque de integración que lee todos los canales y controla la pantalla.
- Una pantalla TFT-LCD con controlador HX8357, para el bloque de visualización.
- Electrodos de Ag/AgCl con sus latiguillos, para el ECG.
- Un amplificador de instrumentación AD620, para la etapa frontal del ECG.
- Un LED infrarrojo IR333C y un fototransistor PT333-3B, para la etapa frontal de PLETH.
- Un amplificador operacional TL081, para la etapa de acondicionamiento de PLETH.
- Un sensor de temperatura LM35.
- Dos baterías de 9 V, para la fuente bipolar que necesita la etapa de instrumentación.
- Un segundo Arduino UNO, usado únicamente como fuente de 5 V (más abajo explico por qué).
Las tres cadenas de señal de un vistazo#
| Señal | Transductor | Amplificación | Filtrado | Pin del Arduino |
|---|---|---|---|---|
| ECG | Electrodos de Ag/AgCl, derivación II de Einthoven | AD620, ganancia 1000 V/V, offset de 2.5 V | Pasabanda, 1.2 a 150 Hz | A12 |
| PLETH | LED IR333C y fototransistor PT333-3B | Etapa con TL081, ganancia 180 (ajustada experimentalmente) | Pasabanda, 1.2 a 150 Hz | A8 |
| Temperatura | LM35 | Ninguna, la salida del sensor ya es usable | Ninguno | A10 |
La cadena de ECG: convertir milivolts en algo que el ADC pueda ver#
La electrocardiografía mide la actividad eléctrica del corazón, y todo empieza con el transductor: un par de electrodos de Ag/AgCl (plata / cloruro de plata) que convierten la señal fisiológica en una señal eléctrica. Usé la configuración de la derivación II de Einthoven para la adquisición.
Este es el problema que tienes que resolver. Un ECG típico de un adulto tiene una amplitud de apenas 0.5 a 4 mV, en un rango de frecuencia de 0.05 a 150 Hz. Si metes eso directo a un Arduino no vas a ver más que ruido, porque la señal es miles de veces más pequeña que el paso del ADC.
La amplificación la aporta un amplificador de instrumentación AD620, que lee la señal de forma diferencial directamente desde los electrodos. Que sea diferencial importa: es lo que rechaza la interferencia que ambos electrodos captan en modo común, que en un cuarto lleno de cableado eléctrico es casi todo lo que captan. Configuré la ganancia en 1000 V/V con un offset de 2.5 V, de modo que la señal amplificada queda cómodamente entre 0 y 5 V, centrada dentro del rango de entrada del Arduino en lugar de recortarse contra tierra.
Después de la amplificación, la señal pasa por un filtro pasabanda de 1.2 a 150 Hz para quitar la deriva de la línea base y el ruido de alta frecuencia, y la señal acondicionada se lee en el pin analógico A12.
La cadena de PLETH: leer el pulso con luz#
La fotopletismografía mide los cambios pulsátiles en el volumen de sangre, lo cual te permite recuperar el ritmo cardiaco de forma óptica en lugar de eléctrica. El transductor es un LED infrarrojo IR333C que ilumina un lecho capilar (la yema de un dedo, en este caso), junto con un fototransistor PT333-3B del otro lado que detecta la luz transmitida y la convierte en señal eléctrica. Con cada latido, las pulsaciones arteriales cambian cuánta luz se absorbe, y esa variación es la señal que buscas.
Usé el fototransistor en configuración de emisor común, alimentando una etapa de acondicionamiento construida con un amplificador operacional TL081. La ganancia, 180, se determinó de forma experimental, ajustada para que el trazo se viera claro en pantalla y no derivada analíticamente.
Vale la pena nombrar dos compromisos honestos, porque son el tipo de decisión que distingue un prototipo que funciona de uno equivocado:
Aquí la PLETH es cualitativa, por decisión propia. Son tantos los factores externos que afectan la absorción de luz que resulta una herramienta poco confiable para medir el volumen absoluto de sangre. La traté estrictamente como un indicador cualitativo de flujo sanguíneo, que es exactamente lo suficiente para visualizar una onda de pulso y nada más de lo que el montaje puede sostener con honestidad.
El filtro es compartido, no óptimo. La PLETH normalmente se filtra entre 0.5 y 5 Hz. Por simplicidad la filtré en la misma banda de 1.2 a 150 Hz que usé para el ECG, reutilizando un solo diseño de filtro en ambas cadenas de adquisición. Eso cuesta algo de rechazo de ruido y compra un montaje mucho más simple, que era la decisión correcta para un prototipo de laboratorio. La señal se lee en el pin analógico A8.
La cadena de temperatura: la que se mantiene simple#
La temperatura es, por diseño, la cadena más sencilla de las tres, y eso es una ventaja. Usé un sensor LM35, elegido por su precisión, su rango de trabajo y su respuesta lineal, que elimina la necesidad de cualquier curva de calibración. Su exactitud ronda los 0.25 °C, que en realidad es más fina que lo que alcanza a resolver el Arduino: con la referencia por defecto de 5 V, un paso del ADC de 10 bits equivale a unos 4.88 mV, y con los 10 mV/°C que entrega el LM35 ese paso se traduce en cerca de 0.49 °C. Dicho de otro modo, quien fija la resolución de la medición es la conversión y no el sensor, y esa resolución se lee directo en el código: la constante 500.0 / 1023 del sketch de abajo es justamente el tamaño del paso, 0.489 °C por cuenta. Ese es el resultado buscado y no un compromiso, porque medio grado por paso sobra para la temperatura corporal humana, que es justo lo que este monitor existe para desplegar, y una lectura con un solo decimal dentro del rango clínicamente interesante no pide nada más fino. Más bits en el ADC solo habrían resuelto dígitos que la exactitud del propio sensor no respalda, es decir, precisión falsa: números que se ven más certeros de lo que realmente es la medición.
Como el LM35 ya entrega un voltaje analógico limpio y proporcional a la temperatura, se salta por completo el filtrado y el acondicionamiento, y se lee directamente en el pin analógico A10. La conversión de cuentas del ADC a grados Celsius es la línea que vas a encontrar en el sketch de abajo:
T = LM35 * (500.0 / 1023)donde LM35 guarda el número de pasos medidos por el ADC de 10 bits. El 500 tampoco es un número mágico: con la referencia analógica de 5 V, la escala completa corresponde a 5000 mV y, como el LM35 entrega 10 mV/°C, esa escala completa abarca 500 °C. Dividir esos 500 °C entre las 1023 cuentas del ADC es lo que convierte las cuentas crudas en grados Celsius, y es la misma aritmética del tamaño de paso de arriba vista desde el otro lado: el voltaje de referencia y la escala de salida del sensor resumidos en una sola cifra.
Un pequeño refinamiento hace que la lectura sea agradable a la vista. La variación natural entre muestras hace que el número en pantalla brinque todo el tiempo, así que el valor que se despliega es el promedio de las últimas cinco mediciones de temperatura, escrito con un decimal. Ese promedio se actualiza cinco veces por cada ciclo del programa: en el sketch, la rama de la temperatura se ejecuta cada vez que el contador de columnas x1 es múltiplo de 63, es decir en 0, 63, 126, 189 y 252 conforme el trazo recorre la pantalla. Son dos cincos distintos y conviene no confundirlos: uno es cuántas muestras entran al promedio y el otro es cada cuánto se vuelve a dibujar el resultado.
La alimentación: el problema que no vi venir#
Alimentar tres cadenas de adquisición tan distintas desde una sola tarjeta resultó más complicado que cualquiera de los diseños de filtro, y ahí se fue la mayor parte de mi tiempo de laboratorio.
La etapa de instrumentación con el AD620 necesitaba una fuente bipolar, así que la alimenté con dos baterías de 9 V conectadas como un riel dividido de -9 V a +9 V. El LM35, el LED infrarrojo, el fototransistor y la etapa sumadora de 2.5 V del circuito de ECG necesitaban un 5 V estable, pero un solo Arduino no podía entregar suficiente corriente para todos a la vez. La solución fue agregar un segundo Arduino UNO dedicado exclusivamente a suministrar ese riel de 5 V, lo cual resolvió el problema de forma limpia, aunque no elegante. Por último, el shield de la pantalla TFT-LCD funciona con el riel de 3.3 V del propio Arduino MEGA.
Al inicio también intenté alimentar todo desde una sola fuente de banco con varios voltajes. No funcionó. El ruido de la línea eléctrica se filtraba a las señales de una forma que las baterías nunca provocaron, probablemente por los filtros Notch: sí formaban parte del diseño desde el principio, pero nunca quedaron bien calibrados, porque no tenía a la mano el equipo necesario para caracterizarlos. Volver a alimentar con baterías las etapas analógicas sensibles lo resolvió de inmediato.
Si vas a construir tu propia etapa frontal, tómalo como un atajo más que como una advertencia. Por algo tanta instrumentación biomédica sigue dependiendo de fuentes aisladas y con respaldo de batería en la entrada, y vas a sentir ese motivo la primera vez que veas 60 Hz montados encima de un complejo QRS.
Dibujar tres señales al mismo tiempo en una pantalla TFT-LCD#
El bloque de visualización es una pantalla TFT-LCD basada en un controlador HX8357, manejada con las librerías Adafruit_GFX y Adafruit_TFTLCD. Llegar hasta ahí fue todo un proyecto aparte.
No existe una sola librería bien documentada que funcione con todas las variantes de esta pantalla, y el controlador que más se menciona en internet es el ILI9341, no el HX8357 que en realidad tenía. Identificar qué controlador traía mi pantalla, antes de que algo se dibujara correctamente, fue una de las sesiones de depuración más difíciles de todo el proyecto. Si tu pantalla solo se ve en blanco, sospecha del controlador antes que del cableado.
Una vez que la pantalla ya se comunica con el Arduino, la lógica de dibujo es sorprendentemente simple. La PLETH y el ECG se dibujan como gráficas que se desplazan en vivo: por cada muestra nueva, el programa traza una línea recta desde la posición de la muestra anterior hasta la actual. Cuando el trazo llega al borde derecho de la pantalla, ambas gráficas se borran y el dibujo vuelve a empezar desde el borde izquierdo, lo cual marca el final de un ciclo del programa. La temperatura, al ser un número y no una forma de onda, simplemente se imprime como texto.
En pantalla, la temperatura aparece en amarillo en la esquina superior derecha, la PLETH en cian en la mitad superior y el ECG en verde en la mitad inferior. Ese esquema de colores no es decoración: es lo que permite leer el arreglo de un vistazo, igual que en un monitor real.
Aquí está el sketch completo de Arduino, TFTLCDemi.ino. Los comentarios dentro del código están en español, tal como los escribí originalmente, y dejé el código funcionando sin tocar en lugar de ordenarlo después:
#include <Adafruit_GFX.h> // Core graphics library
#include <Adafruit_TFTLCD.h> // Hardware-specific library
#define LCD_CS A3 // Chip Select goes to Analog 3
#define LCD_CD A2 // Command/Data goes to Analog 2
#define LCD_WR A1 // LCD Write goes to Analog 1
#define LCD_RD A0 // LCD Read goes to Analog 0
#define LCD_RESET A4 // Can alternately just connect to Arduino's reset pin
// For the Arduino Mega, use digital pins 22 through 29
// (on the 2-row header at the end of the board).
// D0 connects to digital pin 22
// D1 connects to digital pin 23
// D2 connects to digital pin 24
// D3 connects to digital pin 25
// D4 connects to digital pin 26
// D5 connects to digital pin 27
// D6 connects to digital pin 28
// D7 connects to digital pin 29
//Variables
int Ox[316];
int ECG[316];
int x1 = 0; //Contador
//Temperatura
int LM35;
float TEMPERATURA;
float T1 = 0;
float T2 = 0;
float T3 = 0;
float T4 = 0;
#define BLACK 0x0000
#define BLUE 0x001F
#define RED 0xF800
#define GREEN 0x07E0
#define CYAN 0x07FF
#define MAGENTA 0xF81F
#define YELLOW 0xFFE0
#define WHITE 0xFFFF
Adafruit_TFTLCD tft(LCD_CS, LCD_CD, LCD_WR, LCD_RD, LCD_RESET);
void setup() {
// put your setup code here, to run once:
Serial.begin(9600);
tft.reset();
tft.begin(0x8357);
tft.setRotation(1); // establece posicion vertical
tft.fillScreen(BLACK); // fondo de pantalla de color negro
tft.setTextColor(YELLOW, BLACK); // texto en color amarillo
tft.setTextSize(3); // escala de texto en 3
tft.setCursor(270, 30); // ubica cursor
tft.print((char)247);
tft.setTextSize(4); // escala de texto en 4
tft.setCursor(290, 30); // ubica cursor
tft.print('C');
// tft.fillRect(0, 0, tft.width(), 20, CYAN); // rectangulo azul naval a modo de fondo de titulo
// tft.setTextColor(WHITE); // color de texto en blanco
// tft.setTextSize(2); // escala de texto en 2
// tft.setCursor(25, 6); // ubica cursor
// tft.print("Panel de control"); // imprime texto
// tft.setCursor(0, 35); // ubica cursor
// tft.print("Zona: 1"); // imprime texto
// tft.setCursor(0, 55); // ubica cursor
// tft.print("Temperatura Humedad"); // imprime texto
// tft.drawLine(0, 170, 240, 170, RED); // linea horizontal de color rojo
// tft.setCursor(0, 185); // ubica cursor
// tft.print("Zona: 2"); // imprime texto
// tft.setCursor(0, 205); // ubica cursor
// tft.print("Temperatura Humedad"); // imprime texto
}
void loop() {
tft.fillRect(0, 70, tft.width(), tft.height() - 60, BLACK); // Se borra el display
tft.setTextColor(CYAN, BLACK); // texto en color amarillo
tft.setTextSize(1); // escala de texto en 3
tft.setCursor(10, 60); // ubica cursor
tft.print("PLETH");
tft.setTextColor(GREEN, BLACK); // texto en color amarillo
tft.setTextSize(1); // escala de texto en 3
tft.setCursor(10, 170); // ubica cursor
tft.print("ECG");
while ( x1 < 315 ) {
// Leer temperatura
if (x1 % 63 != 0) {
LM35 = analogRead(10);
TEMPERATURA = (LM35 * 500.0) / 1023; //Fórmula para calcular la temperatura
// SUMA = TEMPERATURA + SUMA;
T4 = T3; T3 = T2; T2 = T1; T1 = TEMPERATURA;
delay(1);
}
else {
LM35 = analogRead(10);
TEMPERATURA = (LM35 * 500.0) / 1023; //Fórmula para calcular la temperatura
// SUMA = TEMPERATURA + SUMA;
TEMPERATURA = (TEMPERATURA + T1 + T2 + T3 + T4) / 5;
//Escribir en TFTLCD
tft.setTextColor(YELLOW, BLACK); // texto en color amarillo
tft.setTextSize(4); // escala de texto en 4
tft.setCursor(170, 30); // ubica cursor
tft.print(TEMPERATURA, 1); //Temperatura con 1 decimal
delay(2);
// SUMA = 0; //Se borra la suma de las temperaturas
}
//Leer ECG
ECG[x1 + 1] = analogRead(12);
ECG[x1 + 1] = map(ECG[x1 + 1], 0, 1023, 0, 50);
tft.drawLine( x1 + 4, 230 - ECG[x1], x1 + 5, 230 - ECG[x1 + 1], GREEN);
delay(10);
//Leer Pulsímetro
Ox[x1 + 1] = analogRead(8);
Ox[x1 + 1] = Ox[x1 + 1] * 6;
if (Ox[x1 + 1] > 1023) {
Ox[x1 + 1] = Ox[x1];
}
else {
Ox[x1 + 1] = map(Ox[x1 + 1], 0, 1023, 0, 50);
tft.drawLine( x1 + 4, 120 - Ox[x1], x1 + 5, 120 - Ox[x1 + 1], CYAN);
}
// Ox[x1 + 1] = analogRead(8);
// Ox[x1 + 1] = Ox[x1 + 1] * 6;
// Ox[x1 + 1] = map(Ox[x1 + 1], 0, 1023, 0, 50);
// tft.drawLine( x1 + 4, 120 - Ox[x1], x1 + 5, 120 - Ox[x1 + 1], CYAN);
x1++;
delay(10); // demora de 10 mseg.
}
ECG[0] = ECG[x1]; //Se guarda el último valor medido
Ox[0] = Ox[x1];
x1 = 0;
}Un detalle de tiempos que te va a ahorrar horas#
El ADC del Arduino tiene un tiempo de conversión de 13 ciclos de reloj, y cada llamada a analogRead() necesita ese tiempo para estabilizarse antes de cambiar al siguiente canal. Si te saltas esa espera, o lees canales más rápido de lo que el ADC puede multiplexar entre ellos, obtienes lecturas incorrectas o crosstalk entre canales, donde una señal se filtra visiblemente hacia otra. Por eso el ciclo de adquisición de arriba está lleno de llamadas a delay(), y es lo primero que debes revisar si tu trazo de ECG empieza a pulsar al ritmo de la PLETH.
Con qué te quedas al final#
La recompensa es una pantalla que se comporta como aquello que querías imitar: tres variables fisiológicas, actualizándose en vivo y legibles de un vistazo.
En mi montaje, las tres señales aparecieron al mismo tiempo en la pantalla TFT-LCD, que era todo el punto. Las lecturas de temperatura ambiente del LM35 se movieron entre 23.9 °C y 25.8 °C, coincidiendo con lo que medí de forma independiente en el monitor serial. El trazo de ECG mostró complejos QRS limpios y reconocibles, y el de PLETH mostró ondas de pulso claras y sincronizadas con cada latido.
Más allá de la pantalla, te llevas algo más portable que el prototipo: la capacidad de tomar una señal que existe en el mundo físico y llevarla de punta a punta hasta un display, tomando una decisión defendible en cada etapa.
Lecciones que vale la pena llevarte a tu siguiente proyecto#
La parte difícil es la integración, no ningún circuito en particular. Con cinco bloques interdependientes, una falla en cualquiera rompe todo el sistema, así que cada conexión tiene que hacerse con cuidado y verificarse antes de avanzar. Depurar un sistema terminado que nunca ha funcionado es muchísimo más difícil que validar cada bloque conforme lo agregas.
Cuando el hardware es ambiguo, las hojas de datos le ganan a los foros. Identificar un controlador de pantalla sin documentación clara, planear un presupuesto de energía entre varios rieles y dos tarjetas, y adaptar señales para un periférico que el Arduino nunca fue pensado para manejar de forma nativa: nada de eso salió de un solo tutorial. Salió de leer con atención y resolver cada obstáculo conforme apareció, que es, honestamente, gran parte de en qué consiste la ingeniería.
Elegir la pantalla más difícil fue la decisión correcta. Un display numérico sencillo habría funcionado mucho antes. La TFT-LCD tomó bastante más tiempo, pero permitió mostrar dos formas de onda completas en distintos colores junto con una lectura numérica, así que el resultado sí se parece a un monitor de signos vitales y no a una fila de números. Cuando el objetivo del proyecto es enseñarte cómo se siente un sistema real, escoge el componente que más te acerque a ese sistema real.
Cada tropiezo aquí, la fuente de banco ruidosa, la pantalla en blanco, el Arduino que no daba suficiente corriente, terminó enseñando más que las partes que funcionaron al primer intento.
Hacia dónde llevarlo después#
- Un filtro Notch bien calibrado, caracterizado con el equipo adecuado, para que una fuente de banco sea viable y la etapa analógica frontal deje de depender de baterías.
- Estimación de SpO2, extendiendo la cadena de PLETH con un LED de una segunda longitud de onda para pasar de un trazo de pulso cualitativo a una medición real de saturación de oxígeno.
- Registro de datos, enviando las señales adquiridas por puerto serial a una computadora para guardarlas y analizarlas después, además de mostrarlas en tiempo real.
- Un solo riel de 5 V diseñado desde el inicio con suficiente margen de corriente, para eliminar la necesidad de un segundo Arduino usado únicamente como fuente.
Si estás trabajando en un proyecto de instrumentación biomédica, me encantaría saber qué construiste y con qué te tropezaste en el camino.