HOMeR. 2ème année PROJET. N du projet : 8056. Date : 07/06/2007. Rapport intermédiaire : Promo : 2008. Rapport final : Laurent CABARET

PROJET N du projet : 8056 2ème année Date : 07/06/2007 Rapport intermédiaire : Rapport final : Promo : 2008 HOMeR Élèves participant au projet : Arnaud BONNET Denis CHARMET Jean-Sébastin LELEU Aymeric LE-RENARD Dominique OSWALD Nicolas VERDONCK Enseignant responsable : Laurent CABARET 1/101

Sommaire Résumé...4 Présentation du projet...5 Les enjeux du projet...5 Objectifs du projet...6 Les moyens mis à notre disposition...8 Gestion du projet...10 Les difficultés rencontrées...13 Suivi du projet...13 Le routeur Wi-Fi et l'openwrt...14 Aspects généraux...14 La sécurité...15 Les radios Web et le streaming...16 Les routeurs...17 Installation d'openwrt...20 Interfaçage de la borne et du microcontrôleur...22 Conclusions personnelles...23 Le microcontrôleur et ses différents modules...24 Présentation générale...24 Interface utilisateur...25 L affichage...26 Le Tuner FM...28 Interface Borne-Microcontrôleur...29 Conclusions personnelles...32 Modélisation Boitier...34 Pourquoi réaliser un boitier sous Catia...34 Fabrication des diverses pièces...35 2/101

Dessin du boitier...35 Amélioration du boitier...37 Finalisation...38 Conclusions personnelles...40 Système audio...41 Circuit d alimentation...42 Présentation et objectifs...42 Etude préliminaire...42 Réalisation...43 Conclusion...45 Fin et avenir du projet...45 Bilan...45 Remerciements...46 Annexes...47 Manuel OpenWrT...47 Rapport ME système alimentation...64 Rapport ME Tuner...74 Utilisation des ports du microcontrôleur dans le projet...90 Les programmes du microcontrôleur...90 3/101

I. Résumé Français Le projet HOMeR (Home Opensource Media Receiver), né à l'initiative de p2007, a pour objectif l'élaboration d'un récepteur WiFi portatif de web radios permettant également d'écouter des radios FM. Cet objet devant être autonome : alimentation par batterie, amplificateur audio et haut-parleurs intégrés, il répond au critère de système embarqué. La solution technique adopté pour la base du système est d'installer une distribution Linux pour systèmes embarqués «OpenWRT» sur un routeur WiFi grand public disposant d'un port USB pour y brancher différents périphériques USB. Les compétences engagées par ce projet sont réparties sur deux principaux domaines : informatique (système linux embarqué, réseau WiFi, lecture de flux audio réseau) et électronique (manipulation d'un microcontrôleur, système alimentation... ). Cette année, nous avons en plus réalisé une coque avec le logiciel «CATIA» et reçu le soutien d'un gestionnaire de projet afin de mieux gérer le temps de travail. Le temps imparti cette année nous a permis d'aboutir à un produit fini qu'il sera possible d'améliorer dans le futur du projet. Anglais/English The HOMeR (Home Opensource Media Receiver) project aims at the development of a WiFi portable receiver of Web radios also allowing to listen to FM radios. It is an embedded system : integrated battery, audio amplifier and loudspeakers. The competences engaged by this project are distributed on two fields: data processing (linux embedded system, WiFi network, audio network streaming) and electronics (microcontrolor, audio amplifier ). The solution adopted is to install a Linux distribution for embedded systems «OpenWRT» on a WiFi router with USB ports to connect there an USB hub device. This year, we managed to built a box with «CATIA». We also were helped by a management student, who provided us with the necessary project management tools we needed. We managed to create a finished product, which can be the start of another project. 4/101

II.Présentation du projet Les enjeux du projet Les web radios La motivation principale de ce projet repose sur la volonté de rendre plus accessibles les web radios. On entend par radio les flux de musique ou d'émissions disponibles en écoute sur Internet, elles comportent plusieurs avantages : Diffuser une web radio nécessite peu de moyens financiers et de connaissances techniques. - - Elles peuvent être écoutées dans le monde entier. Ces avantages permettent à beaucoup d'amateurs d'héberger leurs propres radios. De cela découlent des caractéristiques intéressantes : - La plupart des web radios sont exemptes de publicités. - Grande diversité musicale et culturelle. Contrairement aux radios FM il est beaucoup plus facile d'"émettre" sa radio web, en revanche son écoute est encore limitée sur plusieurs aspects : - Le nombre important de web radios peut dérouter certains internautes. - Nécessité d'avoir une connexion internet en général haut débit. - L'écoute ne se fait qu'à partir d'un ordinateur. L'objectif principal du projet est de répondre à ce dernier inconvénient en proposant un objet moins cher et moins encombrant qu'un ordinateur conçu pour l'écoute des web radios. RadioPi Le campus de l École Centrale dispose de sa propre web radio associative "RadioPi" ( www.radiopi.org ). Dans ses statuts il s'agit un club rattaché à l'association loi 1901 étudiante centralienne "VIA Centrale Réseaux" dont le but principal est de fournir un accès réseau au campus de l'école, notamment, depuis mai 2005, un réseau Wifi couvrant toute la résidence. Concrètement RadioPi diffuse des 5/101

émissions en direct animées par des élèves dans le studio situé sur le campus et propose une liste de canaux thématiques lorsqu'il n'y a pas d'émissions. L'initiative de ce projet a donc été influencée par les opportunités qu'un tel objet pouvait offrir à RadioPi, cinq des six membres du projet étant membres actifs de RadioPi. Nous avons recensé trois utilisations possibles d'un tel objet en relation directe avec RadioPi : - Permettre d'écouter RadioPi dans le foyer des élèves (la "nébuleuse"). L'utiliser comme un outil de communication pour RadioPi lors d'évènements de présentation (semaine d'intégration des premières années, forum des clubs et associations...) - - Ecouter RadioPi dans les salons d'étages de la résidence. Objectifs du projet Commandités par RadioPi, nous avons la tâche de fournir un appareil de lecture nomade de radios web, fonctionnant donc sur batteries à un coût strictement inférieur à celui des solutions du marché (environ 300 euros), dont l utilisation est en plus compromise sur le campus à cause du serveur Radius utilisé. Notre objectif en terme de délai est de fournir le produit début Juin, le produit ayant une faible contrainte de taille car c est du nomadisme exceptionnel (déplacement d une salle à une autre). Nous avons bien sûr en parallèle des objectifs pédagogiques (maîtrise des concepts mis en œuvre) ainsi que des objectifs de gestion et de pilotage de projet. Pour plus de détails, voir ci-dessous et le contrat pédagogique. Dans ces différents buts, voici les objectifs et les livrables de notre projet : Concernant l objectif produit final fonctionnant sous réseau Radius: Fin décembre : configuration boutons et écran, Borne fonctionnant sur un réseau wifi libre ; Fin Mars : Borne avec boutons, écran, batterie et tuner FM fonctionnant sur un réseau wifi libre et sur un réseau wifi privé ; Fin Mai, Début Juin, rajout de l interface utilisateur intuitive, des enceintes et assemblage d un produit fini (avec coque). 6/101

Concernant l objectif Pédagogique : 20 décembre : remise du contrat pédagogique, du rapport intermédiaire et de la demande de financement ; 07/06 : deux rapports ME et le rapport final ; 12/ 06 : soutenance ; Concernant les deux : 29/10 : remise de la présentation du projet pour le site Web du LEE ; Mars : Poster de présentation pour les journées Federez et le LEE. Bilan par rapport à nos objectifs: Concernant l objectif produit final fonctionnant sous réseau radius : Notre objectif principal a été atteint, comme nous vous le montrons dans ce présent rapport et lors de la démonstration, notre produit permet aujourd hui la lecture de web radios de façon nomade. Nous montrerons dans notre rapport les difficultés rencontrées et les actions que nous avons menées pour y répondre. Dans un souci de perfectionnement, nous regrettons simplement de ne pas avoir réussi parfaitement le lien entre la borne et le microcontrôleur, ainsi que le fait que notre design de coque ait été revu à la baisse pour cause de budget. Concernant l objectif Pédagogique : Tous les livrables ont été rendus et validés. Nous témoignons par ailleurs de l apport indéniable de ce projet. Cet apport a été perçu tant en terme de connaissances techniques qu en terme d expérience de projet en groupe. 7/101

Les moyens mis à notre disposition Le Laboratoire d' Informatique et des Systèmes Avancés Nous avions à notre disposition une salle et les équipements du Laboratoire d'informatique et des Systèmes Avancés (LISA) de l'école. De plus un aménagement prévu pour certains projets de deuxième année nous a permis de réaliser le module "Méthodologie Expérimentale" (ME) dans le cadre de notre projet qui correspondait à vingt heures supplémentaires pour le projet de deuxième année consacrées aux manipulations électroniques. Dans le cadre des manipulations, l'encadrement de M. Cabaret fut une aide précieuse. Budget Voici notre budget initial : Budget Prévisionnel HoMER Dépenses Recettes Routeur Asus 90,00 Subvention DE 450,00 Clé USB 30,00 Subvention VIA 130,00 Ecran LCD 40,00 Système Amplification 30,00 Total 580,00 Boitier 80,00 Boutons 40,00 Batterie 80,00 Haut-parleurs 30,00 Kit-Tuner 80,00 Fonds de sûreté 80,00 Total 580,00 8/101

Et voici notre budget final : Budget HoMER Dépenses Recettes Routeur Asus 96,00 Subvention DE 450,00 Routeur Netgear 68,80 Subvention VIA 2005 60,00 Clé USB Asus 19,95 Subvention VIA 2006 130,00 Clé USB Netgear 20,65 Boutons 6,59 Kit devel 84,15 Ecran LCD 6,63 Diodes 9,69 Résistances 10,17 Max 712 11,16 Convertisseur 12V 42,70 Alimentation 49,90 Composants electriques 16,61 Total 640,00 Câble Coaxial 25,96 Coque 300,00 Total 768,96 La différence de 128.96 correspond à une sous évaluation du prix de la coque, cette somme a été aimablement complétée par le LEE. 9/101

Gestion du projet En collaboration avec un élève du MS Technologie et Management, nous avons décidé de séparer les rôles de direction et de gestion du projet. La gestion de projet se concentrant sur l application de méthodes de gestion de projet et sur le pilotage de projet. Nous avons décidé de consacrer du temps à la préparation du projet partant du constat qu en Entreprise, 70 % des projets échouent à cause d'une mauvaise préparation ou une mauvaise définition des rôles et des objectifs. Première étape, analyse fonctionnelle: Notre première étape fut de définir notre cahier des charges. Pour cela nous avons utilisé la méthode de l analyse fonctionnelle dont voici le résultat : F1.1 : l appareil doit se connecter à des réseaux wifi (libres ou privés) F1.2 : l appareil doit lire des radios web par ces réseaux wifi. F1.3 : l appareil doit produire du son. F2.1 : l appareil doit être nomade (batterie, enceintes) F2.2 : l appareil doit satisfaire les critères de notre commanditaire : RadioPi (délai, qualité, coût) F3.1 : l appareil doit avoir une interface utilisateur compréhensible F3.2 : l appareil doit avoir une liste préenregistrée de radios-web F4.1 : l appareil doit se connecter facilement à un ordinateur F4.2 : la liste des radios-web et les réseaux privés doivent être facilement paramétrables à partir de l ordinateur F5.1 : l appareil doit se connecter à internet via un ordinateur connecté à internet (réseau câblé) F6.1 : l appareil doit satisfaire les contraintes légales et environnementales * 10/101

De ces différentes fonctions, nous en avons déduit les spécifications dimensionnantes du produit : Borne wifi avec écran LCD, enceintes, batteries et boutons. Utilisation et paramétrage du firmware open-source gratuit OpenWRT pour satisfaire les contraintes de coût (<300 ). Taille transportable. Deuxième étape, analyse des risques: Voici les principaux risques qui ont été détectés en phase préliminaire de notre projet. Probabil Risque ité carte réseau qui flanche 3 Imp Répon Tot act se al 9 1 27 27 risque humain temporaire 9 6 5 0 20 risque humain global 2 10 10 0 64 risque fournisseurs compréhension d'interface 8 du 10 8 0 Système 16 7 6 4 8 36 souci de délai 10 6 6 0 18 microcontrôleur Wi-max (pas vraiment un risque mais suivre pour l'année prochaine) 2 9 10 2 3 2 0 12 10 chaleur 10 10 1 0 11/101

