USB notes

⚠ This is for beginners and very much by a beginner / hobbyist It's intended to get an intuitive overview for hobbyist needs. It may get you started, but to be able to do anything remotely clever, follow a proper course or read a good book. Some basics and reference: Volts, amps, energy, power · batteries · wallwarts and power bricks · resistors · transistors · fuses · diodes · capacitors · inductors and transformers · ground Slightly less basic: amplifier notes · varistors · changing voltage · baluns · frequency generation · Transmission lines · skin effect And some more applied stuff: IO: Input and output pins · wired local IO · wired local-ish IO · ·  Various wireless · 802.11 (WiFi) · cell phone Sensors: General sensor notes, voltage and current sensing · Knobs and dials · Pressure sensing · Temperature sensing · humidity sensing · Light sensing · Movement sensing · Capacitive sensing · Touch screen notes Actuators: General actuator notes, circuit protection · Motors and servos · Solenoids Noise stuff: Stray signals and noise · sound-related noise names · electronic non-coupled noise names · electronic coupled noise · ground loop · strategies to avoid coupled noise · Sampling, reproduction, and transmission distortions Audio and video notes: See avnotes Platform specific: : Microcontroller and computer platforms ·· Arduino and AVR notes · ESP series notes · STM32 series notes · Teensy series notes · RP2040 and RP2350 notes Less sorted: USB notes · Ground · device voltage and impedance (+ audio-specific) · electricity and humans · Soldering · landline phones · pulse modulation · PLL · multimeter notes · signal reflection · Project boxes · resource metering · Radio and SDR · vacuum tubes · Unsorted stuff · 'E-fuse' Some stuff I've messed with: Avrusb500v2 · GPS · Hilo GPRS · JY-MCU · DMX · Thermal printer · See also Category:Electronics.

Everyday USB

Connectors

See Common plugs and connectors#USB

Unplugging USB

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

"Do you need to 'Safely Remove Hardware'?"

tl;dr:

depends on the driver

depends on the device

often it's fine, though it's not a guarantee

if it involves storage, you may break off in the middle of a write.

There are a few angles to discuss:

The electronics

Electrically, the USB bus was designed to be hot-pluggable. Nothing will spark, and the host will almost certainly figure out a device left.

The function

For things like keyboard, mouse, webcam, MIDI interface, transfers are stateless and immediate. It stops functioning, but we were expecting that.

But if the thing the device is stateful in some way, disconnecting it at an arbitrary time may confuse or corrupt. Especially anything involving storage, especially when you yank it in the middle of writing data, it may leave that storage/data in a bad state.

The driver or API

If the driver was not considering the possibility of a device leaving, that may cause trouble. This is rare; it's part of the USB SDK to handle this

Something similar goes for the OS API it talks to.

Basically, is the API hot-plugging: older media API might assume a device could not go away, and break if it does, but newer ones do.

The application

Applications will generally look at the API and implement it, including the 'what happens on disconnect'. But it is possible for the application to skip the last part, which can mean that application can break.

More notes on storage

There are roughly two issues here:

Filesystem APIs mostly assume that a file stays open and available until the program that opened it says it is done.

Built-in storage typically has an optimization in "keep the last seconds worth of data before actually writing it" (see writeback versus writethrough).

As a result, yanking while reading from a external storage will almost certainly make the reading program unhappy, yet the storage itself is typically fine - nothing was changing.

Yanking while writing is usually bad.

Most filesystems write file data in-place (meaning they do not implement a guaranteed recovery)

Assume there is a time at which only the host knows the data.

A number of filesystems are a little more robust about filesystem metadata

but you shouldn't assume that it does

and you shouldn't assume that means the file is fine, just that the filesystem is.

Operating systems classically had a distinction of

larger storage always be hard drives, which was built in couldn't leave

removable media that would generally have their write operations be more immediate.

USB-connected storage made that built-in versus removable distinction fuzzier. Operating systems tend to err on the side of considering it removable media.

USB Device Not Recognized / Device has malfunctioned

