Over the last several months, I have been working on Dr. PD, an open-source USB Power Delivery analyzer and programmable sink. Diving deep into the world of USB-PD and USB-C has given me a unique appreciation for these rich technologies, and I want to share some of the things I have learned.

Most USB-PD transactions are fairly pithy affairs. When you plug your computer, phone, or tablet into a compatible power supply, the latter tells the device which power profiles it supports, the device requests one of the available profiles, and the PSU provides it.

For example, here’s my 5th-generation iPad connecting to one of the many USB-C power bricks I’ve collected over the years:

Source Capabilities	Source	Sink	The source is reporting the following capabilities: Supports EPR mode. Supports dual-role data. Reports unconstrained power. Fixed power profiles: 5V @ 5A 9V @ 5A 12V @ 5A 15V @ 5A 20V @ 5A Programmable power profiles: 5V-21V @ 5A PPS (power limited)
Request	Sink	Source	Power request: Selected source object position: 4 Operating current: 5A Maximum operating current: 5A Asserted request flags: USB communications capable while using this contract. Requests no USB suspend while using this contract.
Accept	Source	Sink
PS RDY	Source	Sink

(Note: in order to make the USB-PD transactions in this post readable, I will be omitting GoodCRC messages, which are used to confirm reception of transmissions.)

As you can see, there isn’t much going on. The connection takes place over an unmarked USB-C cable, so the power brick begins the conversation by sending a Source_Capabilities message that lists the power profiles it supports. The iPad responds by sending a Request message for 15 V @ 3 A (the fourth power profile in the list), the power brick accepts the request, and finally the power rail is brought online, at which point the power brick issues a PS_RDY message to let the iPad know that it can start drawing power.

Nothing to it—four messages (and four acknowledgments) are all that’s needed to establish a power contract that will continue working until either the source or the sink decides to renegotiate it, or until the user disconnects the cable at either end. Things may get a little more complicated if the device decides to use a Programmable Power Supply (PPS) profile or an Extended Power Range (EPR) profile, both of which require periodic messaging to maintain or adjust the contract. In most cases where the devices can only take a fixed role, however, there won’t be much more on the wire than what you see above.

(Eagle-eyed reader may have noticed that the source is offering 5A of current even though there was no interrogation of the cable, which normally limits current to 3A; in this particular case, the cable is captive (that is, attached directly to the power supply), so we can assume that it knows what current it is capable of carrying.)

From telegram to novel

Things change, however, when both devices at the ends of the cable are capable of both charging and being charged.

These are called Dual-Role Ports (DRPs) in the protocol literature, and they can dynamically decide whether to act as a source or a sink, swapping roles as needed in response to operating conditions.

For example, if you connect a mobile phone to a laptop that is connected to mains power, the laptop may decide to act as a source, since it has access to unconstrained power. If you later disconnect it from mains, it may renegotiate the USB-PD contract with the phone to a lower power level in order to conserve battery charge. If that charge drops low enough, the roles may eventually swap, with the phone ending up charging the laptop.

As you can imagine, this is not the kind of relationship that can be established in four messages. To illustrate, let me guide you through what happens when I connect my iPad to my M1 MacBook Pro: the conversation is so long (nearly 100 messages) that I’ve had to break it into multiple pages.

Phase 1: Hello, world!

The exchange between the two devices starts with an unassuming, basic negotiation. The MBP takes on the role of source, and the iPad becomes a sink. This happens entirely through analog signaling: both devices alternate between pulling the CC lines up and down until they detect each other. Then, the MBP holds its line high to signal the iPad to assume the sink role.

At this point, the MBP proceeds to provide the iPad with basic power:

Vendor Defined	Source	Cable	Structured Vendor Defined Message: DISCOVER_IDENTITY REQ Requests identity information from the partner, including product type, USB VID/PID, certification ID, and product-type VDOs. Standard or Vendor ID: 0xFF00 Structured Vendor Defined Message version: 1.0
Vendor Defined	Cable	Source	Structured Vendor Defined Message: DISCOVER_IDENTITY ACK Returns identity information such as product type, USB VID/PID, certification ID, and product-type VDOs. Standard or Vendor ID: 0xFF00 Structured Vendor Defined Message version: 1.1 Discover Identity data: USB Vendor ID: 0x0000 Certification identifier: 0x00000000 USB Product ID: 0x0000 Device release number: 0x0000 Passive Cable Vendor Data Object: Plug type: USB Type-C Extended Power Range capable: yes Maximum bus voltage: 50V Current capability: 5A Latency: 10 ns to 20 ns (~2 m) Termination: VCONN not required Highest USB speed: USB 2.0 only
Source Capabilities	Source	Sink	The source is reporting the following capabilities: Supports unchunked extended messages. Supports dual-role power. Supports dual-role data. Supports USB communications. Fixed power profiles: 5V @ 3A
Request	Sink	Source	Power request: Selected source object position: 1 Operating current: 3A Maximum operating current: 3A Asserted request flags: Capability mismatch: the sink says the selected source capability cannot fully satisfy it. USB communications capable while using this contract. Requests no USB suspend while using this contract. Supports unchunked extended messages.
Accept	Source	Sink
PS RDY	Source	Sink

There are a couple of important things to notice here.

First, remember that neither device knows that it is specifically communicating with the other—at this point, as far as the iPad is concerned, the Mac could just be a simple power brick, and the Mac has no reason to believe that there is anything special about the iPad, other than that it wants power.

Second, and most important, in the Request message, the iPad indicates that the power profile offered by the Mac is not what it wants by setting the Capability Mismatch flag, and this leads to the next stage of the conversation.

Phase 2: You never give me your money

