Modem pour le numérique : Différence entre versions

De Wiki d'activités IMA
(→‎Séance du 05/02/2014 :)
(→‎Séance du 06/02/2014 :)
Ligne 117 : Ligne 117 :
 
-N correspondra à la taille de séquence de longueur 2^N.
 
-N correspondra à la taille de séquence de longueur 2^N.
  
 +
 +
 +
Voir la section "Code Arduino réalisé" en annexe B dans la semaine correspondante.
  
 
==== Possibilités de communications: ====
 
==== Possibilités de communications: ====

Version du 12 avril 2014 à 20:54

Sommaire

Modulateur et démodulateur pour communications numériques

Cahier des charges

Présentation générale du projet

Dans le cadre des TPs d'électronique et de transmission RF, nous avons découvert qu'il existe plusieurs modes de modulation, pour transmettre un signal modulant.

Celles vues en TP au S7 sont la modulation en amplitude, en fréquence, en phase, en BPSK et en QPSK.

Or les modulations en phase, en fréquence et en amplitude étant celles les plus connues, la modulation en QAM (Modulation d'Amplitude en Quadrature) est quant à elle moins connue, mais tout aussi utilisées:

-pour la TNT en 64 QAM (en France).

Exemple de constellation 64QAM.

-pour le WiFi en 64-QAM ou 256-QAM (à vérifier).

Or ces deux dernières étant peu représentées au niveau des travaux pratiques, ce projet permettra de fournir un peu plus de pratique sur les modulations de type QAM (en diagramme I/Q) dans le domaine des radiofréquences (~800MHz).

(Le nombre devant le QAM indique le nombre de points dans le diagramme I/Q qu'on appelle aussi constellation)


On se réserve le droit de faire évoluer le cahier des charges a posteriori, si certaines contraintes étaient amenées à évoluer ou se préciser.

Objectif et intérêt du projet

Pour cela, on nous a fourni des modules commerciaux Mini-circuit pouvant travailler dans les radios-fréquences.

Ceux-ci permettront de mettre en place une grande partie de la chaine de transmission (voir schéma de la chaine de transmission).

Modulation.
Demodulation.

On a tout d'abord à mettre en place une carte FPGA et/ou un dispositif permettant d'envoyer un flux de données numériques continuellement pour pouvoir visualiser le diagramme I/Q (mise en valeur du diagramme I/Q et voir même un diagramme un peu plus complexe que le BPSK ou le QPSK).

Le canal de transmission qui sera un simple fil électrique, mais pourra devenir une antenne réceptrice et émettrice si le temps imparti le permet (mise en valeur du et mesure du Bit Error Rate qui sera bien sûr différent suivant le canal de transmission).

Du côté réception ,après démodulation du signal, une remise en forme et une interprétation des données seront réalisées, celle-ci dépendra bien entendu de la provenance du flux de données (constater le succès ou l'échec d'un envoi de données).

Enfin si le temps le permets on pourra mettre en une place un système de codage de l'information avec par exemple un codage redondant permettant de corrigé l'erreur (À définir, on pourra faire constater l'efficacité d'une méthode de codage au choix).

Étapes/Déroulement du projet

De même que pour le cahier des charges, il se peut que les étapes diffèrent plus ou moins, en fonction des disponibilités, matérielles et contraintes.

=> Caractérisation des blocs Mini-circuits et épluchage des documentations techniques

Avant de les utiliser dans la chaine de transmission, nous avons à faire une caractérisation des blocs fournis:

-la caractérisation du VCO.

-l'étude des possibilités offerte par le modulateur (cela déterminera le nombre de points possible dans la constellation, ie savoir si l'on peut aller au-delà de la QPSK).

-la caractérisation des mélangeurs (Mixer), leurs facteurs réels de multiplication.

=> Utilisation et exploitation des caractérisations

On pourra ensuite trouver les paramètres pour régler correctement dans notre chaine de transmission certains de nos sous-systèmes comme la boucle à verrouillage de phase.

=> Génération d'un flux des données numériques

Comme dit précédemment, l'idéal et d'avoir un flux de données numériques transmis en permanence. Pour cela plusieurs solutions s'offre à nous, on pourra utiliser un montage générateur pseudo aléatoire (un circuit que l'on a fait l'année dernière en Conception de Circuit Électronique). On pourra "émuler" ce montage avec un Arduino, ou bien même le faire au moyen de la Nanoboard. On pourra aussi transmettre des chaines de caractère en continu.

=> Test de la chaine

Une fois les étapes précédentes réalisées, on pourra passer au test de la chaine de transmission. Il faudra vérifier le bon fonctionnement en aval, dedans (boucle a verrouillage de phase), et en amont de la chaine de transmission.

=> Première mesure du Bit Error Rate

Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission. Il est possible que la conception d'un dispositif soit nécessaire que ce soit pour les deux mesures du B.E.R..

=> Antennes

Si toutes les étapes précédentes sont satisfaites, on pourra alors faire un canal de transmission plus intéressant, à savoir l'air. Nous passerons alors à la conception des antennes, émettrice et réceptrice.

=> Deuxième mesure du Bit Error Rate

Il sera temps de mesurer/déterminer le B.E.R. de la chaine de transmission avec un fil électrique en tant que canal de transmission.

=> Codage de l'information et correction d'erreur

En toute fin de ce projet, on pourra même mettre deux dispositifs en aval et en amont de la chaine de transmission. On réalisera alors un codeur et un décodeur permettant de faire de la détection/correction d'erreur.

=> Mise en place d'outil de débogage (tout au long)

La mise en place de simples outils de débogage et primordiale, ceux-ci permettront de vérifier le bon fonctionnement de la chaine.

=> Proposition d'un sujet de TP (tout au long)

Il se trouve que lors du déroulement du projet, on pourra être amené à se poser des questions au niveau des réglages de la chaine de transmission. Or il est fort probable que les élèves qui travailleront sur ce TP pourront alors se poser les mêmes questions. C'est pour cela qui sera judicieux de prendre soin de noter les problématiques rencontrées et de donner un certain fil de développement pour venir à bout de la problématique posée. Ce qui reviendra à proposer des axes/questions sur les manipulations de cette maquette de TP.

1éme semaine: (rédaction en cours) (du 27/01/2014 au 01/02/2014)

Séance du 05/02/2014 :

Pour bien comprendre les différentes choses à réaliser, on a refait les manipulations vues en TP. On a, pour cela utiliser la maquette didactique TIMS pour générer différent type de modulation:

-la modulation en 4,8,16PSK (on obtient une constellation en forme de cercle).

-La modulation en 4,8,16QAM (on obtient une constellation avec un carré, ou deux: de différentes tailles).

On a très vite dégagé la nécessité de réaliser un montage générateur de tous les mots numériques possibles. On a donc fait un programme sur arduino qui équivaut au générateur pseudo aléatoire. Celui-ci est directement inspiré du montage que l'on a réalisé l'année dernière en conception de circuit électronique.

Voir la section "Code Arduino réalisé" en annexe B dans la semaine correspondante.

Séance du 06/02/2014 :

À propos de l'arduino, on pourra envisager une amélioration pour générer une séquence plus longue:

-il faudra simplement utiliser un tableau d'entier.

-paramétrer sa taille avec un N par exemple.

-N correspondra à la taille de séquence de longueur 2^N.


Voir la section "Code Arduino réalisé" en annexe B dans la semaine correspondante.

Possibilités de communications:

Exploration des possibilités de communication entre le PC et la carte en amont:

-> Ethernet:
  • + Vitesse de transmission (~10M-100M-G)bauds
  • - La gestion du flux de données doit être faite par un microcontrôleur (celui-ci pourra être implémenté un bloc I.P. à l'intérieur du FPGA)

-> - Haute consommation de CLB du FPGA.

-> SPI (communication série):
  • - Vitesse de transmission

-> Arduino capable de communiquer jusqu'a 115200 bauds

-> D'après certaines discussions on pourrait « pousser » au-delà : voir le lien des sujets Raspberry Pi.

-> I2C (abandonnée):

Communication abandonné, ce n'est pas une priorité.

À propos des blocs I.P.:

En consultant les ordinateurs et en s'appuyant des TPs de CNP, on constate que les blocs suivants existent:

- Xilinx Microblaze/Xilinx Power PC ("µP FPGA")

-> Est-ce possible d'utiliser ces blocs I.P. pour programmer un FPGA sur une carte autre que la Nanoboard ? Comment ?

- EMACx (Ethernet Media Acess Control)(:lien physique entre processeurs et "standart Physical Layer device IEEE802.3")

Conception de la carte:

L'idéal est de se documenter sur la Compatibilité électromagnétique.

2éme semaine: (rédaction en cours) (du 03/02/2014 au 08/02/2014)

Réflexion sur les possibilités possibles et offertes par le sujet pour ce qui est des parties de communications entre la maquette en interne et de son environnement.

Maquette en interne/externe.

3éme semaine: (rédaction en cours) (du 10/02/2014 au 15/02/2014)

Ayant les oscillateurs commandables en tension, on a pu commencer à faire une manipulation avec les composants Mini Circuit.

Mais après un problème suite à une manipulation l'un des VCOs ne fonctionne plus.

Ce qui nous amène à penser qu'il sera judicieux de prévoir une alimentation au niveau de la carte.

Celle-ci devra être inférieure ou égale à la tension maximale d'alimentation du composant (ceux-ci étant très sensible).

4éme semaine: (rédaction en cours) (du 17/02/2014 au 22/02/2014)

On a donc repris l'idée de la 2éme semaine.

Après avoir mis en place un cahier des charges au niveau des qualités, bande passante minimale.

Nous avons fait des recherches sur les composants à utiliser (ie CAN, CAN, ...)

Ce qui nous a permis après une édition rapide de schéma électrique (schematic) d'avoir une idée du nombre de pins dont nous aurons besoin sur une carte FPGA afin de réaliser le projet.

Après prospection, il se trouve que nous nous dirigerions vers la carte Digilent Spartan 3, dont l'école était déjà en possession.

Donc nous nous sommes attelés à faire des recherches et des essais sur cette carte et pour notamment trouver un moyen de la faire fonctionner.

5éme semaine: (rédaction en cours) (du 03/03/2014 au 08/03/2014)

Tout d'abord, après plusieurs heures de recherches et d'essai infructueux, on a fini par trouver les drivers pour le câble USB diligent:

http://projets-imasc.plil.net/mediawiki/index.php?title=Modem_pour_le_num%C3%A9rique#Annexe_A:_Digilent_Spartan_3

Et donc ainsi avoir un fonctionnement de la communication via le câble JTAG plus propice au fonctionnement de la carte.

On a pu enfin se conforter sur une partie des composants et des dimensionnements pour certains d'entre eux (valeur de résistance,capacité...)

Schématics: Édition de multiple bibliothèque pour Altium, intégrant à la fois schématics et leur empreinte PCB associés.

(On a pu constater qu'un interface 3v3 5v n'est pas forcement nécessaire.)

6éme semaine: (rédaction en cours) (du 10/03/2014 au 15/03/2014)

On a pu enfin se conforter sur l'ensemble des composants et des choix de régulateur et utilisation d'autre diode Zener.

Après envoi de la commande, il se trouve que le projet a changé d'objectif principal.

Il est maintenant prioritaire de réaliser un code VHDL capable d'évaluer la vitesse de transmission numérique du côté récepteur.

7éme semaine: (rédaction en cours) (du 17/03/2014 au 22/03/2014)

Pour cette semaine, on s'est concentré sur la réalisation d'un générateur pseudo aléatoire en interne au FPGA.

On réalisera une échelle de résistance afin de réaliser une conversion numérique analogique afin de l'envoyer sur la chaine de transmission.

Ce code de "base" nous permettra de réaliser un flux de données fictif pour obtenir toutes les combinaisons récupérant le résultat du bus.

(VHDL, résultat en RTL, )

8éme semaine: (rédaction en cours) (du 24/03/2014 au 26/03/2014)

9éme semaine: (rédaction en cours) (du 28/03/2014 au 03/04/2014)

10éme semaine: (rédaction en cours) (du 07/04/2014 au 10/04/2014)

Annexes

Annexe A: Digilent Spartan 3

Procédure pour faire fonctionner la carte Digilent Spartan 3:

Ne connectez pas de connecteur JTAG pendant les installations. Redémarrez après chaque installation.


Tout d'abord, il faut savoir que le l'ISE Webpack 14.6 fonctionne avec la carte (n'utilisez pas la 14.7, elle ne supporte pas la génération spartan 3 !):

Installez donc l'ISE WebPack 14.6 (ou antérieur à condition que celle-ci soit supérieur à la 7.1i (d'aprés leur documentation))

(voir lien utile sur Xilinx)

Une fois l'installation de l'ISE terminé, faites en sorte d'avoir celui que soit opérationnel (la licence est gratuite !).


Installez la "library" ADEPT 2.3 voir le lien utile.


Après vous n'avez plus qu'a utilisez ISE Xilinx normalement et vous serez capable de reconnaitre la carte via la liaison JTAG, et de le programmer.


Liens utiles:

Lien constructeur/vendeur (avec ressources utiles en bas de la page):

http://www.digilentinc.com/Products/Detail.cfm?Prod=S3BOARD


Lien "Library" pour le câble USB digilent:

http://www.digilentinc.com/Products/Detail.cfm?NavPath=2,66,69&Prod=ADEPT


Lien Xilinx (Pour l'ISE 14.6):

http://www.xilinx.com/products/design-tools/ise-design-suite/index.htm


Lien Xilinx (Pour les versions antérieures veuillez faire attention au système d'exploitation, votre architecture matérielle et le FPGA cible):

(Les informations de compatibilité son sur la page suivante:) (mots clés: xilinx classic(s))

http://www.xilinx.com/tools/classics.htm


Procédure pour faire une programmation en volatile:

Générer le bitstream, et le charger.


Procédure pour faire une programmation en "non"-volatile:

Générer le bitstream et l'utiliser pour générer un .mcs qui vous permettra d'inscrire le programme dans la mémoire (E?)PROM.

On remarquera que la programmation en non-volatile est utile pour faire un remise à zéro et recharger le contenu de l'(E?)PROM, mais semble être sensible au débranchement de l'adaptateur d'alimentation de la carte.

Exemple de programmation:

Voir le lien digilent pour ceci.


Annexe B: Détails techniques des semaines

1éme semaine: (rédaction en cours) (du 27/01/2014 au 01/02/2014)

Après on a réfléchi sur la potentielle conception/utilisation d'une carte FPGA. Il sera judicieux de ne pas se précipiter sur le schéma et la conception/utilisation d'une carte FPGA, sans avoir, au préalable fait le VHDL et le testez avec un banc de test virtuel. L'intérêt et de mettre en valeur la nécessité ou non de certains signaux pour le schéma de la carte. On va mettre en oeuvre les connaissances acquises au S7 en VHDL (en TP de Circuit Numérique Programmble).


Pour ce qui est de l'Arduino, on a répondu aux interrogations suivantes (certaines de ces questions paraissent triviales, mais on préfère éviter les surprises):

Quelle est la vitesse maximale de la communication série de l'Arduino ? -115200bauds

Est-ce que, un programme de type "Analog Write" est-il une vraie sortie analogique ?

-Non, c'est juste une PWM. Elle sera exploitable pour faire les signales I/Q mais très contraignantes, car il faudra filtré le signal, et ce sera beaucoup trop lent (du au fait que la modulation est faite au alentour de 850Mhz), le FPGA sera un passage obligé cela ouvrira les portes d'un plus grand débit.


Code Arduino réalisé:

Schéma électronique du générateur pseudo aléatoire.
Résultat de la simulation du générateur pseudo aléatoire (on a eu la même chose en pratique).

[code] /*A peut être supprimer*/

  1. include <avr/io.h>
  2. include <util/delay.h>

void output_init(void){ 

 DDRB |= 0x02; // PIN 8,9 sont les deux sorties.

}

int main(void){ 

 int r1=1,r2=0,r3=0,r4=0,r5=0,retard=0;
 PORTB=0x00;
 while(1)
   {
     r5=r4;//chaque affectation représente une recopie de la bascule sur le "front montant", ici c'est simplement l’exécution du code.
     r4=r3;
     r3=r2;
     r2=r1;
     r1=r4^r5;
     PORTB=0x01*r1+0x02*retard;//écriture des signaux
     _delay_ms(10);//le "front montant", ce qui permet de faire un genre d'horloge.
     retard=r5;//déphasage du signal
   }
 return 0;

} [/code]

Resultat avec le generateur pseudo aléatoire "émuler" avec l'Arduino.

Comparaison carte réelle/résultat Arduino:

C'était exactement les signaux attendus (même s'il y un décalage a par rapport à l'original).

On aura bien pour une QPSK (4PSK) tous les couples (ie 00,01,11 et 10).

2éme semaine: (rédaction en cours) (du 03/02/2014 au 08/02/2014)

3éme semaine: (rédaction en cours) (du 10/02/2014 au 15/02/2014)

4éme semaine: (rédaction en cours) (du 17/02/2014 au 22/02/2014)

5éme semaine: (rédaction en cours) (du 03/03/2014 au 08/03/2014)

6éme semaine: (rédaction en cours) (du 10/03/2014 au 15/03/2014)

7éme semaine: (rédaction en cours) (du 17/03/2014 au 22/03/2014)

8éme semaine: (rédaction en cours) (du 24/03/2014 au 26/03/2014)

9éme semaine: (rédaction en cours) (du 28/03/2014 au 03/04/2014)

10éme semaine: (rédaction en cours) (du 07/04/2014 au 10/04/2014)

Récupérée de « https://wiki-ima.plil.fr/mediawiki//index.php?title=Modem_pour_le_numérique&oldid=11410 »