Understanding OBD2 & CAN Bus

Before configuring the WiCAN Pro's automation engine, it is highly recommended to understand the underlying architecture of vehicle diagnostics.

What is OBD-II?

OBD-II (On-Board Diagnostics, version 2) is the standardized system mandated in all cars sold in the US after 1996 (and later in other regions). It utilizes a standard 16-pin connector (the DLC - Data Link Connector) usually found under the driver's side dashboard.

  • Always-On Power: Pin 16 provides direct 12V battery power, and pins 4/5 provide ground. This is why the WiCAN Pro stays powered even when the car is off, making the Power Saving settings in the web UI crucial.
  • The Network: While older cars used various serial protocols (like K-Line), almost all modern cars (2008+) communicate OBD-II data over the CAN bus (Controller Area Network) standard.

Read more: Wikipedia: On-board diagnostics (OBD-II)

How Data is Requested: Modes and PIDs

The WiCAN Pro acts as a diagnostic client. When it wants information, it sends a request using specific Modes (also called Services) and PIDs (Parameter IDs).

  1. Standard PIDs (Mode 01): These are universally mandated by law. If you request Mode 01, PID 0C, every modern car will reply with its Engine RPM. The formulas to decode these are standardized and public.
    Read more: Wikipedia: OBD-II PIDs (Standard List)
  2. Custom/Extended PIDs (Mode 22 or 21): Manufacturers have thousands of private sensors that aren't legally mandated (e.g., individual EV battery cell voltages, transmission fluid temps, or tire pressures). To get these, you must use manufacturer-specific requests (usually Mode 22). The WiCAN Pro allows you to define these custom PIDs, but you must know the specific hex request and decoding formula for your exact car.

The Raw CAN Bus (The "Listener" Method)

Instead of asking the car for data using OBD-II requests (which is slow), the WiCAN Pro can tap directly into the vehicle's raw CAN bus.

  • How it works: Modules in your car (Engine, ABS, Body Control) are constantly broadcasting their status to each other hundreds of times a second.
  • The Advantage: The WiCAN can simply "listen" to this existing chatter. It provides ultra-fast, real-time data without adding any request traffic to the network.
  • The Challenge: CAN frames are raw hexadecimal data (e.g., ID: 0x1A6, Data: 00 1F C4 00...) and are highly proprietary. You need a "Vehicle Profile" or reverse-engineering tools (like SavvyCAN) to translate them.

The ELM327 Layer

Many third-party smartphone apps (like Car Scanner or Torque Pro) expect to talk to an ELM327 chip. The ELM327 uses standard AT commands to translate serial text into CAN bus signals.

The WiCAN Pro has a built-in software emulator that perfectly replicates an ELM327 over Wi-Fi or Bluetooth, allowing full compatibility with these legacy apps while operating much faster than a standard Bluetooth dongle.

Read more: Wikipedia: ELM327

Why the WiCAN Pro is Different

Most OBD-II dongles are "dumb" bridges—they require a smartphone to be connected to ask the car for data and do the math.

The WiCAN Pro is an Edge Gateway. It stores the PIDs, polls the car autonomously on its own timer, processes the complex math (hex-to-decimal conversion) locally on its ESP32-S3 chip, and pushes the final human-readable data (like Speed: 65mph) directly to a server or Home Assistant.

Table of Contents