Since the iPad is essentially complaining that the power contract offered by the Mac isn’t what it wants, the next thing that happens is that the Mac asks what kind of power profiles it supports:

Get Sink Cap	Sink	Source
Sink Capabilities	Source	Sink	The sink is reporting the following capabilities: Supports dual-role power. Supports dual-role data. Supports USB communications. Fixed power profiles: 5V @ 3A Variable power profiles: 4.75V-21V @ 4.7A

The Get_Sink_Cap request causes the iPad to return a Sink_Capabilities response, which contains both a 5 V @ 3 A profile and a variable profile that accepts anything from 4.75 V to 21 V at up to 4.7 A.

This is a little misleading—the iPad doesn’t actually want to use a variable power profile (called a Programmable Power Supply, or PPS, in USB-PD lingo). In reality, it is simply stating that it can use any fixed power profile between those two voltages. (As it happens, the iPad’s preferred power profile is 15 V @ 3 A.)

Why does the device also specify a 5 V @ 3 A fixed profile? Because that is the default profile provided by the source. This ensures that, in the worst-case scenario where a source isn’t sophisticated enough to handle variable requests, the iPad will at least be able to draw basic power… which, somewhat amusingly, is exactly what happens next:

Source Capabilities	Source	Sink	The source is reporting the following capabilities: Supports unchunked extended messages. Supports dual-role power. Supports dual-role data. Supports USB communications. Fixed power profiles: 5V @ 3A
Request	Sink	Source	Power request: Selected source object position: 1 Operating current: 3A Maximum operating current: 3A Asserted request flags: Capability mismatch: the sink says the selected source capability cannot fully satisfy it. USB communications capable while using this contract. Requests no USB suspend while using this contract. Supports unchunked extended messages.
Accept	Source	Sink
PS RDY	Source	Sink

As you can see, the Mac is having none of it: the offer is 5 V @ 3 A or nothing, which the iPad accepts, even though it still sets the Capability Mismatch flag—which, in a sense, is the USB-PD equivalent of “I accept this under protest.”

Next, the iPad queries what other capabilities the Mac can offer, and the Mac does the same:

Get Source Cap Extended	Source	Sink
Source Capabilities Extended	Sink	Source	Source capabilities extended information: USB Vendor ID: 0x05AC Product ID: 0x7109 XID value: 0x00000000 Firmware version: 0 Hardware version: 0 Voltage regulation: 150 mA/µs load step; 25% IoC load step magnitude Holdup time: 0 ms Compliance: No asserted compliance flags Touch current: No asserted touch-current flags Peak current 1: 0% overload for 0 ms at 0% duty cycle; VBUS voltage droop not allowed Peak current 2: 0% overload for 0 ms at 0% duty cycle; VBUS voltage droop not allowed Peak current 3: 0% overload for 0 ms at 0% duty cycle; VBUS voltage droop not allowed Touch temperature: IEC 60950-1 Source inputs: external supply present, external supply unconstrained, internal battery present Fixed batteries: 1 Hot-swappable battery slots: 0 Standard Power Range source power data profile rating: 7W Could not decode all source capability data: Legacy 24-byte Source Capabilities Extended Data Block: missing EPR Source PDP Rating byte required by USB PD 3.2.
Get Sink Cap Extended	Source	Sink
Sink Capabilities Extended	Sink	Source	Sink capabilities extended information: USB Vendor ID: 0x05AC Product ID: 0x7109 XID value: 0x00000000 Firmware version: 0 Hardware version: 0 Sink capabilities extended data block version: Version 1.0 Load step: 150 mA/µs load step Sink load characteristics: 0% overload for 0 ms at 0% duty cycle; VBUS voltage droop not tolerated Compliance: No asserted compliance requirements Touch temperature: Not applicable Fixed batteries: 1 Hot-swappable battery slots: 0 Sink modes: VBUS powered, battery powered Standard Power Range sink power data profile: minimum 5W, operational 18W, maximum 45W Extended Power Range sink power data profile: unavailable (legacy 21-byte SKEDB) Could not decode all sink capability data: Legacy 21-byte Sink Capabilities Extended Data Block: missing EPR Sink PDP bytes required by USB PD 3.2.

There’s a lot of information being exchanged here, but a few items stand out.

First, both devices are sending what would today be considered incomplete messages, since they are one byte short of the length prescribed in the spec (24 bytes instead of 25 for the Mac, and 21 instead of 22 for the iPad). This occurs because the final byte is used to indicate the supported power in Extended Power Range (EPR), which allows contracts up to 48 V and 5 A, and whose introduction into the standard came well after both this Mac and iPad were manufactured. As a result, these message conform to an older version of the standard (3.0), which used fewer bytes.

More interestingly, the Mac claims that it can only provide 7 W of power, which directly contradicts the power contract it is offering (5 V @ 3 A provides 15 W). The cause of this discrepancy is unclear, but the contracts advertised in the Source_Capabilities message are the only ones that are normative, and therefore they take precedence over any information reported here.

I suspect, however, that there are two primary reasons these messages are being exchanged: they allow the devices to understand how power is being sourced (here, the Mac reports that it is externally powered, while the iPad indicates that it is battery-powered and also drawing power via USB-C), and they help them identify the type of device connected at the other end of the cable.

Both of these bits of information are important for what comes next, as the two device figure out how to best exchange data and power. This page has already gotten way too long, though, so we'll cover more in Part 2.

This kind of deep exploration is just one of the many activities that a USB-PD protocol analyzer like Dr. PD enables! It also lets you troubleshoot faulty connections, characterize power supplies, and much more! If you want your own, you can join our prelaunch page on Crowd Supply for product updates, or stay tuned here for more posts on USB-C, Power Delivery, and the hardware design behind Dr. PD.