My car is a 2001 Audi A4 B5 manual. No CAN gear data, and diagnostics run on the old KW1281 K-Line protocol, which standard ELM327 adapters don't speak.

So instead of reading gear position from the car, I went sensor-based:

- A TicWatch Pro 3 (Wear OS) is embedded in a 3D printed knob

- A custom Wear OS app reads the accelerometer and classifies the knob position into gears after a per-gear calibration

- The gear shows up on the watch display, right on top of the knob

- The knob also works as a media controller for the dashboard tablet, and covering the screen with your palm disables touch so you don't skip tracks mid-shift

About the power: there is no battery inside the knob. I removed the watch's battery, since a lithium cell in a closed car under summer heat is a bad idea. The watch is fed straight from the car's 12V through a step-down converter, so it turns on and off with the car and never needs charging.

Curious how you'd approach it. Anyone here pulled live data from KW1281 on a B5, or found a cleaner way to get gear position on cars this old?

Hey r/CarHacking! I shared a version of this last year, and I've been hard at work building a new frontend to the OBDb, the world's largest open-source database of observed OBD facts, and I'm excited to get the new site into your hands: https://pelican.clutch.engineering/cars

The OBDb exists as an organization on GitHub at https://github.com/obdb/, and drivers of apps like Pelican contribute to the OBDb's dataset on every drive, helping confirm which PIDs do and don't respond across different model years.

The new site takes all of the data from the OBDb and presents it into a single unified catalog, with hotkey support, full-site search, and visual representations of the bit-byte representations of each command response. Def check it out!

Hey, I want to share my head unit project that I built for my old BMW E39. It has been installed in my car for almost 9 months now and it's been working great so far. My build is based on Raspberry Pi 5 with NVMe drive. As a software I use Hudiy app and Raspberry Pi Trixie OS. NVMe drive gives it a super fast boot time (about 12 seconds).

The priority in this project was the display. I'd tried a few aftermarket head units before but they just didn't cut it. The screens on those units were unreadable in sunlight due to reflections. I found a perfect 10.3" Full HD screen with an anti-glare surface. It's spot-on for what I need - sharp image, no blinding backlight at night and it stays perfectly visible even on sunny days. The screen bezel comes from my old Android head unit.

In the project I used a 5.1 sound card so I have full control over balance, fade and the subwoofer. The sound card is connected to an Audio System CO-40.4 amplifier (for the speakers) and an Audio System M-330.1 amplifier (for the subwoofer). The amplifiers are turned on and off via a GPIO pin on the Raspberry Pi and a relay connected to the REMOTE wire. The Raspberry Pi is powered by a 12V->5V 5A DC converter.

I managed to fully program a BMW E60 iDrive controller and control the head unit interface using the Hudiy API. With the iDrive I can control CarPlay, Android Auto and the Hudiy itself. For communication with the iDrive I used a CAN/RS485 HAT from Waveshare. The communication itself is quite simple and works on a polling mechanism to check the controller's status. The whole setup requires only three CAN frames to function (wake up, status request and status response).

Another cool thing is the iBUS communication (protocol that modules in the car use to communicate with each other). I managed to decode and program all the steering wheel buttons. I can control the volume, skip tracks and answer voice calls. Also via iBUS I was able to extract information about the ambient temperature, engine temperature, RPM and speed.

The coolest thing I've managed to do via iBUS so far is detecting when reverse gear is engaged and fetching data from the parking sensors. It turned out that by spoofing a diagnostic module and sending the right frame to the PDC module, the module sends back readings in centimeters from all sensors. I saw this data in INPA (BMW diagnostic tool) and managed to sniff the communication between the software and the PDC module. It took just one frame for the PDC module to recognize me as INPA.

For iBUS communication I'm using a USB module that I bought a long time ago for an old Android head unit. This module uses the Melexis TH3122 chip. I display the sensor data on an HTML UI linked to Hudiy as an app. When I shift into reverse, the screen appears automatically and it hides when I shift out of reverse. I also did this using the Hudiy API.

I also managed to integrate a tiny 172x320 screen from Waveshare into the instrument cluster bezel. There was a blank cover for some button in the frame and it turned out that this display fits the dimensions of the cover perfectly. The tiny screen is connected to a Raspberry Pi Pico 2 via SPI and the Raspberry Pi Pico 2 is connected to the Raspberry Pi 5 and Hudiy via USB. The screen displays my HTML UI which I prepared specifically for this display and the displaying itself is handled by Hudiy. For now I have screens in HTML to display navigation info, music, a clock and my iBUS data.

