Introduction

During my journey as a software engineer, there have been two important milestones (there might be a third one coming soon — I’ll introduce it in a future post). The first project is something I unfortunately cannot talk about in detail. I was the inventor and the main developer, but the project does not belong to me. Still, I feel sentimental about it. It was the first project I worked on that wasactually useful to people. Before that, I wasn’t obsessed with software engineering yet. That project was the spark that started the fire that still burns today.

The second milestone is the project I’ll talk about in this series — Dyno16.

The name

Let’s start with the origin of the name. The “Dyno” part comes from a dynamometer — a tool used to measure engine torque and power. The number 16 is something that has followed me through many parts of my life.

Motivation

I feel obligated to explain the motivation behind the project. The main reason was simple: passion. I love engines, motorcycles, and cars, so building a project connected to this world felt completely natural. Another motivation was my engineering degree. I decided to develop this project as part of the work required to obtain it.

Birth of the idea

The idea appeared completely unexpectedly. One day I found an application of this type on Google Play. I became curious whether something like this could actually work, so I decided to try several of the available apps. Unfortunately, I was disappointed. None of the applications I tested worked well. To be fair, there was one paid app that supposedly worked very well, but the price was high enough that I decided not to try it. At that point I decided to dive deeper into the problem myself.

First steps

At the beginning I defined a few simple project goals.

Unlike most market solutions, I wanted the system to be simple and as cheap as possible. Because of that, I decided the project should work using only a smartphone and its built-in sensors.

Another important decision was architectural. Since backend systems were my main area of interest, I decided that all calculations would run on a server. The phone would only collect sensor data and send it to the server (along with the user interactions, of course).

Using a remote server might not sound like the best idea, but for me it was also an opportunity to improve my engineering skills. I had to design efficient algorithms and communication methods that could run on limited hardware — in my case a Raspberry Pi home server.

Challenges

To be honest, the list of challenges during development felt almost infinite.

Every time I worked on the project, a new problem appeared. But I never gave up.

Listing all the challenges would be impossible for two reasons:

  1. I finished this project several years ago and don’t remember all of them.
  2. This post would become ridiculously long.

Instead, I’ll describe two challenges that I found the most interesting.

Challenge 1: Can I get enough data?

At the very beginning I assumed the system would rely on GPS.

Anyone familiar with GPS probably already knows what comes next:
good luck with that.

I hit the wall almost immediately. GPS refresh frequency is extremely low — typically 1 Hz. That means one position sample per second.

A typical dyno run in a car lasts only a few seconds, so I would have only a handful of samples. With that amount of data I could estimate speed, but with very poor accuracy.

So I started thinking about other sensors available in smartphones.

After researching other solutions on the market, I noticed that they didn’t rely on GPS. That confirmed my suspicion: they were using the accelerometer.

A typical smartphone accelerometer works at roughly 100 Hz — about 100 times faster than GPS.

It’s not perfect for precise measurements, but given my design constraints (no external hardware), it turned out to be a reasonable compromise.

Challenge 2: Data quality

The second challenge came directly from the first one.

Accelerometer data is completely different from GPS data and much harder to interpret.

GPS provides simple samples: position and time. From those two values it is relatively easy to compute velocity and distance.

Accelerometer data is far more complicated.
It returns a 3-dimensional vector in Cartesian coordinates.

When the phone is at rest, the reference point is determined by gravity (about 9.8 m/s²). The values depend on the phone’s orientation, and they change constantly while the vehicle is moving.

But the real problem appears when the device actually starts moving.

The raw accelerometer signal is extremely noisy and almost impossible to interpret directly. I probably lost a few hairs trying to clean that data.

Eventually I applied a low-pass filter, which transformed a completely unreadable signal into something that looked like a real measurement.

In reality the processing pipeline was more complex than that. Before filtering, the data had to be normalized, vectors had to be processed, and changes relative to the reference point had to be calculated.

The full explanation would require a separate technical article, so I’ll keep things simplified here.

What’s next

Sometimes I think about returning to this project, improving it, and maybe even releasing it for users. I don’t know if or when that will happen. But if it does, I promise I’ll write a dedicated post and share more of the challenges and technical details behind Dyno16.