A telemetry interface on Raspberry Pi: staying smooth while data flows

01The one-screen idea

I built this project individually: the embedded system, data collection, interface and technical infrastructure were all mine. The starting point was simple. Instead of following vehicle location and status data from separate sources, I wanted to present them in one clear interface on an embedded device. Live GPS data, an interactive map, navigation and real-time telemetry come together on the same screen.

On the telemetry side there are speed, signal strength, battery status and sensor data. On paper, placing these on a screen does not look hard. The real challenge is keeping the interface smooth while all of them update at once, and doing that not on a powerful desktop computer but on a Raspberry Pi.

The one-screen idea also has a user side. An interface used in a vehicle is not studied at length; it needs to be readable at a glance. So where each piece of information sits on the screen, and which appears large or secondary, is as important a decision as performance. Visual simplicity and technical lightness often pull in the same direction: fewer elements are both easier to read and lighter on the device.

02An embedded device means a different budget

When building web interfaces, I often forget that I am working on a powerful machine. An unnecessary redraw, an extra animation or an update that fires too often can go unnoticed there. On an embedded system the same habits are felt immediately. Processor, memory and graphics capacity are limited, and both data collection and the interface share that limit.

So I started designing the interface by accepting that every element has a cost. You need to think about how often each value on screen really has to update and which change actually tells the user something. A number changing many times a second can consume resources while adding nothing to readability.

GPS and sensors ──> hardware-level data collection ──> current state
                                                       ├──> map and navigation view
                                                       └──> telemetry panel (speed, signal, battery, sensors)

03Separating data collection from the interface

While bringing hardware-level data collection together with the user interface, I made sure the two did not keep each other waiting. My approach is for the collecting side to run at its own rhythm and for the interface to read that data only as much as it needs. Every new value from a sensor does not have to mean a redraw of the screen.

This separation also makes it easier to isolate problems. When a data source slows down or drops out temporarily, the interface should not freeze. A drop in signal strength, for example, is information to show the user, not a condition that locks up the interface. Making such changes visible in a calm way is the actual job of a telemetry screen anyway.

Not every new value has to rush to the screen: the interface should read data only as much as it needs.

04The map is the heaviest component

The interactive map is the most resource-hungry part of the interface. Updating the map as the location changes, drawing navigation information on top of it and letting the user interact with it all happen at the same time. Balancing this component so that it shares the same limited resources with the telemetry panel is, in my view, the most critical part of optimization in a system like this.

Here I rely on a general principle: give priority to where the user's attention is. While the vehicle is moving, keeping location and navigation current matters. Keeping telemetry values readable matters too, but each of them does not need to update at the millisecond level. Separating priorities this way lets me use limited resources more deliberately.

05Every layer at the same table

Owning every layer let me look at performance problems from a single place. To tell whether a stutter in the interface comes from data collection, the system infrastructure or the interface itself, you need to know every layer. In a team these questions can bounce between layers and people. Working alone, they all sit at the same table.

This project made me see interface performance not as a detail to improve later, but as something to consider together with the design of the data flow. Keeping information from the hardware up to date and keeping the screen smooth are two faces of the same problem.