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.
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.
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
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.
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.
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.
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.
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.
CANTrak doesn't replace scan tools, oscilloscopes, or conventional diagnostic procedures. It adds a layer of network visibility that those tools don't provide.
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.