Wat you see:

that error, shown in a balloon near the task bar

with the addition that "One of the USB devices attached to this computer has malfunctioned, and windows does not recognize it."

(that balloon message can be disabled, in which case the device only shows up as an "Unknown Device" in the device manager.)(verify)

What it means:

Broadly, it can tell that there is a device there, but it did not communicate as it should have.

...but yeah, that's a generic description, and this is a generic error

so there are many possible causes

and it's often hard to diagnose what will help most, or even whether it is solvable.

Possible problems/solutions

While troubleshooting it is often a good idea to try easy-to-do checks first (even if they aren't likely to be the actual problem, they may quickly give you more information).

So:

• check for broken cable (cables get stepped, yanked, chewed, plug got bent, plug isn't held in in anymore, etc.)
  • if it's interchangeable, try another one (maybe try this first, in that it is the easiest fix if this is the cause)
  • If it's not interchangeable, try wiggling it to see if it accidentally makes a good contact.

It's not the nest test, in that

if it doesn't start working it tells you nothing

yet if it turns up fine temporarily, you know more

• does the problem follow the device, or the computer
  • test: try in other computers - and to be sure, also with varying OSes (some devices don't have drivers for older/specific OSes)
  • this should give you a strong indication whether it is related to the device, or to the PC

• does the problem persist in all socket/controllers
  • Test: Try other things in the same port, try this device in other ports
  • Note: each pair of ports is usually the same internal hub, so if trying multiple, try ones at some distance rather than the one right next to it
  • Basic mice may be the most useful test devices to test whether ports work, as they are low-power and do not require drivers to work

• USB port in a weird state (e.g. the previous device drew too much power and triggered the polyfuse. But there is another reason or two)
  • (some are more sensitive/careful than others. Macbook's protection was apparently known for triggering very quickly)
  • Test/fix: Turn computer off completely, and then leave the power cord/battery out for a few minutes (that much is rarely necessary, but sometimes it is and it takes less time to wait a bit longer once than to reboot again)

• Some battery-powered devices cannot be bus powered, so will only respond fine if their battery is high enough
  • if switching batter

that said, other battery-powered devices will specifically become bus-powered when plugged in, in which case this cannot be the problem

More work and/or less likely to help:

• USB knows you are crossing the limit of power it can give out, and refuses the next device
  • (except this doesn't really extend to things plugged into external hubs)
  • more likely to happen on a non-powered hub
  • Test: try plugging the device into the computer itself (or into a powered hub that has no high-powered devices)
    • Front ports may sometimes be non-powered hubs, so a back (motherboard) port would be a better test. On laptops there may be less difference, but try multiple.
  • Test: try a mouse in the same port - these are typically low-power and so very likely to work if the port's not broken.

• bad or missing driver for the particular device
  • Test: see if it consistently works fine anywhere else (different PC, different OS on same PC), try with a different driver (but forcing this can be difficult)

annoying to text exhaustively, though

• some devices don't like sleep/hibernate, regardless of version of anything, and may stay confused until a reboot
  • test: either do a full poweroff-and-wait.
  • Sometimes plugging it into a different port helps. Maybe see whether sleep/hibernate makes it stop working - that would tell you that's likely the trigger

• It seems that Windows's collection of drivers for USB devices (one or more) can get wonky.

trying to reset all that is a lot of work for usually no result, and it is hard to tell whether you've done this as thoroughly as you need to

...sod this tends to be more of a last-resort thing, useful when you have all indications it's specific to only this PC and probably not a hardware issue

Test/fix:

unplug device

uninstall as many related drivers as you can (peripheral drivers first, controller drivers last)

then ideally reboot, let it re-detect and re-install everything, and re-plug the device(s)

See also

• http://dan.hersam.com/2005/07/18/usb-device-not-recognized/
• http://support.microsoft.com/default.aspx?scid=kb;en-us;817900
• http://support.microsoft.com/?kbid=873169

USB OTG

For context, USB classically had all devices communicating to a host (which was very typically a PC).

In parallel to that, that meant that USB-A meant host side, almost always, meaning less confusion and fewer smoky mistakes.

USB On-The-Go (OTG) came from the idea of USB devices talking to each other without such a PC acting as a host.

So tl;dr: An OTG port is one that can act both as a a USB device and as a USB host.

It was primarily aimed at phones and other mobile things, in part because sticking a USB-A socket would very chunky at best, so phones's micro-USB and later USB-C became capable of OTG.

USB power and charging

It seems like USB only accidentally became a standard for charging things, which is why the history of transferring more power through it is interesting.

USB3 and USB-C as a plug made things more capable -- but also more negotiated and more varied, so harder to understand and to explain.

Attempt at shortish answer

In the USB-A days

• PC ports

USB2: assume you can get 100mA if you don't ask, probably 500mA if you ask

USB3: assume you can get 100mA if you don't ask, probably 900mA if you ask

• powered USB-A hubs - often similar to PC ports

(but power provisioning does not extend into hubs so it's no guarantee)

(and these were were as common as unpowered hubs)

• unpowered USB-A hubs - assume you can get 100mA

(but if you chain them all bets are off)

• generic USB-A wallplug chargers - probably ≤500mA

• device-specific wallplug chargers - might draw up to 1A, some 2A (at 5V or sometimes higher) - details vary

but you might need a specific charger-phone, or even charger-cable-phone combo

not higher (we could not assume cables were okay)

• Battery Charging (BC) [1]

works on everything compliant to it (which wasn't a whole lot)

up to 1.5A (at 5V, so 7.5W), but some devices play it much safer

In the USB-C days

• note that a source doesn't need to provide any charging, USB-C or no

which may come down to the first 'without PD' option, and if a device doesn't check, the 'try to get away'

• Checking CC, without PD, the host can advertise on the CC pins that a device could draw 5V at

default -- which seems to mean mean 'apply rules from the old days' {{comment|(which, remember, never let you assume more than 100mA was actually available even with negotiation, but DIY might get away with assuming 500mA or 900mA)]}

1.5A

3A

(if devices do not try to deal with CC, then you may get "works from USB-A but not from USB-C sources" behaviour, or some other nonstandard messiness(verify))

• Power Delivery (PD)

works on everything compliant to it

cables allow 3A, and higher than 5V

so practically will do something between 10 and 60W (depending on device and source design)

higher max in later versions

Assume PD isn't a thing when USB-A plugs are involved anywhere

• technically BC work over USB-C

but that's probably mostly useful in a 'great for devices that support only BC' way

and you can't assume sources that do PD will also provide BC

• technically some older quick-charging modes work over USB-C

but in most cases you wouldn't want to do that anymore

More on device-specific chargers (USB-A days)

All the USB-A day's 'device specific fast charging' saw a lot of variations, none of them USB standards, and many of them too licensed to really become de facto standards either.

None would try to engage without being signaled (resistors or a protocol).

At least they gave us some options before Battery Charging or Power Delivery, which came later

Names seem to include

QuickCharge, QC (from Quallcomm)

Adaptive Fast Charging, AFC (from Samsung) (apparently based on Qualcomm Quick Charge?)

SuperCharge, SCP (from Huawei), apparently a successor to FastCharge Procotol, FCP

FastCharge Procotol, FCP (from Huawei)

Pump Express, PE (from Mediatek) (sometimes abbreviated MTK(verify))

TurboPower (from Motorola)

VOOC (from OPPO)[2], a.k.a. Dash Charge, in a few versions

SuperVOOC

SuperVOOC 2

PowerIQ (from Anker)

AiPower (from Aukey)

VoltIQ (from TronSmart)

iSmart (from RavPower)

...and more variations as well as various rebrands.

More on PD

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

PPS

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

AVS

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Using USB to charge batteries

In general, don't count on classical USB supplying more than 2.5W (standard)

...or 5W or 10W if slightly special (not so standard).

Since phones may have batteries on the order of 10Wh, that means charge will rarely take less than 4 hours - and easily double that when some part of the system is being careful

Since laptops have batteries on the order of ~100Wh, that means a charge would take dozens of hours -- which is why we, before USB-C, we didn't try to use USB to charge them

PC port limits

It's often mentioned that USB ports have a polyfuse - a physical component specced so that drawing more than e.g. 500mA will lead to that power being disconnected.

(There are other solutions. A few implementations actually monitor current, and use transistors to disconnect(verify), and in some rare cases the protection is missing)

Implementations play it a little wider than that, to avoid disconnecting devices due to transients and slight deviation -- because polyfuses may, by nature, not reset until power is removed, which is why you sometimes need to completely power off a computer (and sometimes even take the laptop's battery out) to get that port working again.

So USB2 polyfuses seem to have a trip current around 1.5A, and also a higher-than-500mA hold current (I've seen 750mA mentioned)

Roughly twice that for regular USB3 ports (ports can supply 0.9A as per specs)

More so for charging ports (how much?(verify)).

DIYers will know from trial and error that you can get away with just ignoring the intended negotiation and drawing 0.5A from a USB2 PC port without requesting it (0.9A from USB3 as per specs)

...because most hosts/hubs just assume USB devices act according to specs, they assume you would always ask not just draw it. And if you ever made your project into a product, it would need to actually request it to pass USB certification.

Note also that since you are defeating the thing that lets USB guarantee power to its devices, you may be able to cause all USB devices that sharing that power to brown out, something normally prevented by in-spec USB (at least in theory).

• https://en.wikipedia.org/wiki/USB#Power_related_specifications

• https://en.wikipedia.org/wiki/Quick_Charge

• https://learn.adafruit.com/minty-boost/icharging

• https://www.maximintegrated.com/en/app-notes/index.mvp/id/4803

Lower level USB

USB versions

• USB1 exists since 1996, 1.1 since 1998

only type A and type B plugs were technically in the specs

1.5 Mbps (Low speed) and 12 Mbps (Full speed)

• USB2 exists since 2000-ish

used roughly the same cabling (though specs are a little more demanding)

also started introduced various of the mini and micro connectors

adds 480 Mbps (High Speed)

• USB3 exists since 2008ish (USB3.1 since 2013, USB3.2 since 2017)

3.0 adds SuperSpeed at 5 Gbit/s,

3.1 adds SuperSpeed+ at 10 Gbit/s,

3.2 adds a flavour of SuperSpeed+ that does 20Gbit/s

often recognizable by the blue plastic in the plugs and sockets, or SS or SS+ (for Super Speed and its Plus variant, the modes that USB3 adds)

micro plugs/sockets are often not blue, possibly because it would be hard to see anyway(verify)), and because they're less ambiguous that PC-side A sockets

• USB4 exists since 2019

Note that the USB-C connector was a separate development. ...around the time that USB3 was developed so at the time we associated the two. But actually USB-C might carry USB1 (rare now), USB2 (more common than you might think), USB3, or USB4.

Pin-wise:

• USB1 and USB2 were four pins:
  • power lines are 5V and ground
  • data is 3.3V differential

• USB micro has a fifth pin

This is OTG ID, and was used to signal device or host side

...when we started introducing things that could act as either host or device. Note that USB-C drops this and negotiates it over CC instead(verify)

• USB-3's 9-pin versions of A, B, micro, and more

...leaves all those four USB2 pins there that still speak USB2, and adds five pins to do most of the USB3 on:[3]

two differential pairs

and a ground

in fact, technically the USB3 part is entirely separated from USB2 part (great for backwards compatibility, though adds more footnotes about e.g. hub implementations)

(verify)

• USB-C is 24 pins, duplicated to be invertible (with some interesting details)

so roughly 10 different pins overall (six of which are in three pairs)

USB-C carries USB-3's functionality (including the physically separate USB-2?), but some some details differently

even if the pins are not strictly a superset of the 9 USB-3 pins

This also means that USB-C to USB-A adapters may be able to speak superspeed (though some are only wired for USB2 so High Speed) and do basic carging -- but nothing USB-C such as power delivery or alternate modes (or anything else that relies on CC or SBU pins).

Host hardware variants

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

You can think of HCI (Host Controller Interface) as a API of how an OS will communicate with a USB host device. Hardware and OSes think about backwards compatibility so this is mostly invisible to users.

HCI variants are not unique to a USB version, but each variant can be used to carry a set of USB specs, so it roughly seems that way.

Perhaps the USB2 situation helps illustrate this best: EHCI specced only USB2 high-speed, so hardware that supported USB2 and USB1 (basically everything) would actually present two controllers, and the OS spoke EHCI to one and OHCI/UHCI to the other.(verify)

xHCI seems designed to avoid this, and presents USB3, USB2, USB1 (and in future versions USB4) to the OS in a single interface.

it is relatively rate for e.g. motherboards might present its USB ports in both xHCI and older things, though it has some value for legacy support, especially early days

PC controllers will be one of

• OHCI (Open Host Controller Interface)
  • USB 1
  • Open standard

• UHCI (Universal Host Controller Interface)
  • USB 1
  • Proprietary standard
  • Intel and VIA are usually UHCI

• EHCI (Enhanced Host Controller Interface)
  • USB 2
  • public (open?) standard

• xHCI (eXtensible Host Controller Interface)
  • USB 3
  • in theory replaces OHCI, UHCI, and EHCI

See also:

• http://en.wikipedia.org/wiki/USB

Speeds

• USB1 "Low speed"
  • ~178KByte/s (1.5 Mbit/s) of wire speed, max max ~120KByte/s of carried data due to 8b/10b coding (not yet accounting for protocol overhead)
  • Meant for devices that will never need much speed, such as keyboards

• USB1 "Full speed"
  • 1.5MByte/s (12 Mbit/s) wire speed, ~1.2MByte/s of carried data

• USB2 "High speed"
  • 60MByte/s (=480Mbit/s) wire speed, ~48MByte/s carried data
  • expect no more than 30MByte/s, and 25MB/s is more common (apparently because of offloading(verify))

• USB3 "Superspeed+"
  • 625MByte/s (5Gbps) of wire speed, ~500MByte/s (4Gbps) carried data
  • Note: May do USB2 devices a little faster (as in, may reach 30-40MByte/s where many USB2 controller may stop at ~25MByte/s) (verify)
  • expect no more than ~400MB/s usually

• USB3.1 "Superspeed+"
  • 1250MByte/s (10Gbps) of wire speed, before 128b/132b coding, ~1200MByte/s (~9Gbps) carried
  • expect no more than ~900MByte/s usually

Notes:

• Hubs share speed

the scheduling is relatively fair

• PC USB ports often come as two ports side by side - which are typically on a hub, so share their speed

This means e.g. copying between two adjacent ports may happen at half the speed you expected.

• USB3 modes are full-duplex, everything before was half-duplex

• I'm ignoring USB4 for now

Spec stuff

https://www.beyondlogic.org/usbnutshell/usb1.shtml

On bandwidth and latency

Can we push USB latency lower?

More on scheduling

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

If you've looked at USB device interfaces at API level, you may have come across the distinction between:

• Control transfers

basically the "hi new device, let's talk about your time here" part

this can happen within milliseconds of the controller noticing it being plugged in

...but seems designed to not disturb isochronous

• Isochronous transfers

best-effort, no retries

tries to guarantee both bandwidth and timing

...by reserving time slots in the scheduling

...but there is a limit to this, so timing is still not a 100% guarantee

can schedule in terms of microframes

can be relatively bulky

• Interrupt transfers

guaranteed delivery, with retries

interrupt responses happen in immediate response to the poll

(if you understand what interrupt lines are, this is not that, arguably a misleading term)

roughly speaking, this is much like isochronous but without the scheduling guarantee

in USB2: it seems interrupt polls happen only at full-frame interval boundaries(verify), i.e. 1ms

in USB3: the frame/microframe distinction no longer really exists, so isochronous and interrupt can and frequently do work on the same interval(verify)

interrupts are only shedules if there is time left after all the scheduled isochronous stuff. This made more difference in USB2, but still applies in in USB3

• Bulk transfers

all responses still in response to polls

uses whatever bandwidth isn't reserved by isochronous or used by interrupt(verify)

can be relatively bulky

Alternate modes

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

For reference, USB-C has four differential high-speed pairs assigned to data transfers (in eight pins/wires). (Also, this is separate from the USB2 pair, but whenever you have need for USB3 speeds, you tend to ignore those)

Those are labeled for the direction they have in regular USB mode, those are TX1, RX1, TX2, RX2.

Talking USB3 is bidirectional, so will use a TX+RX combination.

(assume that people are not consistent about the wording - in particular, a pair can refer to the electronically-differential nature of each of those four, a TX and RX combination (technically a lane), or even use of both those lanes together in some of the higher-speed modes)

A good amount of the time, USB is spoken over one of the TX+RX lanes, leaving the other lane's two pairs

usable as the second land in some of the faster USB modes (USB 3.2 Gen 2x2 does two times 10 Gbps)

alt modes

Alternate modes means pushing something that isn't USB through USB-C cables.

negotiated by both sides (using the CC lines(verify))

They might also a RX for transfer.

This may more or less multiplex the electrical lines from another device onto the cable, such as

DisplayPort (perhaps most common),

Thunderbolt (which could tunnel multiple things over it - including DP), (does Apple do this a bunch?)

USB4 (mostly to have thunderbolt-like features)(verify)

ethernet(verify)

audio(verify)

anything custom that both sides agree on(verify)

USB sniffing

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

Software USB capture such as that by wireshark can only capture at (roughly) URB level(verify).

These are the final form of the transfers as seen by the USB stack, though not precisely the individual transaction packets of the protocol layer (verify).

For most "what is it actually communicating" needs, that is enough.

You probably only need on-the-wire sniffing when debugging a device you are making, or trying to fiure out low-level or timing or retransmission issues.

https://wiki.wireshark.org/CaptureSetup/USB

Hardware USB sniffers exist - essentially logic analyzers specialized in only USB.

There are some DIY variants of this that are almost as capable, see e.g.

https://www.downtowndougbrown.com/2023/08/building-alex-taradovs-open-source-usb-sniffer/

Related to programming

Can I give my DIY device a custom name?

✎ This article/section is a stub — some half-sorted notes, not necessarily checked, not necessarily correct. Feel free to ignore, or tell me about it.

tl;dr:

not really, at least not easily and probably not without paying

...with a few informal exceptions

To get it to look distinct, you would really need a distinct VID-and-PID, and registration of such.

This would mostly just matter to what is shown in device manager.

This might be nice for the convenience of admins.

Or, in theory, to avoid getting confused which of the many attached Arduinos you need to upload to, except that the name for a device is essentially settled by its VID and PID, so that won't work.

In Windows there is a registry trick to effectively override the name reported by a driver. (it so happens you don't need to alter the driver itself, just the INF around it[4] which is within reach. )

But this is not what you usually want - that would be for all devices that that driver applies to, so

won't help you e.g. distinguish one Arduino from another,

nor will it make your project look distinct on any other PC.

If you are a company

To start, yes,

• you can get a lot of USB-capable microcontrollers to communicate arbitrary VID and PID,
• you can register it somewhere (without necessarily paying a lot of money)

This still is only half the solution, because it is now a new, unknown device, and now you would have to supply drivers.

If you want automatic install in Windows, you have to deal with Microsoft driver certification[5].

This is probably only interesting for people who own a company and want to sell the result.

(Apple has similar checks, though there are a little lighter)

There's an inbetween if you can get people to accept your own custom drivers, but it is fidgety.

I have seen installers do this to their devices, but it is not without footnotes.