Cette article est une présentation des protocoles de communications les plus répandues dans le monde du spectacle.

Les protocoles, généralités

Un protocole de communication consiste en général en la définition d'une collection de messages permettant le dialogue entre un appareil A et un appareil B. De manière générale, un des deux appareils est maître, l'autre est esclave, c'est à dire qu'il répond au message du premier. La position maître-esclave peut s'inverser dynamiquement au cours du dialogue dans certains protocoles.

Certains éléments sont à considérer, dès que l'on parle de protocole.
La difficulté principale dans un protocole de communication est la réception correcte d'un message, c'est à dire la détection de son début, de sa fin, et la vérification de sa validité avant de le déchiffrer. La deuxième difficulté est la détection dans le protocole de la perte d'un message de manière à permettre sa retransmission.

Dans ce domaine, plusieurs techniques existent, et sont parfois utilisées en combinaison, pour garantir la validité des messages.

Généralement un message est constitué de plusieurs parties, pas toutes utilisées en fonction des protocoles : l'entête (HEADER : défini le début du message), le corps (BODY : défini le contenu du message), le terminateur (TAIL : défini la fin du message).




HEADER :
START BYTE(S) : Octet(s) indiquant le début du message.
BYTE(S) COUNT : Octet(s) indiquant la longueur du message.
BODY :
COMMAND BYTE(S) : Octet(s) indiquant l'objet du message.
DATA BYTE(S) : Octet(s) indiquant les paramètres du message.
TAIL :
CHECKSUM BYTE(S) : Octet(s) contenant le résultat d'un calcul opéré sur les octets du message avant transmission.
STOP BYTE(S) : Octet(s) indiquant la fin du message.

La détection et la lecture d'un message peuvent se faire de plusieurs manières, qui dépendent parfois du contexte d'utilisation. L'objectif premier est de détecter le début du message. Sachant qu'a priori rien ne distingue un octet d'un autre, il est nécessaire d'établir des règles, dans un protocole, pour que ces octets prennent des significations bien précises.

Méthodes de détection de début du message :

 Octet réservé :
Une valeur comprise entre 0 et 255 (0 et FFh) est réservée comme identificateur de début du message. Si cette valeur est reçue, un nouveau message est en cours de transmission (tout message non terminé en cours de réception est annulé).

 Time Out :
