Radio Data System (RDS) : analyse du canal numérique transmis par les stations radio FM commerciales, introduction aux codes correcteurs d’erreur – Partie 2/2

5.1 Une erreur

L’annexe C de [13] nous explique que le code correcteur d’erreur est implémenté, lors de l’émission, comme une combinaison linéaire (somme modulo 2, ou XOR) des bits à émettre.

Une transformation linéaire s’implémente soit de façon logique par un registre à décalage avec des points de ponction pour alimenter les portes XOR (Fig. 7), mais comme nous prototypons sous GNU/Octave, nous continuons à exploiter l’approche matricielle [21, p. 244] : une matrice de 16 x 10 calcule les 10 bits de sortie compte tenu des 16 bits d’entrée. Nous avons vu que nous ajoutons un identifiant de bloc pour la synchronisation à ce code de correction d’erreur : le message transmis comprend donc les 16 bits de données suivis des 10 bits de correction sommés au code de bloc. En terme GNU/Octave, cela s’écrit :

Si tout se passe bien, ce message 0 1 0 0 1 0 1 0 0 1 0 0 1 1 0 1 0 1 0 0 1 0 1 0 1 0 qui contient encore les deux caractères ASCII JM est transmis, et reçu sans corruption de bit, donc le décodage que nous avons vu s’obtient côté récepteur par :

et le message reçu mIr doit donner 0 après soustraction du syndrome correspondant au bloc A, nommé ici sA2. Cette petite expérience numérique valide le bon fonctionnement du décodage des messages.

Supposons maintenant qu’entre l’émission et la réception, une erreur survienne :

Pouvons-nous faire mieux que rejeter le paquet ? En affichant le résultat du calcul du syndrome, nous constatons qu’en insérant une erreur sur le troisième bit, le syndrome nous indique :

qui dit bien que le troisième bit est corrompu. Cela correspond au fait que les 10 premières lignes de H forment une matrice identité. De façon générale, une erreur sur le Nième bit se détecte par un syndrome égal à la ligne N de H. En effet, une erreur peut survenir sur n’importe quel bit des 26 bits du message : si une erreur survient sur le bit 25 :

nous obtenons :

qui est bien l’avant-dernière ligne de H. La recherche du bit corrompu se généralise donc par

avec num nous indiquant si le syndrome a été trouvé comme ligne de H, et si c’est le cas, ligne nous indique quel bit a été corrompu. Nous améliorons donc notre capacité de décodage de RDS, avec par exemple 24 caractères en plus des 680 déjà acquis sur l’identification de Le Mouv’ (+4%), 9 caractères en plus des 79 déjà acquis pour Virgin (+11%) et 10 en plus des 60 pour BIP (+17%).

Quelques expérimentations avec les deux expressions de la matrice de décodage H constatées auparavant nous convainquent qu’elles fonctionnent de la même façon, puisque les propriétés du code sont conservées par permutation des lignes et colonnes. Ainsi, nous observons par

qu’en encodant un message, y compris l’identifiant (optionnel dans ces expérimentations) de bloc, nous sommes capables d’une part de valider le transfert d’information sans erreur : commenter l’introduction de l’erreur en ligne 19 pour constater que le résultat des deux décodages, avec H1 ou H2, sont tous deux nuls. Par ailleurs, en cas d’introduction d’une erreur, le résultat est bien le contenu de la ligne d’indice égal au numéro du bit erroné.

5.2 Deux erreurs

Retrouver un bit corrompu fonctionne bien, et nous avons compris comment identifier quel bit est corrompu en recherchant la ligne de H qui contient le syndrome après décodage d’un message avec un bit qui a été modifié. Cependant, que se passe-t-il si deux bits sont corrompus ?

Une rapide petite expérience numérique nous met sur la voie :

se traduit par

