Power Delivery

API Documentation: [cpp] [python] [.NET] [LabVIEW]

Power Delivery or PD is a power specification which allows more charging options and device behaviors within the USB interface. This Entity will allow you to directly access the vast landscape of PD.

When the capabilities of a PD system are fully realized everything in the system is “smart”. That includes the device, the host and even the cable. All of these elements contain electronics that identify themselves and what they are capable of doing. Because of this complexity it is important to align on a few terms that will be used throughout this Entity.

Partner This refers to the side of the PD connection in question. The possible options for this parameter are.

  • Local Indicates the context/perspective of the Acroname device you are communicating with through a BrainStem connection.

  • Remote The context/perspective of anything other than the Acroname device.

Partner Type

Value

Define

Local

0

powerdeliveryPartnerLocal

Remote

1

powerdeliveryPartnerRemote

Power Role Indicates the direction of power. This value is typically used in the context of a “Partner”. i.e. The remote partner is sinking, which would mean the local partner is sourcing. The possible options for this context are:

  • Sink Indicates that the partner is taking power in/from.

  • Source Indicates that the partner is providing power out/to.

Power Roles are also used in the context of what a port is capable of doing.

  • Sink Device is capable of consuming power.

  • Source Device is capable of producing power.

  • Sink/Source Device is capable of both consuming or producing power. Dual Role Port (DRP)

Power Role

Value

Define

Disabled

0

powerdeliveryPowerRoleDisabled

Source

1

powerdeliveryPowerRoleSource

Sink

2

powerdeliveryPowerRoleSink

Source/Sink

3

powerdeliveryPowerRoleSourceSink

Power Data Objects (PDO)

  • PDO’s define what a device is capable of doing in the world of Power Delivery. PDO’s are bit packed integers defined by the PD Specification which vary in meaning based on the type of PDO.

Request Data Objects (RDO)

  • RDO’s are the final agreement after successful Power Delivery negotiations. This RDO is always sent by the sinking device and is the result of the sources advertised PDO’s and the needs/requirements of the sinking device. Only one RDO exists per valid connection.

Manipulating PDO’s and RDO’s

The Power Delivery specification defines a large number of Data Objects and the USBHub3c is capable of manipulating and modifying most of them in some fashion. The most common are PDO’s and RDO’s which were defined above. Direct manipulation is quite a complex process and is a feature of the Pro version only. It is highly recommended that users of these features first experiment with the Power Rule Editor within HubTool. Once you know the values you want to use manipulation can be done through:

stem.pd[x].setPowerDataObject() [cpp] [python] [NET] [LabVIEW]
stem.pd[x].getPowerDataObject() [cpp] [python] [NET] [LabVIEW]
stem.pd[x].setRequestDataObject() [cpp] [python] [NET] [LabVIEW]
stem.pd[x].getRequestDataObject() [cpp] [python] [NET] [LabVIEW]

Power Roles Preferred

Preferred Power Role

Value

Define

None

0

pdPowerRolePreferred_None

Source

1

pdPowerRolePreferred_Source

Sink

2

pdPowerRolePreferred_Sink

Connection State

Connection State

Value

Define

None

0

pdConnectionState_None

Source

1

pdConnectionState_Source

Sink

2

pdConnectionState_Sink

Powered Cable

3

pdConnectionState_PoweredCable

Powered Cable with Sink

4

pdConnectionState_PoweredCableWithSink

Requests

Given the nature of Power Delivery there are only so many things that are within the direct control of the local USBHub3c. Many of the items on the remote side of the USBHub3c are merely request. In other words items in this category not guaranteed to happen.

stem.pd[x].request() [cpp] [python] [NET] [LabVIEW]

Request

Value

Define

Hard Reset

0

pdRequestHardReset

Soft Reset

1

pdRequestSoftReset

Data Reset

2

pdRequestDataReset

Power Role Swap

3

pdRequestPowerRoleSwap

Power Fast Role Swap

4

pdRequestPowerFastRoleSwap

Data Role Swap

5

pdRequestDataRoleSwap

Vconn Swap

6

pdRequestVconnSwap

Sink Go to Min

7

pdRequestSinkGoToMinimum

Remote Source PDOs

8

pdRequestRemoteSourcePowerDataObjects

Remote Sink PDOs

9

pdRequestRemoteSinkPowerDataObjects

Remote Source Extended Capabilities

10

pdRequestRemoteSourceExtendedCapabilities

Remote Sink Extended Capabilities

11

pdRequestRemoteSinkExtendedCapabilities

Status

12

pdRequestStatus

PPS Status

13

pdRequestPPSStatus

Battery Capabilities

14

pdRequestBatteryCapabilities

Battery Status

15

pdRequestBatteryStatus

Manufacturer Info Sop

16

pdRequestManufacturerInfoSop

Manufacturer Info Sopp

17

pdRequestManufacturerInfoSopp

Manufacturer Inof Soppp

18

pdRequestManufacturerInfoSoppp

Discover Identity Sop

19

pdRequestDiscoverIdentitySop

Discover Identity Sopp

20

pdRequestDiscoverIdentitySopp

Discover Identity Soppp

21

pdRequestDiscoverIdentitySoppp

Revision

22

pdRequestRevision

Source Info

23

pdRequestSourceInfo

Country Code

24

pdRequestCountryCode

Country Info

25

pdRequestCountryInfo

Errors return from this function call only indicate the success of sending the request and do not reflect the success of the actual request. To find the status of the request you can investigate the outcome of the connection or check the most recent status of the PD stack.

stem.pd[x].requestStatus() [cpp] [python] [NET] [LabVIEW]

Cable Orientation

Although the Type C connector has no visible orientation the connector does have electrical orientation which directly correlates to the Communications Chanel (CC) strapping internal to the cable. The orientation be be obtained via:

stem.pd[x].getCableOrientation() [cpp] [python] [NET] [LabVIEW]

Orientation

Value

Define

Invalid

0

pdCableOrientation_Invalid

CC1/A Side

1

pdCableOrientation_CC1

CC2/B Side

2

pdCableOrientation_CC2

Cable Type

Cable Type

Value

Define

Invalid

0

pdCableType_Invalid

Passive

1

pdCableType_Passive

Active

2

pdCableType_Active

Override

The USB C connector by default follows rules around maximum cable current and budgetted power. In some test applications, including ones with a Universal Orientation Cable, the port should ignore those rules which is why we have exposed override bits to allow for disabling of specific behavior. Below are the get/set routines for overrides and the bit definitions.

stem.pd[x].getOverride() [cpp] [python] [NET] [LabVIEW]
stem.pd[x].setOverride() [cpp] [python] [NET] [LabVIEW]

Name

Bit

Definition

Cable Current

0

overrides the cable current limiting to 3A unless it’s an emarked cable

Port Power

1

Overrides the port power budgetting and just allows full power always

Auto Discovery

2

Overrides the auto discovery feature. With override true the hub will only establish a basic power connection and wont ask for additional vendor information.