Step tracker — Wearable indoor con MSP430
Dispositivo wearable de bajo consumo para guiar personas en interiores. Microcontrolador MSP430 con sensores de movimiento y luz, e interfaz gráfica en Qt que simula el wearable. Mi primer proyecto embebido serio, hecho en 2018 como trabajo de carrera.
Problema
Los smartphones usan GPS para mapas interactivos, pero el GPS no funciona en interiores. Quería saber si era viable construir un dispositivo de bajo consumo que indicara a una persona dónde está dentro de un edificio — sin depender de la cobertura de satélite.
Solución
Un dispositivo wearable basado en el microcontrolador MSP430G2553, con un acelerómetro para detectar movimiento y un sensor de luz ambiental. Los datos viajan al portátil por cable, donde una interfaz en Qt los traduce a una posición simulada y muestra el resultado como un mapa en pantalla. La idea era demostrar la viabilidad del enfoque antes de invertir en hardware inalámbrico real.
Logros clave
- MSP430G2553 con dos buses de comunicación: I2C hacia los sensores, UART hacia el portátil
- Acelerómetro MMA8451 (ejes X, Y, Z) + sensor de luz TSL2561 como fuentes de datos
- Firmware en C con interrupciones de timer e I2C, pensado para bajo consumo
- Interfaz Qt que traduce el movimiento del sensor en una posición visible y un contador de pasos
- Base de un wearable real: separar la captura de datos del display hace la arquitectura extensible
El problema que intentaba resolver
Este fue mi primer proyecto serio de embebidos, en 2018, como trabajo de una asignatura de la carrera sobre redes inalámbricas y móviles en la Universidad de Málaga.
La pregunta de partida era simple: ¿cómo guías a alguien dentro de un edificio? Los smartphones resuelven la navegación al aire libre con GPS, pero el GPS no llega al interior. Quería ver si un dispositivo pequeño, de bajo consumo, podía darle a una persona una noción de su posición en interiores — sin ser perfecto, sin calidad GPS, pero lo bastante útil como para probar el concepto.
La tesis sobre la que trabajé: con un microcontrolador pequeño, un par de sensores baratos, y una forma de mandar los datos a una pantalla, puedes construir un wearable que ayude a una persona a saber dónde está en interiores.
Qué hacía el dispositivo
El hardware era una placa pequeña con tres partes:
- Un microcontrolador — la launchpad MSP430G2553 de Texas Instruments, elegido por su bajísimo consumo.
- Dos sensores — un acelerómetro (MMA8451) para detectar movimiento, y un sensor de luz (TSL2561) para medir la luz ambiental.
- Un portátil corriendo una interfaz Qt que recibía los datos del sensor y los mostraba como una posición en pantalla, con un contador de pasos y una pequeña simulación de cómo se vería un display wearable.
El camino de los datos era simple: los sensores hablaban I2C con el microcontrolador; el microcontrolador hablaba UART por USB con el portátil; el portátil mostraba el display.
Qué hacía el software
Dos piezas:
-
Firmware en C, escrito en Code Composer Studio. Inicializaba el bus I2C, sondeaba los dos sensores, empaquetaba las lecturas, y las mandaba por UART en una interrupción de timer. La estructura estaba deliberadamente separada: un módulo por sensor, uno para I2C, uno para UART, más un bucle principal que los conectaba.
-
Interfaz en C++, escrita en Qt Creator. Recibía el stream UART, parseaba los valores, y los mostraba en pantalla. Había un “modo GAME” que convertía los datos del sensor en una pelota que podías mover con el dispositivo — una forma de hacer la demo más visual que un simple número.
La separación entre firmware (el dispositivo) e interfaz (el display) fue la decisión de diseño clave. Significaba que el wearable y el visualizador podían evolucionar por separado: cambiar el UART cableado por Bluetooth más adelante, y la interfaz no se toca.
Lo que aprendí
Este es el proyecto que me enseñó los fundamentos de los sistemas embebidos: cómo funcionan las interrupciones, por qué I2C necesita resistencias de pull-up, qué significa realmente “bajo consumo” cuando tienes que mantener una batería viva durante una semana. El hardware era simple pero las lecciones no — cada decisión (sensor, protocolo, bus) tenía consecuencias en consumo, latencia y complejidad de código.
También me enseñó que un prototipo funcionando convence más que un plan perfecto. La interfaz Qt con la pelota moviéndose, aunque fuera cruda, hacía tangible la idea abstracta de “navegación indoor” de una forma que una propuesta escrita nunca habría conseguido.
Qué haría distinto hoy
Mirando hacia atrás, el hueco obvio es la conectividad. Todo el sistema es cableado — el microcontrolador habla con el portátil por UART sobre USB, que fue la decisión correcta para un proyecto universitario en 2018, pero un wearable real necesita ser inalámbrico. Pensé añadir Bluetooth LE o radio sub-GHz en una iteración futura, pero nunca llegué a hacerlo.
El PDF del documento técnico original está conservado en el repositorio — fue mi primer write-up técnico en largo, y releyéndolo ahora veo tanto el hueco como la semilla de cómo sigo pensando los sistemas hoy.