USB and Type-C

A USB-C cable rated for 240 W may still transfer files at USB 2.0 speeds; a laptop charging from a dock does not guarantee that the port supports display output. Connectors, data transmission, video, and power delivery are interrelated but separately declared capabilities. This article first breaks down these concepts, then explains "what happens after plugging in" by following device enumeration and power negotiation.

Connector Names Do Not Replace Data Modes

Type-A, Type-B, Micro-B, and Type-C are connector types, not speeds. Traditional USB 2.0 Type-A has four contacts: VBUS, D−, D+, and GND; SuperSpeed Type-A adds five contacts, four of which form two pairs of high-speed differential signals, and the other is a reference contact. Five contacts are added, not five pairs of differential lines.

The complete definition of a USB-C receptacle has 24 contacts, but products implementing only USB 2.0 may not connect high-speed data channels; some simplified connectors do not provide all contacts. You cannot infer that full data or video functions are implemented just because the receptacle shape is the same.

USB-IF's user-facing naming expresses performance as USB 5/10/20/40/80Gbps. USB4 Version 2.0 has extended to the 80 Gbit/s level, so stating that USB4 is capped at 40 Gbit/s is no longer complete; version names still do not mean every product implements all optional capabilities. USB-IF: Data Performance Naming, USB4 Overview

These are link speeds and cannot be directly equated to file transfer speeds. Taking 5 Gbit/s with 8b/10b encoding as an example, after encoding alone, only 5×8/10=4 Gbit/s remains, which is 500 MB/s; headers, flow control, retries, USB storage protocols, controllers, and media will further consume the budget. Do not treat this as the throughput that a real-world disk can definitely achieve, nor do you simply add bidirectional rates to advertise as unidirectional speed.

When a USB4 port connects to a USB 3.2 Gen 2×2 device, you still need to check if they both support Gen 2×2; "the host has a higher number" does not guarantee that all lower-numbered link combinations will run. A Hub's multiple downstream ports also share upstream bandwidth; adding an interface does not magically increase the host channel.

USB 2.0 and SuperSpeed Lines Are Not the Same

USB 2.0 uses D+/D− for half-duplex transmission. Pull-up positions for Low and Full Speed are used for connection/speed identification; High-Speed devices enter High-Speed mode via handshake during the reset phase, and you cannot distinguish Full Speed from High Speed just by looking at the D+ pull-up. High-Speed signal electrical conditions differ from Low/Full Speed and cannot be uniformly written as "USB 2.0 differential 3.3 V".

SuperSpeed uses independent transmit and receive differential channels, with link training, power states, and flow control. USB-C high-speed pairs also need to be multiplexed according to insertion direction and usage mode. USB4 further organizes supported protocol flows through routing and tunneling; it does not simply accelerate USB 2.0 D+/D−, nor can all USB generation connection detections be drawn as D+ pull-ups.

Traditional USB buses form a hierarchical tree rooted at the Host/Root Hub, with Hubs expanding downstream connections. The Host controls transfer scheduling, and devices provide functionality via endpoints; this does not mean devices can never send any link notifications or request wake-ups, but rather that ordinary functional data cannot arbitrarily seize the bus like in any peer-to-peer network.

Enumeration: From Power On to Driver Ready, Multiple States in Between

Using a standard USB 2.0 peripheral as an example: after the device connects, the Host performs a port reset, reads initial information using the default address 0 control endpoint, assigns an address, then retrieves full descriptors and selects a configuration. Different systems may have different read orders, but the default control endpoint, address, and configuration are distinct stages.

IN/OUT are always named from the Host's perspective: IN is Device to Host, OUT is Host to Device. Endpoint 0 handles default control transfers; other endpoints are declared by configuration and interface descriptors. A composite device can have both a keyboard interface and a vendor data interface, binding to separate drivers; do not treat "loading one device driver" as a fixed model for all devices. Microsoft: USB Endpoints and Their Pipes

The Four Transfer Types Do Not Promise the Same Kind of "Reliability"

Endpoint scheduling constraints and the time the application receives data are still separated by the controller, driver, buffers, and system scheduling. Audio/Video can tolerate minor losses to maintain time continuity; file transfers usually prioritize integrity. A successful USB transfer does not mean the application has persisted the data; device internal caches and command completion semantics need separate confirmation. Linux: USB Host API and Transfer Model

Common classes include HID, Mass Storage, CDC ACM/NCM, Audio, Video, and DFU. "Driver-free" usually means the operating system already has a compatible class driver; version, descriptors, device subclass, and vendor extensions still affect support. CDC is a set of Communication Class definitions; do not label all CDC as requiring drivers and then label ACM within it as not requiring drivers; drivers are always present, the difference is whether the user needs to install them additionally.

Type-C Pins by Function

This explains by signal function and does not provide pad coordinates that might confuse front/back; PCB design must verify against the selected connector's datasheet, viewing direction, and package pin numbers.

CC Detects Connection and Power Roles, Roles Can Be Further Negotiated

