About the Project

Built in the shop.
Designed for the shop.

CANTrak exists because the tools available to technicians don't show enough of what's actually happening on the network. This is an attempt to fix that.

The Developer

Jeremy Rich

I'm an automotive technician and software developer. I've spent years diagnosing vehicles at the component level — working through electrical faults, network communication issues, and the kind of intermittent problems that don't leave clean evidence behind.

The diagnostic tools available to technicians are powerful in some areas and completely blind in others. Scan tools read codes and stream PIDs. They don't show you the network. They don't tell you whether a command was transmitted, which modules responded, or whether the network settled into the right state after an event.

That gap is what CANTrak is built to address. Not to replace existing tools — but to add a layer of visibility that currently doesn't exist in a practical, field-usable form.

RoleAutomotive Technician & Software Developer
FocusCAN bus diagnostics, network analysis, Python
Project statusActive development
jeremy@cantrak ~ profile
$ whoami
Jeremy Rich
Automotive Technician + Software Developer
Building tools that technicians actually need.
$ cat skills.txt
CAN bus analysis & protocol behavior
Python — data capture, pattern recognition
Automotive electrical diagnostics
Network communication fault isolation
Parasitic drain diagnosis
Module dropout & U-code analysis
$ git log --oneline -1
CANTrak — active development, building in public
$
Project Origin

Where CANTrak came from

The idea started with a specific frustration: a vehicle with an intermittent parasitic drain that wouldn't reproduce on command. The standard approach — milliamp clamp, pull fuses, wait — is slow and imprecise. It tells you which circuit is drawing current, but not why, and not which module on that circuit is responsible.

CAN bus data was already available. The hardware to capture it was inexpensive. What was missing was software that could watch the network over time, identify which message groups stayed active after key-off, and point directly at the problem.

That first use case — sleep and wake analysis — became the foundation. Command verification and module dropout detection followed naturally, because they answer the same class of question: what is the network actually doing, and does it match what it should be doing?

CANTrak is built around that question. Not decoding every message. Not replacing scan tools. Just providing the network visibility that conventional diagnostics leave out.

The problem

Scan tools read codes — they don't show network behavior

Command execution can't be verified without network visibility

Parasitic drain diagnosis requires knowing which module stayed awake

Intermittent dropouts leave no trace in conventional diagnostic data

The approach

Capture live CAN traffic and analyze payload transitions

Use trigger-based windows to isolate specific events

Track message frequency and silence over time

Answer three questions: initiated, participated, resolved

Development Philosophy

Principles that guide how CANTrak is built

01

Observable behavior over decoded data

CANTrak doesn't need to know what a message means to know that it changed. Pattern recognition and payload transitions are universal — they work across platforms without manufacturer databases.

02

Precision over volume

Background CAN traffic is noise. The Spacebar Clutch and trigger-based capture exist specifically to reduce that noise and improve the quality of the data that matters.

03

Answers, not raw data

A technician doesn't need a hex dump. They need to know whether a command was transmitted, which modules responded, and whether the network reached the right state. CANTrak is built around those three questions.

04

Hardware agnostic by design

CANTrak is built on Python and standard CAN interfaces. It doesn't require proprietary hardware or manufacturer-specific adapters. If it speaks CAN, it works.

05

Built from real diagnostic work

Every feature in CANTrak exists because it solved a real problem in a real shop. Sleep analysis, command verification, dropout detection — all of them started as a specific diagnostic need.

06

A complement, not a replacement

CANTrak doesn't replace scan tools, oscilloscopes, or conventional diagnostic procedures. It adds a layer of network visibility that those tools don't provide.

Get in Touch

Follow the project or reach out directly

CANTrak is being built in the open. If you're a technician with a specific diagnostic problem, a developer interested in CAN analysis, or just curious about the project — reach out.

ProjectCANTrak — active development
DeveloperJeremy Rich
Roadmap/roadmap
Documentation/documentation