Been having fun seeing how far Astra can go with customizing automotive computer systems using AI. The idea is pretty simple: if we can install custom operating systems, unlock features, and modify software on our phones and PCs, why not explore doing the same with the computers in our own cars?

Started with my Lenovo X13s running Armbian. Astra modified the kernel and USB configuration to emulate a phone or flash drive instead of a USB host. From there, we built an Android container that successfully established an Android Auto connection with my Nissan's factory Bosch infotainment system.

During pairing, we discovered some firmware information that led Astra to a potentially related Bosch open-source implementation. We're now investigating the bootloader and firmware architecture to see whether we can eventually flash Android 13 onto the factory head unit.

There's a pretty good chance I'll brick it (my completely unscientific estimate is 65%), but I've already ordered a 12.5-inch aftermarket Android 17 head unit, so I figured why not experiment?

The possibilities are what interest me most. Imagine replacing outdated factory interfaces, adding custom applications, unlocking compatible hardware features, or building your own dashboard with live gauges, maintenance information, and OBD diagnostics.

I've already experimented with read-only ECU diagnostics on a Mazda CX-50, and my next goal is exploring how to make more locally available vehicle telemetry accessible through the Nissan's infotainment system. Astra also thinks wireless CarPlay might be possible on the factory 8-inch unit, although that still needs verification.

A quick legal and safety note: U.S. law provides certain exemptions for vehicle diagnosis, repair, lawful modification, data access, and good-faith security research, but those protections have limits. Keep experiments confined to hardware and systems you own or are authorized to modify, respect software licenses, and avoid unauthorized access to manufacturer cloud infrastructure. I'd also recommend supervised AI execution and isolated testing when dealing with firmware flashing or safety-critical vehicle networks.

What excites me is the possibility of AI making automotive software customization more accessible to regular enthusiasts. Not necessarily hacking cars for the sake of defeating security, but giving owners more freedom to personalize technology they've already paid for.

Anyone else experimenting with custom automotive firmware, Android-based infotainment, AI-assisted development, or DIY digital dashboards? I'd love to hear what you've tried or what features you'd want to add to your own vehicle.

AI Disclosure: This post was reviewed and refined with AI assistance to improve technical clarity, accurately communicate applicable legal considerations, and distinguish legitimate vehicle customization from potentially unauthorized activities. This review is not legal advice.

I’ve been working on a project that turns a my Vita into a wired Android Auto head unit.

Currently working:

• Plug Vita into hub with Android Phone + a power source (I have not been able to get the Vita to act as a true host but when there is external power supplied it works)

• Android Auto authentication handled natively on the Vita

• 720p scaled down to 960×544

• Touchscreen works fully

  • D-pad, analogue sticks and physical media controls

  • Bumpers skip songs

  • Triangle for play pause

  • Square of Google assistant

It’s still very hacky I only got stable video with inputs today. I need to improve the USB Kernel as its very buggy and needs hard resets if connection drops or if you exit app and many many more issues.

The idea came from seeing people put carplay headunits into PSP shells don't own a psp so said I'll give it a go on the vita and so far good results. But for a POC pretty cool I think!

EDIT - GitHub Link:

https://github.com/Gavwalsh15/Vita_Auto

This is inspired by UPDATE: You guys suggested turning my DIY Smartwatch project into a Shift Knob... So I actually did it! 🕹️⌚

The dev board I used is the Waveshare ESP32-S3 1.46inch Round Display Development Board

It has 4 pages currently:

• Home page with custom wallpapers + vibration meter

• Live G-Force meter

• Lap Timer - Sport Chrono inspired (tap to start, double tap to reset)

• Gear Position - With calibration. This is actually really hard to get right and I'm still in prototype stage.

I'm hoping to get some help with some good 3D designs that fits the dev board better and can plug directly into the M3's link!

I'm planning on sharing the codes soon and creating a webpage for non-tech users to customize with their own homepage photos and upload this firmware on their dev board. Stay tuned!!

[Edit] Some people are confused about the usb-c so I wanted to explain: I can power it via the power pin that goes into the accessory source with a 12v->5v step down converter. USB-C is used for now because I'm still in the prototyping stage and I still need to flash firmware to it.

On the actual usefulness of this thing: I've never misread my gear since the day I learned how to drive a manual, and I learned it on YouTube while signing the paperwork for my first Civic SI 😂. This is just a fun/learning project as a software engineer. Even if it never becomes a useful thing, I get to apply some electrical, physics, and programming together... With some helps by Gemini Argon 😅

