Conception et validation d’une architecture de noeud de capteurs pour l’évaluation hors ligne de stratégies de synchronisation 

Télécharger le fichier pdf d’un mémoire de fin d’études

Etalon de fréquence et oscillateur à quartz

Etalon atomique, TAI et UTC

Un étalon de fréquence est une source de fréquence stable et connue, permettant de mesu-rer le temps en comptant des oscillations. Il existe plusieurs étalons de fréquence permettant de compter le temps. L’étalon atomique est celui qui permet de définir la seconde (au sens unité de base du Système international). La seconde atomique est définie comme suit : « La se-conde est la durée de 9.192.631.770 périodes de la radiation correspondant à la transition entre les deux niveaux hyperfins de l’état fondamental de l’atome de Césium 133 » [24]. En 1971, le Temps Atomique International (TAI), calculé par le Bureau International de l’Heure (BIH) à partir d’horloges atomiques, est officiellement reconnu comme référence de temps lors de la 14ième conférence générale des poids et mesures [25]. D’un autre côté, l’échelle de temps his-toriquement utilisée pour la navigation est le Universal Time 1 (UT1), contrairement au TAI, cette échelle de temps est basée sur le jour solaire moyen (période de rotation de la terre au-tour de son axe, moyennée sur un an). Du fait des variations de la vitesse de rotation, le temps UT1 dérive vis-à-vis du temps TAI. Afin de garder une échelle de temps basée sur la rotation de la terre, l’échelle de temps UTC (mélange de Universal Coordinated Time et Temps Universel

Etalon de fréquence et oscillateur à quartz

Coordonné) est créée. Le UTC est basé sur le TAI mais avec des secondes intercalaires ajoutées ou retranchées pour le maintenir à moins d’une seconde du temps UT1. La dernière seconde in-tercalaire a été ajoutée le 31 décembre 2016. Actuellement le UTC est en retard de 37 secondes par rapport au TAI.
Le UTC United State Naval Observatory (USNO) est une échelle de temps maintenue par le USNO à l’aide de ses propres horloges atomiques pour le système GPS. Ce temps est synchronisé sur le temps UTC à 1 µs près. On appelle GPS System Time le temps global du système GPS. Il est géré par le Control Segment (CS) du système GPS [26] qui contrôle les horloges atomiques des satellites GPS. Ce temps est synchronisé sur le temps UTC(USNO) modulo une seconde pour pouvoir être uniforme (pas de secondes intercalaires à ajouter ou retirer). Le temps global GPS était identique au temps UTC(USNO) le 6 janvier 1980 à minuit. Aujourd’hui ils diffèrent de 18 secondes. Dans les spécifications du système GPS [26], l’erreur de déphasage entre UTC(USNO) et le temps global GPS doit être inférieure à 40 ns 95% du temps. Dans les faits, cette erreur est beaucoup plus basse. Sur l’année 2015, le 95e centile de l’erreur pour chaque mois était compris entre 1.026 ns et 2.571 ns [27]. Les satellites GPS transmettent le temps au format epoch constitué du nombre de secondes écoulées depuis le dernier dimanche à minuit et du nombre de semaines écoulées depuis le 6 janvier 1980. Les satellites GPS transmettent aussi le nombre de secondes intercalaires pour pouvoir synchroniser les récepteurs GPS au temps UTC(USNO). Dans la suite du document, les références à la version USNO du temps UTC seront implicites dès qu’il s’agit du système GPS.

L’Oscillateur à Quartz

L’étalon de fréquence le plus utilisé pour l’électronique embarquée est l’oscillateur à quartz. Les horloges basées sur les oscillateurs à quartz sont moins précises que les horloges atomiques, mais beaucoup moins onéreuses, moins encombrantes et moins énergivores. Le quartz (SiO 2) est une espèce minérale présente à l’état naturel sous forme de cristaux qui possède des pro-priétés piézoélectriques. Ces propriétés permettent au quartz de vibrer à une fréquence stable lorsqu’il est soumis à un signal électrique. Les oscillateurs sont composés d’une partie réso-nante (le cristal de quartz pour les oscillateurs à quartz) et d’une partie amplification permet-tant d’entretenir les oscillations.

