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

De Wiki de Projets IMA
(5éme semaine: (rédaction en cours) (du 03/03/2014 08/03/2014))
(10éme semaine: (du 07/04/2014 au 10/04/2014))
 
(111 révisions intermédiaires par le même utilisateur non affichées)
Ligne 32 : Ligne 32 :
 
[[Fichier:P34_2013_2014_Chaine_modulation.PNG|300px|thumb|center|Modulation.]]
 
[[Fichier:P34_2013_2014_Chaine_modulation.PNG|300px|thumb|center|Modulation.]]
  
[[Fichier:P34_2013_2014_Chaine_demodulation.PNG|300px|thumb|center|Demodulation.]]
+
[[Fichier:P34_2013_2014_Chaine_demodulation.PNG|300px|thumb|center|Démodulation.]]
  
 
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).
 
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).
Ligne 65 : Ligne 65 :
  
 
==== => Test de la chaine ====
 
==== => 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.
+
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 à verrouillage de phase), et en amont de la chaine de transmission.
  
 
==== => Première mesure du Bit Error Rate ====
 
==== => Première mesure du Bit Error Rate ====
Ligne 91 : Ligne 91 :
 
Ce qui reviendra à proposer des axes/questions sur les manipulations de cette maquette de TP.
 
Ce qui reviendra à proposer des axes/questions sur les manipulations de cette maquette de TP.
  
== Séance du 05/02/2014 (Rédaction en cours): ==
+
== Note valable pour toutes les semaines ==
 +
 
 +
'''[[Si un point vous semble imprécis, veuillez vous reporter aux détails fournis en annexe.]]'''
 +
 
 +
