Sommaire

1 Présentation générale
- 1.1 Description
- 1.2 Objectifs
2 Analyse du projet
3 Préparation du projet
4 Réalisation du Projet
- 4.1 Feuille d'heures
- 4.2 Prologue
5 Semaine 1
- 5.1 Séance 1
- 5.2 Séance 2
6 Semaine 2
- 6.1 Séance 3
- 6.2 Séance 4
  - 6.2.1 Lamelle piézoélectrique
  - 6.2.2 Moteur
7 Semaine 3
- 7.1 Séance 5
8 Semaine 4
- 8.1 Séance 6
9 Semaine 5
10 Semaine 6
- 10.1 Séance 10
- 10.2 Séance 11
11 Semaine 7
- 11.1 Séance 12
- 11.2 Séance 13
12 Semaine 8
- 12.1 Séance 14
- 12.2 Séance 15
13 Semaine 9
- 13.1 Séance 16
- 13.2 Bilan de mi-parcours
14 Semaine 10
- 14.1 Séance 17
15 Semaine 11
- 15.1 Séance 18
- 15.2 Séance 19
16 Semaine 12
- 16.1 Séance 20
- 16.2 Séance 21
17 Semaine 13
- 17.1 Séance 22
18 Semaine 14
- 18.1 Séance 23
19 Liens externes

Présentation générale

Description

La communication osseuse est un type d'écoute qui permet de ne pas passer par le système auditif externe. Le système auditif externe n'est donc pas encombré ce qui offre de nouvel possibilité d'écoute.Ainsi, ce système peut se rendre très utile utile pour les personnes sourdes ainsi que pour n'importe qui ayant besoin d’être attentif au bruit environnant tel que les militaires ou les ouvriers. Le système ostéophonique que nous allons utiliser va être utilisé avec une communication à distance qui lui enverra les informations à faire écouter à l'utilisateur.

Objectifs

L’objectif de notre projet est de réaliser un système de communication par ostéophonie (communication osseuse). Une montre connecté servira de passerelle entre le casque et une interface (ordinateur ou appareil embarqué type Raspberry). Il enverra à la montre des informations sonores : musiques, conversation vocale, etc. C’est ensuite la montre qui sera chargé de transmettre l’information au dispositif d’écoute ostéophonique.

Notre objectif sera de réaliser un casque fonctionnel qui pourra communiquer à distance. Ce casque devra respecter une certaine qualité d'écoute et de conforme. Enfin, nous devrons nous attacher à trouver le meilleur système de communication afin d'économiser l'énergie et d'optimiser le transfert des données.

Analyse du projet

Positionnement par rapport à l'existant

Notre objectif est de réaliser un appareil moins coûteux que la concurrence. En effet, ce type de produit est vendu très chère par rapport à des dispositifs auditifs classiques. Tout comme les produits existants, il nous sera nécessaire de parvenir à transmettre du son par conduction osseuse. Pour cela nous devrons étudier les différents composants convertissant l'information sonore en vibration. Il sera également intéressant de tester l'emplacement idéal où poser l'émetteur afin d'avoir le meilleur son possible : mâchoire, tempe, arrière du crâne. d’étudier les différents types de communication à distance: Bluetooth, wifi, radio.

Analyse du premier concurrent

Le premier concurrent est l'entreprise audilo qui commercialise à la fois des casques audio à conduction osseuse et des appareils d'aide à l'audition. Contrairement à cette entreprise nous allons faire en sorte de créer un produit bien moins cher pour la clientèle. En effet, actuellement ces casques sont vendus à partir de 80 euros. Ils utilisent la technologie Bluetooth pour communiquer, nous essayerons d'avoir une vitesse et qualité optimale afin d'avoir quelque chose de comparable aux casque déjà existant à ces prix.

Il sera intéressant par exemple de s'intéresser à la dernière version du Bluetooth pour sa qualité. Au vue des modules piézoélectriques, ils ne vont pas, dans les conditions normal d'utilisation, dans les fréquences hautes entendu par les humains ce qui peut être un problème pour l'écoute de musique ou de son de haute qualité.

Analyse du second concurrent

Le deuxième concurrent est Bose, c'est un constructeur de casques de haute qualité. Notre casque utilisera la technologie osseuse pour fonctionner et comme on ne peut pas placer le capteur directeur sur un os la qualité est moins bonne que pour un casque normal. Cependant, notre casque aura l'avantage de laisser les oreilles libres pour les utilisateurs qui souhaitent entendre en même temps l'environnement ou d'autres personnes.

Notre casque sera destiné à une utilisation plus nomade que des casques Bose qui sont plus destiné à des professionnels ou alors à des utilisateurs voulant une grande qualité d'écoute. Enfin, notre casque sera réalisé pour être bien moins cher que cette marque.

Scénario d'usage du produit ou du concept envisagé

Lors d'un tour de mentalisme, un magicien devra deviner plusieurs cartes les yeux bandées. Son assistant devra donc lui communiquer à chaque fois la réponse via un système de communication par ostéophonie dissimulé dans le foulard du magiciens.

Réponse à la question difficile

Quel sont les os les plus sensibles à l'ostéophonie ?

=> Le crâne, et principalement les os en contact avec l'oreille interne, et notamment la mâchoire (Mandibule), et la tempe (L'os Temporale) sont des os qui sont très proche de la peau. Nous allons devoir tester une fois le casque fonctionnel avec quel os cela fonctionne le mieux.

Préparation du projet

Cahier des charges

Le cahier des charges imposé contient quelques impératifs :

Casque permettant d'émettre du son par ostéophonie
La montre Texas Instrument est imposé et sera relié filairement au casque / oreillette
Une communication à distance avec un ordinateur ou Raspberry est également imposé

Malgré tout, la majorité des éléments nous sont laissés libres :

