¿Por qué la longitud máxima del cable USB es más corta que en RS232?
9
¿Por qué necesitamos almacenar en búfer la señal USB si el cable tiene más de 5 m?
¿Es eso debido a una caída de voltaje de señal?
¿Es eso porque impulsa las corrientes?
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. Entonces el host envía datos y espera un acuse de recibo o una respuesta. Todas las transferencias son controladas por el host. El dispositivo tiene un cierto tiempo (bastante corto) para responder. Esta vez es más o menos 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
¿Por qué hay límites de longitud de cable y cuáles son?
R: La longitud del cable estaba limitada por una especificación de retraso de cable de 26 ns para permitir que las reflexiones se establecieran en el transmisor antes de que se enviara el siguiente bit. Dado que USB utiliza terminación de fuente y controladores de modo de voltaje, este tiene que ser el caso, de lo contrario los reflejos pueden acumularse y volar el controlador. Esto no significa que el voltaje de línea se haya estabilizado completamente al final del bit; con el peor de los casos de infradeterminación. Sin embargo, ha habido suficiente amortiguación al final del bit que la amplitud de reflexión se ha reducido a niveles manejables. La longitud del cable de baja velocidad se limitó a 18ns para evitar que los efectos de la línea de transmisión afecten las señales de baja velocidad.
Quiero construir un cable de más de 5 metros, ¿por qué no funciona?
R: Incluso si violaste la especificación, literalmente no te llevaría muy lejos. Suponiendo los tiempos de retraso en el peor de los casos, un dispositivo de velocidad completa en la parte inferior de 5 concentradores y cables tiene un margen de tiempo de espera de 280ps. Reducir este margen a 0ps solo le daría 5 cm adicionales, lo que difícilmente vale la pena.
Entonces, mi respuesta es solo la mitad correcta: 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 es también justo que el USB se suponía siempre a ser la solución más económica para los periféricos "lentos" como teclados, ratones, impresoras, etc Si usted quería dúplex completo para más velocidad y más distancia, Ethernet 100BaseT es la elección natural.
Este es un cable USB de 20 m. ¿qué pasaría? Dices que el voltaje no cambia y la velocidad importa. Entonces, ¿qué sucede en la caja del cable de 20 my el USB no funciona?
user16307
2
El host envía una solicitud, no recibe una respuesta a tiempo y no puede enumerar el dispositivo en el otro extremo.
pjc50
44
¿Estas seguro acerca de esto? Según la especificación USB , el retraso de propagación de la señal a lo largo del cable debe ser <26ns (tabla 7-9), por lo que la señal tarda menos de 5.2 ns / m en un cable estándar de 5m. El límite para el retraso de ida y vuelta es de aproximadamente 1,5 μs. A esa velocidad, hay tiempo de sobra para que la señal salga y regrese por un cable de> 100 m. El USB Implementers Forum ofrece una razón diferente para la limitación de 5 m.
psmears
¿Hay alguna razón para que USB 1.0-2.0 sea half-duplex en lugar de full duplex desde el primer día (como USB 3.0)? En otras palabras, ¿hay alguna ventaja práctica de la mitad sobre el dúplex completo?
tigrou
1
En general, @tigrou USB1 adoptó opciones simples en todas partes porque podía ser lo suficientemente barato como para implementarlo y poder competir con los puertos RS232 / PS2 / LPT / Game. El silicio se ha vuelto mucho más barato con los años; pero tener un precio más alto que el mínimo necesario para ser "lo suficientemente bueno" para las aplicaciones específicas dio como resultado que USB2 matara FireWire; y Thunderbolt parece cada vez más nacido muerto.
P1: ¿Cuánto 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 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ñó USB, se tomó la decisión de manejar la propagación de campos electromagnéticos en líneas de datos USB de una manera que limitara la longitud máxima de un cable USB a algo en el rango de 4 m. Este método tiene una serie de ventajas y, dado que 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 más detalles sobre este tema, eche un vistazo a la sección de señales USB de las Preguntas frecuentes de los desarrolladores.
Puede ser confuso para usted, pero no hay una manera fácil de explicar la teoría de la señal en la sala que permite este formato.
Wouter van Ooijen
55
Creo que esta respuesta señala ciertas razones por las cuales existen limitaciones. Es bastante fácil explorar más estas áreas haciendo una búsqueda en la web. Por ejemplo en teoría de líneas de transmisión. Por eso publiqué esta respuesta.
Mattias Johansson
1
Raramente rechazo, así que me siento obligado a justificarlo ahora. Contrariamente al comentario de Wouter van Ooijen, realmente no creo que esta respuesta proporcione nada más concreto que una posible sugerencia para buscar en "Limitación de la longitud del cable USB". Además, la respuesta a la que se refiere contiene un enlace muerto y, por lo tanto, su sugerencia para una lectura adicional ni siquiera es tan útil. Si hubiera encontrado la fuente original correcta y citado a partir de eso, como lo hicieron psmears y pjc50, sería un asunto diferente, porque eso realmente proporciona detalles de por qué existe esta limitación.
Oleksandr R.
5
Realmente no es posible "almacenar" el 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 maneja la totalidad del bus. Un host envía una solicitud y el dispositivo debe emitir una respuesta al host. El comienzo de la respuesta debe llegar al host un cierto tiempo después de que la solicitud haya terminado de transmitirse. 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, existen soluciones alternativas, y ninguna de ellas implica un simple "almacenamiento en búfer", ya que el almacenamiento en búfer agrega retrasos adicionales, y necesitamos de alguna manera hacer que el host sea más tolerante a un retraso más largo.
Hay dos clases de soluciones alternativas:
Soluciones alternativas que insertan concentradores 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 hub se programan con demoras adicionales.
Puede insertar un concentrador de puerto único 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 concentradores antes 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.
Puede agregar concentradores virtuales, con un transceptor más robusto con énfasis previo, justo en el enchufe que va al host, luego transmitir el tráfico USB a través de un cable más largo. Mientras las señales recibidas por el dispositivo al final de dicho cable extendido estén dentro de las especificaciones, y mientras su receptor pueda recuperar los datos enviados por el dispositivo estándar a través de un cable largo, estará bien. Los concentradores virtuales se agregan para que el host permita el largo retraso, pero, por supuesto, no hay concentradores físicos, solo una suplantación de ellos.
Soluciones alternativas que emulan un dispositivo que parece "lento" en un nivel superior 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 otro extremo del cable (rDev) .
Inicialmente, el eDev finge 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 emula un evento de complemento y el rHost lo enumera. RHost cree que ve rDev, pero solo eDev está ahí, fingiendo. Del mismo modo, el rDev cree que se ve un rHost, pero es solo un eHost que está allí, fingiendo.
Eventualmente, el rHost quiere emitir algunas transferencias al rDev que cree que está allí, para usarlo. Para las transferencias IN, el eDev pretende no tener datos (responde con un NAK). La solicitud de transferencia se reenvía al eHost, que la 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 el rDev responde con un STALL, lo mejor que puede hacer el eDev es actuar de esta manera en la próxima transferencia desde el host. Alternativamente, el eDev siempre puede NAK la transferencia, con la suposición generalmente correcta de que el host simplemente volverá a intentar la transferencia idéntica más tarde. Aunque 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 de eDev tan pronto como se entera de ella.
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 puede 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 específicos de clase / dispositivo / listas negras / listas blancas del proveedor para ofrecer un mejor rendimiento también.
¿No podrían los centros alternativos pretender ser alimentados por bus? Creo que un concentrador alimentado por bus puede alimentar un concentrador autoalimentado, ¿no es así?
supercat
Nada que ver con el bus alimentado: es el retraso total en respuesta a un ACK.
pjc50
@supercat Sí, podría haber centros de simulación alternativos. No importa cómo lo haga, siempre y cuando el árbol del dispositivo de simulación parezca compatible con el host.
Vuelva a instalar Mónica
@ pjc50 según la especificación USB, el retraso máximo de ACK es de aproximadamente 400ns. La señal horaria puede viajar 40 metros de cobre en ambas direcciones. No es un factor limitante aquí.
La mayoría de los esquemas de transmisión de datos por 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), impedancia de terminación (la 'resistencia' al final de la conexión que es necesaria para evitar los reflejos de su señal rebotando por el cable hacia el emisor), a menudo una 'velocidad de respuesta' específica (el tiempo que tarda la señal (es) en pasar de una señal 0-state a 1-state 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 que la integridad de la señal se degrade y las cosas dejan de funcionar bien.
En comparación con USB, RS232 tiene todas las especificaciones del tipo de cable, impedancia característica, velocidad de respuesta, longitud del cable, tipo de conector. Claro, los conectores 'D' de 25 pines y 9 pines eran comunes, pero en realidad RS232 fue diseñado en todo tipo de conectores y cables y productos sin especificaciones reales para decir lo contrario. En la práctica, con RS232 generalmente puede recorrer distancias más largas cayendo 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 medida según la impedancia de su cable, si está blindado o no, la terminación al final, etc.
y al comparar RS232 con USB, está comparando un 'estándar' de la década de 1960 que superó prácticamente 115k2 (con raras excepciones), con uno de la década de 1990 y 2000 que comenzó a 1.5Mbps, un orden de magnitud más rápido, luego 12Mbps (casi 100x más rápido), luego 480Mbps (casi 5000x más rápido), pero eso significó que los parámetros y la longitud del cable desempeñaron un papel importante para que funcione de manera confiable . Fue diseñado como un estándar de conexión periférica de escritorio, por lo que 5m se consideró aceptable, y luego todos los parámetros de los cables y conectores y velocidades se establecieron desde ese punto. Si hubiera una manera de hacer que el USB sea más lento, probablemente podría hacerlo funcionar con cables más largos (sin repetidor).
RS232 puede haber "alcanzado" a 115K, pero recuerdo cuando era un enlace de 110 o 300 bits por segundo entre una teleimpresora y un módem. Las señales estaban desequilibradas, el voltaje pasó de -12V a + 12V, y no hubo par trenzado, ni terminación ni blindaje. A esa velocidad, y en distancias tan cortas, las características del cable no significaban nada. Más tarde, cuando la gente quería enviar a velocidades más altas durante cientos de metros, obtuvimos RS422 y RS485, que decían mucho más sobre la línea de cable como transmisión.
Respuestas:
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. Entonces el host envía datos y espera un acuse de recibo o una respuesta. Todas las transferencias son controladas por el host. El dispositivo tiene un cierto tiempo (bastante corto) para responder. Esta vez es más o menos 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
Entonces, mi respuesta es solo la mitad correcta: 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 es también justo que el USB se suponía siempre a ser la solución más económica para los periféricos "lentos" como teclados, ratones, impresoras, etc Si usted quería dúplex completo para más velocidad y más distancia, Ethernet 100BaseT es la elección natural.
fuente
Consulte esta página, /superuser/64744/maximum-length-of-a-usb-cable .
fuente
Realmente no es posible "almacenar" el 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 maneja la totalidad del bus. Un host envía una solicitud y el dispositivo debe emitir una respuesta al host. El comienzo de la respuesta debe llegar al host un cierto tiempo después de que la solicitud haya terminado de transmitirse. 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, existen soluciones alternativas, y ninguna de ellas implica un simple "almacenamiento en búfer", ya que el almacenamiento en búfer agrega retrasos adicionales, y necesitamos de alguna manera hacer que el host sea más tolerante a un retraso más largo.
Hay dos clases de soluciones alternativas:
Soluciones alternativas que insertan concentradores 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 hub se programan con demoras adicionales.
Puede insertar un concentrador de puerto único 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 concentradores antes 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.
Puede agregar concentradores virtuales, con un transceptor más robusto con énfasis previo, justo en el enchufe que va al host, luego transmitir el tráfico USB a través de un cable más largo. Mientras las señales recibidas por el dispositivo al final de dicho cable extendido estén dentro de las especificaciones, y mientras su receptor pueda recuperar los datos enviados por el dispositivo estándar a través de un cable largo, estará bien. Los concentradores virtuales se agregan para que el host permita el largo retraso, pero, por supuesto, no hay concentradores físicos, solo una suplantación de ellos.
Soluciones alternativas que emulan un dispositivo que parece "lento" en un nivel superior 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 otro extremo del cable (rDev) .
Inicialmente, el eDev finge 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 emula un evento de complemento y el rHost lo enumera. RHost cree que ve rDev, pero solo eDev está ahí, fingiendo. Del mismo modo, el rDev cree que se ve un rHost, pero es solo un eHost que está allí, fingiendo.
Eventualmente, el rHost quiere emitir algunas transferencias al rDev que cree que está allí, para usarlo. Para las transferencias IN, el eDev pretende no tener datos (responde con un NAK). La solicitud de transferencia se reenvía al eHost, que la 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 el rDev responde con un STALL, lo mejor que puede hacer el eDev es actuar de esta manera en la próxima transferencia desde el host. Alternativamente, el eDev siempre puede NAK la transferencia, con la suposición generalmente correcta de que el host simplemente volverá a intentar la transferencia idéntica más tarde. Aunque 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 de eDev tan pronto como se entera de ella.
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 puede 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 específicos de clase / dispositivo / listas negras / listas blancas del proveedor para ofrecer un mejor rendimiento también.
fuente
La mayoría de los esquemas de transmisión de datos por 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), impedancia de terminación (la 'resistencia' al final de la conexión que es necesaria para evitar los reflejos de su señal rebotando por el cable hacia el emisor), a menudo una 'velocidad de respuesta' específica (el tiempo que tarda la señal (es) en pasar de una señal 0-state a 1-state 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 que la integridad de la señal se degrade y las cosas dejan de funcionar bien.
En comparación con USB, RS232 tiene todas las especificaciones del tipo de cable, impedancia característica, velocidad de respuesta, longitud del cable, tipo de conector. Claro, los conectores 'D' de 25 pines y 9 pines eran comunes, pero en realidad RS232 fue diseñado en todo tipo de conectores y cables y productos sin especificaciones reales para decir lo contrario. En la práctica, con RS232 generalmente puede recorrer distancias más largas cayendo 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 medida según la impedancia de su cable, si está blindado o no, la terminación al final, etc.
y al comparar RS232 con USB, está comparando un 'estándar' de la década de 1960 que superó prácticamente 115k2 (con raras excepciones), con uno de la década de 1990 y 2000 que comenzó a 1.5Mbps, un orden de magnitud más rápido, luego 12Mbps (casi 100x más rápido), luego 480Mbps (casi 5000x más rápido), pero eso significó que los parámetros y la longitud del cable desempeñaron un papel importante para que funcione de manera confiable . Fue diseñado como un estándar de conexión periférica de escritorio, por lo que 5m se consideró aceptable, y luego todos los parámetros de los cables y conectores y velocidades se establecieron desde ese punto. Si hubiera una manera de hacer que el USB sea más lento, probablemente podría hacerlo funcionar con cables más largos (sin repetidor).
fuente