Les oscillateurs à quartz présentent plusieurs sources d’erreurs [28]-[30]. La première source provient du cristal de quartz en lui-même. En effet, celui-ci peut être considéré comme un filtre très sélectif permettant d’obtenir une fréquence pure ; dans la réalité cette fréquence n’est pas « pure » et la sélectivité de l’oscillateur (aussi appelée facteur de qualité Q) dépend de la qualité et du dimensionnement du cristal. Les cristaux de quartz sont aussi sensibles à la température et leur fréquence évolue en fonction de celle-ci. Leur comportement en température dépend de l’angle de coupe du cristal. La coupe en diapason est plutôt utilisée pour les RTC (Real Time Clock) basses fréquence, leur dérive en fréquence est liée à la température par une fonction polynomiale de degré 2. Le cristal est souvent dimensionné de telle sorte que la fonction soit centrée sur 25 °C pour obtenir la fréquence théorique à 25 °C et s’en éloigner quand la tempéra-ture monte ou diminue. Les cristaux de quartz des oscillateurs plus haute fréquence (> 3 MHz) que l’on retrouve fréquemment pour cadencer les circuits numériques sont principalement de coupe dite « AT ». Pour cette coupe les dérives en fréquences sont liées à la température par une fonction polynomiale du troisième degré. Encore une fois, le point d’inflexion de la courbe est généralement placé à 25 °C pour obtenir la fréquence théorique de l’oscillateur à cette tem-pérature. De plus ce placement du point d’inflexion permet d’obtenir une zone plus ou moins affine entre 0 et 40 °C. La fréquence d’un oscillateur à quartz va aussi changer avec le vieillisse-ment du composant ; ce vieillissement entraîne un décalage de la fréquence compris entre 10 ppm et 0.01 ppm par an en fonction de la matière de l’enveloppe du cristal et de la qualité de la mise sous vide de celui-ci [28], [29]. D’autres phénomènes tels que les vibrations, les accélé-rations, la pression, l’humidité, ou le rayonnement électromagnétique peuvent aussi modifier la fréquence de l’oscillateur. Généralement on distingue deux familles de sources d’erreurs : le bruit de phase causé par la sélectivité de l’oscillateur et l’étage d’amplification ; la dérive en fréquence liée à l’environnement de l’oscillateur et plus principalement sa température.

Etalon de fréquence et oscillateur à quartz

Types d’oscillateurs à quartz

Différents types d’oscillateur à quartz, plus ou moins stables, plus ou moins cher et plus ou moins énergivores sont disponibles sur étagère [31]-[34] :
• XO (Crystal Oscillator) : Oscillateur à quartz. Ne comprend que le crystal de Quartz et pas l’étage d’amplification.
• SPXO (Simple packaged crystal oscillator) : Oscillateur à Quartz incluant le crystal et l’étage d’amplification dans le même package. Généralement plus stables que les XO car les deux parties de l’oscillateur sont intégrées dans le même composant.
• VCXO (Voltage Controlled Crystal Oscillator) : La fréquence d’un oscillateur à quartz est liée à la réactance du circuit. Il est ainsi possible d’ajuster la fréquence de l’oscillateur en modifiant la réactance du circuit (à l’aide par exemple d’une diode varicap). Plus la gamme de fréquence ajustable est grande plus le bruit de phase de l’oscillateur est grand. Comme le SPXO, le VCXO comprend un crystal de quartz et un étage d’amplification, mais il possède aussi un circuit permettant de faire varier la réactance pour ajuster la fréquence de l’oscillateur en fonction de la tension appliquée.