Concernant ces risques, se reporter au contrat pédagogique pour voir notre plan d action. Ce fichier a été travaillé durant l année, des risques étant ou rajoutés ou résolus. Troisième étape, découpage du projet en micro-tâche: Voici les différentes macro-tâches détectées : 1) Interfaçage entre les différents composants, le microcontrôleur et la borne Wifi La programmation de l OpenWRT 2) Choix et implémentation d une batterie 3) Conception de l interface utilisateur 4) Conception de la coque Assemblage du produit final. 5) Communication autour du projet 6) Report à l administration et capitalisation autour du projet. Quatrième étape, définition des rôles: Une fois les macros-tâches définies, nous avons décidé de donner le rôle de chef de projet à Arnaud Bonnet et celui de gestionnaire de projet à Jean-Sébastien Leleu. Nous avons ensuite décidé de manière collégiale la répartition des différentes tâches : L interfaçage entre les différents composant, le microcontrôleur et la borne wifi est assuré par Dominique Oswald, Nicolas Verdonck, Aymeric Le Renard et Denis Charmet. La Programmation de l OpenWRT est assurée par Arnaud Bonnet et Denis Charmet Le choix et l implémentation d une batterie est assurée par Arnaud Bonnet, Denis Charmet et Aymeric Le-Renard La conception de la coque et du système audio a été confiée à Aymeric Le-Renard. 12/101

La communication autour du projet est assurée par Jean-Sébastien Leleu. Le report à l administration et la capitalisation autour du projet est assurée par Arnaud Bonnet et Jean-Sébastien Leleu (avec une remontée des informations de tous les membres). Bien sûr, cette répartition est évolutive en fonction du travail et des volontés de chacun. Cinquième étape, définition du planning détaillé. Les difficultés rencontrées Nous avons dû d abord nous familiariser avec ces méthodes que nous ne connaissions pas. Cette difficulté a été surmontée par des présentations de JeanSébastien qui avait déjà été formé à ces méthodes. L autre difficulté consistait à la mise en place du planning et des micros tâches. En effet, premièrement, nous avons dû nous former à l utilisation de MS Project, difficulté surmontée à la fois par une formation suivie par Jean-Sébastien, par l utilisation du logiciel et l aide de communautés du Web. La définition des micros tâches a été laborieuse au départ et nous avons surmonté cette difficulté en ne fixant le planning initial qu une fois le projet commencé, permettant ainsi d ajuster la liste des tâches chaque semaine en fonction du travail accompli et qui donnait une vue plus précise du travail restant à accomplir. Suivi du projet Le suivi de projet a été réalisé conjointement par Arnaud Bonnet et Jean-Sébastien Leleu, soit par des points hebdomadaires avec les différentes équipes ou bien par un contact mail. Dans tous les cas, il y a eu un suivi hebdomadaire permettant de fixer les priorités en cas de dérapage des délais. 13/101

III.Le routeur Wi-Fi et l'openwrt Aspects généraux HOMeR se veut un produit nomade capable de capter facilement les radios Web, c'est donc tout naturellement que nos prédécesseurs se sont tournés vers les réseaux WiFi qui permettent de s'affranchir des câbles réseaux. Le WiFi (pour Wireless Fidelity), nom originellement donné à la certification de compatibilité à la norme de la WiFi Alliance, désigne désormais par extension une technologie réseau sans fil devenue un moyen très répandu d'accès haut débit à Internet. Il est basé sur la norme IEE 802.11 (ISO/CEI 8802-11). Ainsi un réseau dit WiFi est en fait un réseau conforme à cette norme et dont les équipement certifiés WiFi portent le logo : La norme IEE 802.11 est en fait la première norme qui offre des débits de l'ordre de 1 ou 2 Mbit/s. Elle a donc connu plusieurs révisions pour afin d'augmenter son débit et sa portée. On appelle ces nouvelles normes : normes 802.11 physiques : Norme Fréquence IEE 802.11a 5 GHz IEE 802.11b IEE 802.11g Débit théorique Débit réel Portée 54 Mbit/s 30 Mbit/s 10 m 2,4 GHz 11 Mbit/s 6 Mbit/s 100 m 2,4 GHz 54 Mbit/s 26 Mbit/s 100 m Ces réseaux étant simples à installer, ils se sont très vite mis à fleurir un peu 14/101

partout. Toutefois le débit allant décroissant avec la distance, une nouvelle norme a été créée : la norme WiMax qui permet d'étendre un réseau sans fil haut débit jusqu'à une distance de 10 km pour la norme physique dite fixe et 3,6 km pour celle dite mobile avec des débit théoriques respectifs de 75 Mbit/s et 30 Mbit/s. La sécurité Les réseaux wifi offrent une très grande liberté en s'affranchissant d'un support physique, mais c'est au détriment de la sécurité. En effet n'importe qui doté d'une carte wifi peut théoriquement accéder au réseau et même aux informations qui ne lui sont pas destinée. Pour cela, la WiFi Alliance a dû trouver un certain nombre de parades. La première et encore la plus déployée est celle du chiffrement des communications par clé WEP (Wire Equivalent Privacy) mais il a été prouvé que ce chiffrement pouvait être très facilement cassé. L'alliance a donc lancé le WPA (Wifi Protected Access) dont la grande force par rapport au WEP repose dans le TKIP (Temporal Key Integrity Protocol) qui change les clés de façon dynamique. C'est justement ce point critique qui nous a bloqué un long moment. En effet, si le WEP est trivial à utiliser dans la configuration de base de Linux et donc d'openwrt, le WPA est géré par le paquet wpa_supplicant et les pilotes de la carte réseau. Nous avons donc dû attendre la release de pilotes compatibles avec le WPA, heureusement la volonté d'harmonisation des pilotes a permis l'élaboration du pilote Wext qui nous a enfin offert, récemment, la chance d'accéder au réseau wifi WPA du CTI : ECPCTI. Mais nous y reviendrons plus tard. 15/101

Les radios Web et le streaming Les radios Web sont analogues aux radios hertzienne à cela prêt qu'elle diffusent sur Internet grâce à technologie du streaming qui permet, après avoir chargé une partie suffisante du flux (bufferisation) de commencer la lecture avant le téléchargement complet. Très nombreuses et variées, ces radios ne sont pas soumises aux quotas du CSA et très facile à mettre en place grâce à des logiciels comme Icecast ou SHOUTcast. En France, elles n'ont qu'une seule restriction : celle de payer des droit à la SACEM. Il existe plusieurs modèles de diffusion : Le modèle client-serveur où chaque machine cliente se connecte au serveur de streaming pour obtenir un flux ce qui risque de saturer très vite la bande passante du serveur. C'est le modèle le plus répandu. Le peercast est un système très semblable au peer-to-peer qui se sert des auditeurs pour retransmettre. Le multicast qui minimise l'envoi de flux par le serveur, ce sont les équipement réseaux qui se chargent de dupliquer le flux pour le distribuer aux auditeurs. Il est également possible de jouer sur les formats d'émission comme le MP3, le WMA ou encore l'ogg Vorbis qui est un format libre et performant proche de MP3. RadioPi pour sa part utilise un système d'émission en streaming inspiré d'icecast mais qui a été adapté pour gérer plusieurs canaux d'émission multicast et emploie le format Ogg Vorbis. 16/101

Les routeurs Reprenant un projet déjà existant, nous avons essayé de conserver au maximum le travail de nos prédécesseurs concernant leurs choix technologiques et logiciels. Nous sommes donc restés sous OpenWRT. Un système d'exploitation Open Source développé pour une architecture Broadcom basé sur Linux et qui possède toute une structure de gestion de paquet proche de Debian avec la commande ipkg. Toutefois, nous n'avons pas pu tout conserver. Nous sommes reparti du routeur Asus WL 500G Deluxe qu'utilisaient nos prédécesseurs : Processeur Broadcom 5365 à 200 MHz Mémoire Flash 4 Mo RAM 32 Mo Ports Série 2 ajoutables électroniquement Ports USB 2 à l'arrière (USBv2.0) Réseau 4 LAN 1 WAN à l'arrière Chipset wifi Broadcom intégré Ce modèle est très stable et solide, nous avions, en outre, l'avantage de posséder pour lui un manuel OpenWRT et de dead units que nous avons employé à maintes reprises pour restaurer le système de la borne. Dans le même temps nous avons décidé d'acheter un routeur équivalent ou meilleur. 17/101

Le choix s'est donc naturellement, après avoir cependant consulté la table de matériel d'openwrt, porté vers le modèle supérieur au premier routeur : le modèle Asus WL 500G Premium : Processeur Broadcom 4704 à 266 MHz Mémoire Flash 8 Mo RAM 32 Mo Ports Série 2 ajoutables électroniquement Ports USB 2 à l'arrière (USBv2.0) Réseau 4 LAN 1 WAN à l'arrière Chipset wifi Broadcom 4318 Il y avait hélas un problème majeur que ne dénotait alors pas le wiki d'openwrt, les boutons sensés le faire passer en mode revival, mode de fonctionnement minimal dans lequel on peut le reflasher par tftp, sont mal mappés ce qui explique qu'une fois le flashage avec OpenWRT est terminé, il n'est plus facilement reflashable. On s'est alors vu obligé d'utiliser une méthode de court-circuit. En effet, lorsque le système détecte une erreur, il passe en mode revival. C'est une opération très invasive et à utiliser à modération car le système n'est pas conçu pour la supporter. Nous l'avons appris à nos dépends car le modèle Premium n'a pas supporté le septième flashage de ce type. Il reste donc bloqué dans une activité de switch, il reste cependant une possibilité de le restaurer par le biais d'une console série. Nous en avons profité pour changer de type de routeur et surtout de chipset wifi car broadcom n'a toujours pas releasé de pilotes pour ses chipsets WiFi pour les noyaux 2.6 et OpenWRT doit se baser sur les travaux de développeurs indépendants. Le 18/101

problème c'est que les pilotes libres intègrent très mal le WPA ce qui rendait la borne inutile sur tous les réseaux vraiment sécurisés. Le choix s'est donc porté sur le routeur Netgear WGT 634u Processeur Broadcom 5365P à 200 MHz Mémoire Flash 8 Mo RAM 32 Mo Ports Série 1 ajoutable électroniquement Ports USB 1 à l'arrière (USBv2.0) Réseau 4 LAN 1 WAN à l'arrière Chipset wifi Atheros Ce routeur présente l'avantage non négligeable d'utiliser un chipset WiFi Atheros, géré par les pilotes madwifi intégrés dans la distribution Kamikaze d'openwrt. Il est donc resté notre routeur principal depuis son achat en mars. On notera que ce routeur a toutefois des inconvénients. Il n'a qu'un seul port USB alors qu'il nous en fallait au moins deux pour la carte son et la clef USB pour le système. Nous avons pallié ce problème par l'achat d'un hub USB mais c'est au détriment de la qualité de la liaison. Il y a donc un temps de propagation incompressible entre la commande et l'action réelles. Le deuxième problème vient de la méthode de flashage, en effet une fois OpenWRT installée, on doit impérativement passer par une console série pour reflasher. Cela dit la console série permet aisément de connaître l'état du système, ce qui fait qu'avec cette borne nous n'avons jamais eu de vrais cas de dead units. 19/101

