P12AB04 Conception mode communication temps réel sans fil modules recueil électroacoustique usage hospitalier

Client : M. Thierry Hassoun Société Echodia
Tuteur industriel : M. Pascal Fickinger
Tuteur technique : M. Jacques Laffont
Étudiants : Baptiste Soulier / Bertrand Verdier

1. Résumé
2. Abstract
3. Introduction
4. Présentation du Sujet
5. Cahier des Charges
6. Développement

1. Etude Théorique
2. Choix d'une Solution
3. Mise en Oeuvre

1. Matériel
2. Prise en main du Matériel
3.Sous Traitance
4. Développement Préliminaire et Tests
5. Implantation Finale

7. Gestion de Projet

1. Gantt

8. Notes d'application

9. Bilan

Mise à Jour : 05 Janvier 2013


Résumé

L'objectif de ce projet est de développer un système de communication sans fil pour un appareil de mesures médicales dans le domaine de l'ORL.
Dans sa configuration initiale, cet appareil comprend une unité centrale et des périphériques de mesure reliés à l'unité centrale par plusieurs fils.
L'entreprise ECHODIA désirant introduire son produit en milieu hospitalier a décidé, pour des raisons d'ergonomie et de stratégie marketing, de le faire fonctionner sans-fil.
L'objectif de notre projet est donc de transformer le produit existant pour le faire fonctionner en remplaçant les liaisons filaires entre l'unité centrale et les périphériques par une liaison sans-fil.
Cela implique préalablement:

- une phase d’analyse du fonctionnement de l’appareil et notamment des mesures prises en charges pour dégager les contraintes techniques qu’elles impliquent,
- une phase de rédaction du cahier des charges en collaboration avec le client,
- une phase de recherche de technologie compatible,
- une phase de conception et de proposition de solution.


Abstract

The purpose of this project is to develop a wireless communication for a medical device.
In its first version this device is composed of a central unit and measurement peripherals connected to the central unit with wires.
As the company ECHODIA wants to sell its product to medical centers such as hospitals in order to be used in surgical unit, she decided to propose a brand new version of its product: a wireless version.

Our job consist in developping this wireless version of the existing product.

In order to do so, we have to go through:

- an analysis phase, to learn how does the device work and how the measures are made,
- a phase of redaction of the specifications,
- a research phase, during which one we look for a compatible technology,
- and a conception phase.


Introduction

La société ECHODIA est une petite entreprise Clermontoise fondée en 2009 par Thierry Hassoun. Cette société, qui compte 7 employés, travaille dans la fabrication et la commercialisation d'appareils de mesures non invasifs dans le domaine de l'ORL.

On retrouve dans ce domaine différents types de mesures plus ou moins complexes telles que l'audiométrie (détection de surdité), la tympanométrie (détection d'otites), les potentiels évoqués et les otoémissions (détection de la maladie de Menière, détection de défauts sur le nerf auditif).

La société ECHODIA a créé un produit phare qui est l'ELIOS qui regroupe dans un seul et même boitier ces différentes mesures, ce qui le rend unique sur le marché Mondial.
Cet appareil se compose d'une unité centrale, qui se présente comme une petite tablette, et de divers périphériques de mesure qui se branchent sur l'unité centrale.

Figure 1:Présentation de l'ELIOS

Déjà bien répandu dans les cabinets médicaux ORL, ECHODIA souhaite introduire l'ELIOS en milieu hospitalier et plus précisément en bloc opératoire. Or, le nombre d'appareils en bloc opératoire est déjà très élevé et la majorité d'entre eux utilisent de nombreux fils. C'est donc dans le but de proposer une ergonomie optimale qu'ECHODIA a décidé de se placer sur une stratégie du sans-fil et donc de développer une nouvelle version de l'ELIOS dépourvue de liaison filaire entre l'unité centrale et les périphériques de mesure.

C'est ce travail qui nous est confié dans le cadre de notre projet GE:
"Concevoir un mode de communication sans-fil temps réel entre l'ELIOS et ses périphériques de mesure"


Présentation du Sujet

Principe de fonctionnement de l'ELIOS

L' ELIOS se décompose en deux parties:

- L'unité Centrale, qui se présente sous la forme d'un boitier ergonomique avec écran tactile.
- Les périphériques de mesure : des écouteurs, des sondes et des capteurs positionnés sur le patient.

Figure2 : Elios et périphériques

Objectif du projet

