How EV Charging Talks

People lump "EV charging protocols" together, but they live on completely different wires. Only one of the three, CHAdeMO, puts decodable traffic on a CAN bus. Here's why a CAN adapter sees CHAdeMO and nothing else.

SAE J1772, Analog Pilot Signaling not CAN

J1772 (the "J-plug") is the North-American AC connector. The charging conversation runs over two analog wires, not digital messaging:

• Control Pilot (CP): a 1 kHz square wave from the charger (EVSE). Its duty cycle encodes the available current, and the car pulls the CP voltage down through a diode and resistor to announce its state.
• Proximity Pilot (PP): a resistor ladder that tells the car a plug is seated and, on portable cords, the cable's current rating.

Control Pilot: duty cycle to amps

For most of the range the rule is linear: available A = duty% × 0.6. Above 85% a second, steeper linear rule takes over, and past 96% it stops encoding a number at all.

Duty cycle	Meaning
10% – 85%	Available current = duty × 0.6 A (e.g. 50% → 30 A)
85% – 96%	Available current = (duty − 64) × 2.5 A (e.g. 90% → 65 A)
96% – 97%	80 A
5%	Digital communication required (ISO 15118 / DIN handshake)
< 3% or > 97% (incl. steady +12 V)	No charging allowed / not ready

Pilot States

Why a CAN tap sees nothing: the entire J1772 handshake is voltage levels and a PWM duty cycle on two analog pins. There are no CAN frames. You'd need an oscilloscope on CP/PP, not a CAN adapter.

ISO 15118, "V2G" Smart Charging not CAN

ISO 15118 is the digital layer behind Plug & Charge (the car authenticates and bills automatically) and high-power DC under CCS. It reuses J1772's CP wire, but instead of a simple PWM it runs a full networking stack through that wire:

• SLAC: Signal-Level Attenuation Characterization pairs the car to the right charger over the CP line.
• HomePlug Green PHY (PLC): power-line communication modulates a high-frequency carrier onto CP. This is the physical layer, not CAN.
• IPv6 / TCP / TLS: a real IP stack rides the PLC link.
• EXI-encoded XML: the application messages (SessionSetup, ServiceDiscovery, charge loop, certificates) are XML, binary-packed with EXI.

Why a CAN tap sees nothing: ISO 15118 is Ethernet- over-powerline with IPv6 and TLS on top. It never touches the vehicle CAN bus, so a CAN adapter can't decode it. Sniffing it needs a Green PHY / HomePlug interface.

CHAdeMO, DC Fast Charging on CAN

CHAdeMO is the one that puts real, decodable traffic on a CAN bus. The DC charge connector carries its own dedicated CAN at 500 kbit/s, separate from the vehicle's main bus, using fixed 11-bit IDs. The car and charger negotiate limits, then trade dynamic status every ~100 ms while current flows.

Message Set

ID	Dir	Message	Key fields
0x100	V→C	Capability	max battery voltage, charged-rate reference
0x101	V→C	Charging time	max / estimated time, battery capacity
0x102	V→C	Session (dynamic)	proto#, target V, requested A, faults, status, SoC
0x108	C→V	Available output	available V / A, threshold V
0x109	C→V	Status (dynamic)	proto#, present V / A, status, remaining time
0x118, 0x200–0x209	both	Discharge / V2X (v2.0)	bidirectional, name + raw only here

The Exchange

Fault & Status Bitfields

The dynamic messages each carry a status byte the tab renders as labeled chips:

• 0x102 byte 4, vehicle faults: battery over/under-voltage, current deviation, over-temperature, voltage deviation.
• 0x102 byte 5, vehicle status: charging-enabled, shift position, vehicle fault, contactor open, normal-stop request.
• 0x109 byte 5, charger status: charging, charger malfunction, connector locked, battery incompatible, charging-system malfunction, stop control.

Revision drift: CHAdeMO 0.9 / 1.0 / 2.0 shuffle a few bytes. The CHAdeMO tab decodes the stable fields, always surfaces the protocol-number byte so you know which revision you're watching, and shows the rest raw. Tap the charge connector's dedicated bus (500k), not the vehicle's main bus, or start Demo mode and open the CHAdeMO tab to replay a looping handshake + charging ramp with no hardware.