Question:
Encodage Manchester
Adan Sh
2012-04-24 13:36:32 UTC
view on stackexchange narkive permalink

Si je comprends bien, dans le codage Manchester, des bits connus sont envoyés avant de commencer un transfert.

Mais je n'ai pas compris pourquoi - L'un des principaux avantages de Manchester est le fait que la synchronisation entre les deux côtés est plus facile. Alors pourquoi dois-je envoyer des bits avant le transfert?

@mazurnification: Je supprime le lien. C'est le protocole de Manchester
Je dirais que "Manchester protocol" est un mauvais alias pour la même chose que "Manchester code". Wikipedia vous redirige du protocole vers le code.
Adan Sh: vénéré pour remettre le lien; ce que @Telaclvo a dit est correct.
Six réponses:
#1
+10
Olin Lathrop
2012-04-24 18:09:36 UTC
view on stackexchange narkive permalink

Il y a deux raisons principales pour utiliser un préambule pour démarrer un paquet de données encodées manchester:

  1. Laisser le segment de données s'installer. Manchester est souvent utilisé sur des liaisons radio et des liaisons physiques où il n'y a pas de connexion directe et la différence entre un niveau haut et bas n'est pas explicitement connue à l'avance. Cela signifie généralement qu'un signal anlog est présenté à un data slicer , qui détecte et transmet la séquence des hauts et des bas numériques.

    Une propriété de l'encodage manchester qui le rend utile pour de tels liens est qu'il est en moyenne à 1/2 haut et 1/2 bas sur de courts intervalles. Chaque bit a le même niveau moyen de 1/2. Cela rend le découpage des données relativement facile car il peut s'agir d'un simple comparateur par rapport au niveau 1/2. Cependant, cela signifie que vous devez savoir quel est le niveau 1/2. Les anciens récepteurs le feraient dans le matériel en filtrant passe-bas le flux de Manchester. De tels filtres ne réagissent délibérément pas beaucoup en un seul bit, alors prenez quelques bits pour régler. Le préambule contient des bits de rejet que le récepteur n'est pas censé détecter correctement pendant que son segment de données recherche le niveau 1/2.

  2. Indique le début du paquet. Puisque la plupart des récepteurs de Manchester ont essentiellement une commande de gain automatique via le niveau 1/2 utilisé pour le découpage des données comme décrit ci-dessus, le récepteur interprétera le bruit de fond comme une série de niveaux hauts et bas tout comme le signal réel. Il n'y a généralement pas de signal vers la partie d'interprétation du flux numérique du récepteur, seulement que le flux a un sens lorsqu'il y a un signal réel.

    Manchester contient des informations redondantes de sorte que certaines séquences de niveaux peuvent être détecté comme invalide directement sans interprétation de niveau supérieur. Par exemple, il doit y avoir une transition au centre de chaque bit. Trois demi-bits du même niveau sont illégaux, de même que deux-un-deux, par exemple.

    Bien que la réinitialisation au début du paquet chaque fois qu'une violation comme ci-dessus est détectée aide, il y a encore suffisamment de chances que des indésirables aléatoires le transforment en un paquet que cela doit être traité dans la plupart des cas. Vous ne voulez pas des niveaux plus élevés dans la logique de décodage des paquets à partir du bruit lorsqu'un vrai paquet arrive qui ressemble alors à plus de données pour le faux paquet. Finalement, le faux paquet échouera vraisemblablement au test de somme de contrôle du paquet, mais vous perdez toujours le vrai paquet.

    Une bonne stratégie consiste alors à faire du préambule une séquence unique qui n'est pas valide dans le reste du paquet . Lorsque cette séquence est détectée, la logique d'interprétation des paquets de niveau supérieur est réinitialisée au début du paquet indépendamment de ce qu'elle pensait faire à ce moment-là.

    Je le fais habituellement en utilisant un schéma de bits de bourrage. Si les données réelles contiennent 7 0 consécutifs, par exemple, alors l'émetteur doit ajouter un 1 bit de bourrage après les 0. Le récepteur le sait et supprime le 1 bit suivant 7 0 bits consécutifs. Cela signifie qu'il n'y a jamais 8 bits 0 consécutifs, ce qui serait une violation de bourrage de bits. Si une violation de bourrage de bits est détectée, alors la logique d'interprétation des paquets peut être réinitialisée en toute sécurité au début du paquet car il n'était certainement pas dans un paquet valide à ce moment-là. Le préambule contient délibérément une telle violation de bit de truc pour forcer la logique d'interprétation à être réinitialisée au début du paquet.

    Ce schéma de bit de truc et la réinitialisation au début du paquet ne sont pas manchester standard, mais quelque chose que j'aime utiliser pour rendre manchester plus fiable sur des liens comme la radio.

