I ride a Yamaha MT-07. Great bike. But one thing always annoyed me: I needed GPS navigation on the road, and my phone was taking a beating. Rain, cold, vibrations. After a few months, the screen started glitching. It was only a matter of time before it died completely.

So I started looking for solutions.

The problem

My stock dashboard is an old LCD panel. Not digital, not customizable. Just a basic screen showing speed, RPM, and a few warning lights. No way to add GPS or anything else to it.

I thought about mounting a second screen somewhere on the handlebars. But there is literally no space. The MT-07 has a compact cockpit, and adding a screen would look terrible and block my view. The only real option was to replace the entire dashboard.

The expensive way out Yamaha sells a newer generation dashboard for the MT-07. It has a TFT screen, looks great, and supports more features. The price? About 1,200€ with installation parts. For a screen.

I also found a guy on YouTube who builds custom motorcycle dashboards and sells them for around £349. Impressive work, but still expensive, no source code available, limited features, and no GPS integration.

I figured I could do it myself. I am a software engineer after all. How hard could it be?

Reading the bike's brain

Every modern motorcycle has an internal communication network called a CAN bus. It is the same protocol used in cars. All the sensors, the ECU, the dashboard, they all talk to each other through this network using a standard called OBD-II. I got my hands on the official Yamaha technical documentation for the 2018 to 2020 MT-07. Inside, I found the electrical diagrams, the connector pinouts, and confirmation that the bike uses CAN at 500 kbit/s.

The first step was simple. I bought a cheap ELM327 Bluetooth OBD-II adapter, plugged it into the bike's debug port, and confirmed the protocol and speed. The bike was talking. Now I needed to listen.

Listening to the network

I connected a Raspberry Pi to the CAN bus using a MCP2515 CAN module. A few wires, a bit of soldering, and I was ready. I ran a single command: *candump can0*. Instantly, hundreds of messages started flooding the terminal. Hexadecimal values flying by, updating dozens of times per second. The Raspberry Pi was now reading every single message exchanged between the bike's components.

can0  0C0   [8]  00 7A 1F 88 00 00 04 B0
can0  130   [8]  3C 00 00 00
can0  1F0   [8]  00 00 12 34 56 78 9A BC
can0  201   [8]  FF FF 00 64
can0  2A0   [8]  0F A2 00 00 13 88 00 01
can0  3D1   [8]  05 DC
can0  410   [8]  00 00
can0  5A5   [8]  01 00 00 00 00 00 00 00
can0  0C0   [8]  00 7C 20 10 00 00 04 C8
can0  130   [8]  3E 00

The data was there. I just had no idea what any of it meant.

Decoding the bytes

This was the real challenge. Each CAN message is just a series of bytes. No labels, no documentation telling you which byte means "engine speed" or "coolant temperature." Yamaha does not publish that information.

So we built our own tool. A Python backend that reads the CAN bus in real time and streams the data to a web interface through a WebSocket. On the screen, every CAN message ID was displayed as a row, with each byte shown as a column. Values updated live.

The method was straightforward. I would interact with the motorcycle and watch what changed on screen. Turn the ignition on: some bytes light up. Rev the engine: a specific pair of bytes starts climbing. Turn on the left blinker: one bit flips. Shift into first gear: another value changes.

We repeated this process dozens of times for every signal. Rev the engine to 3,000 RPM, note the byte values. Rev to 6,000, note again. Plot the relationship. Find the formula.

We also recorded full sessions so we could replay them later without needing the actual bike. This turned into a proper development environment. I could sit at my desk, replay a recorded ride, and work on the decoding at my own pace.

After many hours, we had successfully identified: engine RPM, vehicle speed, engaged gear (neutral through sixth), engine temperature, air temperature, fuel level, odometer, and the state of various lights like turn signals and high beams.

Building the interface

Once we had the data flowing and decoded, the fun part began. I built a web-based dashboard using HTML, CSS, and JavaScript. The Raspberry Pi ran a lightweight server that decoded CAN messages in real time and pushed the values to the browser via WebSocket.

The interface displayed everything the stock dashboard showed, plus additional data I always wanted: the currently engaged gear displayed as a large number in the center, estimated fuel autonomy in kilometers, trip distance and time since the last engine start, and instantaneous fuel consumption.

It worked. It actually worked. The values updated smoothly, the gear indicator was accurate, and seeing the fuel autonomy calculated live felt like a genuine upgrade over the stock experience. Was it beautiful? Not really. It was a developer's UI, functional but rough. But it proved the concept was solid.

What I wanted to add

The plan was ambitious. Beyond the basic dashboard replacement, I had a whole list of features in mind.

GPS navigation was the original motivation. The idea was to connect the Raspberry Pi to a phone app via Bluetooth and display turn-by-turn directions directly on the dashboard. Ideally something like Waze, with speed camera alerts.

I also wanted to add a lean angle sensor using an IMU (accelerometer and gyroscope). The data would be recorded and could later be overlaid on ride videos. Long term, I imagined a companion phone app that would log every ride, track fuel economy over time, and maybe even use machine learning to predict fuel autonomy more accurately based on riding patterns.

The hardware was all there. A Raspberry Pi with a touchscreen, a CAN interface, and plenty of GPIO pins for additional sensors.

Why I stopped

Everything was going well until I hit a wall that had nothing to do with technology.

To fully replace the stock dashboard, I needed to intercept signals for safety-critical systems. ABS status, engine warning lights, immobilizer communication. Testing those meant physically disconnecting the stock dashboard and riding with the custom one. If something went wrong with ABS or engine management, the consequences could be serious.

I checked with my insurance company. They confirmed that any modification to the vehicle's electrical system, especially anything touching safety components, would void my coverage. If I had an accident with a custom dashboard and the investigation revealed modified wiring, I would be on my own.

That was the end of the road. The project was technically feasible. The prototype worked for all the non-safety data. But the risk was simply not worth it.

What I learned

This project taught me more about embedded systems, reverse engineering, and vehicle protocols than any course ever could. Going from "I wonder what protocol this bike uses" to "I can read and decode every message on the network" in a few weeks was incredibly satisfying.

The CAN bus is a beautiful protocol. Simple, robust, and well-documented at the specification level. The challenge is always manufacturer-specific: every brand encodes their data differently, and none of them share the details.

If you ride a motorcycle and have ever wondered what is happening under the plastic, I can tell you: there is a constant stream of data flowing through two tiny wires, and with about 50€ worth of hardware, you can read all of it.

The project lives on a shelf now, but the Raspberry Pi, the CAN module, and all the code are still there. Maybe one day regulations or insurance policies will catch up. Or maybe I will just buy a bike that comes with a proper screen from the factory.

Until then, my phone stays in a waterproof mount. It is still getting destroyed by the rain.

Ride safe ✌