Installation d'openwrt Comme nous l'avons dit précédemment, nous avons décidé de conserver au maximum les choix techniques de nos prédécesseurs. Cependant, il s'est très vite avéré que les paquets qu'ils avaient utilisés n'étaient plus disponibles. Nous n'avions donc plus de pilotes de sons. Nous avons décidé d'utiliser un noyau 2.6 qui intègre dans ses modules l'architecture son ALSA (Advanced Linux Sound Architecture). Ce noyau n'étant pas disponible dans la version stable White-Russian, nous avons décidé d'utiliser la version de développement qui est certes moins stable mais qui permet d'avoir les paquets les plus récents, un noyau 2.6 et qui permet aussi de packager des applications externes grâce à l'usage de Makefile. Kamikaze diffère par de nombreux point de White-Russian : Tout d'abord elle n'est pas, à l'heure où j'écris ces lignes, releasée, il faut la configurer puis la compiler. Sa sortie officielle ne devrait pas tarder. Il n'y a pas de dépôts de paquets, il faut donc tout compiler nous même quitte à ajouter les sources et les makefile à la main. Les paquets ne fonctionnent pas tous, il faut parfois patcher (ce ne fut heureusement pas le cas pour nous). Quelques commandes ont été remplacées notamment celles orientées réseau, la nvram a été supprimée au profit de fichiers de configuration. Le manuel OpenWRT de l'année dernière n'est donc plus vraiment adapté à notre nouveau système. On va donc redétailler l'installation et la configuration d'openwrt Kamikaze dans le cas de notre routeur principal : le Netgear WGT 634U pour lequel la procédure est la plus compliquée. 20/101

On notera que désormais, il faudra une machine sous Linux pour compiler les sources et flasher correctement Un manuel est détaillé de toutes les actions à effectuer est donné en annexe. Flashage : - On récupère les sources de Kamikaze et des paquets par le dépôt subversion du projet. - On ajoute les paquets voulus (mpd, mpc) aux sources du système. - On met à jour les dépôts. - On configure le noyau à utiliser. - On compile les sources pour obtenir le fichier binaire de l'image à flasher. - On configure un serveur tftp sous Linux, (Windows intègre déjà un tel serveur). - On construit une carte électronique permettant d'ajouter un port série à la borne. - On se connecte par port série sur la borne en utilisant minicom pour Linux. - On flashe par tftp en utilisant la console série pour configurer la connexion et gérer le téléchargement Configuration du système : - On se connecte en telnet sur la borne - On configure le mot de passe - On se reconnecte en SSH. - On met le système sur clé. - On installe les paquets wifi, son, php et http. - On s'assure que les modules de la carte son se lancent bien à chaque démarrage. - On configure le serveur de son mpd. - On crée des scripts d'initialisations qui lanceront automatiquement la connexion au réseau et lanceront tous les services souhaités. 21/101

Interfaçage de la borne et du microcontrôleur La liaison Initialement, on prévoyait d'interfacer la borne et le microcontrôleur par le biais du port série ajouté à la borne. Il s'est avéré qu'il servait avant tout d'interface de debug que l'on a préféré conserver afin de diagnostiquer les éventuels problèmes et d'avoir un accès non dépendant du réseau sur la borne. Nous avons décidé d'utiliser le hub et un convertisseur USB-série pl-2302 afin de connecter les deux. Il y a cependant, manifestement, une défaillance du pilote car le buffer ne semble pas se vider après écriture et l'on doit le vider «manuellement» pour pouvoir communiquer avec le microcontrôleur. Le programme Nous avions envisagé de coder le programme de gestion des boutons et des radios par la borne en C, qui est un langage puissant et rapide, mais le problème de la crosscompilation pour l'architecture mispel s'est très vite posé. Nous ne voulions pas installer un gcc, un g++ et l'ensemble des librairies dont nous avions besoin sur la clé. Et nous n'avons pas pu trouver le moyen de cross-compiler en utilisant la toolchain d'openwrt. Nous avons donc opté pour le PHP qui est un langage de script puissant et très facile d'accès et qui nous a permis de réaliser très rapidement des scripts de plus en plus fonctionnels pour arriver au résultat actuel. Nous avons décidé de laisser la borner gérer complètement les radios, en d'autres termes : - On charge la playliste dans un tableau - On configure le port série - On conserve l'indice de navigation dans un buffer - La borne attend que le microcontrôleur envoie un chiffre correspondant aux 22/101

commandes «haut», «bas» ou «sélectionner» - La borne envoie dans une ligne formatée les radios à afficher sur l'écran et modifie l'indice de navigation en conséquence. - Si la borne reçoit l'information «sélectionner», on lance la radio correspondant à l'indice de navigation - On repasse en mode attente suivant une boucle infinie. La méthode utilisée pour vider le buffer du port série consiste à lire le fichier après avoir écrit dedans. Une solution plus propre consisterait à laisser le microcontrôleur gérer la liste des radios en les téléchargeant par fenêtres ce qui limiterait considérablement les communications entre le microcontrôleur et la borne car cette liaison série est vraiment l'un des gros points faibles du projet dans son état actuel. Nous n'avons hélas pas eu le temps de nous pencher plus sur la question. Conclusions personnelles Ce projet est l'un des points les plus importants de ma deuxième année, car il m'a permis de vraiment mettre mes connaissances en application et de chercher par moimême les informations qui me manquaient, il m'a permis de devenir plus autonome, de voir que notre savoir pouvait servir à autre chose que résoudre des exercices. Il est vraiment gratifiant de réussir à concevoir et réaliser à partir de pas grand chose un produit qui fonctionne. Tout au long de l'année, le travail en équipe a vraiment pris une grande importance car on ne peut pas réussir seul un projet de cette envergure. Je tiens à remercier notamment notre encadrant M. Cabaret pour son aide tout au long du projet, M. Nicolas Boullis pour ses précieuses informations sur le réseau du CTI et Alexandre Coninx pour ses précieuses connaissances sur le WiFi en général et celui de VIA en particulier. 23/101

IV.Le microcontrôleur et ses différents modules Présentation générale Un microcontrôleur est un circuit intégré rassemblant un microprocesseur et d'autres composants tels que de la mémoire et des périphériques. Le microcontrôleur utilisé dans le projet est celui qui fut choisi par l'équipe de l'an dernier : il s'agit d'un microcontrôleur standard de chez Philips, le P89LPC935, qui reprend une architecture très répandue, celle du 8051. Sa place est, comme l'année dernière, centrale dans le projet : il sert à faire l'interface entre l'utilisateur et la partie émettrice de son, c'est-à-dire entre les boutons de commande, l'écran LCD, le tuner FM et le routeur WiFi. Vue schématique des flux de données autour du microcontrôleur Nous avons utilisé ce microcontrôleur avec un kit de développement de Keil, le MCB900, qui se présente sous la forme d'une plaque avec le microcontrôleur, fournie avec l'environnement de développement «µvision 3» et le logiciel de flashage «Flash Magic». Ce kit de développement possède certaines fonctionnalités intéressantes pour la première approche d'un microcontrôleur et pour le debogage de programmes, sans pour autant limiter en quoi que ce soit ses possibilités. 24/101

En particulier, d'un point de vue matériel, le kit de développement a un port série déjà monté (utilisé bien sûr pour le flashage, mais aussi plus tard pour la communication avec la borne WiFi), et 8 LEDs branchées sur le port 2. D'un point de vue logiciel, la programmation du microcontrôleur se fait en C avec µvision. Si la prise en main est assez facile grâce aux divers programmes fournis avec le logiciel, une programmation complexe est possible et même indispensable pour réaliser toutes les fonctions voulues pour le projet HOMeR. Chaque nouvelle fonctionnalité maîtrisée en terme de programmation rend possible ou facilite la réalisation de fonctions pour le poste de radio final. Au cours de l'année, le microcontrôleur a donc été progressivement programmé pour prendre de mieux en mieux en charge son environnement direct, en utilisant par exemple le timer et les interruptions. Interface utilisateur Le rôle principal du microcontrôleur est de permettre une interface entre l utilisateur et la radio. L utilisateur doit pouvoir faire défiler les noms des radios et en sélectionner une. Pour cela on place 3 boutons poussoir agissant sur 3 ports du microcontrôleur, l utilisateur doit aussi pouvoir visionner le défilement des radios, pour cela on utilise un afficheur LCD piloté par le microcontrôleur. L écran choisi peut afficher deux lignes de 16 caractères. Ainsi on peut monter et descendre à l aide des boutons dans la liste des radios, l afficheur montrant à quelle radio on se trouve ainsi que la suivante. Grâce au dernier bouton, on sélectionne la radio pour que la borne la diffuse. Les boutons On a intégré au système trois boutons : un bouton «up» pour remonter dans le défilement des radios, un bouton «down» pour descendre dans le défilement des 25/101