Il y a plus à coder manchester quand on pense vraiment aux détails. Vous pouvez par exemple créer un segment de données à réponse beaucoup plus rapide dans un processeur numérique, auquel cas vous pouvez utiliser d'autres moyens que le bourrage de bits pour détecter de manière fiable le début du paquet, mais c'est tout un sujet sur lui-même.

Deux alternatives au bourrage de bits qui sont utilisées dans certains scénarios: (1) inclure un bit de parité tous les quelques bits. Cette approche est utilisée sur les cartes à bande magnétique, là le nombre maximum de zéros consécutifs dans un flux de données de 5 bits est de 8 (10000 00001); (2) utiliser les données BCD. Cette approche est utilisée avec les données de code temporel SMPTE, bien que les nybbles BCD alternent avec les non-BCD, de sorte que le nombre maximum de "1" consécutifs est de 8 (0111 1111 1001 si c'est big-endian). Je suis curieux de savoir si "1101100100" serait un bon motif de préambule, car il serait unique même sans bourrage de bits.
@supercat: Oui, il existe de nombreux schémas. Par exemple, un préambule de long-court-long-court, etc., fonctionne sans bourrage de bit puisqu'il s'agit d'une violation de manchester en soi. Ce n'est pas une moyenne de 1/2, mais c'est bien si votre segment de données fait autre chose que de comparer avec la moyenne récente. Cela fonctionnerait bien avec mes implémentations de découpage de données numériques, par exemple, car celles-ci utilisent des filtres non linéaires pour dériver le niveau de découpage.
Je pense qu'il est important pour un préambule d'inclure un haut et un bas de la même longueur; sinon, si le canal de transmission est du tout "analogique", les temps longs peuvent lire plus courts qu'ils ne le sont réellement et les temps courts plus longs. Il est possible de décoder des données Manchester équilibrées en mesurant uniquement les temps de front montant à front montant et les temps de front descendant à front descendant, sans avoir à mesurer de front montant à front descendant ou vice versa, mais un préambule de 100 ou 110 serait simplement lu comme une séquence uniforme de fronts montants et une séquence uniforme de fronts descendants.
@supercat: Ce que vous dites vraiment, c'est que les segments de données analogiques typiques exigent que le flux de données ait une valeur moyenne de 1/2. C'est vrai, mais comme je l'ai dit, il existe d'autres types qui n'ont pas cette exigence. Je n'ai pas fait de segment de données analogique depuis des années. Toutes mes séquences numériques iraient bien avec quelque chose comme une séquence longue-courte-longue-courte. Ils s'installent également plus rapidement, généralement en un peu plus d'un peu de temps.
Beaucoup dépend du support par lequel les données transitent. Si le comportement sur les fronts montants et descendants peut être supposé symétrique, ou si le débit de données est connu, alors haut-bas-bas pourrait être un préambule parfaitement fin. Si ces hypothèses ne tiennent pas, haut-bas-bas pourrait ressembler à une séquence de longs ou courts-circuits où l'impulsion basse est «étirée» par rapport à l'impulsion haute.
@Supercat: Il ne s'agit pas nécessairement de temps de montée et de descente. En fait, mes découpeurs de données numériques ne s'en soucient pas.
#2
+6
Telaclavo
2012-04-24 14:20:31 UTC
view on stackexchange narkive permalink

L'un des principaux avantages de Manchester est le fait que la synchronisation entre les deux côtés est plus facile.

Le type de synchronisation que l'encodage Manchester facilite est la synchronisation à au niveau binaire , et non au niveau du mot ou du paquet . En fait, cela n'aide pas du tout avec ce dernier. Et c'est pourquoi vous devrez peut-être encore transférer certains bits connus, avant vos bits de données.

Cela aide avec l'ancien (la synchronisation au niveau du bit), car il facilite la récupération de l'horloge.

Alors pourquoi ai-je besoin d'envoyer des bits avant le transfert?

Pour qu'ils vous aident à synchroniser au niveau mot / paquet. L'encodage Manchester ne vous aide pas à ce niveau.

Merci pour votre réponse. Donc, comme j'ai compris de votre part, je dois envoyer des bits avant un mot ou un paquet pour marquer que je commence le transfert de mot / paquet (en d'autres termes, deux côtés sont décidés sur le signe convenu, qui symbolise le début du paquet / mot). Cela se fait dans la couche netword acsses?
@AdanSh Oui, vous devez envoyer des bits à cause de cela, et je dirais que cela se fait dans la couche liaison de données. Voir ceci http://en.wikipedia.org/wiki/Frame_(networking)
#3
+3
stevenvh
2012-04-26 16:08:18 UTC
view on stackexchange narkive permalink

