Low Speed (LS)

Module 4 explained why USB accumulated several signalling capabilities and showed that which one a connection runs is an intersection rather than a label. Module 3 explained how a device announces which of two it wants and how a third is established.

What neither answered is the question this module exists for: what does it actually mean to operate in a given mode?

The answer is more interesting than a rate, and Low Speed is the best place to see why — because Low Speed differs from its neighbours in ways that have nothing to do with how fast it is.

1. A Mode Is an Envelope, Not a Number

Here is the idea the whole module is built on, stated once and then used everywhere.

An operating mode is a bundle of commitments that go together. A rate is one of them — the most visible and the least interesting. The bundle also fixes what the electrical layer must do, what a packet may be, which kinds of transfer are permitted, and what an implementation on either end must provide.

Those commitments are mutually supporting. A mode's rate is low because its electrical requirements are relaxed; its electrical requirements are relaxed because the devices it serves are cheap; the devices are cheap because the mode asks little of them. Pull one commitment out of the bundle and the others stop making sense.

So the productive question about any mode is not how fast is it but what does it let you get away with, and what does it forbid? Low Speed answers both unusually clearly.

2. What Low Speed Relaxes

Start with what the mode buys, since that is why it exists.

A nominal signalling rate of 1.5 Mbit/s. Note the unit — this is a signalling rate, bits per second on the wire, and Chapter 4.6 §4 established why that is not the same thing as payload or application throughput. The same caution applies to every figure in this module and will not be repeated.

Relaxed edge rates. A slower signalling rate permits — and per Chapter 3.8 §1 requires — slower transitions. That is not a minor consequence: slower edges radiate less, reflect less and crosstalk less, which means the cable and connector requirements are gentler. Low-Speed cabling can be cheaper and less carefully constructed than a faster mode would tolerate.

A simpler device. A device operating here needs less capable analogue circuitry, can be clocked more slowly, and needs less buffering — because the mode will never ask it to sustain a high rate.

Those three are one argument. The mode exists so that a keyboard, a mouse or a simple control device can be built cheaply, attach to the same architecture as everything else, and work — which is the universality promise of Chapter 1.7 applied to the low end of the market.

3. What Low Speed Forbids

Now the part that makes this a mode rather than a setting, and the part most treatments omit entirely.

Only two of the four transfer types are permitted. A Low-Speed device may use control and interrupt transfers. It may not use bulk or isochronous transfers. That is an architectural restriction, not a performance observation — the mode forbids them.

Packets are small. The maximum payload a Low-Speed data packet may carry is markedly smaller than the faster modes permit, which bounds what a single exchange can move regardless of how often exchanges happen.

Cable length is more limited, following from the relaxed electrical requirements — a mode designed around cheap cabling cannot also claim the reach that better cabling would buy.

And a Low-Speed device is not simply attached to a faster bus. A hub serving it must handle the speed difference, which is the transaction-translator arrangement Chapter 4.2 §3 identified as the compatibility bill of the second generation.

Module 10 owns the transfer types themselves — what control and interrupt transfers are, what bulk and isochronous do, and why a device would want each. What belongs here is the mode's restriction, because it is the sharpest possible illustration that a mode constrains architecture and not merely timing. A device designer choosing Low Speed is not choosing a speed; they are choosing a capability set.

4. Why the Restrictions Are Coherent

The forbidden transfer types are not an arbitrary exclusion, and seeing why is the chapter's engineering payoff.

Isochronous transfers exist to deliver data at a guaranteed rate for things like audio. Guaranteeing a rate requires reserving bus capacity, and reserving meaningful capacity out of 1.5 Mbit/s for a device class that does not need it would be a poor trade. More fundamentally, the devices Low Speed was designed for have no isochronous traffic — a keyboard does not stream.

Bulk transfers exist to move large quantities opportunistically, using whatever capacity is left over. On a mode this slow, "large quantities" is not a meaningful proposition, and the devices in the envelope do not have them.

Interrupt transfers, by contrast, are exactly what the envelope's devices need: small amounts of data, delivered with bounded latency, when something happens. A keystroke is precisely that.

And control transfers are mandatory for every device, because that is how Chapter 2.2's device model works — a device must be configurable, and configuration travels on control transfers. No mode may forbid them.

So the restriction is the envelope being internally consistent: the mode permits exactly what its devices need and forbids what they would never use and could not afford. That is good design rather than a limitation, and it is why §1 insisted the commitments are mutually supporting.

5. What This Means for an Implementation

For a device, choosing this envelope is a commitment that reaches into the design. The analogue requirements are lighter, the clocking is slower, and the buffering is smaller — but the device also must not attempt what the mode forbids, and its descriptors must declare an envelope it can actually honour. Chapter 4.7 §6's over-claiming bug has a version here: a device declaring capability it cannot sustain.