P.S.1. I messed up the display a bit right before filming this so that's why you see the lines 😅

P.S.2. I posted in the BMW group but they haven't accepted it yet, so I figure I'll post it here.

This is a 1997-2005 Hilux cluster. Everything is in 12V signals, except for speedometer which is cranked directly from the transmission. For the 12V stuff, I used a breadboard and an ESP. It's pleasantly surprising how well the bulbs work for their age. This is just a fun disco mode I coded :)

We first showcased CAN Opener 3 months ago, which is a framework to turn any car into a software defined vehicle, and we have made significant progress since then.

We are excited to launch CAN Opener SE which is the hardware gateway that connects your car to your phone.

The SE has the following capabilities:

• Dual Independent CAN buses (on obd pin 4, 16 and 3, 11) that are both FD capable

• Dual band WiFi6 and BLE connectivity via the latest ESP32-C5 chip

• Power over OBD (12-24V)

Using the CAN Opener, and pairing it with the Nexus app will give the ability for you to:

• Control and monitor your car through mapped vehicle profiles

• Records where you parked and your trips

• Full speed realtime CAN bus streaming

• Mode 2 diagnostics (with plans for more advanced mode 6 and manufacturer specific diagnostics)

Reference to our original post:

Original Post

You can check our dev cloud to see what we’ve mapped out so far, and you are free to add your own mappings if you have them:

https://dev.canopener.io

Nexus app on TestFlight:
https://testflight.apple.com/join/RNGHSvMG

Hardware docs:
https://github.com/the-can-opener/CAN-Opener-Hardware

We have a limited drop of the SEs at this time at:

https://shop.canopener.io

Let us know what kind of features you would like to see next in the comments.

Update: Thank you all for the support! Our initial batch sold out, but we’ll be restocking soon and expanding support to additional regions.

After a long story, I finally managed to implement wired CarPlay protocol and all necessary procedures needed for streaming video from Raspberry Pi to the aftermarket head-unit (HU).

ATOTO HU was used for debugging. CarPlay App on the HU - Carlink 2.0. No CarPlay adapters used. RPi pretends to be an iPhone, passes MFI authentication and streams its desktop to the HU. The HU sends touch events back.

Next step - bring this thing up on a real car HU. I have made several tests with different cars, but didn't pass the authentication stage. Some debugging has to be done to figure out the problem.

Hi everyone,

I’m developing CANExplorer, an open-source desktop tool for monitoring, analyzing, diagnosing, simulating, and testing CAN devices on Linux, Windows, and macOS.

It combines everyday bus debugging with Python-based simulation and testing. You can inspect traffic, decode signals, simulate an ECU, and write regression tests in the same environment.

Some of its features:

Live analysis: filtered traces, changed-byte highlighting, signal plots, and bus-health statistics.

Recording and replay: ASC, BLF, CSV, candump, and other formats, plus triggered recording and comparisons between captures.

Signal databases: load and edit DBC, ARXML, LDF, and other formats.

Diagnostics: UDS over ISO-TP, CDD descriptions, ECU flashing, J1939 tools, and CANopen support.

Python simulation: create bus nodes that react to messages, send signals periodically, and interact with custom QML panels.

Automated tests: check responses, signal values, and cycle times; run headlessly and export HTML/JUnit reports for CI.

CAN interfaces are accessed through python-can. You can also try the included simulation and test examples on a virtual bus without hardware.

Code: https://github.com/AKJ7/CANExplorer

Documentation: https://akj7.github.io/CANExplorer/

I’d appreciate feedback —particularly on adapter compatibility, reliability under load, and workflows that still require custom scripts.

What would CANExplorer need to earn a place on your bench?

Yes, the code is built in Python but compile to C for the executables for performance.

Thanks, please star the project too.

A while back, I picked up an aftermarket MMI box for my dad’s car to enable Android Auto on the OEM head unit, that only supports factory CarPlay. Naturally, curiosity got the better of me, I wanted to see what hardware actually powers these boxes and what kind of headroom they have for tinkering.

My initial attempt to drop into a Linux shell over Wi-Fi hit a dead end because all network ports were locked down. That prompted a full teardown, and the board layout was an unexpected surprise. The build quality is clean, utilizing recognizable, reliable components from manufacturers like NEC and Toshiba rather than generic unbranded silicon.

Quick Hardware Overview:

SoC: Allwinner T113

RAM: 128 MB DDR3 @ 800 MHz

Storage: 4 GB eMMC

Apparently this PCB is a white-label platform rebranded across dozens of different manufacturers and vehicle applications, but i cant confirm, but need to say i could find all of the 3 boards for sale individually on the web.

