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.

Hey folks,

​I’ve seen a few retrofitters and accounts advertising standalone Android Auto running natively on NBT Evo (iDrive 5/6) without requiring external MMI boxes or display swaps.

​Does anyone know the details of how they achieved this? Did they gain root/shell access to the head unit to run custom binaries, or is it an adaptation of an open-source client?

​I’d love to explore developing custom tools or tweaking the OS on my own ID6 unit, so if anyone has documentation, development workflows, or details on how people gain root access to tinker with NBT Evo, please share!

Hi all,

I’m trying to fit H7 LEDs in the static cornering lights and need help with the SAM coding.

Car / setup

• Mercedes W204 C-Class, 2013 (facelift), M274 1.6 petrol
• Bi-xenon headlights with separate H7 static cornering bulbs
• Front SAM: SAMF_172 (UDS_CAN_D) / SAMF_172_MOPF_212
• Tool: DTS Monaco

Problem
With H7 LEDs in the cornering position, the SAM logs a bulb-out / open-load error. I want to disable the fault detection for that output, or lower its threshold, so I don’t need load resistors.

I found headlight setup and openload parameter for standard H7 headlight, where threshold can be lowered or error disabled. But I can not find anything for H7 cornering lights for cars with bixenon like mine

Questions

1. On SAMF_172 / MOPF_212, which domain and fragment holds the fault enable (open-load detection) for the left/right cornering light outputs?
2. If no such coding exists for this output, can the open-load threshold or cold-check be changed some other way, e.g. a hidden domain or a raw byte in the coding string?
3. Has anyone done this successfully without load resistors?

I uploaded images which show all sections for SAMF

Hi all,

We just released a new CANsub firmware (02.05.01) that adds a 'dashboard view' to webCAN, our free browser-based GUI that runs on the CANsub.

This lets you build powerful custom dashboards for real-time visualization - with zero installation or backend required (everything runs in the browser).

You can read more about this in the CANsub Intro - if you get a few min to check it out I'd be very interested in any thoughts/ideas/feedback, e.g. what you think would be useful for your use cases.

As with the CANsub in general, we make it easy to create new dashboards via AI agents (if you want). I e.g. used this in my AI CAN sniffer article to create a quick Hyundai i10 dashboard to show the OBD2 vs. proprietary CAN signals, you can find a clip of the dashboard in the showcase 1 example.

Happy to hear your inputs!

Martin, co-owner at CSS Electronics

Hello everyone so im just going to start to learn about ecu repair and I looking to meet people that already know and are willing to share with me some knowledge.

Getting into CAN with my 2013 Civic 1.8L. I can log traffic, but figuring out what I'm looking at is the hard part. Thought I'd try turning the cooling fan on with a scan tool while logging with a separate CAN interface, so I'd have something specific to look for.

Budget is around $400. Looking at the topdon AD800BT2, but still checking if it can run that test on my car. Seems easier to start with a knwon command than poke around blindly.

Anyone tried this? Anything to watch out for when picking a scanner for it?

Trying to load a custom file to my car but the CVN and Wrapper checksum are vastly different from anything in the history of carhacking.

Anyone have tips or experience?

Hi everyone!

I have a 2020 Opel Grandland X with the IntelliLink Navi 5.0 infotainment system, running firmware version 21.08.90.52_NAC-r0.

I'm interested in reverse-engineering the system to understand how it works internally and explore the possibility of modifying its software or redesigning its UI to make it look and feel more like a modern Android-based infotainment system, with a more futuristic design, animations, and customizable features.

Has anyone here actually managed to reverse-engineer this system or a similar PSA/Stellantis NAC infotainment unit? Have you successfully modified the firmware, gained access to the underlying OS, or developed custom software that runs on the original hardware?

I'd appreciate any information, GitHub repositories, technical documentation, or experiences from people who have attempted this.

I'm particularly interested in real, working solutions rather than just theoretical discussions.

Thanks!

I’m the developer of G86 Racing, from CrowFoundry. This is the hardware/data path behind G86 Car Computer: a service that collects supported GPS, ECU/CAN and sensor inputs near the car and connects them to the phone recorder and optional live pit wall.

The connection path

GPS / ECU / CAN / supported sensors

↓

Car Computer: native bridges + local MQTT broker + engineering logs

↓ local network

G86 phone: session timing, onboard video and optional live sharing

↓ internet, when sharing is enabled

Browser pit wall: received channels, timestamps and channel age

Hardware and interfaces

