P7 Régulation temps réel sur réseau sans fil
Sommaire
- 1 Régulation temps réel sur réseau sans fil
- 1.1 Présentation du projet
- 1.2 Avancement du projet
- 1.3 Matériel
- 1.3.1 Du 20/10 au 26/10/2016
- 1.3.2 Du 02/11 au 09/11/2016
- 1.3.3 Du 09/11 au 16/11/2016
- 1.3.4 Du 16/11 au 23/11/2016
- 1.3.5 Du 23/11 au 30/11/2016
- 1.3.6 Réunion du 30/11/2016
- 1.3.7 Du 30/11/ au 06/12/2016
- 1.3.8 Interaction STM32 et Module RF
- 1.3.9 Caractérisation du module radio
- 1.3.10 Intégration des différentes couches réseaux
- 1.3.11 Réunion 4 (non rédigé)
- 1.4 Liens bibliographiques et documents
- 1.5 Livrables
Régulation temps réel sur réseau sans fil
Présentation du projet
Les réseaux temps-réels réclament l'acheminement en temps contrôlé des données avec un grand niveau de confiance. L'utilisation de réseaux sans fil pose donc un grand problème dû à la difficulté d'être sur de la délivrance des données dans un temps borné.
Liste des tâches
Le projet consistera en :
- Recherche bibliographique sur les réseaux sans fils temps-réel,
- Implémentation d’un protocole de communication avec des notions temps-réel, soit à partir de la littérature (si possible), soit développé par nos soins.
Les différents algorithmes seront développés sur cartes de développement STM32F4 avec un lien radio de type Zigbee, La délivrance de l’information par lien radio étant sujette à risque, éventuellement modification de l’algorithme de commande pour résister à une perte plus ou moins sévère d’information en provenance des capteurs.
Planning prévisionnel
| Tâche | Date | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2016 | 2017 | ||||||||||||||||||||||||
| 19/09 | 26/09 | 03/10 | 10/10 | 17/10 | 24/10 | 31/10 | 07/11 | 14/11 | 21/11 | 28/11 | 05/12 | 12/12 | 19/12 | 26/12 | 02/01 | 09/01 | 16/01 | 23/01 | 30/01 | 06/02 | 13/02 | 20/02 | |||
| Recherche bibliographique sur les réseaux sans fils temps-réel | |||||||||||||||||||||||||
| Définition des problématiques et d'une application | |||||||||||||||||||||||||
| Recherches sur Riot, Contiki, RPL | |||||||||||||||||||||||||
| Choix de l'OS et implémentation sur les cartes STM32F4 | |||||||||||||||||||||||||
| 1er test : discussion entre 3 nœuds sans notions de temps-réel | |||||||||||||||||||||||||
| 2eme test : ajout d'un nœud pour ajouter une contrainte de routage (statique) | |||||||||||||||||||||||||
| Ajout des contraintes temps-réel (deadlines, priorités...) sans prendre en compte les fautes de transmission | |||||||||||||||||||||||||
| Prise en compte des fautes de transmission | |||||||||||||||||||||||||
Avancement du projet
Recherche bibliographique
La première phase de notre projet consiste à réaliser des recherches bibliographiques sur les réseaux sans fils temps-réel. Pour partager les résultats de ces recherches, nous avons choisi d'utiliser Google Drive : ainsi, nous pouvons à tout moment consulter les documents déjà trouvés sur internet, en déposer de nouveaux, et partager tout cela avec nos tuteurs école.Le but de ces recherches est, notamment, de répondre aux questions suivantes : - Existent-ils des réseaux sans fils temps-réel ? - Si oui, lesquels ? Quelles sont leurs limites ? Comment fonctionnent-ils ? - Si non, quelles sont les difficultés connues et que l'on peut rencontrer lorsqu'on souhaite mettre en place un tel réseau ?
Malheureusement, nous n'avons pas eu beaucoup de résultats, que ce soit sur Internet ou encore à la bibliothèque universitaire. Ceci est simplement du au fait que peu, voire aucun, travaux n'a été effectué sur ce sujet. Est-ce parce que les technologies actuellement existantes ne le permettent pas ou parce que l'apport d'une solution à ce problème n'apporte pas grand chose technologiquement parlant ? Le travail que nous réaliserons lors de ce projet permettra peut-être de répondre à cette question.
Suite à cela, nous avons décider de nous réunir avec nos tuteurs pour discuter un peu de ce sujet, puisque tout cela nous semblait un peu "vague".
Première réunion (05/10/2016)
Nous avons donc eu une première réunion avec Alexandre Boé (Thomas Vantroys n'étant pas disponible pour le créneau fixé). Nous lui avons présenté nos recherches et lui avons exposé nos difficultés à avoir des résultats, ce qui ne l'a pas surpris vu le sujet. Nous avons notamment discuté de la démarche à adopter sur ce projet : le but n'est pas de fournir un livrable fonctionnel à tout prix, mais plutôt de préciser le sujet, de tenter de traiter les problématiques une à une afin que notre travail puisse être repris par une autre personne à la fin du projet.
L'accent a également été porté sur l'aspect "gestion de projet", là encore pour que notre travail soit le plus clair possible. Il a ainsi été convenu qu'une réunion bimensuelle serait prévue afin de faire le point sur notre avancement. A la fin de chaque réunion, un compte-rendu sera établi. Ce dernier sera publié sur le Google Drive commun ainsi que sur le wiki.
Du 05/10 au 12/10/2016
Suite à cette première réunion, nous avons repris l'ensemble des documents que nous avions trouvés lors de nos recherches pour en lister les principales problématiques qu'il serait intéressant de traiter pendant ce projet. Trois problématiques ressortent de ces documents : - le routage : mettre en place un routage "complexe" : non-linéaire et dynamique - le type de temps-réel : doit-on mettre en place un temps-réel dur ? - Que faire en mode dégradé ? (cette question est liée à la problématique précédente)
D'autres questions pourraient être intéressantes à traiter comme la sécurité et la gestion de l'énergie. Toutefois, nous décidons de ne pas prendre en compte ces problématiques pour notre projet.
Nous avons également réfléchi à une application possible, assez simple : le but étant que celle-ci soit la vitrine de notre travail. Elle consisterait à allumer une lampe lorsqu'une personne est détecter dans la pièce.
Enfin, nous avons établi un premier calendrier prévisionnel que l'on peut retrouver plus haut dans cette page.
Jusqu'ici, nous avons travaillé ensemble, sans se répartir les tâches. En effet, il a fallu se mettre d'accord sur l'application, sur le calendrier pour pouvoir ensuite répartir les tâches et avancer efficacement.
Du 13/10 au 19/10/2016
Lors de la première réunion, nous avons décidé d'orienter nos recherches principalement sur deux systèmes d'exploitation : Contiki et Riot. Ce sont tous deux des OS très légers avec une faible empreinte mémoire. Ils présentent beaucoup de points communs, mais Contiki n'offre pas de support temps-réel. Nous avons également fait des recherches sur FreeRTOS, car cet OS temps-réel est proposé par l'aide au développememnt STM32CubeMX. Il est très simpliste, nous pourrons donc l'utiliser assez facilement, mais cela peut être un inconvénient : il ne convient peut-être pas à notre projet.
Le choix de l'OS sera discuté lors de la 2ème réunion avec nos encadrants.
Deuxième réunion (19/10/2016)
Lors de cette réunion, trois points ont été abordés : - Application choisie - Passage en revue du calendrier prévisionnel - Présentation des recherches et choix de l'OS
Après discussion, l'application a été jugée trop simpliste. Nous l'avons donc changer pour prendre celle-ci : commander un robot en ligne droite. Il y aura donc une notion de régulation et un vrai problème en cas de dégradation de la transmission des données (il devra continuer à avancer en ligne droite même s'il ne reçoit plus les ordres).
Comme nous le pensions, nous ne pourrons pas utiliser FreeRTOS, car il ne correspond pas à ce que l'on a besoin pour mener à terme ce projet. Nous avons donc opter l'OS Riot qui implémente le protocole RPL (protocole de routage particulièrement adapté aux réseaux de capteurs). Il nous faudra donc effectuer le portage radio : pour cela, nous choisissons de développer une carte électronique au lieu de modifier le driver d'une carte déjà existante (solution plus rapide à priori).
Enfin, notre calendrier prévisionnel a été jugé trop linéaire. En effet, nos tâches se suivent en cascade, alors qu'il faudrait réaliser plusieurs tâches en même temps afin d'être plus efficace. Nous ajouterons également un échelon supplémentaire à la première version de ce calendrier : la communication entre deux nœuds.
Matériel
Du 20/10 au 26/10/2016
Nous avons du commander très rapidement les composants nécessaires à la conception de notre carte électronique, la date limite de dépôt des bons de commandes étant normalement dépassée. En entendant la réception de ces composants, nous avons décidé de nous répartir les prochaines tâches afin d'être plus efficace. L'un d'entre nous avait alors pour mission de réaliser le routage de la carte, tandis que l'autre s'intéressait plus en détails au code source de RIOT OS en étudiant, par exemple, les exemples fournis avec le code et en tentant de trouver les informations qui nous seront utiles dans les nombreux fichiers de RIOT (comme par exemple le code source du protocole de routage dont nous aurons besoin par la suite). Pour prendre en main RIOT, nous avons décider de réaliser le programme qui permet de faire le classique "Hello World" : le but étant ici d'allumer une LED. Ce programme a été très simple à réaliser grâce aux fonctions que propose RIOT. Ensuite, nous avons décidé d'ajouter une étape supplémentaire : faire clignoter une LED à l'aide d'un timer pour que nous apprenions à nous servir de ce dernier (cela pourrait être utile pour la suite du projet).
Réalisation du module RF
Afin de permettre la liaison sans fils de nos nœuds, nous sommes amenés à utiliser des modules de communication sans fils. Maintenant que nous avons déterminé le micro kernel (Riot-OS) que nous souhaitions intégrer sur notre microcontrôleur, il nous a été conseillé de choisir un module compatible (C’est-à-dire que que le driver de la puce gérant la radiofréquence doit être intégré).Lors de la réunion, après une rapide études des différentes puces gérées, nous avons choisi l’AT86RF231 car il présentait, dans sa datasheet, un schematic simple et une BOM pour la réalisation du module radio.
Réalisation du schematic sous Eagle
Pour la réalisation de cette carte, nous avons commencé par dessiner, sur Eagle, les différents packages nécessaires. Une fois cela réalisé, nous avons constaté une erreur dans notre commande. Il s’agissait de l’oscillateur à 16 Mhz qui ne correspondait pas et dont l’utilisation était différente. C’est une erreur connue mais que l’on devra corriger. Malgré cela, le schematic a pu être réalisé en intégrant un package d’oscillateur commun. Ensuite, concernant les entrées/sorties numériques de la carte, nous avons respecté le schéma ci-dessus et avons ajouté une entrée d’alimentation 3,3V et la masse.
Du 02/11 au 09/11/2016
Réalisation du routage
La réalisation du routage est la partie la plus technique pour cette carte. Le tramsmetteur radio AT86RF231 envoie les données modulées via les pins RFP et RFN. La bande utilisée pour les liaisons Zigbee est à 2,45 GHz ce qui correspond aux hyperfréquences. C’est pourquoi le bloc ci-dessous, constitué d'une antenne, d'un balun et de deux condensateurs, doit être étudié et dimensionné.
Pour cela rappelons quelques éléments de bases nécessaires à notre étude :
*L’impédance d’entrée Ze d’un quadripôle est l’impédance équivalente qui, mise au borne d’un générateur, donne la même intensité et la même
tension.
*L’impédance de sortie Zs d’un quadripôle est l’impédance en série d’un générateur vu par la une résistance Ru en sortie.
*Le principe fondamental de l’adaptation d’impédance est le suivant : en connectant sur une charge de résistance R, une ligne de transmission
d'impédance caractéristique R, on retrouvera à l'autre extrémité de la ligne la même résistance R. Autrement dit, la source et la charge de
résistance R seront « adaptées » si la ligne qui les relie possède une impédance caractéristique de même valeur. L'adaptation sera conservée
quelle que soit la longueur de la ligne.
*L’impédance caractéristique est la résistance vue par le générateur aux premiers instants de la transmission. Elle dépend uniquement des
caractéristiques de la ligne.
*Le coefficient de réflexion est un nombre sans dimensions qui indique la quantité d'énergie réfléchie en bout ou en début de ligne. Il est
défini par une équation qui met en jeu l'impédance caractéristique de la ligne et l'impédance du bout de ligne ou du générateur. Il est
compris entre -1 et +1 et égal à 0 si la ligne est adaptée.
*Les feeders sont les lignes qui alimentent les antennes. Ils doivent véhiculer l'énergie de l'ampli final vers l'antenne dans le cas
d'émission, avec un minimum d'onde réfléchie. Ils doivent donc avoir comme valeur d'impédance caractéristique la valeur de l'impédance de
l'antenne.
L’antenne choisie est une antenne CMS et sera utilisée pour l’émission et la réception. Selon la datasheet, son impédance est de 50 Ohms et il de même pour l’impédance de sortie du balun. Pour adapter ces deux éléments, il nous faut une ligne d’impédance caractéristique 50 Ohms. Pour une ligne microstrip, l'impédance caractéristique dépend de ses dimensions et du matériau isolant. De nombreuse formules sont établies dans la littérature pour calculer cette impédance, nous avons choisi le modèle présent dans logiciel AppCAD.
Pour réaliser cette opération, il nous faut donc l’épaisseur t de la piste, l’épaisseur h du diélectrique ainsi que sa permittivité. A Polytech, il est possible de réaliser des cartes avec des pistes d'épaisseur 35 um avec un diélectrique verre-epoxy FR4 d'épaisseur 0,8 mm. Avec ces informations, nous trouvons une largeur de piste égale à 1,44 mm. Selon la datasheet, il était conseillé d’ajouter un guide d’onde coplanaire constitué de trous afin d'améliorer le transport de l'énergie jusqu'à l'antenne. De plus, l'ajout de vias permet d'atténuer l'effet capacitif des plans de masses situés de part et d'autres du diélectrique. Le rôle du balun est de transformer une impédance symétrique en impédance asymétrique et vice versa. Le balun réalise également une fonction d'adaptation d'impédance entre les ports RFP et RFN et l'antenne. Pour ne pas trop modifier l’impédance différentielle, nous avons décidé de réaliser des pistes de longueur faible et assez large mais surtout des lignes symétriques. Enfin les condensateurs à l'entrées des ports RFP/RFN sont utilisés pour supprimer la composante continue de l'entrée RF provenant de l'antenne.
La demande de réalisation de la carte a été réalisé le 17/11/2016.
Du 09/11 au 16/11/2016
Clignotement de LED grâce aux timers
Comme nous avons pu le dire, nous nous sommes lors de cette semaine sur l'utilisation des timers : le but étant de faire clignoter deux des quatre LED de la carte STM32F4 avec un temps de clignotement différent pour chacune (1 seconde pour la première et 0.5 seconde pour la seconde). Le clignotement se fait donc en mode interruption. Pour plus de clarté, nous avons décidé d'utiliser un timer pour chaque LED (bien qu'il soit possible de n'utiliser qu'un timer). Finalement, le programme est assez simpliste, mais il a fallu un certain temps avant de trouver et de maîtriser les différentes fonctions qui permettent de faire le travail.
PHOTO A VENIR !!!!
Mise en place d'un premier réseau utilisant RPL
N'ayant pas encore finalisé le portage radio (notre carte électronique n'étant pas prête), nous avons décidé de faire un premier test en mode native, c'est-à-dire que nous allons compiler RIOT et le faire tourner sur notre système en temps que processus. Le but de ce test est de mettre en place un réseau virtuel composé de 3 instances RIOT et qui implémente le protocole de routage RPL. Pour ce faire, nous avons utilisé l'exemple "gnrc_networking" fourni par RIOT qui permet, notamment, d'expérimenter la communication entre plusieurs instances RIOT.
Pour utiliser cet exemple, il faut d'abord créer 3 interfaces virtuelles tap (tap0, tap1 et tap2) ainsi qu'un bridge les connectant ensemble (tapbr0) : cela constitue un réseau virtuel que les instances RIOT pourront utiliser pour communiquer. RIOT propose un script qui permet de mettre en place cette configuration. Il suffit donc de taper la commande suivante :
$RIOT_PATH/dist/tools/tapsetup/tapsetup --create 3 (où RIOT_PATH correspond à la racine du dossier RIOT et 3 correspond au nombre d'interfaces souhaité)
Ensuite, nous compilons le code exemple "gnrc_networking" et nous ouvrons 2 autres terminaux (chaque terminal représentera un nœud du réseau). Dans chaque terminal, nous entrons la commande :
make term PORT=tap{0,1,2} (selon le terminal choisi)
Un shell RIOT se lance alors dans les trois terminaux. Il nous faut maintenant initialiser RPL. Nous choisissons le nœud tap0 comme nœud RPL root. Sur ce noeud, la commande ifconfig nous retourne :
ifconfig
Iface 6 HWaddr: 8e:c0:50:34:31:6c
MTU:1500 HL:64 RTR RTR_ADV
Source address length: 6
Link type: wired
inet6 addr: ff02::1/128 scope: local [multicast]
inet6 addr: fe80::8cc0:50ff:fe34:316c/64 scope: local
inet6 addr: ff02::1:ff34:316c/128 scope: local [multicast]
inet6 addr: ff02::2/128 scope: local [multicast]
inet6 addr: ff02::1a/128 scope: local [multicast]
Statistics for Layer 2
RX packets 0 bytes 0
TX packets 2 (Multicast: 2) bytes 142
TX succeeded 2 errors 0
Statistics for IPv6
RX packets 0 bytes 0
TX packets 2 (Multicast: 2) bytes 114
TX succeeded 2 errors 0
Pour ce noeud, nous configurons une adresse IPv6 globale :
> ifconfig 6 add 2001:db8::1 success: added 2001:db8::1/64 to interface 6
Nous pouvons maintenant utiliser la commander suivante dans les trois terminaux afin d'initialiser RPL :
> rpl init 6 successfully initialized RPL on interface 6
Comme nous avons pu le dire, c'est le nœud utilisant tap0 qui est le nœud root. Nous le définissons ainsi grâce à la commande :
> rpl root 1 2001:db8::1
Nous avons désormais la possibilité de voir la configuration du nœud grâce à la commande rpl. Par exemple, pour le nœud root, nous avons le retour suivant :
rpl
instance table: [X]
parent table: [ ] [ ] [ ]
instance [1 | Iface: 6 | mop: 2 | ocp: 0 | mhri: 256 | mri 0]
dodag [2001:db8::1 | R: 256 | OP: Router | PIO: on | CL: 0s | TR(I=[8,20], k=10, c=1, TC=80s, TI=196s)]
Pour un des deux autres nœuds, nous avons :
rpl
instance table: [X]
parent table: [X] [ ] [ ]
instance [1 | Iface: 6 | mop: 2 | ocp: 0 | mhri: 256 | mri 0]
dodag [2001:db8::1 | R: 512 | OP: Router | PIO: on | CL: 0s | TR(I=[8,20], k=10, c=2, TC=0s, TI=1s)]
parent [addr: fe80::8cc0:50ff:fe34:316c | rank: 256 | lifetime: 298s]
Nous avons donc construit un réseau virtuel implémentant le protocole de routage RPL, ce dernier comportant 1 nœud root et deux nœuds fils. Si on tente d'envoyer un message udp entre les deux fils par exemple, cela fonctionne. Cependant, si on supprime le nœud root, alors il n'est plus possible de communiquer entre les deux fils (ce qui est normal car le message devait d'abord passer par le root avant d'être redistribué au bon nœud).
Nous avons donc eu, grâce à cet exemple, une première approche de RPL. IL pourrait être intéressant d'implémenter une architecture différente (qui proposerait plusieurs routes possibles) afin de voir si on peut forcer un paquet à prendre telle ou telle route (ce qui nous aidera par la suite lorsqu'on souhaitera faire face à des problèmes de communications).
Du 16/11 au 23/11/2016
Lors de cette semaine, nous avons envoyé la demande de gravure de la carte au service électronique de l'école. Malheureusement, nous avons appris que la machine permettant de faire cela était en panne et que la carte ne pourra pas être réalisée tout de suite. Nous avons donc mis en place un calendrier jusqu'à la date de pré-soutenance qui tient compte de ce problème :
| Tâche | Date | ||||
|---|---|---|---|---|---|
| 2016 | |||||
| 23/11 | 30/11 | 06/12 | 08/12 | 11/12 | |
| Pilotage d'un servomoteur via RiotOS | |||||
| Programme de test communication module RF | |||||
| Etablir le cahier des charges de l'application finale | |||||
| Mettre en place le calendrier de janvier/février | |||||
| Soudage des cartes électroniques | |||||
| Préparation de la pré-soutenance | |||||
Du 23/11 au 30/11/2016
Nous avons mis en place un programme permettant de contrôler la vitesse des servomoteurs à notre disposition. Même si cette tâche semblait simple, nous avons eu quelques difficultés à trouver les bonnes fonctions et à bien les utiliser sous Riot.
Nous avons également élaborer le programme de test du module radio. Toutefois, nous avons un problème avec le retour série : nous ne parvenons pas à afficher les informations souhaitées à l'écran via le port série. Il nous faudra donc résoudre ce problème.
Le calendrier mis en place précédemment est pour le moment respecté.
Réunion du 30/11/2016
Lors de cette réunion, nous avons fait une mise au point sur l'avancement du projet. Conclusion : le projet avance normalement selon le calendrier. Nous avons exposé le fait que nous rencontrons quelques problèmes avec l'utilisation de RPL : nos tuteurs nous ont alors donné un contact qui pourra nous aider.
Nous avons également discuté sur les difficultés à réaliser la carte (machine en panne). Nous avons alors appris que la machine avait été changé et que la carte serait bientôt gravée. Nous en avons profité pour apporter quelques dernières améliorations avec l'aide de M. Boé.
Les objectifs fixés pour la pré-soutenance est cohérent avec ce qui a été fixé en début de projet et notre dernier calendrier permettra d'atteindre ces objectifs.
Du 30/11/ au 06/12/2016
Nous nous sommes penchés sur la communication sans fil entre deux cartes STM32F4discovery. Notre carte pour le module radio n'étant pas encore gravée, nous avons utilisé la communication via UART. Le but était le suivant : lorsque l'on appuie sur le User Button d'une des cartes, cela a pour effet de faire clignoter la carte réceptrice et de faire tourner le servomoteur. Nous sommes parvenus à trouver les bonnes fonctions sous Riot pour réaliser ce petit programme test.
Affichage du terminal disponible sous RIOT
L'avantage de RIOT est la mise en place d'un shell permettant d’interagir avec un microcontrôleur de manière assez intuitive. Pour cela les développeurs ont choisi d'utiliser un script python pour l'utilisation dans un terminal. Afin de pouvoir l'utiliser correctement, il est impératif d'avoir installé le paquet python2.7. Ensuite dans ./RIOT/dist/tools/pyterm lancer les commandes suivantes afin d'installer les autres paquets nécessaires au bon fonctionnement de ce script:
./setup.py build ./setup.py install
Ce sera ensuite le script pyterm présent dans ce même dossier qui sera lancé dans la commande make suivante:
sudo BOARD=stm32f4discovery make all flash term
par défaut, le DPI est défini sur /dev/ttyUSB0 si ce n'est pas le cas il faut modifier cela dans le fichier pyterm. De plus, on s'assurera de brancher les pins TX/RX aux pins PA2-3 de la stm32 configurées pour l'UART.
Interaction STM32 et Module RF
Le 15 et 16 décembre nous avions eu l'occasion de réaliser les soudures sur deux de nos cartes.
(photo)
Nous avons ensuite réaliser les différents tests suivants dès la rentrée au 3 janvier:
- Vérification de toutes les soudures et de la présence de court-circuit. Ces tests ont été effectués à l'aide d'un ohmètre afin de mesurer l'impédance entre les différentes pins. Le résultat de ce test a démontré un court-circuit au niveau des broches IRQ et XTAL2 placées perpendiculairement l'une de l'autre dans un coin de l'AT86RF231. Ce court-circuit est dû à une mauvaise gravure de la machine car le package de la puce était aux limites des capacités de celle-ci. Pour résoudre ce problème, il a fallu rompre ces court-circuits sur toutes les cartes.
- Vérification du fonctionnement de la carte via un programme de test. Le programme de test est intégré à RIOT et afin de tester l'interaction entre la carte STM32 et le module RF il suffit de modfier le fichier RIOT/drivers/at86rf2xx/include/at86rf2xx_params.h afin d'y indiquer les pins utilisés pour la communication.
#ifndef AT86RF2XX_PARAM_SPI #define AT86RF2XX_PARAM_SPI (SPI_0) // correspond au SP1 de la STM32F4 avec : SCK<->PA5 / MISO<->PA6 / MOSI<->PA7 #endif #ifndef AT86RF2XX_PARAM_SPI_SPEED #define AT86RF2XX_PARAM_SPI_SPEED (SPI_SPEED_5MHZ) // comme indiqué dans la datasheet ne pas dépasser 8MHz #endif // Choix arbitraire des pins correspondant à des GPIOs #ifndef AT86RF2XX_PARAM_CS #define AT86RF2XX_PARAM_CS (GPIO_PIN(PORT_D, 6)) #endif #ifndef AT86RF2XX_PARAM_INT #define AT86RF2XX_PARAM_INT (GPIO_PIN(PORT_E, 2)) #endif #ifndef AT86RF2XX_PARAM_SLEEP #define AT86RF2XX_PARAM_SLEEP (GPIO_PIN(PORT_D, 7)) #endif #ifndef AT86RF2XX_PARAM_RESET #define AT86RF2XX_PARAM_RESET (GPIO_PIN(PORT_D, 10)) #endif
Cependant à ce niveau les résultats du test étaient incohérents ( registres contenant l'ID constructeurs différents de la datasheet, valeur de la puissance de sortie à 65125 dBm...)
- Vérification des tensions au bornes des pins /RST, MISO et /SEL Les tensions correspondent aux niveaux indiqués de tension dans la datasheet (environ 1,8V).
- Vérification des oscillations au niveau du Quartz aux pins XTAL1-2 de l'AT86RF231. A ce niveau aucune oscillation n'est détectée.
Sur la datasheet, il est indiqué que l'on peut injecter un signal externe afin de faire fonctionner l'at86rf231. Pour effectuer ce test nous avons dessoudé au préalable le quartz présent sur la carte. Nous avons ensuite introduit un signal de 16MHz avec une amplitude entre 400 et 500 mV comme indiqué. Nous relançons ensuite notre programme de test et obtenons enfin des résultats cohérents.
(photo)
Le problème est donc enfin détecté et se situe au niveau du quartz qui n'arrive pas à osciller. Après plusieurs recherches sur les quartz et grâce à l'expertise de Mr Flamen, nous sommes arrivé à la conclusion que les pins indiquant les bornes du quartz sur la datasheet étaient erronées. En effet, les pins que nous utilisions au préalable, formaient un court-circuit entres-elles. Comme les quartz sont, en général, des matériaux isolants de type céramique, la résistance mesurée par l'ohmètre aurait dû être très grande. La réalisation d'une nouvelle carte a pu confirmer notre conclusion car nous sommes parvenu à observer les oscillations sur un oscilloscope, et obtenir des informations cohérentes grâce au programme de test. Nous avons donc pu au 17 janvier obtenir 3 modules RF fonctionnels.
Caractérisation du module radio
Intégration des différentes couches réseaux
Tout d'abord nous avions déjà eu un aperçu de l'intégration de couches réseaux avec notre programme de test qui permettait d'initialiser une adresse MAC à notre appareil. La communication était ensuite possible par adresse mac. La limite de cette communication est bien évidemment du point à point et ne permet pas de constituer de réseaux. Après quelques recherches, l'utilisation, dans RIOT, des différentes couches réseaux se réalise au mieux en utilisant la GNRC network stack.
Réunion 4 (non rédigé)
documenter les étapes pour faire fonctionner RIOT
caractériser le module radio (portée, consommation, etc) et l'antenne (bilan de puissance, voir pour récupérer TxPower)
Liens bibliographiques et documents
Recherches sur les travaux déjà existants liés aux réseaux sans fil temps-réel
Fichier:Proposition et validation formelle d'un protocole MAC temps reel pour reseaux de capteurs lineraires sans fils.pdf
Fichier:A Real-Time and Reliable Transport RT Protocol for Wireless Sensor and Actor Networks.pdf
Fichier:A Survey on Real-Time MAC Protocols in Wireless Sensor Networks.pdf
Fichier:SPEED A Stateless Protocol for Real-Time Communication.pdf
Recherches sur Contiki
http://www.contiki-os.org/
https://fr.wikipedia.org/wiki/Syst%C3%A8me_d%27exploitation_pour_capteur_en_r%C3%A9seau
Recherches sur Riot
Recherches sur FreeRTOS
https://www.freertos.org/
https://fr.wikipedia.org/wiki/FreeRTOS
Recherches sur RPL
http://www.ipso-alliance.org/wp-content/media/rpl.pdf https://fr.wikipedia.org/wiki/6LoWPAN
Livrables
Rapport de mi-parcours Fichier:Rapport mi parcours pfe7.pdf