For a host controller, supporting Low Speed is not free even though the mode is slow. The controller must keep timing appropriate to the mode, must know which transfer types are legal for a given device, and must handle the mode in a datapath shared with much faster traffic. Slow does not mean cheap to support — the support costs structure rather than throughput, which is Chapter 4.2 §4's observation applied to the slowest mode.

For a hub, Low Speed is the expensive case. It is the mode that makes speed-bridging logic necessary, and it is served through a different path than a same-speed device would be.

The state a design must hold is small but specific: which mode this port is operating in, and — because the mode restricts what is legal — enough of the envelope to reject what is not. A controller that knows the rate but not the restrictions can be asked to do something illegal and will not know.

6. Verification

Stimulus. A Low-Speed device model, attached directly and behind a hub — the second being the configuration that exercises the speed-bridging path, and the one a bench setup rarely constructs.

Observation. The active mode, read from where the controller reports it rather than from what the test configured. Chapter 5.3 develops this distinction properly; even here it matters, because a test that assumes Low Speed became active has not checked.

Checking. Mode-appropriate behaviour: timing consistent with the mode, packet sizes within the envelope, and — the interesting one — rejection of what the mode forbids.

Negative testing is unusually productive for this mode, because the restrictions give you specific illegal things to attempt: a bulk transfer to a Low-Speed device, an oversized packet, an isochronous endpoint declared by a Low-Speed device. Correct behaviour is refusal, and refusal paths are exactly what a test plan built around working configurations never contains.

Representative coverage dimensions — a method, not a plan:

• Low-Speed device attached directly × attached behind a hub of each capability
• permitted transfer types exercised × forbidden types attempted and refused
• packet sizes at and beyond the envelope's limit
• a Low-Speed device active while faster devices share the same hub

That last cross is worth emphasising: it is where the speed-bridging logic is genuinely exercised, and it is the configuration real users create immediately.

7. Common Misconceptions

8. Reason It Through

A device designer wants a low-cost sensor that reports readings continuously and proposes operating it at Low Speed to save component cost.

Is the rate sufficient? Possibly — a sensor producing small readings may fit comfortably within 1.5 Mbit/s, and a rate calculation alone would say yes.

Is the envelope appropriate? That is the real question, and it depends on what continuously means. If readings are events — something changed, here is a value — then interrupt transfers fit and the envelope is right. If the sensor streams at a fixed rate and the receiver needs delivery paced to that rate, the natural transfer type is isochronous, which this mode forbids. No amount of available bandwidth changes that.

What if the designer tries anyway? The device cannot declare an isochronous endpoint in this mode and remain conforming, so either the design changes or the mode does. A device that declares one anyway is the over-claiming failure of Chapter 4.7 §6 — it may be accepted and then behave badly.

What is the correct decision procedure? Check the envelope before the rate. Determine which transfer type the traffic actually needs, confirm the mode permits it, and only then ask whether the rate suffices. Doing it the other way round produces a design that is fast enough and structurally illegal.

The general lesson. Bandwidth sufficiency does not imply mode suitability. A mode is a capability set, and the binding constraint is frequently one of its restrictions rather than its rate.

9. Understanding Check

10. Summary

An operating mode is an envelope, not a number. It bundles a signalling rate with electrical requirements, permitted transfer types, packet limits and reach — and the commitments are mutually supporting, so pulling one out makes the others incoherent.

Low Speed relaxes: a nominal 1.5 Mbit/s signalling rate, slower edge rates that make cabling and connectors cheaper, and a device that needs less analogue capability, slower clocking and less buffering.

It forbids: bulk and isochronous transfers, permitting only control and interrupt; markedly smaller packets; and a shorter reach. These are architectural restrictions, and they are coherent — the mode permits exactly what its devices need and excludes what they would never use and could not afford, with control permitted because no mode may forbid configuration.

For implementations, slow is not cheap to support. The cost is structural: mode-appropriate timing, knowledge of what is legal, and a shared datapath — plus the speed-bridging logic hubs must carry.

For verification, the restrictions make negative testing unusually productive, because there are specific illegal actions whose correct outcome is refusal, and refusal paths are the least-exercised logic in any implementation.

And the decision rule: bandwidth sufficiency does not imply mode suitability. Check which transfer type the traffic needs and whether the mode permits it before checking the rate.

11. What Comes Next

Low Speed is the clearest case because its restrictions are the most visible. It is not, however, the reference point — it is a deliberately narrowed version of something.

Chapter 5.2 takes Full Speed, which is the baseline the architecture was designed around and against which Low Speed is a reduction. The comparison is where the envelope idea becomes properly useful: the two modes share a great deal — the same conductors, the same signalling framework, the same device model — and differ in a small number of specific commitments. Seeing exactly which commitments differ, and which do not, is what turns envelope from a metaphor into something you can reason with.

Browse the full path on the USB tutorials index.