¿Por qué hay que amortiguar la señal USB si el cable es de más de 5 m?
¿Se debe a una caída de la tensión de la señal?
¿Es porque impulsa las corrientes?
La velocidad de transmisión es importante porque el USB es semidúplex: para transmitir una respuesta, hay que dar la vuelta al bus y transmitir los datos en la otra dirección. Así que el host envía los datos y espera un acuse de recibo o una respuesta. Todas las transferencias son controladas por el host. El dispositivo tiene entonces un tiempo determinado (bastante corto) para responder. Este tiempo es aproximadamente el que tardan dos viajes de señal a lo largo de un cable de 5 metros.
(No puedo encontrar las referencias en este momento, pero los documentos de especificaciones relevantes son públicos)
Edición: gracias a psmears por encontrar esta sección
Cables y soluciones de largo recorrido
- ¿Por qué hay límites de longitud de los cables y cuáles son?
R: La longitud del cable estaba limitada por una especificación de retardo del cable de 26ns para permitir que las reflexiones se asienten en el transmisor antes de que el siguiente bit se envíe el siguiente bit. Dado que el USB utiliza la terminación de la fuente y los controladores en modo de tensión, esto tiene que ser así, de lo contrario, las reflexiones pueden acumularse y hacer estallar el controlador. Esto no significa que la tensión de la línea se haya estabilizado por completo al el final del bit; en el peor de los casos, la subterminación. Sin embargo, se ha amortiguación suficiente al final del bit para que la amplitud de la reflexión de reflexión se ha reducido a niveles manejables. El cable de baja velocidad La longitud del cable de baja velocidad se limitó a 18ns para evitar que los efectos de la línea de transmisión de transmisión afecten a las señales de baja velocidad.
- Quiero construir un cable de más de 5 metros, ¿por qué no funciona?
R: Incluso si violas la especificación, literalmente no te llevaría muy muy lejos. Asumiendo los tiempos de retardo en el peor de los casos, un dispositivo a toda velocidad en el fondo de 5 hubs y cables tiene un margen de tiempo de espera de 280ps. Reduciendo reducir este margen a 0ps sólo te daría 5cm extra, lo que no merece la pena. apenas merece la pena.
Así que mi respuesta es correcta a medias: el límite de ida y vuelta es para una cadena de bujes y cables en el peor de los casos, para una profundidad total de 25 m.
Dan Neely también tiene razón en que el USB siempre fue la solución de menor coste para los periféricos "lentos" como teclados, ratones, impresoras, etc. Si querías un dúplex completo para obtener más velocidad y más distancia, 100baseT ethernet es la opción natural.
¿Qué pasaría si se hace un cable USB de 20 metros? Dices que el voltaje no cambia y que la velocidad importa.
El host envía una solicitud, no recibe una respuesta a tiempo y no logra enumerar el dispositivo en el otro extremo.
¿Está seguro de esto? Según el Especificaciones del USB El retardo 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 5 m. El límite para el retardo de ida y vuelta es de aproximadamente 1,5 s. A esa velocidad hay tiempo suficiente para que la señal viaje de ida y vuelta por un cable de >100m. El Foro de Implementadores de USB ofrece un razón diferente para la limitación de 5 m.
Consulte esta página, https://superuser.com/questions/64744/maximum-length-of-a-usb-cable .
P1: ¿Qué longitud de cable puedo utilizar para conectar mi dispositivo? R1: En la práctica, la especificación USB limita la longitud de un cable entre dispositivos de máxima velocidad a 5 metros (algo 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 utilizar un cable de más de 3 o 5 m? A2: El diseño eléctrico de USB no lo permite. Cuando se diseñó el USB, se tomó la decisión de gestionar la propagación de los campos electromagnéticos en las líneas de datos del USB de forma que se limitara la longitud máxima de un cable USB a algo del orden de 4 m. Este método tiene una serie de ventajas y, dado que el USB está pensado para un entorno de escritorio, las limitaciones de alcance se consideraron aceptables. Si estás familiarizado con la teoría de las líneas de transmisión y quieres más detalles sobre este tema, echa un vistazo a la sección de señales USB de las preguntas frecuentes de los desarrolladores.
Puede que te resulte nebuloso, pero no hay forma fácil de explicar la teoría de la señal en el espacio que permite este formato.
Creo que esta respuesta señala ciertas razones por las que las limitaciones están ahí. Es bastante fácil profundizar en estas áreas haciendo una búsqueda en la web. Por ejemplo, sobre la teoría de las líneas de transmisión. Por eso he publicado esta respuesta.
En realidad no es posible "amortiguar" el USB, al menos no en el sentido habitual de la palabra. Normalmente, amortiguar significa amplificación eléctrica y quizás regeneración de la señal.
Con el USB, el host maneja la totalidad del bus. El host envía una solicitud y el dispositivo tiene que emitir una respuesta al host. El principio de la respuesta tiene que llegar al host un cierto tiempo después de que la petición haya terminado de transmitirse. Con un cable demasiado largo, el retardo de propagación es demasiado largo para que la respuesta llegue al host a tiempo.
Así que hay soluciones, y ninguna de ellas implica un simple "buffering", ya que el buffering añade retrasos adicionales, y tenemos que hacer de alguna manera que el host sea más tolerante a un mayor retraso.
Hay dos clases de soluciones:
Soluciones que insertan concentradores físicos o virtuales. Si un host enumera un hub en el bus, el propio hub añade un retardo adicional, y hay otro cable potencialmente de longitud completa entre el hub y el host. Todas las solicitudes de dispositivos que se conectan a continuación del concentrador se programan con retrasos adicionales.
Puede insertar un concentrador de un 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, así que si hay algún concentrador aguas arriba de tu aparato, tienes que reducir el número de concentradores en consecuencia. Muchos hosts USB incluyen un único nivel de hubs internos, por lo que un límite realista sería 28 m de cable, con 6 hubs en serie. Todos los concentradores, excepto el primero, tendrán que pretender ser autoalimentados.
Puedes añadir concentradores virtuales, con un transceptor más potente con preénfasis, justo en el enchufe que va al host, y así transmitir el tráfico USB por un cable más largo. Siempre que las señales que reciba el dispositivo al final de ese cable prolongado estén dentro de las especificaciones, y siempre que el receptor pueda recuperar los datos enviados por el dispositivo estándar a través de un cable largo, todo irá bien. Los hubs virtuales se añaden para que el host permita el largo retardo - pero, por supuesto, no hay hubs físicos, sólo una suplantación de ellos.
Soluciones 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 extremo opuesto del cable (rDev).
Inicialmente, el eDev finge no estar allí. En algún momento el eHost ve que un rDev fue conectado. Lo enumera y envía los datos al eDev. El eDev entonces emula un evento de conexión, y el rHost lo enumera. El rHost cree que ve al rDev, pero sólo es el eDev el que está allí, fingiendo. Del mismo modo, el rDev cree que ve un rHost, pero es sólo un eHost que está allí, fingiendo.
Eventualmente, el rHost quiere emitir algunas transferencias al rDev que cree que está ahí, para hacer algún uso de él. Para las transferencias IN, el eDev finge no tener datos (responde con un NAK). La solicitud de transferencia se reenvía al eHost, que la vuelve a ejecutar con el rDev. Los resultados de esto se reenvían al eDev, que utiliza los resultados la próxima vez que el host intenta la transferencia.
Para las transferencias OUT, el eDev tiene que adivinar cuál sería el comportamiento del rDev. Hay varias heurísticas y comportamientos que se pueden intentar aquí. Una forma es que el eDev siempre reciba los datos y responda con un ACK. La transferencia es reenviada a eHost, que luego repite la transferencia a rDev. Lo ideal es que rDev acabe consumiendo 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 siguiente transferencia desde el host. Alternativamente, el eDev puede siempre NAK la transferencia, con la suposición generalmente correcta de que el host simplemente reintentará la transferencia idéntica más tarde. Aunque la transferencia original fue NAK-ed, se reenvía a eHost, que entonces ejecuta la transferencia con rDev. Cualquiera que sea la respuesta de rDev, se convierte en la respuesta del eDev tan pronto como la conoce.
Las implementaciones realistas comenzarán con una heurística conservadora que implica un viaje de ida y vuelta completo a rDev para todas las transferencias que puedan ser pospuestas por un NAK. A medida que las transferencias avanzan, el comportamiento esperado de rDev puede ser aprendido, y eDev puede volverse menos conservador. El "extensor" puede utilizar el conocimiento de las clases estándar de USB, y algunos conocimientos de clases/dispositivos específicos del proveedor/listas negras/listas blancas para ofrecer también un mejor rendimiento.
¿No podrían los núcleos alternativos pretender ser alimentados por autobús? Creo que un hub alimentado por bus puede alimentar a un hub autoalimentado, ¿no es así?
@supercat Sí, podría haber cubos alternativos de mentira. No importa cómo lo hagas, siempre que el árbol de dispositivos de simulación aparezca conforme al anfitrión.
La mayoría de los esquemas de transmisión de datos por cable tienen una norma decente reconocida internacionalmente que describe cómo implementarlos, incluyendo una especificación para la "impedancia característica" del cable (piensa en esto como resistencia, pero se aplica a la CA), la impedancia de terminación (la "resistencia" en el extremo de la conexión necesaria para evitar que las reflexiones de la señal reboten en el cable y vuelvan al emisor), y a menudo un "slew rate" especificado (el tiempo que tardan las señales en pasar de un estado 0 a un estado 1 o viceversa) y, por tanto, el número máximo de transiciones entre 0/1 por segundo (es decir, los kbps/mbps). es decir, los kbps / Mbps / Gbps) y, por tanto, la longitud que puede tener el cable antes de que la integridad de la señal se degrade y las cosas dejen de funcionar correctamente.
En comparación con el USB, el RS232 no tiene ninguna especificación sobre el tipo de cable, la impedancia característica, la velocidad de giro, la longitud del cable o el tipo de conector. Es cierto que los conectores "D" de 25 y 9 pines eran comunes, pero en realidad RS232 se diseñó en todo tipo de conectores, cables y productos sin ninguna especificación real que dijera lo contrario. En la práctica, con RS232 se pueden alcanzar distancias más largas si se reduce la velocidad de bits por segundo (también conocida como "baudios"). La distancia máxima que se puede alcanzar también dependerá en gran medida de la impedancia del cable, de si está apantallado o no, de la terminación en el extremo, etc.
y al comparar el RS232 con el USB, estás comparando un "estándar" de los años 60 que prácticamente alcanzó un máximo de 115k2 (con raras excepciones), con uno de los años 90 y 2000 que comenzó a 1,5 Mbps, un orden de magnitud más rápido, luego a 12 Mbps (casi 100 veces más rápido), luego a 480 Mbps (casi 5000 veces más rápido), pero eso significaba que los parámetros y la longitud del cable jugaban un papel importante para que funcionara de forma fiable . Se diseñó como un estándar de conexión de periféricos de escritorio, por lo que se consideró que 5 m eran aceptables, y a partir de ahí se establecieron todos los parámetros de los cables y conectores y las velocidades. Si hubiera una forma de hacer que el USB fuera más lento, probablemente se podría hacer que funcionara con cables más largos (sin un repetidor).
Puede que el RS232 haya "tocado techo" en 115K, pero recuerdo cuando era de 110 o 300 bit por segundo entre una teleimpresora y un módem. Las señales estaban desequilibradas, el voltaje oscilaba entre -12V y +12V, y no había 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 quiso enviar a velocidades más altas a través de cientos de metros, obtuvimos RS422 y RS485, que decían mucho más sobre el cable como línea de transmisión.
Por dos razones:
1. Tensión
El USB utiliza señalización diferencial a +5V y -5V. Eso da una diferencia de 10V. RS232 varía, pero según este tutorial de Sparkfun la mayoría de los PCs utilizan de -13V a 13V. Eso da un margen de 26V. Además, dicen que la especificación permitía que las implementaciones utilizaran +25/-25, que serían 50V.
2. Velocidad
El RS232 alcanza un máximo de 115kbps. El USB 1.x de baja velocidad era de 1,5 Mbps, es decir, aproximadamente 10 veces más rápido. El USB 3.0 llega a los Gbps.
Ambas cosas hacen que sea mucho más difícil diferenciar la señal al final del cable. Veo que en otros posts se habla del retardo de propagación de la señal, pero no parece que ese sea el problema.
I-Ciencias es una comunidad de estudiantes y amantes de la ciencia en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.
1 votos
Rs232 utiliza +/-12 voltios, USB 0-5 voltios