== 1éme semaine: (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:
 
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:
Ligne 102 : Ligne 108 :
 
On a donc fait un programme sur arduino qui équivaut au générateur pseudo aléatoire.
 
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.
 
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é".
 
  
 +
Séance du 06/02/2014 :
 +
 +
Lors de cette séance on a exploré toutes les possibilités concernant la communication entre la maquette/carte, car cela pour avoir une influence non négligeable sur le choix de la carte F.P.G.A. et du design de la maquette.
 +
 +
On a donc aussi fait des recherches concernant les possibilités de communications et les blocs I.P. (Intellectual Properties) permettant de programmer un F.P.G.A.
 +
 +
Et enfin, on a eu une discussion avec un responsable technique pour ce qui de la C.E.M. (Compatibilité Electro-Magnétique)
 +
 +
== 2éme semaine: (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.
 +
 +
[[Fichier:P34_2013_2014_schéma_principe_carte_semaine_2.PNG|300px|thumb|center|Maquette en interne/externe.]]
 +
 +
N'ayant jamais utilisé d'autre carte que la Nanoboard, on s'est attelé à faire des recherches sur la manière de procéder pour programmer une carte F.P.G.A., il se trouve que chaque carte de développement à ses propres manières pour être programmé.
 +
 +
On a pris le soin de noter toutes les questions concernant le F.P.G.A. pour un intervenant industriel qui assura un cours la semaine prochaine.
 +
 +
== 3éme semaine: (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).
 +
 +
 +
Questions/Réponses:
 +
 +
Comment fait-on pour programmer une carte F.P.G.A. est-ce que la programmation se fait "in situe" ? (in situe : c'est à dire sur la carte elle-même)
 +
Oui, c'est ce qui est utilisé, via un câble JTAG.
 +
 +
Est-ce possible faire une interface USB pour permettre à un ordinateur de communiquer avec la maquette/carte via un F.P.G.A. ? Oui.
 +
 +
Est-ce que la gestion de l'interface Ethernet est envisageable ? Oui.
 +
 +
Pour une communication en protocole UDP avec un ordinateur via une liaison Ethernet, est-ce qu'il y a d'autres façons que d'utiliser un "SoftCore" ?
 +
 +
Oui, il existe aussi bien en Software, qu'en Hardware.
 +
 +
== 4éme semaine: (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 (i.e. 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: (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.
 +
 +
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é...)
  
Après on a réfléchi sur la potentielle conception d'une carte FPGA.
+
Schématics: Édition de multiple bibliothèque pour Altium, intégrant à la fois schématics et leur empreinte PCB associée.
Il sera judicieux de ne pas se précipiter sur le schéma et la conception de la carte FPGA, sans avoir, au préalable fait le VHDL et le testez avec un banc de test virtuel.
+
 
 +
(On a pu constater qu'une interface 3v3 5v n'est pas forcement nécessaire pour assurer le bon fonctionnement entre deux cartes avec des tensions d'alimentation différentes.)
 +
 
 +
== 6éme semaine: (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.
 +
 
 +
On trouvera le schéma intégral avec les bibliothèques nécessaires dans la semaine 5.
 +
 
 +
Cette semaine a été dédiée à l'envoi de la commande des composants au sein du magasin de l'école et du fournisseur.
 +
 
 +
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: (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.
 +
 
 +
[[MédiaP34_2013_2014_gene_pseudo_19_03_2014_6_semaine_7.zip|Archive contenant le projet ISE Xilinx.]]
 +
 
 +
[[Fichier:P34_2013_2014_rtl_semaine_7.PNG|300px|thumb|center|extrait du schéma RTL, on peut y voir clairement les inférences de Xilinx.]]
 +
 
 +
Ce schéma a deux entrées et une sortie, une entrée d'initialisation, une horloge et une sortie pour la trame en pseudo aléatoire.
 +
 
 +
On fera l'essai sur la carte lors de la semaine suivante.
 +
 
 +
== 8éme semaine: (du 24/03/2014 au 26/03/2014) ==
 +
 
 +
Après le premier test, on pourrait penser que l'on récupère du bruit en sortie de la carte:
 +
 
 +
[[Fichier:P34_2013_2014_DSC_0024_1_probleme_d_overshoot_semaine_8.jpg|300px|thumb|center|Overshoot.]]
 +
 
 +
Pour pouvoir remédier à ce problème, on a fait une prédivision de l'horloge
 +
 
 +
[[Fichier:P34_2013_2014_DSC_0037_1_div_freq_semaine_8.jpg|300px|thumb|center|Overshoot après division.]]
 +
 
 +
[[Fichier:P34_2013_2014_DSC_0039_1_div_freq_zoom_semaine_8.jpg|300px|thumb|center|Overshoot après division (Zoom).]]
 +
 
 +
Archive contenant toutes les modifications:
 +
 
 +
[[Média:P34_2013_2014_gene_pseudo_26_03_2014_2_semaine_8.zip|VHDL Semaine 8.]]
 +
 
 +
On a trouvé un moyen de faire un CNA facilement, via une "échelle dite R-2R". [[http://www.uchobby.com/index.php/2008/01/08/arduino-audio-dac-options/|Pour le réseau R 2R.]]
 +
 
 +
Il faut encore modifier le VHDL pour pouvoir l'exploiter et ainsi générer une constellation.
 +
 
 +
== 9éme semaine: (du 28/03/2014 au 03/04/2014) ==
 +
 
 +
On a pris donc le soin de modifier le VHDL:
 +
 
 +
[[Média:P34_2013_2014_gene_pseudo_31_03_2014_1_semaine_9.zip|VHDL semaine 9]]
 +
 
 +
Ce VHDL à été mis à jour, avec deux entrées (initialisation et une horloge) et un bus de sortie (8 bits), avec les trames pseudoaléatoires.
 +
 
 +
On envoie ces signaux sur deux C.N.A.s (4 bits chacun) pour générer deux signaux I et Q, on peut voir une constellation se dessiner en mode X-Y.
 +
 
 +
[[Fichier:P34_2013_2014_DSC_0072_1_Montage_entier_4qam_semaine_9.jpg|300px|thumb|center|Montage avec constellations 4QAM.]]
 +
 
 +
D'autres constellations réalisées sont disponibles en annexe. On peut monter jusqu'à une constellation de 256 points (2^4*2^4).
 +
 
 +
On a réalisé le montage complet de toute la chaine de transmission. Il se trouve que la Boucle à Verrouillage de Phase (ou appellée PLL, Phase Loop Locker) ne se verrouille pas sur la porteuse du signal que l'on souhaite récupéré, de ce fait on ne peut pas récupérer les signaux I et Q.
 +
 
 +
== 10éme semaine: (du 07/04/2014 au 10/04/2014) ==
 +
 
 +
On a réalisé le montage que l'on évoquait en semaine 9:
 +
 
 +
[[Fichier:P34_2013_2014_DSC_0027_montage_realisee_semaine_10.jpg|center|thumb|300px|Montage pour améliorer la PLL.]]
 +
 
 +
Il se trouve qu’après un réglage précis de la tension d'offset permettant d'être un proche de la fréquence à capturer on obtient:
 +
 
 +
[[Fichier:P34_2013_2014_DSC_0025_PLL_non_verrouillage_semaine_10.jpg|center|thumb|300px|Signaux I/Q après ajout du montage.]]
 +
 
 +
Pour ce qui des axes d'amélioration et de développement, on pourra proposer:
 +
 
 +
-Améliorer la P.L.L.
 +
 
 +
-Écrire le VHDL permettant de faire la remise en forme en utilisant un montage simplifié de la chaine de transmission
 +
 
 +
-Réaliser la carte
 +
 
 +
Liens pour la P.L.L.:
 +
 
 +
http://en.wikipedia.org/wiki/Phase-locked_loop
 +
 
 +
http://fr.wikipedia.org/wiki/Boucle_%C3%A0_phase_asservie
 +
 
 +
== Conclusion: ==
 +
 
 +
Ce projet intéressant m'a permis de prendre conscience les différences fondamentales entre la théorie et la pratique. Cela m'a permis de prendre conscience que faut toujours avoir un esprit critique envers la théorie, car il faut savoir découvrir l'origine du problème en cas de dysfonctionnement, car le travail d'un ingénieur ne se limite pas à fournir des solutions.
 +
 
 +
Mon projet scolaire s'est donc achevé à ce point, cependant d'autres élèves pourront prendre le relais en réalisant la carte correspondant au schéma et ainsi réaliser rapidement l'interface entre la carte FPGA et la maquette. Et pourront se concentrer sur la mise en route intégrale de la chaine.
 +
 
 +
= Annexes =
 +
 
 +
== Annexe A: Détails techniques des semaines ==
 +
 
 +
=== 1éme semaine: (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.
 
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).
 
On va mettre en oeuvre les connaissances acquises au S7 en VHDL (en TP de Circuit Numérique Programmble).
Ligne 120 : Ligne 292 :
 
-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.
 
-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.
  
 +
==== Manipulation réalisée sur la maquette TIMS : ====
  
=== Code Arduino réalisé: ===
+
On a fait un des montages présentés dans l'ouvrage "Volume D1 Fundamental Digital Experiments" dans le but de visualiser l’objectif à atteindre.
  
[[Fichier:P34_2013_2014_schema_electronique_generateur_pseudo_aleatoire.png|300px|thumb|center|Schéma électronique du générateur pseudo aléatoire.]]
+
On obtient la constellation suivante (16QAM):
 +
 
 +
[[Fichier:P34_2013_2014_constelation_tims_semaine_1.PNG|300px|thumb|center|Constellation visualisée en mode X-Y.]]
 +
 
 +
Ce qui correspond à deux signaux en visualisation temporelle de cette forme :
 +
 
 +
[[Fichier:P34_2013_2014_constelation_temporelle_tims_semaine_1.PNG|300px|thumb|center|Signaux I et Q. (Image très floutée, à remplacer)]]
  
[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_chrono_simule.PNG|300px|thumb|center|Résultat de la simulation du générateur pseudo aléatoire (on a eu la même chose en pratique).]]
+
On pourra facilement obtenir le même résultat en générant un bus de trame pseudo aléatoire et en l'injectant dans un C.N.A. (Conversion Numérique Analogique)
  
[code]
+
==== Code Arduino réalisé: ====
/*A peut être supprimer*/
 
#include <avr/io.h>
 
#include <util/delay.h>
 
  
void output_init(void){
+
[[Fichier:P34_2013_2014_schema_electronique_generateur_pseudo_aleatoire.png|300px|thumb|center|Schéma électronique du générateur pseudo aléatoire.]]
  DDRB |= 0x02; // PIN 8,9 sont les deux sorties.
 
}
 
  
int main(void){
+
[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_chrono_simule.PNG|300px|thumb|center|Résultat de la simulation du générateur pseudo aléatoire (on a eu la même chose en pratique).]]
  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]
 
  
[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_arduino.jpg|300px|thumb|center|Resultat avec le generateur pseudo aléatoire "émuler" avec l'Arduino.]]
+
[[Fichier:P34_2013_2014_generateur_pseudo_aleatoire_arduino.jpg|300px|thumb|center|Resultat avec le générateur pseudo aléatoire "émuler" avec l'Arduino.]]
  
 
Comparaison carte réelle/résultat Arduino:
 
Comparaison carte réelle/résultat Arduino:
Ligne 161 : Ligne 319 :
  
 
On aura bien pour une QPSK (4PSK) tous les couples (ie 00,01,11 et 10).
 
On aura bien pour une QPSK (4PSK) tous les couples (ie 00,01,11 et 10).
 
== Séance du 06/02/2014 (Rédaction en cours): ==
 
  
 
À propos de l'arduino, on pourra envisager une amélioration pour générer une séquence plus longue:
 
À propos de l'arduino, on pourra envisager une amélioration pour générer une séquence plus longue:
Ligne 172 : Ligne 328 :
 
-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: ====
  
 
Exploration des possibilités de communication entre le PC et la carte en amont:
 
Exploration des possibilités de communication entre le PC et la carte en amont:
  
====-> Ethernet: ====
+
=====-> Ethernet: =====
  
 
*+ Vitesse de transmission (~10M-100M-G)bauds
 
*+ Vitesse de transmission (~10M-100M-G)bauds
Ligne 185 : Ligne 342 :
 
-> - Haute consommation de CLB du FPGA.
 
-> - Haute consommation de CLB du FPGA.
  
====-> SPI (communication série): ====
+
=====-> SPI (communication série): =====
  
 
*- Vitesse de transmission
 
*- Vitesse de transmission
  
-> Arduino capable jusqu'a 115200 bauds
+
-> 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.
+
-> D'après certaines discussions sur des forums, on pourrait « pousser » au-delà.
  
====-> I2C (recherche à faire): ====
+
=====-> I2C : =====
 
 
Communication abandonné, ce n'est pas une priorité.
 
  
 +
Communication abandonnée, ce n'est pas une priorité.
  
 
==== À propos des blocs I.P.: ====
 
==== À propos des blocs I.P.: ====
  
En consultant les ordinateurs et en s'appuyant des TPs de CNP, on constate que les blocs suivants existent:
+
En consultant les ordinateurs et en s'appuyant des T.P.s de CNP, on constate que les blocs suivants existent:
  
 
- Xilinx Microblaze/Xilinx Power PC ("µP FPGA")
 
- Xilinx Microblaze/Xilinx Power PC ("µP FPGA")
Ligne 206 : Ligne 362 :
 
-> Est-ce possible d'utiliser ces blocs I.P. pour programmer un FPGA sur une carte autre que la Nanoboard ? Comment ?
 
-> 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)
+
- EMACx (Ethernet Media Acess Control)(:lien physique entre processeurs et "standart Physical Layer device IEEE802.3")
  
==== Conception de la carte: ====
+
===== Conception de la carte: =====
  
 
L'idéal est de se documenter sur la Compatibilité électromagnétique.
 
L'idéal est de se documenter sur la Compatibilité électromagnétique.
  
== 2éme semaine: (rédaction en cours) (du 03/02/2014 08/02/2014) ==
+
=== 2éme semaine: (du 03/02/2014 au 08/02/2014) ===
 +
 
 +
(Rien pour l'annexe.)
 +
 
 +
=== 3éme semaine: (du 10/02/2014 au 15/02/2014) ===
 +
 
 +
Lors de cette semaine, après avoir eu le problème de manipulation, nous avons pu prendre connaissance d'un certain montage qui s’avéra utile pour la conception de la carte/maquette.
 +
 
 +
[[Fichier:P34_2013_2014_schéma_limiteur_de_courant_semaine_3.PNG|300px|thumb|center|Schéma limiteur de courant.]]
 +
 
 +
On remarquera que ce montage se retrouve dans la partie "typical application" de la documentation technique du 7805.
 +
 
 +
=== 4éme semaine: (du 17/02/2014 au 22/02/2014) ===
 +
 
 +
On souhaite pouvoir réaliser une communication unidirectionnelle ou même transmettre un signal audio ce qui nous contraint à une bande passante minimale de 48kHz, on prendra 200kHz (pour être bien au-delà de la condition du théorème de Shannon): le but serait donc de brancher par exemple une source audio quelconque puis de la transmettre à travers la maquette et de la recomposer en fin de chaine.
 +
 
 +
Après édition rapide du schéma, on en dégage qu'il nous faudra un minimum d'environ 50 entrées/sorties. Mais ceci ce nombre sera très probablement revu à la hausse lors de prochaine séance.
 +
 
 +
Voici la carte que l'on utilisera dans la suite du projet:
  
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.
+
[[Fichier:P34_2013_2014_S3BOARD-top-400_semaine_4.gif|300px|thumb|center|Digilent Spartan 3.]]
 +
 
 +
=== 5éme semaine: (du 03/03/2014 au 08/03/2014) ===
 +
 
 +
Lien vers le Design complet avec les librairies incluses (on remarquera qu'il serait judicieux d’installer toutes les librairies avant d’essayer d'ouvrir le schéma)
 +
 
 +
A notez aussi que l'on trouvera des reliques de feuilles Excel permettant de trouver rapidement des ratios dans la série E12.
  
[[Fichier:P34_2013_2014_schéma_principe_carte_semaine_2.PNG|300px|thumb|center|Maquette en interne/externe.]]
+
[[Média:P34_2013_2014_Design_pcb_plus_librairies_semaine_5_6.zip|Schéma + Bibliothèques.]]
  
== 3éme semaine: (rédaction en cours) (du 10/02/2014 au 15/02/2014) ==
+
[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.pdf|Schéma en PDF.]]
  
Ayant les oscillateurs commandables en tension, on a pu commencer à faire une manipulation avec les composants Mini Circuit.
+
[[Média:P34_2013_2014_sch_design_pcb_semaine_5_6.png|Schéma au format A2.]]
  
Mais après un problème suite à une manipulation l'un des VCOs ne fonctionne plus.
+
=== 6éme semaine: (du 10/03/2014 au 15/03/2014) ===
  
Ce qui nous amène à penser qu'il sera judicieux de prévoir une alimentation au niveau de la carte.
+
(Rien pour l'annexe.)
  
Celle-ci devra être inférieure ou égale à la tension maximale d'alimentation du composant (ceux-ci étant très sensible).
+
=== 7éme semaine: (du 17/03/2014 au 22/03/2014) ===
  
== 4éme semaine: (rédaction en cours) (du 17/02/2014 22/02/2014) ==
+
(Rien pour l'annexe.)
  
On a donc repris l'idée des 2 éme semaine.
+
=== 8éme semaine: (du 24/03/2014 au 26/03/2014) ===
  
Après avoir mis en place un cahier des charges au niveau des qualités, bande passante minimale.
+
(Rien pour l'annexe.)
  
Nous avons fait des recherches sur les composants à utiliser (ie CAN, CAN, ...)
+
=== 9éme semaine: (du 28/03/2014 au 03/04/2014) ===
  
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.
+
[[Fichier:P34_2013_2014_DSC_0061_1_r_2r_semaine_9.jpg|center|thumb|300px|Le réseau R-2R.]]
  
Après prospection, il se trouve que nous nous dirigerions vers la carte Digilent Spartan 3, dont l'école était déjà en possession.
+
[[Fichier:P34_2013_2014_DSC_0062_1_4QAM_semaine_9.jpg|center|thumb|300px|4QAM.]]
  
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.
+
[[Fichier:P34_2013_2014_DSC_0066_1_16QAM_semaine_9.jpg|center|thumb|300px|16QAM.]]
  
== 5éme semaine: (rédaction en cours) (du 03/03/2014 au 08/03/2014) ==
+
[[Fichier:P34_2013_2014_DSC_0069_1_64QAM_semaine_9.jpg|center|thumb|300px|64QAM.]]
  
Tout d'abord, après plusieurs heures de recherches et d'essai infructueux, nous avons fini par trouver les drivers pour le câble USB diligent:
+
Pas de photos pour la constellation à 256 points, mais elle a été réalisée.
  
(URLs à insérer) (URL library, URL page digilent, URL, URL, URL, URL)
+
Pour ce qui est du montage, malgré que la P.L.L., on a un signal d'erreur après filtrage :
  
(Procédure à suivre pour faire fonctionner la carte à rédiger) (mode (non) volatile)
+
[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Chaine 1: Vtune (commande du V.C.O.)/Chaine 2: "erreur" de commande]]
  
Et donc ainsi avoir un fonctionnement de la communication plus propice au fonctionnement de la carte.
+
Ce qui met en valeur immédiatement deux problèmes majeurs:
  
On a pu enfin se conforter sur une partie des composants et des dimensionnements pour certains d'entre eux (valeur de résistance,capacité...)
+
La chaine fonctionne sur le papier, mais lors de sa mise en pratique, il faut penser à mettre une tension d'offset et aussi réaliser une amplification de l'erreur pour avoir des grandeurs de commande adaptée au Vtune du V.C.O..
  
Schématics: Édition de multiple bibliothèque pour Altium, intégrant à la fois schématics et leur empreinte PCV associés.
+
On propose l'amélioration suivante (qui sera réalisé à la prochaine séance):
  
On a pu enfin se conforter sur l'ensemble des composants et des choix de régulateur et utilisation d'autre diode Zener.
+
[[Fichier:P34_2013_2014_DSC_0015_ch1_vtune_ch2_e(t)_semaine_9.jpg|center|thumb|300px|Proposition de voie d'amélioration.]]
  
(On a pu constater qu'un interface 3v3 5v n'est pas forcement nécessaire...)
+
On remarquera que les valeurs des résistances et des capacités on était choisi pour permettre un fonctionnement correct des A.O. (Amplificateur Opérationnel), mais pas pour ce qui de l'asservissement de la boucle par manque de temps.  
  
== 6éme semaine: (rédaction en cours) (du 10/03/2014 au 15/03/2014) ==
+
A la fin de cette, on a eu à démonter le montage à cause de contraintes concernant les Mini-circuits (car utilisé en travaux pratiques).
  
Après envoi de la commande, il se trouve que le projet a changé d'objectif principal.
+
=== 10éme semaine: (du 07/04/2014 au 10/04/2014) ===
  
Il est maintenant prioritaire de réaliser un code VHDL capable d'évaluer la vitesse de transmission numérique du côté récepteur.
+
Spectres des signaux de la chaine de transmission:
  
== 7éme semaine: (rédaction en cours) (du 17/03/2014 au 22/03/2014) ==
+
[[Fichier:P34_2013_2014_DSC_0001_allure_spectre_reception_semaine_10.jpg|center|thumb|300px|Spectre en réception.]]
  
Pour cette semaine, on s'est concentré sur la réalisation d'un générateur pseudo aléatoire en interne au FPGA.
+
Porteuse utilisée pour la modulation I/Q à environ 60MHz.
  
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.
+
Porteuse utilisée pour le transport en fréquence à environ 810MHz:
  
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.
+
[[Fichier:P34_2013_2014_DSC_0035_constellation_recupere_PLL_NV_semaine_10.jpg|center|thumb|300px|"Constellation" récupérée avec la PLL défectueuse (on souhaite se verrouiller sur la raie à 868MHz).]]
  
(VHDL, résultat en RTL, )
+
Question en suspens: faudrait-il utiliser un filtre passe-bande incluant 868Mhz pour pouvoir se verrouiller sur cette fréquence ?
  
== 8éme semaine: (rédaction en cours) (du 24/03/2014 au 26/03/2014) ==
+
On remarquera le fait que l'oscillateur du côté de la chaine d'émission a d'importantes non-linéarités (on peut observer à l'analyseur de spectre 3 à 4 raies aux fréquences multiples).
  
== 9éme semaine: (rédaction en cours) (du 28/03/2014 au 03/04/2014) ==
+
Ce qui donne un diagramme de constellation plutôt mauvais si l'on fait le montage suivant:
  
== 10éme semaine: (rédaction en cours) (du 07/04/2014 au 10/04/2014) ==
+
[[Fichier:P34_2013_2014_montage_non_linearite_vco_constellation_semaine_10.PNG|center|thumb|300px|Montage réalisée.]]
  
= Annexes =
+
[[Fichier:P34_2013_2014_sortie_montage_non_linearite_semaine_10.PNG|center|thumb|300px|La constellation 4QAM est attendue, on est loin du résultat attendu (aucune photo n'a était réalisé d'ou le dessin).]]
  
== Annexe A: Digilent Spartan 3 ==
+
== Annexe B: Digilent Spartan 3 ==
  
 
=== Procédure pour faire fonctionner la carte Digilent Spartan 3: ===
 
=== Procédure pour faire fonctionner la carte Digilent Spartan 3: ===
Ligne 293 : Ligne 473 :
 
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 !):
 
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))
+
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)
 
(voir lien utile sur Xilinx)
Ligne 307 : Ligne 487 :
  
 
=== Liens utiles: ===
 
=== Liens utiles: ===
 
  
 
Lien constructeur/vendeur (avec ressources utiles en bas de la page):
 
Lien constructeur/vendeur (avec ressources utiles en bas de la page):
Ligne 340 : Ligne 519 :
 
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.
 
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: ===
 
=== Exemple de programmation: ===
  
Voir le lien digilent pour ceci.
+
Voir le lien digilent pour ceci dans cette annexe.
 +
 
 +
= Fichiers Rendus =
 +
 
 +
Rapport projet numéro 34 VAESSEN :[[Fichier:Rapport_projet_p34_s8_6.pdf]]
 +
 
 +
Source VHDL Final :[[Fichier:P34_2013_2014_gene_pseudo_31_03_2014_1_semaine_9.zip]]
 +
 
 +
Code Arduino :[[Fichier:P34_2013_204_Generateur_pseudo.zip]]
 +
 
 +
Design sous Altium :[[Fichier:P34_2013_2014_Design_pcb_plus_librairies_semaine_5_6.zip]]

Version actuelle datée du 15 avril 2014 à 20:19

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.
Démodulation.

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 à 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.

Note valable pour toutes les semaines

Si un point vous semble imprécis, veuillez vous reporter aux détails fournis en annexe.

1éme semaine: (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.

Séance du 06/02/2014 :

Lors de cette séance on a exploré toutes les possibilités concernant la communication entre la maquette/carte, car cela pour avoir une influence non négligeable sur le choix de la carte F.P.G.A. et du design de la maquette.

On a donc aussi fait des recherches concernant les possibilités de communications et les blocs I.P. (Intellectual Properties) permettant de programmer un F.P.G.A.

Et enfin, on a eu une discussion avec un responsable technique pour ce qui de la C.E.M. (Compatibilité Electro-Magnétique)

2éme semaine: (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.

N'ayant jamais utilisé d'autre carte que la Nanoboard, on s'est attelé à faire des recherches sur la manière de procéder pour programmer une carte F.P.G.A., il se trouve que chaque carte de développement à ses propres manières pour être programmé.

On a pris le soin de noter toutes les questions concernant le F.P.G.A. pour un intervenant industriel qui assura un cours la semaine prochaine.

3éme semaine: (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).


Questions/Réponses:

Comment fait-on pour programmer une carte F.P.G.A. est-ce que la programmation se fait "in situe" ? (in situe : c'est à dire sur la carte elle-même) Oui, c'est ce qui est utilisé, via un câble JTAG.

Est-ce possible faire une interface USB pour permettre à un ordinateur de communiquer avec la maquette/carte via un F.P.G.A. ? Oui.

Est-ce que la gestion de l'interface Ethernet est envisageable ? Oui.

Pour une communication en protocole UDP avec un ordinateur via une liaison Ethernet, est-ce qu'il y a d'autres façons que d'utiliser un "SoftCore" ?

Oui, il existe aussi bien en Software, qu'en Hardware.

4éme semaine: (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 (i.e. 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: (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.

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ée.

(On a pu constater qu'une interface 3v3 5v n'est pas forcement nécessaire pour assurer le bon fonctionnement entre deux cartes avec des tensions d'alimentation différentes.)

6éme semaine: (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.

On trouvera le schéma intégral avec les bibliothèques nécessaires dans la semaine 5.

Cette semaine a été dédiée à l'envoi de la commande des composants au sein du magasin de l'école et du fournisseur.

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: (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.

Archive contenant le projet ISE Xilinx.

extrait du schéma RTL, on peut y voir clairement les inférences de Xilinx.

Ce schéma a deux entrées et une sortie, une entrée d'initialisation, une horloge et une sortie pour la trame en pseudo aléatoire.

On fera l'essai sur la carte lors de la semaine suivante.

8éme semaine: (du 24/03/2014 au 26/03/2014)

Après le premier test, on pourrait penser que l'on récupère du bruit en sortie de la carte:

Overshoot.

Pour pouvoir remédier à ce problème, on a fait une prédivision de l'horloge

Overshoot après division.
Overshoot après division (Zoom).

Archive contenant toutes les modifications:

VHDL Semaine 8.

On a trouvé un moyen de faire un CNA facilement, via une "échelle dite R-2R". [le réseau R 2R.]

Il faut encore modifier le VHDL pour pouvoir l'exploiter et ainsi générer une constellation.

9éme semaine: (du 28/03/2014 au 03/04/2014)

On a pris donc le soin de modifier le VHDL:

VHDL semaine 9

Ce VHDL à été mis à jour, avec deux entrées (initialisation et une horloge) et un bus de sortie (8 bits), avec les trames pseudoaléatoires.

On envoie ces signaux sur deux C.N.A.s (4 bits chacun) pour générer deux signaux I et Q, on peut voir une constellation se dessiner en mode X-Y.

Montage avec constellations 4QAM.

D'autres constellations réalisées sont disponibles en annexe. On peut monter jusqu'à une constellation de 256 points (2^4*2^4).

On a réalisé le montage complet de toute la chaine de transmission. Il se trouve que la Boucle à Verrouillage de Phase (ou appellée PLL, Phase Loop Locker) ne se verrouille pas sur la porteuse du signal que l'on souhaite récupéré, de ce fait on ne peut pas récupérer les signaux I et Q.

10éme semaine: (du 07/04/2014 au 10/04/2014)

On a réalisé le montage que l'on évoquait en semaine 9:

Montage pour améliorer la PLL.

Il se trouve qu’après un réglage précis de la tension d'offset permettant d'être un proche de la fréquence à capturer on obtient:

Signaux I/Q après ajout du montage.

Pour ce qui des axes d'amélioration et de développement, on pourra proposer:

-Améliorer la P.L.L.

-Écrire le VHDL permettant de faire la remise en forme en utilisant un montage simplifié de la chaine de transmission

-Réaliser la carte

Liens pour la P.L.L.:

http://en.wikipedia.org/wiki/Phase-locked_loop

http://fr.wikipedia.org/wiki/Boucle_%C3%A0_phase_asservie

Conclusion:

Ce projet intéressant m'a permis de prendre conscience les différences fondamentales entre la théorie et la pratique. Cela m'a permis de prendre conscience que faut toujours avoir un esprit critique envers la théorie, car il faut savoir découvrir l'origine du problème en cas de dysfonctionnement, car le travail d'un ingénieur ne se limite pas à fournir des solutions.

Mon projet scolaire s'est donc achevé à ce point, cependant d'autres élèves pourront prendre le relais en réalisant la carte correspondant au schéma et ainsi réaliser rapidement l'interface entre la carte FPGA et la maquette. Et pourront se concentrer sur la mise en route intégrale de la chaine.

Annexes

Annexe A: Détails techniques des semaines

1éme semaine: (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.

Manipulation réalisée sur la maquette TIMS :

On a fait un des montages présentés dans l'ouvrage "Volume D1 Fundamental Digital Experiments" dans le but de visualiser l’objectif à atteindre.

On obtient la constellation suivante (16QAM):

Constellation visualisée en mode X-Y.

Ce qui correspond à deux signaux en visualisation temporelle de cette forme :

Signaux I et Q. (Image très floutée, à remplacer)

On pourra facilement obtenir le même résultat en générant un bus de trame pseudo aléatoire et en l'injectant dans un C.N.A. (Conversion Numérique Analogique)

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).
Resultat avec le générateur 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).

À 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 sur des forums, on pourrait « pousser » au-delà.

-> I2C :

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

À propos des blocs I.P.:

En consultant les ordinateurs et en s'appuyant des T.P.s 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: (du 03/02/2014 au 08/02/2014)

(Rien pour l'annexe.)

3éme semaine: (du 10/02/2014 au 15/02/2014)

Lors de cette semaine, après avoir eu le problème de manipulation, nous avons pu prendre connaissance d'un certain montage qui s’avéra utile pour la conception de la carte/maquette.

Schéma limiteur de courant.

On remarquera que ce montage se retrouve dans la partie "typical application" de la documentation technique du 7805.

4éme semaine: (du 17/02/2014 au 22/02/2014)

On souhaite pouvoir réaliser une communication unidirectionnelle ou même transmettre un signal audio ce qui nous contraint à une bande passante minimale de 48kHz, on prendra 200kHz (pour être bien au-delà de la condition du théorème de Shannon): le but serait donc de brancher par exemple une source audio quelconque puis de la transmettre à travers la maquette et de la recomposer en fin de chaine.

Après édition rapide du schéma, on en dégage qu'il nous faudra un minimum d'environ 50 entrées/sorties. Mais ceci ce nombre sera très probablement revu à la hausse lors de prochaine séance.

Voici la carte que l'on utilisera dans la suite du projet:

Digilent Spartan 3.

5éme semaine: (du 03/03/2014 au 08/03/2014)

Lien vers le Design complet avec les librairies incluses (on remarquera qu'il serait judicieux d’installer toutes les librairies avant d’essayer d'ouvrir le schéma)

A notez aussi que l'on trouvera des reliques de feuilles Excel permettant de trouver rapidement des ratios dans la série E12.

Schéma + Bibliothèques.

Schéma en PDF.

Schéma au format A2.

6éme semaine: (du 10/03/2014 au 15/03/2014)

(Rien pour l'annexe.)

7éme semaine: (du 17/03/2014 au 22/03/2014)

(Rien pour l'annexe.)

8éme semaine: (du 24/03/2014 au 26/03/2014)

(Rien pour l'annexe.)

9éme semaine: (du 28/03/2014 au 03/04/2014)

Le réseau R-2R.
4QAM.
16QAM.
64QAM.

Pas de photos pour la constellation à 256 points, mais elle a été réalisée.

Pour ce qui est du montage, malgré que la P.L.L., on a un signal d'erreur après filtrage :

Chaine 1: Vtune (commande du V.C.O.)/Chaine 2: "erreur" de commande

Ce qui met en valeur immédiatement deux problèmes majeurs:

La chaine fonctionne sur le papier, mais lors de sa mise en pratique, il faut penser à mettre une tension d'offset et aussi réaliser une amplification de l'erreur pour avoir des grandeurs de commande adaptée au Vtune du V.C.O..

On propose l'amélioration suivante (qui sera réalisé à la prochaine séance):

Proposition de voie d'amélioration.

On remarquera que les valeurs des résistances et des capacités on était choisi pour permettre un fonctionnement correct des A.O. (Amplificateur Opérationnel), mais pas pour ce qui de l'asservissement de la boucle par manque de temps.

A la fin de cette, on a eu à démonter le montage à cause de contraintes concernant les Mini-circuits (car utilisé en travaux pratiques).

10éme semaine: (du 07/04/2014 au 10/04/2014)

Spectres des signaux de la chaine de transmission:

Spectre en réception.

Porteuse utilisée pour la modulation I/Q à environ 60MHz.

Porteuse utilisée pour le transport en fréquence à environ 810MHz:

"Constellation" récupérée avec la PLL défectueuse (on souhaite se verrouiller sur la raie à 868MHz).

Question en suspens: faudrait-il utiliser un filtre passe-bande incluant 868Mhz pour pouvoir se verrouiller sur cette fréquence ?

On remarquera le fait que l'oscillateur du côté de la chaine d'émission a d'importantes non-linéarités (on peut observer à l'analyseur de spectre 3 à 4 raies aux fréquences multiples).

Ce qui donne un diagramme de constellation plutôt mauvais si l'on fait le montage suivant:

Montage réalisée.
La constellation 4QAM est attendue, on est loin du résultat attendu (aucune photo n'a était réalisé d'ou le dessin).

Annexe B: 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 dans cette annexe.

Fichiers Rendus

Rapport projet numéro 34 VAESSEN :Fichier:Rapport projet p34 s8 6.pdf

Source VHDL Final :Fichier:P34 2013 2014 gene pseudo 31 03 2014 1 semaine 9.zip

Code Arduino :Fichier:P34 2013 204 Generateur pseudo.zip

Design sous Altium :Fichier:P34 2013 2014 Design pcb plus librairies semaine 5 6.zip