câble, blindage et vitesse

"pes"

Les données USB transitent via deux signaux en opposition de phase sur une paire de conducteurs symétriques : pour 12 Mb/s sur 10 cm ca *devrait* passer.

Mais pourquoi ne pas récupérer un petit bout de câble avec 2 conducteurs entourés d'un blindage à la masse ?

Le 25/07/2013 14:58, Jean-Christophe a écrit :

En plus de D+ et D-, il faut aussi le VUSB, qui porte aussi une part de l'info de négociation. Donc 3, pas 2 -- mais ça ne remet pas en cause ta question.

Amicalement,

--
Albert.

Mais le VUSB est référencé par rapport à la masse ( et non par rapport aux D+/D- ) non ? Si oui, alors il faut aussi la masse, donc 4 fils ...

S'il insiste pour utiliser du non-blindé (câble plat) il reste toujours possible de torsader D+/D- ... à 12 Mb/s sur 10 cm, pas sûr que ca vaille le coup.

Le 25/07/2013 14:58, Jean-Christophe a écrit :

C' est une question d' encombrement. Il me faut quelque chose de pas trop épais.

Le 25/07/2013 15:45, Jean-Christophe a écrit :

Oui, tout est référencé à la masse, mais ici j'ai répondu après "2 conducteurs entourés d'un blindage à la masse", donc 3 fils... et le blindage qui font 4.

Je ne pense pas, mais il faudrait une idée même vague des perturbations envisagés.

Amicalement,

--
Albert.

Un câble avec blindage + 3 conducteurs trés fins ( le courant étant faible, une fine section suffit ) sera plus fin que la section globale de 4 fils plats ...

Ok. Je ne savais pas que le VUSB portait lui aussi de l'information : de quoi s'agit-il ?

Le 25/07/2013 17:21, Jean-Christophe a écrit :

Par exemple, dans la spec USB 2.0 / OTG ça sert à la détection d'un "attachement", et de façon générale pour la gestion d'énergie.

Amicalement,

--
Albert.

Bon sang mais c'est bien sûr, où avais-je la tête :o)

Par exemple, dans le cas d'un bidule téléalimenté branché sur le port USB d'un PC, la détection du courant consommé sur VUSB correspond à un seul bit d'information signifiant " il y a un truc qui demande un attachement ". ( on peut qualifier cela de "donnée", même si ce n'est qu'un unique bit )

Mais dès lors la suite des échanges du protocole se fait via les fils de données D+/D- et non par VUSB ; sinon, quelles sont les données qui y circulent ?

Le 25/07/2013 19:20, Jean-Christophe a écrit :

En termes d'état, VBUS est identique à D+ ou D- : c'est censé être du binaire. Mais d'une part la combinatoire des états possibles et leurs évolutions dans le temps, d'autre part la force avec laquelle la ligne est tirée au 0 ou au 5V de part et d'autre, permettent de passer bien plus que deux états stables, et donc davantage qu' un unique bit qui ne traduirait que le courant consommé.

Ainsi, un bidule esclave auto-alimenté sait par VBUS si son port maître est actif ou en veille ; et en OTG, l'activation ou la désactivation de VBUs fait partie des protocoles (et est donc susceptible d'empêcher le fonctionnement s'il n'est pas transmis d'un port à l'autre).

Noter aussi que pour les attachements en OTG, ce n'est pas la tension sur VBUS qui est mesurée ; c'est la capacitance d'ensemble. La tension, elle varie dynamiquement entre trois seuils.

Bref: sauf à savoir que l'hôte et l'esclave USB à relier peuvent fonctionner hors spec, relier leurs VBUS est aussi nécessaire que relier leurs D+, D- et masse. :)

Amicalement,

--
Albert.

Le 25/07/2013 19:20, Jean-Christophe a écrit :

et le sata .... 1 bit et plusieurs dizaines de MHz :-)

Le 25/07/2013 17:18, Jean-Christophe a écrit :

Je vais regarder peut être cette optique, un connecteur fin blindé pour les 2 datas, et un autre plat car j' ai aussi 3 autres signaux de puissance à transmettre et le 5V de l' USB pourrait éventuellement servir aussi à alimenter en énergie (~300mA dans certains cas).

Le 25/07/2013 22:40, pes a écrit :

Attention : VBUS n'est pas un simple "5V" ; il peut, selon l'état de l'hôte, tomber à 0 pour de longues périodes. Si donc tu as besoin d'une alimentation constante, choisis une autre source de 5V que le VBUS d'un port hôte USB.

