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.

In the first part of this series, the Mac and the iPad managed to do the bare minimum: establish a working power contract and exchange a few high-level hints about their capabilities. 

That’s enough to get electrons flowing, but it’s nowhere near enough to make full use of what a USB-C connection can actually do. At this point, the conversation shifts from what power can you provide? to what are you, and what else can you do? 

The devices begin probing each other more deliberately, using structured messages to identify capabilities, supported modes, and potential roles beyond simple power delivery.

Phase 3: Is it me you're looking for?

Remember how, up to this point, the iPad and the Mac had no idea they were talking to each other? That’s about to change.

Both Source_Capabilities_Extended and Sink_Capabilities_Extended contain the Vendor ID (VID) and Product ID (PID) of their respective senders. This means that both the Mac and the iPad are now aware that they are exchanging data with an Apple device, which opens up the possibility of exchanging proprietary information and using more specialized communication mechanisms.

With this information in hand, the Mac immediately moves to learn more:

The iPad starts spilling the beans on a bunch of its capabilities; here, we learn that it supports both USB 2.0 and up to USB4 Gen 3 (40 Gbps). (These are, technically, two separate interfaces and are therefore listed as such.)

Note the use of the Vendor_Defined message here. This is a bit of a jack-of-all-trades mechanism for devices to exchange data, both using predefined binary layouts (called structured data in USB-PD parlance) and in a completely proprietary format (called unstructured data). We’re going to see a lot more of it shortly.

Now that it has some idea of what it’s dealing with, the Mac starts to dig a bit deeper:

The first vendor request, DISCOVER_SVIDS, asks for the iPad’s Standards or Vendor IDs (SVIDs) that it supports. These, in turn, tell the Mac which Alternate Modes the iPad supports. Alternate Modes allow devices to repurpose the high-speed lanes of a USB-C cable to carry protocols other than USB (e.g., DisplayPort or Thunderbolt).

Here, the iPad states that it “knows” three SVIDs:

• 0x8087, which is one of Intel's Vendor IDs specifically used for Thunderbolt modes.
• 0xFF01, which is the DisplayPort Standard ID, used to negotiate video transmission.
• 0x05AC, which is Apple's own VID.

The Mac the sends a DISCOVER_MODES for each of the 3 SVIDS.

• The first response, 0x01 for SVID 0x8087, indicates that the iPad supports Thunderbolt 3 Alternate Mode
• The second response, 0x1C46 for SVID 0xFF01, provides information about the iPad’s DisplayPort capabilities. Specifically, it indicates that the device can act as a DisplayPort source (i.e., it can send video data), uses a USB-C receptacle (rather than a captive cable), and supports several pin assignments.
• Finally, the last response (0x02 for SVID 0x05AC) is an Apple-specific value whose meaning is proprietary.

Phase 4: With arms wide open

Having established what alternate modes the iPad supports, the Mac proceeds to establish full communications with it:

The first message, Enter_USB, causes the two devices to establish a USB data connection. It may seem strange that this has to be negotiated through USB-PD messaging, but remember that the kind of USB connection that can be established is governed by multiple factors: the type of interface supported by each device, as well as the cable’s ability to carry data. Without this step in the USB-PD transaction, the devices may end up in conflicting configurations, which could cause connectivity problems.

As you can see, here the Mac requests a USB 2.0 connection despite the fact that both it and the iPad could support USB 3.x/USB4. The reason is that the cable being used between the two does not include SuperSpeed wiring, and therefore cannot carry signals for the higher-speed interfaces.

Next, the Mac asks the iPad to enter the mysterious Apple-proprietary mode. Unsurprisingly, I was unable to find any documentation on this, and so it's hard to say what this means or does.

This concludes the two devices' data negotiation, but it's far from the end for the overall conversation, We'll pick things back up in Part 3, where we return to power negotiation.

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.