Notre objectif avec ce projet va être de réaliser du transport de données binaires par les clignotements d'une LED. 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, é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'images d'une taille ridicule).

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 en fonction de la valeur de chaque 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. Une fois la led localisée, on va regarder à intervalle de temps régulier la valeur du pixel où l'on a trouvé notre led 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 a que:

• 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 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.

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 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 plus propre (même si moins efficace) d'utiliser des pauses. Nous comptons également sur 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.

Comme décrit ci-dessus, le travail a été séparé en deux parties (émetteur/récepteur). Vous pouvez retrouver les explications relative à chacune de ces deux parties ci-dessous.

• partie émetteur

• partie récepteur

Photo du setup émetteur/récepteur prise du côté de l'émetteur

Photo du même setup prise du côté du récepteur

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