FR2509553A1 - Procede de diffusion de donnees sur canal de television - Google Patents

Procede de diffusion de donnees sur canal de television Download PDF

Info

Publication number
FR2509553A1
FR2509553A1 FR8113675A FR8113675A FR2509553A1 FR 2509553 A1 FR2509553 A1 FR 2509553A1 FR 8113675 A FR8113675 A FR 8113675A FR 8113675 A FR8113675 A FR 8113675A FR 2509553 A1 FR2509553 A1 FR 2509553A1
Authority
FR
France
Prior art keywords
data
packet
packets
byte
bits
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR8113675A
Other languages
English (en)
Other versions
FR2509553B1 (fr
Inventor
Michel Henry
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
EFCIS
Original Assignee
EFCIS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by EFCIS filed Critical EFCIS
Priority to FR8113675A priority Critical patent/FR2509553A1/fr
Publication of FR2509553A1 publication Critical patent/FR2509553A1/fr
Application granted granted Critical
Publication of FR2509553B1 publication Critical patent/FR2509553B1/fr
Granted legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/0078Avoidance of errors by organising the transmitted data in a format specifically designed to deal with errors, e.g. location
    • H04L1/0083Formatting with frames or packets; Protocol or part of protocol for error control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00Television systems
    • H04N7/025Systems for the transmission of digital non-picture data, e.g. of text during the active part of a television frame

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

L'INVENTION CONCERNE UN PROCEDE DE TRANSMISSION DE DONNEES NUMERIQUES SUR CANAL DE TELEVISION. LES DONNEES SONT TRANSMISES PAR PAQUETS ET LES PAQUETS SONT AGENCES EN WAGONS OU LES DONNEES SONT TOUTES DE MEME TYPE, AVEC UN PAQUET DE PROCEDURE EN TETE DE CHAQUE WAGON. CHAQUE PAQUET COMPORTE UNE SEQUENCE CARACTERISTIQUE QUI SE REDUIT A 0 SI LE PAQUET FAIT PARTIE D'UN WAGON DE TELETEXTE EN CODE ASCII, ET QUI COMPREND DE UN A TROIS OCTETS DE HAMMING AVEC UN BIT INDIQUANT SEULEMENT SI LE PAQUET EST PLEIN OU NON DANS LE CAS OU LES DONNEES SONT AGENCEES EN CHAINES DE BITS DANS LES PAQUETS. LES PAQUETS DE PROCEDURE ONT COMME SEQUENCE CARACTERISTIQUE UN OCTET DE HAMMING NUL. APPLICATION A TOUS LES SYSTEMES DE DIFFUSION DE DONNEES SUR CANAL DE TELEVISION, MULTIPLEXEES AVEC L'IMAGE OU NON.

Description

PROCEDE DE DIFFUSION DE DONNEES SUR CANAL DE TELEVISION.
La présente invention concerne la diffusion de données numériques å sens unique par canal de télévision selon des normes compatibles avec la diffusion actuelle des émissions publiques de télévision.
On essaye actuellement de créer des réseaux de transport d'informations par voie hertzienne à sens unique, de manière que des usagers possédant un récepteur de télévision puissent recevoir ces informations. On ne s'intéresse ici qut la transmission des informations, même si certaines applications prévoient une possibilité d'interaction entre la source d'information et l'usager en effet, dans ce cas, le retour de l'usager vers la source s'effectuera en principe autrement que par canal de télévision.
En prat-ique, il est prévu que l'on transmette les données numériques, sous forme d'impulsions binaires modulant en fréquence la porteuse du canal de télévision, soit sur un canal réservé à cet effet, soit pendant les quelques lignes correspondant au retour de trame dans un canal réservé è une émission normale de télévision. Les données numériques transmises sont décodées au niveau d'un récepteur spécialisé et peuvent être affichées sur l'écran du récepteur de télévision, par exemple sous forme d'un texte qui s'inscrit sur l'écran.
Surtout dans le cas où on transmet des informations pen- dant quelques lignes du retour de trame, les données numériques doivent être transmises par paquets correspondant chacun à une ligne vidéo. Compte tenu de la fréquence porteuse des canaux utilisés, de la modulation possible de cette fréquence, et de la durée imposée des lignes vidéo, on conçoit que l'on peut transmettre seulement un petit nombre d'informations pendant la durée de chaque ligne. En pratique, les paquets ne peuvent guère comporter plus d'une quarantaine d'octets.
De plus, il faut réserver dans chaque paquet un certain nombre d'octets qui sont destinés à la synchronisation des don nées, è l'identification des paquets, à la détection des pertes de paquets, etc...
On a donc déjé proposé des procédés de transmission dans lesquels les paquets sont divisés en un certain nombre d'octets d'en-tête et un certain nombre d'octets de données.
Plusieurs systemes ont été proposés, et notamment un systeme dans lequel l'en-tête est décomposé en une première partie et une seconde partie de la manière suivante.
La première partie comprend
- des bits de synchronisation destinés à la définition de la fréquence de transmission des données qui suivent ; le récepteur détecte ces bits et se synchronise sur leur fréquence
- un octet de départ ayant une valeur particulière que reconnait ie récepteur pour définir ensuite les limites d'octets qui suivent par comptage de groupes de huit bits à partir de l'octet de départ
- plusieurs octets d'adresse définissant le paquet transmis par rapport aux autres paquets : ces octets peuvent concerner par exemple un numéro de voie s'il y a transmission multiplexée des paquets en plusieurs voies, ou encore un numéro de magazine d'information, ou de page ou de paragraphe, etc... auxquels se réfère le paquet
- éventuellement, un indice de continuité qui est un octet définissant le numéro du paquet dans un groupe de paquets transmis sur une même voie : si deux paquets de la même voie se suivent en présentant deux indices de continuité non consécutifs, il y aura lè une indication de perte d'un ou plusieurs paquets.
La deuxième partie de l'en-tete du systeme le plus performant proposé actuellement comporte un octet de format qui indique combien d'octets suivent dans le paquet de données. Cet octet de format est nécessaire car on ne connais pas a priori la longueur des paquets de données, notamment du fait que cette longueur dépend de la capacité de transmission du canal, donc de la fréquence de celui-ci qui peut varier dans de larges proportions.
I1 faut indiquer ici que les canaux de transmission hertzienne de télévision sont relativement bruyants et qu'il faut pro téger efficacement les données transmises contre les erreurs. En particulier, les octets de l'en-tete doivent être tout spécialement protégés, et c'est pourquoi on prévoyait dans le système décrit ci-dessus que chaque octet était en réalité un octet redondant comportant quatre bits utiles et quatre bits de redondance, les bits de redondance étant codés par exemple selon le code normalisé dit de Hamming.
Or, quatre bits utiles dans un octet de format ne permettent pas de définir un nombre supérieur à seize. On résolvait le problème d'une maniere assez lourde d'emploi,~ en désignant non pas un format effectif, mais un numéro de format, chaque format correspondant à un nombre d'octets particulier, et en coupant les paquets ne comportant pas un nombre d'octets correspondant è un format existant.
La présente invention se fonde sur plusieurs remarques.
La première est que les données transmises seront le plus souvent des pages de texte où les caractères alphanumériques seront transmis tout simplement suivant le code binaire normalisé ASCII, c 'est-è-dire le code actuellement utilisé pour les téléimprimeurs.
Dans ce code, tous les caractères alphanumériques, ainsi qu'un certain nombre de codes de commande, sont des octets comportant sept bits utiles et un bit de parité. Parmi les codes de commande, il existe un code dit code NUL , qui est simplement un code de bourrage qui n'a aucune signification particuliere, mais qui peut être utilisé pour remplir des durées d'émission dans lesquelles aucune information n'est transmise. I1 parait donc possible d'ores et déjà de supprimer l'octet de format si on sait que les données numériques transmises sont des pages de télétexte en code ASCII.
Une deuxième remarque est que les systemes connus s'inspirent de la transmission de textes dans lesquels toutes les données sont découpées en octets, et ils ne peuvent travailler que dans ces conditions. Si le découpage est différent, les procédés utilisés ne permettent plus le décodage des données transmises. Un exemple d'inadéquation du découpage en octets est la transmission musicale sous forme numérique : il est couramment admis qu'il faut entre onze et quatorze bits pour définir des niveaux de son per mettant une reproduction sonore avec une dynamique suffisante.
D'autres exemples pourraient être trouvés, et d'ailleurs, même dans le cas de traitements de données de texte, on s'oriente actuellement de plus en plus vers une transmission par chaînes de bits quelconques.
I1 est donc souhaitable d'envisager une procédure de transmission permettant aussi bien la réception et la reconnaissance de données découpées en octets que la réception et la reconnaissance de données découpées autrement ou transmises tout simplement en chaines de bits.
Une troisième remarque est que, dans les systèmes proposés, on a pris grand soin de protéger les informations de l'en-té- te des paquets, puisqu'on les a codées en octets redondants de
Hamming, mais on n' a rien prévu pour protéger les données ellesmêmes. Or, comme on l'a dit, les canaux de transmission sont bruyants et il est souhaitable de terminer chaque paquet de données par un code de détection et de correction d'erreurs
On admet qu'un code correcteur capable de corriger une erreur dans un paquet de données nécessite environ dix bits, soit en pratique deux octets si le découpage des données est fait en octets. liais, l'utilisation de deux octets réduit encore la capacité de transmission de chaque paquet.Un des buts de l'invention est d'essayer d'optimiser la capacité de transmission et la protection contre les erreurs aussi bien dans l'en-tête des paquets que dans les données transportées elles-mêmes.
Enfin, un but de l'invention est de proposer un procédé de diffusion de données qui rende le réseau de transport des données aussi "transparent" que possible vis-à-vis de la structure des données transportées. Ceci signifie que l'on doit pouvoir envoyer des données de structures différentes avec un minimum de conventions implicites entre la source de données et les réceptueurs Un exemple de convention implicite que la présente invention cherche à éliminer pour rendre le réseau plus transparent est la convention selon laquelle les données sont découpées en octets.
Pour atteindre ces différents buts, et pour éliminer un certain nombre d'inconvénients des systèmes de diffusion de données proposés jusqu'à maintenant, la présente invention propose un procédé de transmission de paquets de données, avec un agencement particulier des paquets les uns par rapport aux autres et un agencement particulier des en-têtes de ces paquets (et plus prEcisé- ment de la seconde partie d'en-tête), cet agencement étant différent selon les structures de données transportées dans les paquets, afin que l'on puisse transmettre soit des informations agencées en octets de télétexte selon le code ASCII, soit des informations agencées autrement, et notamment en channes de bits.
Selon l'invention, on transmet, dans une même voie numérique, les paquets de la manière suivante
a) les paquets sont transmis par 'wagons" ne comprenant que des paquets correspondant à des données de même type
b) chaque wagon comprend d'abord un ou plusieurs paquets dits "de procédure spécifiques au wagon et indiquant notamment le type de données transmises dans le wagon, des paquets de procédure spécifiques étant prévus notamment pour les wagons de transmission de télétexte en code ASCII et pour les wagons de transmission de données par channes de bits ;;
c) chaque seconde partie d'en-tête d'un paquet de procédure comprend d'abord un octet ou plusieurs non susceptibles d'être confondus avec un des symboles du code ASCII utilisés effectivement dans la transmission de données à sens unique , la première partie d'en-tête peut être celle qu'on a déjà mentionnée;
d) les paquets de données correspondant aux wagons de transmission de texte selon le code ASCII comprennent la première partie de l'en-tEte suivie immédiatement des données à transmettre agencées en octets selon le code ASCII et utilisant le code de bourrage "NUL" pour remplir les fins de paquets non pleins ;;
e) les paquets de données correspondant aux wagons de transmission de données agencées en channes de bits comprennent une seconde partie d'en-tête comportant au moins
- un bit indiquant si le paquet est plein ou non,
- et si le paquet n'est pas plein, un nombre de bits fixe suffisant pour indiquer combien de bits de données sont contenus dans le paquet.
L'invention permet donc de transmettre des données de types différents ; le paquet de procédure qui se trouve en tête de chaque wagon définit la structure des données qui suivent. S'il indique que les données sont en code ASCII, aucun octet de format ne sera prévu dans les paquets de données du wagon ; en tant que correcteur d'erreurs, on utilisera à la fin du paquet un code de parité longitudinale en un seul octet. Si le paquet de procédure indique qu'il s'agit d'une transmission en channes de bits, les paquets de données suivants seront dans la grande majorité des cas des paquets pleins, auquel cas il ne sera pas nécessaire d'indiquer un format particulier ; c'est seulement si le paquet n'est pas plein qu'on indiquera, par une instruction de formait, combien de bits sont contenus dans le paquet.
Par ailleurs, selon une autre caractéristique de l'invention, on divise les wagons en malles correspondant à des groupes dtinformations à distinguer les uns des autres, surtout pour les informations émises en chaines de bits. Chaque malle comprend plusieurs paquets. Dans ce cas, un octet de Hamming est prévu dans la seconde partie d'en-tête des paquets de données agencées en chat- nes de bits, cet octet comprenant quatre bits utiles qui sont:
- un bit indiquant si le paquet est un début de malle ou non,
- un bit indiquant si le paquet est une fin de malle ou non,
- un bit indiquant si le paquet est plein ou non,
- un bit indiquant le chiffre de poids supérieur du nombre binaire représentant le nombre de bits de données du paquet, ce bit étant forcé-à 1 si le paquet est plein.
D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description détaillée qui suit et qui est faite en référence aux dessins annexés dans lesquels
la figure 1 représente un modele de paquets de données numériques à transmettre pendant la durée d'une ligne de balayage de télévision ;
la figure 2 représente des paquets de données découpés en octets
la figure 3 représente des paquets de données qui sont des suites de caractères du code ASCII
la figure 4 représente des paquets de données en chaines de bits
la figure 5 représente des paquets de procédure.
Les paquets de données comprennent chacun un en-tête destiné à leur identification, suivi des données numériques proprement dites (figure 1). On peut considérer que l'en-tête est divisé en une première partie et une deuxième partie.
La premiere partie peut être celle qui a déjà été men- tionnée à propos des systemes antérieurs : elle peut comprendre deux octets de synchronisation SY1 et SY2, un octet de départ SO, un ou plusieurs octets d'adresse, SA1, SA2, SA3 (cette adresse peut inclure un numéro de voie si les paquets sont transmis sur plusieurs voies avec multiplexage de ces voies), et enfin un indice de continuité IC qui termine la première partie de l'en-tête des paquets.
La deuxième partie de l'en-tête comprend une séquence caractéristique SC à laquelle s'intéresse la présente invention.
Dans les systèmes déjà proposés, cette deuxieme partie n'existait pas ou comprenait seulement un octet de format indiquant le nombre d'octets de données qui suivent dans le paquet.
La deuxième partie est suivie par les données proprement dites, et on peut terminer ces données par un code correcteur CC comprenant un nombre de bits plus ou moins important selon la puissance de correction désirée.
Selon l'invention, les paquets peuvent transporter des données agencées en octets ou agencées autrement, et la séquence caractéristique SC dépend de cet agencement. De même, le code correcteur CC peut dépendre aussi de cet agencement.
Toutefois, ce ntest pas la séquence caractéristique SC d'un paquet de données qui définit la structure des données qui arrivent ensuite. Au contraire, cette structure est définie pour tout un ensemble de paquets qui arrivent successivement sur une même voie, ensemble que l'on appellera un "wagon" de données.
Ainsi, sur une voie, les données arrivent par wagons comprenant chacun une série de paquets dans lesquels les données transportées ont la même structure. On peut diviser les wagons en malles comportant plusieurs paquets chacune, afin de séparer des groupes d'informations selon une articulation logique pour l'utilisateur : par exemple, on pourrait imaginer qu'un wagon correspond à un magazine et que les malles correspondent aux pages de ce magazine. Cette notion de malle a surtout un aspect pratique. De plus, on peut faire coïncider la notion de malle avec la notion d'adresse demandée par l'utilisateur. On peut aussi s'en servir pour faire en sorte que si une perte de paquets se produit, la malle toute entiere soit recherchée à nouveau (dans un système où les informations sont émises cycliquement sur le canal de télévision).
Chaque wagon de données comprend donc plusieurs malles et la première malle qui se présente dans un wagon est une malle dite de procédure, qui a essentiellement pour fonction de permettre la reconnaissance du type de wagon dont il s'agit (notamment wagon de télétexte ou wagon de chaînes de bits). La malle de procédure peut comprendre plusieurs paquets, ou en pratique un seul paquet de procédure ; elle est suivie d'une ou plusieurs malles de données.
Les séquences caractéristiques des paquets de données seront tres différentes selon qu'elles concernent des paquets de données de télétexte ou des paquets de données en chaînes de bits, ou encore d'autres types de paquets, et toutes ces séquences caractéristiques devront être différentes des séquences caractéristiques SCP concernant les paquets de procédure.
La difficulté est de trouver des séquences caractéristiques aussi peu encombrantes que possible et permettant de distinguer les divers cas de figures.
Tout d'abord, étant donné la nécessité de protéger fortement contre les erreurs ces séquences caractéristiques, on les découpera en octets protégés individuellement. Le nombre d'octets est variable de O à 3 dans les divers types de séquences.
On a représenté à la figure 2 des paquets de données appartenant à des wagons transportant des données dont la seule ca ractéristique est qu'elles sont découpées en octets. I1 s'agit du découpage effectué dans les systèmes qui sont actuellement proposés. On l'a représenté d'une part pour faire comprendre ce qui a déjà été proposé, et d'autre part pour montrer que le procédé de transmission selon l'invention peut accepter, si on le désire, ce type de découpage.
La ligne a représente la structure d'un paquet plein, et la ligne b la structure d'un paquet non plein. A la figure 2 comme aux figures suivantes, on a supprimé du paquet la première partie de l'en-t8te dont la structure peut être celle décrite en référen- ce à la figure 1. Les paquets sont donc supposés commencer par la séquence caractéristique SC.
Cette séquence comprend un octet de format FH à quatre bits utiles et quatre bits de redondance codés selon le code de
Hamming. Cet octet FH désigne un numéro de format parmi seize, chaque numéro de format correspondant à un nombre d'octets bien déterminé du paquet de données.
Les données proprement dites suivent l'octet FE et sont terminées de préférence par deux octets de correction d'erreurs CCî et CC2. Si N max est le nombre d'octets maximum du paquet, y compris la séquence caractéristique, le nombre d'octets de données utiles est N max - 3.
L'octet FR est toujours le même pour tous les paquets pleins.
La ligne b représente un paquet de données qui n'est pas plein. Il a la même structure que celui de la ligne a , mais il est plus court et l'octet FH qui sert de séquence caractéristique désigne un format quelconque parmi seize. Le nombre N d'octets du paquet doit correspondre à un des quinze formats possibles. Sur les N octets, N - 3 sont des données utiles Si, comme à la ligne a, le paquet est terminé par un code correcteur d'erreurs à deux octets CCI et CC2.
On peut remarquer ici que dans les wagons de ce type on ne rencontrera jamais de paquets dont la séquence caractéristique soit un code de Hamming nul, ctest-à-dire dont les quatre bits utiles sont 0000. En effet, ce code particulier désignerait, dans les systèmes proposés actuellement, un paquet ne comportant pas d'octets, ce qui n'a pas de signification.
A la figure 3, on a représenté des paquets de données correspondant à une transmission de télétexte en code ASCII. Dans ce cas, la séquence caractéristique d'en-tête est réduite à zéro et les paquets de données présentent un coefficient de remplissage maximal.
A la ligne a, on a représenté un paquet de données situé en début de malle de télétexte : comme cela est courant en télétexte, on peut définir le début de malle par des codes ASCII particuliers, tels que SOH ("Start Of Heading), et RS ('Record Separator'). Ces caractères sont des octets avec sept bits utiles et un bit de parité comme tous les caractères du code ASCII. Ils sont suivis d'autres octets du code ASCII, qui constituent le texte à transmettre. Ces octets représentent des lettres, chiffres, symboles, caractères de commande, désignés sur la figure 3 par la référence ISO.Les paquets de données transportant ainsi des octets du code ASCII ont une longueur constante et le dernier octet de chaque paquet est un octet de parité longitudinale PL qui sert de code correcteur d'erreurs à l'ensemble du paquet.
On peut remarquer en effet qu'un code de parité longitudinale, dont chaque bit représente la parité de la somme des bits de même rang de tous les octets qui précèdent, constitue un excellent code correcteur d'erreurs n' occupant qu'un espace restreint-, car il permet, en combinaison avec le fait que chaque octet ASCII comporte luimême un bit de parité, de détecter une erreur dans un octet quelconque et de localiser dans cet octet le bit erroné.
ta ligne b de la figure 3 représente un paquet de données en milieu de malle de télétexte. La séquence caractéristique de ce paquet est réduite à zéro. Le remplissage du paquet en données utiles est maximal, seul le dernier octet étant encore un code de parité longitudinale PL.
La ligne c représente un paquet de données qui est une fin de malle de télétexte. Ce paquet comprend d'abord la fin du télétexte, c'est-à-dire des octets ISO, puis des octets qui sont des codes de commande du code ASCII et qui indiquent une fin de texte, par exemple un octet ETX du code ASCII ('End of Tex ) et un octet EOT (zend Of Transmission"). Ces codes sont couramment utilisés en télétextes et font partie tout naturellement de la séquence transmise. Si le paquet comporte encore des emplacements d'octets libres, on utilisera ici le code de bourrage NUL pour donner au paquet de fin de malle la même longueur que les autres.
Le dernier octet sera encore un octet de parité longitudinale.
Il faut noter ici que le récepteur doit être capable de diriger les caractères reçus après la première partie de l'en-tête des paquets de données vers un décodeur apte à décoder les caractères ASCII, alors que dans le cas de la figure 2, le récepteur devait diriger le premier octet vers un décoder capable de décoder un code de Hamming. C'est le paquet de procédure ou la malle de procédure placée en tête du wagon correspondant qui prepare le récepteur à recevoir les codes de l'un ou l'autre type et à les aiguiller vers les décodeurs appropriés selon le type de wagon et selon la position des octets dans le paquet.
A la figure 4, on a représenté des paquets de données correspondant à des wagons de transmission de données en chaînes de bits. Là encore, le paquet de procédure qui est en tête du wagon prépare le récepteur 1 recevoir des paquets de ce type.
Ces paquets comportent comme séquence caractéristique SC essentiellement un octet à quatre bits utiles et quatre bits de redondance codés selon le code de Hamming.
Etant donné que la plupart des paquets seront pleins, on ne définit un format de paquets dans la séquence caractéristique
SC que lorsque le paquet n'est pas plein. Un des bits de l'octet de Hamming définira si le paquet est plein ou non plein. Un autre bit de l'octet de Hamming définira le chiffre de plus fort poids du nombre de bits du paquet dans les cas où le paquet n'est pas plein. Dans le cas où le paquet est plein, ce bit sera forcé à 1.
I1 reste deux bits utiles dans l'octet de Hamming. On peut s'en servir pour définir les début et fin de malle : le pre- mier bit est à 1 si le paquet de données constitue un début de malle, il est à O dans le cas contraire. Le deuxième bit est à 1 si le paquet est une fin de malle ; il est à O dans le cas con traire.
La ligne- a de la figure 4 montre un paquet plein qui constitue un début de malle. Le premier bit utile de la séquence caractéristique est à 1 ; le deuxième bit est à O si on suppose que la malle ne se termine pas dans ce paquet 5 le troisième bit est à O et indique qu'il s'agit d'un paquet plein. Le quatrième bit utile est forcé à 1, mais il nta pas de signification particu lière dans ce cas.
L'octet de Hamming est suivi des données transmises en chaînes de bits, deux octets étant réservés à la fin pour constituer des codes correcteurs d'erreurs CC1 et CC2. On considère que deux octets permettent une bonne correction d'erreur pour ce type de paquet.
La ligne b de la figure 4 montre un paquet correspondant à un milieu de malle, ctest-à-dire ni un début, ni une fin : le premier bit utile qui est le bit de début de malle est à 0, le second qui est le bit de fin de malle est également à O ; le troisième est à O et le quatrieme à 1 car un paquet de milieu de malle est en principe plein. Les codes correcteurs d'erreur CC1 et CC2 terminent le paquet après la transmission des données.
La ligne c montre un paquet de fin de malle : le deuxième bit utile est à l. Le premier est ici à 0, mais il peut être à 1 si la malle ne comporte qu'un paquet qui est à la fois un début et une fin de malle.
La ligne d montre un paquet plein, quelle que soit sa place dans la malle : le troisième bit utile est à O et le quatrième est forcé à 1.
Enfin, la ligne e montre la constitution d'un paquet non plein : le troisième bit utile est à 1. Le quatrième bit utile définit le chiffre de plus fort poids du nombre de bits contenus dans le paquet ; les autres chiffres de ce nombre sont indiqués dans les deux octets qui suivent et qui sont également codés selon un code de Hamming, de sorte que neuf bits permettent de désigner le nombre.de bits du paquet, ce qui est suffisant pour les longueurs de paquets considérées (environ 40 octets).
te paquet est encore terminé par deux octets CC1 et CC2 de correction d'erreurs.
Ainsi, c'est seulement dans le cas rare où les paquets ne seront pas pleins que l'on utilisera trois octets pour la séquence caractéristique, un seul octet étant suffisant dans la majorité des cas, cet octet servant en plus à définir des séparations entre malles.
La figure 5 représente la constitution des paquets de procédure : ceux-ci sont tous divisés en octets à quatre bits utiles et quatre bits de redondance codés selon le code de Hamming afin d'assurer une sécurité élevée contre les erreurs. La séquence caractéristique SC de la deuxième partie d'en-tête de ces paquets comprend au moins un octet (de préférence deux) de Hamming.
Bien entendu, il faut que cette séquence caractéristique, indiquant qu'il s'agit d'un paquet de procédure et non pas d'un paquet de données dsun type ou d'un autre, soit reconnaissable des autres séquences caractéristiques déjà decritesi afin que le récepteur puisse distinguer qu'il s'agit d'un paquet de procédure en tête d'un wagon de données dont le type est justement défini par le contenu de ce paquet de procédure.
Les séquences caractéristiques déjà utilisées ou snscep- tibles d'entre utilisées dans les paquets de données déjà décrits sont évidemment indisponibles pour définir une séquence caractéristique de paquets de procédure puisqu'il y aurait confusion possible.
On remarquera cependant que; selon l'invention, on stest arrangé dans les paquets de données en chaînes de bits pour ne pas utiliser, comme premier octet de la séquence caractéristique, l'octet de Hamming dont les quatre bits utiles sont 0000. De même, dans les paquets de données divisés en octets de la figure 2 > il n'apparaîtra jamais l'octet de Hamming 0000 qui indiquerait un paquet de données de longueur 0.
Par contre, dans les malles de données de télétexte pour lesquelles on n'a prévu aucune séquence caractéristique puisqu'il n'y a pas de format à indiquer et que les divisions des paquets en malles peuvent se faire par des caractères de commande faisant justement partie des caractères ASCII, il peut se trouver que n'importe quel octet du code ASCII se situe en début de paquet.
I1 faut donc que la séquence caractéristique des paquets de procédure, qu'elle comporte un ou deux octets ou plus, ne se confonde pas avec un octet ou plusieurs octets du code ASCII.
Or, justement, l'octet de Hamming nul, qui était le seul pratiquement que l'on puisse utiliser si l'on voulait pouvoir transmettre des paquets du type de la figure 2, correspond à un octet du code ASCII. Cet octet esc le caractere NACK du code
ASCII. En effet, l'octet de Hamming nul et Itoctet NACK du code
ASCII s'écrivent tous deux 10101000.
Bien qu'il y ait cette possibilité de confusion, on utilise selon l'invention comme premier octet de la séquence caractéristique des paquets de procédure le code Hamming nul HO, car, en transmission de télétexte à sens unique sur canal de télévision, le symbole NACK ne sera jamais utilisé puisqu'il a justement comme signification, en télétexte, un accusé de réception négatif que le système de transmission de données ne sera pas amené à utiliser (NACK = Non "Non Acknowledge).
De ce fait, l'apparition du code de Hamming nul, à la première position d'octet de la seconde partie d'en-tête d'un paquet de données, signifie qu'il s'agit d'un paquet de procédure.
Toutefois, par sécurité, pour éviter qu'une erreur sur un ou deux bits ne transforme le code de Hamming nul en un octet lisible selon le code ASCII, on renforce la séquence caractéristique des paquets de procédure en prévoyant qu'elle comprend soit deux octets de Hamming nul, soit un octet de Hamming nul suivi d'un octet de
Hamming 0001 qui, lui aussi, correspond à un octet ASCII qui ne sera normalement pas utilisé en transmission de données : il s'agit de l'octet STX ("star of Tex').
La figure 5 montre à la ligne a un premier paquet de procédure dont la séquence caractéristique comprend un octet de Hamming HO (0000) et un octet de Hamming H1 (0001). Les octets qui suivent, désignés par HX, sont des octets de Hamming quelconques auxquels on donne des significations concernant le décodage des paquets de données qui vont suivre. Ces indications de procédure concernent évidemment, d'une part, le type de données transmises ultérieurement, de manière que le récepteur soit prêt à recevoir des séquences caractéristiques ultérieures sous une forme bien déterminée ; elles peuvent concerner, d'autre part, toutes sortes d'indications de procédure, telles que la présence, la nature et la position du ou des codes correcteurs d'erreurs utilisés, la longueur maximum des paquets de données, des informations sur la structure des malles, etc.
La ligne b de la figure 5 montre une autre séquence caractéristique possible pour un paquet de procédure ; cette séquence comprend tout simplement deux codes de Hamming nul HO. On peut utiliser la séquence caractéristique HO, H1 par exemple pour un premier paquet d'une malle de procédure et la séquence HO, HO pour les paquets suivants de la malle de procédure du wagon. On peut prévoir, à la fin de la malle de procédure, un octet HS caractéristique qui indique cette fin.
I1 pourra être nécessaire de prévoir un instant de silence à l'émission après la fin des paquets de procédure pour laisser au récepteur le temps de l'interprétation de la procédure avant la réception du premier paquet de données.
On aura remarqué dans tout ce qui précède que toutes les secondes parties d'en-tête des paquets de données ou de procédure sont découpées en octets pour faciliter le travail de décodage du récepteur, sans que les données transmises elles-mêmes soient obligatoirement agencées en octets.
Note : Les codes Hamming et le code ASCII sont bien connus ; on rappelle cependant qu'un octet de Hamming s'écrit bl, b2, b3, b4, b5, b6, b7, b8 où bl est le premier bit transmis, où b2, b4, b6 et b8 sont les bits utiles de l'octet et bl, b3, b5, b7 sont les bits redondants, avec
b7 b8 + b6 + b4
. b5 = b6 + b4 + b2*
b3 = b4 + b2* + b8
bl = b2* + b8 + b6 où b2* est le complément de b2 et où le signe + désigne une opération OU exclusive.
Ainsi, le code de Hamming nul (0000) correspond à l'octet 10101000 et le code de Hamming 0001 correspond à l'octet 01000000.

Claims (10)

REVENDICATIONS.
1. Procédé de transmission à sens unique de données numériques par paquets comprenant chacun un en-tête suivi de données, l'en-tête comprenant une première partie suivie d'une séquence caractéristique (SC), caractérisé par le fait que, dans le but de transmettre des types de paquets différents correspondant respectivement à différents types d'agencement de données numériques qui sont
- soit des informations agencées en octets codés selon le code ASCII avec bit d'imparité exclusivenent,
- soit des informations agencées autrement, et notamment en channes de bits, on transmet les paquets de la manière suivante ::
a) las paquets sont transmis par wagons ne comprenant que des paquets correspondant à des données de même type,
b) chaque wagon comprend d'abord un ou plusieurs paquets dits de procédure", spécifiques au wagon et indiquant notamment le type de données transmises dans le wagon, des paquets de procé- dure spécifiques étant prévus notamment pour les wagons de transmission de télétexte en code ASCII et pour les wagons de transmission de données par chaînes de bits,
c) chaque séquence caractéristique (SC) d'un paquet de procédure comprend d'abord un octet (HO) ou plusieurs non susceptibles d'être confondus avec un des symboles du code ASCII utilisés effectivement dans la transmission de données à sens unique,
d) les paquets de données correspondant aux wagons de transmission de texte selon le code ASCII comprennent la première partie de l'en-tête suivie immédiatement des données à transmettre agencées en octets selon le code ASCII et utilisant le code de bourrage NUL pour remplir les fins de paquets non pleins,
e) les paquets de données correspondant aux wagons de transmission de données agencées en chaînes de bits comprennent une seconde partie d'en-tête comportant au moins
- un bit indiquant si le paquet est plein ou non,
- et, si le paquet n'est pas plein, un nombre de bits fixe suffisant pour indiquer combien de bits de données sont contenus dans le paquet.
2. Procédé selon la revendication 1 caractérisé par le fait que l'octet utilisé au début de la séquence caractéristique des paquets de procédure est le code NACK (10101000).
3. Procédé selon la revendication 2 caractérisé par le fait que l'octet NACK est suivi d'un autre octet NACK ou d'un octet STX (01000000).
4. Procédé selon l'une des revendications 1 à 3 caractérisé par le fait qu'un paquet de procédure spécifique est prévu pour indiquer que le wagon dont il constitue un début va transmettre des données découpées en octets avec un octet de format en seconde partie de chaque paquet de données du wagon, cet octet comportant quatre bits utiles et quatre bits de redondance codés selon un code de Hamming et indiquant selon une table particulière le nombre d'octets de données contenus dans le paquet.
5. Procédé selon l'une des revendications 1 à 4 caractérisé par le fait que les paquets de procédure sont découpés en octets (HX) ayant chacun quatre bits utiles et quatre bits de redondance codés selon un code de Hamming.
6. Procédé selon l'une des revendications 1 à 5 caractérisé par le fait que toutes les séquences caractéristiques de paquets sont découpées en octets.
7. Procédé selon l'une des revendications 1 à 6 caractérisé par le fait que la séquence caractéristique des paquets de données des wagons transportant des données agencées en chaînes de bits comprend un octet à quatre bits utiles et quatre bits de redondance codés selon le code Hamming, deux des bits utiles étant respectivement
- le bit indiquant si le paquet est plein ou non,
- un bit qui indique le chiffre de poids supérieur du nombre binaire représentant le nombre de bits de données du paquet, ce bit étant forcé à 1 si le paquet est plein.
8. Procédé selon la revendication 7 caractérisé par le fait que le bit indiquant le chiffre de poids supérieur du nombre de bits du paquet est suivi, uniquement dans le cas où le paquet n'est pas plein, de deux octets de format indiquant le nombre de bits du paquet et codés selon le code de Hamming.
9. Procédé selon l'une des revendications 7 et 8 caractérisé par le fait que les deux autres bits utiles de l'octet de
Hamming du début de la séquence caractéristique des paquets des wagons de chaînes de bits servent à indiquer une division des wagons en malles correspondant à des groupes d'informations à distinguer les uns des autres, et pour cela
- l'un de ces deux autres bits utiles indique si le paquet est un début de malle ou non,
- l'autre indique si le paquet est une fin de malle ou non.
10. Procédé selon l'une des revendications 1 à 9 caractérisé par le fait que chaque paquet de données d'un wagon de transmission de texte selon le code ASCII est terminé par un octet de parité longitudinale-(PL) en tant que code correcteur d'erreur des octets de données qui précèdent.
FR8113675A 1981-07-10 1981-07-10 Procede de diffusion de donnees sur canal de television Granted FR2509553A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR8113675A FR2509553A1 (fr) 1981-07-10 1981-07-10 Procede de diffusion de donnees sur canal de television

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR8113675A FR2509553A1 (fr) 1981-07-10 1981-07-10 Procede de diffusion de donnees sur canal de television