Common Sources provide Rp, Sinks provide Rd; after insertion, the valid CC path detects connection and direction. A simple fixed Sink receptacle sets independent Rd on CC1 and CC2 respectively, commonly 5.1 kΩ nominal; the two pins cannot share one resistor to short them, nor can only one side be installed, causing abnormality in one direction. For full role, current detection, or PD, use an appropriate controller and power path design. TI: Type-C Engineering Guide

Type-C current advertisement includes USB Default, 1.5 A, 3 A, etc., 5 V capabilities. USB Default must be judged in conjunction with corresponding USB/charging rules; do not uniformly treat it as "plug in and get 500 mA", and certainly do not assume you can get 3 A just because you see two Rd resistors. The Sink must draw current according to actual advertisement and protocol limits.

Data roles (Host/Device) and Power roles (Source/Sink) should be separated. For example, a laptop can act as a data Host managing a dock, while simultaneously acting as a Sink charging from the dock; PD-supported devices can perform role swaps according to capability. Contacts not used for current CC communication may also carry VCONN, powering the cable's electronic components; VCONN and high-power VBUS are not the same power path.

PD: Establish Contract First, Then Supply Power According to Contract

A standard Type-C connection first completes safe connection detection and default power supply processes; you cannot apply arbitrary high voltage immediately upon insertion. PD requests new power conditions via message exchange on CC; the Source provides capabilities, and the Sink proposes a Request based on its own, cable, and system limits. The fixed PDO example flow is as follows.

The Source sending Accept only means it accepts the request; the power still needs to switch and stabilize, and then report ready via PS_RDY. PPS is a programmable power capability, not a generic state after Accept. The Request may be rejected, and power capabilities may be renegotiated due to multi-port sharing or temperature changes; the device must handle negotiation failures and contract changes.

EPR introduced in PD 3.1 extends the limit to 48 V×5 A=240 W, requiring the port, cable, and power path to jointly possess relevant capabilities; nominal PD version does not replace specific capability declarations. USB-IF: USB Power Delivery

PPS allows the power supply to output voltage/current more suitable for the device charging chain, reducing some conversion losses, but the battery still requires controlled voltage/current, protection, and thermal management; common systems still use buck or charge pump circuits. The programming granularity of a PPS Request does not equal measured voltage accuracy or current ripple; charging speed is jointly limited by battery state and overall system strategy.

Power Calculation Example: Interface Input Power Is Not Battery Power

Assume negotiation to 20 V, 3 A, interface limit is 60 W; under teaching conditions of 3 A load and a complete power loop resistance of 0.10 Ω, the cable voltage drop is 0.30 V, loss is 0.90 W, and the receiving end gets approximately 59.1 W. If the device itself consumes 10 W, the remaining power passes through an assumed 90% efficient charging path, and the battery gets approximately (59.1−10)×0.9=44.19 W.

This is an allocated budget, not the measured efficiency of a specific phone or computer. Increasing negotiated power does not guarantee the device continuously absorbs at the limit; port sharing, battery charging stages, and temperature control may all change actual values.

Can new power be used immediately after Accept?

Reject a request and the previous ready conditions remain. Accept one and the supply becomes transitioning rather than immediately available at the target. Buttons represent protocol events with causal prerequisites.

Cable Markings and Video Capabilities Must Be Checked Separately

USB-IF's USB-C cable certification markings distinguish data performance and power capabilities. USB 2.0 data cables can also support higher PD power, so "240 W" is not proof of a high-speed cable; the e-marker is part of cable capability identification and cannot be judged to support all speeds just by having a chip. USB-IF: Cables and Connectors, Type-C Product Language Guidelines

DP Alt Mode can allocate high-speed signal pairs to DisplayPort: common two DP lane schemes retain another set of USB 3.x transceiver connections, while four DP lane schemes use the high-speed pairs for video, with USB 2.0 D+/D− still usable. Resolution is not determined solely by lane count; it also depends on link speed, blanking, refresh rate, color depth, chroma subsampling, and DSC support. Do not fixedly write "two lanes means 4K60". VESA: DisplayPort Alt Mode

Video tunneling in USB4 allocates bandwidth within the USB4 connection, which is different from Alt Mode that directly switches connector high-speed pairs to native DP. Thunderbolt also has its own versions and certification requirements; do not directly equate all USB4 products to a specific generation of Thunderbolt.

Locate by Failure Stage, More Explicit Than Repeatedly Swapping for "More Expensive Cables"

Recalculate Bandwidth and Power

from math import isclose

encoded_byte_rate = 5e9*(8/10)/8
assert encoded_byte_rate == 500e6  # Has not yet deducted packet and storage protocol overhead
voltage, current, loop_r = 20, 3, 0.10
loss = current**2*loop_r
received = (voltage-current*loop_r)*current
assert isclose(loss, 0.9) and isclose(received, 59.1)
assert isclose(received+loss, voltage*current)
assert isclose((received-10)*0.9, 44.19)
assert 48*5 == 240
print('Encoding throughput, cable voltage drop, power allocation, and EPR limit calculation checks passed')

Continue Reading

• PCIe and High-Speed Interconnects: Lanes, encoding, and link throughput.
• Display and Camera Interfaces: Video bandwidth and interface modes.
• Charging Protocols and Fast Charging: Negotiation, conversion, and battery charging paths.