January 22, 2013 at 17:56100 watts over USB or how Power Delivery works
After reading this post and the discussion accompanying it, I decided to try to clarify what USB Power Delivery is and how it actually works. Unfortunately, I got the impression that most of the participants in the discussion perceive 100 watts via USB too literally, and do not fully understand what is behind this at the level of the schematic and protocols.
So, briefly - the main points:
Under the cut - details.
USB Power Delivery works with six types of connectors:
Accordingly, the following types of connections are allowed in pairs
Separately, it is worth noting that the specification directly prohibits perversions with several connectors on one side of the connecting cable, which is quite logical, given currents up to 100 watts. On the other hand, the use of adapters and adapters is not prohibited, provided that they correspond to the power profile, and do not short-circuit the cable screen to its ground.
After certification, USB PD ports are marked as follows:
This logo informs about the USB version (2.0 or 3.0 SuperSpeed), as well as the power profiles that this port supports. The value “I” means the consumed profile necessary for the full functioning of the device, and the value “O” means which profile the port can provide. Port Labeling Examples:
USB PD defines a schematic diagram of the physical organization of the connection through the cable as follows:
As can be seen from the diagram, USB PD also requires that the source and receiver have implemented schemes for determining the voltage drop / surge, as well as methods for determining a discharged battery for cases when one of parties cannot be powered from its internal source.
The following are suggested as algorithms for determining a discharged battery. If one of the sides sets a resistance of 1 kOhm between the screen and the ground, this indicates that its battery is discharged. In this situation, the other side takes on the role of a source and starts to give a minimum of 5V to give power to the other side via VBus and start messaging via USB PD.
As mentioned earlier, the protocol uses the VBus line for USB PD messaging. Below is a block diagram that defines the key functional elements of the transmitter:
And, accordingly, the same block diagram for the receiver:
Serialized 4b5b encoding and 5b4b decoding implies that all data on the bus, except for the packet preamble, is transmitted in five-bit sequences in accordance with the encoding table defined by the standard . Each such sequence encodes either one of 16 digits (0x00..0x0F) or the start / synchronize / reset signals and the end of the packet. Thus, the transmission of one byte takes 10 bits, 16-bit words - 20 bits and 32-bit double words - 40 bits, etc.
The USB PD protocol is based on sequential request-response pairs. Requests and responses are forwarded using packets. Packets consist of a preamble (phase of preparation for transmission), the beginning of the SOP packet (three Sync-1 signals and the final Sync-2 encoded 4b5b), header, 0..N payload bytes, checksum (CRC-32) and end signal packet (single EOP signal):
As mentioned above, the preamble is not encoded in 4b5b. SOP, CRC and EOP are encoded 4b5b at the physical layer, the header and payload are encoded at the level of the logical protocol.
The bus is reset by sending three signals RST1 and a terminating signal RST2, in accordance with the coding 4b5b.
All USB PD messages consist of a header and a chunk of data of arbitrary length. Messages are either generated at the logical protocol level and then sent to the physical layer, or received at the physical layer and then sent to the logical protocol layer.
The message header has a fixed length of 16 bits and consists of the following fields:
Messages are of two types - control (control) and information (data).
Audit messages consist only of a header and a CRC. The number of data objects for such messages is always set to 0. The types of USB PD control messages are presented in the table below:
Separately, it should be mentioned that the fields are of the form tSourceActivity , tSinkRequest , etc. Are constants whose values are globally set by the specification itself in a separate chapter. This is done because they were determined empirically as a result of prototyping, and the optimal values found were simply substituted in a separate chapter so as not to scour the entire specification.
This type of message is designed to obtain detailed information about the source or receiver, as well as to transmit the requested characteristics of the power supply - current strength, voltage, etc. Informational messages always contain a nonzero value in the ”Number of Data Objects” field.
The specification defines four types of information messages:
Types of informational messages are encoded in the ”Message Type” field of the message header as follows:
The source port is always required to communicate its characteristics to the receiver by transmitting a series of 32-bit PDOs. The information transmitted through these objects is used to determine the capabilities of the source, including the ability to work in receiver mode.
Messages about the characteristics are presented in the form of one or more objects following the heading:
Messages about the characteristics are transmitted:
Each PDO object must characterize a separate power supply element that is part of the device at the maximum voltage values that are allowed for it. For example, a built-in 2.8-4.1V battery, a stationary 12V power supply, etc. All power supply elements must support at least 5V and, accordingly, each source must have at least one PDO corresponding to a profile with 5V characteristics.
A PDO corresponding to an element with a constant type of power supply 5V should always go first in the chain of objects.
PDO Object Structure:
Various characteristics are offered for each type of power supply.
Constant type of power supply, constant voltage. A source must have at least one such element:
Programmabletype of power supply, voltage can be regulated by queries between the minimum and maximum:
Variable type of power supply, voltage can vary within the specified limits of the absolute minimum and absolute maximum, but cannot be regulated:
Battery , this type is used to indicate batteries that can be directly connected to VBus lines:
Request messages are sent by the receiver to the source to transmit its requirements in the phase of establishing the power agreement. This message is sent in response to the characteristics message and should contain one and only one data request object - RDO, which describes the information about the required power characteristics for the receiver.
This request has two types, depending on the addressed type of power supply transmitted in the message about the characteristics of the source. For requests to a constant or variable type power supply element or battery, the fields "Operating Current / Power" and "Total Current / Prog Voltage" are interpreted in one way, and for requests to a programmable type element in another way, since in this case the voltage is also requested , and current strength.
The structure of the RDO object:
In my opinion, this information is enough to get a good idea about the principles of USB Power Delivery. I deliberately did not delve into the jungle associated with timers, counters, and error handling.
As mentioned above, Power Delivery is an independent subsystem that operates in parallel and independently of canonical USB. However, in cases where devices implement both protocols - USB and Power Delivery, the specification recommends the implementation of the so-called. System Policy Manager or SPM, a component that can control USB PD equipment through traditional USB requests.
For systems with SPM support, the specification recommends providing PD information through special types of USB descriptors. I do not consider it necessary to go into details in detail, just list their names:
To control USB Power Delivery via USB requests, if the device supports the Power Delivery class, the specification offers commands that can be used to transfer PD requests and objects via USB, that is, via a data bus. A summary table is given below:
I hope that this post has fueled public interest in USB Power Delivery. I modestly note that the author is directly related to this specification, so I am ready to answer any questions about Power Delivery in particular and USB in general.
Sincerely.
So, briefly - the main points:
- USB PD defines 5 standard power profiles - up to 5V @ 2A, up to 12V@1.5A, up to 12V @ 3A, up to 12-20V @ 3A and up to 12-20V@4.75-5A
- Cables and ports for Power Delivery are certified and have additional pins in the connector
- The type of cable and its conformity to the profile are determined automatically through additional pins and determination of the type of USB connector (micro, standard, A, B, etc.)
- Conventional USB cables (not Power Delivery) are certified only for the first profile up to 5V @ 2A
- When connecting, roles are distributed, between those who give current ( Source / Source ) and who consumes ( Sink / Receiver )
- Source and Receiver exchange messages using a special protocol that runs parallel to traditional USB
- As a physical medium, the protocol uses a pair - VBus / GND. That is why Power Delivery is independent of the main USB protocol and is backward compatible with USB 2.0 and 3.0.
- Using messages, the source and the receiver can change roles at any time, change the current strength and / or voltage, go into hibernation or wake up, etc.
- If desired, devices can support PD control through traditional USB requests, descriptors, etc.
Under the cut - details.
About males About cables
USB Power Delivery works with six types of connectors:
Accordingly, the following types of connections are allowed in pairs
- USB 3.0 PD Standard-A <-> USB 3.0 PD Standard-B plug
- USB 3.0 PD Standard-A <-> USB 3.0 PD Micro-B plug
- USB 3.0 PD Micro-A <-> USB 3.0 PD Micro-B plug
- USB 3.0 PD Micro-A <-> USB 3.0 PD Standard-B plug
- USB 2.0 PD Standard-A <-> USB 2.0 PD Standard-B plug
- USB 2.0 PD Standard-A <-> USB 2.0 PD Micro-B plug
- USB 2.0 PD Micro-A <-> USB 2.0 PD Micro-B plug
- USB 2.0 PD Micro-A <-> USB 2.0 PD Standard-B plug
Separately, it is worth noting that the specification directly prohibits perversions with several connectors on one side of the connecting cable, which is quite logical, given currents up to 100 watts. On the other hand, the use of adapters and adapters is not prohibited, provided that they correspond to the power profile, and do not short-circuit the cable screen to its ground.
About ports
After certification, USB PD ports are marked as follows:
This logo informs about the USB version (2.0 or 3.0 SuperSpeed), as well as the power profiles that this port supports. The value “I” means the consumed profile necessary for the full functioning of the device, and the value “O” means which profile the port can provide. Port Labeling Examples:
- The first port supports USB2. It can supply power according to Profile 1 (2A @ 5V) and uses Profile 3 (5V @ 2A or 12V @ 3A) for full functioning. For example, a port for a tablet or netbook.
- The second port supports USB2. It can supply power according to Profile 2 (2A @ 5V or 12V@1.5A) and uses Profile 4 (5V @ 2A or 12V @ 3A or 20V @ 3A) for full operation. For example, a port for a laptop or laptop.
- The third port supports USB3. It only provides power on Profile 1 (5V @ 2A). He himself is not powered by VBus. For example port of desktop, monitor, TV, etc.
- The fourth port supports USB3. As in the first example, it can supply power according to Profile 1 (5V @ 2A) and it itself requires power according to Profile 3 for full functioning (5V @ 2A or 12V @ 3A). Think of an example yourself :)
Physical channel
USB PD defines a schematic diagram of the physical organization of the connection through the cable as follows:
As can be seen from the diagram, USB PD also requires that the source and receiver have implemented schemes for determining the voltage drop / surge, as well as methods for determining a discharged battery for cases when one of parties cannot be powered from its internal source.
The following are suggested as algorithms for determining a discharged battery. If one of the sides sets a resistance of 1 kOhm between the screen and the ground, this indicates that its battery is discharged. In this situation, the other side takes on the role of a source and starts to give a minimum of 5V to give power to the other side via VBus and start messaging via USB PD.
As mentioned earlier, the protocol uses the VBus line for USB PD messaging. Below is a block diagram that defines the key functional elements of the transmitter:
And, accordingly, the same block diagram for the receiver:
Serialized 4b5b encoding and 5b4b decoding implies that all data on the bus, except for the packet preamble, is transmitted in five-bit sequences in accordance with the encoding table defined by the standard . Each such sequence encodes either one of 16 digits (0x00..0x0F) or the start / synchronize / reset signals and the end of the packet. Thus, the transmission of one byte takes 10 bits, 16-bit words - 20 bits and 32-bit double words - 40 bits, etc.
Logical channel
The USB PD protocol is based on sequential request-response pairs. Requests and responses are forwarded using packets. Packets consist of a preamble (phase of preparation for transmission), the beginning of the SOP packet (three Sync-1 signals and the final Sync-2 encoded 4b5b), header, 0..N payload bytes, checksum (CRC-32) and end signal packet (single EOP signal):
As mentioned above, the preamble is not encoded in 4b5b. SOP, CRC and EOP are encoded 4b5b at the physical layer, the header and payload are encoded at the level of the logical protocol.
The bus is reset by sending three signals RST1 and a terminating signal RST2, in accordance with the coding 4b5b.
Protocol
All USB PD messages consist of a header and a chunk of data of arbitrary length. Messages are either generated at the logical protocol level and then sent to the physical layer, or received at the physical layer and then sent to the logical protocol layer.
The message header has a fixed length of 16 bits and consists of the following fields:
Messages are of two types - control (control) and information (data).
Control messages
Audit messages consist only of a header and a CRC. The number of data objects for such messages is always set to 0. The types of USB PD control messages are presented in the table below:
Separately, it should be mentioned that the fields are of the form tSourceActivity , tSinkRequest , etc. Are constants whose values are globally set by the specification itself in a separate chapter. This is done because they were determined empirically as a result of prototyping, and the optimal values found were simply substituted in a separate chapter so as not to scour the entire specification.
Informational Messages
This type of message is designed to obtain detailed information about the source or receiver, as well as to transmit the requested characteristics of the power supply - current strength, voltage, etc. Informational messages always contain a nonzero value in the ”Number of Data Objects” field.
The specification defines four types of information messages:
- Power Data Objec t (PDO) - used to describe source port characteristics or receiver requirements
- Request Data Object (RDO) - Used by the receiver port to establish an agreement on the power characteristics
- BIST (Built In Self Test) Data Object (BDO) - used to test the connection for compliance with the specifications for the physical connection
- Vendor Data Object (VDO) - used to transmit non-standard, additional or other proprietary information determined by the equipment manufacturer and beyond the scope of the USB PD specification.
Types of informational messages are encoded in the ”Message Type” field of the message header as follows:
Feature Report
The source port is always required to communicate its characteristics to the receiver by transmitting a series of 32-bit PDOs. The information transmitted through these objects is used to determine the capabilities of the source, including the ability to work in receiver mode.
Messages about the characteristics are presented in the form of one or more objects following the heading:
Messages about the characteristics are transmitted:
- From the source to the receiver after a certain time interval, with a direct cable connection. The source must continue to send messages for one minute after connecting until a successful power agreement is established, or the receiver returns an RDO with the Capability Mismatch flag - mismatch.
- From source to receiver for the purpose of forcibly reinstalling the power agreement or changing the characteristics.
- In response to Get_Source_Cap or Get_Sink_Cap control messages
Each PDO object must characterize a separate power supply element that is part of the device at the maximum voltage values that are allowed for it. For example, a built-in 2.8-4.1V battery, a stationary 12V power supply, etc. All power supply elements must support at least 5V and, accordingly, each source must have at least one PDO corresponding to a profile with 5V characteristics.
A PDO corresponding to an element with a constant type of power supply 5V should always go first in the chain of objects.
PDO Object Structure:
Various characteristics are offered for each type of power supply.
Constant type of power supply, constant voltage. A source must have at least one such element:
Programmabletype of power supply, voltage can be regulated by queries between the minimum and maximum:
Variable type of power supply, voltage can vary within the specified limits of the absolute minimum and absolute maximum, but cannot be regulated:
Battery , this type is used to indicate batteries that can be directly connected to VBus lines:
Request Message
Request messages are sent by the receiver to the source to transmit its requirements in the phase of establishing the power agreement. This message is sent in response to the characteristics message and should contain one and only one data request object - RDO, which describes the information about the required power characteristics for the receiver.
This request has two types, depending on the addressed type of power supply transmitted in the message about the characteristics of the source. For requests to a constant or variable type power supply element or battery, the fields "Operating Current / Power" and "Total Current / Prog Voltage" are interpreted in one way, and for requests to a programmable type element in another way, since in this case the voltage is also requested , and current strength.
The structure of the RDO object:
In my opinion, this information is enough to get a good idea about the principles of USB Power Delivery. I deliberately did not delve into the jungle associated with timers, counters, and error handling.
Connectivity with traditional USB
As mentioned above, Power Delivery is an independent subsystem that operates in parallel and independently of canonical USB. However, in cases where devices implement both protocols - USB and Power Delivery, the specification recommends the implementation of the so-called. System Policy Manager or SPM, a component that can control USB PD equipment through traditional USB requests.
For systems with SPM support, the specification recommends providing PD information through special types of USB descriptors. I do not consider it necessary to go into details in detail, just list their names:
- The Power Delivery Capability Descriptor is an integral part of the BOS descriptor and reports whether the device supports battery charging via USB, whether it supports the USB PD standard, whether it can act as a power source, and whether it can be a receiver. In addition, this descriptor contains information about the number of source ports, receiver ports, and the version of the supported USB Battery Charging and Power Delivery specifications.
- Battery Info Capability Descriptor , required for all devices that claim the battery as one of the power supplies. It contains information about the name, serial number and manufacturer of the battery, its capacity, and also about threshold current values in the charged and discharged state.
- PD Consumer Port Capability Descriptor , required for all devices that have declared support for at least one receiver port. Contains support information for Power Delivery and Battery Charging standards, minimum and maximum voltage, operating power, maximum peak power and maximum time that it can consume this peak power
- PD Provider Port Capability Descriptor , required for all devices that have declared support for at least one power supply port. It contains information about the support of Power Delivery and Battery Charging standards, as well as a list of all PDO objects that characterize the power elements available to the device.
- PD Power Requirement Descriptor , required for all receiver devices supporting USB PD. Each device must return at least one such descriptor as part of the configuration descriptor. This descriptor should go immediately after the first interface descriptor. In the case when there are several of them, it should go after each first descriptor of the function interface, if IAD is used, or in the case of a composite device without IAD, immediately after each interface descriptor, and before the endpoint descriptors.
To control USB Power Delivery via USB requests, if the device supports the Power Delivery class, the specification offers commands that can be used to transfer PD requests and objects via USB, that is, via a data bus. A summary table is given below:
Conclusion
I hope that this post has fueled public interest in USB Power Delivery. I modestly note that the author is directly related to this specification, so I am ready to answer any questions about Power Delivery in particular and USB in general.
Sincerely.