Pourquoi la longueur maximale du câble USB est-elle plus courte qu'en RS232?
9
Pourquoi devons-nous mettre en mémoire tampon le signal USB si le câble mesure plus de 5 m?
Est-ce à cause d'une chute de tension du signal?
Est-ce parce qu'il entraîne des courants?
La vitesse de transmission est importante car l'USB est semi-duplex: pour transmettre une réponse, le bus doit être inversé et les données transmises dans l'autre sens. L'hôte envoie donc des données et attend un accusé de réception ou une réponse. Tous les transferts sont contrôlés par l'hôte. L'appareil dispose alors d'un certain délai (assez court) pour répondre. Ce temps est à peu près le temps pris pour deux trajets de signal le long d'un câble de 5 m.
(Je ne trouve pas de références juste cette seconde, mais les documents techniques pertinents sont publics)
Pourquoi y a-t-il des limites de longueur de câble et quelles sont-elles?
R: La longueur du câble a été limitée par une spécification de retard de câble de 26 ns pour permettre aux réflexions de se déposer sur l'émetteur avant l'envoi du bit suivant. Étant donné que l'USB utilise des pilotes de terminaison de source et de mode tension, cela doit être le cas, sinon les réflexions peuvent s'accumuler et faire exploser le pilote. Cela ne signifie pas que la tension de ligne s'est complètement stabilisée à la fin du bit; avec sous-terminaison dans le pire des cas. Cependant, il y a eu suffisamment d'amortissement à la fin du bit pour que l'amplitude de réflexion ait été réduite à des niveaux gérables. La longueur du câble à basse vitesse a été limitée à 18 ns pour empêcher les effets de la ligne de transmission d'avoir un impact sur les signaux à basse vitesse.
Je veux construire un câble de plus de 5 mètres, pourquoi cela ne fonctionnera-t-il pas?
R: Même si vous avez violé la spécification, cela ne vous mènerait littéralement pas très loin. En supposant les temps de retard les plus défavorables, un périphérique pleine vitesse au bas de 5 concentrateurs et câbles a une marge de temporisation de 280ps. Réduire cette marge à 0ps ne vous donnerait que 5 cm supplémentaires, ce qui ne vaut guère la peine.
Ma réponse n'est donc qu'à moitié droite: la limite aller-retour concerne une chaîne de concentrateurs et de câbles dans le pire des cas, pour une profondeur totale de 25 m.
Dan Neely a également raison de dire que l'USB a toujours été censé être la solution la moins coûteuse pour les périphériques "lents" comme les claviers, les souris, les imprimantes, etc. Si vous vouliez du duplex intégral pour plus de vitesse et de distance, Ethernet 100baseT est le choix naturel.
chapeau est un fait un câble USB de 20 m. ce qui se passerait? vous dites que la tension ne change pas et que la vitesse compte. alors que se passe-t-il dans un boîtier de câble de 20 m et que l'USB ne fonctionne pas?
user16307
2
L'hôte envoie une demande, n'obtient pas de réponse à temps et ne parvient pas à énumérer le périphérique à l'autre extrémité.
pjc50
4
Es-tu sûr de ça? Selon la spécification USB , le retard de propagation du signal le long du câble doit être <26 ns (tableau 7-9), donc le signal prend moins de 5,2 ns / m dans un câble standard de 5 m. La limite du délai d'aller-retour est d'environ 1,5 μs. À cette vitesse, il y a beaucoup de temps pour que le signal puisse aller et venir sur un câble de> 100 m. Le forum des implémenteurs USB donne une raison différente à la limitation de 5 m.
psmears
Y a-t-il une raison pour que l'USB 1.0-2.0 soit semi-duplex au lieu de duplex intégral depuis le premier jour (comme USB 3.0)? En d'autres termes, y a-t-il des avantages pratiques de la moitié par rapport au duplex intégral?
tigrou
1
@tigrou plus largement, USB1 a adopté des options simples partout où il le pouvait car il devait être suffisamment bon marché pour être implémenté et pouvoir rivaliser avec les ports RS232 / PS2 / LPT / Game. Le silicium est devenu beaucoup moins cher au fil des ans; mais avoir un prix supérieur au minimum devait être «suffisamment bon» pour les applications ciblées, USB2 a tué FireWire; et Thunderbolt apparaissant de plus en plus comme mort-né.
Q1: Quelle longueur de câble puis-je utiliser pour connecter mon appareil? A1: En pratique, la spécification USB limite la longueur d'un câble entre les appareils à pleine vitesse à 5 mètres (un peu moins de 16 pieds 5 pouces). Pour un appareil à basse vitesse, la limite est de 3 mètres (9 pieds 10 pouces).
Q2: Pourquoi ne puis-je pas utiliser un câble de plus de 3 ou 5 m? A2: La conception électrique de l'USB ne le permet pas. Lors de la conception de l'USB, il a été décidé de gérer la propagation des champs électromagnétiques sur les lignes de données USB d'une manière qui limitait la longueur maximale d'un câble USB à quelque chose dans la plage de 4 m. Cette méthode présente un certain nombre d'avantages et, comme l'USB est destiné à un environnement de bureau, les limitations de portée ont été jugées acceptables. Si vous connaissez la théorie des lignes de transmission et que vous souhaitez plus de détails sur ce sujet, jetez un œil à la section des signaux USB de la FAQ des développeurs.
n'explique toujours rien beaucoup d'informations brumeuses
user16307
10
Cela peut être brumeux pour vous, mais il n'y a pas de moyen facile d'expliquer la théorie du signal dans la pièce que ce format permet.
Wouter van Ooijen
5
Je pense que cette réponse indique certaines raisons pour lesquelles les limitations sont là. Il est assez facile d'explorer ces domaines en effectuant une recherche sur le Web. Par exemple sur la théorie des lignes de transmission. C'est pourquoi j'ai posté cette réponse.
Mattias Johansson
1
Je vote rarement, donc je me sens obligé de le justifier maintenant. Contrairement au commentaire de Wouter van Ooijen, je ne pense vraiment pas que cette réponse apporte quoi que ce soit de plus concret qu'une éventuelle suggestion de recherche sur "Limitation de longueur de câble USB". De plus, la réponse à laquelle vous faites référence contient un lien mort et sa suggestion de lecture supplémentaire n'est donc même pas utile. Si vous aviez trouvé la source d'origine correcte et cité à partir de cela, comme l'ont fait psmears et pjc50, ce serait une autre affaire - car cela fournit en fait des détails sur les raisons de cette limitation.
Oleksandr R.
5
Il n'est pas vraiment possible de "tamponner" l'USB, du moins pas dans le sens habituel du terme. Typiquement, la mise en mémoire tampon signifie une amplification électrique et peut-être une régénération du signal.
Avec USB, l'hôte pilote l'intégralité du bus. Un hôte envoie une demande et le périphérique doit émettre une réponse à l'hôte. Le début de la réponse doit arriver à l'hôte un certain temps après la fin de la transmission de la demande. Avec un câble trop long, le délai de propagation est trop long pour que la réponse atteigne l'hôte à temps.
Il existe donc des solutions de contournement, et aucune d'entre elles n'implique une simple "mise en mémoire tampon" car la mise en mémoire tampon ajoute des retards supplémentaires, et nous devons en quelque sorte rendre l'hôte plus tolérant à un délai plus long.
Il existe deux classes de solutions:
Solutions de contournement qui insèrent des concentrateurs physiques ou virtuels. Si un hôte énumère un concentrateur sur le bus, le concentrateur lui-même ajoute un délai supplémentaire et il existe un autre câble potentiellement pleine longueur entre le concentrateur et l'hôte. Toutes les demandes d'appareils qui se connectent en aval du concentrateur sont planifiées avec des délais supplémentaires.
Vous pouvez insérer un concentrateur à port unique tous les 4 m du câble, avec jusqu'à 7 concentrateurs en série. La limitation est de 7 niveaux de concentrateurs de l'hôte à l'appareil ultime, donc s'il y a des concentrateurs en amont de votre appareil, vous devez réduire le nombre de concentrateurs en conséquence. De nombreux hôtes USB incluent un seul niveau de concentrateur interne, donc une limite réaliste serait de 28 m de câble, avec 6 concentrateurs en série. Tous les concentrateurs, sauf le premier, devront faire semblant d'être autonomes.
Vous pouvez ajouter des concentrateurs virtuels, avec un émetteur-récepteur plus robuste avec préaccentuation, directement à la prise qui va dans l'hôte, puis transmettre le trafic USB sur un câble plus long. Tant que les signaux reçus par l'appareil à l'extrémité d'un tel câble étendu sont conformes aux spécifications, et tant que votre récepteur peut récupérer les données envoyées par l'appareil standard sur un long câble, vous serez OK. Les concentrateurs virtuels sont ajoutés afin que l'hôte autorise le long délai - mais bien sûr, il n'y a pas de concentrateurs physiques, juste une usurpation d'identité.
Solutions de contournement qui émulent un périphérique qui semble «lent» à un niveau de protocole supérieur. C'est ainsi que certaines "extensions" USB Cat-5 fonctionnent. Il y a cinq partenaires ici: l'hôte réel (rHost), un appareil émulé vu par lui (eDev), un long câble, un hôte émulé (eHost) et les appareils qui le voient à l'extrémité du câble (rDev) .
Au départ, l'eDev fait semblant de ne pas être là. À un moment donné, l'eHost voit qu'un rDev a été branché. Il l'énumère et transmet les données à l'eDev. L'eDev émule ensuite un événement de plug-in et le rHost l'énumère. Le rHost croit qu'il voit rDev, mais c'est seulement eDev qui est là, faisant semblant. De même, le rDev pense qu'il voit un rHost, mais ce n'est qu'un eHost étant là, faisant semblant.
Finalement, le rHost veut émettre des transferts vers le rDev qu'il croit être là, pour en faire usage. Pour les transferts IN, l'eDev prétend n'avoir aucune donnée (répond par un NAK). La demande de transfert est transmise à l'eHost, qui la réexécute avec rDev. Les résultats sont renvoyés à eDev, qui les utilise la prochaine fois que l'hôte tente le transfert.
Pour les transferts OUT, l'eDev doit deviner quel serait le comportement de rDev. Il existe différentes heuristiques et comportements qui peuvent être tentés ici. Une façon consiste pour eDev à toujours recevoir les données et à répondre avec un ACK. Le transfert est transmis à eHost, qui relit ensuite le transfert à rDev. Idéalement, rDev finira par consommer les données et les ACK. Si cela ne réussit pas, ou si le rDev répond par un STALL, le mieux que l'eDev puisse faire est d'agir de cette façon lors du prochain transfert depuis l'hôte. Alternativement, l'eDev peut toujours NAK le transfert, avec l'hypothèse généralement correcte que l'hôte va simplement réessayer le transfert identique plus tard. Même si le transfert d'origine était NAK-ed, il est transmis à eHost, qui exécute ensuite le transfert avec rDev. Quelle que soit la réponse de rDev, elle devient la réponse de l'eDev dès qu'il en a connaissance.
Les implémentations réalistes commenceront par des heuristiques conservatrices qui impliquent un aller-retour complet vers rDev pour tous les transferts qui peuvent être reportés par un NAK. Au fur et à mesure des transferts, le comportement attendu de rDev peut être appris et eDev peut devenir moins conservateur. L'extendeur peut utiliser les connaissances des classes USB standard et certaines connaissances / listes / listes blanches spécifiques aux fournisseurs / classes pour offrir également de meilleures performances.
Les hubs alternatifs ne pourraient-ils pas prétendre être alimentés par bus? Je pense qu'un concentrateur alimenté par bus peut alimenter un concentrateur autoalimenté, n'est-ce pas?
supercat du
Rien à voir avec l'alimentation par bus - c'est le retard total en réponse à un ACK.
pjc50
@supercat Oui, il pourrait y avoir d'autres hubs de simulation. Peu importe comment vous le faites, tant que l'arborescence des prétendus périphériques semble conforme à l'hôte.
Rétablir Monica le
@ pjc50 selon les spécifications USB, le délai ACK maximum est d'environ 400 ns. Le signal horaire peut parcourir 40 mètres de cuivre dans les deux sens. Ce n'est pas un facteur limitatif ici.
La plupart des schémas de transmission de données sur câble ont une norme décente internationalement reconnue décrivant comment les mettre en œuvre, y compris une spécification pour l '"impédance caractéristique" du câble (pensez à cela comme une résistance, mais s'applique au CA), une impédance de terminaison (la `` résistance '' à la fin de la connexion qui est nécessaire pour éviter que les réflexions de votre signal ne rebondissent sur le câble vers l'expéditeur), souvent une `` vitesse de balayage '' spécifiée (le temps qu'il faut pour que le ou les signaux passent d'une 0 à 1 ou vice versa), et donc le nombre maximum de transitions entre 0/1 par seconde (c'est-à-dire les kbps / Mbps / Gbps), et donc la durée du câble avant que l'intégrité du signal ne se dégrade & les choses ne fonctionnent plus correctement.
Comparé à l'USB, le RS232 possède des spécifications de type de câble, d'impédance caractéristique, de vitesse de balayage, de longueur de câble et de type de connecteur. Bien sûr, les connecteurs `` D '' à 25 et 9 broches étaient courants, mais en réalité, le RS232 a été conçu pour toutes sortes de connecteurs, de câbles et de produits sans aucune spécification réelle pour dire le contraire. Dans la pratique, avec RS232, vous pouvez généralement parcourir de plus longues distances en passant à un taux de bits par seconde (aka 'baud') inférieur. La distance maximale que vous pouvez atteindre sera également déterminée en grande partie sur l'impédance de votre câble, qu'il soit ou non blindé, la terminaison à la fin, etc.
et en comparant RS232 à USB, vous comparez un `` standard '' des années 1960 qui dépassait à peu près 115k2 (à de rares exceptions près), avec un des années 1990 et 2000 qui a commencé à 1,5 Mbps, un ordre de grandeur plus rapide, puis 12 Mbps (près de 100 fois plus rapide), puis 480 Mbps (près de 5000 fois plus rapide), mais cela signifiait que les paramètres et la longueur des câbles jouaient un rôle important pour le rendre fiable . Il a été conçu comme une norme de connexion périphérique de bureau, donc 5 m ont été jugés acceptables, puis tous les paramètres des câbles et connecteurs et des vitesses ont été définis à partir de ce point. S'il y avait un moyen de ralentir l'USB, vous pourriez probablement le faire fonctionner sur des câbles plus longs (sans répéteur).
RS232 peut avoir "dépassé" à 115K, mais je me souviens quand c'était une liaison de 110 ou 300 bits par seconde entre un téléimprimeur et un modem. Les signaux étaient déséquilibrés, la tension est passée de -12 V à + 12 V, et il n'y avait ni paire torsadée ni terminaison ni blindage. À cette vitesse et sur de si courtes distances, les caractéristiques du fil ne signifiaient rien. Plus tard, lorsque les gens ont voulu envoyer à des vitesses plus élevées sur des centaines de mètres, nous avons obtenu RS422 et RS485, ce qui en dit beaucoup plus sur la ligne de transmission par fil.
Réponses:
La vitesse de transmission est importante car l'USB est semi-duplex: pour transmettre une réponse, le bus doit être inversé et les données transmises dans l'autre sens. L'hôte envoie donc des données et attend un accusé de réception ou une réponse. Tous les transferts sont contrôlés par l'hôte. L'appareil dispose alors d'un certain délai (assez court) pour répondre. Ce temps est à peu près le temps pris pour deux trajets de signal le long d'un câble de 5 m.
(Je ne trouve pas de références juste cette seconde, mais les documents techniques pertinents sont publics)
Edit: merci à psmears d'avoir trouvé cette section
Ma réponse n'est donc qu'à moitié droite: la limite aller-retour concerne une chaîne de concentrateurs et de câbles dans le pire des cas, pour une profondeur totale de 25 m.
Dan Neely a également raison de dire que l'USB a toujours été censé être la solution la moins coûteuse pour les périphériques "lents" comme les claviers, les souris, les imprimantes, etc. Si vous vouliez du duplex intégral pour plus de vitesse et de distance, Ethernet 100baseT est le choix naturel.
la source
Voir cette page, /superuser/64744/maximum-length-of-a-usb-cable .
la source
Il n'est pas vraiment possible de "tamponner" l'USB, du moins pas dans le sens habituel du terme. Typiquement, la mise en mémoire tampon signifie une amplification électrique et peut-être une régénération du signal.
Avec USB, l'hôte pilote l'intégralité du bus. Un hôte envoie une demande et le périphérique doit émettre une réponse à l'hôte. Le début de la réponse doit arriver à l'hôte un certain temps après la fin de la transmission de la demande. Avec un câble trop long, le délai de propagation est trop long pour que la réponse atteigne l'hôte à temps.
Il existe donc des solutions de contournement, et aucune d'entre elles n'implique une simple "mise en mémoire tampon" car la mise en mémoire tampon ajoute des retards supplémentaires, et nous devons en quelque sorte rendre l'hôte plus tolérant à un délai plus long.
Il existe deux classes de solutions:
Solutions de contournement qui insèrent des concentrateurs physiques ou virtuels. Si un hôte énumère un concentrateur sur le bus, le concentrateur lui-même ajoute un délai supplémentaire et il existe un autre câble potentiellement pleine longueur entre le concentrateur et l'hôte. Toutes les demandes d'appareils qui se connectent en aval du concentrateur sont planifiées avec des délais supplémentaires.
Vous pouvez insérer un concentrateur à port unique tous les 4 m du câble, avec jusqu'à 7 concentrateurs en série. La limitation est de 7 niveaux de concentrateurs de l'hôte à l'appareil ultime, donc s'il y a des concentrateurs en amont de votre appareil, vous devez réduire le nombre de concentrateurs en conséquence. De nombreux hôtes USB incluent un seul niveau de concentrateur interne, donc une limite réaliste serait de 28 m de câble, avec 6 concentrateurs en série. Tous les concentrateurs, sauf le premier, devront faire semblant d'être autonomes.
Vous pouvez ajouter des concentrateurs virtuels, avec un émetteur-récepteur plus robuste avec préaccentuation, directement à la prise qui va dans l'hôte, puis transmettre le trafic USB sur un câble plus long. Tant que les signaux reçus par l'appareil à l'extrémité d'un tel câble étendu sont conformes aux spécifications, et tant que votre récepteur peut récupérer les données envoyées par l'appareil standard sur un long câble, vous serez OK. Les concentrateurs virtuels sont ajoutés afin que l'hôte autorise le long délai - mais bien sûr, il n'y a pas de concentrateurs physiques, juste une usurpation d'identité.
Solutions de contournement qui émulent un périphérique qui semble «lent» à un niveau de protocole supérieur. C'est ainsi que certaines "extensions" USB Cat-5 fonctionnent. Il y a cinq partenaires ici: l'hôte réel (rHost), un appareil émulé vu par lui (eDev), un long câble, un hôte émulé (eHost) et les appareils qui le voient à l'extrémité du câble (rDev) .
Au départ, l'eDev fait semblant de ne pas être là. À un moment donné, l'eHost voit qu'un rDev a été branché. Il l'énumère et transmet les données à l'eDev. L'eDev émule ensuite un événement de plug-in et le rHost l'énumère. Le rHost croit qu'il voit rDev, mais c'est seulement eDev qui est là, faisant semblant. De même, le rDev pense qu'il voit un rHost, mais ce n'est qu'un eHost étant là, faisant semblant.
Finalement, le rHost veut émettre des transferts vers le rDev qu'il croit être là, pour en faire usage. Pour les transferts IN, l'eDev prétend n'avoir aucune donnée (répond par un NAK). La demande de transfert est transmise à l'eHost, qui la réexécute avec rDev. Les résultats sont renvoyés à eDev, qui les utilise la prochaine fois que l'hôte tente le transfert.
Pour les transferts OUT, l'eDev doit deviner quel serait le comportement de rDev. Il existe différentes heuristiques et comportements qui peuvent être tentés ici. Une façon consiste pour eDev à toujours recevoir les données et à répondre avec un ACK. Le transfert est transmis à eHost, qui relit ensuite le transfert à rDev. Idéalement, rDev finira par consommer les données et les ACK. Si cela ne réussit pas, ou si le rDev répond par un STALL, le mieux que l'eDev puisse faire est d'agir de cette façon lors du prochain transfert depuis l'hôte. Alternativement, l'eDev peut toujours NAK le transfert, avec l'hypothèse généralement correcte que l'hôte va simplement réessayer le transfert identique plus tard. Même si le transfert d'origine était NAK-ed, il est transmis à eHost, qui exécute ensuite le transfert avec rDev. Quelle que soit la réponse de rDev, elle devient la réponse de l'eDev dès qu'il en a connaissance.
Les implémentations réalistes commenceront par des heuristiques conservatrices qui impliquent un aller-retour complet vers rDev pour tous les transferts qui peuvent être reportés par un NAK. Au fur et à mesure des transferts, le comportement attendu de rDev peut être appris et eDev peut devenir moins conservateur. L'extendeur peut utiliser les connaissances des classes USB standard et certaines connaissances / listes / listes blanches spécifiques aux fournisseurs / classes pour offrir également de meilleures performances.
la source
La plupart des schémas de transmission de données sur câble ont une norme décente internationalement reconnue décrivant comment les mettre en œuvre, y compris une spécification pour l '"impédance caractéristique" du câble (pensez à cela comme une résistance, mais s'applique au CA), une impédance de terminaison (la `` résistance '' à la fin de la connexion qui est nécessaire pour éviter que les réflexions de votre signal ne rebondissent sur le câble vers l'expéditeur), souvent une `` vitesse de balayage '' spécifiée (le temps qu'il faut pour que le ou les signaux passent d'une 0 à 1 ou vice versa), et donc le nombre maximum de transitions entre 0/1 par seconde (c'est-à-dire les kbps / Mbps / Gbps), et donc la durée du câble avant que l'intégrité du signal ne se dégrade & les choses ne fonctionnent plus correctement.
Comparé à l'USB, le RS232 possède des spécifications de type de câble, d'impédance caractéristique, de vitesse de balayage, de longueur de câble et de type de connecteur. Bien sûr, les connecteurs `` D '' à 25 et 9 broches étaient courants, mais en réalité, le RS232 a été conçu pour toutes sortes de connecteurs, de câbles et de produits sans aucune spécification réelle pour dire le contraire. Dans la pratique, avec RS232, vous pouvez généralement parcourir de plus longues distances en passant à un taux de bits par seconde (aka 'baud') inférieur. La distance maximale que vous pouvez atteindre sera également déterminée en grande partie sur l'impédance de votre câble, qu'il soit ou non blindé, la terminaison à la fin, etc.
et en comparant RS232 à USB, vous comparez un `` standard '' des années 1960 qui dépassait à peu près 115k2 (à de rares exceptions près), avec un des années 1990 et 2000 qui a commencé à 1,5 Mbps, un ordre de grandeur plus rapide, puis 12 Mbps (près de 100 fois plus rapide), puis 480 Mbps (près de 5000 fois plus rapide), mais cela signifiait que les paramètres et la longueur des câbles jouaient un rôle important pour le rendre fiable . Il a été conçu comme une norme de connexion périphérique de bureau, donc 5 m ont été jugés acceptables, puis tous les paramètres des câbles et connecteurs et des vitesses ont été définis à partir de ce point. S'il y avait un moyen de ralentir l'USB, vous pourriez probablement le faire fonctionner sur des câbles plus longs (sans répéteur).
la source