Publications (2)

Publication Number Publication Date
FR2509553A1 true FR2509553A1 (fr) 1983-01-14
FR2509553B1 FR2509553B1 (fr) 1983-10-21

Family

ID=9260449

Family Applications (1)

Application Number Title Priority Date Filing Date
FR8113675A Granted FR2509553A1 (fr) 1981-07-10 1981-07-10 Procede de diffusion de donnees sur canal de television

Country Status (1)

Country Link
FR (1) FR2509553A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1987003444A1 (fr) * 1985-11-27 1987-06-04 Hughes Aircraft Company Unite d'interface de donnees numeriques
EP0306208A2 (fr) * 1987-09-02 1989-03-08 Ing. C. Olivetti & C., S.p.A. Méthode et appareil pour la transmission et/ou la réception de programmes d'ordinateur et/ou données au moyen de télétexte
US4943978A (en) * 1985-11-27 1990-07-24 Hughes Aircraft Company Digital interface unit
FR2667748A1 (fr) * 1990-10-09 1992-04-10 Trt Telecom Radio Electr Systeme de transmission d'informations selon un multiplex temporel presentant une structure variable.
EP0505659A1 (fr) * 1991-02-28 1992-09-30 Rai Radiotelevisione Italiana Méthode de transmission de messages sur un canal de télévision dans le système télétexte

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
EXBK/80 *

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1987003444A1 (fr) * 1985-11-27 1987-06-04 Hughes Aircraft Company Unite d'interface de donnees numeriques
US4943978A (en) * 1985-11-27 1990-07-24 Hughes Aircraft Company Digital interface unit
EP0306208A2 (fr) * 1987-09-02 1989-03-08 Ing. C. Olivetti & C., S.p.A. Méthode et appareil pour la transmission et/ou la réception de programmes d'ordinateur et/ou données au moyen de télétexte
EP0306208A3 (en) * 1987-09-02 1990-08-29 Ing. C. Olivetti & C., S.P.A. System for the transmission and/or reception of computer programs and/or data by way of teletext
FR2667748A1 (fr) * 1990-10-09 1992-04-10 Trt Telecom Radio Electr Systeme de transmission d'informations selon un multiplex temporel presentant une structure variable.
EP0480506A1 (fr) * 1990-10-09 1992-04-15 Philips Communication D'entreprise Système de transmission d'informations selon un multiplex temporel présentant une structure variable
US5251217A (en) * 1990-10-09 1993-10-05 U.S. Philips Corporation Time-division multiplex information transmission system having a variable structure
EP0505659A1 (fr) * 1991-02-28 1992-09-30 Rai Radiotelevisione Italiana Méthode de transmission de messages sur un canal de télévision dans le système télétexte