Le but de ce projet consiste à concevoir un système de communication sans fil entre l'unité centrale et les instruments de mesure . Le principe retenu pour y parvenir consiste à prévoir deux boitiers, l'un sur l'unité centrale et l'autre sur les périphériques.

Figure 3 : Principe de fonctionnement du projet


Cahier des Charges

Pour réaliser notre projet, nous avons dû définir un cahier des charges.
Ce cahier des charges a été établi en analysant les différentes contraintes auxquelles nous seront confrontés.
Ces contraintes sont :

- Techniques: liées aux caractéristiques des mesures réalisées par l'appareil,
- Technologiques: propres à la technologie sans fil que nous choisirons,
- Réglementaires: le produit étant destiné à un usage médical, il devra respecter les réglementations qui s'appliquent dans ce domaine,
- Mise en Oeuvre et Volonté du Client: choix spécifiés par le client.

Les contraintes techniques sont directement déduites des caractéristiques des mesures réalisées par l'appareil.
Le principe de ces mesures est de stimuler l'oreille du patient par un signal sonore et d'acquérir, par un ensemble de sondes, la "réponse" du patient (évolution du signal dans l'oreille et le cerveau).
Ces stimulations sonores, que nous appellerons par la suite des "Tops" ou des "Clics", sont produites de 1 à 20 fois par seconde. La réponse est quand à elle enregistrée sur 2048 points par un échantillonnage à 48kHz. Chaque point enregistré étant codé sur 16bits, l'acquisition totale représente 32768 bits. Tous ces bits devront donc être transmis via la liaison sans fils à l'unité centrale. Cela nous permet de déterminer différentes contraintes sur le débit de la liaison (vitesse de transfert) suivant plusieurs modes de transmission (par paquets, flux continu, flux continu moyenné).

Les contraintes technologiques concernent le choix de la technologie de sans fil à utiliser. Elles sont bien entendu liées aux contraintes techniques, puisque le critère principal sera le débit de la liaison, mais elles concernent aussi d'autres propriétés intrinsèques de la technologie comme le taux d'erreur, la portée et la consommation.

Les contraintes d'ordre réglementaire sont quant à elles propres au milieu médical et sont indiquées par des normes et directives Européennes.
Cette partie de validation réglementaire sera à la charge du client.

Les dernières contraintes que l'on retrouve sont liées aux volontés du client et concernent la réalisation du projet et la mise en oeuvre de la solution proposée.

Figure 4 : Cahier des Charges


Développement

Notre projet GE se déroule sur 2ans, une partie en GE2 et l'autre en GE3.

Au cours de l'année GE2 nous avons:

- pris connaissance de l'entreprise, du produit existant et des mesures réalisées,
- établi un cahier des charges en se basant sur nos observations et sur les attentes du client,
- réalisé une phase de recherche bibliographique sur les technologies sans fil existantes et leurs mises en oeuvre respectives,
- proposé une solution viable pour notre projet.

Au cours de l'année GE3 nous avons:

- Commandé le matériel nécessaire au développement (cartes de développement Xbee et µContrôleur)
- Pris en main ce matériel
- Supervisé la réalisation en sous traitance de cartes de connection Xbee
- Réalisé une phase de développement préliminaire
- Implanté la communication sans fil sur le matériel réel fourni par ECHODIA
- Mis en place un protocole de communication simple


Etude Théorique

Le plus gros du travail que nous avons réalisé en GE2 était de décrire un cahier des charges le plus précis possible et en accord avec les attentes du client.

Une des principales problématiques concernait les caractéristiques techniques liées aux mesures réalisées par l'ELIOS.
En effet, ces mesures doivent s'opérer avec une synchronisation précise et surtout déterministe: le temps entre l'émission du signal d’excitation de l'oreille ("Top") et le début de l'acquisition de la réponse doit être minimal mais surtout rester constant pour toutes les mesures. Or, cette synchronisation est très difficile à garantir en sans fil. C'est pourquoi nous avons décidé d'exporter une partie de l'intelligence de l'unité centrale vers le module sans fil côté périphériques. Cela permet de conserver la partie "gestion des mesures" déjà existante, et donc d'avoir les mêmes caractéristiques de synchronisation, et, qui plus est, cela permet de n'avoir sur la liaison sans fil que des échanges de données ou commandes sans forte contrainte temporelle.

Une autre problématique, elle aussi liée aux mesures, concerne la taille des données à échanger sur la liaison sans fil. Comme il a été vu précédemment (Cahier des Charges), les mesures imposent de transférer (pour chaque acquisition) 32768 bits. Il faut donc trouver une technologie de sans fil qui puisse supporter des débits plus ou moins importants suivant le mode de transmission:

- Emission par paquet
- Emission en flux continu

Les principes d'acquisition et de transfert dans les deux modes possibles sont présentés ci-dessous.

- En émission par paquet, la contrainte imposée sur le débit devient une contrainte forte très rapidement lorsque l'on réalise des mesures avec un nombre de tops/s élevé (>15). En effet, plus on a de tops/s moins on a de temps pour transmettre toujours la même quantité de données (32768bits) entre chaque top.

Figure 5 : Description de l'Emission par Paquet

- En émission en flux continu, étant donné que l'on n'attend plus d'avoir tous les bits acquis pour transmettre, la contrainte sur le débit est beaucoup moins forte et ce même lorsque l'on réalise des mesures à 20tops/s.

Figure 6 : Description de l'Emission en Flux Continu

- Une troisième possibilité s'offre à nous: l'envoi en flux continu avec un pré moyennage ce que permet de diminuer encore plus la contrainte en vitesse de transmission.

Figure 6 : Description de l'Emission en Flux Continu moyenné

Suivant le mode de transmission choisi et le nombre de tops/s, la contrainte sur le débit varie et le cahier des charges évolue permettant de sélectionner une ou plusieurs technologies :

Figure 7 : Courbes d'acceptation des technologies

Sur ce graphique on voit clairement, suivant le mode de transfert choisi, quelles sont les technologies admissibles ou non en terme de vitesse de transfert. Dans le mode de transfert en flux continu accompagné d'un moyennage, pratiquement toutes les technologies répertoriées proposent un débit acceptable. C'est donc ce mode de transfert (flux continu + moyenne) qui sera choisi.

Cependant, une exigence du client est d'avoir un affichage fluide des données sur l'écran de l'ELIOS, ce qui veut dire avoir le maximum de points à afficher et ce, en continu. Le moyennage devra donc être réalisé de façon dynamique: suivant la fréquence (tops/s) à laquelle la mesure sera réalisée, le nombre de points moyennés ne sera pas le même. Le protocole de communication à établir tiendra donc compte de la fréquence de la mesure demandée et ajustera de façon dynamique le moyennage pour conserver un affichage fluide. Dans la pratique ce moyennage sera ajusté de telle sorte que le débit nécessaire soit juste en dessous du débit maximal permis par la technologie choisie.


Choix d'une solution

Pour répondre au mieux au cahier des charges présenté ci-dessus, nous proposons une solution de mise en oeuvre basée sur la technologie Xbee fonctionnant sur le protocole Zigbee.

Figure 8 : Présentation du module Xbee

Caractéristiques principales de la technologie Xbee:

- bande 2.4GHz
- débit 250kbps
- portée de 30m ou plus selon version
- consommation 50mA en communication et <10µA au repos
- possibilité de réseau maillé
- prix maximal d'un module 55€

Les kits de développement Xbee du catalogue Matlog :

Figure 9 : Présentation et prix des kits de développement

Nous recommandons d'acheter le kit série 1 pro car c'est le plus complet, il contient plusieurs platines de développement ainsi que divers modules ce qui pourrait nous permettre de développer en parallèle.


Mise en Oeuvre

Cette partie présente le travail de mise en oeuvre de la solution choisie et les différentes étapes que nous avons suivi pour parvenir au résultat répondant au mieux au cahier des charges.


Matériel

Comme cela a été présenté ci-dessus nous avons proposé une solution basé sur la technologie sans fil Xbee.

Pour mettre en oeuvre cette solution, la société ECHODIA a mis notre disposition le matériel nécessaire.
- Deux kits de développement Xbee série 1 :

- 4 modules Xbee avec différentes antennes (planaire, filaire petite et grande)
- 2 platines support de module
- 2 câbles USB
- Logiciel XCTU de configuration et communication

Figure 10 : Kit de développement Xbee série 1

- Deux kits de développement µContrôleur LPC1769 (µContrôleur équipant l'ELIOS) :

- 2 platines de développement LPCXpresso avec processeur LPC1769 Cortex-M3 ARM
- 2 câbles USB et 2 debugger Coolink

Figure 11 : Kit de développement LPCXpresso LPC1769

- Une Unité Centrale ELIOS (UCE) accompagné de la "têtière" pour réaliser les mesures. Pour rappel, c'est la liaison filaire entre ces deux éléments que nous allons ici remplacer par la liaison sans fil Xbee.

Figure 12 : UCE Elios et sa têtière Echodiff pour la mesure


Prise en main du Matériel

Avant de démarrer la conception proprement dite, une phase de prise en main du matériel a été nécessaire. Nous avons tout d’abord appris à utiliser les modules Xbee du point de vue

- Emission : envoi de données, envoi de buffers, portée
- Réception : réception de données, de buffers, portée
- Configuration : association, liaison série, paramètres sans-fil,…

Nous nous sommes aussi familiarisés avec les outils liés aux microcontrôleurs LPC1769 Cortex-M3 ARM :

- Utilisation Générale (platines de développement et debugger)
- Logiciel Keil µVision4?: interface de développement
- Librairie CMSIS : ensemble de fonctions haut niveau facilitant la mise en œuvre des périphériques du LPC1769 (UARTs, GPIO,…).
- UART et GPIO : mise en œuvre de ces périphériques (configuration, utilisation)

Suite à ces manipulations, les modules Xbee ont été connectés aux UARTs des LPC1769. De nouveaux essais ont été réalisés :

- Émission / réception via UART
- Communication entre les 2 platines
- Paramétrage des modules Xbee
- Contrôle de flux via GPIO


Sous Traitance

Pour faciliter nos différentes phases de développement, nous avons fait réaliser deux cartes de support simples pour les modules Xbee.
Ce travail à été confié à un élève de GE2.
L'objectif était notamment de faciliter l'interconnexion des modules Xbee avec les platines de développement LPCXpresso du µContrôleur.

Figure 13 : Carte d’inter-connection réalisée en sous traitance

Développement Préliminaire et Tests

Après la première phase de prise en main du matériel, nous avons développé sur les platines de développement Xbee et µContrôleur les fonctionnalités utiles à la communication sans fil. Nous avons notamment établi la communication entre µcontrôleur et module Xbee en utilisant la liaison série et donc l'UART du µContrôleur.
Nous avons ensuite vérifié la communication sans fils entre deux entités (µContrôleur + module Xbee), en émission ainsi qu'en réception.
Un code à été développé pour paramétrer le module Xbee à partir du µContrôleur et non plus à partir du kit de développement Xbee. Ce code permet entre autres de configurer le débit de la liaison série du côté du module Xbee, de configurer le canal RF à utiliser, l'utilisation ou non du mode veille et du mode contrôle de flux,...
Enfin, nous avons aussi mis en place la fonctionnalité de contrôle de flux sur les liaisons séries afin de ne pas perdre de données lorsque les buffers d'émission et réception arrivent à saturation. Ce contrôle de flux à été mis en place de deux façons différentes: en logicielle avec une fonction de polling sur une broche GPIO reliée au signal CTS (Clear To Send) et en matérielle en connectant directement le signal CTS à la broche prévue sur l'UART du µContrôleur. En terme d'efficacité, les deux méthodes se valent. Nous avons développé ces deux façons de faire car toutes les UARTs ne possèdent pas forcément d'entrée CTS pour contrôle de flux matériel et d'autre part, il peut aussi arriver que cette broche même si elle est présente sur l'UART ne soit pas disponible car utilisée pour une autre fonctionnalité.

Durant cette phase de développement préliminaire nous avons également testé le matériel pour vérifier qu'il satisfasse bien les caractéristiques théoriques annoncées par le fabriquant et par conséquent pour vérifier qu'il soit capable de répondre au cahier des charges.
Nous avons dans un premier temps vérifier la liaison série qui relie le module Xbee au µContrôleur. Le but était ici de vérifier que le contrôle de flux fonctionne correctement (et donc pas de perte de données) et d'analyser l'impact de ce contrôle de flux sur la rapidité globale de la liaison série.

Pour rappel, le principe du contrôle de flux est le suivant: le µcontrôleur envoi les données au module Xbee via une liaison série configurée à 250kbps (un bit sur cette liaison aura donc toujours une durée de 4µs). Le module Xbee reçoit les données dans un buffer tampon de taille limitée (202 octets). Si ce buffer n'est pas vidé à la même vitesse qu'il est rempli, les données s'accumulent et au bout d'un certain temps le buffer est saturé (plein). A ce moment là, les données qui sont envoyée sur la liaison série ne pouvant plus entrer dans le buffer sont perdues. Pour remédier à ce problème, le module Xbee génère un signal CTS (Clear To Send) pour informer le µcontrôleur de l'état du buffer tampon (presque plein ou pas). Ainsi lorsque le buffer arrive à saturation, le signal CTS est mis à '1' et le µcontrôleur stop alors l'envoi de données sur la liaison série, laissant ainsi le temps au buffer d'être vidé de l'autre côté.

Figure 14 : Principe du contrôle de flux

Le premier test que nous avons réalisé concernait donc la liaison série et le contrôle de flux. Nous avons observé le comportement de ces derniers lors de l'envoi de buffers de taille croissante.
Voici ce que nous avons constaté: lors de l'envoi de buffers de petites taille, les données sont évacuées suffisamment rapidement du buffer pour qu'il ne soit jamais saturé, le CTS n'est jamais activé et on observe bien un débit de 250 kbps. En revanche, lorsque la taille des buffers commence à être importante, le CTS est activé à plusieurs reprises stoppant momentanément l'envoi de données sur la liaison. Ceci à pour effet de rallonger le temps de transmission des buffers et donc, globalement, de diminuer le débit de transmission (attention : on parle de débit global sur l'envoi complet d'un buffer, le débit de la liaison série est lui toujours fixe à 250 kbps : 1 bit dure toujours 4µs CTS actif ou pas). Finalement on observe que le buffer ne se vide pas aussi vite qu'il se rempli et comme le vidage est réalisé par la liaison RF, cela suggère que le débit de cette dernière n'est pas celui annoncé par le constructeur de 250 kbps. Le débit observé sur la liaison série semble plafonner à 90 kbps, ce qui serait l'image du débit réel de la liaison RF.

Figure 15 : Test de la liaison série et de l'impact du contrôle de flux sur le débit des transmissions

Dans un second temps, et pour confirmer les observations réalisées précédemment, nous avons testé la liaison RF pour connaître son débit réel. Pour cela nous avons réalisé ce que nous avons appelé le test "ping pong". Le principe est le suivant: nous disposons de deux modules (µcontrôleur + Xbee), le premier module envoi une commande au second lui demandant d'envoyer un certain nombre d'octets, le second module reçoit la commande et y répond en envoyant le bon nombre d'octets, à la réception des données, le premier module les recopies et les renvoi au second module, lorsque celui ci les reçoit il les stocke et les compare avec celles qu'il à envoyé pour détecter d'éventuelles erreurs.

Figure 16 : Test de la liaison RF (débit + nombres d'erreurs)

La mesure des temps t1 et t2 nous permettent d'avoir des informations sur les temps de traitement et surtout sur le débit de la liaison RF. Il est à noter que ce test à été réalisé dans un environnement perturbé avec plusieurs tours d'ordinateur, écrans cathodiques, PC portables, oscilloscope, avec une distance séparant les deux modules d'environ 3m et que nous n'avons à aucun moment détecté d'erreur sur les données transmises.

Nous avons observé les résultats suivants: lorsque la liaison n'est pas beaucoup sollicitée, que l'on envoi des buffers de petite taille, la liaison à un débit faible de 60 kbps. Plus la liaison est sollicitée, plus on envoi des buffers de grande taille, plus le débit s'accélère pour finalement plafonner à 90 kbps. On retrouve donc bien le résultat aperçu au cours du test précédent: le débit de la liaison RF n'est pas celui de 250 kbps annoncé par le fabricant mais seulement 90 kbps.

Figure 17 : Résultat du Test de la liaison RF

Pour expliquer ces résultats nous avons réalisé une recherche plus poussée sur le fonctionnement du Xbee et Mm El Rachkidy, professeur à l'université Blaise Pascal, nous a aidé à mieux comprendre cette différence entre débit théorique et débit observé sur la liaison Xbee.

Le débit 250kbps est le débit théorique du Xbee. En pratique, il n'est presque jamais atteint parce que le temps de traitement de données et celui d'injection (le temps de copier les données du µcontrôleur a la carte via UART) ne sont pas négligeables. De plus les entêtes des données ne sont pas des données utiles donc elles ne sont pas comptées dans le débit. Finalement, le Xbee introduit aussi des délais aléatoires (pour tester le canal, pour envoyer l'acquittement, etc.) qui réduisent le débit utile.

Avoir un débit de 90 kbps est déjà pas mal quand on a une seule carte émettrice. Ce débit augmenterai si nous avions plus de sources d'émission (tout en restant bien inférieur à 250 kbps).

Le changement de débit entre émission d'une trame courte et émission d'une trame longue est normal. En effet, avec une trame courte, on envoie plus d'entête que de données utiles par contre avec une trame longue pour le même nombre d'octets en entête on envoie plus de données. Ce qui rend le débit plus élevé.

La conclusion de ces deux tests est que nous avons une technologie qui à un débit de transmission inférieur à ce qui était prévu. La question est maintenant de savoir ce que l'on fait ?
Changeons nous de technologie ? Le projet est-il condamné à l'échec compte tenu du temps qu'il nous reste ?

Certes le débit n'est pas celui attendu, mais ce n'est pas si grave. Rappelons nous, nous avons choisi de réaliser la transmission des données en flux continu avec un pré moyennage. Nous avions au départ fait une simulation de débit nécessaire avec un pré moyennage sur 5 points, dans la pratique nous travaillons sur des systèmes numériques, le moyennage se fera sur des nombres de points multiples de 2 (4pts ou 8pts par exemple).

Figure 18 : Adaptation du pré moyennage au débit de la liaison RF

Finalement, la mise en place d'un pré moyennage dynamique en fonction de la fréquence de la mesure permettra de passer outre ce problème. Plus la fréquence de la mesure sera élevée plus le nombre de moyennage sera grand. Réaliser un pré moyennage n'est pas non plus gênant pour la mesure puisque avant l'affichage, les données sont déjà moyennées sur l'UCE, rajouter des moyennage en pré traitement n'est donc pas gênant.


Implantation Finale

Une fois le matériel bien pris en main, la phase de développement préliminaire et les divers tests réalisés, nous avons pu passer à l'implantation final sur le matériel réel.

Figure 19 : Schéma de l'implantation finale

Le schéma ci-dessus montre l'implantation finale. Le module UCE ELIOS est en fait composé de deux µcontrôleur, le LPC1769 qui est le µcontrôleur principal et le LPC1758 qui est dédié à la génération des stimulus audio. Le LPC1769 commande et cadence la génération des tops audio qui sont transmis aux oreilles du patient. L'oreille soumise à stimulation transforme le signal sonore en signal électrique conduit via le nerf auditif jusqu'au cerveau. Des électrodes de surface positionnées sur le front et derrière les oreilles du patient permettent de capter les signaux électriques du nerf auditif. Ces électrodes sont connectées au Convertisseur Analogique Numérique de l'ECHODIFF qui échantillonne la réponse électro-physiologique du patient. Les données échantillonnées sont alors transmises au µcontrôleur LPC1114 de l'ECHODIFF par un bus SPI. Après récupération des données sur le bus SPI, le µcontrôleur LPC114 les met en forme (passage 16 bits vers 8 bits) et les envoi au module Xbee via l'UART. Le module Xbee transmet en sans fil les données qui sont récupérées par le secon module Xbee connecté à l'UCE. Les données sont remises en forme et transmises à l'affichage.

Figure 20 : Schéma de l'implantation ECHODIFF

Figure 21 : Implantation réelle ECHODIFF

Du côté de l'ECHODIFF le travail d'implantation à consisté à porter les fonction écrites en pré développement sur µcontrôleur LPC1769 sur le µcontrôleur LPC1114 de l'ECHODIFF. Nous avons notamment porté les fonctions UART et GPIO pour le transfert sériel des données avec contrôle de flux, les fonctions de gestions de mode sleep, de formatage des données ainsi que de configuration Xbee et nous avons mis en place le bus SPI de façon hardware et software (CAN en mode master, µcontrôleur en mode slave, horloge de bus généré par le CAN,...).

Figure 22 : Schéma de l'implantation ELIOS

Figure 23 : Implantation réelle ELIOS

Du côté ELIOS, nous avons aussi porté les fonctions pré développées pour l'UART, nous avons configuré (hard et soft) le port UART et nous avons développé une fonction de reformatage des données. Il a aussi fallu modifier le code existant pour rediriger l'arrivé des données de mesures et leur passage à l'affichage.

La liaison filaire entre l'UCE ELIOS et l'ECHODIFF est conservée car elle conduit l'alimentation de l'ECHODIFF mais aussi une liaison I2C qui permet de charger les nouveaux firmware depuis la carte mémoire de l'UCE.

La communication sans fil entre les deux modules est aujourd'hui établie, l'ECHODIFF récupère bien les données de mesure et les transmet au module Xbee qui les envoi sans fil au second module Xbee relié à l'UCE. Les données sont bien reçues, remises en formes et passées à l'affichage et on observe bien en temps réel l'évolution des courbes sur l'écran.

Figure 24 : Dispositif Complet

Nous sommes à présent en train de mettre en place le pré moyennage dynamique avec un protocole de communication. Pour rappel, le pré moyennage intervient lorsque la fréquence de la mesure est élevée et que la quantité de données dévient trop importante pour le débit réel de la liaison sans fil. A ce moment là, nous analysons les paramètres de la mesure (fréquence, nombre d'échantillons,..) --d'où la nécessité d'un protocole de communication avec une liaison descendante de l'UCE-- pour calculer le moyennage dynamique (nombre de points moyennées).

Rappelons également le principe du pré moyennage:

Figure 25 : Description de l'Emission en Flux Continu moyenné


Gestion de Projet

Le tableau de Gantt ci-dessous présente l'organisation temporelle de notre projet.


Gantt

Légende:

- Bleu clair : travail réalisé en binôme (Bertrand & Baptiste)
- Jaune : Stage GE2 => projet en standby
- Vert : travail réalisé par le client ECHODIA
- Bleu foncé : travail en monôme ( Bertrand ou Baptiste)
- Violet : travail en monôme ( Baptiste ou Bertrand)

Ce diagramme de Gantt à été établie au début du projet. Dans les faits, peu de modifications ont eu lieu. Dans la phase de développement nous avions prévu un travail en parallèle qui a parfois été remplacé pour des raison de facilité et de mise en commun des connaissances par un travail en binôme.

En terme de gestion du temps, le diagramme présenté ci dessus, n'est aujourd'hui plus tout à fait respecté. En effet, suite à certains points de blocages à la fois logiciels et matériels que nous avons rencontré, nous accusons a ce jour un certain retard. La plus grosse partie du projet est réalisée et le dispositif fonctionne pour des fréquences de mesure basses. En revanche la partie, amélioration et perfectionnement est toujours en cours et il est possible que cette partie ne puisse être terminée. Nous estimons le temps de travail restant à environs 2 semaines.


Notes d'application

Configuration d'un module Xbee à partir d'un µcontrôleur : Baptiste Soulier

Xbee_configuration_from_µcontroller

La transmission sans fil,débit et temps de latence : Bertrand Verdier

transmission_sans_fil_debit_temps_latence

Bilan

Notre projet ECHODIA touche à sa fin. Depuis son début en Janvier 2012, nous avons appris beaucoup de choses, sur le projet lui même (programmation embarquée, technologies sans fil, design de cartes,...), mais aussi et surtout sur la gestion de projet (rédaction d'un cahier des charges, réunions avec le client, organisation prévisionnelle, commande de matériel, sous traitance, développement,...).

Notre réalisation est à ce jour pratiquement terminée, et en tenant compte du fait que ce fut notre première industrielle, notre premier projet, nous sommes plutôt satisfaits du déroulement global du projet.
Nous avons su travailler en équipe, mettre en commun nos connaissances et compétences pour permettre au projet d'avancer, nous avons su régler les points de blocage qui sont survenus et aujourd'hui nous avons des résultats à présenter au client.


Profitons de cette occasion pour remercier l'ensembles des personnes qui nous ont accompagnées dans ce projet :

- au sein de la société ECHODIA : M. Hassoun, M. Gérenton, M. Moura et M. Chartoire
- au sein de l'école Polytech Clermont Ferrand : M. Laffont, M. Sanchez, Mm El Rachkidy

Nous remercions particulièrement notre tuteur industriel, M. Fickinger (Michelin), pour toutes ses interventions, ses conseils et ses encouragements qui nous ont beaucoup fait progresser dans nos méthodes et dans notre travail.

P12AB04_echodia_20120516083330_20120516083357.jpg (27.7 KB) axel BARRIEUX, 04/09/2021 10:35 AM

P12AB04_Elios_20120516202852_20120516202949.jpg (43.2 KB) axel BARRIEUX, 04/09/2021 10:46 AM

P12AB04_UCE_20120516203111_20120516203140.jpg (15.9 KB) axel BARRIEUX, 04/09/2021 10:48 AM

P12AB04_Periph_20120425003054_20120425003231.png (21 KB) axel BARRIEUX, 04/09/2021 10:48 AM

P12AB04_name_20120425113128_20120425113238.jpg (9.92 KB) axel BARRIEUX, 04/09/2021 10:49 AM

P12AB04_principe_20121127093236_20121127111924.jpg (88 KB) axel BARRIEUX, 04/09/2021 10:50 AM

P12AB04_cdc_20120512121605_20120512121731.jpg (118 KB) axel BARRIEUX, 04/09/2021 10:51 AM

P12AB04_paquet_1top_20120516205629_20120516205704.jpg (43.5 KB) axel BARRIEUX, 04/09/2021 10:53 AM

P12AB04_paquet_20tops_20120516205629_20120516205722.jpg (43.9 KB) axel BARRIEUX, 04/09/2021 10:54 AM

P12AB04_flux_continu_20130105112959_20130105113110.jpg (42.7 KB) axel BARRIEUX, 04/09/2021 10:55 AM

P12AB04_flux_continu_moyenne_20130105112959_20130105113135.jpg (45.1 KB) axel BARRIEUX, 04/09/2021 10:56 AM

P12AB04_specifications_20120516081318_20120516081401.jpg (161 KB) axel BARRIEUX, 04/09/2021 10:57 AM

P12AB04_Xbee_20120517114305_20120517114346.jpg (22.1 KB) axel BARRIEUX, 04/09/2021 10:59 AM

P12AB04_kit_dev_prix_20120517115114_20120517115313.jpg (28.4 KB) axel BARRIEUX, 04/09/2021 11:00 AM

P12AB04_kit_dev1_20120517115114_20120517115201.jpg (16.6 KB) axel BARRIEUX, 04/09/2021 11:00 AM

P12AB04_Xbee_kit_20121127091532_20121127092055.png (107 KB) axel BARRIEUX, 04/09/2021 11:02 AM

P12AB04_LPC_kit_20121127091532_20121127092122.png (73.3 KB) axel BARRIEUX, 04/09/2021 11:03 AM

P12AB04_UCE_tetiere_20121127092737_20121127092749.jpg (35.1 KB) axel BARRIEUX, 04/09/2021 11:03 AM

P12AB04_lpc_connecte_module_20121127093236_20130103143824.jpg (30.7 KB) axel BARRIEUX, 04/09/2021 11:06 AM

P12AB04_CTS_20130105100837_20130105101004.jpg (13.4 KB) axel BARRIEUX, 04/09/2021 11:07 AM

P12AB04_test1_20130105102943_20130105103114.jpg (32.4 KB) axel BARRIEUX, 04/09/2021 11:08 AM

P12AB04_test2_20130105104025_20130105104319.jpg (27.8 KB) axel BARRIEUX, 04/09/2021 11:11 AM

P12AB04_test2_resultat_20130105105716_20130105105815.jpg (39.7 KB) axel BARRIEUX, 04/09/2021 11:12 AM

P12AB04_moyennagedynamique_20130105111827_20130105111937.jpg (52.3 KB) axel BARRIEUX, 04/09/2021 11:13 AM

P12AB04_implantation_finale_20130105114709_20130105114733.jpg (58.3 KB) axel BARRIEUX, 04/09/2021 11:16 AM

P12AB04_implantation_ECHODIFF_20130105122419_20130105122434.png (10.8 KB) axel BARRIEUX, 04/09/2021 11:17 AM

P12AB04_photo_echodiff_20130105125644_20130105131023.jpg (58.2 KB) axel BARRIEUX, 04/09/2021 11:18 AM

P12AB04_implantation_ELIOS_20130105123407_20130105123448.jpg (23 KB) axel BARRIEUX, 04/09/2021 11:19 AM

P12AB04_photo_ELIOS_20130105125644_20130105130754.jpg (35.3 KB) axel BARRIEUX, 04/09/2021 11:19 AM

P12AB04_dispositif_complet_20130105131523_20130105131906.jpg (126 KB) axel BARRIEUX, 04/09/2021 11:20 AM

P12AB04_flux_continu_moyenne_20130105112959_20130105113135.jpg (45.1 KB) axel BARRIEUX, 04/09/2021 11:21 AM

P12AB04_gantt_20120517131742_20120517131827.jpg (113 KB) axel BARRIEUX, 04/09/2021 11:22 AM

AN_P12AB04_1.pdf (980 KB) axel BARRIEUX, 04/09/2021 11:24 AM

AN_P12AB04_2.pdf (356 KB) axel BARRIEUX, 04/09/2021 11:25 AM