Projet capteurs : 2011 - Romain Bitschené et Philippe Virouleau : Différence entre versions

De Ensiwiki
Aller à : navigation, rechercher
Ligne 21 : Ligne 21 :
  
 
=== But ===
 
=== But ===
[[Fichier:projet_capteur_couches.png|right|thumb|upright=2|alt=Schéma en couche expliquant à quel niveau nous avons travaillé|Schéma en couche expliquant à quel niveau nous avons travaillé]]
+
[[Fichier:projet_capteur_couches.png|right|thumb|upright=2|alt=Schéma en couches expliquant à quel niveau nous avons travaillé|Schéma en couches expliquant à quel niveau nous avons travaillé]]
 
Les capteurs fournis peuvent être considérés comme vierge dans le sens où il n'y a rien d'autre présent dessus que quelques informations de configuration. Il est demandé à partir des outils libres énoncés plus haut, de la documentation disponible chez TI et des bibliothèques MRFI et BSP de créer un protocole permettant à ces capteurs de communiquer entre eux.
 
Les capteurs fournis peuvent être considérés comme vierge dans le sens où il n'y a rien d'autre présent dessus que quelques informations de configuration. Il est demandé à partir des outils libres énoncés plus haut, de la documentation disponible chez TI et des bibliothèques MRFI et BSP de créer un protocole permettant à ces capteurs de communiquer entre eux.
  
Ligne 31 : Ligne 31 :
  
 
Afin d'économiser les piles au maximum, on organise le cycle de vie des capteurs en périodes d'activité et d'inactivité. Tous les capteurs s'endorment et se réveillent en même temps, doivent s'annoncer dans le slot qui leur est attribué et ne pas émettre en dehors de la période d'activité.
 
Afin d'économiser les piles au maximum, on organise le cycle de vie des capteurs en périodes d'activité et d'inactivité. Tous les capteurs s'endorment et se réveillent en même temps, doivent s'annoncer dans le slot qui leur est attribué et ne pas émettre en dehors de la période d'activité.
 +
 +
On voit donc que deux aspects se dégagent : d'un côté la synchronisation, de l'autre le routage.
  
 
== Travail Réalisé ==
 
== Travail Réalisé ==
Ligne 36 : Ligne 38 :
  
 
=== Aspect routage ===
 
=== Aspect routage ===
 +
==== Table de routage ====
 +
Afin de pouvoir faire du relayage de packets il faut entretenir des tables de routage sur chacun des capteurs. Chaque capteur possède donc un tableau de structures pour représenter cette table.
 +
{| class="wikitable centre" width="40%"
 +
|+ Table de routage
 +
|-
 +
! width="33%" | Next Hop
 +
! width="33%" | Hops
 +
! width="34%" | Timeout
 +
|-
 +
|0x01
 +
|0
 +
|2
 +
|-
 +
|...
 +
|...
 +
|...
 +
|-
 +
|x
 +
|x
 +
|0
 +
|}
 +
Le champ timeout sert à indiquer qu'une route à expiré (timeout = 0). Next hop représente le noeud à qui s'addresser pour faire suivre le packet et hops le nombre de noeuds intermédiaires.
 +
 +
Cette table est propagée aux voisins périodiquement qui vérifient s'ils peuvent trouver une meilleure route que ce qu'ils possèdent actuellement. La table est envoyée dans un ou plusieurs packets avec le flag FROUTING.
 +
 +
==== Packet forwarding ====
 +
Pour indiquer qu'un packet doit être relayé il faut l'indiquer dans ses flags avec le flag FFORWARD, lever ce flag implique d'ajouter l'addresse de destination finale dans le premier octet de data. Un noeud qui reçoit un paquet FFORWARD peut le traiter de 2 manières :
 +
* Si la destination finale se trouve à proximité directe (hops = 0) alors on retire le flag FFORWARD, on remplace le champs destination du packet et on enlève l'adresse finale du data.
 +
* Sinon on remplace simplement l'adresse de destination par celle du noeud suivant dans la table.
 +
 +
=== Difficultés ===

Version du 9 juin 2011 à 14:11


AttentionPage en construction


Présentation du projet

Matériel

Le projet se déroule sur les kits de développement Texas Instruments eZ430-rf2500. Ces kits contiennent :

  • 2 capteurs équipés d'un microtrolleur basse consommation TI MSP430 et d'une radio CC2500 opérant dans la bande des 2.4Ghz
  • Une interface de développement USB
  • Un conteneur de piles pour alimenter un capteur de manière autonome

Logiciels

  • Linux (ou n'importe quel UNIX like)
  • Compilateur MSPGCC
  • Utilitaire MSPDEBUG
  • Bibliothèques MRFI (Minimal RF Interface) et BSP (Board Support Package) de TI.
  • Gestionnaire de versions GIT

But

Schéma en couches expliquant à quel niveau nous avons travaillé
Schéma en couches expliquant à quel niveau nous avons travaillé

Les capteurs fournis peuvent être considérés comme vierge dans le sens où il n'y a rien d'autre présent dessus que quelques informations de configuration. Il est demandé à partir des outils libres énoncés plus haut, de la documentation disponible chez TI et des bibliothèques MRFI et BSP de créer un protocole permettant à ces capteurs de communiquer entre eux.


Protocole imposé

Le schéma ci-dessous décrit le protocole imposé à suivre.

Protocol eZ430-RF2500.png

Afin d'économiser les piles au maximum, on organise le cycle de vie des capteurs en périodes d'activité et d'inactivité. Tous les capteurs s'endorment et se réveillent en même temps, doivent s'annoncer dans le slot qui leur est attribué et ne pas émettre en dehors de la période d'activité.

On voit donc que deux aspects se dégagent : d'un côté la synchronisation, de l'autre le routage.

Travail Réalisé

Aspect synchronisation

Aspect routage

Table de routage

Afin de pouvoir faire du relayage de packets il faut entretenir des tables de routage sur chacun des capteurs. Chaque capteur possède donc un tableau de structures pour représenter cette table.

Table de routage
Next Hop Hops Timeout
0x01 0 2
... ... ...
x x 0

Le champ timeout sert à indiquer qu'une route à expiré (timeout = 0). Next hop représente le noeud à qui s'addresser pour faire suivre le packet et hops le nombre de noeuds intermédiaires.

Cette table est propagée aux voisins périodiquement qui vérifient s'ils peuvent trouver une meilleure route que ce qu'ils possèdent actuellement. La table est envoyée dans un ou plusieurs packets avec le flag FROUTING.

Packet forwarding

Pour indiquer qu'un packet doit être relayé il faut l'indiquer dans ses flags avec le flag FFORWARD, lever ce flag implique d'ajouter l'addresse de destination finale dans le premier octet de data. Un noeud qui reçoit un paquet FFORWARD peut le traiter de 2 manières :

  • Si la destination finale se trouve à proximité directe (hops = 0) alors on retire le flag FFORWARD, on remplace le champs destination du packet et on enlève l'adresse finale du data.
  • Sinon on remplace simplement l'adresse de destination par celle du noeud suivant dans la table.

Difficultés