Manchester est une méthode de codage, pas un protocole, qui décrit beaucoup plus sur la communication. Ethernet est un protocole qui utilise le codage Manchester.

Le codage Manchester fonctionne au niveau du bit, il ne voit qu'un seul bit, il ne se soucie pas des bits précédents ou successifs. Peu importe que ce soit le premier ou le cinquième bit, et en tant que tel, il ne peut pas imposer d'envoyer des bits supplémentaires avant le début d'un transfert.

Ce que vous voulez dire probablement, c'est que le protocole commencera le transfert d'un paquet / mot avec une séquence connue (également codée Manchester, donc cela devient le premier bit).

Considérez la séquence suivante de quatre impulsions négatives:

\ $ \ mbox {1 1 1 1 1 0 1 0 1 0 1 0 1 1 1 1 1} \ $

Il n'y a aucun moyen de savoir s'il s'agit de 0x0000 ou 0x1111 , et Manchester s'en fiche. Vous devrez définir des bits supplémentaires pour vos données pour pouvoir les décoder. Par exemple, si votre protocole dit que chaque message commence par un préambule de 1 bits, il doit être 0x1111 . Les préambules de plusieurs bits facilitent la synchronisation, mais diminuent également l'efficacité du canal.
En fait, de telles séquences, seules les 1 s ou 0 s, sont les seules qui peuvent ne pas être décodé. Toute séquence qui a au moins 1 1 et 1 0 peut être décodée. Le bourrage de bits peut aider à éviter tous les 1 s ou tous les modèles de 0 .
Même dans ce cas, un préambule reste utile car le décodeur pourra pour sortir les bits au fur et à mesure qu'ils sont reçus. Sans préambule, les données telles que 0x0000001 ne peuvent être décodées que lorsque le bit 1 est reçu.

Néanmoins, le préambule n'est pas une exigence de codage de Manchester!

#4
+2
Federico Russo
2012-04-24 13:47:08 UTC
view on stackexchange narkive permalink

Le codage Manchester aboutit à un signal biphasé: soit un demi-bit de temps bas, suivi d'un demi-bit de temps haut (c'est par exemple pour un 1 logique), soit un demi-bit de temps haut suivi de un demi-bit de temps bas ( 0 logique). Il ne nécessite aucun bit supplémentaire.

enter image description here

Il est possible que le niveau de protocole supérieur suivant nécessite un préambule avant que la charge utile réelle ne soit transférée, mais ce n'est pas défini par Manchester. Manchester uniquement s'occupe du codage de bits individuels, il ne connaît pas de concepts comme les messages ou les paquets.

Êtes-vous sûr? J'ai lu la phrase suivante dans un livre qui traite de cette question: "les bits qui sont connus de deux côtés, sont envoyés avant que le transfert d'une information ne commence". Je le traduis en anglais, mais j'espère que vous en comprenez le sens.
@AdanSh: positif! Manchester ne concerne que le codage que j'ai décrit. Les bits supplémentaires doivent faire partie d'un protocole de niveau supérieur. Au fait, comment ces bits supplémentaires sont-ils encodés?
Le livre ne mentionne pas comment, il énonce simplement ces informations.
#5
+2
MikeJ-UK
2012-04-24 14:17:35 UTC
view on stackexchange narkive permalink

La raison habituelle est de donner à l'horloge du récepteur le temps de se synchroniser / se verrouiller avant l'arrivée des données réelles. En règle générale, une série de uns ou de zéros consécutifs est utilisée.

Avec MIL-STD 1553 (un protocole de bus avionique), un un logique (ou zéro) d'une durée de 1,5 bit est envoyé suivi par un zéro logique (ou un) d'une durée de 1,5 bits. Il s'agit en fait d'une violation du code Manchester mais est facilement détectable par le récepteur.