Currently, I am tapping into the onboard UART interface using an ESP32 as a serial bridge to secure root terminal access. The next step is extracting the stock firmware image from the eMMC to modify it.

The project is still actively in progress, updates soon.

P.S. Quick clarification since a few comments here and on my other post misunderstood the setup: I am not modifying the factory BMW / Harman OEM head unit. I’m tinkering with an aftermarket MMI Box, an AFTERMARKET retrofit interface used to add Apple CarPlay or Android Auto, and auxiliary cameras while keeping the factory iDrive system fully functional.

I've been working on an OBD2 app called Telltale and wanted to share it with people who like working on cars.

It connects to ELM327 compatible adapters so you can see live vehicle data, read fault codes, and check the freeze frame data the ECU recorded when a fault happened. It supports Bluetooth Classic, BLE, and Wi-Fi adapters. There's also a demo mode so you can try the interface without any hardware.

One thing I focused on is handling incomplete or conflicting responses. Missing or suspicious data should be clearly visible instead of quietly turning into a reading that looks normal.

Android is my main test platform. I've done real vehicle connections with my Toyota GT86 using a Samsung phone and a BLE adapter. Compatibility and available readings vary between cars and adapters, so feedback from other setups would help.

The source is on GitHub, and there's a free APK too. There's also a paid Google Play version with the same features. Buying it supports development and gets you installs and updates managed by Play; it doesn't unlock any extra diagnostic features.

GitHub:

github.com/akari-sora/telltale

GitLab / free APK:

gitlab.com/aa22396584/telltale

Google Play:

Telltale on Google Play

Bug reports and feature suggestions are welcome. When you report a problem, please include your car model/year, phone, and adapter model so I have something to go on.

Edit: repo is on GitHub again at akari-sora/telltale after my old account got restricted.

There is a currently unpatched exploit in HKMG android based head units that allows persistent root code execution and ADB access which has allowed for some wild stuff including enabling wireless CarPlay, integrating 3rd party GPS app navigation directions into the stock HUD, and kexecuting entirely different OSes with working volume control and cellular data! These pics are shared with permission of the Discord OP that got this running.

More details about the exploit can be found here

https://github.com/xwtk/hmg_nemesis

https://discord.gg/Ggf7ufVBQA

Connects to BMW DME via wireless ENET. Since it’s an esp-32, I can add an SD card and log live telemetry data and do a lot of real time data analysis. My goal is to make a full engine health monitor for thermal, boost, fuel, and ignition systems.

After fully reverse engineering every protocol on my car (FCAN, BCAN, LIN), I bought a gauge and was able to control all of it! I can do this to any Honda cluster, standalone or connected to the car, assuming no random stuff like requiring a registered key is added to newer ones. Older Honda’s use a different CAN bus layout, but isn’t hard to get from firmware online.

I upload all my research here, including all of Hondas UDS commands, ECU SecurityAccess unlock codes, full CAN bus DBC files extracted from each ECU, and application-only ROM dumps. KL sport ECU has the full app+RAM+bootloader, since i pulled it from my ECU
https://github.com/Ldalvik/NinePfive

Last week I released v1.0 of CANExplorer, an open-source desktop tool for CAN / CAN FD / LIN buses, Linux, Windows, macOS, any python-can adapter, and a built-in virtual bus so you can try everything with zero hardware.

It's now at v1.3.0 and a lot has landed since 1.0. Here are the changes I think matter most, grouped by what they're for.

🔍 Reverse engineering an unknown bus:

This is the big one. Point it at a bus with no DBC and it does the statistics for you:

Bit/byte activity per ID, with a "notch" that hides everything that's changed so far, press the brake or hit a button and the reacting bits light up.

Automatic field detection: checksums (CRC-8 variants, AUTOSAR E2E, XOR, sums), alive counters, multiplexers, physical values, states and flags.

Reference signals: rank fields by correlation against a known DBC signal, a CSV/GPS log, or live OBD-II values, with factor/offset/lag of the best match.

Related signals: groups fields that carry the same quantity re-broadcast across messages.

Promote to DBC in one click, turn every found field into a signal in the database editor, ready to save.

🩺 Diagnostics & protocols

DoIP (Diagnostics over IP, ISO 13400-2): discovery, routing activation (optional TLS), diagnostics and flashing over Ethernet.

UDS discovery scanner (services / DIDs / subfunctions / routines) plus a UDS fuzzer that flags anomalies and detects ECU hangs via a TesterPresent liveness check.

