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

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.