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 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!

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.

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

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?

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

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?