Deux bits sont désormais à 1 après décodage du syndrome, celui de la deuxième et de la cinquième ligne. L’analyse est donc triviale tant que deux des dix premiers bits ont changé : le numéro des bits modifiés apparaissent dans le syndrome calculé en réception, toujours parce que les 10 premières lignes de H forment la matrice identité. Ce concept se généralise en citant le cours [25] : « Suppose we wish to correct all patterns of t errors. In this case, we need to pre-compute more syndromes, corresponding to 0, 1, 2,… t bit errors. Each of these should be stored by the decoder. ».

Nous devons donc calculer une nouvelle matrice, déduite de H, que nous noterons m2r, qui contient tous les syndromes de 10 bits correspondant aux sommes de toutes les combinaisons possibles de 2 lignes de H. Une approche par boucle for, pas nécessairement la plus élégante pour GNU/Octave, mais qui a le bon goût de fonctionner, donne :

Évidemment, m2r est beaucoup plus grande que H puisque cette fois nous avons tous les couples d’erreurs possibles représentés dans chaque ligne de la nouvelle matrice. Nous nous assurons que toutes les lignes sont uniques – propriété du code capable de corriger deux erreurs de communication :

ne renvoie par de réponse (question : pourquoi [m2runiq,m,n]=unique(m2r,’rows’); renvoie moins de lignes dans m2runiq qu’il n’y en a dans m2r, alors que toutes les lignes sont uniques ?).

Nous pouvons maintenant rechercher quelle paire de bits a changé lors de la transmission par

et comme nous avions pris soin de placer dans solution le couple j et k des lignes de H qui ont été sommées pour donner la ligne de m2r, nous connaissons l’indice k et j des bits modifiés. En effet,

se traduit bien par

dans laquelle nous constatons que la recherche du syndrome mIr dans la matrice H (une modification) ne donne pas de résultat (num=0), mais que la recherche dans m2r donne un résultat, avec le syndrome présent dans la 314ème ligne de m2r, qui a été calculée lorsque j=21 et k=25. Le décodage fonctionne bien. RDS n’annonce que la capacité à corriger 1 ou 2 bits corrompus lors de la transmission, nous arrêtons donc là notre étude du code correcteur d’erreurs.