radios et enfin un bouton «select» permettant de faire diffuser par la borne la radio en cours d affichage. Si on appuie sur un bouton, la sortie est reliée à Vcc, ce qui correspond à un 1. Dans le cas contraire, la sortie est reliée par une résistance à la masse, il y a donc un 0 en sortie. La résistance choisie doit être suffisamment importante pour limiter les pertes d énergie (quand le bouton est appuyé) tout en ne correspondant pas à un état haut impédance. On a choisi R = 10kΩ Les 3 sorties de ce montage sont relié aux ports p0.0, p0.1, p0.2 du microcontrôleur, ces ports pouvant être à l état «input only». La programmation des boutons est assez simple : Programmation des boutons : P0M1 = 0x03 ; P0M2 = 0; Ces deux lignes permettent de paramétrer les entrées p0.0, p0.1, p0.2 en input only If (P0 & 01) { Ce qu il faut faire en cas d appui du bouton L affichage Pour afficher, on utilise un écran LCD. Il comporte 8 bits de données et 3 bits de commandes. Les 8 bits de données sont reliées au port 2 du microcontrôleur qui est le seul port dont tous les fils peuvent marcher en sortie. Les 3 bits de commandes sont les fils p0.4, p0.5, p0.6. 26/101

- p0.4 correspond à R/W (read and write). Pour écrire sur l afficheur, il faut mettre R/W à 1. - p0.5 correspond à RS. Mis à 1, l écran attend une instruction, à 0, l écran attend un caractère en ASCII. - p0.6 correspond à E (enable), mis à 1, l écran lit les informations données sur les autres ports. Il doit être remis à 0 pour changer ces informations. L écran ayant une vitesse de traitement plus faible que le microcontrôleur, il faut faire une temporisation entre chaque changement d état de E afin qu il puisse prendre les nouvelles informations. Le programme est détaillé en annexe. Voici le corps du programme pour envoyer une instruction ou un caractère : - R/W = 1, - RS = 0 (caractère) ou 1 (instruction) - P0 = (caractère ou instruction à envoyer) - On met une petite temporisation pour être sur que les infos sont aux entrées de l afficheur (T>40 ns) - E = 1 l écran prend ainsi en compte les informations données. - Il faut attendre que l afficheur ait compris le passage à 1 de E. (T>220ns) - E = 0 afin de pouvoir changer les valeurs des entrées de l afficheur. - Il faut encore temporiser avant de changer les valeurs d entrée de l afficheur (T>280ns) Avant d afficher, il faut initialiser l afficheur, afin que l afficheur soit configuré comme on le souhaite (écriture de gauche à droite, pas de curseur apparent, deux lignes, pas de défilement ) Les fils de l afficheur ont été soudés complètement à la plaque de développement du microcontrôleur afin de pouvoir intégrer le tout dans le boîtier. Il marche bien même si les 16 caractères ne sont pas suffisants pour afficher la totalité des noms des radios tels qu ils sont envoyé par la borne, il faudra donc que l utilisateur renomme les radios pour qu elles prennent moins de 16 caractères. 27/101

Le Tuner FM L intérêt d intégrer un tuner FM est de pouvoir continuer à capter la radio quand on est en dehors d une zone couverte par le wifi. Son rôle est donc de compléter le système de réception wifi mais la fonction première du système est de capter les radios web. Le Tuner avait déjà été choisi par l équipe de l année dernière, il s agit du modèle TEA5768HL de chez Philips. Il a l avantage de nécessiter peu de composants externes pour fonctionner, diffuser du son directement en stéréo et est directement contrôlable par le microcontrôleur grâce à seulement deux fils de commandes (protocole I2C), cet avantage est important car l afficheur prenant déjà 9 sorties, les boutons 3 autres, on ne pouvait pas utiliser un Tuner trop gourmand en connectique. L utilisation du port série aurait été à proscrire, car il est déjà utilisé pour la communication avec la borne. L année dernière, l équipe avait fabriqué une plaque test auquel il manquait deux composant (les varicaps) que nous nous sommes procurés cette année. De plus, grâce à l utilisation de l USBee nouvellement acquis par le LISA, nous avons pu tenter de communiquer du PC au tuner : il reçoit bien les instructions et répond des informations cohérentes. Nous avons ensuite réalisé un circuit imprimé pour le Tuner, qui réussit à communiquer avec le PC via l USBee, mais il ne diffuse pas de son. Ceci peut être dû soit à des faux contacts sur la plaque, soit à des ondes parasites créées par la plaque et empêchant de bien capter les ondes radios, soit tout simplement à une mauvaise programmation du tuner. Nous n avons pas pu approfondir cette partie faute de temps car le tuner n était pas une priorité du projet. Grâce à l USBee, nous avons pu tester la communication entre le microcontrôleur et le tuner, mais cette communication n a pas fonctionné, que se soit avec la plaque test ou le circuit imprimé. L origine la plus probable de ce problème est que le programme fourni par Philips pour l I2C ne fonctionne pas. L un d entre nous a donc démarré une étude en autonomie afin de réaliser un programme I2C fonctionnant, mais elle n est pas encore terminée. 28/101

La description du tuner a été approfondie dans notre rapport de ME fourni en annexe. Interface Borne-Microcontrôleur L'interface entre la borne WiFi et le microcontrôleur représente l'aboutissement du projet. Il s'agit en effet de réunir les deux grandes parties du poste radio l'interface utilisateur et le routeur, chacune d'entre elles fonctionnant déjà séparément. Il avait été décidé dès le départ que le dialogue entre le microcontrôleur et la borne se ferait par le port série. Ce choix s'était imposé par son aspect standard, et surtout déjà mis au point par Philips dans le microcontrôleur d'une part, et dans les pilotes pour le port série sur OpenWRT pour la borne d'autre part. La gestion du port série sur le microcontrôleur Tout d'abord, il faut savoir que le port série est défini par défaut comme entrée et sortie standards pour le microcontrôleur. D'un point de vue programmation, cela signifie que tout se fait en utilisant les fonctions de la bibliothèque stdio.h (printf, getchar, etc.). Ensuite, la configuration se fait assez aisément en se rapportant à la documentation, section UART (page 71 de la documentation), et/ou en se basant sur le programme exemple «hello.c» fourni avec µvision. Nous avons choisi de travailler en mode 1, c'est à dire avec 8 bits transmis, aucun bit de parité et un bit stop. Un exemple : le calcul du baud rate Pour illustrer l'utilisation de la documentation, voici comment régler la vitesse du port série sur notre microcontrôleur dans le mode 1. Il faut pour cela considérer BRGR0 et BRGR1 comme un seul nombre hexadecimal (BRGR1,BRGR0) = N. La 29/101

vitesse du port série est donnée par la division de la fréquence de l'horloge CCLK = 7 372 800 Hz par N+16. Ainsi, pour obtenir un baud rate de 9600, il faut que N = CCLK / 9600-16 = 752, soit 02F0 en hexadecimal. Il faut donc que BRGR1 = 0x02 et BRGR0 = 0xF0 pour avoir un baud rate fixé à 9600. De même, pour avoir un baud rate à 115200, il faut N = 0030 en hexadecimal. Pour les tests, nous avons limité le baud rate à 9600 ; cependant, nous avons pu essayer avec succès de le fixer à 115200. Comment interfacer? Au début de la réflexion sur l'interfaçage borne-microcontrôleur, deux différentes manières d'interfacer sont apparues. L'unique hypothèse était qu'une playlist contenant des radios ou des fichiers soit en mémoire sur la borne. Le microcontrôleur central Dans cette première solution, on stocke toute la playlist de l'utilisateur sur le microcontrôleur, pour ensuite envoyer à la borne quel élément de la liste il faut jouer. Dans ce cas, le microcontrôleur est au centre du système, et la borne ne fait qu'exécuter ce que le microcontrôleur lui envoie. Cette solution a deux avantages. Le premier est d'être très proche, du point de vue programmation, des programmes déjà réalisés auparavant pour les tests ; le second, qui découle du premier, est la maturité et la simplicité d'une grande partie du programme qui serait utilisé. Le stockage de la playlist, dans ce cas, ne signifie évidemment qu'un stockage du nom des pistes afin d'être affichées sur l'écran LCD. Cependant, cela peut nécessiter énormément d'espace en mémoire du microcontrôleur, qui n'est absolument pas faite pour cela : certaines playlists peuvent en effet atteindre plusieurs centaines de 30/101

morceaux... Et à titre d'information, le P89LPC935 possède 8ko de mémoire flash. Bien que ce système soit beaucoup plus proche des programmes déjà réalisés pour les tests, ce problème de mémoire nous a poussé à choisir la seconde solution : Le microcontrôleur simple intermédiaire Dans cette seconde solution, absolument rien n'est stocké sur le microcontrôleur : il indique à la borne si l'utilisateur a appuyé sur un bouton, avant d'attendre une réponse pour savoir ce qu'il doit faire afficher. Pour plus de détails sur le programme, vous pouvez vous reporter aux commentaires des programmes en annexe. Les vitesses de transmission sur le port série nous a rendus optimistes sur la faisabilité de cette méthode. Cependant, dans la pratique, on se rend compte qu'il y a non seulement un temps de latence important (et très désagréable si on doit naviguer dans une grande playlist), mais aussi beaucoup d'erreurs de transmission. Nous avons trouvé deux pistes pour l'explication de ces erreurs : - une mauvaise configuration du port série sur la borne, due au fait que nous ne parvenons pas à savoir s'il faut un contrôle de flux et si oui, lequel ; - un problème de pilote pour le convertisseur USB-Série sur la borne : le buffer n'est pas vidé après l'envoi des données... Quoiqu'il en soit, ce problème a été contourné dans les dernières versions du programme d'interfaçage, mais il subsiste le problème du temps de latence, qui n'existe pas dans la première méthode. Au final, l'ensemble est fonctionnel, avec malheureusement ce défaut que nous n'avions pas imaginé au départ. Une piste d'amélioration Une solution à ce problème de temps de latence pourrait être de repasser dans la méthode où le microcontrôleur occupe une place centrale, en l'adaptant à son manque de mémoire. Cette adaptation pourrait prendre la forme d'une «fenêtre glissante» 31/101

d'environ une centaine de morceaux dans la playlist selon ce que peut stocker le microcontrôleur en dehors du programme lui-même. Il s'agirait alors par exemple de charger en mémoire du microcontrôleur les 50 morceaux précédents et les 50 morceaux suivants de la playlist par rapport au curseur, et d'attendre que le curseur soit arrivé près de l'un des bords de la «fenêtre» pour modifier les entrées en mémoire afin de les recentrer sur le curseur. Une première version test du programme pour cette méthode dans le cas d'une petite playlist a été rédigée afin de vérifier la base du programme, mais elle n'a pour l'heure pas été testée. Conclusions personnelles La programmation du microcontrôleur a été une tâche assez difficile à appréhender, en particulier parce qu'aucun de nous n'avait déjà programmé en C. Il a donc fallu simultanément se former à un nouveau langage de programmation et se familiariser avec un composant que nous n'avons pas eu l'habitude d'utiliser dans nos cours jusqu'à présent. Après 10 mois passés sur ce projet, le langage et le microcontrôleur ne sont plus des inconnues pour moi ; pourtant, j'ai toujours l'impression d'apprendre régulièrement quelque chose sur le fonctionnement de l'un ou de l'autre, au fur et à mesure que les objectifs des programmes et les problèmes à résoudre changent. Aussi, s'il est clair qu'au jour d'aujourd'hui, tout ce qui a été fait semble facile, il faut bien se rendre compte que cela n'a pas du tout été le cas au cours de l'année, et que ce qui est décrit dans ce rapport est le fruit d'une longue réflexion et de nombreuses corrections. Ensuite, nous avions été prévenus de la complexité de la programmation de l'i2c pour la communication entre le microcontrôleur et le tuner FM. Cela est tout à fait vrai, et c'est encore ce qui nous pose problème cette année pour faire aboutir la partie radio FM. Cependant, je souhaite rajouter qu'il est à mon avis absolument inutile de se pencher sur le programme fourni par Philips sans bien connaître certaines 32/101

fonctionnalités du microcontrôleur, telles que le timer et les interruptions, et sans bien maîtriser les structures de données en C en particulier les pointeurs et toutes leurs subtilités. Parallèlement à la programmation, la réalisation des plaques tests aura demandé une très grande méthode, non seulement pour la connexion des câbles, mais aussi pour la recherche d'erreurs. Enfin, à la lecture du rapport de l'équipe précédente, nous nous attendions à des problèmes pour obtenir des composants au détail et dans des délais raisonnables. En réalité, nous n'avons pas été confrontés à ce problème, mais il me semble important de mentionner que le contraire aurait pu tout aussi bien être vrai. Pour cette raison, je souhaite rappeler une partie du rapport du projet HOMeR 2005-2006 : «Les problèmes liés à la difficulté de s'approvisionner en petite quantité de composants électroniques nous ont montré qu'il faut prendre en compte le temps de l'achat (temps de trouver le fournisseur+délais de livraison), dans le temps de recherche d'un composant électronique. En particulier, lorsque l'on développe un produit, il faut être conscient que la plupart des fournisseurs travaillent avec des industriels, et qu'il vendent leurs composants en gros, donc cela peut être difficile de se fournir en petites quantités.» 33/101

V.Modélisation Boitier Pourquoi réaliser un boitier sous Catia L idée fut à l origine proposée par Jean-Sébastien qui avait discuté avec un enseignant de 3eme année. Catia est le logiciel de Conception Assistée par Ordinateur mis en place par Dassault. A la base, il permet la modélisation en 3D d objets et l assemblage de ceux-ci. Son développement actuel est tel qu on réalise maintenant de nombreux tests virtuels qui remplacent des tests réels trop couteux. L utilisation pour le projet est bien plus restreinte. La modélisation sous Catia possède plusieurs avantages qui correspondent au cahier des charges fixé pour le boitier. En effet, elle permet : - de dimensionner exactement l objet par rapport aux composants internes qui sont aussi modélisés et d obtenir ainsi une taille optimale et adaptée. - de réaliser un boitier avec un design sympathique - le prototypage grâce à une imprimante 3D utilisable à l IUT de Cachan J ai pu assister à un module de formation de trois après-midis sous Catia prévu pour des élèves de troisième année de filière CAO et présenté par M. Morenton, ce qui m a permis d acquérir les bases nécessaires à la fabrication du boitier. 34/101

Fabrication des diverses pièces Afin de produire un boitier adapté au système, il faut tout d abord dessiner l ensemble des pièces qui seront placées à l intérieur. Pour cela, on ne cherche pas la complication mais on va simplement mesurer les pièces et dessiner des parallélépipèdes correspondant au volume qu elles occuperont. Pour les composants qui seront en contact avec l extérieur, on améliore un peu le dessin de manière à pouvoir adapter les ouvertures dans le boitier (enceintes, écran, boutons) Dessin du boitier Le dessin du boitier commence par la partie la plus compliquée, les cotés du boitier, qui sont arrondis pour obtenir un design intéressant. Pour cela il faut utiliser le module de dessins de surface. On dessine d abord des surfaces qu on va assembler afin d obtenir un volume. On cote toujours les différentes longueurs et on cherche déjà à réaliser un modèle adapté à la taille des composants internes. 35/101

La transformation des surface en volume s est avérée difficile car il y avait des problèmes de tangences mais Catia notifiait juste qu il y avait un problème sans l expliciter. Le schéma ci-dessous montre les différentes étapes permettant d obtenir une première ébauche du boitier. Lors des dessins primaires, il faut faire attention à ce que les étapes soient réversibles, c'est-à-dire que l on puisse modifier une longueur sans que cela ne gène le reste de la pièce. Cela ressemble aux règles de programmation où dès le début, on doit écrire proprement son code pour pouvoir revenir en arrière. 36/101

Amélioration du boitier Une fois la première ébauche terminée, on commence à assembler les pièces à l intérieur du boitier pour voir quelles longueurs il va falloir modifier. Des tests effectués sur les enceintes l année dernière et cette année ont montré que sans caisse de résonnance, on n entendait aucunement les basses. C est pour cela qu on a dessiné un compartiment pour les enceintes ainsi qu un système de bass reflex, renvoyant le son des basses vers l avant. Cette étape fut simplifiée car Catia permet de modifier une pièce dans une fenêtre et de voir en temps réel les modifications apparaître sur la fenêtre de l assemblage. Le boitier obtenu après ces modifications est le suivant : Optimisation du volume Lors d un rendez-vous avec M. Morenton, nous nous sommes rendus compte que le volume à fabriquer était beaucoup trop grand (plus de 600g). Or comme le matériel à prototypage coute 1 euro au gramme, il a fallu faire des modifications drastiques afin de diminuer le volume. Ainsi l épaisseur de la coque a été diminué jusqu à 2.5 mm. On a ajouté des nervures sur la coque arrière afin de la solidifier. La coque avant n en avait pas besoin car les parois des enceintes rigidifiaient déjà suffisamment le boitier. 37/101

Afin de diminuer la masse on a aussi pratiqué des trous là où la matière n était pas nécessaire : au niveau des enceintes et au niveau de l écran. On a aussi réalisé deux modèles pour la coque arrière car il y avait une grande surface plane qu on pouvait remplacer par du plexiglas. Une autre contrainte imposée à ce moment fut la taille maximale, en effet l imprimante 3D ne peut pas prototyper des objets dépassant 30cm de longueur. Il a donc fallu reprendre toute la modélisation à zéro afin de réaliser le boitier convenable, car de nombreuses étapes de modélisation n étaient pas réversibles. Après modification la masse totale n était plus que de 390g. Ci-dessous, à gauche, la coque arrière avec et sans l évidement ; à droite la coque avant évidée : Finalisation Après avoir réduit la taille et la masse du boitier, il ne restait plus qu à finaliser le boitier. Dans cette étape, on rajoute simplement des trous pour accueillir les vis qui permettront de fixer les deux boitiers ensemble. On ajoute aussi des encoches complémentaires afin de contrer les erreurs de planéité des surfaces de contact des deux parties du boitier. 38/101

Le boitier final obtenu dans l assemblage complet ressemblera donc à cela : 39/101

Conclusions personnelles Cette partie que j ai réalisée seul fut vraiment la source de nombreux enseignements. Tout d abord la formation de 3 après-midi avec M. Morenton que j ai beaucoup apprécié puis après son aide au cours du développement du projet m ont permis de progresser vite avec Catia. Ce logiciel est au début difficile à prendre en main car les bugs qui occurrent se résolvent rarement de manière intuitive mais avec un peu d expérience et de volonté, on peut réussir à faire rapidement des objets complexes. D autre part, je pense que cette formation par l expérimentation personnelle me servira toujours et m a donné envie de développer des projets où l initiative et la responsabilité est personnelle. 40/101

VI.Système audio Le système d émission audio est constitué d un amplificateur stéréo, de deux enceintes et d un potentiomètre permettant de régler le volume. Il est directement relié à la carte son usb, elle-même reliée au routeur. Nous avons abandonné l ajout d une sortie ligne en mini-jack prévue initialement dans le projet l année dernière. En effet pour la version transportable du projet, ajouter une sortie ligne ne semble pas nécessaire car on utilisera plutôt les enceintes intégrées alors que dans la version fixe, elle était nécessaire, pour pouvoir envoyer le signal vers un amplificateur. Pour ce qui est du circuit d amplification nous avons repris exactement celui de l année dernière en remplaçant quelques connexions défectueuses et en y soudant directement les câbles des enceintes. Pour garder un bon signal amplifié nous avons choisi d utiliser du câble coaxial pour effectuer les liaisons entre l amplificateur et les enceintes car la place dans le boitier étant restreinte, les câbles risquent de passer près d autres composants électroniques qui pourraient générer des interférences. 41/101

VII.Circuit d alimentation Présentation et objectifs Un module expérimental a été consacré au circuit d alimentation. L ensemble de l étude se trouve dans le rapport de ME. On ne présentera dans cette partie qu une synthèse des réalisations et résultats. Afin de réaliser un système autonome, il fallait nécessairement munir notre système d une alimentation intégrée. L objectif de cette alimentation est de pouvoir faire fonctionner le circuit en autonomie pendant deux heures. Etude préliminaire Nous avons d abord listé l ensemble des composants du système ainsi que leurs caractéristiques électriques. Composants tensi inten puissan on en sité en ce en W V A routeur 12 1 12 microcontrôl eur 5 0,1 0,5 ampli audio 14 0,80,9 12 tuner 3 ~0 ~0 écran 5 ~0 ~0 42/101

Nous avons choisi d utiliser une batterie composée de 12 accumulateurs ayant une grande charge (3200mAh) et délivrant une tension de 14.4V. Pour le circuit de charge, un composant spécialisé a été trouvé. Il a fallu étudier précisément la documentation afin de pouvoir l adapter exactement à notre système. Pour alimenter les différents éléments du système il faut aussi adapter la tension. Nous avons choisi pour cela un convertisseur DC/DC qui alimentera le routeur avec une tension stabilisée de 12V avec un bon rendement pour éviter les pertes. L alimentation de l amplificateur audio se fera en direct puisqu on peut lui fournir une tension variable. Pour les petits composants ne nécessitant pas beaucoup de puissance nous avons choisi un simple écréteur 5V. Le schéma-bloc du système est le suivant. Réalisation Une fois tous les composants reçus, le montage a été testé sur une plaque test puis modélisé sous Orcad puis mis sur circuit imprimé. Le circuit fonctionne parfaitement et des tests d intensité ont été réalisés afin de déterminer les puissances effectives consommées. 43/101

P (W) Composant V I (A) Routeur au lancement 12 0,6 7,2 Routeur en fonctionnement stationnaire 12 0,4 4,8 Enceintes à volume maximum 14, 4 1,2 17,3 Enceintes à volume moyen 14, 4 0,8 11,5 Microcontrôleur 5 0,1 0,5 Ecran 5 0,0025 0,0 Tuner Fm 5 0,1 0,5 Autonomie (heures) Puissance totale volume moyen 17,3 2,66 Puissance totale volume maximum 23,1 2,00 Voici la plaque réalisée : Afin de s adapter aux exigences du boitier, nous avons fait deux ensembles de 6 piles en les soudant. 44/101

VIII.Conclusion Fin et avenir du projet Le projet arrive cette année à un palier. En effet, l'équipe de cette année a abouti à un produit fini mais pas finalisé! Les fonctionnalités doivent encore être améliorées mais le travail fourni a permis de concevoir un produit complet. La prochaine phase du projet passe par une miniaturisation des différents modules et une meilleure intégration, sans oublier les énormes possibilités offertes par la distribution OpenWrt. L'arrivée des prochaines normes wifi devraient permettre le développement de notre type de récepteur et aussi des nouvelles directions de travail à la future équipe. Bilan Cette année a été notre premier projet et notre première vraie expérience de travail en groupe. Cela nous a permis de développer des capacités qui nous seront utiles dans notre future vie professionnelle. Après une reprise du projet plus longue que prévue, l'équipe a avancé pour arriver à un résultat concluant. Les différentes avancées se sont enchaînées et ont permis de garder la motivation du groupe jusqu'à la fin d'année et même de l'augmenter à la fin! Nous avons aussi essayé de laisser le plus de documentation afin qu'une future équipe puisse être efficace le plus rapidemment possible. L'ensemble de cette documentation et le rapport seront gravés sur DVD avec les programmes nécessaires. 45/101

IX.Remerciements Nous tenons à remercier vivement toutes les personnes nous ayant aidé pour ce projet : - Notre encadrant Laurent Cabaret pour ses conseils avisés, son soutien et sa disponibilité. - Pascal Morenton pour son aide sur la conception sous «CATIA» - Alexandre Coninx pour son aide sur OpenWRT et le réseau WiFi. - Le personnel du LISA pour les moyens qu'ils ont mis à notre disposition. - Les membres de RadioPi et de l'association «VIA Centrale réseaux» pour leur soutien, leur aide technique, et leur apport financier. - Les développeurs OpenWRT pour tout leur travail essentiel à notre projet. - L'équipe de l'année dernière pour l'idée et le travail accompli avant nous. 46/101

X.Annexes Manuel OpenWrT Flashage a. Prérequis : Kamikaze étant une version de développement, il faut la compiler, c'est pourquoi on a besoin d'au moins une machine sous linux si possible avec une bonne puissance de calcul car la compilation peut être très longue. Il faut commencer par installer les paquets nécessaires à la compilation : gcc, g++, binutils, patch, bzip2, flex, bison, make, gettext, unzip, ncurses (libncurses-dev), libzdev, libc headers, sharutils, autoconf, pkg-config et automake. Soit sous Debian ou Ubuntu il faut taper : # apt-get install gcc g++ binutils patch bzip2 flex bison make gettext unzip ncurses libz-dev libc6-dev sharutils autoconf pkg-config automake subversion b. La compilation Une fois les paquets essentiels installés, on checkoute le svn du projet openwrt dans le dossier ~/svn/kamikaze : % % % % % % % cd mkdir svn cd svn/ mkdir kamikaze cd kamikaze svn co https://svn.openwrt.org/openwrt/trunk/ svn co https://svn.openwrt.org/openwrt/packages 47/101

On met les sources à jour : % % % % cd trunk svn up cd../packages/ svn up On linke ensuite les paquets au trunk : % % % % % % cd ln ln ln ln ln ~/svn/kamikaze/trunk/package -s../../packages/libs/* -s../../packages/sound/* -s../../packages/utils/* -s../../packages/net/* -s../../packages/lang/* On se prépare à la compilation en configurant OpenWRT pour correspondre à notre routeur soit on choisit de le faire à la main en sélectionnant toutes les bonnes options en fonction de la borne et de nos besoins (noyau 2.6, madwifi, mpc, mpd, php, lighttpd, alsa, usb, wpa_supplicant, stty...), soit on décide d'utiliser la configuration que nous avons faite. Le fichier est dans l'archive : % % % % cd <répertoire de l'archive> cp configuration ~/svn/kamikaze/trunk/.config cd ~/svn/kamikaze/trunk/ make oldconfig Si on pose des questions il faudra choisir, on peut obtenir des informations en tapant «?». En général laisser l'option par défaut est une solution sure. On vérifie que tout est bien : % make menuconfig Lorsque tout est bien configuré, on quitte en enregistrant la configuration puis on lance : % make 48/101

La compilation risque de durer longtemps c'est pourquoi je recommande de la lancer dans un screen (on pourra donc remplacer donc la dernière commande par les suivantes) : # apt-get install screen % screen -S compilation % make On prendra le binaire trunk/bin/openwrt-wgt634u-2.6-squashfs.bin que l'on placera dans le répertoire du serveur tftp, de base sous debian, le répertoire /tftpboot. % cp ~/svn/kamikaze/trunk/bin/openwrt-wgt634u-2.6-squashfs.bin /tftpboot/ % cd /tftpboot c) Console série Il est désormais temps de réaliser la console série en suivant le schéma suivant : On configure minicom : % minicom -s 49/101

Puis dans le menu «Configuration du port série» : - on tape «A» puis on configure l'adresse du port série (en général /dev/ttys0 ou /dev/ttyusb0 on peut le voir lançant la commande dmesg) on revient en tapant «Échap» - on tape «E» puis «IL1» ce qui correspond à 115200 8N1 puis «Entrée» - Enfin on active contrôle logiciel en tapant «G» - On appuie sur «Échap» - On enregistre la configuration sous dfl - On sort A ce niveau on doit se trouver au niveau d'un prompt. On connecte le serveur au port WAN de la borne. On maintient «Ctrl+C» pendant qu'on reboote la borne jusqu'à l'apparition du prompt : CFE> On tape alors : CFE> ifconfig eth0 -addr=192.168.1.250 -mask=255.255.255.0 CFE> flash -noheader <ip du serveur en 192.168.2.xxx>:openwrt-wgt634u-2.6-squashfs.bin flash0.os Si le fichier dépasse les 4Mo, il y a des chances qu'on obtienne un message du type : Reading <ip du serveur en 192.168.2.xxx>:openwrt-wgt634u-2.6-squashfs.bin: Done. 3932160 bytes read Programming...done. 3932160 bytes written *** command status = 0 Le 3932160 pouvant varier et représentant l'offset bs à utiliser car il va alors falloir spliter l'image : % dd if= openwrt-wgt634u-2.6-squashfs.bin of=foo.img.1 bs=3932160 skip=1 50/101

Il ne faut pas oublier de modifier la valeur de bs en fonction de l'offset que l'on a obtenu. On finit de flasher : CFE> flash -noheader -offset=3932160 <ip du serveur en 192.168.2.xxx>:foo.img.1 flash0.os Reading tftp_host:foo.img.2: Done. 786256 bytes read Programming...done. 786256 bytes written *** command status = 0 Après quelques minutes, on peut enfin employer la commande CFE> reset On a donc désormais un système OpenWRT Kamikaze fonctionnel. 2) Configuration a. Bases Normalement à ce niveau il suffit de se brancher sur des ports LAN pour obtenir du DHCP. On tape alors : % telnet 192.168.1.1 Normalement, on voit s'afficher l'écran suivant : Il est temps de mettre un mot de passe : root@openwrt:/# passwd Changing password for root Enter the new password (minimum of 5, maximum of 8 characters) Please use a combination of upper and lower case letters and numbers. Enter new password: Reenter new password: Password changed. root@openwrt:/#exit 51/101

Il ne reste alors plus qu'à se connecter en SSH sur la borne soit avec PuTTY sous windows soit avec la commande linux : % ssh root@192.168.1.1 b. Mettre le système sur clé USB Nous allons pouvoir passer le système sur la clé USB : On commence par formater la clé en ext2, en s'assurant que l'on a bien activé l'ext2 dans OpenWRT - On branche la clé sur le hub - On lance la commande dmesg on doit obtenir quelque part un résultat de ce type : usb 2-1: new full speed USB device using ohci_hcd and address 3 usb 2-1: configuration #1 chosen from 1 choice scsi1 : SCSI emulation for USB Mass Storage devices Vendor: Generic Model: USB Flash Drive Rev: %z!y Type: Direct-Access ANSI SCSI revision: 02 SCSI device sda: 64128 512-byte hdwr sectors (33 MB) sda: Write Protect is off sda: assuming drive cache: write through SCSI device sda: 64128 512-byte hdwr sectors (33 MB) sda: Write Protect is off sda: assuming drive cache: write through /dev/scsi/host1/bus0/target0/lun0: p1 sd 1:0:0:0: Attached scsi removable disk sda On sait donc que la clé est attachée à /dev/scsi/host1/bus0/target0/lun0/part1 ce résultat peut varier il va donc falloir adapter la suite. On va ensuite taper : mkdir -p /usb mount /dev/scsi/host1/bus0/target0/lun0/part1 /usb cd /usb # On crée des répertoires de racine mkdir proc mkdir sys mkdir dev mkdir rom # On copie le contenu depuis la mémoire Flash mkdir bin cp -a /rom/bin/* bin mkdir etc cp -a /rom/etc/* etc mkdir usr cp -a /rom/usr/* usr mkdir lib 52/101

cp -a /rom/lib/* lib mkdir sbin cp -a /rom/sbin/* sbin # copy from jffs mkdir tmp cp -a /tmp/* tmp mkdir var cp -a /var/* var cp -a /etc/config etc # On achève les préparations pour notre nouvelle racine chmod oug+rwxt /tmp # On démonte les systèmes de fichier que le noyau monte ou qui sont requis par preinit # depuis /rom cat << EOF >> etc/init.d/s99done # umount old dev, proc and usbfs umount /rom/proc/bus/usb umount /rom/proc umount /rom/dev EOF On doit démonter proprement ces systèmes de fichier et remonter le système de fichier en lecture seule avant d'éteindre la borne pour éviter d'endommager les données à chaque extinction. On crée donc le fichier etc/init.d/rck : vim etc/init.d/rck Dans lequel on copie : #!/bin/sh # umount usb_root_device=`mount echo umount umount umount echo mount dev, awk '{ "unmounting "remounting $usb_root_device echo /sbin/halt proc, if ($3 memory root sys == "/") and print based in / -o read remount "halting $1 usbfs '` filesystems" /sys /dev/pts /proc/bus/usb only -o mode" ro system" On fait en sorte de le rendre exécutable : chmod +x etc/init.d/rck On modifie l'inittab pour appeler ce script d'arrêt : cat << ::sysinit:/etc/init.d/rcs ::shutdown:/etc/init.d/rck tts/0::askfirst:/bin/ash #tts/1::askfirst:/bin/ash EOF EOF > inittab --login --login 53/101

On enlève tout ce qui pourrait modifier la flash : rm /usb/bin/firstboot /usb/sbin/jffs2root /usb/sbin/mount_root /usb/etc/preinit /usb/sbin/mtd Une fois qu'on a bien vérifié que tout s'est bien passé, on peut démonter la clé. Il faut alors faire une nouvelle image qui a un /etc/preinit différent. On retourne donc au svn : cd # on rm bin/firstboot # on recrée mkdir usb Soit on ~/svn/kamikaze/trunk/openwrt/build_mipsel/root protège la flash sbin/mount_root etc/preinit sbin/mtd sbin/jffs2root le point de montage de l'usb télécharge directement le fichier préinit dans ~/svn/kamikaze/trunk/openwrt/build_mipsel/root avec : wget -O etc/preinit chmod +x etc/preinit http://openwrt.pbwiki.com/f/wgt634u_usb_root_preinit Soit on recrée etc/preinit : vim etc/preinit Et on copie ce fichier : #!/bin/sh # dacb's preinit to pivot_root to USB export PATH=/bin:/sbin:/usr/bin:/usr/sbin # not sure if this is strictly necessary, but the usb modules like usbfs # and it gives us someplace specific to look for usb storage devices mount none /proc -t proc # this allows your system to boot from ext2 or fat - I use ext2, but fat # is nice if you want to drop the USB device into a windows box (I guess) # if your root is ext2 insmod ext2 # if your root is fat/vfat insmod nls_base insmod fat 54/101

insmod vfat # load modules for usb storage insmod usbcore insmod ohci-hcd insmod uhci-hcd insmod ehci-hcd insmod scsi_mod insmod sd_mod insmod usb-storage # find a suitable USB filesystem: assemble a list of devices available # using lsusb might be better than searching for devices? # first wait until the scsi device tree is created usb_device_search_start=/dev/scsi echo "waiting for usb storage devices (in device tree $usb_device_search_start)" while [! -d $usb_device_search_start ]; do sleep 5 echo "still waiting $usb_device_search_start)" for usb storage devices (in device tree done echo "found base of usb storage device tree at $usb_device_search_start" # now search the scsi device tree for filesystem device files find_usb_storage_devices () { usb_storage_devices="" usb_scsi_hosts=`\ls $usb_device_search_start` if [! -z $usb_scsi_hosts ]; then usb_storage_devices=`\ls $usb_device_search_start/*/*/*/*/part*` echo "list of found usb storage device partition files: $usb_storage_devices" else echo "no scsi hosts found in $usb_device_search_start, retrying in 5 seconds" sleep 5 fi find_usb_storage_devices while [ -z $usb_storage_devices ]; do echo "unable to find any suitable storage devices in $usb_device_search_start, retrying in 5 seconds" sleep 5 find_usb_storage_devices 55/101

done # go through list of usb storage devices and see if any are possible roots, use first one find_usb_root_device () { found_usb_root_device=0 for usb_root_device in $usb_storage_devices; do echo "trying to mount $usb_root_device on /usb in readonly mode" mount $usb_root_device /usb -o ro \ls -l /usb # is there an indiciation this partition has enough of a filesystem to be our new root? if [ -d /usb/bin ] && [ -d /usb/etc ] && [ -d /usb/sbin ] && /usb/sbin/init ] && [ -d /usb/usr ] && [ -d /usb/var ] && [ -d /usb/tmp ]; then [ -x echo "found suitable USB storage device w/ filesystem that looks like root: $usb_root_device" found_usb_root_device=1 umount /usb break fi # if the mount failed, so will this, oh well... echo "trying to unmount /usb" umount /usb done find_usb_root_device if [ $found_usb_root_device = 0 ]; then # final catch while [ 1 ]; do echo "unable to find suitable USB storage device w/ filesystem, waiting 10 seconds before retry" sleep 10 find_usb_storage_devices if [! -z $usb_storage_devices ]; then find_usb_root_device if [ $found_usb_root_device = 1 ]; then break; fi fi done fi # check and mount base filesystem 56/101

echo "determining filesystem type on $usb_root_device and checking filesystem" # this would be easier with 'file' but we don't have it and neither does busybox # this might be dangerous - determining filesystem type by trying to mount specific # types (read only) - if it succeeds the filesystem type is known and a check is done if mount -t ext2 $usb_root_device /usb -o ro ; then umount /usb # if your filesystem is ext2 echo "$usb_root_device is ext2" e2fsck -y $usb_root_device elif mount -t msdos $usb_root_device /usb -o ro ; then umount /usb # if your filesystem is fat check it echo "$usb_root_device is fat" dosfsck -y $usb_root_device else echo "giving up without checking filesystem" fi # mount our new root mount $usb_root_device /usb -o rw # pivot root - mount /usb as root and our old root as /rom under the usb partition pivot_root /usb /usb/rom # umount old dev, proc and usbfs # doesn't work here, add to end of /etc/init.d/s99done on usb root filesystem #umount /rom/proc/bus/usb #umount /rom/proc #umount /rom/dev # mount new dev, proc, sys and usbfs mount none /proc -t proc mount none /dev -t devfs mkdir -p /dev/pts mount none /dev/pts -t devpts mount none /proc/bus/usb -t usbfs mount none /sys -t sysfs exec /sbin/init Il ne nous reste plus qu'à recompiler : 57/101

cd ~/svn/kamikaze/trunk/ make target/install On reflashe la nouvelle image par la console série et on peut admirer le résultat : root@openwrt:/# df Filesystem /dev/scsi/host0/bus0/target0/lun0/part1 1k-blocks 31029 Used Available Use% Mounted on 4665 24762 16% / c) Installation des paquets A ce niveau là, je conseille fortement d'utiliser un serveur http (comme apache) sur une machine connectée à internet et de faire un lien symbolique entre le trunk/bin/packages et le ~/public_html/ % % % % cd mkdir public_html cd public_html ln -s ~/svn/kamikaze/trunk/bin/packages Ceci nous permet d'avoir notre propre dépôt de paquets à l'adresse : http://<serveur>/~<user>/packages Il ne nous reste alors plus qu'à modifier la source-list : % vi /etc/ipkg.conf On commente les lignes (avec des «#») puis on ajoute les lignes suivantes : src snapshots http://<serveur>/~<user>/packages dest root / dest ram /tmp On peut alors lancer : ipkg update Et commencer l'installation des paquets qui nous intéressent : ipkg install kmod-usb2 ipkg install kmod-usb-core 58/101

ipkg install kmod-soundcore ipkg install kmod-usb-audio ipkg install lighttpd ipkg install kmod-madwifi ipkg install wpa_supplicant ipkg install wireless-tools ipkg install mpc ipkg install mpd ipkg install php5 ipkg install php5-cgi d) Configuration On peut commencer à configurer le mpd : On crée nos propres répertoires : mkdir /usr/local mkdir /usr/local/mpd On ouvre le fichier de configuration vi /etc/mpd.conf On édite les option comme suit : music_directory "/usr/share/mpd" playlist_directory "/usr/share/mpd" db_file "/usr/local/mpd/mpd.db" log_file "/usr/local/mpd/mpd.log" error_file "/usr/local/mpd/mpd.error" pid_file "/usr/local/mpd/mpd.pid" # use this if you want to use OSS audio output audio_output { type "oss" name "my OSS sound card" device "/dev/sound/dsp" # optional format "44100:16:2" #optional # OSS Mixer mixer_type "oss" mixer_device "/dev/sound/mixer" mixer_control "PCM" state_file "/usr/local/mpd/mpdstate" On peut ensuite le lancer pour tester : mpd /etc/mpd.conf 59/101

Normalement on doit avoir : root@openwrt:~# netstat -na grep 6600 tcp 0 0 0.0.0.0:6600 0.0.0.0:* LISTEN Il ne reste a priori plus qu'à configurer le client : export MPD_HOST=localhost On a désormais une véritable station multimédia facilement commandable : Commande Action mpc add <fichier ou flux distant> Ajoute le fichier ou flux à la playlist mpc del 3 Supprime l occurrence 3 de la playlist mpc clear Efface toute la playlist mpc play 6 Joue l occurrence 6 de la playlist mpc stop Arrête la lecture mpc volume +30 Augmente le volume de 30% mpc volume -50 Baisse le volume de 50% mpc Affiche le statut actuel de MPD Enfin, il reste à configurer le wifi : cd /etc vim wpa_supplicant.conf Dans lequel on copie : ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=0 eapol_version=1 ap_scan=2 fast_reauth=1 network={ ssid="ecp-cti" key_mgmt=wpa-eap eap=peap pairwise=tkip group=tkip proto=wpa identity="<login CTI>" password="<mdp CTI>" phase1="peaplabel=0" 60/101

phase2="auth=mschapv2" priority=10 On peut alors lancer le wifi avec les commandes : wpa_supplicant -i ath0 -c /etc/wpa_supplicant.conf -D wext -Bw udhcpc -i ath0 Pour finir, on crée un script de démarrage pour que le mpd et le wifi se configure tout seul : vim /etc/init.d/initialisation Dans lequel on copie : #!/bin/sh /etc/rc.common # Script d'initialisation des services START=80 start() { /usr/bin/mpd /etc/mpd.conf /usr/sbin/wpa_supplicant -i ath0 -c /etc/wpa_supplicant-cti.conf -D wext /bin/sleep 1 /sbin/udhcpc -i ath0 Puis on le rend exécutable : chmod 755 /etc/init.d/initialisation cd /etc/rc.d/ ln -s /etc/init.d/initialisation S80initialisation Avec ceci la borne s'autoconfigure au démarrage et est tout de suite prête à l'emploi. On pourra accessoirement ajouter plus tard l'exécution du script php de contrôle par le microcontrôleur dans initialisation. 3) L'interfaçage Voici le script d'interfaçage de la borne et du microcontrôleur qui tourne sur la borne : 61/101

<?php exec("rm -f playlist.dat && mpc playlist > playlist.dat"); $pl = fopen("playlist.dat","r"); echo " Ouverture du fichier playlist.dat "; $playlist=array(); if ($pl) { while (!feof($pl)) { array_push($playlist,fgets($pl)); fclose($pl); array_pop($playlist); print_r($playlist); $taille=sizeof($playlist); exec("stty -F /dev/usb/tts/0 9600 -ixoff -ixon cs8 -parenb -cstopb -crtscts"); $fp = fopen("/dev/usb/tts/0", "w+"); echo "Configuration du port serie effectuee.\n"; fwrite($fp,"1"); fclose($fp); echo "La borne est prete.\n"; $a_envoyer=" ok "; $i=0; $cursor=0; while(true) { $c=""; $fp = fopen("/dev/usb/tts/0", "w+"); $c = fread($fp,1); fclose($fp); //usleep(10); echo "Le MC a envoyé : ".$c[strlen($c)-1]; $fp = fopen("/dev/usb/tts/0", "w+"); fwrite($fp," "); if (!strcmp($c,"1")) { $a_envoyer = $playlist[$cursor]." ".$playlist[($cursor+1)%$taille]." "; $cursor=($cursor+1)%$taille; else if (!strcmp($c,"2")) { $a_envoyer = $playlist[($taille+($cursor-1)%$taille)%$taille]." ".$playlist[$c $cursor=($taille+($cursor-1)%$taille)%$taille; else if (!strcmp($c,"3")) { exec("mpc play ".($cursor+1)); echo "Ok c'est parti pour la musique coco\n"; fwrite($fp,$a_envoyer); echo "\nla borne a repondu et envoyé : ".$a_envoyer.".\n"; usleep(100); 62/101

fread($fp,strlen($a_envoyer)); fclose($fp);?> 63/101

Rapport ME système alimentation Résumé Il faut rappeler que ce ME s'inscrit dans le cadre du projet de seconde année «HOMeR, conception et développement d'un récepteur portatif de radio web». Ce projet a été lancé par des élèves de la promotion p2007 et repris par des p2008. Le but est de permettre aux Centraliens de pouvoir écouter les radios web sur le campus à partir d'un récepteur portatif. Ce récepteur se devant d'être alimenté sur batterie pour pouvoir être transporté n'importe où. Notre démarche, chronologique, est aussi à l'origine du découpage de ce rapport. Nous allons ainsi commencer par fixer un premier cahier des charges pour le système d'alimentation. Une fois cela fait, nous serons en mesure de choisir le système le plus approprié à notre projet. Puis suivra l'étude théorique et la démarche de commande des composants, qui ne fut pas aisée! On terminera par la phase de réalisation, de test et d'intégration dans le projet. 64/101

Cahier des charges Les besoins en énergie et les contraintes liés au système d'alimentation nous sont fournis par le cahier des charges général du récepteur. Notre but est de concevoir une alimentation unique avec des batteries pour faire fonctionner le récepteur avec tous ses composants et modules. La première chose à faire est de recenser l'ensemble des composants demandeurs d'énergie. Les besoins : Le routeur qui requiert une tension de 12V Le micro-contrôleur qui requiert une tension de 5V L'écran LCD qui requiert 5V Le tuner FM qui requiert 3V L'amplificateur audio qui requiert du 14V Les intensités requises vont du ma pour le tuner FM à 1A pour le routeur (voir tableau des consommations ). Le composant qui va dimensionner nos batteries est celui qui consomme le plus à savoir l'amplificateur audio et le routeur. Il faut aussi prendre en compte que l'autonomie voulue est d'au moins une heure et que le poids doit être faible. ( des piles LR6 serait l'idéal mais pas plus d'une quinzaine ) Il faut aussi prendre en compte la facilité pour recharger les batteries et la nécessité de délivrer des tensions continues différentes. Nous allons voir dans la partie suivante les choix qui ont été pris. 65/101

Tableau des consommations : Composants tension en V intensité en A puissance en W routeur 12 1 12 micro-contrôleur 5 0,1 0,5 ampli audio 14 0,8-0,9 12 tuner 3 ~0 ~0 écran 5 ~0 ~0 66/101

Choix des composants Pour des raisons de poids, nous nous sommes tournés vers des accus ni-mh 3200 mah de type LR6. En associant 12 piles en série, nous obtenons une tension d'environ 14,4 V, ce qui convient parfaitement à notre utilisation. En faisant un calcul grossier, nous devrions avoir une autonomie d'environ une heure trente minutes. De plus, ces batteries ont un coût modique d'environ 30 euros pour 16 accus. Le choix suivant a été le moyen de recharger ce type de batterie. Leur fonctionnement étant un peu complexe, nous avons cherché un circuit pouvant servir à charger les batteries et alimenter l'ensemble des modules à partir d'une tension continue classique. Après quelques recherches, nous avons choisi un composant Maxim, le max 712. La documentation fournie nous a donné le circuit permettant de charger et d'alimenter en même temps. Malheureusement, cette dernière étant un peu «obscure» au début, il nous a fallut contacter le service client de Maxim pour obtenir des précisions supplémentaires, ce qui a retardé l'avancement. La dernière étape a été de choisir comment délivrer différentes tensions. Notre choix s'est tourné vers un convertisseur DC-DC qui sort une tension de 12V pour 1,5 A max, parfaitement adapté au routeur. Ce type de convertisseur est relativement cher ( 40 euros ) mais son rendement est élevé ( 85%). Une des difficultés fut d'en trouver un qui accepte des voltages entre 14 et 20 V car les convertisseurs classiques de ce type sont soit 9-18V soit 18-36V. L'amplificateur audio pouvant fonctionner de 14 V à 20V, nous avons décider de l'alimenter directement sur les batteries ( une tension d'environ 14,5V ) ou sur la tension de charge des batteries ( 20V ) qui sera calculée dans la partie suivante sur le circuit théorique. Pour le reste des modules qui sont alimentés en 5V et consomment quelques ma, un simple écrêteur de tension suffit. L'ensemble des composants a été commandé en plusieurs fois à cause des problèmes de disponibilités. Il a fallu aussi attendre le calcul de certains composants sur le circuit théorique et aussi les tests pour commander l'alimentation du circuit. 67/101

Schémas-blocs L alimentation doit fonctionner dans deux cas. Lorsque la borne est branchée sur secteur, alors le circuit charge la batterie et alimente le reste du circuit. Lorsque la borne n est plus branchée sur secteur, ce sont les piles qui alimentent tout le circuit. En réalité on va voir qu avec le circuit MAX712 les deux schémas sont compatibles. 68/101

Circuit choisi C est ce circuit proposé dans la documentation du composant de charge MAX712 que nous allons retenir. On remarque que la batterie et le circuit (load) sont reliés en parallèle avec un condensateur entre les deux qui permet la bascule lorsque l on débranche le secteur. En effet, lorsque le circuit est branché sur secteur, le composant max712 délivre l intensité nécessaire à la batterie pour qu elle se charge et en même temps alimente le circuit. Lors du débranchement, le condensateur se décharge dans le circuit le temps que la batterie se mette à délivrer le courant nécessaire au fonctionnement du circuit. Pour que le composant MAX712 s adapte au circuit, il faut tout d abord déterminer la résistance Rsense qui va contrôler l intensité de charge de la batterie. Celle-ci se calcule en fonction du temps de charge rapide des batteries. 69/101

Ce qui donne dans notre cas Ifast = 800mA et RSense =.33 Ω. Une telle résistance est assez rare dans le commerce. Le choix a été fait de prendre une résistance de puissance de 5W pour prendre large et éviter que celle-ci puisse fondre. Il faut aussi programmer le composant pour qu il s adapte à la batterie. La programmation se fait à l aide des pins PGM. On programme le nombre de piles dans la batterie avec PGM0 et PGM1. On se réfère pour cela au tableau 2 de la documentation du max712. Dans notre cas il faut les connecter respectivement à REF et BATT-. On programme aussi le temps de charge de la batterie. Pour 4h de charge, il faut connecter les pins PGM2 et PGM3 sur BATT-. Une fois tous les composants reçu, le circuit a été réalisé sur une plaque test et a fonctionné du premier coup. Nous avons pu charger entièrement les 12 piles et tester les piles sur le routeur et sur l amplificateur. 70/101

Réalisation, tests Suite à cela, nous avons modélisé le circuit sous Orcad et nous avons fabriqué le circuit imprimé. Ce circuit aussi a fonctionné dès la première fois. Nous avons aussi fait deux blocs avec les batteries en les soudant afin de pouvoir les placer dans le boitier. Nous avons alors effectué divers tests d intensité et de puissance afin de voir combien de temps les batteries pourraient alimenter le circuit. L'intensité est mesurée grâce à un ampèremètre à induction. 71/101

Composant V I (A) P (W) Routeur au lancement 12 0,6 7,2 12 0,4 4,8 Enceintes à volume maximum 14,4 1,2 17,3 Enceintes à volume moyen 14,4 0,8 11,5 Microcontrôleur 5 0,1 0,5 Ecran 5 0,0025 0,0 Tuner Fm 5 0,1 0,5 Autonomie (heures) Puissance totale volume moyen 17,3 2,66 Puissance totale volume maximum 23,1 2,00 Routeur en fonctionnement stationnaire L autonomie obtenue même en maintenant le volume au maximum est de deux heures c est beaucoup plus que ce qui était espéré. Cela est du au fait que les puissances du routeur et des enceintes avait été surdimensionnées. Ainsi, il y a une marge au cas où il y aurait une surconsommation du routeur. En effet il faut faire attention à éviter toute rupture spontanée de courant dans le routeur car il est assez fragile. 72/101

Conclusion Ce module expérimental a permis la fabrication d un élément essentiel à la portabilité du modèle d Homer développé cette année. Une grosse partie du travail fut en fait de la recherche de composant et de l étude de manuel afin de trouver le circuit de charge adapté à notre système. Les commandes de composants et les différents mails dans les services techniques ont grandement ralenti l'avancement de ce ME mais nous avons malgré tout réussi à remplir notre objectif. Cela nous a permis de nous rendre compte de l'influence des paramètres extérieurs sur un projet et nous sera profitable dans notre future vie professionnelle. 73/101

Rapport ME Tuner Introduction Ce module expérimental s'inscrit dans le cadre de notre projet de deuxième année, le projet HOMeR (Home Media Opensource Media Receiver). Ce projet a pour but la réalisation d'un poste de radio hybride, capable à la fois de capter des radios diffusées sur le web en utilisant une borne WiFi, et des radios de la bande FM en utilisant un tuner FM. Dans cette optique, nous avons consacré notre ME à l'étude et à l'intégration d'un tuner FM (le Philips TEA5768HL) dans le poste de radio final. Nous nous intéresserons donc rapidement à la modulation de fréquence dans un aspect théorique, avant d'étudier le fonctionnement du tuner lui-même, et la réalisation d'une plaque test puis du circuit imprimé final pour le tuner. Enfin, nous aborderons le volet de la communication entre le microcontrôleur et le tuner, qui se fait avec le protocole I2C. 74/101

La modulation en fréquence Pourquoi moduler un signal? Les signaux que nous souhaitons transmettre entre un émetteur et un récepteur distants sont en général des signaux à basse fréquence (BF). Par exemple, l'oreille n'est sensible qu'aux fréquences approximativement comprises entre 50Hz et 20kHz : transmettre du son signifie donc transmettre un signal dont le spectre est entièrement situé en dessous de 20 khz. Or, outre le fait que si on transmettait ces signaux directement sans les moduler, nous les entendrions tous en même temps dans une véritable cacophonie en permanence, la réception d'un tel signal nécessiterait des antennes gigantesques. En effet, la taille d'une antenne pour recevoir un signal est de l'ordre de λ/2, ce qui donne une antenne d'environ 680 km pour recevoir la note «la» à 440 Hz. La solution à ces deux principaux problèmes se trouve dans la modulation du signal, c'est-à-dire sa transformation afin de le transmettre dans des fréquences beaucoup plus élevées, et avec surtout une fréquence donnée pour chaque signal transmis. Ce signal devra ensuite être démodulé afin de restituer le signal original. Comment moduler un signal? Formellement, il y a deux grandes manières de moduler les signaux : la modulation en amplitude (AM). Dans ce cas, c'est en étudiant l'amplitude du signal porteur qu'on peut reconstituer le signal original. Un signal modulé en amplitude La modulation en fréquence (FM), qui est la plus répandue. Cette fois-ci, l'information est transmise en modifiant la fréquence de la porteuse autour d'une fréquence moyenne. 75/101

Un signal modulé en fréquence La modulation en fréquence présente l'avantage non négligeable d'être insensible aux perturbations électromagnétiques. Celles-ci provoquent en effet des variations d'amplitude du signal, mais pas de sa fréquence : on obtient donc une meilleure qualité du signal reconstitué après démodulation. Chaque signal modulé est transmis par une onde porteuse de haute fréquence spécifique au signal. Par exemple, RTL2 dans la région valenciennoise est porté à 89,1 MHz, et seule cette radio est portée à cette fréquence dans cette zone de la France. L'État définit et gère et attribue les fréquences disponibles pour l'émission des radios sur le territoire, afin d'assurer le non chevauchement des signaux. Pour les radios modulées en fréquence, la bande de fréquences disponibles est comprise entre 87,5 et 108 MHz. Détail du principe de la modulation en fréquence HYPOTHÈSES On considère d'une part un signal s(t) à basse fréquence (BF) : il contient l information à transmettre (son, musique, voix ). D autre part, on considère un signal sinusoïdal à haute fréquence p(t). Ce second signal est couramment appelé porteuse. La porteuse est un signal de la forme Acos 2 f p t avec f p sa fréquence et A son amplitude. Elle va être modulée en fréquence pour donner le signal m(t), prêt à être transmis (par voie hertzienne par exemple). Posons les hypothèses suivantes : s(t) < 1 soit f la demie-largeur de la bande de fréquence mise à notre disposition pour 76/101

moduler le signal (aussi appelée incursion en fréquence, ou déviation en fréquence). On a en général : f p f On va chercher à créer un signal dont la fréquence instantanée est, à tout instant t : f t = f p s t. f et défini par : t m t = A cos 2. f d 0 CAS D'UN S I G N A L S I N U S O Ï DA L Posons s t =cos 2 f s t. Cela donne : t 0 t [ f f d = f p f. cos 2 f s d = f p sin 2 f s 2 f s 0 f = f p t sin 2 f s t 2 f s ] t 0 f D'où m t =A cos 2. f p t f sin 2 f s t s f On note m le rapport f, appelé indice de modulation. Le signal modulé s'écrit s alors : m t =A cos 2. f p t msin 2 f s t Illustration de la modulation en fréquence par un signal sinusoïdal G É N É R A L I S AT I O N D U C A S S I N U S O Ï DA L Tout signal réel s(t) pouvant être décomposé en série de Fourier, c'est à dire en une somme infinie de fonctions sinusoïdales, il suffit d'appliquer ce raisonnement à chacune des composantes de la série de Fourier pour obtenir la modulation de la 77/101

porteuse par un signal quelconque. La modulation de fréquence peut donc s'appliquer pour n'importe quel signal avant d'être transmis. Principe de fonctionnement du tuner Le tuner FM sert à démoduler un signal modulé en fréquence qui lui est transmis par une antenne. De manière générale, un récepteur radio se schématise de la façon suivante : L'antenne capte les ondes hertzienne et les convertit en oscillations électriques. Le signal ainsi créé est transmis au circuit LC qui a pour but de filtrer le signal et d'amplifier certaines fréquences par rapport à d'autres. Le signal entre ensuite dans un amplificateur de hautes fréquences (HF), puis dans le démodulateur avant d'être à nouveau amplifié dans les basses fréquences (pour le domaine de l'audible) avant d'être envoyé au haut-parleur qui restitue le son. Le tuner FM est donc le dispositif permettant de démoduler un signal pour en extraire un signal s(t). Le mot «tuner» désigne l'ensemble des circuits d'amplification HF et de démodulation : la partie amplification basse fréquence (BF) du schéma ci-dessus ne fait pas partie du tuner, de même que le circuit LC de sélection. Sur le diagramme en blocs qui schématise le tuner fourni dans la documentation de l'appareil on retrouve les deux parties du tuner vues dans le premier schéma : l'amplificateur HF et la démodulation (en rouge sur le schéma). On remarque dans ce diagramme l'antenne et le circuit LC à connecter au tuner (en bleu), ainsi que les sorties pour le signal démodulé (en violet). Sur ce diagramme, on voit également apparaître toute la partie qui permet de contrôler le tuner, c'est-à-dire la partie dédiée à la communication en I2C entre le 78/101

tuner et un autre composant (en vert). Dans le projet, cet autre composant sera un ordinateur pour des tests et, à terme, le microcontrôleur. Diagramme en blocs du tuner Après amplification du signal HF capté, deux étapes sont nécessaires à l'extraction du signal modulant intégré à une porteuse modulée en fréquence : - La première étape constitue une limitation en amplitude, permettant ainsi d'éliminer la majorité des parasites dus à la propagation : cette étape porte le nom de limiteur. - La seconde étape, appelée démodulation, réalise l'extraction du signal modulant. 79/101

Plaque Test et plaque finale La plaque test La plaque test avait déjà été réalisée l année dernière, mais nous l avons défaite puis refaite afin d être sûr que les problèmes de l an passé n étaient pas liés à un mauvais câblage. De plus nous avons ajouté les deux diodes varicaps qui leur manquaient. LES COMPOSANTS Il manquait à l équipe de l année dernière les diodes varicaps BB202 qu ils n avaient pas acheté car il fallait les acheter par 50, et cela coûtait cher. Grâce aux moyens qu on nous a alloué cette année, nous avons pu acheter ces varicaps (que nous avons trouvées vendues par 10) et les intégrer aux systèmes. Tous les autres composants pour la réalisation de la plaque test étaient bons et nous avons réutilisé les mêmes. 80/101

La plaque test ne peut supporter que des composants axiaux ou radiaux. Les composants en CMOS ont dû être intégrés à des plaques elles-même à connexion par fil ou axial. Pour le circuit intégré du Tuner, l ancienne équipe avait réalisé une plaque CMOS pour placer le tuner avec deux broches de 16 connexions en parallèle. De même, cette année nous avons dû intégrer les diodes varicaps, en technologie CMOS, au système. Pour cela, nous avons fait une plaque très simple permettant de souder chaque diode varicap à deux pistes, une pour l anode, une pour la cathode, elles-même reliées à un fil. Ainsi, nous avons deux fils anodes, et deux fils cathodes. C O M M U N I C AT I O N I2C Nous avons connecté la plaque test à l ordinateur via l USBee, et nous avons tenté de communiquer. Ce test est détaillé dans la suite du rapport. Le tuner envoie des accusés de réception en mode écriture, puis renvoie des données cohérentes en mode lecture. Ainsi nous avons pu voir que l I2C et la plaque fonctionnaient. LIMITE DE LA PLAQUE TEST Même si le tuner nous renvoyait des données cohérentes, il ne réussissait pas à capter une radio. Nous avons pensé que le problème était lié à l utilisation des fils rebouclés nécessaires à la réalisation de la plaque test : on ne peut pas, dans ces conditions, capter des ondes radios. Nous avons donc décidé de réaliser le circuit imprimé du tuner. Le circuit imprimé CAO ( C O N C E P T I O N A S S I S T É E PA R O R D I N AT E U R ) Nous avons tout d abord dessiné le circuit sur Orcad Capture en suivant la connectique donnée par Philips. De ce logiciel, on obtient un fichier.max qui nous donne les connections entre les différents composants. Ce fichier est réutilisé par Orcad Layout dans lequel on définit pour chaque composant virtuel un boitier 81/101

adéquat avec nos composants physiques. Schéma sur Orcad Layout Ensuite, il faut réaliser les pistes de connexions entre les divers composants afin qu ils soient tous reliés comme il faut en évitant de mettre deux pistes trop proches et en essayant de faire les pistes les plus larges possibles (afin d éviter les microcoupures et les pertes d informations à cause d une piste possédant une résistance interne trop importante). En général les pistes doivent avoir 8mm d épaisseur. Pour cela, il faut arranger les composants le plus judicieusement possible et retravailler chaque connexion. En faisant du double couche, on a la possibilité de réaliser des pistes sur le dessus (en bleu sur le schéma) et en dessous (en rouge sur le schéma). Sachant que chaque passage d une piste du dessous au dessus et du dessus au dessous nécessite un perçage de la plaque et une soudure, il faut isoler chacun de ces «ponts». R É A L I S AT I O N DE LA PLAQUE. Il faut imprimer sur deux feuilles transparentes les pistes du dessus sur l une et les 82/101

pistes du dessous sur l autre. On intègre une plaque vierge entre ces deux feuilles en s assurant que les pistes du recto et du verso se correspondent bien. Cette plaque vierge est composé de : - Un isolant au centre - Une fine plaque de cuivre de chaque côté - Un film protecteur réagissant aux UV sur chaque plaque de cuivre. On passe chaque côté de la plaque sous des rayons ultra-violets, ainsi le cuivre perd sa protection sauf là où les pistes imprimées sur les feuilles transparentes protègent le film. Ensuite on passe cette plaque dans un produit corrosif qui attaque le cuivre s'il n est pas protégé par du film protecteur. On repasse ensuite aux UV pour éliminer le film qui reste, et on a réalisé notre plaque. 1. Soudage des composants CMOS On colle ensuite chaque composant CMOS à son emplacement à l aide d un produit légèrement collant rempli de billes d étain. On passe la plaque dans un four : sous la chaleur, les billes vont éclater, puis attiré par le cuivre et par lui-même, l étain va se reformer autour des connexions des composants. On laisse refroidir puis on nettoie la plaque afin de supprimer toute bille d étain subsistant en dehors des pistes. Il faut aussi vérifier qu il n y a pas de court circuit réalisé par l étain entre deux pattes (surtout en ce qui concerne les pattes du circuit intégré central qui sont très rapprochées les unes des autres). 2. Perçage Il faut percer la plaque puis souder les 9 fils sortant du circuit, ainsi que les «gros» condensateurs polarisés, le quartz ainsi que chaque connexion entre les pistes du haut et les pistes du bas (pour faire le lien, on utilise des morceaux de patte de résistance). 83/101