Dans les tags RFID basse fréquence utilisant le protocole EM 4100, une trame de données commence par un en-tête de 9 ceux de Manchester. La synchronisation n'est pas le problème ici puisque le récepteur a déjà une horloge (car il la rayonne vers l'étiquette émettrice). Cependant, les données peuvent être inversées, le récepteur doit donc déterminer la polarité. Puisque 9 bits consécutifs de la même polarité ne peuvent jamais apparaître dans les données réelles (en raison des bits de parité), l'en-tête peut être détecté sans ambiguïté comme une série de uns.

#6
-3
Tony Stewart Sunnyskyguy EE75
2012-04-24 23:25:44 UTC
view on stackexchange narkive permalink

Nommez au moins 3 méthodes de Manchester Code ou Bi-Phase, a) Mark, Space, Transition

Nommez au moins 3 niveaux de synchronisation dans la communication;

a) bit sync , b) synchronisation des mots (~ octet) c) synchronisation des images

Qu'est-ce qui est optimal pour la synchronisation des images?

Code de corrélation croisée où les mots de code ont un caractère unique lorsqu'ils sont synchronisés et non synchroniser. c'est-à-dire un schéma de détection de modèle qui est également le moins susceptible d'être des données.

Ceci est essentiel lors de la conversion de bits série en mots parallèles et de la synchronisation de trames. C'est ce que je savais il y a 35 ans lorsque j'ai implémenté pour la première fois un système SCADA au milieu des années 70. Cela a peut-être changé maintenant. La synchronisation d'horloge peut être aussi simple qu'un XOR avec un retard de 1 coup sur les transitions pour créer une horloge non redéclenchable, ou mieux une PLL avec des transitions échantillonnant un VCXO ultra stable en utilisant un signal d'horloge en dents de scie et des bords de données pour échantillonner la tension d'erreur de phase. Bien sûr, votre filtre passe-bande et votre support introduiront une gigue, vous devez donc apprendre à utiliser des filtres à cosinus surélevés où le décalage de bits est égal à zéro. Le taux d'erreur sur les bits ou BER est fonction de l'asymétrie de votre trancheur d'horloge, de l'erreur de phase de gigue & dans votre horloge et de la gigue dans vos données. Le BER est directement prévisible à partir du SNR et les tests de marge de phase aident à isoler la cause de vos problèmes de BER en utilisant des fenêtres de synchronisation réduites et décalées pour forcer votre horloge à décentrer et voir si les données sont toujours valides.

C'est la méthode secrète pour analyser tout système de communication marginal. J'ai postulé à mes jours SCADA comm, Telemtry to Aerospace, HDD data recovery et Telecom T1.

(si vous voulez des détails sur le VCO en dents de scie avec Sample & Hold phase error from data transitions .. il suffit de demander: p) il y a plus de 30 ans, j'ai conçu mais je pense que je peux toujours le faire.

Bien sûr, c'était un canal de communication synchrone. Vous pouvez également l'utiliser pour les communications ASYNC. et c'est peut-être ce que vous vouliez avec les parties du préambule. . J'ai utilisé des détecteurs de crête et de maintien +/- pour le filtre de suivi du slicer.

Si aucune de ces réponses ne fonctionne pour vous, essayez peut-être une autre question ....

Hein? Peu de ces bavardages apparemment sans but ont beaucoup de sens.
On dirait que vous ne savez rien sur le code de Manchester. J'en ai conçu beaucoup avec succès depuis 1976. Biphase nécessite un préampli pour activer la phase de synchronisation d'horloge. Puisqu'il existe à 3 protocoles de phase, Mark, Space et Inverse définis par IEEE, vous ne pouvez pas deviner que c'est connu. Ensuite, l'extraction d'horloge est facile. Il me vient toujours à l'esprit que ceux qui ne savent rien ne peuvent pas comprendre la raison et la logique et faire des commentaires comme les vôtres. Veuillez vous rétracter. BTW car il est utilisé pour asynchrone. mode. Le préamble est essentiel pour maintenir la synchronisation après les mots. tels que la synchronisation de trame, la synchronisation d'octet, etc. utilisés dans les répéteurs T1 et Biø
chaque fois que vous établissez une communication synchrone ou asynchrone avec un seul canal (horloge intégrée dans les données codées), la récupération des données nécessite un préamble établi. Le code Manchester ou BIPHASE ou les modems ont tous besoin d'un préamble, mais contrairement à UARTS qui est échantillonné au centre Nx horloges sur le front avant du bit de démarrage.


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...