Différences

Ci-dessous, les différences entre deux révisions de la page.

--- diy:projets:transmissiondonneesled [2018/05/23 14:17] – sdurand
+++ diy:projets:transmissiondonneesled [2018/07/19 12:49] (Version actuelle) – [Bilan] sdurand
@@ Ligne 6: / Ligne 6: @@
 Dans l'idée, cela ressemble fortement au fonctionnement d'une **fibre optique, la vitesse en moins**. En effet, notre caméra
 peut délivrer dans sa plus faible résolution (640*480) un maximum de 90 images secondes. Soit un maximum de 90 bits par secondes
-théorique, soit environ **12 octets/s**. Autant vous dire tout de suite qu'on ne va pas s'amuser à transférer
+théorique, équivalent à un peu plus de **11 octets/s**. Autant vous dire tout de suite qu'on ne va pas s'amuser à transférer
-des images ou du son de cette manière, cela n'est pas réalisable (à moins de se contenter d'image d'une taille ridicule).
+des images ou du son de cette manière, cela n'est pas réalisable (à moins de se contenter d'images d'une taille ridicule).
 ===== Les objectifs =====
-Pour ce projet, **Gauthier Bouyjou** et moi même (**Sylvain Durand**) nous sommes répartis le travail en 2 parties: une **partie
+Pour ce projet, **Gauthier Bouyjou** et moi même (**Sylvain Durand**) nous sommes réparties le travail en deux: une **partie
 récepteur** (réalisée et expliquée par Gauthier) et une **partie émetteur** (réalisée et expliquée par moi-même).
 **Dans la partie émetteur**, on va développer une **interface permettant de contrôler une led** ou tout autre dispositif
-fonctionnant de la même façon. On utilisera ensuite cette interface pour modifier l'état d'une led suivant la valeur de chaque
+fonctionnant de la même façon. On utilisera ensuite cette interface pour modifier l'état d'une led en fonction de la valeur de chaque
-bit de chaque caractère à transmettre, suivant une certaine horloge.
+bit de chaque caractères à transmettre suivant une certaine horloge.
 **Dans la partie récepteur**, on va devoir créer un système permettant de localiser dans notre image la position de la led.
@@ Ligne 22: / Ligne 22: @@
 pour en observer l'état et reconstituer les octets transmis.
-Ces deux parties ont été réalisées en **C++**. Parmis les raisons qui nous ont poussées à choisir le C++, on peut
+Ces deux parties ont été réalisées en **C++**. Parmis les raisons qui nous ont poussées à choisir le C++, on a que:
-citer:
   * on va **travailler directement avec des bits**, le C++ permet d'y accéder sans difficultés
-  * on va tenter d'être aussi **précis** que possible,  nous voulons être certains que les **pauses** que nous utiliserons ne seront pas inutile.
+  * on va tenter d'être aussi **précis** que possible,  nous voulons être certains que les **pauses** que nous utiliserons ne seront pas inutiles. Autrement dit, on veut être certains que toutes les actions à effectuer entre deux pauses ne prendront pas **trop de temps**, on a donc une **contrainte de performance** inévitable si on veut **obtenir la meilleure précision que possible**.
-Autrement dit, on veut être certains que toutes les actions à effectuer entre deux pauses ne prendront pas **trop de temps**,
-on a donc une **contrainte de performances** inévitable si on veut **garder autant de précision que possible**.
-Je viens à l'instant de vous parler de **précision**, et en même temps, je vous ai parlé d'utiliser des pauses (pour gérer les
+Je viens à l'instant de vous parler de **précision** et en même temps, je vous ai parlé d'utiliser des pauses (pour gérer les
 temporisation). Certains d'entre vous trouveront sans doute ça contradictoire, à juste titre. En effet, les pauses
-n'offrent pas de précisions absolues. Pour parrer à cela, on aurait très bien pu utiliser
+n'offrent pas une précision absolue. Pour parrer à cela, on aurait très bien pu utiliser
 de **l'attente active**. Cependant, nous avons décidé d'un commun accord
-qu'il était sans doute mieux, pour éviter de carboniser les raspberry, d'utiliser des pauses. Nous comptons également sur
+qu'il était plus propre (même si moins efficace) d'utiliser des pauses. Nous comptons également sur
-une certaines régularité dans l'imprécision des pauses. Si toutes les pauses causent un décalage suffisamment
+une certaine régularité dans l'imprécision des pauses. Si toutes les pauses causent un décalage
 régulier, on ne devrait pas se hurter à trop de problèmes de **désynchronisation**.
@@ Ligne 59: / Ligne 56: @@
 {{:diy:projets:receptor.jpg?600|}}
 // Photo du même setup prise du côté du récepteur //
 ----
-//Auteurs: Gauthier Bouyjou/Sylvain Durand//
+===== Video de demonstration =====
+{{youtube>QNpdVOuzoTo?medium}}
+----
+===== Bilan =====
+Comme vous vous en êtez surement déjà rendu compte, les performances que permettent d'atteindre cette
+méthode de transmission sont **évidemment mauvaises**. On peut, si tout se passe bien, réussir à
+transmettre des messages complets sans erreurs, mais la précision des pauses (qui ne sont pas optimales) et
+l'**instabilité du framerate** de la caméra ne permettent pas de transmettre systématiquement des messages complets.
+De plus, nous n'avons **aucun moyen de synchroniser la caméra et la led**. Autrement dit, il arrive
+fréquemment que des messages entiers soient reçus en **"oppositions de phases"** et soient donc totalement
+incorrects.
+**Nous sommes cependant satisfait** d'avoir pu développer un ensemble émetteur/récepteur qui fonctionne,
+même si c'est **un système imparfait qui comporte des défauts**.
+----
+//Auteurs: Gauthier Bouyjou/S. Durand//