Also Published As

Publication number Publication date
FR2509553B1 (fr) 1983-10-21

Similar Documents

Publication Publication Date Title
EP0019545B1 (fr) Système de vidéographie muni de moyens de protection contre les erreurs de transmission
EP0627821A1 (fr) Procédé et dispositif d'entrelacement d'une séquence d'éléments de données
FR2678121A1 (fr) Dispositif d'insertion de paquets numeriques dans un canal de transmission.
FR2839405A1 (fr) Procede de transmission et de reception de paquets de longueur variable base sur le codage fec(forward error correction)
EP0605312A1 (fr) Procédé de transmission d'informations à débit élevé par allocation multiple de blocs, procédé de réception associé et dispositif de réception pour sa mise en oeuvre
FR2570234A1 (fr) Procede de transmission de donnees par interface et dispositif de liaison par interface pour la mise en oeuvre de ce procede
EP1344151A1 (fr) Procede pour diviser des documents structures en plusieurs parties
FR2799320A1 (fr) Procede d'equilibrage de debit entre des canaux de transport de donnees, dispositif, station de base et station mobile correspondants
EP1445882B1 (fr) Trame de transmission de données, et procédé et dispositif d'émission et de réception d'une telle trame
EP0066512A1 (fr) Procédé de codage de données binaires, et son application à un système de transfert de signal vidéo numérisé sur bande magnétique
FR2509553A1 (fr) Procede de diffusion de donnees sur canal de television
EP0430126B1 (fr) Procédé et dispositif de transmission numérique d'informations, avec demande automatique de retransmission, ou "ARQ"
EP0648063B1 (fr) Méthode et dispositif pour la transmission d'une suite de cellules ATM
EP0238382A1 (fr) Dispositif de démultiplexage de paquets d'un signal de radiodiffusion de type MAC/PAQUETS
EP1989807B1 (fr) Procede et systeme permettant de transmettre un message s' exprimant au moyen d' un polynome
FR2522908A1 (fr) Procede de transmission d'une voie de service, susceptible d'etre modifiee en cours de transmission, emetteur et recepteur pour la mise en oeuvre d'un tel procede
EP0982866B1 (fr) Procédé de codage convolutif et de transmission par paquets d'un flux série de données numériques, procédé et dispositif de décodage correspondants
FR2709902A1 (fr) Trame supportant différents débits, émetteur et récepteur adaptés à une telle trame.
FR2873532A1 (fr) Procede de codage et de decodage d'une sequence d'elements, signal, codeur, decodeur, programmes d'ordinateur et moyens de stockage correspondants
EP1397896A1 (fr) Procede de codage
FR2785757A1 (fr) Procede et dispositif de compression, procede et dispositif de decompression de format numerique
EP0024236B1 (fr) Procédé de transcodage d'informations pour transmission sur ligne et système de transmission l'utilisant
EP1455537A1 (fr) Protection de données avec en-tête contre les erreurs dans un système de transmission
WO2003007615A1 (fr) Methode de protection et de correction d'une information de scene multimedia
EP2163020A1 (fr) Methode a base de codes correcteurs d'erreurs applicable a un flux de donnees multimedia a debit variable

Legal Events

Date Code Title Description
ST Notification of lapse