Amicalement,

--
Albert.

Ne pas confondre un fil d'alimentation avec un fil de données sérielles.

Un fil d'alimentation est par définition, soit à zéro soit à +E : s'il est à zéro le circuit ne fonctionne pas et tant qu'il est à +E son état ne change pas, ce n'est donc pas strictement un bit d'information.

Un seul fil de données sérielles ne porte qu'un seul bit de donnée à chaque instant ; c'est son état temporel qui peut encoder autant de bits qu'on veut sur un seul fil.

Cela dit, on peut superposer sur un seul fil à la fois une alim et des données sérielles, le tout est de bien définir ce que l'on fait.

300 mA c'est OK avec VUSB, et là ca vaut le coup de bien séparer les fils de l'USB d'avec les fils de puissance, avec blindage pour D+/D-

Note que lors de la connection, le protocole USB prévoit l'échange de données concernant l'hôte, entre autres un champ où l'hôte indique au maître combien de mA il a besoin sur sa ligne d'alimentation.

J'ai réalisé quelques cartes à uC avec port USB ( vers un PC, ce n'est donc pas du OTG ) et j'utilise évidemment VUSB pour alimenter cette carte ( courant crête consommé autour de 450 mA ) le VUSB alimentant aussi d'autres chips sur la même carte, ( entre autres un MAX202 pour une sortie RS232 ) et tout ceci marche trés correctement : fiche USB plug in/out à froid et à chaud et jamais aucun problème avec VUSB.

Par exemple :

HTH

Je crois qu'on s'est mal compris : de mon côté je parlais d'une carte sans alimentation, avec son port USB relié au port USB d'un PC et donc alimenté par le VUSB en provenance du PC, ce n'est donc pas de l'OTG.

Dans le cas cité sur le post en réponse à "pes" le VUSB sert d'alim, et tant que la carte est active et alimentée via VUSB je n'ai jamais eu de cas où VUSB ait une valeur différente de la tension nominale qu'on s'attend à y trouver, ni à traiter d'éventuelles données qui y transiteraient. D'autant plus que sur la carte le VUSB est fortement découplé à la masse par un condo chimique et diverses capas de compensation : si un signal y transitait il serait shunté à la masse.

Le 26/07/2013 13:03, Jean-Christophe a écrit :

Même sans OTG, on n'est pas 100% à l'abri d'une chute du VUSB à zéro.

On s'est mal compris sur la nature de VBUS : il ne transport pas de signal HF vecteur d'un flux important de bits, en effet ; mais il n'est pas constant pour autant, et peut notamment, en OTG mais pas seulement, tomber à zéro durablement de temps à autres.

Reste au demandeur à voir s'il est sensible à ce problème et comment il peut le résoudre le cas échéant -- il se peut par exemple que par sa propre configuration l'hôte ne fasse jamais tomber le VBUS au moment où l'esclave en aurait besoin ; il se peut que le client et l'hôte négocient un maintien hors veille ; etc.

Amicalement,

--
Albert.

Le 26/07/2013 12:47, Jean-Christophe a écrit :

("ou l'esclave indique à l'hôte", en fait)

Juste une remarque complémentaire : tant que cette négo n'a as eu lieu, l'esclave doit consommer au plus 100 mA, et ne peut consommer davantage qu'une fois autorisé par l'hôte (qui peut refuser, et qui peut couper le port si surconsommation) -- voir par exemple :

Amicalement,

--
Albert.

Situons-nous hors du fait qu'on ferme le soft PC qui discute avec la carte, ou qu'une commande issue volontairement de ce soft ferme la connection USB, ou que la carte créée une surconsommation de courant sur VUSB, ou que le PC soit hors secteur et que sa batterie tombe en rade, ou qu'on éteigne le PC, ou d'une coupure secteur sans batterie, etc ...

On a une carte reliée (et alimentée) sur un port USB d'un PC, aprés un start-up réussi la carte et le PC sont en communication via le port USB : est-ce que le PC peut arbitrairement cesser d'alimenter la carte via VUSB ? Si oui, la carte est subitement HS et on perd des données : dans quelles conditions (autres que celles citées ci-dessus) le PC va-t'il décider de cesser d'alimenter VUSB ?

Dans quelles conditions ?

J'avais effectivement supposé ( peut-être un peu vite ) qu'il s'agissait d'une carte alimentée via un USB de PC, et il est vrai que l'on a aucune information à ce sujet ...