9
\$\begingroup\$

Why do we need to buffer USB signal if the cable is longer than 5m?
Is that because a signal voltage drop?
Is that because it drives currents?

\$\endgroup\$
  • 1
    \$\begingroup\$ Rs232 uses +/-12 Volt, USB 0-5 volt \$\endgroup\$ – mischnic Apr 28 '15 at 20:07
16
\$\begingroup\$

Speed of transmission matters because USB is half-duplex: in order to transmit a response, the bus must be turned around and data transmitted in the other direction. So the host sends out data and waits for an acknowledgement or a response. All transfers are controlled by the host. The device then has a certain (fairly short) time in which to respond. This time is roughly the time taken for two signal trips along a 5m cable.

(I can't find references right this second, but the relevant spec documents are public)

Edit: thanks to psmears for finding this section

Cables and Long-Haul Solutions

  1. Why are there cable length limits, and what are they?

A: The cable length was limited by a cable delay spec of 26ns to allow for reflections to settle at the transmitter before the next bit was sent. Since USB uses source termination and voltage-mode drivers, this has to be the case, otherwise reflections can pile up and blow the driver. This does not mean the line voltage has fully settled by the end of the bit; with worst-case undertermination. However, there's been enough damping by the end of the bit that the reflection amplitude has been reduced to manageable levels. The low speed cable length was limited to 18ns to keep transmission line effects from impacting low speed signals.

  1. I want to build a cable longer than 5 meters, why won't this work?

A: Even if you violated the spec, it literally wouldn't get you very far. Assuming worst-case delay times, a full speed device at the bottom of 5 hubs and cables has a timeout margin of 280ps. Reducing this margin to 0ps would only give you an extra 5cm, which is hardly worth the trouble.

So my answer is only half-right: the round trip limit is for a worst-case chain of hubs and cables, for a total depth of 25m.

Dan Neely is also right that USB was always supposed to be the lowest-cost solution for "slow" peripherals like keyboards, mice, printers etc. If you wanted full duplex for more speed and more distance, 100baseT ethernet is the natural choice.

\$\endgroup\$
  • \$\begingroup\$ hat is one makes a 20m USB cable. what would happen? you say the voltage doesnt change and speed matters. so what happens in 20m cable case and USB doesnt work? \$\endgroup\$ – user16307 Apr 28 '15 at 11:49
  • 2
    \$\begingroup\$ The host sends out a request, doesn't get a reply in time, and fails to enumerate the device on the other end. \$\endgroup\$ – pjc50 Apr 28 '15 at 12:38
  • 4
    \$\begingroup\$ Are you sure about this? As per the USB spec, the propagation delay of the signal along the cable must be <26ns (table 7-9), so the signal takes less than 5.2 ns/m in a standard 5m cable. The limit for the round-trip delay is about 1.5 μs. At that speed there's plenty of time for the signal to travel out and back over a cable of >100m. The USB Implementers Forum gives a different reason for the 5m limitation. \$\endgroup\$ – psmears Apr 28 '15 at 16:15
  • \$\begingroup\$ Is there any reason for USB 1.0-2.0 to be half-duplex instead of full duplex since day one (like USB 3.0) ? In other words is there any practical advantages of half over full duplex ? \$\endgroup\$ – tigrou Apr 28 '15 at 16:31
  • 1
    \$\begingroup\$ @tigrou more broadly USB1 embraced simple options everywhere it could because it needed to be cheap enough to implement that it could compete out RS232/PS2/LPT/Game ports. Silicon has gotten a lot cheaper over the years; but having a price higher than the minimum needed to be 'good enough' for the targeted applications resulted in USB2 killing FireWire; and Thunderbolt increasingly appearing to be stillborn. \$\endgroup\$ – Dan Neely Apr 28 '15 at 18:13
10
\$\begingroup\$

See this page, https://superuser.com/questions/64744/maximum-length-of-a-usb-cable.

Q1: How long of a cable can I use to connect my device? A1: In practice, the USB specification limits the length of a cable between full speed devices to 5 meters (a little under 16 feet 5 inches). For a low speed device the limit is 3 meters (9 feet 10 inches).

Q2: Why can't I use a cable longer than 3 or 5m? A2: USB's electrical design doesn't allow it. When USB was designed, a decision was made to handle the propagation of electromagnetic fields on USB data lines in a way that limited the maximum length of a USB cable to something in the range of 4m. This method has a number of advantages and, since USB is intended for a desktop environment, the range limitations were deemed acceptable. If you're familiar with transmission line theory and want more detail on this topic, take a look at the USB signals section of the developers FAQ.

\$\endgroup\$
  • 1
    \$\begingroup\$ still doesnt explain anything a lot of foggy information \$\endgroup\$ – user16307 Apr 28 '15 at 11:44
  • 10
    \$\begingroup\$ Might be foggy to you, but there is no easy way to explain signal theory in the room this format allows. \$\endgroup\$ – Wouter van Ooijen Apr 28 '15 at 13:12
  • 5
    \$\begingroup\$ I think that this answer points out certain reasons why the limitations are there. It is quite easy to further explore these areas by doing a web search. For example on transmission line theory. That is why I posted this answer. \$\endgroup\$ – Mattias Johansson Apr 28 '15 at 13:44
  • 1
    \$\begingroup\$ I rarely downvote, so I feel compelled to justify it now. Contrary to the comment of Wouter van Ooijen, I really do not feel that this answer provides anything more concrete than a possible suggestion to search on "USB cable length limitation". Additionally, the answer you refer to contains a dead link and so its suggestion for further reading is not even that useful. If you had found the correct original source and quoted from that, as psmears and pjc50 did, it would be a different matter--because that actually provides details of why this limitation exists. \$\endgroup\$ – Oleksandr R. Jun 13 '15 at 16:39
5
\$\begingroup\$

It's not really possible to "buffer" USB, at least not in the usual sense of the word. Typically, buffering means electrical amplification and perhaps signal regeneration.

With USB, the host drives the entirety of the bus. A host sends out a request, and the device has to issue a response to the host. The beginning of the response has to arrive at the host a certain time after the request has finished transmitting. With too long of a cable, the propagation delay is too long for the response to reach the host in time.

So there are workarounds, and none of them involve simple "buffering" since the buffering adds additional delays, and we need to somehow make the host more tolerant of a longer delay.

There are two classes of workarounds:

  1. Workarounds that insert physical or virtual hubs. If a host enumerates a hub on the bus, the hub itself adds an extra delay, and there's another potentially full-length cable between the hub and the host. Any requests for devices that attach downstream from the hub are scheduled with additional delays.

    1. You can insert a single-port hub every 4m of the cable, with up to 7 hubs in series. The limitation is 7 levels of hubs from the host to the ultimate device, so if there are any hubs upstream of your contraption, you need to reduce the number of hubs accordingly. Many USB hosts include a single-level of internal hub, so a realistic limit would be 28m of cable, with 6 hubs in series. All hubs but the first one will have to pretend to be self-powered.

    2. You can add virtual hubs, with a beefier transceiver with preemphasis, right at the plug that goes into the host, then transmit USB traffic over a longer cable. As long as the signals received by the device at the end of such an extended cable are within spec, and as long as your receiver can recover the data sent by the standard device over a long cable, you'll be OK. The virtual hubs are added so that the host allows the long delay - but of course there are no physical hubs, just an impersonation of them.

  2. Workarounds that emulate a device that appears "slow" at a higher level of protocol. That's how some Cat-5 USB "extenders" work. There are five partners here: the real host (rHost), an emulated device seen by it (eDev), a long cable, an emulated host (eHost), and the devices that see it at the far end of the cable (rDev).

    Initially, the eDev pretends not to be there. At some time the eHost sees that an rDev was plugged in. It enumerates it, and forwards the data to the eDev. The eDev then emulates a plug-in event, and the rHost enumerates it. The rHost believes that it sees rDev, but it's only eDev being there, pretending. Similarly, the rDev thinks that is sees an rHost, but it's only an eHost being there, pretending.

    Eventually, the rHost wants to issue some transfers to the rDev it believes is there, to make some use of it. For IN transfers, the eDev pretends to have no data (replies with a NAK). The transfer request is forwarded to the eHost, which re-executes it with rDev. The results of this are forwarded back to eDev, which uses the results the next time the host attempts the transfer.

    For OUT transfers, the eDev has to guess as to what the behavior of rDev would be. There are various heuristics and behaviors that can be attempted here. One way is for eDev to always receive the data and reply with an ACK. The transfer is forwarded to eHost, which then replays the transfer to rDev. Ideally, rDev will eventually consume the data and ACK it. If this doesn't succeed, or if the rDev replies with a STALL, the best the eDev can do is act this way on the next transfer from the host. Alternatively, the eDev can always NAK the transfer, with the usually correct assumption that the host will simply re-try the identical transfer later. Even though the original transfer was NAK-ed, it is forwarded to eHost, which then executes the transfer with rDev. Whatever rDev's reply is, becomes the reply of the eDev as soon as it learns of it.

    Realistic implementations will start with conservative heuristics that involve full roundtrip to rDev for all transfers that can be postponed by a NAK. As the transfers proceed, rDev's expected behavior can be learned, and eDev can become less conservative. The "extender" can use the knowledge of standard USB classes, and some vendor-specific class/device knowledge/blacklists/whitelists to offer better performance as well.

\$\endgroup\$
  • \$\begingroup\$ Couldn't alternate hubs pretend to be bus-powered? I think a bus-powered hub can power a self-powered hub, can it not? \$\endgroup\$ – supercat Apr 28 '15 at 17:00
  • \$\begingroup\$ Nothing to do with bus-powered - it's the total delay in response to an ACK. \$\endgroup\$ – pjc50 Apr 28 '15 at 22:16
  • \$\begingroup\$ @supercat Yes, there could be alternate pretend hubs. It doesn't matter how you do it, as long as the pretend device tree appears compliant to the host. \$\endgroup\$ – Kuba Ober Apr 30 '15 at 14:17
  • \$\begingroup\$ @pjc50 according to USB spec the maximum ACK delay is about 400ns. The time signal can travel 40 meters of copper in both directions. It is not a limiting factor here. \$\endgroup\$ – ZAB Dec 12 '16 at 14:43
  • 1
    \$\begingroup\$ @ZAB See usb.org/developers/usbfaq/#cab1 \$\endgroup\$ – pjc50 Dec 12 '16 at 15:55
2
\$\begingroup\$

Most data-transmission-over-cable schemes have a decent internationally recognised standard describing how to implement them, including a specification for the "characteristic impedance" of the cable (think of this as resistance, but applies to AC), termination impedance (the 'resistance' at the end of the connection that's needed to avoid reflections of your signal bouncing back up the cable back toward the sender), often a specified 'slew rate' (the time it takes for the signal(s) to transition from a 0-state to a 1-state or vice-versa), and hence the maximum number of transitions between 0/1 per second (i.e. the kbps / Mbps / Gbps), and hence how long the cable can be before signal integrity degrades & stuff stops working right.

Compared to USB, RS232 has bugger all specification on cable type, characteristic impedance, slew rate, cable length, connector type. Sure, 25-pin & 9-pin 'D' connectors were common, but in reality RS232 was designed into all sorts of connenctors & cables & products with no real specification to say otherwise. In practise, with RS232 you can usually go longer distances by dropping to a lower bits-per-second (aka 'baud') rate. The maximum distance you can achieve will also be determined in significant part on the impedance of your cable, whether or not it's shielded, termination at the end, and so on.

and in comparing RS232 to USB, you're comparing a 'standard' from the 1960s that pretty much topped out at 115k2 (with rare exceptions), with one from the 1990s & 2000s that started at 1.5Mbps, an order of magnitude faster, then 12Mbps (nearly 100x faster), then 480Mbps (nearly 5000x faster), but which meant that cable parameters and cable length played an important part in making it work reliably. It was designed as a desktop peripheral connection standard, so 5m was deemed acceptable, and then all the parameters of the cables & connectors & speeds was laid down from that point. If there was a way to make USB go slower, you could probably make it run on longer cables (without a repeater).

\$\endgroup\$
  • 2
    \$\begingroup\$ RS232 may have "topped out" at 115K, but I remember when it was a 110 or 300 bit per second link between a teleprinter and a modem. The signals were unbalanced, the voltage swung from -12V to +12V, and there was no twisted pair or termination or shielding. At that speed, and over such short distances, the characteristics of the wire meant nothing. Later, when people wanted to send at higher speeds over hundreds of meters, we got RS422 and RS485 which said a lot more about the wire-as-transmission line. \$\endgroup\$ – Solomon Slow Apr 28 '15 at 19:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.