• TCXO (Temperature Compensated Crystal Oscillator) : Mêmes composants que le SPXO (quartz et amplificateur), mais une boucle de contrôle est ajoutée pour compenser les va-riations de fréquence en fonction de la température. Différentes techniques peuvent être appliquées, les plus simples sont entièrement analogiques et consistent en un circuit de régulation de la réactance en fonction de l’impédance de thermistances intégrées au cir-cuit. La méthode la plus précise consiste à numériser les variations de température puis à appliquer une tension calculée par un composant numérique (généralement un ASIC) à une diode varicap connectée à l’oscillateur. Cette méthode permet d’évaluer, pendant une phase de calibration, la fonction qui à la température associe la dérive en fréquence et donc d’enregistrer les coefficient de la fonction polynomiale caractérisant le plus pré-cisément les paramètres Δff = f(T emp) de chaque oscillateur.
• VCTCXO (Voltage Controlled Temperature Compensated Crystal Oscillator) : Même prin-cipe que le TCXO, mais avec une entrée permettant de faire varier la réactance en fonction de la tension appliquée pour ajuster la fréquence de l’oscillateur.

• MCXO (Microcontroller Compensated Crystal Oscillator) : L’idée est la même que pour les TCXO : compenser les dérives en fréquences en fonction de la température. Ces oscilla-teurs évaluent la température du quartz en fonction des différences d’évolution des modes harmoniques du quartz plutôt que par thermographie, ce qui permet d’avoir plus de pré-cision sur la température du quartz. Ils utilisent des coupes de quartz spécifiques (SC-Cut) permettant d’avoir deux modes simultanément. La fréquence est ensuite ajustée numé-riquement soit en pilotant le quartz (toujours à l’aide de la réactance) soit en utilisant un synthétiseur de fréquence. Ces oscillateurs sont plus précis, mais plus coûteux que les TCXO.
• OCXO (Oven Controlled Crystal Oscillator) : Ici l’oscillateur est enfermé dans un four contrôlé pour maintenir une température constante, ainsi l’oscillateur n’est pas sujet aux varia-tions de températures. Ces oscillateurs sont plus précis que les TCXO et les MCXO, mais plus énergivores et plus coûteux.
• DOCXO (Double Oven Controlled Crystal Oscillator) : Même principe que l’OCXO, mais avec un double four pour que la température soit encore plus constante. Plus précis, mais plus coûteux et plus énergivore qu’un OCXO.
• VCOCXO (Voltage Controlled Oven Controlled Oscillator) : Même principe que l’OCXO, mais avec une entrée permettant de faire varier la réactance en fonction de la tension appliquée pour ajuster la fréquence de l’oscillateur.

Synchronisation des noeuds de capteurs

Les horloges locales des noeuds de capteurs dérivent différemment les unes des autres du fait des imperfections des oscillateurs énumérées précédemment. Ainsi, pour pouvoir main-tenir une référence de temps commune aux noeuds de capteurs du réseau, ceux-ci ont besoin d’être synchronisés de manière périodique. Cette référence de temps peut être une référence externe au réseau et commune à tous les noeuds tels que le temps UTC propagé par les sa-tellites des systèmes de géolocalisations si tous les noeuds sont équipés d’un récepteur GNSS (Géolocalisation et Navigation par un Système de Satellites). Cette référence peut aussi être ex-terne et propagée au sein du réseau par un ou plusieurs noeuds équipés de récepteurs GNSS les autres noeuds doivent alors se synchroniser au(x) noeud(s) référent(s) à l’aide d’un protocole de communication RF. Enfin la source de synchronisation peut être interne au réseau, dans ce cas elle peut être l’horloge locale d’un des noeuds du réseau ou de plusieurs noeuds du réseau si un système de consensus est utilisé. Les noeuds se synchronisent entre eux, là encore, à l’aide d’un protocole de communication RF.