Nous pouvons choisir la méthode de conversion de l'information sonore en vibration pour la conduction osseuse : transconducteur ostéophonique, moteur à rotation, etc.
Il nous est également nécessaire de choisir sur quel os se placer pour transmettre au mieux le son; des tests sont donc à réaliser.
La méthode de communication nous est également laissé libre : Wifi, Bluetooth, Radio.

Choix techniques : matériel et logiciel

Liste des tâches à effectuer

Etude des différentes solutions pour entendre par ostéophonie : etude qualitative : volume, qualité du son
création d'un PCB pour accueillir l'ensemble processeur,module bluetooth/audio et la mémoire
réalisation de la communication bluetooth
création d'un interface utilisateur pour l'émission vers le casque
conception d'un casque : utilisation de la modélisation 3D

Calendrier prévisionnel

Réalisation du Projet

Feuille d'heures

Tâche	Prélude	Heures S1	Heures S2	Heures S3	Heures S4	Heures S5	Heures S6	Heures S7	Heures S8
Analyse du projet	6
Recherche documentaire	5	9	5	3	1		2	2	2
montage électronique			3	4	4		3		2
conception de carte électronique et de schematics						6	1	5
Modélisation 3D						3	2	2
Programmation									4
Total	11	9	8	6	5	9	8	9	8

Prologue

Semaine 1

Séance 1

