Communication sous-marine
Introduction
Communiquer sous l'eau est complexe. Les plongeurs utilisent des gestes à courte distance et des moyens limités pour des communications plus éloignées. Pour améliorer cela, un laboratoire R&D a développé une solution acoustique économique et efficace, permettant de transmettre des messages via des "montres" spéciales aux plongeurs, en utilisant la modulation de fréquence. Après une première version à fréquence unique en 2016, une version améliorée à double fréquence, inspirée du DTMF utilisé en téléphonie, a été conceptualisée mais non testée. Votre tâche est de valider cette dernière version, vérifier son efficacité, y compris dans des conditions bruyantes, réfléchir à sa conception pour une maintenance aisée, et créer un prototype de PCB pour démontrer son fonctionnement.
Pour résumer le but de réaliser un récepteur de message sous marin à partir d’un prototype d’un système déjà existant (qui lui fonctionnait avec une porteuse), vérifier si ce système fonctionnerait avec 2 porteuses (pour améliorer la fiabilité du système), réaliser un prototype fonctionnel et valider son bon fonctionnement pour une communication sous marine (avec bruits parasites)
Livrables :
Rapport d’activités (Activités, gestion du projet, réflexion sur les apprentissages et lien avec les compétences)
Rappel du cahier des charges
lien vers TRELLO ou cahier de suivi de vos séances
Plannings prévisionnel et réel commentés
Rapport des tests (et simulations le cas échéant)
Procédure des tests
Tous les documents de fabrication (Sch, Pcb, Algo, programmes)
Prototype fonctionnel
Analyse fonctionnelle
Je commence premièrement par faire une analyse fonctionnelle du système.
Objectif : réaliser un prototype d’un système de décodage de fréquences DTMF, le système doit pouvoir réceptionner une fréquence DTMF et pouvoir restituer un message
Diagramme bête à corne :
à partir des consignes on peut rédiger les exigences suivantes :
(Les indices de flexibilités sont choisis arbitrairement)
Puis on rédige le diagramme suivant :
Plannification
Pour la planification j'ai produit un diagramme de GANTT
Etude des données d'entrées
Après l’analyse fonctionnelle, il est nécessaire de prendre en main les différentes données d’entrées mises à disposition.
On a à notre disposition le schéma suivant :
On a aussi la datasheet du MT8870D-1, décodeur de fréquences DTMF.
Le composant en entrée prend un signal et regarde si on à une addition de 2 fréquences et nous rend en sortie un numéro codé sur 4 bits.
2 fréquences -> 1209Hz + 697Hz = 1 -> DTMF Tones
Les 4 bits sont sur les sorties Q1,Q2,Q3,Q4 et la sortie StD est à true lorsque le composant active ses sorties.
Il faut vérifier que l’entrée TOE soit à true pour faire fonctionner le composant.
Test sur plaque d'essai du composant MT8870D-1
Sur une plaque d’essais, je refais et je soude seulement le câblage du décodeur DTMF et je mets des leds avec des résistances à la masse sur les sorties Q1 à Q4, et avec mon téléphone j'émet des fréquences DTMF.
Pour émettre des fréquences avec mon téléphone je me sert de l’application “simply DTMF”
Ainsi je pourrais voir si j’ai bien compris le fonctionnement du composant et si le câblage est correct.
Après plusieurs essais, les leds ne s'allument pas lorsque j’émet des fréquences DTMF.
Je commence à faire plus de recherches sur le composant et je regarde les différents paramètres et son fonctionnement.
Le problème peut venir de l'alimentation, des leds, du MT8870D-1, du TOE, du signal (microphone), du filtre, du gain.
Le gain se règle grâce à R1 et R2, RS = Gain Select
Je mesure grâce à l’oscilloscope la sortie du microphone ,et je me rends compte que le signal capté par le microphone est de l'ordre du mv, il est bien trop faible et il se confond dans le bruit, il faut l’amplifier, pour cela on règle le GS.
GS = 330/10 = 33
Dans un premier temps je choisis un gain aléatoirement jusqu'à trouver le bon réglage.
Je refais ensuite un test en émettant des fréquences avec mon téléphone.
Mes leds s'allument correctement, le DTMF fonctionne.
Pour une meilleure stabilité je décide de modifier et de doubler le gain -> 330/5 = 66
Le test avec les leds fonctionne encore avec un gain de 66.
Test sur plaque d’essais du composant MT8870D-1 avec une carte Arduino
Je branche ensuite la carte Arduino en suivant le schéma et je téléverse dans la carte le programme qui nous à été donné dans la carte, le programme ne veut pas se téléverser dans la carte, il s'agissait de la carte Arduino qui n’était pas reconnu par l’ordinateur, on défini le périphérique comme une carte Arduino avec le bon driver et le problème est corrigé.
Je fais maintenant un test en émettant avec le téléphone le code D52 en DTMF ce qui correspond d’après le tableau Excel à la lettre R, on se sert ensuite du port de communication de la carte Arduino pour afficher la lettre.
Le test fonctionne pour une lettre.
J’essaie ensuite d’envoyer grâce à une enceinte une série de lettres permettant d’afficher le code RETOUR_URGENT.
La réception fonctionne jusqu'à une distance de 40cm, je décide alors d’augmenter encore le gain à 100. R1 = 4.7k et r2 = 470K
On peut maintenant réceptionner le code à une distance de 8m dans l’air
Règle de propagation du son
La pression sonore d’un front d’onde sphérique est divisée par deux lorsque la distance est doublée. On perdra en dB, 6 dB lorsque l’on double la distance.
Dans l’eau on à une perte de 0.1 dB/KM
On peut retrouver ce graphique grâce à l’équation d’état de l’eau de mer qui dépend de la distance, de la pression, de la température et de la salinité de l’eau.
Il existe un effet physique qu’est la thermocline qui peut aussi poser problème.
La thermocline peut avoir un effet significatif sur la propagation du son dans l'océan. En effet, la vitesse du son dans l'eau dépend de la température, de la pression et de la salinité de l'eau.
Dans la zone de la thermocline, où la température change rapidement avec la profondeur, la vitesse du son peut également varier rapidement. Cette variation de la vitesse du son peut provoquer la réflexion, la réfraction et la diffraction du son, ce qui peut rendre la propagation du son difficile à prévoir et à interpréter.
De plus, la thermocline peut agir comme un écran acoustique naturel qui peut bloquer ou atténuer la propagation du son dans certaines directions.
Conception du PCB
Je produit ensuite le schéma de mon prototype, par rapport au schéma initial il comporte 5 leds +résistances sur les sorties Q1 à Q4 et StD pour vérifier en temps réel si le DTMF décoder fonctionne, il comporte les valeurs des résistances modifiés , un écran LCD et une alimentation interne.
Je crée ensuite le routage de la carte
Je fais ensuite une commande chez JLCPCB, qui est une entreprise qui imprime des cartes pcb.
Test du PCB
Une fois le PCB réceptionné, il faut le souder, puis faire la liste des tests suivants :
Test avec l’envoi d’une fréquence DTMF dans l'air lecture sur les leds
Test avec l’envoi d'un caractère dans l'air lecture sur la liaison série.
Test avec l'envoi d'un un code dans l'air lecture sur la liaison série
Test message sur l’écran LCD
Test avec l'envoi d' un code dans l'air lecture sur l'écran LCD.
Test du bon fonctionnement du système en autonomie.
Test dans une bassine
Test dans une bassine + son parasite
(Test dans un étang)
(Test en mer)
Test avec l’envoi d’une fréquence DTMF dans l'air lecture sur les leds :
Juste après avoir soudé le décodeur DTMF, la carte Arduino et les autres composants, je décide de faire un test en émettant une fréquence DTMF afin de vérifier le bon fonctionnement du convertisseur DTMF. Cependant, aucune LED ne s'allume. Je vérifie la continuité des alimentations et je me rends compte qu'il s'agissait de la pin VSS qui n'était pas reliée à la masse et qui avait un potentiel flottant. Je refais un test et cette fois-ci, les LEDs s'allument correctement en fonction des fréquences que j'émet.
Test avec l’envoi d'un caractère dans l'air lecture sur la liaison série.
Je vais maintenant tester l'affichage d’un caractère sur la liaison série de la carte Arduino. J'émet un caractère avec mon téléphone ; cependant, le caractère affiché n’est pas le bon. Pourtant, les LEDs s'allument correctement. Je vérifie la continuité entre les sorties Q1, Q2, Q3, Q4 et les entrées numériques de la carte Arduino, respectivement : D7, D6, D5, D4.
La continuité est bonne, la partie matérielle me paraît correcte. Je me tourne donc vers le programme de la carte. Par rapport à ma plaque d’essais, les entrées de la carte Arduino sont inversées, 7, 6, 5, 4 sur ma carte et 4, 5, 6, 7 sur la plaque d’essais. J’avais pris en compte que les entrées étaient inversées dans la définition de mes variables. Plus loin dans le code, je remarque que le programme lit tous les pins numériques : byte R = PIND; C’est pourquoi le caractère affiché n’est pas le bon. Il suffit alors d’inverser les pins de la façon suivante :
Pour cela on utilise des masques et des décalages
On refait le test et finalement le bon caractère est affiché.
Test avec l'envoi d'un un code dans l'air lecture sur la liaison série
J'émet une suite de caractères avec l’enceinte et aucun problème le code est bien reçu par la carte.
Test message sur l’écran LCD
J’utilise la fonction digitalWrite pour écrire un message sur l’écran LCD et tout fonctionne correctement.
Test avec l'envoi d' un code dans l'air lecture sur l'écran LCD.
Je teste l’envoie d’une suite de caractères en affichant le code sur l’écran LCD, le code ne s’affiche pas entièrement. J’écrit alors le code suivant :
Ainsi je prend en compte la ligne et la colonne dans laquelle le caractère précédent était écrit.
Test du bon fonctionnement du système en autonomie
La carte est alimentée grâce au câble USB qui me sert à lire la liaison série de la carte arduino. Cependant il faut que le système puisse être autonome pour cela j'alimente 3,3V avec une pile l’entrée VIN de la carte arduino. Cependant l’écran arduino est quasiment illisible, cela peut venir du LCD qui n’est pas correctement alimenté. Je me décide à changer l’alimentation et de mettre l'alimentation sur le 3,3V. L’écran LCD est toujours peu visible, j’en conclu que l’écran LCD est défectueux ou que l’écran LCD est de qualité médiocre.
Test dans une bassine
pour ce test on utilise le protocole suivant :
On met la carte dans un sac imperméable, on émet sur l’enceinte le code “RETOUR_URGENT” 10 fois.
Et on relève sur l’écran le code reçu, on peut faire ce test plusieurs fois pour plusieurs valeurs de gain du microphone ainsi que pour plusieurs valeurs de gain de la source afin d’obtenir le taux de transmission maximale.
On calcul la proportion de code transmis, pour cela on calcul le taux de caractères reçu correct par rapport au code envoyé.
Test avec un gain de 100 avec un volume de 80dB à la source.
Test avec un gain de 80 avec un volume de 80dB à la source.
- Premièrement que la proportion de code transmis dépend grandement du son émis par la source
- Deuxièmement, le gain de 57 est plus efficace (86% de transmission) que le gain de 100.
On se rend compte de deux choses :
Cependant comment savoir si la transmission fonctionnera sur 1 km ?
- Soit on fait le test en grandeur réel sur une distance de 1km
- Soit on prend la mesure du son de l'émetteur, on met le récepteur à une certaine distance, on met le son de l’émetteur à fond, puis on baisse progressivement jusqu'à ce que le récepteur ne reçoit plus la totalité du signal, on simule ainsi la distance (perte de dB) avec la baisse du son de l’émetteur (perte de dB).
Comparaison planning prévisionnel et réel :
J'ai largement dépassé les délais lors des tests sur une plaque d’essais, pensant que la prise en main des composants serait plus rapide. Cependant, j’ai rencontré plusieurs problèmes qui m'ont retardé. La réalisation du PCB a pris du temps, car je ne maîtrisais pas bien le logiciel Altium Designer. La commande du PCB, quant à elle, a été assez rapide et respectait les délais.
REX et pistes d'améliorations
Le système respecte toutes les exigences cependant des pistes d’améliorations sont envisageables.
- Plus d’exigences :
Les exigences demandées par le client n'était pas précise, on peut ajouter des exigences de dimensionnement ou bien une exigence de résistance à l'immersion ou bien encore le taux de transmission.
- Écran
Le choix de l’écran n’est peut être pas le meilleur, choisir un écran de meilleur qualité avec rétroéclairage sera nécessaire pour la bonne visibilité du plongeur.
- Microphone
Le choix du microphone n’est pas le plus optimal, on perd beaucoup d’information en fixant le microphone contre la paroi de notre système, une solution serait d’utiliser un hydrophone qui sont créés pour fonctionner efficacement dans un milieu aquatique.
- Système de codage
Le système de codage donné est à revoir, plutôt que d’envoyer caractère par caractère, il vaut mieux enregistrer des phrases pré faites et envoyer plusieurs fois un caractère pour afficher la phrase, ainsi on gagne du temps à transmettre le message (plus rapide d’envoyer 5 caractères plutôt que 13 caractères). On gagne aussi en taux de transmission, si on envoie 3 fois le même caractère, et que un de ses caractère est différent, on peut choisir le caractère dominant comme le bon.
admettons 15% d’erreur de transmission.
On suit une loi binomiale on obtient 3% d’échec de transmission.
Ce qui est bien moindre avec cette logique que de faire caractère par caractère.
- Le problème du gain
Le prototype que l’on a créé à un énorme problème, On a vu plus tôt qu’une valeur de gain de 100 fonctionne dans l’air à 10m, puis on a testé le système dans l’eau et la nous avions une transmission qui ne fonctionnait pas, on a alors fait le choix de régler le gain à 57 pour avoir une bonne transmission à 3m dans l’eau.
On peut alors se poser la question, si on augmente cette distance est ce que le système fonctionnera toujours ?
Et bien non le problème avec cette solution est que le système fonctionnera seulement à une distance fixe en fonction du gain.
Il faudrait pouvoir régler le gain en fonction de la distance, pour cela on utilisera un compresseur Basse Fréquence, qui lui réglera le gain en fonction du signal en entrée.