La synchronisation dans les systèmes distribués a tout d’abord été formalisée par Lamport [35]. Depuis, de nombreuses solutions ont vu le jour pour résoudre ce problème dans les ré-seaux filaires. Le Network Time Protocol (NTP) à été développé par Mills [36] [37] (dernière version [38]) afin de fournir une solution de synchronisation universelle pour synchroniser les horloges locales d’ordinateurs via internet. Le Precision Time Protocol (PTP) a ensuite été créé, puis normalisé sous la norme IEEE 1588 (dernière version [39]), afin d’améliorer la précision de synchronisation du NTP. Les versions actuelles du NTP et du PTP sont les standards de facto sur les machines connectées à internet, elles permettent une précision de synchronisation sous la microseconde, jusqu’à 100 ns suivant les implémentations. Une extension du PTP, le projet white rabbit [6][40] (intégré dans la version 2019 de la norme IEEE 1588) développé par le CERN pour ses équipements scientifiques permet d’atteindre une précision de synchronisation sous la nanoseconde. Ces protocoles sont cependant peu adaptés aux noeuds de capteurs sans-fil qui disposent de ressources matérielles moindres, doivent limiter leur utilisation d’énergie et n’utilisent pas les mêmes topologies de réseau [41].

Synchronisation sans-fil par échanges de paquets

Afin de pallier les inconvénients des protocoles NTP et PTP Elson et al ont développé le Reference Broadcast Synchronization (RBS) [1] spécifiquement conçu pour la synchronisation des noeuds de capteurs. Ganeriwal et al présentent eux aussi une solution spécialisée pour la synchronisation des noeuds de capteurs : Timing-sync Protocol for Sensor Networks (TPSN) [2]. Ces deux protocoles de synchronisations se basent sur l’échange de paquets horodatés entre les noeuds de capteurs pour synchroniser le réseau. Les noeuds qui ne sont pas à portée du noeud « origine » de la synchronisation sont progressivement synchronisés à mesure que la synchroni-sation se diffuse dans le réseau par sauts. Ces sauts correspondent aux passages par des noeuds intermédiaires pour que les noeuds situés aux extrémités du réseau (par rapport au noeud « ori-gine ») puissent être synchronisés. Ces échanges de paquets sont sujets à de nombreux délais déterministes et stochastiques qui diminuent la précision de la synchronisation. Ces délais ont été formalisés par Kopetz and Ochsenreiter dans [42] et étendus dans [2] et [3]. La figure 2.3 tirée de [2] représente ces délais, ils sont les suivants :
1. Temps d’envoi : Temps nécessaire à l’assemblage du message et à l’envoi de la demande d’émission à la couche MAC du côté émetteur. Ce délai dépend de l’architecture et de l’OS/-logiciel du noeud de capteur. Généralement il n’est pas déterministe, car il dépend des délais d’interruption et de traitement de l’OS/logiciel utilisé sur le noeud de capteurs.
2. Temps d’accès : Temps d’attente pour l’accès au canal de transmission. Non déterministe, car il dépend du trafic réseau.
3. Temps de transmission : Temps nécessaire à l’émetteur radio pour transmettre les bits du message. Ce délai dépend de la vitesse de transmission de la radio ainsi que de la longueur du message. Il est déterministe.
4. Temps de propagation : Temps de propagation du message sous forme d’onde électroma-gnétique entre l’émetteur et le récepteur. Ce temps est déterministe en théorie, mais dans la pratique l’environnement des noeuds et les obstacles physiques potentiellement pré-sents entre l’émetteur et le récepteur affectent le temps de propagation.
5. Temps de réception : Temps nécessaire au récepteur radio pour récupérer les bits du mes-sage et les transmettre à la couche MAC. Ce temps est déterministe.
6. Temps d’horodatage : Temps nécessaire au paquet pour remonter de la couhe MAC à la couche application du noeud pour être déchiffré et horodaté. Comme le temps d’envoi, ce délai n’est pas déterministe car il dépend des délais d’interruption et de traitement de l’OS/logiciel utilisé sur le noeud de capteurs.