Nous nous sommes renseignés plus en détail sur les éléments de notre projet et notamment sur la montre. En effet, nous n'avions pas pensé à vérifier qu'elle possédait une prise quelconque pour y brancher un casque car cela paraissait évident pour rendre la montre nécessaire. Après l'étude de la datasheet de la montre TI EZ430, nous nous sommes rendu compte qu'il n'y a en fait aucune prise (jack, usb, etc.) sur laquelle brancher notre casque. Cela voudrait dire que l'ordinateur (ie l'interface) va envoyer une bande sonore à la montre et que celle-ci effectuera un simple relais en envoyant à son tour la bande sonore au casque. La montre ne semble donc pas être indispensable pour notre projet. Pour le savoir nous discuterons avec un enseignant pour en savoir plus.

Nous avons également pu avoir une piste sur les microcontrôleurs les plus adaptées à notre utilisation. En effet, notre dispositif doit être suffisamment petit et discret pour pouvoir être dissimulé. Les contraintes qui rentre donc en jeu sont :

Nombre de pins supérieur à 8 (pour le DAC et/ou le module Bluetooth)
Petit taille de batterie, donc MCU à faible consommation d'énergie
Fréquence d'horloge suffisante (à définir)

Après quelques recherches, nous nous sommes rendu compte que les microcontrôleurs Atmega ne sont pas adaptées à cet usage en vu de leurs consommations, mais la famille de microcontrôleurs STM32L (dit LOW POWER) sont un bon compromis entre performances et consommation.

Nous avons aussi listé les composants électriques pour l'ostéophonie, nous avons décidé de tester plusieurs technologies. D'après nos recherches, nous pouvons avoir des vibrations (transformation du signal électrique en vibration mécanique) soit en utilisant un moteur à courant continue, soit un transconducteur piézoélectrique. Nous avons donc commandé trois capteurs piézoélectriques avec différentes fréquences de résonance pour essayer de couvrir les fréquences audibles, et un moteur à courant continue.

Séance 2

Nous avons donc discuté avec M. Boé sur l'utilité de la montre. Il pensait qu'il y avait possibilité d'y ajouter un module pour stocker une bande sonore directement dessus par exemple. Cela aurait permis de se passer d'ordinateur et donc, de lancer une piste directement à partir de la montre mais cela n'est malheureusement pas possible. En effet, après vérification il n'y a pas de PIN libre. Notre projet doit donc être modifié : nous devrons envoyer des informations depuis l'ordinateur au casque directement.

Nous avons ensuite cherché les modules que nous devions utiliser pour le casque. En effet, nous avons besoin de choisir un composant de communication sans fil (Bluetooth, WiFi, Zigbee, etc.). Pour notre application, nous cherchons à transmettre de la voix ainsi que de la musique. Pour la musique, il faudra cependant vérifier que la conduction osseuse permet d'entendre de la musique, d'avoir une qualité d'écoute suffisante. Un fichier mp3 est souvent codé avec un débit de 128kbit/s (avec un MPEG-1 Layer III) car c'est un bon compromis : il permet d'avoir une bonne qualité par rapport au poids du fichier. Il y a différent types de protocoles réseaux qui peuvent être utilisés :

Le WiFi est un protocole qui consomme énormément d'énergie et qui est utile pour des débits très rapide sur des grandes distances, ce qui n'est pas notre cas.
Le Zigbee quant à lui peut théoriquement permettre du transfert à 250 kbits/s mais cette valeur ne représente pas le payload (les données utiles). En effet, il prendre en compte tous les bits de protocoles comme le CRC ou l'entête.

Ainsi avec Zigbee on atteint au maximum un throughput de 912 bits/s (throughput représente le payload diviser par le temps complet pour l'échange de donnée, ie transfert et réception)[1].

Le Bluetooth v4.0/4.1 permet un throughput de 305kbits/s et le v4.2 permet quand à lui d'atteindre 803 kbits/s[2].

(remarque : on parle ici du Bluetooth 4 Classic et non du Bluetooth 4 Low Energy qui n'est pas du tout conçu pour ça)

Étant donné le débit correspondant au mp3 nous nous tournons donc vers cette alternative car le débit est suffisant pour notre utilisation.

Nous avons également besoin d'un DAC (Digital to Analogic Converter) car une fois l'information numérique reçu par le module wireless, nous devons le convertir en analogique pour transmettre les vibrations correspondantes.

Semaine 2

Séance 3

Lors de cette séance nous avons terminé la liste de matériel pour être près pour la commande et savoir ce que nous allons utiliser. Nous avons perdu beaucoup de temps lors de cette séance à cause des notions autour du Bluetooth. En effet, comme précisé dans la séance précédente, les données intéressantes pour le Bluetooth sont le data throughput et le payload. Le problème est qu'il n'existe visiblement aucune norme sur quelles informations sont données pour les datasheets. Sur la plupart des datasheets, Seul le débit est indiqué et ce débit ne correspond en fait qu'au débit théorique de chaque version du Bluetooth. Pour le peu de modules que nous avons trouvés contenant des informations supplémentaires, les indications ne sont pas cohérentes puisque pour un modèle le data throughput n'est que de 32 kbps (ce qui n'est pas claire car il n'est pas précisé si l'on parle ici de bits ou de bytes) ce qui est très faible comparé au débit du Bluetooth. Cela signifierait que sur 1 Mb pour une seconde, seulement 32 kb sont "utiles", ce qui n'est pas cohérent. Sur un autre modèle enfin, le data throughput est indiqué en kilobyte (ce n'est donc pas un débit mais une valeur) et dépend du système d'exploitation utilisé. Ces valeurs restent très faible même si on suppose que l'on donne cette valeur pour une seconde.

Après concertation avec M.Redon puis avec M.Boé, qui nous ont confirmés que ces valeurs étaient effectivement très faible et/ou pas précises, incohérentes, M.Boé nous a indiqué de trouver un modèle étant de dernière génération et de le commander quitte à faire des tests plus tard quant à son data throughput réel. Finalement, nous avons trouvé un composant qui contient à la fois un module Bluetooth de quatrième génération permettant le Bluetooth Classic et le BLE, et un module de conversion audio. Ce composant est en effet pensé pour être utilisé sans même de contrôleur si nécessaire et d'assurer la réception Bluetooth et la conversion audio.

Comme précisé précédemment, le Bluetooth LE 4.2 étant conçu pour être utiliser pour de long moments de veilles et un faible volume de données, il ne permet pas d'avoir un débit net (troughput) supérieur à 128Kbits/s. Nous avons donc préféré utiliser un Bluetooth Classic 4.1 qui contient un DAC 12 bits intégré et un module IS2020 pour avoir de l'audio stéréo en sortie [3]. Le module Bluetooth que nous avons choisi est de classe 2, ce qui veut dire qu'il a une puissance de 2.5W et une porté d'une dizaine de mètres [4].

Nous avons aussi commandé une mémoire qui nous permettra de stocker le fichier audio dans le casque pour un deuxième mode d'utilisation ou cas où la transmission en Bluetooth streaming ne serait pas optimal.

Séance 4

Lors de cette séance nous avons utilisé le matériel de la salle C201 pour vérifier le fonctionnement d'une lamelle piézoélectrique et du moteur.

Lamelle piézoélectrique

Nous avons premièrement fait des tests avec un générateur de signaux. Comme vu sur internet le signal qui émet le plus de son est le signal carré (puis le triangle et enfin le plus faible est le sinus). Cela s'explique par le fait que plus la variation de tension est importante et plus le matériaux va vibrer et donc produire du son. Nous avons ensuite testé de brancher directement la lamelle sur une sortie jack. Pour cela nous avons utiliser des simples écouteurs dont nous avons enlever les speakers (partie à mettre dans l'oreille) puis nous y avons souder la lamelle.

Dans chacun de nos tests nous avons pu entendre du son par ostéophonie, les tests sont donc concluant mais à nuancer :

Premièrement, le volume sonore est très faible comparer à des écouteurs classiques
Ensuite, le volume sonore dépend beaucoup de l'endroit placer : il est le plus fort lorsque la lamelle est mordu entre les dents, il est également assez élevé au dessus de la tempe
Contrairement à nos attentes, il est parfaitement possible d'entendre le son directement par l'oreille auditif, c'est un problème car l'objectif est de laissé le champ auditif libre pour d'autres sons.

Pour la prochaine séance, l'objectif est d'ajouter à notre montage un amplificateur pour pouvoir entendre le son à un volume bien moindre. Pour cela, nous devrons prendre des mesures lors de la prochaine séance pour voir la tension nécessaire pour que le son soit à un niveau agréable lors de l'écoute. Remarque : l'inconvénient d'augmenter le volume sonore des lamelles est que l'on entendra également bien mieux le son même sans le coller à un os ce qui n'est pas ce qui est voulu, il faudra donc trouver le bon équilibre.

Moteur

Nous n'avons pas réussi à faire fonctionner le moteur que nous avions mais nous avons trouvé d'autres moteurs que nous essaierons lors de la prochaine séance.

Semaine 3

Séance 5

Nous avons continué les tests avec plusieurs moteurs et le transducteur piézo déjà disponible. Le piézo que nous possédons déjà fonctionne à 30Vpp max et résonne à 4200±500Hz. Nous disposons également de plusieurs moteurs à courant continu de taille différentes et donc sans doute de puissances différentes. Malheureusement, les caractéristiques techniques ne sont cependant pas indiqués mais ces moteurs peuvent nous permettre d'avoir une bonne idée du fonctionnement d'un moteur en but auditif.

Pour commencer nous avons réussi à faire fonctionner les moteurs et ils s'avèrent produire un son moins élevé pour une même tension par rapport à une lamelle. Également, l'avantage d'un tel moteur est qu'il ne produit pas de son audible par les oreilles ce qui est un gros avantage. Pour le plus petit moteur testé, nous avons pour une même tension (0.3 V) un son légèrement moins audible que pour un lamelle. Cependant pour des plus gros moteurs la tension demandée devient de plus en plus importante. Le problème d'un tel moteur c'est qu'il n'est pas possible de tester sur les os, la seule solution a été de faire les comparaisons lorsque le composant est mordu entre les dents. Il faudrait donc modifier le moteur pour que la partie centrale ne tourne pas mais effectue des mouvements de va-et-viens pour venir taper l'os.

En cherchant, nous avons trouvé un composant Adafruit qui permet justement de conduire le son à travers les os. Ce composant fonctionne exactement comme nous voudrions : il y a trois bobines qui entourent une bobine centrale. Cette dernière bobine se déplace en fonction du champs du moteur. Nous avons donc rajouté ce composant à la liste du cahier des charges pour pouvoir tester si il fonctionne comme on l'attends.

Nous avons également mesuré qu'en sortie d'un prise jack, la tension maximale que nous obtenons est de 200mV ce qui n'est pas suffisamment fort pour une bonne qualité d'écoute. Nous avons donc commencé à utiliser un amplificateur audio LM386 pour augmenter le volume sonore. Nous vérifierons lors de la prochaine séance que nous amplifions correctement.

Le dernier point à préciser est que le son est différent en fonction du composant utiliser. En effet, il peut être plus grave ou plus aigu d'un composant à un autre ce qui est important pour de l'écoute de musique mais l'est moins pour écouter une voix.

Semaine 4

Séance 6

Lors de cette séance nous avons réaliser un amplificateur audio afin de tester les moteurs et les lamelles piézoélectriques pour des sons bien plus complexes que de simples sinus. Pour réaliser ce montage, nous avons utilisé un montage à base d'un composant que nous avions utiliser l'an dernier en CCE pour un montage audio justement : l'amplificateur LM386N.

Lors du premier montage nous ne parvenions pas à amplifier la tension d'entrée et il n'y avait rien qui arrivait jusqu'à la sortie du montage. Après plusieurs tests nous avons constaté que le composant récupéré n'était en fait pas fonctionnel. Nous avons donc commandé sur le site de Thierry Flamen le composant qui était justement disponible. Nous avons également demandé un potentiomètre pour pouvoir contrôler le volume.

Nous avons donc refait tout le montage. Celui-ci s'est avéré très fonctionnel; on peut d'ailleurs noter que l'amplificateur est censé être alimentée en 9V mais peut très facilement fonctionner au minimum à 6V. Le composant LM386 permet de modifier le gain grâce à une capacité entre 2 pattes (1 et 8) et une résistance intermédiaire permet de régler le gain entre 0 et 200. (capacité seule : gain de 200 / rien du tout entre les pattes : gain de 20). Avec la capacité seule on obtient un tension bien trop fort en sortie ce qui rend inaudible le moteur car il trembles beaucoup trop. On règles donc le gain en fonction du moteur que l'on utilise.

On peut également, comme précisé plus haut, régler le potentiomètre pour modifier le "volume" en sortie. Lors de tests avec la lamelle piézoélectrique, nous parvenons à obtenir un son plus propre en baissant le volume par l'action du potentiomètre. On peut en déduire que plus le volume augmente par cette action et plus le son sera bruité.

De manière général lors de l'écoute avec un moteur, le son produit est de bien moindre qualité (assimilable à une radio écouté en plein campagne !). De plus, nous remarquons que pour des tensions plus élevé on entends également le son sans le coller sur un os : ce son provient de l'intérieur du moteur et provient sans doute de la vibration interne plus élevé. Cependant, le son est bien moins audible que pour une lamelle piézoélectrique qui s'avère très bruyante et qui produit très facilement un son aigu en continu. Il faudra donc vérifier que le composant Adafruit commandé soit bien un compromis entre ces deux solutions.

Semaine 5

Séance 7

Lors de cette séance nous avons utilisé Altium Designer pour commencer la création d'un PCB, la semaine dernière nous avions déjà récupérer le symbole du MCU STM32L4 qui est déjà disponible. Le module Bluetooth n'est cependant pas disponible donc nous avons dû le créer nous même. C'était la première fois que nous utilisions Alitum dans cet objectif et c'est donc plus long que prévu. En effet, le symbole est déjà réalisé mais il reste à terminer le footprint. Nous prenons plus de temps sur cette partie car il ne faut pas se tromper sur les dimensions des trous ni sur les distances car sinon le PCB sera inutilisable.

Séance 8

Durant cette séance nous avons finalisé la réalisation des symboles et footprints des composants électronique, nous avons créé celui du module Bluetooth BM20SPKS1NBC-0001AA et de la mémoire flash IS25WP064A-RMLE avec Altium le premier en CMS et l'autre traversant, et nous avons récupéré celui du microcontrôleur STM32L433CCT6 sur internet.Durant cette séance nous avons également fait quelques recherches sur l'architecture matériel que nous allons adopté. nous nous somme rendu compte que le module Bluetooth BM20 contient une mémoire EEPROM et un cristal 16MHz en plus de la carte Bluetooth IS2020 pour le transfert audio stéréo. Nous pouvons donc théoriquement utiliser le IS2020 indépendamment du BM20, qui sera commandé en UART directement par le MCU et court-circuitant donc la commande du BM20.

L'utilisation du BM20 reste aussi possible, en programmant l'EEPROM avec un utilitaire fourni par Microship, la programmation sera limitée aux fonctionnalités fournis et donc diffusera automatiquement les données reçues.

Séance 9

Lors de cette séance nous avons réalisé grâce à l'outil de modélisation 3D Blender un premier prototype de casque 3D que nous pourrions réaliser. Ceci est cependant un prototype puisque le modèle est dans l'ensemble très fin et il faudra l'épaissir un peu pour faire rentrer la carte et l'alimentation.

Idéalement nous aimerions réaliser deux prototypes :

un modèle caché dans un objectif de dissimuler le système à la vue de tous; deux idées sont retenues :
- placer le système dans la doublure ou l'intérieur d'un bonnet (ce qui existe déjà pour des écoutes classiques)
- dans un gant au bout d'un doigt (dans une doublure aussi sans doute) et l'utilisateur n’aurait qu'à placer son doigt sur la tête pour entendre.
un modèle utilisable par le grand public notamment pour la course ou simplement garder les oreilles externes disponibles.

Semaine 6

Séance 10

Lors de cette séance nous avons fait des recherche sur la programmation du STM32L433CCT6. les microcontrôleurs STM32L font partie de la gamme des cœurs de processeurs proposés par ARM, le Cortex-M4, opérant sur des registres de 32 bits, fournit un compromis entre une puissance de calcul appréciable et une consommation réduite qui, sans atteindre les performances du MSP430 (16 bits), propose néanmoins des modes de veille en vue de réduire la consommation moyenne d’une application. [5]

La chaîne de compilation est basée sur l’habituelle génération des binaires issus de 'binutils' et 'gcc' sur architecture x86 à destination du processeur ARM, et en particulier Cortex M3. Nous nous somme basé sur le script git://github.com/esden/summon-arm-toolchain.git pour l'installation de la toolchain avec la version Vanilla de GCC au lieu de linaro GCC, par défaut, seule la bibliothèque libre 'libopencm3' est installée.

Le second prérequis, après l’obtention d’une chaîne de compilation fonctionnelle, concerne l’outil pour programmer le microcontrôleur. Deux solutions sont possibles : la programmation par JTAG grâce à OpenOCD et à une sonde, et la programmation par RS232 avec un outil tel que stm32flash. Nous ne disposant pas de sonde JTAG, nous allons donc utiliser la deuxième solution avec une liaison série. 'stm32flash' prend en argument le nom du fichier contenant l’image binaire à placer en mémoire du microcontrôleur (fichier .bin ou .hex), la commande à effectuer (lecture, écriture, vérification) et l’interface de communication.

Séance 11

Durant cette séance nous avons testé les transducteurs à conducteur osseux et pièzo que nous avions commandés. Les lamelles pièzo restent beaucoup plus puissantes que le moteur et le Bone transducer, mais elles émettent du son audible, le Bone transducer lui (comme le moteur) est moins puissant mais beaucoup plus discret est pratique à utiliser. Nous avons donc adapté et utilisé notre montage d'amplification, est nous obtenons un résultat correcte, avec un signal d'entrée d'amplitude entre 0.5V et 0.9V, et une alimentation de 4V. Nous pouvons également alimenter l'ampli à 3.6V (tension de la pile commandé) comme le reste de nos composants. Nous avons néanmoins noté que le signal de sortie est fortement bruité, nous devons donc filtrer celui-ci, ou améliorer l'amplification si il se dégrade après le transferts Bluetooth. Après plusieurs tests il s'avère cependant que le son sortie est propre. Le bruit provient donc peut-être du montage en lui-même.

Lors de cette séance, nous avons également créer un PCB du module Bluetooth. Ce PCB ne va contenir que le module Bluetooth et les sorties sont reliés à des Headers afin de pouvoir faire des tests dessus. Par manque d'expérience nous n'avons pas commandé deux exemplaires du module Bluetooth et du microcontrôleurs, ainsi nous ne pouvons pas réaliser un PCB de test et un autre final. Le problème est qu'il existe deux solutions au niveau de la carte :

nous n'avons pas besoin du microprocesseur car celui intégré au module Bluetooth suffit pour notre utilisation
nous avons besoin du STM32 pour pouvoir remplir les fonctionnalités attendues

Nous avons essayé de souder des fils directement sur les sorties du BM20 mais ça s'avère très délicat et nous risquons de l’abîmer. Une solution envisagé par M.Boé serait d'utiliser ensuite cette carte comme un shield sur une autre carte qui contiendrait le reste des composants nécessaire. Notre problème sera cependant le manque d'espace étant donné que nous recherchons quelque chose le plus petit possible. Nous allons donc dans un premier temps faire les tests et en parallèle commander un autre module.

Semaine 7

Séance 12

Lors de cette séance nous avons finalisé la conception du PCB du module Bluetooth BM20. Nous avions décidé qu'il valait mieux réaliser un PCB de test pour le BM20 afin de savoir si ce dernier est a besoin du microcontrôleur STM32L pour pouvoir satisfaire notre cahier de charge ou pas, nous avons donc adapté ce PCB à la breadbord. Dans le cas contraire, Nous avons également commandé un autre module Bluetooth BM20 pour pouvoir réaliser un autre PCB final avec le microcontrôleur et le circuit d'amplification.

Nous avons également fait des recherche sur d'autres ampli audio plus adapté à la contrainte énergétique. L'ampli LM386 fonction avec une tension entre 4V et 22V, malgré qu'avec la tension de 3.6V dont nous disposons l'ampli marche bien, nous préférons trouvé un autre ampli qui consomme moins. L'ampli TDA2822 fonction avec une tension entre 1.8V et 15V, et fonctionne en stéréo, semble donc plus adapté.

Séance 13

Durant cette séance nous avons réalisé des plan Altium des circuits d'amplification du TDA2822 et du LM386 pour pouvoir les intégrer au module Bluetooth. Et nous avons également vérifié les branchement du module Bluetooth BM20, Nous nous somme rendu compte qu'il fallait à chaque pin une résistance pulldown, et que, en plus des pins RX et TX, il y avait des pins d'appairage, de changements de mode (utilisateur, programmation EEPROM, et modification Firmware), et d'initialisation.

Nous avons également vérifié notre PCB BM20 de test avec M.Boé, qui a retiré le plan de masse sous le module pour le garder loin de l'antenne Bluetooth. Puis nous avons remis les fichiers du PCB à M.Flamen pour l'impression.

Lors de cette séance nous avons également une nouvelle version du casque qui sera plus simple à modifier et à imprimer (moins de polygones, moins d'arrondis). Cette version est également plus large pour pouvoir accueillir le PCB, le bone transducer et la batterie.

Semaine 8

Séance 14

Lors de cette séance nous avons récupéré le PCB que nous avions fait imprimer. Nous avons donc souder le module bluetooth dessus. Pour ce faire, nous nous sommes servi de pâte abrasive mais nous n'avons pas utiliser le four sur les conseilles de M. Flamen car il a déjà eu des problèmes avec ce type de composant au four. Après avoir placer la pâte puis le composant, nous avons utiliser un fer à souder fin (à 300 degrés) pour solidifier la pâte ce qui est très efficace. Cependant nous n'avions pas mis assez de pâte la première fois car elle perd en fait environ la moitié de sa taille une fois sèche. Nous avons donc réitéré l'opération une deuxième fois. Après avoir vérifié grâce à un multimètre que nous n'avions pas de problème de contact et que tout était correctement soudé, nous avons réalisé le montage visible pour la séance précédente. Ce montage est cependant fait pour la programmation. Pour le mode "normal" d'appareillage nous passons simplement P2_0 à l'état haut et nous n'avons pas besoin des connexions TX et RX. Cependant dans le temps qu'il nous restait nous ne sommes pas parvenu à faire fonctionner le système. Après lecture plus approfondi, il semblerait que le module nécessite d'être "allumé" par le pin MFB qui selon la datasheet est utilisé comme Power key when in off mode soit comme clef pour quitter le mode off qui semble être un mode de veille basique ou le système tourne au minimum (au vue de la consommation). Pour vérifier dans quel mode nous sommes et ce qui fonctionne, nous avons également appris sur un forum que pour le mode d'appareillage des DELs branchées à SYS_PWR clignotent et restent allumées en mode programmation.

Séance 15

Sur cette séance, comme précisé ci-dessus, nous avons ajouté des LEDs pour connaître le mode de fonctionnement actuel du module et nous avons su utilisé le pin MFB pour enfin nous appareiller à notre module depuis un téléphone portable. Dans un second temps nous avons essayé de regarder si par défaut, lorsqu'on envoie des informations, le BM20 envoie des informations sur la sortie audio ou sur TX mais nous n'avons rien vu. Nous avons donc par la suite télécharger un ensemble de logiciels qui sont fait pour programmer le module. Cependant il y a pas moins de 5 exécutables à utiliser pour pouvoir communiquer et programmer le BM20. Grâce à un page de forum sur le site du constructeur MicroChip. Cette page de forum est assez succincte mais nous avons pu en retirer quelques informations sur quelles logiciels à utiliser et dans quel ordre. En effet, il faut créer un fichier texte contenant pour résumé le code que l'on veut implémenter avec un premier logiciel. Ensuite, on utilise un second logiciel qui convertit une première fois en binaire puis une seconde fois ce binaire au format .ipf. Enfin, il faut parvenir à utiliser une liaison série pour écrire sur l'EEPROM pour y téléverser notre configuration. Nous avons finalement réussi à modifier le code, pour cela nous avons demandé une autre configuration pour les LEDs d'état. Nous avons constaté que leur comportement changeait bien à chaque écriture. Ensuite nous avons activé l'UART qui est désactivé par défaut mais malheureusement nous n'avons pas réussi à communiquer en série. Le module série FTDI à bien les LEDs qui nous indiquent le bon fonctionnement mais il est impossible d'utiliser un logiciel tel que putty pour se connecter en liaison série.

Semaine 9

Séance 16

Lors de cette séance nous avons utilisé le manuel de la carte d'évaluation BM-20-EVB qui est une carte qui permet de tester toutes les fonctionnalités de notre module Bluetooth sur une carte déjà réalisé. Sur son manuel nous avons trouvé des informations plus détaillées sur les logiciels et ainsi, nous avons pu confirmer ce que nous avions déjà fait lors de la dernière séance. Par la suite nous avons utilisé les pins qui servent normalement pour la prise jack pour essayer de récupérer le son. Nous sommes en effet parvenu à envoyer de la musique à partir d'un téléphone à distance et de la récupérer grâce à notre écouteur ostéophonique. Le système est donc bien fonctionnel mais le son est légèrement bruité et très faible en volume. Nous devrons donc utilisé l'amplificateur LM386 grâce au montage que nous avions réalisé pour pouvoir entendre le son correctement.

Nous avons également installer la chaîne de compilation arm-none-eabi-gcc pour le STM32L, et nous avons rédigé un Makefile pour la compilation et la génération du fichier binaire. Pour programmer le microcontrôleur nous avons également installer deux utilitaires openocd et stutil fonctionnant avec le flasher ST-LINK/V2 avec les pin SWCLK et SWDIO du STM32L. Nous avons donc emprunté une carte de développement STM32 Nucleo-64 boards disposant du programmeur ST-LINK/V2 pour pouvoir tester notre Makefile.

Bilan de mi-parcours

Il nous faut imprimer un PCB qui contient au moins le BM20 et l'ampli audio.
Nous devons choisir si l'on aura le temps d'implémenter le microprocesseur STM32L ainsi que la mémoire flash et ainsi les placer sur le PCB ou non
Imprimer le casque avec un plastique souple et un emplacement pour pouvoir placer tout notre PCB et notre batterie

Semaine 10

Séance 17

Lors de cette séance nous avons fait des recherches sur le STM32L pour la programmation. Nous avons notamment noté tous les pins dont nous pourrions avoir besoin ainsi que les différents pins d'alimentation et notamment sur le GROUND qui est ici appelé VSS et nous GROUND. En effet, l'alimentation est gérer par plusieurs pins VDD et un pin VSS qui correspondent en fait au potentiel positif et négatif de l'alimentation. Nous avons aussi déterminer les pins utilisés au fonctionnement du microcontrôleur, tel que ceux servant à l'alimentation, l'horloge, et des entrées sorties de testes.

Nous avons également conçu le PCB du STM32L. Celui-ci est fait avec le même objectif, c'est à dire tester les différentes fonctionnalités et réussir à programmer notre composant. Ce PCB a été réalisé bien plus rapidement que le précédent grâce aux compétences acquises lors du premier PCB et nous avons donc lancé l'impression à la fin de la séance.

Nous avons également eu des problèmes sur le module Bluetooth. En effet, le module semblait bloquer en appareillage et ce, peu importe comment étaient branchés les pins dédiés. Nous avons donc rechercher dans les fichiers que nous avions modifiés grâce aux différents logiciels si nous n'avions pas bloquer une opération. Nous avons également essayé de réinitialiser la carte mais malgré un témoin lumineux rien ne semblait fonctionnait. Avec l'aide de M.Boé, nous nous sommes finalement rendu compte que l'erreur était très simple : nous avions simplement décalé de un pin l'un de nos fils et nous ne changions donc rien lors de nos différents essaies.

Semaine 11

Séance 18

Cette séance s'est axé sur la soudure du microprocesseur. Cette soudure s'est avéré bien plus dur que pour le module Bluetooth car l'écart entre chaque pin n'est que de 0.280 millimètre. Cette distance est bien trop petite pour pouvoir appliquer la pâte à braser avec la seringue. La seule solution qui nous a été conseiller par M.Flamen est d'appliquer une ligne de pâte à braser sur tous les pins (et donc même entre chaque pin). Ensuite nous avons placé le composant le plus précisément possible et nous avons utiliser le four. En sortie du four, on voit bien que l'étain s'est resserré sur les pins mais il y a quand même quelques court-circuits entre plusieurs pins. M.Flamen nous a donc montré la marche à suivre pour réussir à enlever l'étain sans enlever la soudure partout. Au final, il semble que nous ayons un seul court-circuit entre deux pins que nous n'utiliserons pas.

Ensuite, nous avons effectué de nombreuses modifications sur le casque afin qu'il soit imprimable. L'idée est de scinder chaque pièce en deux pour que l'on puisse mettre nos composants à l'intérieur et ensuite coller les pièces. Il aurait été plus efficace d'utiliser des fixations avec des trous et des inserts directement sur les pièces mais en demandant à certains collègues de la filière mécanique nous n'avons pas pu savoir quelle dimension il fallait laissé pour que les pièces s’emboîtent.

recherche code, programmation et protocole a utiliser

Séance 19

Nous avons commencé par effectuer des tests en branchant l'amplificateur audio avec la sortie son du module bluetooth afin de voir si on obtient un son de bonne qualité assez fort. Malheureusement nous nous rendons compte que le son est très bruité et n'est pas fort (aussi fort que sans amplificateur). En analysant la sortie son du module bluetooth, nous nous apercevons que la sortie est toujours à 2.4V. Lorsqu'on le composant transmet la musique la composante continu de 2.4V reste et c'est uniquement qu'une très faible tension qui varie. Nous décidons donc de supprimer la composante continu pour voir le rendu. Pour cela nous avions décidez de faire un passe-bas mais M. Boé nous a conseillé d'utiliser simplement une capacité. En ajoutant une capacité on s’aperçoit que le son est bien plus fort car la variation de tension ce fait cette fois sur tout l'intervalle de 2.4V. C'est pourquoi, nous réalisons que nous n'aurons en fait pas besoin d'utiliser d'amplificateur car non seulement ce genre de système rajoutera toujours du bruit mais en plus le son est suffisamment audible.

Nous avons finalisé les fichiers 3D. Pour cela, grâce à Blender, nous avons vérifié que l'épaisseur de chaque pièce était suffisante. Il a été en effet nécessaire de rajouter une épaisseur aux pièces car il faut penser qu'elles vont être imprimer en 3D. Nous avons également regarder l'angle entre chaque pièce (pour éviter les structures de soutien) ainsi que vérifier qu'aucune face ne rentrait dans une autre et qu'il n'y avait pas de creux dans le maillage.

Durant cette séance nous avons aussi monter le circuit de teste du STM32L, avec le programmeur ST-LINK/V2 présent dans STM32 Nucleo-64 boards en utilisant les pin SWCLK et SWDIO. Le microcontrôleur présent dans la carte de développement n'étant pas le même que le nôtre, nous avons donc adapter le Makefile et le code précédemment conçu de tel sorte à compiler pour le STM32L433CC. Puis nous avons modifier les jumpers de tel sorte à court-circuiter le microcontrôleur présent dans la carte de développement et programmer celui en sortie du SWD. Après quelques tests nous nous sommes rendu compte que le bootloader du STM32L n'était pas correctement mis.

Semaine 12

Séance 20

Nous avons essayé de réaliser l'impression de nos pièces 3D pour le casque mais cela s'est avéré très fastidieux au Fabricarium : une impression avec du plastique souple a échoué trois fois et l'autre à été arrêté sans accord. Etant donné que le nombre de réservation est très limité il aurait été difficile de trouver un créneau avant une semaine. Grâce à l'aide de M.Redon nous avons pu imprimer notre casque. Plus précisément une oreillette pour se rendre de deux problèmes :

le casque est très volumineux en l'état et nous n'avons pas besoin d'autant d'espace.
comme la souligné M.Redon nous n'avions pas fait de système de fixation (cf séance 18), nous ayant donné des conseilles nous allons modifié le prototype en conséquence.

Lors de cette séance nous nous sommes concentré sur la partie codage du STM32L4. Cela s'est avéré difficile car notre composant est très peu utilisé et trouvé des bibliothèques et des logiciels compatible s'avère délicat. En parallèle nous décidons donc de regarder comment nous pourrions le faire avec un 328p car ce processeur est très documenté et nous l'avons déjà utilisé à plusieurs reprise. Bien sûr il ne s'agirait que d'un prototype car il consomme bien plus que le STM32. Cela nous permettrait néanmoins de proposer un prototype possédant la fonctionnalité de stockage de musiques. Après quelques recherches nous décidons d'utiliser le format .wav qui permet de ne pas utiliser de conversion à partir du format .mp3. Ce serait bien plus complexe car la conversion comporte beaucoup d'étapes et de calcul compliqué à implanter sans module dédié. Nous avons également souder une mémoire flash pour pouvoir faire des tests dessus. Nous n'avons pas eu le temps de le faire lors de cette séance mais c'est le dernier point à éclaircir avant de pouvoir enfin imprimer le PCB final.

Séance 21

Pour pouvoir utiliser le STM32L nous devons modifier le pcb pour libérer les pins qui permettent de mettre le bootloader, et aussi modifier les pins que nous avons sélectionner pour l'horloge. l'impression d'un autre PCB de test avec les corrections nous prendra beaucoup de temps. Étant plus familiarisé avec l'architecture AVR, nous avons laissé de coté le STM32L et décidé de travailler avec l'atmega328p pour un premier prototype. Nous avons donc commencé à réaliser le PCB finale du microcontrôleur avec la mémoire flash et le module bluetooth.

Les erreurs commise avec le STM32L nous ont permises de mieux réaliser ce pcb, en prenant bien compte des entrées/sorties, puis de libérer des sorties pour mettre le bootloader en SPI, et de pouvoir programmer l'atmega38p, et le BM20 et série. Durant cette séance nous avons également codé le programme permettant d'utiliser la mémoire flash, nous avons tester avec une mémoire que M.Redon nous avait donnée.

Bilan : il reste à finaliser le PCB et combiner le code de la mémoire flash et de la bibliothèque wav.

Semaine 13

Séance 22

Durant cette séance nous avons d'une part travailler sur la conception du schematic sur Arduino pour notre carte finale. D'autre part, nous avons travaillé sur la communication SPI entre l'atmega 328p et la mémoire flash. Pour la communication SPI, il est normalement nécessaire d'utiliser la datasheet pour respecter les temps de transfert des communications. Pour s'affranchir de ces contraintes nous utilisons donc la bibliothèque SPIFlash qui permet à la base de communiquer avec des mémoire flash du constructeur Winbond mais, fort de son succès, cette bibliothèque a été très développé et peut ainsi permettre de gérer de nombreuses cartes et disposent de plusieurs de haut niveau qui permet de ne pas gérer les durées des échanges du protocole SPI. Il est nécessaire de faire de légère modifications dans un code d’analyse afin que ce programme nous renvoie les informations basiques à propos de la mémoire flash. Plusieurs fichiers "exemples" sont proposés, notamment un fichier qui permet de caractériser la mémoire flash. Durant les vacances précédentes nous avions déjà essayé de communiquer mais le test ne fonctionnait pas du tout. Il y avait deux explications possibles :

la première est que nous utilisons pour chaque un diviseur de tension qui pourrait poser des problèmes car ce n'est pas vraiment prévu pour l'échange de donnée mais simplement pour l'abaissement de tension d’alimentation.

En effet, la mémoire flash demande du 4 V ou moins lorsqu'elle est alimenté comme nous en 3.6 V, nous devons baisser la tension et comme nous ne disposons pas de diode ou alors directement de carte permettant ce changement, nous utilisons des ponts diviseurs de tension.

la deuxième est que nous n'ayons pas respecté les branchements.

En effet, les branchements ne sont pas bon. Le pin #HOLD (not HOLD) n'avait pas été branché car nous l'avions jugé inutile alors que c'est tout le contraire. En effet si il est low lorsque #CS est low alors tous les messages envoyés sont ignorés, c'est pourquoi nous n'obtenons aucun résultat.

Notre mémoire flash de test est une CMS et nous avions donc branché des fils dessus pour les tests, évidemment ces fils ont fini par céder. Avec l'assistance de M. Redon nous avons soudé une nouvelle mémoire flash de manière non orthodoxe. Cette fois #HOLD est toujours connecté à l'alimentation et lorsqu'on lance le fichier de test on obtient enfin des résultats. Par la suite nous avons également testé si nous arrivions à écrire sur la mémoire et lire ce que nous écrivons et cela fonctionne également. Il nous reste tout de même à écrire le code de l'atmega qui regroupe la lecture du WAV et récupérer la musique stocké dans la mémoire flash. Le problème est que la musique est trop grosse pour tenir entièrement dans la mémoire de l'arduino et d'un autre côté le wav lit la musique dans un tableau statique, nous devons donc écrire notre code en conséquence.

Semaine 14

Séance 23

Durant cette dernière séance officielle nous nous sommes chargé de concevoir le schéma et le PCB final de notre projet. Nous y intégrerons donc une mémoire, une atmega 328p et un module Bluetooth. Nous ajoutons sur le PCB plusieurs interrupteurs qui permettent de changer de mode de fonctionnement, allumer le système ou encore changer le mode de test en mode appairage pour le BM20. Il y a également des headers qui seront utilisés afin de d'utiliser le bootloader pour l'atemga 328p ce qui nécessaire qu'une fois mais qui est obligatoire.

D'autres modules sont ajoutés tel que le quartz pour le fonctionnement de l'horloge de l'atmega 328p ou le bouton permettant d'activer l'appareillage de notre casque ou non. Il y a de nombreux impératif sur cette carte, en effet pour le module Bluetooth notamment aucune connexion ne peut passer sous le composant ce qui nous oblige à utiliser des headers que nous connecterons de l'autre côté de la plaque avec des fils. Nous avons un problème similaire pour la connexion SPI entre la mémoire flash et l'atmega. En plus de cette connexion les fils doivent être connectés à un header afin de faire le bootload. Les câbles se croisent beaucoup trop pour pouvoir réaliser le câblage sur une même face, nous avons donc ajouté des headers que nous connecterons également avec des fils sur la même face cette fois.

Il faut également respecter la zone d'antenne du BM20 et donc ne pas mettre de composant à la même hauteur que la partie hors PCB du module Bluetooth. Cela engendre un agrandissement de la carte. La carte est au final un carré de 6cm x 6cm à peut près ce qui n'est pas négligeable et il nous faut donc modifier la coque imprimé en 3D en conséquence.

Nous remarquons aussi qu'il y a un problème au niveau du branchement du quartz, en effet, le PCB indique des branchements qui sont différents de ce que nous avons fait dans notre schematic. Nous décidons de ne pas respecter ce qu'il nous indique mais de rester sur nos branchement même si nous devrons vérifier notre schéma.

Remarque : sur la photographie ci-contre, certains éléments sont indiqué en vert (donc des problèmes) car les règles imposaient à notre PCB sont celles indiqués dans le didacticiel à propos d'Altium. L'atmega 328p ayant des pins plus proches que ce qu'imposent nos règles, le logiciel nous indiques ces pins comme des erreurs mais il n'en est rien.