Un délai maximum est autorisé entre chaque octet (généralement une valeur multiple de la durée d'un octet). Tout octet arrivant après ce délai est considéré comme début de message, c'est à dire que tous les octets du message doivent être transmis l'un derrière l'autre avec un temps inférieur à ce délai.

 Bits de synchro :
Un ou plusieurs bits forment une séquence unique d'identification de début de trame. Fréquemment il s'agit de la différentiation entre octets de commande et octets de donnés. Les octets de commande ont leur bit de poids fort (bit 7) à 1, les octets de donnés ont leur bit de poids fort à 0.

 Signal externe :
Certains signaux de la ligne physique de communication peuvent être utilisés pour indiquer le début d'un message(ex RTS, DTR sur une ligne RS 232C, signal BREAK etc.).

Méthodes de détection de la fin du message :

Toutes les techniques de détection du début d'un message peuvent être utilisées plus :
 Comptage des octets :
Un comptage des octets à partir du début du message est effectué, la fin du message à lieu quand le compte attendu est atteint. Le compte attendu peut être calculé de deux manières :

 l'objet du message implique sa longueur.
 des octets de BYTE(S) COUNT donnent cette indication.

Méthodes de résolution de valeurs doubles :

Si la technique de valeur d'octet réservé est utilisée, un problème fréquent est rencontré : cette valeur d'octet peut se retrouver dans le message lui-même. Dans ce cas, il existe une manière de contourner le problème. Une autre valeur est réservée comme octet de codage (dit caractère d'échappement (ESCAPE)). Cet octet sert d'identificateur précisant que l'octet qui le suit à une signification différente.
Exemple : si on considère les trois valeurs suivantes 55h, AAh, 10h respectivement pour l'octet de début, de fin, d'escape, alors dans le message, tout octet ayant une de ces trois valeurs sera modifiée en une autre valeur et précédé de l'octet d'escape 10h. 55h sera transformé en 10h05h (par exemple), AAh en 10h0Ah et 10h en 10h10h. Suivant cette méthode les valeurs 55h et AAh sont exclusivement réservé au début et à la fin du message.

Méthodes de vérification de la validité du message :

Une fois le message reçu, c'est à dire que la phase de détection du début et de la fin à permit de constituer une trame, il reste à vérifier que ce message est valide, qu'il ne contient pas de valeurs erronées : un ou plusieurs octets à la fin du message contiennent le résultat d'un calcul opéré sur les octets du message avant la transmission. Si le même calcul, effectué après la réception du message ne donne par la même valeur, le message est corrompu.
Cette méthode est communément appelée CHECKSUM (somme de vérification) par extention du langage; mais en réalité, le CHECKSUM n'est que l'une des méthodes de calcul possible.

Méthodes de calcul :

 Somme des octets (CHECKSUM) :
La somme arithmétique des valeurs des octets est faite octet après octet, d'un octet de départ à un octet d'arrivé.
 OU logique (OR) :
Un OU logique est appliqué d'octet en octet, d'un octet de départ à un octet d'arrivé.
 OU EXCLUSIF logique (XOR) :
Un OU EXCLUSIF logique est appliqué d'octet en octet, d'un octet de départ à un octet d'arrivé.
 CRC :
Un calcul polynomial de bit en bit à partir d'une valeur d'initialisation est appliqué, d'un octet de départ à un octet d'arrivé. Souvent appelé CRC16 car effectué sur un masque de 16 bits.

Si le résultat dépasse le nombre d'octets prévus pour le CHECKSUM, seuls les octets de poids faible sont gardés.

 Une autre technique : l'analyse de la logique du contenu :
le contenu du message est vérifié par son sens, c'est à dire les valeurs admissibles de chaque partie du message. Cette solution s'applique si ces valeurs sont discrètes et en faible quantité.

Cette article est une présentation des protocoles de communications les plus répandues dans le monde du spectacle.

Les protocoles, les principaux types

Les protocoles basés sur l'ASCII :

Le codage ASCII est la représentation numérique (sur 8 bits) des caractères affichables, imprimables ou de contrôles ; ex 'A' est codé 65 (40h).

Ces protocoles utilisent les caractères de contrôle pour coder le début et la fin du message, le corps du message étant uniquement constitué de caractères affichages. Tous les chiffres devant être contenu dans le message sont convertis en ASCII ex 125 sera codé 31h32h35h.



STX est généralement défini à 02h, ETX à 03h.
Ex : 02h l o a d : 0 0 5 03h pourrait être un message signifiant charger le numéro 5. Tous les caractères compris entre STX et ETX sont affichables.

Il existe aussi des variantes, plus proche des terminaux ASCII qui définissent un message comme une suite de caractères affichables suivis du caractère de contrôle CR (0Dh) et/ou LF (0Ah).
Ex : P L A Y F R O M 1 2 0 3 4 5 0Dh pourrait être un message signifiant jouer à partir de 12h03mn45sec.

Les protocoles basés sur le format généraliste HEADER|BODY|TAIL :

Toutes les valeurs d'un octet sont utilisables, il est donc vital d'établir des règles de décodage deterministes. Deux schémas sont souvent utilisés :

 Il n'y a pas d'octet de début de message, mais les octets sont transmis sans délai (time out sur la réception) et le message contient un CHECKSUM de validation. Le premier octet est généralement l'octet qui contient la commande, suivit d'un octet (ou plusieurs) donnant la taille du message.



 Il y a un octet de début de trame, de fin de trame, mais pas de CHECKSUM. La longueur du message est déterminée par l'octet de fin de message et paralèllement la commande.



 Les protocoles utilisant le bit de poids fort comme identificateur de début de message :

Dans la plus part des cas, on différentie deux types d'octets, les octets de commande et les octets de donnés. Les octets de commande ont leur bit de poids fort à 1, les 7 autres bits servants à définir la commande elle-même. Les octets de donnés ont leur bit de poids fort à 0 et donc permettent de coder 128 valeurs (au lieu des 256 possibles dans un octet). Si des valeurs supérieures à 127 doivent être transmises, elles sont codées sur plusieurs octets de donnés par groupe de 7 bits.
La fin du message est généralement déduit du compte des octets, ce compte dépendant de la commande.



cccccc : indique la commande.
dddddd : indique les donnés.

 Les protocoles basés octet :

Un message peut être contenu dans un octet ou dans plusieurs octets mais la transmission se fait octet par octet. Tout octet envoyé donne lieu à une réponse du récepteur, ce qui permet la suite de la transmission, soit du message courant, soit du prochain message. Certaines valeurs d'octet sont réservées pour l'acquittement ou le non acquittement de la transmission, ainsi que pour préciser si le message est valide ou pas ces valeurs sont symbolisées par ACK (Acknowledge), NACK (None Acknowledge), ERR (Error).

 Les protocoles basés sur la redondance :

Généralement la complexité des messages est faible, mais l'assurance de la stabilité du dialogue est impérative, de plus, souvent, la vitesse de communication est rapide car la variation du contenu du message peut être rapide. On retrouve dans ce cas une répétition en cycle des messages de façon à ce que la perte totale ou partielle d'un message soit compensée par le message suivant.

MIDI (Musical Instrument Digital Interface)

Le protocole de communication MIDI définit d'une part les caratéristiques de communication de la ligne, mais aussi le format des messages transmis.

Caratéristiques de communication :

 Vitesse de communication à 31,25 Kilobits/seconde.
 8 bits de donnée, 1 Bits de stop, pas de parité.

Format des messages :

Tous les messages MIDI sont constitués d'un octet de Status (dont le bit de poid fort, bit 7, est toujours à 1) suivit d'octets de données (dont le bit de poid fort, bit 7, est toujours à 0). Certains messages utilisent la notion de canal (channel, il y en a 16).
Les messages MIDI sont divisés en groupes et sous-groupes :

Channel Messages :

 Format :



 Channel Voice Messages : Contrôle des sons des instruments.


nnnn : Numéro de canal (0-15).
kkkkkkk : Numéro de note (0-127).
vvvvvvv : Vélocité de note (0-127).
ccccccc : Numéro de contrôleur (0-120).
ppppppp : Numéro de programme (instrument) (0-127).

 Channel Mode Messages : Définition du mode des sons et instruments.

nnnn : Numéro de canal (0-15).
ccccccc : 0 > nombre de canaux = nombre de voie, 1 > Nombre de canaux (0-15).

System Messages :

 Format :



 System Exclusive Messages : Messages 'péniche' qui permettent de transmettre des informations propriétaires vers les instruments, ou qui permettent l'extension du protocole MIDI.

Structure :
 11110000 (F0H) : Octet de status 'Exclusive Message'
 0iiiiiii : iiiiiii identification.
 0ddddddd : ddddddd Data 1.
 ...
 0ddddddd : ddddddd Data n.
 11110111 (F7H) : Octet de EOX 'End Of Exclusive Message'

 Example of MTC Full Message :

 F0H: Start Exclusive Message.
7FH : Real Time Message.
7FH : Message to all system.
01H : Sub ID1 = MIDI Time Code.
01H : Sub ID2 = Full MTC Message.
hhH : Hours and type of TC : 0 yy zzzzz.

yy = type :

00 = 24 Frames/Second.
01 = 25 Frames/Second.
10 = 30 Frames/Second Dop Frame.
11 = 30 Frames/Second.
zzzzz = Hours (0-23).
mmH : Minutes (0-59).
ssH : Seconds (0-59).
ffH : Frames (0-29).
F7H : End Of Exclusive message.

System Common Messages : Messages transmis à tous les récepteurs.
nnn : MTC Message Type.

0 = Frame count LS nible.
1 = Frame count MS nible.
2 = Seconds count LS nible.
3 = Seconds count MS nible.
4 = Minutes count LS nible.
5 = Minutes count MS nible.
6 = Hours count LS nible.
7 = Hours count MS nible and SMPTE Type.
dddd : 4 Bits of binary data for MTC Message.

SMPTE Type (Message Type = 7) Bit 1 et 2 :
0 = 24 Frame/Second.
1 = 25 Frame/Second.
2 = 30 Frame/Second (Drop Frame).
3 = 30 Frame/Second.
lllllll: Bits de poid faible du paramètre (0-127).
mmmmmmm: Bits de poid fort du paramètre (0-127).
sssssss : Numéro de son (0-120).

 System Real Time Messages : Messages utilisés pour la synchronisation.

USITT DMX512

Le protocole de communication DMX définit d'une part les caratéristiques de communication de la ligne, mais aussi le format des messages transmis.

Caratéristiques de communication :

 Vitesse de communication à 250 Kilobits/seconde.
 8 bits de donnée, 2 Bits de stop, pas de parité.

Format des messages :

Il y a qu'un seul message qui est une trame cyclique, d'une fréquence maximum de 44hz, décrivant l'état de tous les équipements d'éclairage connectés. Cette trame débute par un 'break' ligne (mise à l'état bas logique 0 pendant une durée d'un minimum de 88 micro-secondes, suivi d'un MAB (Mark After Break, état haut logique 1 de la ligne) d'une durée minimum de 8 micro-secondes, suivi d'un octet de départ (START BYTE), suivi des niveaux des différents équipements, du premier au dernier. Le nombre d'appareils (circuits) pouvant aller de 1 à 512.



Le START BYTE est par défaut à 0, mais d'autres valeurs peuvent être utilisées si les équipements connectés en tire partie. C'est le cas par exemple, pour les équipements qui ont une résolution de 16 bits; une trame sur deux, la valeur du START BYTE change pour indiquer que cette trame concerne les valeurs de poids faible des niveaux. Toutes les deux trames, la valeur d'un équipement est actualisée.
Un autre technique est aussi utilisée pour adresser des équipements en 16 bits : deux valeurs successives dans la trame sont utilisées pour transmettre le poids faible et le poids fort du niveau.

La fréquence d'envoi de la trame peut varier et diminuer jusqu'à 1trame/seconde. En dessous de 1Hz, les équipements peuvent considérer que le signal n'est plus valide et prendre alors un état par défaut, mais ce n'est pas le cas systématiquement.

Même si ce protocole est défini par cette norme depuis 1990 pour sa dernière mise à jour, certains constructeurs proposent des produits qui ne la respectent pas scrupuleusement, ce qui pose des problèmes de compatibilité entre équipements.
On peux noter par exemple un MAB inférieur à 8 micro-secondes ou un 'Byte Space' espace entre deux octets de 1 ou 2 bits, ce qui peux être interprété comme des bits de parités non attendus.