La distinction entre les erreurs déterministes et non déterministes est importante car les erreurs déterministes peuvent souvent être éliminées si elles sont identiques sur deux noeuds ce qui est le cas lorsque celles-ci sont générées par un matériel radio identique (au sens même référence de composants) sur les deux noeuds. Pour supprimer une partie de ces erreurs plu-sieurs stratégies d’échanges de messages sont possibles. Dans l’échange bidirectionnel, déve-loppé dans [2], le noeud à synchroniser envoi un message horodaté à la référence qui horodate l’arrivée de ce message et renvoie un message horodaté contenant les deux autres horoda-tages. En horodatant l’arrivée de la réponse, le récepteur possède quatre horodatages qui lui permettent de calculer le déphasage de son horloge par rapport à l’horloge de référence en éli-minant le temps de propagation (en partant du principe que celui-ci est symétrique) et en diminuant les temps de réception et de transmission du fait de leur soustraction. Dans l’échange entre récepteurs, développé dans [1], un noeud tierce diffuse un message non horodaté à tous les récepteurs en même temps. Ces derniers horodatent l’arrivée du message et s’échangent ensuite les horodatages pour calculer leur déphasage. Ce mécanisme permet de supprimer les temps d’envoi, d’accès et de transmission. Dans [43] et [2] l’horodatage au niveau de la couche MAC est proposé pour diminuer les erreurs d’envoi et de temps d’accès. L’horodatage au ni-veau de la couche MAC consiste à déplacer la génération et l’encapsulation de l’horodatage, de la couche application à la couche MAC, pour être le plus près possible de la transmission du message.

Cette technique n’est pas applicable sur tous les émetteurs-récepteurs radio. Maroti et al ont décrit le Flooding Time Synchronisation Protocol dans [3], basé sur la synchronisation expéditeur à récepteur, comme TPSN, pour ajouter de la robustesse aux défaillances de noeuds ou de liaisons entre les noeuds. Contrairement à TPSN qui est basé sur une topologie en arbre et découvre le réseau lors d’une phase spécifique avec un protocole STP (Spanning Tree Protocol), FTSP est basé sur une topologie maillée avec un mécanisme d’élection périodique du noeud de référence. Dans le protocol FTSP, la synchronisation s’effectue par diffusion en partant de la référence. Celle-ci diffuse un paquet qu’elle horodate à l’aide de son horloge locale. Tous les noeuds à portée reçoivent le paquet et horodatent l’arrivée de celui-ci avec leur propre hor-loge locale. En faisant la différence entre les deux horodatages, les noeuds récepteurs peuvent calculer le déphasage de leur horloge avec celle du noeud émetteur et ainsi se synchroniser à celle-ci. Une fois les noeuds synchronisés ils diffusent à leur tour les messages de synchroni-sation pour les diffuser dans le réseau. De plus, le protocole FTSP est le premier à introduire un mécanisme pour réduire les erreurs d’interruptions en utilisant plusieurs horodatages par paquets.

Synchronisation avec les normes IEEE 802.11 et IEEE 802.15.4

