VCGU
Vehicle Computational Gut Unit
I applied the CGU idea to a real vehicle by capturing OBD-II telemetry, preserving drive sessions, inferring operating states, and comparing change within the context of how the vehicle was being used.
Overview
Modern vehicles expose substantial internal telemetry, but it is usually viewed reactively: a warning code appears, a technician requests a value, or an application displays an isolated gauge. VCGU asks a different first question: what does normal internal behavior look like for this vehicle across real operating states, and how does that behavior change over time?
The prototype began with a 2013 Kia Sorento EX V6 AWD and an OBDLink MX+ adapter. After exploring phone-based capture and encountering limitations in higher-level Python libraries, the working path stabilized around a Windows laptop, raw serial OBD commands, standardized CSV drive logs, and an offline interpreter.
That workflow captured real vehicle signals and separated thousands of rows into distinct operating states such as low idle, high idle, stopped transitions, crawl, city, and highway driving. VCGU is not a repair bot. It is an applied internal-state and context model for making vehicle telemetry more meaningful before any diagnostic claim is made.
How It Started
On April 17, 2026, I asked whether the CGU/artificial-interoception concept could be applied to my vehicle through OBD data. The longer-term idea was a car that could learn its own normal behavior and communicate meaningful drift before every problem was reduced to a generic warning light or fault code.
The first phase was deliberately narrower: connect to the vehicle, capture a useful signal set, preserve the data correctly, and determine whether the resulting logs contained stable contextual structure.
Several early directions were corrected during development. The system should not depend on labels I assign to a drive. It should infer state from telemetry. It should use a common signal layer where possible, while learning a vehicle-specific baseline after connection. It should also analyze continuous, messy sessions rather than only curated examples.
Can a vehicle’s internal telemetry be organized into stable, contextual states before the system attempts to identify meaningful deviation?
Architecture
Vehicle Signals
The primary signal set included:
- RPM
- speed
- engine load
- throttle position
- coolant temperature
- manifold absolute pressure
- mass airflow where supported
The architecture treats missing or unsupported signals as a normal part of cross-vehicle capture rather than a project failure.
Capture Layer
The successful prototype path used:
- OBDLink MX+ adapter;
- Windows laptop;
- Bluetooth serial COM connection;
- raw initialization and PID commands;
- standardized timestamped CSV logging.
The live logger remains intentionally lightweight: connect, request, decode, and write. More experimental interpretation happens after capture so the logging path remains stable.
Context Layer
The offline interpreter reads all available standardized logs and infers operating context from signal patterns and timing. It separates stopped behavior from motion, distinguishes steady from transient stopped windows, and groups motion into crawl, city, and highway states.
This creates two complementary layers:
- a vehicle-agnostic signal and feature layer;
- a vehicle-specific baseline learned from repeated sessions.
Analysis and Reporting
The reviewed interpreter run analyzed five files and classified:
- 2,253 city rows
- 690 crawl rows
- 1,742 highway rows
- 1,063 steady high-idle rows
- 1,061 steady low-idle rows
- 449 stopped-transient rows
- 334 unknown rows
The stopped-state report found two stable idle bands:
- low idle mean: 569.90 RPM, standard deviation 12.15;
- high idle mean: 601.30 RPM, standard deviation 17.53.
The distinction was visible in RPM, while the reviewed output did not show a similarly meaningful separation in load, throttle, MAP, or coolant. That is useful because it narrows the result rather than inflating it.
Development Timeline
Project origin
VCGU was defined as Vehicle Computational Gut Unit and applied to a real 2013 Kia Sorento through OBD telemetry.
Connection and capture exploration
OBDLink MX+ setup, baseline concepts, signal selection, phone capture, and Android-device ideas were explored.
Raw serial pivot
After instability in higher-level Python/OBD approaches, the implementation moved to Windows raw serial communication and direct OBD commands.
Standard logger
A standardized logger captured the core PID set into timestamped drive-session CSV files. Live readouts were confirmed.
Context corrections
The design was corrected so states would be inferred from telemetry instead of supplied labels, and so all continuous logs in the folder would be analyzed.
Interpreter results
The offline interpreter analyzed five logs, classified thousands of rows, and identified distinct low-idle, high-idle, stopped-transient, crawl, city, and highway states.
Results and Current Boundaries
Real telemetry captured
The prototype established a repeatable path from an actual vehicle to standardized local drive logs.
Operating states recovered
Offline analysis found stable contextual states that would have been obscured by a single overall average or dashboard snapshot.
Architecture clarified
Capture and interpretation were separated. The live logger remains simple and stable, while scoring, state discovery, and comparison can evolve offline.
VCGU does not currently predict mechanical failure, replace diagnostic trouble codes, provide repair instructions, or generalize one vehicle’s learned baseline to every vehicle. The prototype demonstrates capture and state interpretation; broader anomaly detection requires more sessions, controlled comparisons, and validation.
Behind the Build
VCGU is easiest to understand as two connected parts: a logger that records the vehicle and an interpreter that gives those readings context after the drive.
What I built
A Windows-based logger using an OBDLink MX+, direct serial commands, and timestamped CSV files, followed by an offline interpreter and scorer that separate stopped, crawl, city, highway, and idle behavior.
The key idea
A value is only meaningful in context. An engine speed that looks unusual while stopped may be ordinary while moving, so the system first determines what the vehicle is doing before comparing its behavior.
Selected technical detail
Separating the drive into useful states
if speed == 0:
state = "stop_transient"
elif speed <= 15:
state = "crawl"
elif speed <= 55:
state = "city"
else:
state = "highway"This is one small part of the interpreter. Stopped sections are evaluated again for stable low idle, high idle, or transient behavior instead of being treated as one generic condition.
Evidence to show on the page
These are the strongest visual proof points for a recruiter or technical reviewer. The image and video URLs can be inserted after the Squarespace asset list is finalized.
A logger or terminal view showing real OBD readings being recorded.
A chart or report showing how the drive was divided into operating states.
The OBDLink adapter and laptop connected to the test vehicle.