USB A to A Direct Link: What Transfers, What Fails, and Why

Two male Type-A ends on one cable form the direct link, and the question behind ‘usb a usb a adapter’ is not the cable, it is the behavior: what actually moves across the link, which devices enumerate, which pairs sit dead, and why the difference is architecture rather than cable quality. A direct A-to-A link is a USB bus with two ends, and a USB bus has exactly one root, the host, which is the fact that decides every outcome on the wire. This article maps the outcomes, the transfers that work, the failures that are structural, and the correct alternative for each failed case.

The Bus Has One Root

A USB link is not a symmetric wire; it is a bus with a root. The host, the computer or a host-mode controller, owns the root hub, supplies 5 V on VBUS, and drives the clock for enumeration. The device side presents itself, the host assigns it an address, and the connection is up. On a direct A-to-A link the two ends must take these two roles, one host and one device, and the roles are fixed by the hardware at each end, not by the cable and not by a setting on the wire. Where both ends claim the host role, or both sit as devices, the bus has no single root and the link does not form, regardless of the cable’s quality.

Host, Root Hub, and Enumeration

Enumeration is the handshake that makes a device visible: the device pulls up a data line to signal its speed, the host detects the connection, addresses the device, reads its descriptor, and binds the driver. The whole sequence runs from the host side, and it is why the host end of a direct link is the end that ‘does the work’. A drive on the device end enumerates as mass storage in a second or two; a pair of hosts on the two ends never starts the sequence at all, because both are waiting for the other to present.

VBUS Ownership

VBUS, the 5 V line, is owned by the host. The host’s port drives it high, and the device draws from it. The ownership is the second half of the one-root rule: a working link has one supply, and a broken link often has two, the two-host case where both ports drive VBUS high and the current between them is the risk. The voltage on the wire is measurable, and the pattern of who drives it is the diagnostic: one side high and the other drawing is the working bus; both sides high is the contention, and neither high is the no-host case.

What Transfers

The transfers that work on a direct link are the ones where the device end presents a class the host end can bind without extra machinery. The USB mass-storage class is the clean case: the drive presents, the host’s OS mounts the file system, and the copy runs, no driver install, no protocol negotiation beyond the class. The second case is the phone in USB storage mode, where the phone presents as a mass-storage device and the same copy runs. The transfers that do not work are the ones where the device end speaks a protocol that needs the host OS’s stack in a way the direct link does not provide, the MTP phone in its default mode, the camera with its own firmware, the instrument with a vendor driver.

UMS Drives: Plug and Copy

The UMS drive is the direct link’s native device: it presents the mass-storage class, the host mounts it, the files copy at the 2.0 tier’s rate, 20 to 40 MB/s for a flash drive and the rated rate for a 2.0 hard drive. The pattern is the field backup, the drive at the equipment, the laptop at the backup window, one cable, no hub, no software between. Every USB mass-storage drive supports this, which is why the UMS drive is the device to specify for a direct-link deployment, and why a drive that ‘does not show up’ on a direct link is usually a power or a length problem, not a class problem.

MTP Devices: the OS in the Loop

The MTP device, the modern phone in its default media mode, is the direct link’s hard case. MTP is a protocol, not a class: the phone presents a media session, and the host OS’s MTP stack, the Windows Media Transfer or the macOS equivalent, is what makes the files visible. On a direct link to a drive, there is no host OS at the other end to run the stack, and the files do not appear. The phone in USB storage mode, where it presents as UMS instead, does copy, and the mode switch is the fix, but the MTP default is the reason ‘my phone does not back up to the drive directly’ is a real and frequent report.

What Fails, and the Fix

The failures on a direct link are three, and each has its correct alternative rather than its correct cable. The two-host failure is the structural one: two roots, VBUS contention, no enumeration, and the fix is the chip-carrying USB networking cable or a LAN link, not a better A-to-A cable. The no-host failure is the two-peripheral case: two devices, neither a host, no supply in the host sense, and the fix is a host at one end or a powered interpose, not a longer cable. The protocol failure is the MTP and vendor-driver case: the device presents, but the class needs a stack the other end cannot provide, and the fix is the host in the loop, the laptop between the two devices, or the device’s storage mode.

Two Hosts: VBUS Contention

The two-host case is the purchase that goes wrong most often on this cable: two machines, one A-to-A link, and the expectation of a direct connection. The bus forms no root, the ports drive VBUS against each other, and the range of outcomes is nothing happening to a port brown-out. The correct part for machine-to-machine is the USB networking cable, which carries an interposed controller that presents a network adapter to each side, or a LAN connection, which does the same job at a better rate. The plain A-to-A cable is not in either purchase, and naming it as such is the fix for the failed deployment.

The Alternatives: Networking Cable, LAN, OTG

The three alternatives cover the three failed asks. The PC-to-PC ask goes to the USB networking cable or the LAN link, the chip or the switch replacing the plain join. The two-peripheral ask, drive to drive or device to device, goes to a host in the loop, the laptop that takes both in turn, or a powered hub with a host upstream. The phone-to-drive backup ask goes to the OTG pattern on the phone’s own port, where the phone hosts and the drive presents, or to the laptop in the middle. Each alternative is a different product for a different root cause, and the direct A-to-A link is the case where the one-root rule is satisfied, not the case that bends to cover the others.

Direct Link Outcomes

Real-World Application Scenarios

Field data collection, where a UMS drive sits at the equipment and the laptop connects directly for the backup window; appliance service, where the A-terminated service lead meets the laptop on the direct link; lab fixtures, where the fixture drive and the fixture host meet on a permanent run; and the fleet documentation case, where the legal direct links, host to UMS, are named in the site standard and the failed links, host to host, MTP to drive, are named with their alternatives. The one-root rule is the standard, and the outcomes table is the acceptance test.

Recommended Internal Resources

Editorial Note: Internal linking recommendation: (1) The joining cable and its limits – https://zh-zong.com/usb-a-to-a-joining-cable/ (anchor: who powers the run and the passive length); (2) The coupler form of the join – https://zh-zong.com/usb-a-male-to-male-coupler/ (anchor: the installed two-socket block); (3) The site FAQ – https://zh-zong.com/faq/ (anchor: common connection questions and their answers).

Frequently Asked Questions (FAQ)