D’autres approches pour la synchronisation de noeuds se basent sur des normes déjà exis-tantes telles que les normes IEEE 802.11 (WiFi) pour les réseaux sans fils locaux [55] ou IEEE 802.15.4 [56] pour les LRWPAN (Low Rate Wireless Personal Area Network), qui définissent des spécifications pour la couche physique et la couche MAC. Mahmood et al comparent plusieurs implémentations de protocoles de synchronisation conformes à la norme IEEE 802.11 ou uti-lisant un émetteur-récepteur conforme à la norme IEEE 802.11b dans [57]. Les mécanismes de synchronisations conformes à la norme 802.11 sont la TSF (Timing Synchronization Function), la TM (Timing Measurement), et la TA (Timing Advertisement). La TSF et la TM sont basées sur la diffusion de messages horodatés par le point d’accès en mode infrastructure. La TM est ba-sée sur un échanges bidirectionnel entre les stations en mode ad-Hoc. L’implémentation de la TSF permet une erreur de synchronisation moyenne de 4 µs avec un écart-type inférieur à 1 µs tandis que l’implémentation de la TA permet d’obtenir une erreur moyenne de 0.5 µs avec un écart-type de 2.5 µs [57], [58]. Le PTP (IEEE 1588) a été implémenté avec un chip radio 802.11b dans [59]-[62] sur des ordinateurs sous Windows et Linux et sur des FPGA. L’implémentation sur FPGA permet l’horodatage dans les couches basses tandis que les versions sur Windows et Linux doivent se contenter des compteurs et interruptions proposés par les systèmes d’ex-ploitation. Les versions avec horodatage matériel (FPGA) permettent d’atteindre des erreurs de synchronisation de l’ordre de la nanoseconde tandis que les versions purement logicielles sont de l’ordre de la microseconde. Exel et al [4] proposent une amélioration de la version horodatage matériel en prenant en considération les délais sur la chouche physique. Leur solu-tion permet une erreur de synchronisation inférieure à la nanoseconde avec 240 ps d’erreur moyenne et 531 ps d’écart-type. Similairement dans [63], Mahmood et al améliorent la version logicielle sous Linux en prenant en compte les délais d’interruptions ainsi que les délais déter-ministes du chip radio. Leur solution permet une erreur de synchronisation moyenne de 59 ns avec un écart-type de 0.46 µs.

Le NTP a été implémenté avec la norme IEEE 802.11 dans [64] de manière purement logicielle. Leur implémentation permet une erreur de synchronisation de l’ordre de la milliseconde. L’implémentation décrite dans [65] permet une amélioration de la synchronisation avec une erreur moyenne de 0.5 ms (écart-type de 5.27µs) en implémentant l’horodatage au niveau driver. Dans [66], une implémentation logicielle du protocole de syn-chronisation RBS avec la norme IEEE 802.11 permet d’atteindre une erreur de synchronisation moyenne de 0.2 µs avec un écart-type de 0.18 µs. Ces méthodes de synchronisation permettent une meilleure précision que les protocoles par échange de paquets décrits précédemment au coût d’une implémentation plus complexe nécessitant un chip radio IEEE 802.11, du matériel capable de supporter les piles logicielles pour le 802.11 et un FPGA pour les implémentations avec horodatage matériel.
La norme IEEE 802.15.4 est plus adaptée aux réseaux de noeuds de capteurs du fait de son implémentation moins complexe et de sa plus faible consommation énergétique. Cependant le débit de données de 250 kbits/s est moins important que les débits atteignables par cer-taines spécifications de la norme IEEE 802.11. Dans [67] une implémentation de cette norme est utilisée et l’interférence constructive est exploitée pour synchroniser les noeuds de cap-teurs. Leur protocole de synchronisation permet une synchronisation du réseau plus rapide que le FTSP [3] et le protocole PulseSync [68] avec une erreur de synchronisation de l’ordre des microsecondes après huits sauts. Dans [69] le protocole FTSP est utilisé avec le protocole de communication ZigBee (lui-même basé sur une implémentation IEEE 802.15.4 auquel il ajoute des couches de plus haut niveau) avec une erreur de synchronisation maximale de 61 µs. L’uti-lisation de la technologie UWB (Ultra Wide Band) dans la couche physique a été intégré dans la version 2011 de la norme 802.15.4. Les systèmes UWB à impulsions courtes, ou Impulse Radio Ultra Wide Band (IR UWB), sont particulièrement adaptés à la géolocalisation et à la synchro-nisation du fait de l’estimation plus aisée du temps de vol des impulsions [70]-[72].