Le nombre de bits qui peut ainsi être corrigé par un code est déterminé par le concept de distance de Hamming, qui se représente graphiquement comme la distance entre le « bon » message et le message corrompu reçu, en deçà de laquelle la correction est possible (http://fr.wikipedia.org/wiki/Code_correcteur).

La capacité de corriger des transmissions corrompues est au cœur du gain de débit de communication (Fig. 10), que ce soit dans une liaison avec les sondes spatiales lointaines (deep space network) [24] ou en liaison courte portée à faible consommation [26]. Ce survol rapide d’un exemple simple ouvre donc des perspectives d’approfondissement qui restent d’actualité : sans prétendre comprendre comment générer ces codes, l’expérimentation sur des données réelles avec un résultat concret fournit la motivation à approfondir les ouvrages plus théoriques sur le sujet tels que [21] et son excellente mise en relation de compression, cryptographie et correction d’erreurs.

Fig. 10 : Évolution du taux d’erreur en fonction du rapport signal à bruit, pour divers types de codes correcteurs d’erreurs, reproduit de [24, Fig. 7-11, p. 477].

Conclusion

Nous avons analysé le protocole RDS, exploité pour la transmission numérique d’informations associée aux chaînes FM de la bande commerciale incluant le nom de la station ou la nature du programme, en partant de l’acquisition de l’information analogique depuis un récepteur de télévision numérique terrestre, puis extraction de l’information numérique sur la sous-porteuse à 57 kHz, avant d’extraire les trames (en ayant résolu la synchronisation des phrases) et d’en interpréter le contenu. Nous avons finalement abordé la correction d’erreurs pour constater que nous pouvions simuler des erreurs connues et les identifier. En appliquant cette méthode de traitement aux données reçues expérimentalement, nous avons pu retrouver plus de 10% de signaux exploitables additionnels par rapport au cas où nous ne traitions que les informations transmises dans leur intégralité.

Bien des développements seraient nécessaires avant que cette démonstration de principe ne puisse être considérée comme robuste pour un environnement en production, en particulier sur la synchronisation du décodage des trames transmises à 1187,5 bps de façon asynchrone, mais cela se ferait en alourdissant le code proposé au détriment de sa lisibilité. Il nous semble que la démonstration des principes de base de ce mode de modulation est explicite, avec des messages intelligibles et cohérents avec les informations transmises par chaque station. Cet exercice a nécessité environ 2 mois de travail pour aboutir : il s’agit donc d’un bon exercice pour se familiariser avec les diverses couches d’un protocole de communication, en allant de la couche matérielle à la couche session.

Un point décevant est l’absence de transfert précis de temps par ce médium. Nous n’avons reçu que peu de trames de datation (CT, groupe 4A) qui nous permettent de connaître la date et l’heure qu’avec une précision de ±0,1 s au début de chaque minute. Cette déficience sera bientôt corrigée avec le décodage logiciel de DCF77 que nous présenterons dans un autre numéro.

Une archive contenant les scripts GNU/Octave, configuration de GNURadio Companion et fichiers d’exemples, est disponible à http://jmfriedt.free.fr/lm_rds.tar.gz.

Remerciements

Je remercie Thomas Lavarenne pour avoir motivé cette étude par ses interrogations et des échanges constructifs, et Bastien Bloessl pour avoir exprimé l’opinion que le décodage de RDS est trivial [27], un commentaire inacceptable tant que ce protocole avait résisté à nos investigations. Ce défaut de compréhension est maintenant corrigé. G. Cabodevila a amélioré la qualité du code GNU/Octave lors de sa relecture, et É. Carry a clarifié un certain nombre de points. Bien que nous ayons acquis une copie papier de l’ouvrage de Dunod [21], les autres références ont été obtenues auprès de Library Genesis, http://gen.lib.rus.ec, une source indispensable pour nos recherches.

Annexe A : phase ou amplitude ?

Nous avons pris le parti au cours de cette étude de considérer le signal transmis par RDS comme une information modulée en phase, car nos premières tentatives consistant à afficher l’amplitude du signal filtré (Band Pass Filter autour de 57 ± 2,5 kHz) se traduisaient par un signal inexploitable. Bien que la boucle de Costas pour asservir en phase reste nécessaire, afficher la partie réelle au lieu de la phase donne aussi un signal parfaitement exploitable (Fig. 11). Quelques petites oscillations sont visibles sur les symboles les plus longs, qui pourraient se traduire par une fausse détection d’un symbole court si on n’y prend garde : un filtre passe-bas optimisé retire cette fluctuation et garantit une meilleure détection de la nature du signal transmis. En effet, filtrer par une fonction de transfert spectrale quasi-rectangulaire se traduit, par transformée de Fourier de la porte rectangulaire, par une convolution par un sinus cardinal (sin(x) / x) et donc un étalement de chaque symbole sur ses voisins compte tenu du temps de décroissance lent du filtre. Quel que soit le filtrage, tracer l’amplitude du signal (module du complexe) donne une information inexploitable pour la détection des bits : seules la phase ou la partie réelle sont exploitables.

Fig. 11a : graphique pour l’extraction des diverses composantes du signal dans la sous-porteuse RDS après asservissement de l’oscillateur par la boucle de Costas. La phase s’affichera en bleu, la partie réelle en vert, et le module en rouge.

Fig. 11b. En haut : sans filtre passe-bas RRC, la partie réelle présente quelques oscillations sur les symboles les plus longs. En bas : un filtre RRC permet d’atténuer ces artefacts et de rendre la partie réelle du signal exploitable. Dans tous les cas, le module (rouge) est inexploitable.

 


Le filtre Root Raised Cosine (RRC [28]) a été conçu pour pallier à cette déficience : un filtre passe-bande réduisant à la fois l’encombrement spectral et temporel, permettant de filtrer finement un signal tout en évitant un temps de décroissance trop long. Alors qu’un filtre rectangulaire dans le domaine spectral (bleu sur Fig. 12, gauche, cas α = 0) se traduit par un excellent filtrage spectral, mais une réponse temporelle en sinus cardinal très longue avec un zéro aux positions des symboles adjacents, la moindre erreur sur la date d’émission d’un symbole (Fig. 12, cas de gauche de la courbe en temps) se traduit par une contribution de ce symbole sur ses voisins, d’autant plus importante que les symboles voisins sont loin. Le RRC présente aussi des zéros sur les symboles adjacents, mais sa décroissance est bien plus rapide (Fig. 12, droite, cas α = 1), évitant la pollution des voisins en cas d’erreur de synchronisation [29, p.136][30]. Le paramètre α fournit un levier pour passer continûment du meilleur filtrage spectral à l’optimum entre filtrage spectral et étalement temporel de l’impulsion. Le RRC vise donc à optimiser à la fois l’occupation du spectre en réduisant l’encombrement du canal utilisé (réduction de la bande passante B) pour transmettre le flux numérique, tout en maximisant le débit de communication en réduisant l’intervalle de temps 1/B entre les symboles successifs.

Fig. 12 : À gauche : réponse spectrale des filtres RRC avec diverses formes, du rectangle (meilleure sélectivité spectrale) au segment de fonction trigonométrique. À droite : plusieurs impulsions successives dans le temps, filtrées avec diverses formes de RRC, avec l’impulsion de gauche décalée de 20% par rapport à sa date nominale pour une transmission périodique.

 


Annexe B : ajustement de l’horloge de la trame numérique

La modulation de phase nécessite une copie locale de la porteuse du signal radiofréquence sans modulation, une tâche résolue par la boucle de Costas qui élimine la modulation de phase. Une fois les bits visibles sous forme de phase à 0 ou π (pour BPSK), il reste le problème de connaître le rythme auquel les bits sont transmis. L’horloge qui cadence la transmission numérique (par exemple un microcontrôleur sur l’émetteur) n’a aucune raison d’être la même source de fréquence que la porteuse radiofréquence, et il faut donc de nouveau retrouver une copie locale de l’horloge qui cadence le signal numérique pour le décoder (Fig. 13). Diverses stratégies sont disponibles, telles que maximiser le nombre de transitions dans le signal transmis pour permettre l’asservissement de l’horloge locale (cas du codage Manchester qui garantit au moins une transition à chaque bit). GNURadio fournit divers blocs pour la synchronisation de l’horloge cadençant le flux numérique, tels que Clock Recovery (selon l’algorithme publié dans [27]) ou MPSK Receiver. Ces blocs s’alimentent de la sortie de la boucle de Costas qui a éliminé l’erreur grossière de fréquence, et manipulent maintenant les symboles numériques issus du traitement précédent pour ajuster le flux de données. Ces blocs fournissent un échantillon par symbole, rendant le traitement ultérieur très simple (saturation par comparaison – nommé Binary Slicer dans GNURadio – puis analyse de la séquence numérique ainsi formée). Nous validons le bon fonctionnement de ces blocs en affichant le diagramme de constellation, qui comporte en ordonnée la partie imaginaire de la sortie du bloc de traitement et en abscisse la partie réelle. Puisque dans le plan complexe l’angle à l’axe des abscisses est la phase et la distance à l’origine la magnitude, un nuage de points à angle constant et distance constante indique une synchronisation efficace. Un nuage de points « qui danse » ou forme un cercle indique l’absence de synchronisation. La sortie directe de la boucle de Costas fournit une illustration du second point (Fig. 14, droite) tandis que le passage dans un bloc chargé de synchroniser l’horloge cadençant le flux numérique donne bien deux nuages (Fig. 14, gauche) qui sont les deux états possibles attendus en BPSK. Nous constatons ici que le filtre RRC que nous avons vu auparavant, même s’il ne change pas de façon significative la forme du signal d’un point de vue visuel, assiste la synchronisation de l’horloge en réduisant la diffusion de puissance dans un état des symboles numériques vers l’autre. Un filtre passe-bas atteint le même résultat, mais moins efficacement.

Fig. 13 : Chaîne de traitement des informations acquises depuis l’antenne pour retrouver le message (phrases) : dans cette annexe, nous nous intéressons à la synchronisation du message numérique, en rouge.

 

Fig. 14 : En haut : flux de traitement, ajoutant la synchronisation du flux numérique après la synchronisation sur la porteuse (Costas). En bas : diagramme de constellation (mode XY d’un oscilloscope recevant le flux de données complexes) dans les diverses conditions – de gauche à droite, sortie de la boucle de Costas (sans synchronisation de la séquence numérique), synchronisation de l’horloge numérique après un filtre passe-bas, et finalement après un filtre RRC. Deux nuages de points distincts garantissent la capacité à séparer les symboles.


La configuration des blocs de synchronisation telle que décrite dans http://gnuradio.org/redmine/projects/gnuradio/wiki/Guided_Tutorial_PSK_Demodulation nous informe que nous devons tenter de minimiser le nombre d’échantillons par symbole, tout en le maintenant au-dessus de 2. Pour ce faire, un RRC est inséré entre la boucle de Costas et le bloc de synchronisation d’horloge, avec un facteur de décimation qui permet d’atteindre un facteur Omega (ratio de la fréquence d’échantillonnage au débit du flux numérique) proche, mais au-dessus de 2. Dans notre exemple, Omega vaut samp_rate/128/(1187.5*2) avec 128 le produit des décimations des divers blocs de traitements entre la source et la synchronisation d’horloge, 1187,5 x 2 le débit de bits en encodage Manchester, et samp_rate le débit de données issues de la source. Les autres paramètres du bloc de synchronisation restent inchangés. Le RRC est quant à lui configuré avec un débit d’entrée égal au débit de la source divisé du produit des divers facteurs de décimations dans la chaîne de traitement qui le précède, et un débit de symboles égal à 1187,5 x 2 de nouveau, déterminant donc sa fréquence de coupure.

Le fichier issu d’une synchronisation de la porteuse (Costas) et du flux numérique (Clock Recovery ou MPSK) se décode parfaitement avec les scripts proposés dans le texte (section 3), en retirant les 4 premières lignes puisque nous avons désormais 1 échantillon/symbole, et en ne gardant des lignes 8 à 24 que p=angle(r);p=p-mean(p);s=(p>0);s=s-mean(s);s1=s(2:2:end);s2=s(1:2:end-1);. En effet, s est la version saturée de la phase p, dont le décodage par Manchester différentiel considère les valeurs successives des paires d’échantillons initiaux. La suite du traitement (synchronisation sur le syndrome des séquences de 16 bits) reste identique, pour par exemple donner

qui est cette fois parfaite, ou

de nouveau sans corruption de données, voir

ou

qui est proche de la perfection. La date est en accord avec nos attentes : la date est le jour julien modifié 57811, que http://www.csgnetwork.com/julianmodifdateconv.html convertit en 27 Février 2017, l’heure est 7h5{1,4} décalée de 2 demi-heures, qui est bien 8h5{1,4}, heure de l’enregistrement. La trame 4A [13, p.28] est donc convenablement décodée et permet de recevoir l’heure par RDS, avec une mise à jour chaque minute annoncée comme exacte à ±0,1 s près. Ce n’est qu’après avoir inclus la synchronisation d’horloge de la trame numérique que nous obtenons des trames de datation de la forme 4A qui ne sont émises qu’une fois chaque minute. Une proportion trop faible de trames convenablement décodées a toutes les chances de nous faire rater cette séquence exceptionnelle de bits transmis :

Tous les exemples de cette annexe ont été acquis au rythme d’un échantillon complexe (2 x 4 octets) par symbole, tel que le propose la sortie du bloc Clock Recovery MM. Au rythme de 1187,5 x 2 = 2375 Hz, les fichiers d’enregistrement sont typiquement de quelques centaines de kilo-octets pour des acquisitions d’une dizaine de secondes (19000 kB/s).

Annexe C : code PI

Chaque trame RDS transmise contient, dans son premier paquet (bloc A [13, p. 15]), le code PI de la station. Il a été suggéré [13, p. 66] que connaissant ce code PI, unique à chaque station radio, il serait possible de se synchroniser sur cette séquence de bits qui se répète tous les 104 bits (4 blocs de 26 bits), au lieu de se battre avec le code correcteur d’erreur et calculer pour chaque séquence de 26 bits reçus si les 10 derniers bits correspondent au syndrome des 16 premiers bits tel que nous l’avons implémenté. Nous aurions pu réécrire l’histoire de cet article en démontrant ce concept avant d’entreprendre l’implémentation du code correcteur d’erreur, mais la vérité est que la liste des codes PI n’a été trouvée qu’une fois cette prose achevée. En effet, le site http://www.csa.fr/maradiofm/radiords_tableau fournit la liste des codes PI des diverses stations autorisées. Par exemple pour Radio Campus à Besançon, nous apprenons que son code PI est FC3A. En ajoutant dans la boucle de décodage des trames, au même titre que le texte libre ou le nom de la station, le décodage du PI par

en ayant pris soin d’initialiser PI=0 en dehors de la boucle, notre script GNU/Octave de décodage identifie bien PI = FC3A lorsque nous écoutons 102,4 MHz. Le code est bien identifié de cette façon.

Notes et Références

[1] BARISANI A. et BIANCO D., « Hijacking RDS-TMC Traffic Information signals », Phrack 64 (5), 2011 sur http://phrack.org/issues/64/5.html#article, et son archive http://dev.inversepath.com/rds/
[2] LI L., XING G., SUN L., HUANGFU W., ZHOU R., et ZHU H., « Exploiting FM radio data system for adaptive clock calibration in sensor networks », Proc. of the 9th ACM International Conference on Mobile systems, applications and services, p. 169 à 182, 2011.
[3] SYMEONIDIS D., « RDS-TMC spoofing using GNU Radio », Proc. 6th Karlsruhe Workshop on Software Radios, p. 87 à 92, mars 2010, avec une copie fournie par l’auteur de ce papier placée sur http://jmfriedt.free.fr/Symeonidis.pdf
[4] FERNANDES E., CRISPO B., et CONTI M., « FM 99.9, Radio Virus: Exploiting FM Radio Broadcasts for Malware Deployment », IEEE Trans. on Information Forensics and Security 8 (6), p.1027 à 1037, 2013.
[5] GNURadio : http://gnuradio.org
[6] GNU/Octave : http://www.gnu.org/software/octave
[7] Communication Toolbox :http://octave.sourceforge.io/communications/overview.html
[8] Le repliement est un effet de l’échantillonnage périodique à intervalles de temps 
discrets 1/fe, qui suppose que le spectre entre fe/2 et fe/2 se répète tous les fe. De ce fait lors de la décimation d’un facteur N, toutes les composantes spectrales du signal comprises entre fe/(2N) et fe/2 se ramènent entre fe/(2N) et fe/(2N) par translations par pas de fe/(2N). Cet effet est évité en précédant la décimation d’un filtre passe-bas qui élimine efficacement toute composante du signal au-dessus de fe/(2N).
[9] Nous avions introduit le Xlating FIR Filter comme un bloc implémentant une étape fondamentale de la démodulation, à savoir transposition en fréquence, filtrage passe-bas et décimation [10]. Pour rappel, le filtre passe-bas a pour vocation d’atténuer les composantes spectrales du signal après transposition en fréquence au-dessus de la fréquence d’échantillonnage atteinte suite à la décimation : sans ce filtre, tous les signaux au-dessus de la nouvelle fréquence d’échantillonnage se retrouveraient dans la bande de base par repliement spectral lors de la décimation et pollueraient la séquence de traitement qui suit.
[10] FRIEDT J.-M., « La réception de signaux venus de l’espace par récepteur de télévision numérique terrestre », Open Silicium n°13, décembre 2014/janvier-février 2015.
[11] https://bitbucket.org/azimout/gr-rds/
[12] https://github.com/bastibl/gr-rds
[13] European Standard EN 50067, « Specification of the radio data system (RDS) for VHF/FM sound broadcasting in the frequency range from 87,5 to 108,0 MHz », avril 1998, disponible sur http://www.interactive-radio-system.com/docs/EN50067_RDS_Standard.pdf ou pour sa version américaine http://www.nrscstandards.org/DocumentArchive/NRSC-4%201998.pdf
[14] TRETTER S.A., « Communication System Design Using DSP Algorithms, With Laboratory Experiments for the TMS320C30 », Chap. 6 « Double-Sideband Suppressed-Carrier Amplitude Modulation and Coherent Detection », Springer, 1995.
[15] FRIEDT J.-M, CABODEVILA G., « Exploitation de signaux des satellites GPS reçus par récepteur de télévision numérique terrestre DVB-T », Open Silicium n°15, juillet-septembre 2015
[16] http://www.mathworks.com/examples/simulink-communications/mw/rtlsdrradio_product-RBDSSimulinkExample-rbds-rds-and-radiotext-plus-rt-fm-receiver
[17] FRIEDT J.-M, GOAVEC-MÉROU G., « La réception radiofréquence définie par logiciel (Software Defined Radio –SDR) », GNU/Linux Magazine n°153, octobre 2012, p.4 à 33.
[18] WESLEY PETERSON W. et WELDON E.J., « Error-Correcting Codes », 2nd Ed., MIT Press, 1996.
[19] TOPPING P., « RDS decoding for an HC11-controlled radio », Motorola AN495/D, 1994.
[20] GUIDON Y., « Comprendre les générateurs de nombres pseudo-aléatoires », GNU/Linux Magazine n°81, p. 64 à 76, 2006.
[21] DUMAS J. G., ROCH J. L., VARRETTE S., et TANNIER E., « Théorie des codes : compression, cryptage, correction », Dunod, 2007.
[22] HILL R. A., « A First Course in Coding Theory », Oxford University Press, 1990.
[23] PATROIS N., « Réparer un code QR », GNU/Linux Magazine n°198, novembre 2016
[24] http://descanso.jpl.nasa.gov/performmetrics/profileDSCC.html fait apparaître les modes de codage dans les gains significatifs de bande passante de communication, tandis que la Fig. 7-11 (page 477) de https://history.nasa.gov/SP-4227/Chapter07/Chapter07.PDF indique la chute du taux d’erreur avec les améliorations sur les modes de codage de canal.
[25] Notes du cours du MIT 6.02, BALAKRISHNAN H. et VERGHESE G., « Introduction to EECS II : Digital Communication Systems », chapitre 6 : « Linear Block Codes : Encoding and Syndrome Decoding », disponible sur https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-02-introduction-to-eecs-ii-digital-communication-systems-fall-2012/readings/MIT6_02F12_chap06.pdf, 2012
[26] TSIMBALO E., FAFOUTIS X. et PIECHOCKI R., « Fix it, don’t bin it! CRC error correction in Bluetooth Low Energy », Proc. 2nd IEEE World Forum on Internet of Things (WF-IoT), 2015 sur http://eis.bris.ac.uk/~xf14883/files/conf/2015_wfiot_crc.pdf
[27] MEYR H., MOENECLAEY M., FECHTEL S.A ., « Digital Communication Receivers: Synchronization, Channel Estimation, and Signal Processing », John Wiley & Sons, 1998.[28] CUBUKCU E., « Root Raised Cosine (RRC) Filters and Pulse Shaping in Communication Systems », 2012, sur https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20120008631.pdf
[29] BARRY J. R., LEE E. A. et MESSERSCHMITT D. G., « Digital Communication », Springer, 2004.
[30] http://www.dsplog.com/2008/04/22/raised-cosine-filter-for-transmit-pulse-shaping/ qui fournit un script GNU/Octave pour expérimenter avec le filtre RRC.

 

Jean-Michel FRIEDT
[Institut FEMTO-ST, dpt. Temps-fréquence, Besançon]

Retrouvez cet article (et bien d’autres) dans GNU/Linux Magazine n°204, disponible sur la boutique et sur la plateforme de lecture en ligne Connect !

Laisser un commentaire