A Mac and an iPad walk into a bar, Part 3

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.

As we saw in the previous part, it has taken 35 messages for the Mac and the iPad to set up a basic power contract and establish USB serial communications. There still remains an important task: negotiating a long-term power arrangement.

Recall that both devices are Dual-Role Ports, meaning that they can act as either source or sink based on demand. In practice, the Mac will usually act as the source — though not always, since there are ways to charge the Mac from an iPad, which is quite cool — but that does not diminish the need for a more thorough inspection of the iPad’s power requirements.

After all, there might be multiple devices connected to the Mac’s four USB-C ports, and the Mac itself has a limited amount of power available to charge other devices, even when it is connected to mains power. Therefore, its power-management system needs to understand the needs of each connected device so it can better balance the amount of power sent to each port.

Phase 5: I've got the power

The power negotiation begins with the Mac asking the iPad about its identity and battery setup:

In this exchange, the Mac first asks the iPad for information about its battery. Recall from Part 1 that the Mac learned the iPad has one battery from the Sink_Capabilities_Extended message. The iPad replies that it has a 40 Wh capacity, and that the last full charge also brought the battery to 40 Wh. This, incidentally, is a lie: this iPad’s battery is on its last legs and barely reaches 80% capacity.

Next, the Mac asks for the status of the iPad’s battery. The iPad replies that it is full and that it is charging. That is true on both counts, since the battery was at maximum charge and the iPad was topping it up with power from the Mac.

The Mac then asks for the iPad’s status so that it can determine whether there are any conditions, such as an overtemperature warning, that could affect the power profile. The iPad’s response is entirely unremarkable—to the point that it is probably perfunctory rather than a reflection of its actual status.

Finally, the Mac asks for the iPad's manufacturer information, and the iPad replies with its name, VID, and PID.

Phase 6: My turn

We're finally getting into the home stretch now. 

A Mac and an iPad walk into a bar, Part 2

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:

A Mac and an iPad walk into a bar, Part 1

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:

(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...