An example Linux setup is a Raspberry Pi with a 64-bit OS, a supported USB/serial NMEA GPS receiver and either a supported serial ECU connection or CAN interface. The computer runs the hardware bridges and an authenticated Mosquitto broker. The phone joins the reachable local network and pairs using a short-lived QR code.

Linux supports SocketCAN and supported local I²C sensors. The supported macOS and Windows builds use their available serial/network and compatible gateway paths; they do not gain Linux-only interfaces just by running the same app. Supported wireless routes include an ESP CAN module over BLE or local MQTT. A supported CAN/ELM Bluetooth adapter can also connect directly to the phone without Car Computer.

The wizard scans for devices, then you review the configuration and select one primary engine source. Finding a port, saving an adapter or pairing Bluetooth is not the same as receiving measurements. The live checks separately show broker connectivity, fresh channels and GPS fix.

Channels and actual rates

Depending on the ECU/profile and sensors, channels can include RPM, throttle, coolant temperature, oil pressure, vehicle speed and motion measurements. A generic OBD adapter provides the PIDs the car actually exposes, at the rate the adapter and vehicle permit. Changing from wired to Bluetooth or MQTT does not unlock channels hidden by a vehicle gateway.

For recognised supported u-blox, MediaTek and compatible Quectel receivers, automatic GPS setup requests 10 Hz in RAM. The dashboard distinguishes the requested rate from the measured output rate; unknown receivers and network feeds keep their settings. There is no single guaranteed sampling rate for every ECU/CAN channel.

Missing and stale values

The displays expose source information, timestamps and channel age. Unavailable measurements stay unavailable rather than being filled with invented engine values. Check the stream on the computer, then the phone, then the pit wall. A pit-wall recording only contains the packets that display actually received.

Logging and offline operation

The computer keeps independent local engineering recordings, with gzip NDJSON or ZIP exports and metadata describing sources and known gaps. The phone remains responsible for app runs, lap timing and onboard video. The open pit helper can also record the stream it observes and export CSV/NDJSON.

Managed acquisition requires an active Pro or Team subscription. First activation needs internet; after activation, a verified offline grant can allow local telemetry for up to 72 hours, capped by subscription expiry. Remote pit-wall delivery still needs internet. Basic phone GPS timing and local history are free.

US App Store subscription prices: Pro $14.99/month or $149.99/year; Team $49.99/month or $499.99/year, auto-renewing. Current prices vary by platform/region and are shown before purchase. Team ownership is optional; Pro supports a personal pit wall and team participation, while additional teammates need their own Pro subscriptions.

Installation, interfaces and troubleshooting: https://g86racing.com/car-computer/

Phone app and setup guides: https://g86racing.com/

Interactive pit-wall demo with generated telemetry: https://app.g86racing.com/?demo=1

Hello there

Based on recent publications, a lot of peoples are going at it with various ESP32 1.75 inch screen, i started mine around 2 years ago with TFT screen and some ESP32 WROOM. I went to the 1.75 inch screen route and since i've been trying to develop this.

I'm aware of this already existing same kind of project that, i swear lmao, learned existence only today (https://github.com/Mr-Mika/M-Gauge/**)**

What i tried to do differently based on the other projets it the ability to wire physical sensors as well for older cars where the CANBUS / OBD data doesn't contains as much informations as recent vehicules.

On my case, it's my AP1 S2000 which doesn't provide oil pressure / temperature from the ECU.

So, i started working on a breadboard, doing at the beginning hand made code (now almost fully assisted with GPT) to create something that could be incorporated on any vehicule, and also provide the ability to wire sensors directly to the board

I went also a different to try and create my own custom PCB (still tweaking the board at the moment) to be able to have something the most "out of the box" possible :

