In the auto world, there are lots of overarching standards that all automakers comply with. There are also lots of proprietary technologies that each automaker creates and uses for its own benefit. [Shehriyar Qureshi] has recently been diving into Suzuki’s Serial Data Line standard, and has created a digital dash using the data gained.
The project started with Python-based scanner code designed to decode Suzuki’s SDL protocol. Armed with the ability to read the protocol, [Shehriyar] wanted to be able to do so without having to haul a laptop around in the car. Thus, the project was ported to Rust, or “oxidized” if you will.
More after the break…
[Shehriyar] has installed the system in a Suzuki Baleno. The Raspberry Pi uses a VAG KKL interface to connect to the car via its OBD port and connect to the SDL line. It decodes this data, and processes it to pull out parameters like speed, RPM. It then drives an LCD display on the double-DIN stereo in the dash. A simple composite output allows the system to display live data while driving the vehicle. The UI uses the Ratatui library. The result is a display that both updates smoothly and rapidly. It has a great retro vibe that kind of reminds us of some interfaces seen in Hollywood movies. Despite being analog video, the results are pretty sharp.
We’ve seen a few great digital dashboards over the years.
Crazy news: Ratatui made it into a car dashboard 😱🎉🚗 suzui-rs — Suzuki Serial Data Line viewer in Rust📟 Displays live car data, powered by Pi and shown on stereo over RCA🦀 Written in Rust & built with @ratatui.rs ⭐ GitHub: github.com/thatdevsherr…#rustlang #ratatui #tui #car #suzuki
So you’re driving in the dark, looking at a display that is so bright that the camera has to do significant exposure time reduction to show the image. What a wonder full Idea. (But it does like the person videoing the stuff is not behind the wheel, so that’s a good thing).
The Ratatui library may be a very nice library worth looking into. Looks like a (more capable?) variant of ncurses.
I’m quite curious about making a “universal display” that can be combined with multiple backends, for example on hardware such as:
https://hackaday.com/2025/07/02/subpixel-rendering-for-impossibly-small-terminal-text/
Leaning more towards the hardware side, there are displays such as the “Nextion” frameworks, but for those (best I know) you first have to design the whole GUI on a PC. But nextion software does not run on Linux, and Wine is apparently also a bit problematic.
Hi, I’m the author of the tool.
I get the concern. The stereo is number one (from the bottom). The camera does injustice to the actual brightness since turning on parking/tail lights dims the display, so it’s not “that” bad at night.
I had swapped out the previous “better” android head unit for this cheap stereo as the brightness of android one was too much for me (maybe due to the bigger size as well). This is way better in terms of low brightness even though the quality is crap.
There has been work by people making ratatui work on embedded hardware. Linking one below in case you find it interesting.
https://github.com/j-g00da/mousefood
This highlights that cars should be able to display all that live data on one of the displays already in the car. Maybe not while driving. There are some diagnostic functions available, but not live data like throttle position or EGO voltage.
Needing a separate scan tool seems a little silly given all the hardware is already there
For what purpose? Curiosity?
Those systems connected to displays are not usually on the same bus as the power train. You’d require the car not to have any significant electrical issues for it to even function, so it would pay to have a proper tool. Would also be unwise to give it the ability to issue diagnostic commands. Playing around with the infotainment system shouldn’t give someone the ability to test airbag deployment.
a lot of the data is standardize OBD UDS, Lots of aftermarket devices that will show you data that way.
you can only read, not control anything unless you have the key code.
My 2002 Corvette’s instrument cluster has a small display that can read OBD2 trouble codes from the powertrain control module (GM’s term for what everyone else calls an engine control unit or ECU).
So I wonder when (or if) modern cars started keeping the UI and the ECU on separate networks.
Typically cars use CANbus, and all the different control units are connected to the same bus. Which means, every control unit can pull out the data it needs anyway. They have access to everything when needed, so all it would require is a bit of software to display values.
But that doesn’t mean, every device can control everything. The airbag control unit is the authority to decide, when an airbag deployment is necessary, it won’t receive that command from any other device.
I know VW stuff uses a gateway module that arbitrates communication between busses. This module provided the necessary abstraction to prevent things from going too awry in normal operation.
The infotainment bus was connected to the gateway, as was the powertrain. The infotainment would read vehicle speed from powertrain for speed sensitive volume. One example of many where data is routed over several buses.
That said the necessary communications to actually invoke diagnostic functions or change programming is usually quite complex and generally requires a lot of other prerequisite conditions that aren’t possible in a drive readiness state.
The main hiccup with getting anything to show on a factory display isn’t the lack of data on the CAN bus, it’s that the display module is built to a price point and probably doesn’t even use CAN. I did display engine parameters over the factory dot matrix display, but that display was connected by LIN and used a serial like BAP protocol. An aftermarket device was added that read the CAN bus and spat out BAP on the LIN bus. The factory display would invoke the hands free calling module, which the aftermarket device was man in the middle to. It would read CAN data, parse it and kick out display data. It read the steering wheel button presses over CAN to manipulate its own interface and also forwarded the actual hand free module functionality. Clever little thing really. Too bad the car got scooped up in dieselgate.
Given that the device only needs to speak OBD2 or CAN, this is a trivial thing and has been done for ages. Some cars even had the information available without 3rd party tools, Notably the Nissan Skyline.
Cool. But anything below 1995 has OBD 1. 1982 was the start of OBD 1.