Beluch et al utilisent la modulation IR UWB avec un schème CLD (Cross Layer Design [73]) pour propager la synchronisation dans un réseau a topologie en arbre dans [5]. Leur solution permet d’at-teindre une erreur moyenne de 374 ps entre deux noeuds avec un écart-type de 677 ps. Dans [74], un protocole de synchronisation par consensus est développé pour les réseaux communi-cants en UWB. Une implémentation de leur protocole est testée dans [75] et obtient une erreur de synchronization moyenne de l’ordre de la nanoseconde avec un écart-type de 3 nanose-condes. L’utilisation de l’UWB pour les couches basses de l’IEEE 802.15.4 permet d’obtenir des erreurs de synchronisation du même ordre de grandeur que les implémentations du PTP IEEE 802.11 avec une complexité réduite et une plus faible consommation d’énergie mais la portée des communications est plus faible.

Table des matières

Liste des tableaux
1 Introduction 
2 Contrôle de santé des structures et réseaux de capteurs 
2.1 Contrôle de santé des structures
2.1.1 Définition
2.1.2 Exemples industriels
2.1.3 Les réseaux de capteurs sans fil
2.2 Etalon de fréquence et oscillateur à quartz
2.2.1 Etalon atomique, TAI et UTC
2.2.2 L’Oscillateur à Quartz
2.2.3 Types d’oscillateurs à quartz
2.3 Synchronisation des noeuds de capteurs
2.3.1 Synchronisation sans-fil par échanges de paquets
2.3.2 Synchronisation avec les normes IEEE 802.11 et IEEE 802.15.4
2.3.3 Synchronisation par GNSS
2.3.4 Fréquence de synchronisation
2.4 Conclusion
3 Conception et validation d’une architecture de noeud de capteurs pour l’évaluation hors ligne de stratégies de synchronisation 
3.1 Description de l’architecture des noeuds
3.1.1 Architecture du noeud de capteurs
3.1.2 Calcul des horodatages
3.1.3 Architecture de l’unité d’horodatage
3.2 Validation des noeuds
3.2.1 Validation de l’unité d’horodatage
3.2.2 Validation des noeuds avec synchronisation GPS
3.3 Erreurs de synchronisation du récepteur GPS
3.3.1 Bruit GPS
3.3.2 Filtrage du signal PPS
3.3.3 Evaluation des filtres
3.4 Conclusion
4 Évaluation en post-traitement de la stratégie de synchronisation cyclique par GPS 
4.1 Synchronisation périodique par GPS
4.2 Modélisation
4.2.1 Modèle d’horloge
4.2.2 Prédiction de l’état pendant la période d’apnée
4.3 Filtrage de Kalman
4.3.1 Filtrage de Kalman avec récepteur GPS allumé
4.3.2 Filtrage de Kalman avec extinction périodique du récepteur GPS
4.4 Évaluation expérimentale des modèles
4.4.1 Évaluation de l’impact sur les horodatages
4.4.2 Cas particulier de la datation a posteriori
4.5 Conclusion
5 Évaluation de l’influence de la température 
5.1 Influence de la température ambiante sur les horloges des noeuds
5.2 Prédictions du déphasage avec la température
5.3 Utilisation d’un TCXO sur le noeud de capteurs
5.3.1 Prédiction « temps réel »
5.3.2 Prédiction a posteriori
5.4 Conclusion
6 Implémentation d’un noeud à faible consommation 
6.1 Description de l’architecture
6.1.1 Architecture du noeud de capteurs
6.1.2 Architecture de l’unité d’horodatage
6.2 Essais et résultats
6.3 Conclusion
7 Conclusion 
A Architecture du premier prototype 
B Architecture du deuxième prototype 
C Algorithme de l’unité de contrôle 
Bibliographie 

Télécharger le rapport complet