Back to projects
2018 · Embedded Systems · Archived

Step tracker — Indoor wearable with MSP430

A low-power wearable for indoor wayfinding. An MSP430 microcontroller reads motion and light sensors, and a Qt interface on a laptop simulates the wearable's display. My first serious embedded project, built in 2018 as a university thesis.

C C++ MSP430G2553 I2C UART Qt Creator Code Composer Studio

Problem

Smartphones rely on GPS for interactive maps, but GPS does not work indoors. I wanted to find out whether a low-power device could tell a person where they are inside a building — without depending on satellite coverage.

Solution

A wearable built around the MSP430G2553 microcontroller, with an accelerometer for motion and a light sensor for ambient light. The data travels to a laptop over a wired link, where a Qt interface turns it into a simulated position on a screen. The goal was to prove the approach before committing to real wireless hardware.

Key takeaways

  • MSP430G2553 with two communication buses: I2C to the sensors, UART to the laptop
  • MMA8451 accelerometer (X, Y, Z axes) + TSL2561 light sensor as data sources
  • C firmware with timer and I2C interrupts, designed for low power
  • Qt interface that turns sensor motion into a visible position and a step counter
  • Foundation for a real wearable: separating data capture from display keeps the architecture extensible

The problem I was trying to solve

This was my first serious embedded project, in 2018, as part of a university course on wireless and mobile networks at the University of Málaga.

The starting question was simple: how do you guide someone inside a building? Smartphones handle outdoor navigation with GPS, but GPS doesn’t reach inside. So I wanted to see if a small, low-power device could give a person a sense of place indoors — not perfect, not GPS-grade, but something useful enough to prove the concept.

The thesis statement I worked from: with a small microcontroller, a couple of cheap sensors, and a way to send the data to a screen, you can build a wearable that helps a person know where they are indoors.

What the device actually did

The hardware was a small board with three parts:

  • A microcontroller — the MSP430G2553 launchpad from Texas Instruments, chosen because of its very low power consumption.
  • Two sensors — an accelerometer (MMA8451) to detect movement, and a light sensor (TSL2561) to measure ambient light.
  • A laptop running a Qt interface that received the sensor data and showed it as a position on screen, with a step counter and a small simulation of what a wearable display would look like.

The data path was simple: sensors spoke I2C to the microcontroller; the microcontroller spoke UART over USB to the laptop; the laptop ran the display.

What the software did

Two pieces:

  1. Firmware in C, written in Code Composer Studio. It initialized the I2C bus, polled the two sensors, packaged the readings, and sent them out over UART on a timer interrupt. The structure was deliberately split: one module per sensor, one for I2C, one for UART, plus a main loop that tied them together.

  2. Interface in C++, written in Qt Creator. It received the UART stream, parsed the values, and showed them on screen. There was a “GAME mode” that turned the sensor data into a ball you could move with the device — a way to make the demo more visual than a raw number readout.

The split between firmware (the device) and interface (the display) was the key design decision. It meant the wearable and the visualizer could evolve independently: replace the wired UART with Bluetooth later, and the interface doesn’t change.

What I learned

This is the project that taught me the basics of embedded systems: how interrupts work, why I2C needs pull-up resistors, what “low power” really means when you have to keep a battery alive for a week. The hardware was simple but the lessons were not — every choice (sensor, protocol, bus) had consequences for power, latency, and code complexity.

It also taught me that a working prototype is more convincing than a perfect plan. The Qt interface with a moving ball, even crude, made the abstract idea of “indoor navigation” tangible in a way that a written proposal never could.

What I would do differently today

Looking back, the obvious gap is connectivity. The whole system is wired — the microcontroller talks to the laptop over UART-over-USB, which was the right call for a 2018 university project, but a real wearable needs to be untethered. I planned to add Bluetooth LE or a sub-GHz radio in a future iteration, but never got to it.

The PDF of the original technical document is preserved in the repository — it was my first long-form technical write-up, and re-reading it now I can see both the gap and the seed of how I still think about systems today.