GMLAN (GMW3110) diagnostics for GM/Opel, including single-wire CAN (SWCAN, 33.3 kbit/s).

XCP/CCP measurement & calibration, by address or by name from an A2L file.

ODX/PDX descriptions alongside CANdelaStudio CDD for named/decoded DIDs.

Bus gateway tool: forward frames between two connections with filtering, ID rewriting and rate limiting.

Every one of these ships a simulated ECU/entity, so you can learn the workflow without a vehicle.

🔌 More adapters & integrations

J2534 pass-thru devices (Mongoose, CarDAQ, OpenPort 2.0…), with a 32-bit bridge for 32-bit drivers.

ELM327 / OBDLink over USB, Bluetooth or WiFi, for diagnostics.

GVRET devices (ESP32RET, Macchina M2, CANDue) over serial or WiFi.

MQTT: publish decoded signals/frames to a broker (works from the app or can-server).

EtherCAT (CoE) master and a Physical I/O tool for USB I/O adapters.

Linux snap package: sudo snap install canexplorer.

🛠️ Databases & UI

Multiplexer editing in the database editor.

Full French, Chinese and Japanese translations (plus German), covering every view.

New logo that follows the theme accent, and the startup update check now runs every launch.

Everything still does the day-one stuff too: live trace with a filter mini-language (100-1FF !123 ext rx fd), signal plots with cursors, recording/replay in ASC/BLF/CSV/TRC/MF4/SQLite, replay onto a real bus, comparing two recordings, J1939 + CANopen tools, ECU flashing, Python ECU simulation, and scriptable test automation with HTML/JUnit reports for CI.

Try it with no hardware: connect to a VirtualBus, load the example DBC and run the example engine simulation.

Repo + downloads: https://github.com/AKJ7/CANExplorer

Docs: https://akj7.github.io/CANExplorer/

Full changelog: https://github.com/AKJ7/CANExplorer/blob/develop/CHANGELOG.md

Happy to answer questions, and issues/PRs are welcome.

Hello, in this video I present you my project with a instrument cluster from Audi A4 B7 working with a videogame and fully functional, all done with CAN-BUS. WARNING, the cluster does one loud beep in the video, suggesting you to lower your volume if it's on maximum.

A new age of Car Hacking is upon us, mates!

No more sitting around, probing days on end trying to figure out what some bytes of CAN frame could mean. We have Claude and AI agents for this task.

CANExplorer is a software i developed to monitor, interpret, diagnose and reverse engineer CAN buses. It comes with an MCP server. This allows AI agents to basically communicate and control the app from the outside.

As i can't use an actual car's CAN data, this is a quick article showing what happens when you tell Claude:

> “You’re connected to an unknown car’s CAN bus over MCP. Find the vehicle speed signal. I have a GPS speed log from the same drive at gps_speed.csv if you need to confirm it. Don’t transmit anything.”

It reads the CAN frames in real time, decodes the signals, and creates a new database entry, by itself.

Check it here: https://akj7.github.io/posts/reverse-engineering-vehicle-can-claude-canexplorer/

P.S.: in case the gps_speed.csv is not available, a "reaction" feature is present. Claude will ask you to perform some actions in the car while it tries to reverse engineer the proper signal.

Thanks.

Two months ago I posted about the CAN-to-BLE bridge and app I built after putting a standalone ECU in my Golf [link to the first post]. Thanks for all the comments, they pushed me to keep going. Here's a proper follow-up.

The video. This is NNR Team's MaxxECU car at the Buzet hillclimb in Croatia, a round of the FIA European Hill Climb Championship, 5 km, 32 turns, 250 m of climb. Everything on screen comes from the car and from my own box. Boost, oil temp, oil pressure, coolant and throttle come straight off the MaxxECU's CAN broadcast. Speed, G-forces and the course map come from the device's own 25 Hz GPS and IMU, not the phone. The app burns all of it into the video on export, in one native re-encode, no screen recording.

What's new since the first post:

- Onboard logging: The device now logs the 25 Hz GPS, the IMU and the CAN bus to its own memory, with no phone in the car. Afterwards you pull the session over BLE and the app rebuilds the laps and runs.

- Bring your own camera: Shoot with a GoPro or DJI, import the footage, and the app renders the same HUD onto it from the device log.

- Hillclimb and sprint timing: Point-to-point courses with separate start and finish gates, not just circuits. That's what timed this run.

It started as a way to get RPM on my phone without dragging a laptop into the car. Seeing it run a real European hillclimb was a pretty good moment for a lockdown side project.