¿Por qué la longitud máxima del cable USB es más corta que en RS232?

La velocidad de transmisión es importante porque el USB es semidúplex: para transmitir una respuesta, el bus debe girarse y los datos deben transmitirse en la otra dirección. Así que el host envía datos y espera un acuse de recibo o una respuesta. Todas las transferencias son controladas por el anfitrión. El dispositivo entonces tiene un cierto tiempo (bastante corto) para responder. Este tiempo es aproximadamente el tiempo necesario para dos viajes de señal a lo largo de un cable de 5 m.

(No puedo encontrar referencias en este momento, pero los documentos de especificaciones relevantes son públicos)

Editar: gracias a psmears por encontrar esta sección

  

Cables y soluciones de larga distancia

     

1. ¿Por qué hay límites de longitud de cable y cuáles son?
  

A: La longitud del cable estaba limitada por una especificación de demora de cable de 26 ns a   Permitir que los reflejos se asienten en el transmisor antes del siguiente bit   fue enviado. Dado que el USB utiliza la terminación de fuente y los controladores de modo de voltaje,   Este tiene que ser el caso, de lo contrario los reflejos pueden acumularse y explotar.   el conductor. Esto no significa que el voltaje de línea se haya resuelto completamente por   el final del bit con el peor de los casos de subestimar. Sin embargo, hay   suficiente amortiguación al final del bit que el reflejo   La amplitud se ha reducido a niveles manejables. El cable de baja velocidad.   La longitud se limitó a 18 ns para mantener los efectos de la línea de transmisión desde   impactando señales de baja velocidad.

     

2. Quiero construir un cable de más de 5 metros, ¿por qué no funciona?
  

A: Incluso si violaste la especificación, literalmente no lo conseguiría mucho.   lejos. Suponiendo tiempos de demora en el peor de los casos, un dispositivo de velocidad completa en el   La parte inferior de 5 concentradores y cables tiene un margen de tiempo de espera de 280 ps. Reduciendo   este margen a 0 pps solo le daría 5 cm adicionales, lo cual es difícilmente   vale la pena.

Por lo tanto, mi respuesta es solo a la mitad: el límite de ida y vuelta es para una cadena de hubs y cables en el peor de los casos, para una profundidad total de 25 m.

Dan Neely también tiene razón en que se suponía que el USB era la solución de menor costo para periféricos "lentos" como teclados, ratones, impresoras, etc. Si desea dúplex completo para más velocidad y más La distancia, 100baseT Ethernet es la elección natural.

Consulte esta página, enlace .

  

P1: ¿Cuánto tiempo de cable puedo usar para conectar mi dispositivo?   A1: En la práctica, la especificación USB limita la longitud de un cable entre dispositivos de velocidad máxima a 5 metros (un poco menos de 16 pies y 5 pulgadas). Para un dispositivo de baja velocidad, el límite es de 3 metros (9 pies y 10 pulgadas).

     

P2: ¿Por qué no puedo usar un cable de más de 3 o 5 m?   A2: el diseño eléctrico del USB no lo permite. Cuando se diseñó el USB, se tomó la decisión de manejar la propagación de campos electromagnéticos en las líneas de datos USB de una manera que limitaba la longitud máxima de un cable USB a algo en el rango de 4 m. Este método tiene varias ventajas y, como el USB está destinado a un entorno de escritorio, las limitaciones de rango se consideraron aceptables. Si está familiarizado con la teoría de la línea de transmisión y desea obtener más detalles sobre este tema, consulte la sección de señales USB de las preguntas frecuentes de los desarrolladores.

Realmente no es posible "almacenar" USB, al menos no en el sentido habitual de la palabra. Típicamente, el almacenamiento en búfer significa amplificación eléctrica y quizás regeneración de señal.

Con USB, el host controla la totalidad del bus. Un host envía una solicitud y el dispositivo tiene que emitir una respuesta al host. El inicio de la respuesta debe llegar al host un cierto tiempo después de que la solicitud haya terminado de transmitir. Con un cable demasiado largo, el retraso de propagación es demasiado largo para que la respuesta llegue al host a tiempo.

Por lo tanto, hay soluciones alternativas, y ninguna de ellas implica un simple "almacenamiento en búfer", ya que el almacenamiento en búfer agrega demoras adicionales, y debemos hacer que el host sea más tolerante a una mayor demora.

Hay dos clases de soluciones:

1. Soluciones alternativas que insertan centros físicos o virtuales. Si un host enumera un concentrador en el bus, el concentrador agrega un retraso adicional, y hay otro cable potencialmente de longitud completa entre el concentrador y el host. Todas las solicitudes de dispositivos que se conectan en sentido descendente desde el concentrador se programan con demoras adicionales.

   1. Puede insertar un concentrador de un solo puerto cada 4 m del cable, con hasta 7 concentradores en serie. La limitación es de 7 niveles de concentradores desde el host hasta el dispositivo final, por lo que si hay algún concentrador aguas arriba de su dispositivo, debe reducir la cantidad de concentradores en consecuencia. Muchos hosts USB incluyen un concentrador interno de un solo nivel, por lo que un límite realista sería de 28 m de cable, con 6 concentradores en serie. Todos los concentradores, excepto el primero, deberán pretender ser autoalimentados.

   2. Puede agregar concentradores virtuales, con un transceptor más robusto con énfasis previo, justo en el enchufe que va al host, y luego transmitir el tráfico USB a través de un cable más largo. Siempre que las señales recibidas por el dispositivo al final de dicho cable extendido estén dentro de las especificaciones, y siempre que su receptor pueda recuperar los datos enviados por el dispositivo estándar a través de un cable largo, estará bien. Los centros virtuales se agregan para que el servidor permita la demora prolongada, pero, por supuesto, no hay centros físicos, solo una suplantación de ellos.