• 8 screens fully customizable
• 4 values per screen
• Unit, Threshold and Threshold color per value customizable
• 2 Physical Sensor input
• OBD2 Bluetooth BLE Dongle support (i'm going to add CANBUS capabilities also) (both will be supported / compatible)
• OBD Values discover and assigned to specific values that can be renamed and customized as well
• Smartphone application to manager each parameters per ESP Unit
• Gauges data exportable with history data (only physical sensor for now but easily addable for each values)

I'm adding also some picture and videos of what i've done so far

The code is sitting on gitlab for now, i also wanna go opensource but i want to know if people would be interested

Side not, i'm clearly not confortable with PCB conception, i've went the AI route with my own breadbord conception as a baseline, i think there's clearly more to refined / polish on this side

For physical sensors, i also want to add more conversion table for different brand and type of sensors, right now i'm only using it for oil pressure, but the idea is to support more sensors

What's your thoughs ? I'm aware there's lot of similar projets going around and i found out about them really recently

I could not find published CAN information for the Alfa Romeo Giulietta 940, so I worked from captures on my own 2011 car, starting from fmntf's fiatcan work on the Fiat Doblò and karolkrupa's alfa-blue-me for the 159. A Raspberry Pi Zero W now takes the place of the dead Blue&Me module, node 4021.

What the captures settled:

• B-CAN at 50 kbit/s, 29-bit identifiers, ID = topic<<16 | node. Body Computer 4000, cluster 4003, radio 4005.
• **PROXI:** about a second after the bus wakes, the Body Computer sends `1E114000#`. On my car, nodes `400A`, `4003` and `401A` answered within milliseconds with the same six-byte value. A silent node gets three retries; a mismatch makes the odometer blink. The Pi uses the value read from that car. The public code reads it from a setting that is covered by tests but has not yet been run in the car.
• The Body Computer's PROXI record `2023` had to list the telematic unit as present. I read and saved the original record before changing it with the documented script and keeping an undo file, then ran the alignment with the Pi answering diagnostics as the telematic ECU. This changes the car's configuration and is not a generic value to copy.
• **Source handshake:** MEDIA makes the radio send 06314005#0C…; the node has about 100 ms to answer …84 on 06314021. Unprompted answers are ignored.
• **Wheel buttons:** frame 06354000 from the Body Computer, one bit per button, same layout fiatcan documents for the Doblò.
• **Track text:** the Doblò's format and 6-bit character set work on the Giulietta's radio.
• The body-B-CAN pair on OBD pins 1 and 9 carried body traffic but no `18DA…` diagnostic frames during a PROXI alignment on my car. It is usable for body traffic; I used the module connector for the complete Blue&Me captures.

One rule in the software: it transmits only frames first recorded on this car, each tied to a capture file and timestamp. A fresh install is listen-only.

Write-up with the frame tables, timing and wiring:

https://duzgun.org/blog/giulietta-blue-me/

Corrections welcome, especially from anyone with another 940

When you want to record what a car is doing over time, there are two common starting points. One is to listen passively to the CAN bus and record every frame. The other is to actively poll the ECU with diagnostic requests, usually the standardized OBD-II PIDs or a manufacturer's UDS reads. Both get you data, but they fail in different ways.

Passive sniffing is read-only in principle, so it does not ask any module for anything. You see the real traffic at the real rate, with accurate timestamps, and you can catch short events that a polling loop would miss. The downside is that raw frames mean nothing until you decode them. Without a database file or a lot of reverse engineering, you are staring at hex and guessing which bytes are RPM, throttle position, or a fault flag. Decoding also depends on the bus speed, the gateway's filtering, and whether the manufacturer even sends the signal you want on the bus you can reach.

Polling is the opposite trade. The standard PIDs are documented, so the answers are easy to interpret, and most cars respond to them without any special setup. The costs are speed and coverage. Each request and response takes time, so your sample rate is limited and you get a snapshot rather than a continuous signal. The standard only defines a small set of parameters, so anything manufacturer specific needs UDS reads, which require knowing the addresses and data identifiers, and those vary a lot between makers and even between model years. Active requests also add load to the diagnostic channel and can interfere with other tools or sessions if you are not careful about who else is talking.

A common middle ground is to use passive capture to understand timing and relationships, then use polling or UDS to label the values with known names. Whether that combination is practical depends heavily on the vehicle, so I would not assume results from one platform carry over to another.

For people who have done both: which problems did you hit first, decoding the passive data or getting reliable answers from polling? I am curious whether the gateway filtering was the bigger blocker or the lack of documentation.

I recently completed an Embedded Systems course and am currently looking for a job. In parallel, I’m starting a hobby project called FELIX RACING — a motorsport-style digital instrument cluster built around automotive CAN communication.

Hardware:

• STM32 NUCLEO-H723ZG with native FDCAN
• MCP2515 + TJA1050 CAN module
• Arduino and ESP32 for a second ECU/simulator node
• Planning to use a 3.5-inch TFT display

Project scope:

I want to build a working dashboard that receives simulated vehicle data over CAN, displays parameters such as RPM, speed and engine temperature, and includes an engineering screen for monitoring communication health.

The main technical feature will be CAN communication integrity testing:

• Message timeout and stale-data detection
• Message counters and basic data validation
• Injecting missing or invalid messages to test fault handling
• Logging faults and verifying recovery when communication resumes

This will initially be a bench setup with simulated data, not connected to a live vehicle.

I’d appreciate specific advice on three things:

1. Hardware architecture: Is STM32 native FDCAN for the dashboard and an Arduino + MCP2515 for the simulated ECU a sensible setup? Are there any electrical compatibility issues I should address first?
2. CAN fault handling: For a small portfolio project, which failure scenarios should I implement to demonstrate meaningful automotive-style diagnostics beyond a basic message timeout?
3. Engineering quality: What would you expect to see in a project like this to distinguish it from a typical DIY dashboard — for example, testing methods, logging, protocol design, or documentation?

I’m looking for practical feedback from people with hands-on CAN and automotive embedded experience, especially on design mistakes worth avoiding before I start wiring everything up.

Hi all! I'm looking for testers for OBDash, my first app. It turns an Android phone, tablet or head unit into a live car dashboard.

You don't need a car or an OBD adapter to help. The app has a demo mode with simulated data, so you can install it and try every skin from your couch.

How to join:

1. Join the tester group: https://groups.google.com/g/obdash-testers

2. The app is in Google's review right now. As soon as it's approved, I'll email the group the Play Store opt-in link.

3. Install it and keep it installed for 14 days.

It's free for testers. Drop a comment with your own app's tester link and I'll join yours too.

Thanks!

Hi. Does anyone have account on mhhauto forum and could help me to contact few users from there? I would send you links to users and a message (containing my phone number) that I would love you to send them. Its about scam company that I wanted to sue and I saw there are more victims and those people lost money on this company too. Anyone willing to help? Thank you.

I'm investigating whether it's possible to permanently disable all wireless communications on a 2026 Toyota Corolla Hybrid (Australian model) without affecting essential vehicle functionality.

I haven't purchased a new vehicle in approximately 18 years, and I'm genuinely surprised by how much the automotive industry has changed regarding connectivity, telemetry, and data collection.

I work in IT and cybersecurity, and I'm concerned about the privacy and security implications of modern connected vehicles, particularly persistent 4G connectivity, location tracking, and remote access capabilities.

With rapid advances in AI, large-scale data collection and increasingly sophisticated analysis techniques, these concerns are becoming even more significant to me.

My goal is to physically prevent the vehicle from transmitting data or communicating with external networks. Software opt-outs and privacy settings are not sufficient.

I'm willing to sacrifice connected services, SOS functionality, and OTA updates, provided essential vehicle functions remain unaffected.

Questions for Toyota technicians, automotive electronics engineers, or anyone with relevant experience:

1. Can the DCM/4G modem be physically disconnected or removed without affecting essential vehicle systems?
2. Are there other independent wireless modules capable of transmitting telemetry or location data?
3. Would removing the DCM fuse be sufficient, or is complete hardware disconnection necessary?
4. Could these modifications affect internal systems, infotainment, diagnostics, driver-assistance features, or normal vehicle operation?
5. Warranty: Could these modifications affect the warranty on a brand-new Toyota, particularly under Australian Consumer Law?
6. Is there a reversible, non-destructive hardware solution that minimises potential warranty issues?
7. How can I independently verify that no wireless telemetry is being transmitted?
8. Has anyone successfully done this on a recent Toyota, particularly a 2025–2026 Australian Corolla Hybrid?

I'm specifically interested in hardware-level solutions, technical documentation, and firsthand experiences, rather than software privacy controls.

I'm not looking to debate whether these concerns are justified. I'd simply like to understand what's technically possible and what the consequences might be.

Any technical insights would be greatly appreciated.

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.

Hi!

Ready to buy instrument cluster firmware/dump file for Lexus TX350 for US market only!

Please send a message if you have one.

Thanks!

PullScan is more than just a CSV datalog analysis tool. Here’s what it offers today:

• Datalog Analysis: Analyze complex automotive datalogs and understand what’s happening with your vehicle in plain English.
• Screenshot Analysis: Upload screenshots of datalog graphs and convert them into interactive graphs for further analysis.
• Fix Me: Uses machine learning trained on real-world automotive troubleshooting cases to provide guidance on how to address issues identified during analysis. Currently available for JB4 platforms only.
• Live OBD2 Monitoring: Connect an OBD2 device to monitor your vehicle’s live telemetry while driving.
• Performance Measurement: Measure 0–60 mph, quarter-mile times, and use Street Dyno to estimate vehicle performance. These features are still in beta and currently free to use. I’ll be sharing a video soon demonstrating how they work!

I’m continuously improving PullScan and working on new features. There’s more to come!

PullScan is available on iOS and Android.

iOS:
https://apps.apple.com/us/app/pullscan-automotive-analyzer/id6799187256

Android:
https://play.google.com/store/apps/details?id=com.pullscan.android

Website:
https://www.pullscan.com