2. Soluciones provisionales que emulan un dispositivo que aparece "lento" en un nivel más alto de protocolo. Así es como funcionan algunos "extensores" USB Cat-5. Aquí hay cinco socios: el host real (rHost), un dispositivo emulado visto por él (eDev), un cable largo, un host emulado (eHost) y los dispositivos que lo ven en el extremo más alejado del cable (rDev) .

   Inicialmente, el eDev pretende no estar allí. En algún momento, el eHost ve que se conectó un rDev. Lo enumera y reenvía los datos al eDev. El eDev luego emula un evento de plug-in, y el rHost lo enumera. El rHost cree que ve rDev, pero es solo eDev estar allí, fingiendo. De manera similar, el rDev piensa que es un rHost, pero es solo un eHost que está allí, fingiendo.

   Finalmente, el rHost desea emitir algunas transferencias al rDev que cree que está ahí, para hacer un uso del mismo. Para las transferencias IN, el eDev pretende no tener datos (responde con un NAK). La solicitud de transferencia se reenvía al eHost, que se vuelve a ejecutar con rDev. Los resultados de esto se reenvían a eDev, que utiliza los resultados la próxima vez que el host intente la transferencia.

   Para las transferencias OUT, el eDev tiene que adivinar cuál sería el comportamiento de rDev. Hay varias heurísticas y comportamientos que pueden intentarse aquí. Una forma es que eDev siempre reciba los datos y responda con un ACK. La transferencia se reenvía a eHost, que luego reproduce la transferencia a rDev. Idealmente, rDev eventualmente consumirá los datos y los ACK. Si esto no tiene éxito, o si rDev responde con STALL, lo mejor que puede hacer eDev es actuar de esta manera en la próxima transferencia desde el host. Alternativamente, el eDev puede NAK siempre la transferencia, con la suposición generalmente correcta de que el host simplemente volverá a intentar la transferencia idéntica más tarde. A pesar de que la transferencia original fue NAK-ed, se reenvía a eHost, que luego ejecuta la transferencia con rDev. Cualquiera que sea la respuesta de rDev, se convierte en la respuesta del eDev tan pronto como se entera de ello.

   Las implementaciones realistas comenzarán con heurísticas conservadoras que implican un viaje de ida y vuelta completo a rDev para todas las transferencias que un NAK pueda posponer. A medida que avanzan las transferencias, se puede aprender el comportamiento esperado de rDev, y eDev puede volverse menos conservador. El "extensor" puede usar el conocimiento de las clases USB estándar, y algunos conocimientos de clase / dispositivo / listas negras / listas blancas específicas del proveedor también ofrecen un mejor rendimiento.

La mayoría de los esquemas de transmisión de datos a través de cable tienen un estándar decente reconocido internacionalmente que describe cómo implementarlos, incluida una especificación para la "impedancia característica" del cable (piense en esto como resistencia, pero se aplica a CA), terminación impedancia (la "resistencia" al final de la conexión que se necesita para evitar los reflejos de su señal que rebota el cable hacia el remitente), a menudo una "velocidad de respuesta" especificada (el tiempo que tarda la señal en recibir). Transición de un estado 0 a un estado 1 o viceversa, y por lo tanto el número máximo de transiciones entre 0/1 por segundo (es decir, kbps / Mbps / Gbps), y por lo tanto, cuánto tiempo puede durar el cable antes de la señal la integridad se degrada & Las cosas dejan de funcionar bien.

En comparación con USB, RS232 tiene especificación sobre el tipo de cable, la impedancia característica, la velocidad de giro, la longitud del cable, el tipo de conector. Claro, 25 pines y amp; Los conectores 'D' de 9 pines eran comunes, pero en realidad RS232 fue diseñado para todo tipo de connenctors & cables y amp; Productos sin especificación real para decir lo contrario. En la práctica, con RS232, por lo general, puede recorrer distancias más largas al disminuir a una velocidad de bits por segundo (también conocida como "baudios"). La distancia máxima que puede alcanzar también se determinará, en gran parte, en la impedancia de su cable, ya sea que esté o no blindado, la terminación al final, y así sucesivamente.

y al comparar RS232 con USB, estás comparando un 'estándar' de la década de 1960 que alcanzó casi 115k2 (con raras excepciones), con uno de la década de 1990 & 2000s que comenzó a 1.5Mbps, un orden de magnitud más rápido, luego 12Mbps (casi 100 veces más rápido), luego 480Mbps (casi 5000x más rápido), pero eso significó que los parámetros y la longitud del cable jugaron un papel importante en Haciéndolo funcionar confiablemente . Fue diseñado como un estándar de conexión periférica de escritorio, por lo que se consideró aceptable 5 m, y luego todos los parámetros de los cables y amp; conectores y amp; Las velocidades se establecieron desde ese punto. Si hubiera una manera de hacer que el USB se vuelva más lento, probablemente podría hacerlo funcionar con cables más largos (sin un repetidor).