Brêchet Julien

AKUNU
Réseau mondial de capteurs atmosphériques

pour les pays à faible revenu
Travail de Bachelor
Rapport de projet
Etudiant : Julien Brêchet

Responsable : Marcos Rubinstein
Yverdon-les-Bains, jeudi 26 juillet 2018

Julien Brêchet
AKUNU – rapport de projet -2- 26.07.2018

Julien Brêchet
1 Clause de confidentialité liée au travail de Bachelor

Julien Brêchet

Julien Brêchet
2 Remerciements
Je tiens à remercier Monsieur Hervé Dedieu, directeur de l’entreprise Novaccess et professeur à la
HEIG-VD et Monsieur Jean-Daniel Carrard, fondateur de l’entreprise JDC Electronic SA pour leurs
conseils en matière de capteurs et de technologies de communication au sujet des stations
météorologiques.
Je remercie aussi Monsieur Marcos Rubinstein, mon responsable de travail de Bachelor, qui m’a
suivi et conseillé tout au long du projet ainsi que Monsieur Claude Guinchard et ses collègues de
l’atelier A03 pour m’avoir aidé lors de la conception des cartes PCB.
3 Planification
La planification des tâches ainsi que le diagramme de GANTT de la planification sont ajoutés en
annexes de ce rapport. Tous les deux sont sous forme de tableur Excel et le modèle du diagramme
de GANTT m’a été fourni par Monsieur Marcos Rubinstein.
4 Journal de travail
Un journal de travail a été tenu durant toute la seconde phase du travail de Bachelor. C’est-à-dire
à partir du lundi 18 juin 2018. Aucun journal n’a été établi pendant la première partie du projet
car cela n’avait pas été jugé nécessaire.

Julien Brêchet
5 Cahier des charges

Voici ci-dessous le cahier des charges (écrit en anglais par Monsieur Rubinstein) pour le travail de
Bachelor du projet AKUNU :
Specifications :
1. Objective: acquire data at multiple stations for analysis and location applications
2. Global specifications
a. Types of data
i. Wideband E-field
ii. Electrostatic
iii. Temperature
iv. Humidity
v. Wind
b. Timing et localisation
i. GPS
c. Communications
i. Inter station or station-to-base
ii. Maximum distance between stations: 200 m
iii. Transmission speed: to be determined for real-time or post-processing
applications
d. Scalable in number
e. Power requirements
i. Mains
ii. Explore possibility of batteries
iii. Explore possibility of solar
f. Security requirements
i. Not critical at this time: either open or standard encryption and
authentication offered by existing systems
Tasks :
1. High-level design of the system
2. Lower-level specifications per platform unit
a. Required sampling rate for
i. Temperature
ii. Wind
iii. Humidity
iv. Slow E field
v. Wideband E Field
b. Required data communication data rates per unit
3. Search for suitable platforms
a. Does Raspberry Pi satisfy the requirements?
i. Availability of sensors
ii. Ports
iii. Communications
b. Does Arduino satisfy the requirements?
ii. Ports
iii. Communications
c. Other platforms (evaluation of suitability for each one)

Julien Brêchet
ii. Ports
iii. Communications
4. Choice of platform
5. Acquisition of platform and sensors
6. Test of hardware and sensors
7. Programming
a. Flow diagram
b. Implementation
8. Test

Julien Brêchet
6 Résumé du projet
AKUNU est un projet qui a pour but de développer un réseau de capteurs portant le même nom et
dont l’objectif est de collecter au niveau mondial des données atmosphériques pour les pays à
faible revenu. Ce projet est proposé conjointement par le laboratoire Armstrong de l’université
d’Uppsala en Suède, l’université nationale de Colombie, l’université de Colombo au Sri Lanka,
l’université nationale de Cordoba en Argentine, l’UNIDEF en Argentine et l’institut IICT de la HEIG-
VD à Yverdon-les-Bains en Suisse.
Il existe déjà un grand nombre de stations météorologiques qui sont à la pointe de la technologie.
Ces stations sont généralement très fiables, très robustes et permettent de récolter des données
atmosphériques d’une grande précision, y compris des champs électromagnétiques de la foudre
avec une précision suffisante pour permettre la détection et la localisation en temps réel de ces
décharges. Mais le grand problème est que ces stations coûtent beaucoup trop cher pour les pays à
faible revenu et que ces derniers n’ont pas forcément besoin d’un réseau de capteurs
météorologiques de si haute précision. Utiliser une solution plus accessible en acceptant en
contrepartie de perdre quelque peu en fiabilité et en précision serait suffisant pour ces pays.
L’objectif principal du projet AKUNU est de mettre en place une infrastructure de stations
météorologiques permettant de récolter des données atmosphériques telles que la température
ambiante, l’humidité dans l’air, la pression atmosphérique, la vitesse et la direction du vent ainsi
que les champs électromagnétiques. Le coût de l’infrastructure se doit d’être bon marché afin que
les prix soient accessibles pour les pays en voie de développement. La spécification des prix et
coûts d’exploitation se place dans une fourchette large, allant des capteurs ultra bas prix ne
coûtant que quelques centaines de francs suisses jusqu’à une dizaine ou une vingtaine de milliers
de francs pour une solution finale.
Les premiers pays visés par le projet AKUNU sont l’Argentine, la Colombie et le Brésil en Amérique
latine ainsi que le Sri Lanka situé au sud de l’Inde. Puis, si la mise en place d’une infrastructure à
bas prix de stations météorologiques s’avère concluante dans ces quatre pays, il serait envisageable
de mettre en place des réseaux de stations météorologiques dans d’autres pays à faible revenu.
Dans un premier temps, une petite infrastructure a été mise en place pour tester des solutions à
très bas prix (quelques centaines de francs) en commençant par utiliser du matériel bon marché et
des technologies de communication basiques. Plus tard, il sera possible d’utiliser des protocoles de
communication et du matériel plus optimisés pour les stations météorologiques afin d’améliorer la
fiabilité, la robustesse et l’autonomie du réseau AKUNU et de ses stations.
Concernant la récupération des données atmosphériques, actuellement les stations
météorologiques envoient des données sur un serveur de fichiers à l'intérieur du réseau AKUNU.
Dans le futur, l’idéal serait de pouvoir récolter les données en temps réel afin de pouvoir détecter
au plus vite l’arrivée d’orages, de bourrasques de vent ou d’autres phénomènes atmosphériques.
L’objectif serait que les stations météorologiques puissent envoyer chaque seconde les données
qu’elles récoltent à un serveur central puis ensuite sur le Cloud afin que les informations puissent
être traitées en temps réel par les personnes concernées.
Les données sont pour l'instant envoyées de manière séquentielle au serveur central via un fichier
de logs. Il est possible de modifier différents compteurs pour augmenter ou diminuer les fréquences
de récolte indépendamment pour chaque type de donnée et il est aussi possible de gérer les
fréquences d'envoi des fichiers de logs sur le serveur de fichiers. Pour les données relatives aux
champs électromagnétiques, les transmissions ont lieu de façon événementielle où la station émet
uniquement lorsqu'un flux électromagnétique est détecté.

Julien Brêchet
Un des points les plus importants du projet AKUNU est de pouvoir facilement ajouter des stations
météorologiques supplémentaires et d’étendre la taille du réseau couvert par les stations. Cela
signifie que la conception de l'infrastructure mise en place a été étudiée pour être évolutive.
La force du réseau AKUNU est de pouvoir offrir une infrastructure de stations météorologiques qui
soit évolutive et abordable pour les pays à faible revenu tout en leur permettant néanmoins de
récolter des données atmosphériques de bonne qualité à des fins de recherche scientifique et
d’alertes météorologiques

Julien Brêchet
7 Table des matières

1 CLAUSE DE CONFIDENTIALITÉ LIÉE AU TRAVAIL DE BACHELOR ............................................................................. 3
2 REMERCIEMENTS ................................................................................................................................................. 5
3 PLANIFICATION .................................................................................................................................................... 5
4 JOURNAL DE TRAVAIL........................................................................................................................................... 5
5 CAHIER DES CHARGES .......................................................................................................................................... 6
6 RÉSUMÉ DU PROJET ............................................................................................................................................. 8
7 TABLE DES MATIÈRES ..........................................................................................................................................10
8 INTRODUCTION ...................................................................................................................................................11
9 RAPPORT DE PROJET ...........................................................................................................................................11
9.1 CONCEPTION HAUT NIVEAU DU SYSTÈME ..................................................................................................................... 11
9.1.1 Objectifs du système ..................................................................................................................................... 11
9.1.2 Spécifications des plateformes ...................................................................................................................... 12
9.1.3 Spécifications des capteurs ........................................................................................................................... 12
9.1.4 Spécifications des technologies ..................................................................................................................... 12
9.1.5 Analyse des plateformes existantes .............................................................................................................. 13
9.1.6 Analyse des capteurs existants ..................................................................................................................... 17
9.1.7 Analyse des technologies de communication existantes .............................................................................. 20
9.2 SÉLECTION DU MATÉRIEL ET DES TECHNOLOGIES ........................................................................................................... 32
9.3 PREMIÈRE PHASE DE CONCEPTION.............................................................................................................................. 33
9.4 PREMIÈRE PHASE DE TEST ......................................................................................................................................... 35
9.4.1 Mise en place d’un réseau wifi ...................................................................................................................... 35
9.4.2 Installation et configuration du serveur de fichiers ...................................................................................... 36
9.4.3 Configuration du serveur SMB ...................................................................................................................... 37
9.4.4 Installation et configuration de la station météorologique .......................................................................... 38
9.4.5 Installation du client SMB ............................................................................................................................. 39
9.4.6 Installation du capteur Adafruit BME 280 .................................................................................................... 39
9.4.7 Installation de la carte de dérivation Adafruit Ultimate GPS ........................................................................ 41
9.4.8 Processus de récolte des données ................................................................................................................. 43
9.5 SECONDE PHASE DE PROJET ...................................................................................................................................... 44
9.5.1 Modifications de conception ......................................................................................................................... 44
9.5.2 Seconde phase d’implémentation ................................................................................................................. 48
9.5.3 Problème de chute momentanée du débit du wifi ........................................................................................ 68
9.5.4 Tests de performance .................................................................................................................................... 69
9.5.5 Améliorations futures.................................................................................................................................... 71
9.5.6 Problèmes connus ......................................................................................................................................... 71
10 CONCLUSION .......................................................................................................................................................73
11 RÉFÉRENCES ........................................................................................................................................................75
12 LISTE DES SYMBOLES ET DES ABRÉVIATIONS .......................................................................................................78
13 LISTE DES FIGURES ..............................................................................................................................................79
14 ANNEXES .............................................................................................................................................................81
15 SIGNATURE .........................................................................................................................................................82
AKUNU – rapport de projet - 10 - 26.07.2018

Julien Brêchet
8 Introduction
Ce document est le rapport final du travail de Bachelor effectué sur le projet AKUNU. AKUNU est
un projet qui a pour but de développer un réseau de capteurs portant le même nom et dont
l’objectif sera de collecter au niveau mondial des données atmosphériques pour les pays à faible
revenu. Ce projet est proposé conjointement par le laboratoire Armstrong de l’université d’Uppsala
en Suède, l’université nationale de Colombie, l’université de Colombo au Sri Lanka, l’université
nationale de Cordoba en Argentine, l’UNIDEF en Argentine et l’institut IICT de la HEIG-VD à Yverdon-
les-Bains en Suisse.
Ce travail est effectué par Julien Brêchet, étudiant de troisième année de la filière Réseaux et
Services au sein de l’HEIG-VD d’Yverdon-les-Bains. Le professeur responsable est Monsieur Marcos
Rubinstein, professeur à la HEIG-VD et membre de l’institut IICT.
Le travail de Bachelor est divisé en deux phases. La première a lieu du lundi 19 février 2018 au
vendredi 15 juin 2018 à raison d’environ 12 heures par semaine et où le travail préliminaire est
effectué en parallèle d’autres cours lors du dernier semestre de la formation d’ingénieur HES au
sein de la HEIG-VD. A la fin de ces seize premières semaines, un rapport intermédiaire doit être
rendu le 15 juin 2018 et celui-ci est noté afin d’évaluer le travail préparatoire effectué sur le projet
AKUNU.
Ensuite, la seconde partie s’effectue du lundi 18 juin 2018 au vendredi 27 juillet 2018. Durant ces
six semaines, l’étudiant travaille sur le projet à plein temps, ce qui équivaut à une quarantaine
d’heures par semaine. Le rapport final du travail de Bachelor doit être remis au secrétariat TIC le
vendredi 27 juillet 2018 à 12h00 et sera défendu par l’étudiant courant septembre 2018.
9 Rapport de projet
9.1 Conception haut niveau du système
9.1.1 Objectifs du système
Le projet AKUNU a pour objectif de permettre à des pays en voie de développement de récolter
des données atmosphériques telles que la température ambiante, l’humidité dans l’air, la pression
atmosphérique, la vitesse et la direction du vent et les champs électromagnétiques en mettant en
place une infrastructure de stations météorologiques pour un coût relativement faible et accessible
ne dépassant pas la vingtaine de milliers de francs suisses.
Le premier critère est que l’infrastructure soit évolutive, c’est-à-dire qu’il doit être aisé d’ajouter
de nouvelles stations au sein du réseau AKUNU et que ce soit facile d’améliorer les composants et
les technologies utilisés. Le second critère est que le coût de mise en place de l’infrastructure soit
accessible aux pays émergents. L’infrastructure et les stations météorologiques qui la composent
doivent, malgré leur faible coût, être fiables et robustes afin d’avoir des coûts de maintenance peu
élevés. Les données relevées par les stations devront aussi être d’une précision suffisamment
satisfaisante, même si nous savons qu’il ne sera probablement pas possible de rivaliser avec les
instruments de mesure de haute-précision fabriqués par des constructeurs de renommée mondiale.
Le plus important est d’avoir une infrastructure robuste, fiable et de récolter des données
atmosphériques avec une précision honnête tout en restant dans un budget accessible.
Les données récoltées devront être envoyées à un serveur central le plus vite possible afin que des
météorologues et autres personnes compétentes puissent analyser les données au plus proche du
temps réel. Pour ce faire, beaucoup de réflexions sont axées sur l’évolutivité de l’infrastructure et
l’objectif est de pouvoir améliorer les technologies et les composants qui forment le réseau de

Julien Brêchet
capteurs météorologiques au fur et à mesure afin de se rapprocher le plus possible de la récolte de

données en temps réel et avec des données de plus en plus fiables et précises.
9.1.2 Spécifications des plateformes

Les plateformes utilisées pour mettre en place l’infrastructure du réseau AKUNU doivent être
robustes, fiables et si possible autonomes. Elles doivent pouvoir résister à l’environnement
extérieur tout en garantissant une récolte fiable et précise des données atmosphériques.
Dans un premier temps, la protection des stations météorologiques ne sera pas prise en compte car
l’infrastructure de test sera mise en place en intérieur. Normalement, la conception du boîtier de
protection ne sera pas effectuée dans le cadre de ce travail de Bachelor. Mais si en fin de projet le
temps le permet, la conception d’une boîte de protection pourrait alors être étudiée.
Quant à la question de la consommation électrique, l’étude du choix des plateformes doit
s’effectuer en ayant comme objectif de mettre en place des stations météorologiques totalement
autonomes. Pour ce faire, la plateforme composant la station doit idéalement consommer peu
d’énergie et doit pouvoir fonctionner avec une source d’énergie rechargeable comme par exemple
des batteries pouvant être rechargées à l’aide d’un petit panneau photovoltaïque intégré à la
plateforme.
Mais premièrement, lors de la mise en place de l’infrastructure de test, les plateformes seront
initialement toutes branchées au courant électrique à l’aide d’une prise d’alimentation. Selon la
vitesse à laquelle avance le projet, il sera envisageable d’utiliser une solution permettant aux
stations météorologiques d’être entièrement autonomes et de pouvoir ainsi les placer n’importe
où sans être dépendant de la présence proche d’une prise électrique.
9.1.3 Spécifications des capteurs

9.1.3.1 Fréquence d’échantillonnage
Il a été décidé d’établir initialement des fréquences d’échantillonnage allant d’une seconde à
plusieurs minutes pour la température, l’humidité et la pression atmosphérique. Ces fréquences
pourront être modifiées en direct pendant le processus de récolte des données. Pour les données
du vent aussi, des fréquences d’échantillonnage d’une à plusieurs secondes sont envisageables car
la vitesse du vent est susceptible de changer assez rapidement.
Quant aux champs électromagnétiques, il est prévu que le capteur envoie des données de manière
asynchrone, c’est-à-dire uniquement lorsque le champ électromagnétique capturé dépasse un seuil
prédéfini. L’idéal serait de pouvoir capturer les champs électromagnétiques avec une fréquence
d’au moins 200 échantillons par seconde, et ceci uniquement lorsque la force du champ est
supérieure au seuil d’envoi prédéfini.
9.1.4 Spécifications des technologies

Selon Monsieur Hervé Dedieu, l’idéal serait que chaque station puisse communiquer directement
avec le serveur central ou l’instance Cloud qui récolte et met à disposition les données
atmosphériques. Mais selon les technologies utilisées, le prix peut rapidement devenir élevé et
dépasser de loin le budget alloué pour ce travail de Bachelor.
L’utilisation de protocoles de communication station à serveur sera donc étudiée. Mais seront aussi
étudiés, selon les technologies existantes, des protocoles de communication inter-stations. Toutes
ces différentes technologies seront étudiées pour voir s’il en existe certaines qui puissent répondre
aux besoins du projet AKUNU.

Julien Brêchet
L’un des objectifs est d’utiliser des protocoles de communication basse consommation afin que les
stations soient énergétiquement autonomes. Mais initialement, la première infrastructure de test
sera mise en place avec des technologies dites basiques et avec des transmissions de données ne
coûtant rien ou très peu.
L’un des autres objectifs, probablement le plus important, est que les plateformes et les
technologies utilisées puissent offrir une grande évolutivité de l’infrastructure du réseau de
capteurs. Il devra être aisé d’ajouter de nouvelles stations dans le réseau, d’améliorer les
plateformes et les technologies de communication utilisées, d’augmenter la vitesse de transmission
et de s’approcher de plus en plus de la récolte de données en temps réel.
Dans un souci de maintenance, il serait aussi utile de pouvoir détecter si une station de
météorologie ou un autre élément du réseau AKUNU tombe en panne et éventuellement pouvoir le
redémarrer à distance. Selon les plateformes et les technologies utilisées, une solution de
maintenance peut être plus ou moins facilement mise en place.
9.1.5 Analyse des plateformes existantes

9.1.5.1 Modèles Raspberry Pi
Ma première idée lors de la recherche de plateformes pouvant faire office de station
météorologique et/ou de serveur central a été d’utiliser des Raspberry Pi. Avec ces nano-
ordinateurs, il est possible de connecter toutes sortes de capteurs au Raspberry Pi et d’écrire des
scripts permettant de récupérer les données des capteurs. De plus la communauté Raspberry Pi est
en plein essor et il est assez facile de trouver de la documentation.
9.1.5.1.1 Raspberry Pi Zero W

Il existe plusieurs modèles de Raspberry Pi, comme par exemple le Raspberry Pi Zero W (figure 1)
étant muni du hardware minimum nécessaire et étant orienté basse consommation, ce qui pourrait
s’avérer intéressant pour l’autonomie des stations.
Le Raspberry Pi Zero W possède [1] :
 1 processeur monocoeur d’une fréquence de 1GHz

 512MB de mémoire RAM
 1 port Mini HDMI
 1 port USB On-The-Go
 1 port USB power
 1 en-tête GPIO à 40 broches compatible HAT
 1 connecteur CSI
 1 port vidéo composite
 1 carte WLAN compatible 801.11 b/g/n
 Bluetooth 4.1
 BLE
Exemple de prix pour le Raspberry Pi Zero W sans le câble d’alimentation : 15.15 CHF sur pi-
shop.ch.

Julien Brêchet
Figure 1 : Raspberry Pi Zero W trouvé sur le site officiel raspberrypi.org
Selon le site de comparaison socialcompare.com [2], le Raspbery Pi Zero W consomme seulement

180mA à 3.3V, ce qui est beaucoup moins que le modèle principal actuel qui est le Raspberry Pi 3
Modèle B+ [3]. En effet le Raspberry Pi 3 B+ consomme 1.13A à un voltage de 5V.
9.1.5.1.2 Raspberry Pi 3 Modèle B+

A l’heure actuelle, courant 2018, le modèle le plus avancé de Raspberry est la version 3 Modèle B+
(figure 2). La société Raspberry Pi en a fait son produit principal et garantit de le commercialiser
au moins jusqu’à janvier 2023 [3].
Comme expliqué dans le paragraphe ci-dessus, ce modèle consomme plus d’électricité que le
Raspberry Pi Zero W [2] mais il est aussi plus puissant et serait plutôt destiné à faire office de
serveur central.
Le Raspberry Pi 3 B+ possède [3] :
 1 processeur Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC @ 1.4GHz

 1GB LPDDR2 SDRAM
 1 en-tête GPIO à 40 broches compatible HAT
 1 carte WLAN compatible 802.11 b/g/n/ac
 Bluetooth 4.2
 BLE
 1 port HDMI
 1 port Gigabit Ethernet over USB 2.0 avec un debit maximum de 300Mbps
 4 ports USB 2.0
 1 connecteur CSI
 1 port d’affichage DSI
 4 ports vidéo composite et sortie stéréo
 1 port USB power 5V/2.5A DC
 PoE supporté
Exemple de prix pour le Raspberry Pi 3 Modèle B+ sans le câble d’alimentation : 44.90 CHF sur pi-
shop.ch.

Julien Brêchet
Figure 2 : Raspberry Pi 3 B+ trouvé sur le site officiel raspberrypi.org
9.1.5.2 Modèles Arduino

Une autre solution serait d’utiliser des cartes Arduino. Arduino est une plateforme électronique
open-source basée sur du matériel et des logiciels faciles à utiliser [4]. Contrairement aux
Raspberry Pi, les cartes Arduino ne sont pas des nano-ordinateurs. Ce sont des cartes munies d’un
microcontrôleur et sont plutôt considérées comme des petits automates exécutant une tâche
unique en boucle. Une plateforme Arduino est donc considérée comme « plus proche » du matériel
électronique qu’un nano-ordinateur Raspberry Pi [5].
9.1.5.2.1 Arduino M0
Il existe de nombreux produits Arduino comme le modèle M0 disposant d’un microcontrôleur 32 bits
(figure 3). Tout comme le Raspberry Pi Zero W, sa consommation énergétique est assez faible.
Les spécifications de l’Arduino M0 sont les suivantes [6] :
 1 microcontrôleur ATSAMD21G18, 48pins LQFP

 Architecture ARM Cortex-M0+
 Tension de 3.3V pour le microcontrôleur
 Tension d’entrée de 5 à 15V
 Mémoire flash de 256kB
 SRAM de 32kb
 Vitesse d’horloge à 48MHz
 6 I/O pins analogiques
 20 I/O pins digitales
 Consommation énergétique de 29mA
Exemple de prix pour l’Arduino M0 : 28.90 CHF sur digitec.ch.

Julien Brêchet
Figure 3 : Arduino M0 trouvé sur le site officiel arduino.cc
9.1.5.2.2 Arduino Due

Arduino Due est un des modèles Arduino les plus populaires (figure 4). Tout comme le modèle M0,
il dispose d’un microcontrôleur 32 bits mais il est plus puissant, possède plus d’I/O pins et
consomme plus d’énergie que l’Arduino M0.
Voici ci-dessous les spécifications du modèle Arduino Due [7] :
 1 microcontrôleur AT91SAM3X8E
 Tension de 3.3V pour le microcontrôleur
 Tension d’entrée recommandée de 7 à 12V
 Mémoire flash de 512kB
 SRAM de 96kb
 Vitesse d’horloge à 84MHz
 12 I/O pins analogiques
 54 I/O pins digitales
 Consommation énergétique de 800mA
Exemple de prix pour l’Arduino Due : 48.- CHF sur digitec.ch.
Figure 4 : Arduino Due trouvé sur le site officiel arduino.cc
9.1.5.3 Autres plateformes

Il existe encore d’autres plateformes moins connues pouvant fournir une solution viable pour le
projet AKUNU. J’ai trouvé une liste non-exhaustive de quelques plateformes pouvant s’avérer
être des alternatives aux nano-ordinateurs Raspberry Pi [8].

Julien Brêchet
9.1.6 Analyse des capteurs existants

Dans un premier temps, les types de données qui nous intéressent sont la température ambiante,
l’humidité et la pression atmosphérique. Une antenne GPS est aussi désirable pour pouvoir obtenir
la position de la station météorologique et de pouvoir synchroniser son horloge pour obtenir un
temps précis lors de la récolte des données atmosphériques. Durant la seconde partie du travail de
Bachelor, l’acquisition de capteurs supplémentaires sera étudiée pour pouvoir récolter et analyser
d’autres types de données tels que le vent ou les champs électromagnétiques.
9.1.6.1 Adafruit BME 280

Le capteur BME 280 d’Adafruit (figure 5) est un capteur trois en un permettant d’analyser la
température, l’humidité et la pression barométrique avec une précision honnête et pour un prix
relativement peu élevé.
La précision du capteur de température est de +/- 1°C, +/- 3% pour le capteur d’humidité et +/-
1hPa pour la pression barométrique. Le BME 280 est un capteur de nouvelle génération de
l’entreprise Bosch Sensortec. Il résulte de la mise à niveau des capteurs BMP085, BMP180 et BMP183
et possède un temps de conversion analogique numérique rapide. Il est possible de récupérer les
données récoltées par le capteur par I2C ou SPI [9].
Des librairies et des exemples de code Python sont disponibles pour convertir et obtenir les données
récupérées par le capteur.
Prix du capteur BME 280 : 19.95$ sur le site d’Adafruit.
Figure 5 : Capteur Adafruit BME 280 trouvé sur le site officiel adafruit.com
9.1.6.2 Antenne GPS passive UFL 9mm x 9mm

Une antenne GPS peut être utilisée pour obtenir une localisation plus ou moins précise d’une station
météorologique. Elle permet aussi de synchroniser l’horloge de la station avec l’heure des
satellites.
Il existe de très petites antennes GPS telles que l’antenne passive UFL 9mm x 9mm qui est très
petite, très légère et qui ne coûte vraiment pas cher. Cette antenne passive permet d’améliorer la
détection des satellites par le dispositif GPS auquel elle est branchée.
Voici les caractéristiques disponibles sur le site officiel pour cette antenne GPS [10] :
 Interface IPX UFL

 Gain d’environ -2dBi
 Longueur du câble de 50mm

Julien Brêchet
 Poids de 2.4g
Prix de l’antenne GPS : 4.95$ sur le site d’Adafruit.
Figure 6 : Antenne passive avec connecteur UFL trouvée sur le site officiel adafruit.com
A noter que les antennes passives comme celle que nous apercevons à la figure 6 ne possèdent pas
de LNA et n’exigent donc aucune puissance pour fonctionner [11].
9.1.6.3 Adafruit Ultimate GPS Breakout

Une solution à prix abordable est d’utiliser une carte de dérivation (breakout board) GPS telle que
le modèle Adafruit Ultimate GPS Breakout - 66 channel w/10 Hz updates - Version 3. Les
caractéristiques et spécifications de ce modèle sont les suivantes [12] :
 Chipset MTK3339
 66 canaux pour rechercher des satellites
 Fréquence de mise à jour à 10Hz
 Tension de 5V
 Intensité de 20mA
 Compatible avec une batterie RTC
 Enregistrement de données intégré
 Sortie PPS
 Antenne interne + connecteur UFL pour une antenne externe active
 LED de statut
 66 satellites recherchés et 22 suivis (traking)
 Taille de l’antenne : 15mm x 15mm x 4mm
 Précision de la position : 1.8m
 Précision de la vitesse : 0.1m/s
 Sensibilité d’acquisition : -15dBm
 Sensibilité de suivi : -165dBm
 Jusqu’à 210 canaux PRN
 Détection et réduction du brouillage
 Détection et compensation du multi-path
Avec un Arduino ou un Raspberry Pi, il est possible de communiquer avec le capteur Ultimate GPS
Breakout par TTL ou avec un lien série UART. Le capteur permet de récupérer le temps, la date, la

Julien Brêchet
longitude, la latitude et l’altitude toutes les 15 secondes et en cas de besoin la mémoire flash
interne peut stocker jusqu’à 16 heures de données [12].
Exemple de prix de la carte de dérivation Ultimate GPS : 39.95$ sur le site d’Adafruit.
Figure 7 : Adafruit Ultimate GPS Breakout sur une plaque de test trouvé sur le site officiel adafruit.com
La figure 7 nous montre qu’il est possible de connecter l’Adafruit Ultimate GPS Breakout sur une
plaque de test et que la carte possède neuf pins ainsi qu’un connecteur UFL pour y brancher une
antenne passive.
9.1.6.4 Anémomètre avec sortie de tension analogique QS-FS01

Par la suite, durant la seconde partie du travail de Bachelor, un anémomètre pourra être installé
pour calculer la vitesse du vent et éventuellement donner sa direction.
J’ai trouvé sur le site d’Adafruit un anémomètre QS-FS01 avec une sortie de tension analogique
permettant de calculer la vitesse du vent de 0.5 à 50 mètres par seconde avec une précision de +/-
1m/s (figure 8). Par contre, cet anémomètre n’indique pas la direction du vent. Voici ci-dessous
les spécifications et les dimensions le concernant [13] :
 Sortie de 0.4V à 2V
 Plage de mesure fiable allant de 0.5 à 50 mètres par seconde
 Précision de +/- 1 mètre par seconde
 Résolution de 0.1m/s
 Vitesse maximale de calcul : 70m/s
 Hauteur : 105mm
 Poids : 111.8g
 Longueur de bras : 70mm
 Longueur du câble : 99cm avec un diamètre de 4.8mm
 Longueur de la prise : 30mm
Exemple de prix de l’anémomètre : 44.95$ sur le site d’Adafruit et 44.95 CHF sur digikey.ch

Julien Brêchet
Figure 8 : Anémomètre avec tension de sortie analogique trouvé sur le site officiel adafruit.com
9.1.6.5 Capteur de champ électromagnétique

Un capteur de champ électromagnétique est en train d’être développé dans le cadre d’un travail
de Master par un étudiant suivi par Monsieur Rubinstein. Si le capteur s’avérait fonctionnel, il serait
possible de l’utiliser afin de pouvoir récolter, calculer et analyser des données de champs
électromagnétiques.
Sinon après plusieurs recherches, je n’ai trouvé aucun capteur de champ électromagnétique à un
prix abordable. Soit ce sont des capteurs de champ électromagnétique ultra large bande qui coûtent
très cher et qui font partie des matériaux de calcul de pointe avec une grande précision, soit ce
sont des solutions complètes d’appareils de mesure avec leurs propres capteurs intégrés et
affichant directement les données sur l’écran de l’appareil.
9.1.7 Analyse des technologies de communication existantes

Il existe de nombreux protocoles de communication possédant chacun leurs propres spécificités,
leurs points forts et leurs points faibles. Dans ce chapitre sont présentées différentes technologies
de communication afin de permettre premièrement de choisir ce qui va être utilisé pour
l’infrastructure de test qui sera mise en place durant la période du travail de Bachelor mais aussi,
et surtout, pour permettre aux personnes qui prendront le relais à la suite de ce travail d’avoir une
petite analyse d’une liste non-exhaustive de technologies qui pourront être utilisées pour améliorer
l’infrastructure du réseau AKUNU.
Dans ce chapitre, je décris quelques technologies de communication, dont certaines que j’ai
découvertes durant le cours d’IOT donné par le professeur Dedieu. Pour certaines informations que
j’avance, je n’ai pas forcément de références car certains éléments proviennent directement de
mes notes prises lors du cours d’IOT suivi en parallèle de la première phase de mon travail de
Bachelor.
9.1.7.1 Technologies LPWAN

Les technologies LPWAN utilisent des bandes non licenciées (bande ISM 868MHz) et peuvent émettre
et recevoir des messages de petite taille et sur de longues portées allant jusqu’à une quarantaine
de kilomètres. Les technologies LPWAN sont ultra-low power, cela veut dire qu’elles consomment
très peu d’énergie pour émettre des messages et qu’il est tout à fait possible de brancher sur

Julien Brêchet
batteries les appareils fonctionnant avec ces technologies. Les communications ont lieu
sporadiquement et vont du périphérique LPWAN à un serveur. Parfois le serveur peut répondre dans
les secondes qui suivent pour donner des informations au périphérique qui a envoyé la requête.
Le débit n’est en général pas très élevé, il s’élève à une centaine de bits par seconde. Et comme
je l’ai déjà expliqué auparavant, les communications ne se font que de temps en temps comme par
exemple de manière séquentielle toutes les 15 minutes. Les technologies LPWAN peuvent s’avérer
très intéressantes au niveau de l’autonomie des stations météorologiques car la consommation
énergétique est moindre mais le problème est qu’il serait impossible de s’approcher de l’envoi des
données en temps réel car le nombre et le débit des communications sont limités. Parmi les
technologies LPWAN les plus connues, nous pouvons trouver LoRa et Sigfox.
9.1.7.1.1 LoRa
LoRa est une technologie LPWAN utilisée pour envoyer des messages de petite taille de façon
sporadique d’un périphérique LoRa à un serveur qui peut être physique, virtuel ou être une instance
sur un Cloud tel qu’Amazon Web Services.
A proprement parler, LoRa est la couche physique qui utilise une modulation de spectre propriétaire
développée par la société française Cycleo qui a ensuite été rachetée par Semtech. La modulation
s’effectue principalement sur les bandes ISM 868MHz mais peut aussi s’effectuer sur d’autres
fréquences. LoRaWAN est quant à elle la couche applicative qui fonctionne sur la couche physique
LoRa. C’est une technologie ouverte (open-standard).
Figure 9 : architecture LoRaWAN simplifiée selon thethingsnetwork.org
La figure 9 ci-dessus décrit de manière simplifiée le fonctionnement de l’infrastructure de la

technologie LoRaWAN. Les périphériques (devices) envoient un message sur la couche physique
LoRa à des gateways qui redirigent les messages à destination d’un network server. Le network
server filtre les messages qui lui sont destinés et supprime les doublons au cas où plusieurs gateways

Julien Brêchet
auraient relayé le message du périphérique. Ensuite il envoie le message à l’application à laquelle

le message est destiné.
Parfois, l’application doit répondre à la requête envoyée par le périphérique LoRa. Si c’est le cas,
elle répond dans les secondes qui suivent le traitement de la requête et le network server se charge
de distribuer le message à la bonne gateway pour que celle-ci émette la réponse et que le
périphérique puisse la recevoir.
Le principal inconvénient avec la technologie LoRa est que c’est une technologie émergente qui
commence à devenir connue en Europe mais qui ne l’est pas forcément partout dans le monde. Par
exemple un des contacts argentins de Monsieur Marcos Rubinstein pour le projet AKUNU nous a
affirmé que la technologie LoRa était peu connue en Argentine et qu’il n’y avait pas d’antennes
(gateways) installées pour permettre l’envoi de messages LoRa depuis des périphériques jusqu’à
une infrastructure LoRaWAN. Cela est aussi très probable dans les autre pays concernés par le
projet AKUNU et cela signifie malheureusement que mettre en place une solution LoRa n’est
actuellement pas possible. Un autre problème est qu’il serait impossible de s’approcher de l’envoi
des données en temps réel car le nombre et le débit des communications sont limités.
9.1.7.1.2 Sigfox
Tout comme LoRa, Sigfox est une technologie LPWAN utilisant des composants qui consomment très
peu d’énergie et qui peuvent fonctionner sur batteries. Sigfox est un protocole de communication
développé par la société française du même nom qui est implantée à Labège, commune de la
banlieue toulousaine [14].
A l’aide de la figure 10, nous pouvons constater que les zones couvertes par Sigfox sont
actuellement un peu plus nombreuses que pour LoRa mais le réseau Sigfox ne couvre pas tous les
pays visés par le projet AKUNU. L’Argentine, le Brésil ainsi que la Colombie possèdent des
infrastructures permettant d’utiliser la technologie Sigfox mais ce n’est pas encore le cas pour le
Sri Lanka [15].
Figure 10 : Couverture du réseau Sigfox selon le site officiel [15]

Julien Brêchet
Sigfox utilise une technologie de modulation propriétaire qui utilise tout comme LoRa les bandes
ISM 868MHz en Europe et 902MHz aux Etats-Unis [14]. Sigfox utilise une modulation d BPSK pour les
transmissions montantes (liaisons uplink allant du périphérique au Cloud Sigfox). Il utilise un
protocole léger avec peu d’overhead pour gérer des messages de petite taille dans des systèmes
conventionnels. Sigfox est optimisé au maximum afin de consommer le moins d’énergie possible
lors de l’envoi d’un message [16].
La taille maximale d’un message uplink est de 12 octets, ce qui équivaut à 96 bits. Le nombre
maximal d’envoi de messages par jour pour un périphérique est défini à 140 pour éviter à ce que
ce dernier consomme trop d’énergie. Quant aux messages de liaison descendante (downlink), ils
sont limités à 4 envois par jour et ont une taille maximale limitée à seulement 8 octets.
La topologie de l’architecture du réseau Sigfox est en étoile. Des milliers d’objets (périphériques)
transmettent leurs messages au réseau Sigfox via les stations Sigfox déployées dans les différents
endroits du monde indiqués par la figure 10. Ces stations communiquent via un lien point à point
avec le Cloud Sigfox et ce dernier pousse les messages vers de nombreux serveurs clients et
plateformes informatiques [16]. La figure 11 ci-dessous illustre un exemple d’architecture Sigfox.
Figure 11 : Architecture Sigfox trouvée sur une vidéo Youtube de l'entreprise [17]
Sigfox est compatible avec les technologies Bluetooth, GPS 2G/3G/4G et wifi. Ses coûts de
connectivité sont peu élevés et c’est une technologie qui permet de mettre en place des solutions
qui consomment très peu d’énergie [16].
Tout comme avec la technologie LoRa, l’un des inconvénients de Sigfox est que la couverture du
réseau n’est pas disponible dans au moins un des quatre pays qui sont concernés par le projet
AKUNU. Ici le problème serait pour le Sri Lanka qui ne dispose à priori d’aucune couverture du
réseau Sigfox. L’autre problème est aussi le même que pour LoRa, c’est-à-dire que chaque station
météorologique ne pourrait envoyer au serveur qu’un nombre limité de messages par jour, 140 avec
Sigfox. Ce serait donc, tout comme pour LoRa, impossible de s’approcher de l’envoi des données
en temps réel.

Julien Brêchet
9.1.7.2 Technologies LR WPAN

Le 802.15.4 est un protocole de communication défini par l’IEEE. Il est destiné aux réseaux sans-fil
de la famille des LR WPAN du fait de leur faible consommation, de leur faible portée et du faible
débit des dispositifs utilisant ce protocole. La norme 802.15.4 est utilisée par de nombreuses
implémentations basées sur des protocoles propriétaires ou sur IP, comme le ZigBee et le 6LoWPAN
[18].
Les caractéristiques des LR WPAN sont les suivantes [18] :
 Formation d’un réseau de type étoilé ou maillé

 Allocation d’une adresse de 16 bits ou de 64 bits
 Utilisation de la méthode d’accès CSMA/CA pour communiquer
 Faible consommation d’énergie
 Détection d’énergie
 Indication de la qualité de la liaison
 16 canaux dans la bande de fréquence de 2.4 à 2.4835GHz
 10 canaux dans la bande de fréquence de 902 à 928MHz
 1 canal dans la bande de fréquence de 868 à 868,6 MHz
L'IEEE a défini deux types de dispositifs pouvant participer à un réseau :
 Dispositif ayant toutes les fonctions possibles (FFD : Full Function Device)
 Dispositif ayant des fonctions limitées (RFD : Reduced Function Device)
Le FFD peut assurer trois rôles dans un réseau : coordinateur PAN, routeur ou dispositif relié à un
capteur (plus petite fonction possible, appelé dispositif de fin). Le RFD quant à lui est prévu pour
des applications simples (signaler l'état d'un capteur, contrôler l'activation d'un actionneur). Il est
considéré comme un dispositif d’extrémité (end device en anglais), dans le sens où il n'est pas
essentiel au réseau [18].
Pour communiquer sur un même réseau, un FFD (au moins) et des RFD doivent utiliser le même
canal physique parmi ceux définis selon la bande de fréquence choisie. Le FFD peut dialoguer avec
des RFD et des FFD, tandis que le RFD dialogue avec un FFD uniquement [18].
9.1.7.2.1 Zigbee
ZigBee est un protocole de haut niveau permettant la communication d'équipements personnels ou
domestiques équipés de petits émetteurs radio à faible consommation ; il est basé sur la norme
IEEE 802.15.4 pour les réseaux PAN. ZigBee peut utiliser les trois bandes définies par la norme IEEE
802.15.4 : [19]
 1 canal 868MHz disponible en Europe, débit maximal théorique de 20kbps

 10 canaux 915MHz disponibles en Amérique du Nord, Amérique du Sud et en Australie, débit
maximal théorique de 40kbps
 16 canaux 2.4GHz disponible partout dans le monde, débit théorique maximal de 250kbps
ZigBee est développé par la ZigBee Alliance qui est représentée par des entreprises telles que Texas
Instruments, Huawei, Comcast, Silicon Laboratories et d’autres encore [20]. La version actuelle est
la 3.0 qui est basée sur la couche ZigBee PRO qui étend la norme IEEE 802.15.4 en ajoutant un
réseau maillé et des couches de sécurité supplémentaires avec un framework applicatif pour
devenir une solution interopérable et à faible consommation énergétique [21].

Julien Brêchet
Figure 12 : Aperçu sous forme de pile pour la technologie ZigBee 3.0 [21]
La norme IEEE 802.15.4 définit la couche physique et la couche MAC du protocole ZigBee. Pour
obtenir une solution fonctionnelle, il faut implémenter les couches de plus haut niveau que sont
les couches réseau et application parce que celles-ci ne sont pas standardisées par la norme IEEE
802.155.4. La ZigBee alliance s’occupe de cette partie du protocole en fournissant une pile de
référence qui est réservée aux membres de l’alliance [19] qui développent leurs propres solutions.
Nous pouvons apercevoir ces différentes couches dans la figure 12 ci-dessus.
Zigbee PRO sert d'infrastructure réseau pour les réseaux et produits basés sur Zigbee. Utilisé seul,
il peut constituer la base d’implémentations d’architectures IoT robustes et propriétaires. Comme
déjà dit auparavant dans ce document, il étend la norme IEEE 802.15.4 en ajoutant un réseau maillé
et des couches de sécurité supplémentaires avec un framework applicatif pour devenir une solution
interopérable et à faible consommation énergétique.
Caractéristiques de ZigBee PRO [22] :
 Communication crossband (full duplex) sur des bandes de 2.4GHz et sous-GHz avec prise en
charge de plusieurs supports physiques
 Fonctionnement global dans la bande de fréquence 2.4GHz selon la norme IEEE 802.15.4
 Opération régionale dans les bandes 915MHz et 868MHz
 Solution agile de fréquence fonctionnant sur 16 canaux pour la fréquence 2.4GHz et 90
canaux pour la bande sous-GHz
 Intègre des mécanismes d’économie d’énergie pour toutes sortes d’appareils et supporte
les appareils sans batterie
 Mécanisme de découverte avec confirmation de l’application
 Mécanisme de jumelage avec confirmation de l’application
 Topologie réseau maillée
 Communication dans un PAN
 Différentes options de transmission incluant unicast, broadcast et multicast
 Mécanisme sécurisé pour la génération de clefs
 Utilise le standard AES-128 pour le schéma de sécurité

Julien Brêchet
 Prise en charge des normes de la ZigBee Alliance ou d’innovations spécifiques au fabricant

 Comprend des mesures de puissance pour réduire la puissance de sortie permettant aux
dispositifs de communiquer au niveau de puissance requis
 Canaux de transmission en sous-GHz pouvant émettre jusqu’à une distance d’un kilomètre
Au niveau de la couche réseau, le routage est soit direct, soit indirect. Le routage est considéré
comme direct lorsqu’un dispositif qui veut transmettre des données connaît l’adresse réseau du
destinataire. Cette adresse est transmise dans la trame afin que cette même trame puisse atteindre
le destinataire [19].
Le routage indirect se fait lorsqu’un dispositif ne connaît pas l’adresse du destinataire. Un élément
de type routeur ou coordinateur PAN fait la relation avec le vrai destinataire d’après la table de
routage et la table de découverte des routes [19].
La table de découverte d'une route contient les informations sur les sources du message. Elle stocke
l'adresse d'origine du dispositif qui a fait la demande et l'adresse du dispositif qui va transmettre
les données en tant qu'intermédiaire. Elle contient aussi les coûts de transmission entre la source
jusqu'au nœud actuel et du nœud jusqu'au destinataire. Elle peut donc adapter la route pour être
plus performante en mettant à jour les adresses à utiliser [19].
L'algorithme de routage suggéré par la ZigBee Alliance pour les réseaux maillés est AODV. C'est un
protocole de routage dit réactif car une route est établie uniquement sur demande. L'avantage est
qu'il ne charge pas le trafic [19].
Dans un réseau maillé ZigBee, le coordinateur PAN forme la seule racine du réseau. D’abord il crée
le réseau puis il attend que des nœuds joignent le réseau. Il permet à tous les nœuds de
communiquer au sein du réseau et stocke les données. En raison d’une portée de communication
limitée, des coordinateurs intermédiaires (routeurs) sont impliqués pour transférer des données
entre les nœuds de capteurs (end-devices) et le coordinateur PAN via un routage multi-saut. La
figure 13 ci-dessous illustre l’architecture réseau de différentes topologies ZigBee. Un FFD est un
nœud qui peut détecter l’environnement et communiquer avec les autres nœuds du réseau. Un
dispositif d’extrémité quant à lui est uniquement capable de détecter et d’envoyer des données au
coordinateur PAN ou au nœud de coordination le plus proche. Il ne peut pas router les messages.
Le coordinateur PAN est généralement alimenté par courant alternatif, tandis que les routeurs et
les dispositifs d’extrémité sont généralement alimentés par batterie [23].

Julien Brêchet
Figure 13 : 3 différentes topologies ZigBee expliquées dans l'article [23]
Selon un article qui étudie les distances maximales de communication pour ZigBee [24], pour un
message de 1'024 bits sur le canal 26, la distance maximale est de 45 mètres. La distance chute
considérablement à 20 mètres s’il y a du trafic sur le canal wifi numéro 13. Avec des messages
d’une taille de 512 bits, la distance maximale de communication n’augmente pas de manière très
significative : 50 mètres avec du bruit environnant standard, 45 mètres avec un autre réseau ZigBee
sur le canal 26 et 30 mètres si du trafic sur le canal wifi numéro 13 est présent.
Pour une taille de message de 256 bits, la distance maximum augmente à 45 mètres si du trafic wifi
sur le canal 13 a lieu et sinon c’est 50 mètres. Les distances de communication ZigBee sont donc
influencées par la présence ou non de réseaux wifi [23].
La technologie ZigBee peut s’avérer très intéressante pour le projet AKUNU car il serait
envisageable d’installer des stations météorologiques tous les 20-30 mètres afin que les messages
de chaque station puissent être relayés jusqu’au coordinateur PAN. Il serait aussi techniquement
possible de mettre en place une solution de self-healing au cas où un nœud du réseau tomberait
en panne.
9.1.7.2.2 Z-Wave
Z-Wave est un protocole qui communique en utilisant une technologie de faible puissance dans la
bande de fréquence 868MHz. Ce protocole radio est optimisé pour des échanges à faible bande
passante (entre 9 et 40 kbit/s) et des appareils sur pile ou alimentés électriquement, par opposition
au wifi par exemple, qui est prévu pour des échanges à haut débit et sur des appareils alimentés
électriquement uniquement. Z-Wave fonctionne dans la gamme de fréquences sous-GHz, qui
dépend des régions (868MHz en Europe, 908MHz aux Etats-Unis, et d'autres fréquences suivant les
bandes ISM des régions). La portée est d'environ 50 m [25].
Tout comme ZigBee, Z-Wave est basé sur la norme IEEE 802.15.4 et fonctionne avec une topologie
maillée. Mais contrairement à son concurrent, Z-Wave est surtout spécialisé dans les domaines de

Julien Brêchet
la domotique et il utilise uniquement les bandes de fréquence 915MHz et 868MHz (sous-GHz), pas
de 2.4GHz. Z-Wave utilise un système radio propriétaire élaboré par la société californienne Sigma
Designs [26].
Puisque Z-Wave est totalement propriétaire, cela signifie qu’il y a moins de problèmes
d’interopérabilité qu’avec ZigBee car ce dernier est développé par différentes entreprises au
niveau de la couche réseau et de la couche applicative.
Voici ci-dessous quelques caractéristiques de la technologie [27] :
 Technologie de communication radiofréquence à faible alimentation supportant les réseaux

maillés (mesh et full mesh) sans qu’un nœud de coordination soit nécessaire
 Fonctionne sur la bande sous-GHz, insensible aux interférences wifi (contrairement à
ZigBee !) et d’autres technologies fonctionnant sur la fréquence 2.4GHz
 Les couches Physique et MAC sont définies par la recommandation UIT-T G.9959
 Conçu spécifiquement pour les applications de contrôle et d'état, prend en charge des débits
de données allant jusqu'à 100kbps, avec cryptage AES-128, IPv6 et fonctionnement
multicanal
 Interopérabilité complète grâce à la couche 6 avec rétrocompatibilité avec toutes les
versions
 Partage la même position dans le catalogue de normes NIST / SGIP que les familles IEEE
802.11 et 802.15 et 802.16
La figure 14 nous fait constater que le réseau Z-Way ne couvre pas encore le Sri Lanka, ce qui n’est
pas non plus le cas de Sigfox [28].
Figure 14 : Couverture du réseau Z-Wave selon [28]
Un réseau Z-Way possède une topologie maillée, tout comme ZigBee. Il peut y avoir trois types de
nœuds différents dans le réseau [29] :
 Contrôleur : 1 ou plusieurs dans le réseau, connaît tous ses voisins, a un accès intégral à la
table de routage, peut communiquer chaque nœud du réseau, si une route existe
 Esclave : connaît tous ses voisins, n’a aucun accès à la table de routage, peut uniquement
répondre au nœud dont il a reçu le message

Julien Brêchet
 Esclave de routage : connaît tous ses voisins, connaît partiellement les informations
contenues dans la table de routage, peut répondre au nœud dont il a reçu le message et
peut aussi envoyer des messages non sollicités à un nombre prédéfini de nœuds auxquels il
a accès
Z-Way fournit des fonctionnalités ressemblantes à ZigBee mais est beaucoup plus axé côté
domotique et n’est pas actuellement couvert au Sri Lanka. L’utilisation de ZigBee semble
actuellement plus adaptée pour mettre en place l’infrastructure du réseau AKUNU.
9.1.7.2.3 Autres technologies LR WPAN

Il existe encore d’autres technologies LR WPAN qui n’ont pas été discutées dans ce rapport. Il existe
par exemple les technologies Enocean, 6LoWPAN, MQTT, Thread, DASH7 et bien d’autres encore.
9.1.7.3 Bluetooth
Bluetooth est une norme de communications permettant l'échange bidirectionnel de données à très
courte distance en utilisant des ondes radio UHF sur une bande de fréquence de 2,4 GHz. Il existe
plusieurs versions, la plus récente étant la 5 qui a été rendue publique en 2016 [30].
La technologie Bluetooth fonctionne sur la bande de fréquence ISM 2.4GHz qui est comprise plus
précisément entre 2'400 et 2'435MHz [30].
Il existe 79 canaux RF numérotés de 0 à 78 et qui sont séparés de 1MHz en commençant par
2'402MHz. Le codage de l'information se fait par sauts de fréquences et la période est de 625 µs,
ce qui permet 1 600 sauts par seconde. Il existe trois classes de modules radio Bluetooth [30] :
 Classe 1 : puissance de 100mW (20dBm), portée maximale de 100 mètres

 Classe 2 : puissance de 2.5mW (4dBm), portée maximale de 10 à 20 mètres
 Classe 3 : puissance de 1mW (0dBm), portée de quelques mètres
Il est possible de mettre en place plusieurs topologies réseau différentes avec la technologie
Bluetooth. La plus simple est la topologie point à point qui est utilisée pour établir une connexion
d’un dispositif vers un autre (1:1).
Broadcast est la seconde topologie existante. C’est une topologie réseau utilisée pour établir une
connexion d’un dispositif à plusieurs (1:m). Elle est disponible avec la technique de transmission
Bluetooth Low Energy et est optimisée pour le partage d’informations et les services de localisation.
La troisième solution est d’utiliser une topologie maillée. C’est une topologie réseau utilisée pour
établir des communications de plusieurs à plusieurs (m:m). Tout comme pour Broadcast, elle
fonctionne sur BLE et permet de créer des réseaux de dispositifs à grande échelle. Elle convient
aux systèmes de contrôle, de surveillance et d'automatisation où des dizaines, des centaines ou des
milliers de périphériques doivent communiquer de manière fiable et sécurisée entre eux [31].
La technique de transmission sans fil Bluetooth Low Energy, également appelée Bluetooth LE ou
intégralement abrégée en BLE, a été créée en 2006 par la société Nokia sous la forme d’un standard
ouvert basé sur le Bluetooth. BLE complète celui-ci mais ne le remplace pas.
Comparé au Bluetooth standard, le BLE permet un débit du même ordre de grandeur (1Mbps) pour
une consommation d'énergie 10 fois moindre. Les modes BLE (bande passante plus limitée et très
faible consommation) et Bluetooth standard (niveau d’émission plus élevé et portée plus grande)
sont donc des technologies complémentaires [32].
Pour le projet AKUNU, il serait intéressant de tenter de mettre en place une infrastructure avec
des stations météorologiques pouvant discuter entre elles grâce à la technologie Bluetooth Low

Julien Brêchet
Energy afin de consommer peu d’énergie lors de l’envoi de données. Par contre, il faudrait
absolument des cartes Bluetooth de classe 1 pour avoir une portée proche de la centaine de mètres
car la portée maximale des classes 2 et 3 est absolument insuffisante !
Les Raspberry Pi sont compatibles Bluetooth 4.x et BLE. Il pourrait être intéressant de coupler ces
plateformes avec la technologie Bluetooth classe 1 pour tenter de mettre en place un réseau maillé
basse consommation pouvant s’étendre initialement sur quelques centaines de mètres.
9.1.7.4 Wifi
Les protocoles de communication wifi sont très connus et très répandus à travers le monde. Il existe
de nombreux documents expliquant les caractéristiques et les spécificités de cette technologie et
c’est pourquoi je ne vais pas beaucoup détailler dans ce rapport ce qu’est le wifi.
Les principaux éléments à connaître sont les différentes normes existantes IEEE 802.11 concernant
les réseaux sans fil locaux ainsi que leurs caractéristiques principales. J’ai trouvé un tableau
résumant bien cela sur Wikipédia [33]. Le voici représenté dans la figure 15 ci-dessous :
Figure 15 : tableau montrant les protocoles wifi existants ainsi que leurs caractéristiques principales
En observant le tableau ci-dessus, nous pouvons constater qu’il existe deux bandes de fréquence
bien distinctes. Certains protocoles comme le 802.11b et le 802.11g fonctionnent sur la bande ISM
à 2.4GHz alors que les normes 802.11a et ac utilisent la bande U-NII dans les 5GHz. Le protocole
802.11n, et bientôt le 802.11ax, utilise même les deux bandes de fréquence.
Comparé à la technologie Bluetooth, le taux de transfert de données des technologies wifi est
beaucoup plus élevé et la portée est meilleure. Par contre ce sont des protocoles qui consomment
beaucoup plus d’énergie et il serait difficilement possible de mettre en place une solution avec des
équipements sur batteries communiquant en wifi à l’intérieur du réseau AKUNU.
Le wifi est donc beaucoup plus rapide et plus performant que le Bluetooth, mais ce premier
consomme beaucoup plus d’énergie. Quoiqu’il existe depuis 2017 un nouvel amendement wifi basse
consommation et sous-GHz nommé IEEE 802.11ah.
La norme 802.11ah est surnommée Halow et a pour objectif de permettre l’utilisation du wifi pour
l’Internet des objets. Halow fonctionne sur les fréquences 863 à 868MHz en Europe et grâce à ses
fréquences moins élevées, il est plus aisé pour les signaux de conserver leur intégrité lors de leur
passage à travers les obstacles solides, et cela tout en essayant d’envoyer les messages avec une
faible puissance d’émission pour favoriser l’autonomie des appareils wifi. Par contre, à cause de sa
puissance d’émission plus faible, le débit est beaucoup plus faible que celui des autres normes wifi
[34].

Julien Brêchet
La technologie wifi pourrait être utilisée pour la mise en place de la première infrastructure de
test car elle est facile à mettre en place et est compatible avec beaucoup d’équipements comme
les nano-ordinateurs Raspberry Pi ou les plateformes Arduino équipées d’une carte réseau wifi. Il
serait aussi envisageable de mettre en place une solution wifi fonctionnant avec le protocole basse
consommation 802.11ah pour favoriser l’autonomie des stations météorologiques.
9.1.7.5 Réseaux de téléphonie mobile publics

Pour communiquer sur de longues distances, l’utilisation des réseaux de téléphonie mobile est aussi
une solution envisageable. Il existe plusieurs générations et normes possédant chacune ses propres
caractéristiques et spécificités ainsi que ses propres avantages et inconvénients.
9.1.7.5.1 Réseaux GSM / GPRS

GSM est une norme de seconde génération (2G) pour la téléphonie mobile. Elle a été développée
au début des années 90 et peut utiliser différentes bandes de fréquence en fonction du continent
où l’on se trouve. Les bandes GSM 850 et 1900 sont utilisées en Amérique et en Europe ce sont les
bandes GSM 900 et 1800. Un appareil qui fonctionne tant en 900 qu'en 1800 est appelé GSM dual
band [35].
GPRS est dérivé et complémentaire du GSM. Il permet un débit de données plus élevé et est aussi
appelé 2.5G ou 2G+. Il ajoute par rapport au protocole GSM la transmission par paquets. Cette
méthode est plus adaptée à la transmission des données. En effet, les ressources ne sont allouées
que lorsque des données sont échangées, contrairement à GSM où un circuit est établi et les
ressources sont associées pour toute la durée de la communication [36].
Concernant les débits, j’ai trouvé un tableau intéressant sur le site Futura Tech comparant les
débits indicatifs théoriques de différentes générations de réseaux de téléphonie mobile [37]. Il est
représenté dans la figure 16 ci-dessous.
Figure 16 : comparatif des débits des différentes normes de réseaux téléphoniques trouvé sur [37]
Les réseaux GSM, GPRS et EDGE vont gentiment commencer à disparaître au début des années 2020
pour laisser place aux technologies plus récentes telles que la 4G.

Julien Brêchet
9.1.7.5.2 Réseaux UMTS

UMTS est une technologie de téléphonie mobile de troisième génération (3G) qui succède aux
technologies de deuxième génération citées auparavant. La 3G permet un débit de données
descendantes théorique de 1.9Mbps [38] et fonctionne sur différentes fréquences dont les bandes
IMT (2'100MHz) et E-GSM (900MHz) en Europe [39].
Au début des années 2010, la 3G a petit à petit remplacé les technologies de seconde génération
mais a aussi vite été remplacée à son tour par la 4G quelques années plus tard.
9.1.7.5.3 Réseaux 4G LTE

La dernière génération de réseaux cellulaires est appelée LTE et fournit un débit théorique de
téléchargement de 300Mbps. Cela est nettement supérieur aux normes antérieures. Le LTE utilise
des bandes de fréquences hertziennes d’une largeur pouvant varier de 1,4 MHz à 20 MHz dans une
plage de fréquences allant de 450 MHz à 3,8 GHz selon les pays [40].
Le LTE Advanced ou 4G+ sera capable de fournir des débits pics descendants (téléchargement)
supérieurs à 1Gbps à l’arrêt et à plus de 100Mbps pour un terminal en mouvement. Il existe plusieurs
catégories de terminaux pour la 4G dont la 0 et la M qui ont été introduites pour viser le marché
des terminaux à basse consommation et à faible coût ainsi que le marché de l’Internet des objets
[41].
Utiliser des technologies de réseaux cellulaires pour communiquer avec les stations de météorologie
du réseau AKUNU ne me semble pas très optimal. En effet, à part deux catégories précitées de la
norme 4G/4G+, ces technologies consomment pas mal de puissance et il serait difficile de mettre
les stations sur batteries. Mais il pourrait être intéressant d’avoir quelques appareils intermédiaires
dans le réseau qui soient branchés sur le secteur électrique et qui récoltent les données envoyées
par les stations afin de les envoyer ensuite par la 4G sur un serveur central ou une instance Cloud.
Pour chaque nœud du réseau voulant communiquer par réseau cellulaire, il faut payer un
abonnement de plusieurs dizaines de francs suisses par mois, les tarifs pouvant beaucoup varier
selon le pays. Cela appuie le fait que si nous voulons utiliser de la 4G ou une autre technologie de
téléphonie mobile, il faudrait restreindre l’utilisation de la 4G à seulement quelques nœuds qui
récolteraient les données des stations météorologiques avoisinantes pour ensuite les envoyer sur
un serveur de centralisation des données.
La couverture des réseaux 4G est de plus en plus étendue et englobe toujours plus de pays.
Actuellement, en 2018, les pays visés par le projet AKUNU possèdent chacun une couverture de la
4G dans une bonne partie de leurs contrées.
9.2 Sélection du matériel et des technologies

Pour concevoir la première infrastructure de test, il a été décidé de commencer au plus simple en
utilisant la technologie wifi pour communiquer entre les différents éléments du réseau. En effet,
en commençant par utiliser la technologie WLAN, il sera plutôt aisé de mettre en place un réseau
et beaucoup de plateformes possèdent déjà une interface compatible WLAN. Il ne sera donc pas
nécessaire pour l’instant d’acheter des interfaces spécialisées utilisant des protocoles moins
répandus.
Concernant les plateformes, j’ai sélectionné des Raspberry Pi pour plusieurs raisons. La première
étant que je connaissais déjà ce genre de plateforme avant le début de ce travail et la seconde
étant que ces nano-ordinateurs permettent d’effectuer de nombreuses tâches et sont donc
beaucoup plus flexibles que des Arduino ou d’autres fabricants de cartes avec microcontrôleurs

Julien Brêchet
embarqués. De trois, ils possèdent aussi une interface WLAN intégrée qui leur permettra de
communiquer au travers du réseau wifi AKUNU.
Au début, les Raspberry Pi seront branchés sur secteur mais j’ai sélectionné le modèle Zero W pour
les stations météorologiques pour favoriser une mise en place ultérieure d’une solution de stations
sur batteries afin de tenter d’avoir des stations avec une autonomie acceptable.
Les stations communiqueront avec un serveur de fichier qui sera installé sur un Raspberry Pi 3
modèle B+ qui récoltera les données des capteurs envoyées par les stations Raspberry Pi Zero W.
Tous ces dispositifs se trouveront dans un réseau WLAN distribué par un point d’accès wifi.
Les deux capteurs sélectionnés pour la première partie du travail de Bachelor sont le capteur
Adafruit BME 280 pour récolter la température, l’humidité environnante et la pression
barométrique ainsi que le capteur Adafruit Ultimate GPS pour récupérer le temps, la date, la
longitude, la latitude et l’altitude en fonctionnant de satellites GPS.
Durant la seconde partie du travail de Bachelor, des capteurs supplémentaires seront installés et
testés. La possibilité de concevoir des cartes PCB sera étudiée et le programme de récolte de
données sera amélioré au fur et à mesure. Si le temps le permet, la mise en place d’une instance
sur un Cloud est envisageable pour fournir aux météorologues un accès facile à toutes les données
atmosphériques récoltées par l’infrastructure de test du réseau AKUNU.
9.3 Première phase de conception

La première phase de conception consiste à mettre en place une infrastructure de test simple mais
fonctionnelle. Le réseau AKUNU est composé de :
 1 Raspberry Pi 3 Modèle B+ faisant office de serveur de fichiers

 1 Raspberry Pi Zero W qui est la station météorologique qui communique avec les capteurs
 1 capteur Adafruit BME 280 qui permet à la station de récolter des données sur la
température, l’humidité et la pression barométrique
 1 carte de dérivation Adafruit Ultimate GPS permettant à la station de récupérer le temps
UTC ainsi que la latitude et la longitude auxquelles la carte se trouve
 1 routeur wifi Linksys permettant d’établir et de configurer un réseau WLAN AKUNU.
Comme expliqué dans un chapitre précédent, il a été décidé de mettre premièrement en place un
simple réseau WLAN dans lequel pourront communiquer les appareils du réseau AKUNU. Pour ce
faire, l’école m’a prêté un routeur faisant office de point d’accès wifi et avec ce routeur j’ai
configuré un réseau WLAN local, actuellement sans connexion vers l’extérieur. Si l’utilisation d’un
réseau wifi est toujours d’actualité après la remise du rapport intermédiaire, il serait envisageable
de demander à l’école de m’allouer une plage d’adresses IP afin que les appareils du réseau WLAN
AKUNU puissent avoir accès à Internet.

Julien Brêchet
Figure 17 : Exemple de topologie WLAN pour le réseau AKUNU
La figure 17 ci-dessus montre un exemple de topologie pour un réseau WLAN contenant un point
d’accès wifi, un serveur de fichiers ainsi que quatre stations météorologiques. Les stations récoltent
des données atmosphériques à l’aide de capteurs et utilisent une carte de dérivation GPS pour
obtenir le temps UTC ainsi que la longitude et la latitude de la station.
Le diagramme de flux en bloc représenté dans la figure 18 montre le processus de récolte des
données atmosphériques et GPS. La station météorologique envoie toutes les X secondes/minutes
une requête aux différents capteurs pour récupérer la température, l’humidité dans l’air, la
pression atmosphérique ainsi que des données relatives au GPS comme le temps UTC, la latitude et
la longitude. Ensuite ces données sont stockées localement dans un fichier de logs, un simple fichier
texte par exemple. Quand un certain nombre de ces données sont récupérées, le fichier est envoyé
sur le serveur de fichiers et pendant ce temps un nouveau fichier est créé localement sur la station
météorologique et il va stocker à son tour les nouvelles données récupérées des capteurs.
Selon le ou les protocoles de communication qui seront utilisés lors de la seconde partie du travail
de Bachelor, la taille des paquets de données transmis peut être limitée. C’est pourquoi il a été
décidé de mettre en place un processus qui va, après avoir écrit un certain nombre de données
dans un fichier, envoyer ce fichier au serveur et commencer à écrire dans un nouveau fichier. Ainsi,
la taille des fichiers transmis au serveur Raspberry Pi 3 B+ peut être facilement gérée afin de ne
pas avoir de fichiers trop volumineux.
Le diagramme pourra être mis à jour en cours de projet en fonction des modifications qui seront
opérées et des différents capteurs mis en place. Par exemple, nous pourrions mettre en place un
capteur de pluie qui détecterait de lui-même quand il devrait envoyer des données à la station, car
ça ne servirait à rien qu’il envoie des données quand il ne pleut pas. Dans ce cas-ci, l’envoi de
requêtes deviendrait bidirectionnel et le diagramme de la figure 18 devrait être modifié.

Julien Brêchet
Figure 18 : Diagramme de flux en bloc indiquant comment les données sont récoltées et stockées
Par la suite, il sera par exemple possible de mettre en place une instance sur le Cloud à laquelle le
serveur de fichiers pourra envoyer tous les logs qu’il a reçus des stations météorologiques. La
technologie de communication à utiliser entre le serveur de fichiers et l’instance Cloud sera
discutée dans la seconde phase du travail de Bachelor.
Actuellement, il est prévu de brancher tous les équipements du réseau AKUNU sur le secteur
électrique. Mais, grâce à leur faible consommation, les plateformes Raspberry Pi Zero W ont été
sélectionnées pour faire office de stations météorologiques pour tenter de les mettre plus tard sur
batteries afin de pouvoir les rendre autonomes sur plusieurs jours ou semaines, voire plusieurs mois.
9.4 Première phase de test

9.4.1 Mise en place d’un réseau wifi
La première étape consiste à mettre en place un réseau wifi. J’ai demandé à l’école de me fournir
un routeur qui fait office de point d’accès wifi et j’ai configuré le réseau sans fil. La figure 19 ci-
dessous montre le routeur wifi en question.

Julien Brêchet
Figure 19 : Point d'accès Linksys Wireless G
Le point d’accès qui m’a été fourni est un Linksys Wireless G. La configuration que j’ai mise en
place est assez standard. Les caractéristiques principales sont les suivantes :
 Nom du routeur : R1
 Modèle du routeur : Linksys WRT54G/GL/GS
 Version du firmware : DD-WRT v24-sp2 (10/10/09) mini - build 13064
 Adresse MAC : C0:C1:C0:59:B8:6E
 SSID : AKUNU-LAN1
 Mode de sécurité : WPA2 Personal avec algorithme AES
 Plage d’adresse IP du réseau : 192.168.1.1/24
 Réseau wifi G-Only
 Canal utilisé : 11
L’ensemble de la configuration du réseau wifi est consultable en se connectant sur le routeur à
l’adresse 192.168.1.1.
Il a été décidé de mettre en place un réseau LAN de classe C car actuellement, pour l’infrastructure
de test, il n’y aura au maximum que cinq ou six dispositifs. Dans le cas très peu probable où il y
aurait plus de 254 équipements au sein du réseau, il serait possible de modifier l’adresse IP du
réseau ainsi que son masque de sous-réseau afin d’utiliser un réseau LAN de classe B ou de classe
A. J’ai configuré le wifi pour qu’il utilise le canal 11 afin de limiter au maximum le risque
d’interférences (les trois canaux recommandés sont le 1, le 6 et le 11) et pour qu’il fonctionne
uniquement avec la norme 802.11g à 2.4GHz. Les Raspberry Pi sont compatibles avec la norme
802.11g, donc je préfère éviter la cohabitation avec la norme 802.11b et forcer tous les
équipements à se parler en 802.11g.
9.4.2 Installation et configuration du serveur de fichiers

Pour mettre en place le serveur de fichiers, j’ai choisi d’utiliser un Raspberry Pi 3 B+ qui est
actuellement le modèle Raspberry le plus performant du marché. J’utilise une carte micro SD de
16GB, ce qui est plus que suffisant pour stocker des milliers de données GPS et météorologiques.

Julien Brêchet
Le système d’exploitation que j’utilise est le Raspbian Stretch Desktop. Raspbian Stretch est la
dernière version du système d’exploitation officiel de Raspberry qui est basé sur la distribution
Debian et optimisé pour fonctionner sur un Raspberry Pi. J’ai choisi d’utiliser au début la version
Desktop car j’estime avoir suffisamment de place disponible avec ma carte SD de 16GB et la
configuration des réseaux wifi est plus simple avec une interface graphique. Mais par la suite il
serait envisageable d’utiliser une image épurée sans interface graphique et où tous les logiciels
superflus seraient désinstallés et les processus inutiles seraient désactivés. Cela permettrait
d’économiser quelques GB d’espace disque et d’augmenter légèrement les performances du
Raspberry Pi.
J’ai aussi autorisé les connexions SSH afin de pouvoir me connecter à distance à partir de mon
ordinateur portable. Pour ce faire, j’ai utilisé la commande sudo raspi-config, menu « 5 Interfacing
Options », interface « P2 SSH » et j’ai autorisé les connexions SSH sur le Raspberry Pi. J’ai configuré
le nom du serveur en AKUNU-server et lui ai mis une adresse IP statique 192.168.1.10 en éditant
le fichier « /etc/dhcpcd.conf » selon la figure 20 ci-dessous.
Figure 20 : configuration de l'interface wlan0 dans le fichier dhcpcd.conf
9.4.3 Configuration du serveur SMB

Une fois le Raspberry Pi 3 B+ configuré, il a été décidé d’installer un serveur de fichiers SMB pour
pouvoir stocker les données atmosphériques récoltées par les stations météorologiques. Mais
puisque le système d’exploitation Raspbian est basé sur Unix, il faut en fait installer un serveur
Samba. Samba est un logiciel d'interopérabilité qui implémente le protocole propriétaire SMB/CIFS
de Microsoft Windows dans les ordinateurs tournant sous le système d'exploitation Unix et ses
dérivés. Il s'agit d'une réimplémentation des protocoles SMB/CIFS sous GNU/Linux et d'autres
variantes d'Unix [42].
Le serveur SMB permet de donner l’accès aux clients du réseau à des systèmes de fichiers, mais
aussi à d’autres ressources comme des imprimantes. Le client peut avoir ses propres disques qui ne
seront pas partagés et peut accéder en même temps aux disques et imprimantes partagés par le
serveur [43]. Les ressources partagées sont accessibles à partir d'une adresse utilisant la convention
UNC de type : \\serveur\partage\chemin\nom_fichier
Mettre en place un partage SMB semble être une bonne solution car il sera possible de stocker
facilement les fichiers de logs générés par les stations de météorologie. Il serait aussi envisageable
de mettre en place un système de gestion de base de données (SGBD) mais ce genre de solution
peut parfois s’avérer coûteux en terme de consommation des ressources. De plus, selon le protocole
de communication utilisé entre les stations et le serveur, il ne serait pas toujours envisageable de
communiquer directement à la base de données les informations récoltées lors de chaque requête
émise aux capteurs atmosphériques et GPS.
Pour configurer le Raspberry Pi en serveur de fichiers, j’ai suivi un tutoriel trouvé sur le site officiel
de Raspberry qui explique comment installer un serveur de fichiers Samba [44]. Il faut
premièrement mettre à jour la liste des paquets disponibles pour l’utilitaire d’installation APT avec
la commande sudo apt-get update puis ensuite installer samba avec sudo apt-get samba samba-
common-bin.

Julien Brêchet
Ensuite, il faut créer le dossier où nous souhaitons stocker nos fichiers de données météorologiques
et le partager. On utilise la commande sudo mkdir -m 1777 /share pour créer le dossier « share »
et le partager.
Une fois le dossier créé, il faut éditer le fichier « smb.conf » qui a été créé lors de l’installation de
samba. On utilise la commande sudo nano /etc/samba/smb.conf pour l’éditer.
On édite la section [share] pour paramétrer le partage SMB selon les informations de la figure 21.
Figure 21 : Paramétrage du partage SMB
Ensuite, il faut configurer les utilisateurs autorisés ainsi que leur mot de passe pour se connecter
au partage SMB. Dans notre cas, il nous faut ajouter l’utilisateur pi : sudo smbpasswd -a pi
Une fois le mot de passe configuré pour le compte pi, il faut relancer le service Samba avec la
commande sudo /etc/init.d/samba restart. A partir de maintenant, Samba va démarrer
automatiquement au démarrage du Raspberry Pi et notre serveur de fichiers est désormais
opérationnel. La figure 22 montre qu’il suffit d’un simple chargeur avec câble micro USB pour
alimenter et faire tourner le serveur de fichiers Raspberry Pi 3 B+.
Figure 22 : Serveur de fichiers Raspberry Pi 3 B+
9.4.4 Installation et configuration de la station météorologique

Pour les stations météorologiques, il a été décidé d’utiliser des Raspberry Pi Zero W car c’est un
modèle de nano-ordinateur qui consomme beaucoup moins d’électricité que les Raspberry Pi
standards. En mettant les stations sur batteries, elles auront une meilleure autonomie que si elles
tournaient par exemple sur un Raspberry Pi 3 Modèle B+ comme c’est le cas pour le serveur de
fichiers. Les performances du Raspberry Pi Zero W sont certes un peu plus faibles que celles de son
confrère mais en mettant en place l’infrastructure de test, nous allons voir si nous avons besoin de
performances supplémentaires ou bien si ces plateformes sont suffisamment puissantes pour
récolter des données atmosphériques et GPS de façon adéquate.

Julien Brêchet
Tout comme pour le serveur de fichiers, j’utilise le système d’exploitation Raspbian Stretch
Desktop. J’utilise aussi une carte micro SD de 16GB que j’ai préalablement formatée avec le logiciel
SD Card Formatter et sur laquelle j’ai flashé l’image Raspbian Stretch à l’aide du logiciel Etcher.
Ensuite, j’ai autorisé les connexions SSH en effectuant la même procédure que pour le serveur de
fichiers. J’ai nommé la station AKUNU-station1 et lui ai fixé une adresse statique 192.168.1.11
avec un masque de sous-réseau /24.
9.4.5 Installation du client SMB

Pour pouvoir communiquer avec le serveur SMB, j’ai installé le client smbclient. Je l’ai tout d’abord
installé sur le serveur de fichiers pour tester le transfert de fichiers en local puis une fois que les
tests se sont avérés concluants, j’ai procédé à l’installation du client sur la station météorologique.
J’ai installé smbclient à l’aide de la commande sudo apt-get install smbclient et j’ai ensuite créé
dans le répertoire de l’utilisateur pi un fichier « .smbclient » qui contient le login et le mot de
passe pour se connecter au partage SMB. La première ligne du fichier indique le nom de l’utilisateur
autorisé à se connecter, pi dans notre cas, tandis que la seconde correspond au mot de passe utilisé
pour se connecter au partage.
En utilisant la commande man smbclient et en consultant une page du site Coderwall [45], j’ai pu
trouver les informations dont j’avais besoin pour définir une commande qui me permette d’envoyer
un fichier au serveur en utilisant le fichier « .smbclient » pour s’authentifier automatiquement,
c’est-à-dire sans que je doive intervenir pour entrer un mot de passe. La commande est la suivante :
smbclient -A /home/pi/.smbclient //AKUNU-server/share -c 'put "fichierAEnvoyer.txt"'
9.4.6 Installation du capteur Adafruit BME 280

Pour installer le capteur Adafruit BME 280 et établir une connexion avec la station météorologique,
j’ai suivi un tutoriel que j’ai trouvé sur le site xDevs [46]. Premièrement, j’ai acheté un kit
d’extension GPIO me permettant de relier les pins GPIO du Raspberry Pi Zero W avec la plaque de
test. Il est possible de trouver ce genre de kits sur différents sites comme Digitec ou Amazon. La
figure 23 nous montre l’un de ces kits d’extension trouvé sur Amazon [47] contenant un câble IDE
40 pins, une carte d’extension en forme de T et une plaque d’essai à 400 points. Le câble IDE
permet de relier les 40 pins GPIO du Raspberry Pi à la carte en T pour pouvoir établir la connexion
avec la plaque de test.

Julien Brêchet
Figure 23 : Contenu d'un kit d'extension GPIO trouvé sur Amazon [47]
En suivant le tutoriel, j’ai tout d’abord dû télécharger deux librairies Python écrites et fournies par
Adafruit me permettant de contacter le capteur BME 280. Les librairies Adafruit_Python_GPIO et
Adafruit_Python_BME280 sont disponibles sur GitHub et sont publiées par la société Adafruit [48],
[49]. Après les avoir clonées avec Git, j’ai installé leurs modules pour Python avec la commande
sudo python setup.py install pour chacune des deux librairies Python.
J’ai connecté les pins du Raspberry Pi et du capteur BME 280 selon le tableau ci-dessous :
Pin du Raspberry Pi Pin du capteur BME 280

3V3 3Vo
GND GND
SCL1 SCK
SDA1 SDI
La communication entre la station et le capteur BME 280 s’effectue avec un bus I2C. Il m’a fallu
activer le chargement automatique du kernel module I2C pour que la communication I2C avec le
capteur puisse s’activer automatiquement au démarrage du Raspberry Pi. Pour ce faire, j’ai utilisé
la commande sudo raspi-config et je suis allé dans le menu « 5 Interfacing Options », interface
« P5 I2C » et j’ai activé l’interface I2C.
I2C est un bus série synchrone bidirectionnel half-duplex, où plusieurs équipements, maîtres ou
esclaves, peuvent être connectés au bus. Les échanges ont toujours lieu entre un seul maître et un
ou plusieurs esclaves, toujours à l'initiative du maître. Cependant, rien n'empêche un composant
de passer du statut de maître à esclave et réciproquement. La connexion est réalisée par
l'intermédiaire de deux lignes [50] :

Julien Brêchet
 SDA : ligne de données bidirectionnelle

 SCL : ligne d'horloge de synchronisation bidirectionnelle
Il ne faut pas non plus oublier la masse qui doit être commune aux équipements. J’ai trouvé sur
Wikipédia un graphique (figure 24) expliquant brièvement comment fonctionne le codage des bits
avec un bus I2C. Le niveau (« HIGH » ou « LOW ») de la ligne SDA doit être maintenu stable pendant
le niveau « HIGH » sur la ligne SCL pour la lecture du bit [50].
Figure 24 : codage d'un bit I2C trouvé sur Wikipédia [50]
Pour tester si la connexion fonctionne, nous pouvons utiliser la commande i2cdetect –y 1 sur la
station et vérifier que le capteur est présent à l’adresse 0x77. Si c’est le cas comme l’indique la
figure 25, il est possible de tester le fonctionnement du capteur avec les exemples de scripts fournis
dans la librairie Adafruit_Python_BME280.
Figure 25 : vérification que la communication I2C fonctionne avec le capteur
9.4.7 Installation de la carte de dérivation Adafruit Ultimate GPS

Une fois le capteur BME 280 fonctionnel, je me suis attaqué à l’installation de la carte de dérivation
Adafruit Ultimate GPS. Il est possible de mettre une pile Lithium CR1220 pour alimenter le GPS
mais ici j’utilise directement l’alimentation fournie par le nano-ordinateur.
Pour installer et connecter la carte de dérivation Adafruit Ultimate GPS, j’ai suivi un tutoriel que
j’ai trouvé sur le site officiel d’Adafruit [51]. Il existe aussi un complément du tutoriel pour pouvoir
brancher le capteur en utilisant une liaison série UART [52]. J’ai connecté les pins du Raspberry Pi
Zero W et de l’Adafruit Ultimate GPS selon le tableau ci-dessous :
Pin du Raspberry Pi Pin du GPS

5V0 VIN
GND GND
TXD0 RX
RXD0 TX

Julien Brêchet
Il aurait été possible de connecter le GPS avec la technologie TTL mais je n’ai pas d’adaptateur
série USB TTL à disposition. A la place, j’envoie des trames UART sur une liaison série entre le
Raspberry Pi et le GPS. J’ai trouvé sur Wikipédia un graphique et une explication sur la constitution
d’une trame UART [53]. Le graphique est affiché dans la figure 26 ci-dessous :
Figure 26 : Exemple d'une trame UART trouvé sur Wikipédia [53]
Le bit « start » est toujours à 0 et sert à la synchronisation du récepteur. La taille des données est
comprise entre 5 et 9 bits et les bits sont envoyés en format Little Endian, c’est-à-dire du bit de
poids le plus faible au bit de poids le plus fort. Le bit de parité est optionnel et le bit « stop » est
toujours à 1 et sa durée varie entre 1, 1.5 et 2 coups d’horloge (défini par l’utilisateur) [53].
Une fois les pins correctement connectées, il faut installer un daemon GPS qui puisse parser les
données brutes du GPS et il est possible d’utiliser pour cela l’utilitaire gpsd qui fait office
d’interface entre l’application et le hardware du GPS [51]. Pour installer gpsd, il faut entrer la
commande suivante : sudo apt-get install gpsd gpsd-clients python-gps
Une fois gpsd installé, il faut éditer le fichier « /boot/cmdline.txt » avec la commande sudo nano
/boot/cmdline.txt et supprimer toutes les valeurs console=tty**** à part console=tty1.
Ensuite, il faut éditer le fichier « /boot/config.txt » et ajouter la ligne enable_uart=1 à la fin du
fichier. Grâce à cette ligne, nous activons explicitement le port série sur les pins GPIO du Raspberry
Pi [52]. Ensuite, il faut redémarrer le nano-ordinateur afin qu’il prenne en compte la modification.
Une fois la station redémarrée, nous nous assurons qu’aucun processus gpsd n’est en train de
tourner et nous le tuons le cas échéant. La commande est la suivante : sudo killall gpsd
Maintenant, il faut encore entrer la commande sudo gpsd /dev/ttyS0 -F /var/run/gpsd.sock pour
forcer gpsd à utiliser la liaison série UART. Il est possible de tester si le GPS fonctionne avec la
commande cgps –s ou cgps tout court.
La figure 27 montre le branchement des capteurs BME 280 et GPS sur la plaque d’essai.

Julien Brêchet
Figure 27 : Branchement des capteurs BME 280 et GPS sur la plaque d'essai
9.4.8 Processus de récolte des données

Maintenant que toutes les connexions sont établies entre la station et les capteurs, j’ai écrit un
script Python qui récupère les données atmosphériques du capteur BME 280 ainsi que les données
du GPS pour aller les écrire sous forme de logs dans un fichier texte. Pour écrire ce script, je me
suis basé sur les exemples fournis dans la librairie Adafruit_Python_BME280 et sur un script Python
écrit par un certain Dan Mandle [54] qui permet de récupérer des données GPS avec gpsd.
J’ai écrit ce script pour qu’il fonctionne de façon similaire à ce qui est défini dans le diagramme
de flux de la figure 18. Un thread GpsPoller est lancé pour aller récupérer les données du GPS et
toutes les 60 secondes j’envoie une requête au GPS pour avoir la latitude, la longitude et le temps
UTC. Par la même occasion, je vais récupérer la température, la pression atmosphérique ainsi que
l’humidité sur le capteur BME 280.
J’écris ensuite toutes ces données que j’ai récoltées sous forme d’une ligne de logs dans un fichier
texte. Chaque donnée est séparée par une virgule selon l’ordre cité dans le paragraphe précédent.
A partir d’un certain nombre de logs, pour éviter que le fichier devienne trop lourd, j’arrête
d’écrire dans ce fichier et j’en crée un nouveau dans lequel je vais aller écrire de nouvelles lignes
de logs. Par la même occasion, j’active un thread qui va envoyer le fichier sur le partage SMB du
serveur de fichiers.
Ce script me permet de récupérer les données dont j’ai besoin mais il n’est pas encore optimisé au
niveau de la charge des processus. En effet, je pourrais optimiser la manière dont je vais récupérer
les données du GPS. Au lieu de faire tourner un thread en permanence, je pourrais peut-être en
lancer un une fois de temps à autre pour récupérer les nouvelles coordonnées GPS ainsi que le
temps UTC pour synchroniser l’horloge interne de la station. Idem pour l’envoi du fichier sur le
serveur. Je pourrais faire tourner le thread uniquement lorsque j’ai besoin d’effectuer l’envoi d’un
fichier sur le serveur.
Suite à une discussion avec Monsieur Rubinstein, après la remise du rapport intermédiaire je vais
étudier comment décomposer la récolte des données de manière plus générique pour pouvoir
ensuite coder des scripts Python me permettant d’aller récupérer uniquement les données qui

Julien Brêchet
m’intéressent et qui me permettent aussi de paramétrer la fréquence à laquelle je veux récolter

ces données. Contrairement à ce que fait le script actuel qui va récolter toutes les données en
même temps à une fréquence définie en dur, il faudrait pouvoir aller chercher uniquement les
informations qui nous intéressent et aussi pouvoir modifier la fréquence de récupération
indépendamment pour chaque type de donnée.
Pendant que j’effectuais mes tests, j’ai constaté qu’à l’intérieur des bâtiments de la HEIG-VD du
site de Cheseaux je ne réussissais parfois pas à détecter de satellites avec ma carte GPS. Cela est
probablement dû à la structure de ces bâtiments qui ne facilite pas la propagation des ondes
satellites. J’ai installé une antenne passive UFL 9mm x 9mm pour tenter d’améliorer la détection
des satellites mais ce n’est toujours pas suffisant. Par contre quand j’ai effectué des tests en
extérieur ou chez moi, je n’ai rencontré aucun problème de détection. Le GPS arrivait toujours à
se connecter aux satellites pour récupérer les données.
La figure 28 ci-dessous nous montre comment l’antenne passive est branchée sur la carte GPS. Elle
est branchée sur un connecteur UFL de la carte.
Figure 28 : Ajout d'une antenne passive UFL 9mm x 9mm pour améliorer la détection des satellites
9.5 Seconde phase de projet

La seconde phase du projet de Bachelor dure six semaines et se déroule du lundi 18 juin 2018 au
vendredi 27 juillet 2018. Durant cette phase, le travail s’effectue à plein temps, ce qui équivaut à
environ quarante heures par semaine.
La seconde phase du travail de Bachelor comprend entre autres l’installation de nouveaux types de
capteurs qui seront testés et la nouvelle conception du processus de récolte de données qui sera
étudiée à nouveau afin d’y apporter des améliorations.
9.5.1 Modifications de conception

9.5.1.1 Modification du processus de récolte de données
Le processus de récolte des données atmosphériques et GPS a été revu et amélioré. Maintenant,
un thread différent est créé pour chaque type de données à récolter. Chacun de ces threads va

Julien Brêchet
récolter un certain type de donnée et va stocker les valeurs obtenues dans des fichiers de logs
séparés. Par exemple, les données concernant la température seront stockées séparément des
données de pression, d’humidité et de localisation GPS. Pour reconnaître le type des données
stockées dans le fichier, un indice à deux chiffres est utilisé. Le tableau ci-dessous indique quel
indice correspond à quel type de donnée.
Indice Type de donnée

00 Température
01 Pression barométrique
02 Humidité
03 Localisation GPS
04 Vitesse du vent
05 Champs électromagnétiques
La figure 29 illustre le fonctionnement du nouveau processus de récolte des données. Chaque thread
de récolte va récupérer les données auprès du capteur concerné et lorsque le nombre de logs
stockés pour un certain type de donnée atteint une certaine valeur, un nouveau thread est appelé
pour envoyer le fichier de logs sur le partage SMB du serveur de fichiers. Pendant ce temps, le
thread de récolte ouvre un nouveau fichier dans lequel il va écrire les prochains logs qu’il va
récupérer.
Les threads récoltant la température, la pression barométrique et l’humidité ambiante
communiquent avec le capteur Adafruit BME 280 par le protocole I2C. Chaque type de donnée est
récolté de manière indépendante en fonction des compteurs d’intervalle paramétrés pour chacun
d’entre eux. Mais il faut savoir que les trois types de données sont retournés par le capteur dans
un seul et même vecteur et que ce dernier est uniquement mis à jour lors de l’appel de la fonction
qui va récupérer la température (fonction read_temperature() fournie par la librairie
Adafruit_Python_BME280). Cela signifie que si nous paramétrons pour la pression et/ou l’humidité
une fréquence d’échantillonnage plus petite que celle pour récolter la température, les données
de pression et/ou d’humidité récoltées ne seront pas actualisées tant que le thread qui récupère
la température n’a pas mis à jour le vecteur de retour du capteur BME 280 en appelant la fonction
read_temperature(). Il est donc par exemple inutile de récolter la pression et/ou l’humidité chaque
seconde si la température n’est récupérée que toutes les soixante secondes. Dans ce cas-ci, nous
aurions les mêmes valeurs pour la pression et/ou l’humidité pendant une minute car le vecteur de
retour n’est mis à jour que toutes les soixante secondes. Pour avoir des données cohérentes pour
la pression et l’humidité, il faut que l’intervalle de récolte de la température soit inférieur ou égal
à ceux de la pression et de l’humidité.
Concernant la localisation GPS, un thread récupère en boucle dans une variable les données du
capteur GPS en UART. Le thread de récolte va récupérer périodiquement la latitude et la longitude
auxquelles se trouve la station météorologique en accédant à la variable mise à jour par le thread
GPS Poller. Si la récupération des données de localisation échoue plus de dix fois, le thread attend
un certain temps défini par une autre variable utilisée en cas d’échec, possédant un temps
d’attente généralement plus court que la fréquence standard de localisation. Ainsi, en cas
d’incapacité momentanée du GPS à obtenir le positionnement GPS de la station, il est possible de
retenter une localisation en utilisant un intervalle d’attente plus court.
Pour obtenir la vitesse du vent récupérée analogiquement par l’anémomètre, il faut mettre en
place et configurer un convertisseur analogique-numérique pour pouvoir numériser la tension
analogique de sortie de l’anémomètre. Une fois numérisée, la vitesse est récupérée par le thread

Julien Brêchet
responsable de données du vent et calibrée selon les normes fournies par le constructeur de
l’anémomètre.
La capture de la force des champs électromagnétiques se fait via un câble coaxial et les données
récupérées doivent tout comme pour celles de l’anémomètre être numérisées avec un convertisseur
analogique-numérique.
Figure 29 : Diagramme de flux en bloc illustrant le fonctionnement du nouveau processus de récolte des données
Le thread de gestion des compteurs de récolte est responsable d’écouter sur un port TCP afin
d’ouvrir et de gérer des connexions TCP avec des machines distantes. Il récupère le nom du
compteur à modifier ainsi que la nouvelle valeur à lui attribuer. Si le nom du compteur passé en
paramètre est erroné, le thread avertit la machine distante que le compteur n’existe pas. Mais

Julien Brêchet
dans le cas où le compteur existe, il attribue la nouvelle valeur au compteur et avertit la machine
distante que les modifications ont été effectuées.
Grâce à ce thread, il est possible depuis une machine distante de modifier séparément pour chaque
type de donnée les intervalles de récupération des valeurs ainsi que le nombre maximal de logs à
stocker dans un fichier avant de l’envoyer au serveur de fichiers.
Chaque thread de récolte écrit les valeurs qu’il récupère dans un fichier et lorsque le compteur de
logs dépasse la valeur du nombre maximal de logs à stocker, le fichier est envoyé sur le partage
SMB du serveur de fichiers. Chaque fichier possède un nom qui respecte le format suivant :
<Version>_<Nom de la station>_<Indice>_<Compteur de fichiers>
Le numéro de version est utilisé principalement pour le développement du script de récolte des
données. La version permet d’identifier facilement quel fichier de logs a été écrit lors de quelle
phase de test et permet de comparer plus facilement les différences entre chaque version pour
vérifier le résultat des nouvelles améliorations qui ont été développées.
Le nom de la station permet d’identifier la station qui a récolté les logs inscrits dans le fichier.
L’indice quant à lui permet de distinguer le type des données stockées dans le fichier. Une
explication détaillée est fournie au début de ce chapitre 9.5.1.1.
Le compteur de fichiers est incrémenté de 1 à chaque ouverture d’un nouveau fichier. Prenons
exemple pour les données de température de la station 1 en l’état de la version 24 du script. Le
premier fichier ouvert au lancement du script va s’appeler V24_STA01_00_1.txt. Lorsque le fichier
devient volumineux et que le compteur de logs dépasse la valeur du nombre maximal de logs de
température à stocker, le fichier est fermé et envoyé sur le partage SMB du serveur de fichiers.
Pendant ce temps, le script incrémente le compteur de fichiers et le concatène au nom qui va être
utilisé pour ouvrir le fichier suivant qui va stocker les nouveaux logs. Le fichier va s’appeler
V24_STA01_00_2.txt, les suivants s’appelleront V24_STA01_00_3.txt, V24_STA01_00_4.txt et ainsi
de suite…
9.5.1.2 Modification de la topologie WLAN

La topologie du réseau WLAN a été un peu modifiée. Maintenant, le Raspberry Pi 3 Modèle B+ qui
servait uniquement de serveur de fichiers fait aussi office de routeur wifi en créant lui-même son
réseau local AKUNU et fournit un point d’accès wifi pour les autres dispositifs voulant se joindre au
réseau AKUNU. Le routeur wifi possède aussi une autre interface avec laquelle il peut se connecter
à un réseau disposant d’un accès vers l’extérieur. Ainsi, les appareils du réseau AKUNU peuvent
avoir un accès à Internet.
La principale raison d’avoir décidé de supprimer le routeur Linksys est que je n’ai pas réussi à le
configurer pour qu’il puisse à la fois servir de point d’accès au réseau AKUNU et pouvoir se
connecter à un autre réseau disposant d’un accès Internet. Même après de nombreuses recherches,
je ne sais toujours pas pourquoi je n’arrivais pas à connecter le routeur Linksys à un autre réseau.
Du coup, j’ai décidé de m’en débarrasser et d’intégrer ce service dans le Raspberry Pi faisant déjà
office de serveur de fichiers.
La figure 30 affiche au centre le Raspberry Pi 3 qui fait maintenant office à la fois de routeur wifi
et de serveur de fichiers.

Julien Brêchet
Figure 30 : Nouvelle topologie du réseau WLAN AKUNU
9.5.2 Seconde phase d’implémentation

9.5.2.1 Nouveau processus de récolte et de gestion des données
Comme il a été expliqué dans le chapitre 9.5.1.1, un nouveau processus de récolte et de gestion
des données a été conçu et implémenté. Maintenant, les données de chaque type sont récoltées
de manière indépendante et stockées dans des fichiers de logs séparés. Ce nouveau fonctionnement
permet de gérer indépendamment la récolte des données pour chaque type sans interférer avec les
configurations des autres types.
9.5.2.2 Synchronisation de l’horloge interne de la station météorologique

Au début, une synchronisation rudimentaire de l’horloge interne a été mise en place pour mettre
à jour l’horloge de la station. Le processus consistait à récupérer le temps UTC du GPS à l’aide du
thread GPS Poller et de mettre à jour l’heure de la station via une commande Bash. Ce processus
pouvait prendre plusieurs centièmes de secondes, et si nous ajoutons les imprécisions de
synchronisation du GPS en lui-même, l’écart de synchronisation était trop important pour être jugé
comme étant fiable. Du coup une nouvelle solution a dû être étudiée.
9.5.2.3 Amélioration du système de synchronisation du temps avec NTP

Après de nombreuses recherches, une solution a été trouvée pour tenter d’améliorer la
synchronisation de l’horloge interne de la station météorologique. Pour ce faire, une solution
combinant des daemons gpsd et ntpd va être mise en place. Pour configurer ces daemons, j’ai suivi
un tutoriel que j’ai trouvé sur le site autonomic.guru [55].

Julien Brêchet
Le but est de configurer un daemon NTP qui va récupérer le temps UTC du capteur GPS, synchroniser
le temps de la station avec celui du GPS et définir la station en tant que stratum 1 pour que les
autres dispositifs du réseau AKUNU puissent éventuellement venir synchroniser leur horloge avec le
temps de la station.
Pour commencer, il faut disposer d’une connexion à Internet pour mettre à jour les paquets
disponibles pour une installation avec l’utilitaire APT. Une fois la commande sudo apt-get update
exécutée, il faut installer différents paquets dont nous avons besoin avec la commande
sudo apt-get install gpsd gpsd-clients python-gps pps-tools. A noter que certains paquets ont déjà
été installés lors de la première phase du travail de Bachelor.
Ensuite, il faut activer le support du kernel module PPS pour les interfaces GPIO. Pour ce faire, il
faut éditer le fichier « /boot/config » de la station et y ajouter les lignes suivantes :
dtoverlay=pps-gpio,gpiopin=18
core_freq=250
La première ligne active le support de PPS au travers de la pin GPIO18 et la seconde ligne force la
fréquence de l’horloge du CPU. Pour activer automatiquement le module PPS au démarrage du
Raspberry Pi, il faut éditer le fichier « /etc/modules » et ajouter le module pps-gpio.
PPS (Pulse-Per-Second) est un signal électrique de forme carré transmettant une information de
temps dans un câble [56]. Grâce au signal PPS, il est possible d’améliorer la précision de la
synchronisation de l’horloge.
Une fois le module PPS activé par défaut, il faut modifier la configuration par défaut du daemon
gpsd en éditant le fichier « /etc/default/gpsd ». La configuration doit ressembler à la figure 31 ci-
dessous :
Figure 31 : Configuration par défaut du daemon gpsd
Ainsi par défaut le daemon se lance au démarrage du Raspberry Pi et se met à faire

automatiquement des requêtes sur le GPS en utilisant l’interface série ttyS0. Après, il faut que le
service gpsd s’active automatiquement au démarrage. Il faut entrer la commande sudo systemctl
enable gpsd et ensuite redémarrer le Raspberry Pi.
Pour utiliser le signal PPS, il faut ajouter un nouveau connecteur à la carte Adafruit Ultimate GPS
sur la pin PPS et connecter le câble à la pin GPIO18 de la station. Avec l’ajout du signal PPS, la
connectique de la carte GPS devient la suivante :

Julien Brêchet
Pin du Raspberry Pi Pin du GPS

5V0 VIN
GND GND
TXD0 RX
RXD0 TX
GPIO18 PPS
Le rectangle rouge de la figure 32 montre le nouveau branchement qui a été effectué sur le GPS
afin de pouvoir activer le signal PPS avec la pin GPIO18 de la station de météorologie.
Figure 32 : Ajout du signal PPS pour le GPS
Il est possible de tester si le module PPS a été chargé par le kernel avec la commande
sudo dmesg | grep pps et de vérifier si le signal PPS fonctionne correctement avec
sudo ppstest /dev/pps0
Une fois que le signal PPS et le daemon gpsd sont configurés et fonctionnels, il faut installer le
paquet ntp avec l’utilitaire APT. Ensuite, il faut éditer le fichier « /etc/ntp.conf » pour ajouter en
fin de fichier nos sources GPS et PPS. Les configurations effectuées sont visibles dans la figure 33.
Figure 33 : Ajout des sources GPS et PPS pour NTP
Maintenant, nous pouvons utiliser le programme ntpq pour envoyer des requêtes au service NTP et
vérifier la précision du temps récupéré des satellites GPS. La commande à utiliser est
sudo ntpq –np et cela nous donne un affichage comme illustré par la figure 34. A noter qu’il n’y a
pas de connexion à Internet lorsque la requête est effectuée, c’est pourquoi les serveurs
x.debian.pool.n ne peuvent pas être atteints par la station en ce moment.

Julien Brêchet
Figure 34 : Affichage de la sortie de la commande ntpq -np
L’offset indique le décalage horaire, en millisecondes, entre le client NTP et la source. Le jitter
indique la différence, en millisecondes, entre deux échantillons [57]. L’offset peut être diminué
en allant modifier le time1 du fichier ntp.conf (-0.031s dans la figure 33). En ajustant le time1, il
est possible de diminuer l’offset à moins de 10 millisecondes.
Actuellement, une précision de quelques dizaines de millisecondes est amplement suffisante mais
si nous voulons par la suite récolter des données sur des champs électromagnétiques de la foudre
et les comparer avec les chiffres d’autres instituts, il faudrait idéalement avoir une précision bien
inférieure à la milliseconde. En effet, la capture des champs électromagnétiques devrait
s’effectuer idéalement avec une fréquence aux alentours de la microseconde et la précision de
l’horloge de la station météorologique se devrait d’être au moins aussi précise que la fréquence
d’échantillonnage. Ce faisant, il faudrait un GPS d’une meilleure précision (moins de variation de
l’offset) que l’Adafruit Ultimate GPS mais cela coûterait évidemment bien plus cher.
D’ici la fin du travail de Bachelor, une étude va être faite pour penser à d’autres types de solutions
plus précises à mettre en place pour la synchronisation de l’horloge des stations météorologiques.
Des tests de performance seront aussi établis pour tester jusqu’à combien d’échantillons par
seconde nous pouvons récolter avec un nano-ordinateur Raspberry Pi Zero W et Raspberry Pi 3.
9.5.2.4 Configuration à distance des paramètres de récupération des données

Afin de pouvoir gérer et mettre à jour facilement la fréquence d’échantillonnage et la taille des
fichiers de logs pour chaque type de données, il a été décidé d’implémenter un script qui permet
d’effectuer à distance la modification des différents compteurs existants. A noter qu’il est aussi
possible de lancer le script localement sur la station.
Après quelques recherches, je suis tombé sur le la librairie Twisted. Twisted est un framework
réseau axé sur les événements (event-driven) écrit en Python et qui est sous licence MIT open
source [58]. Le site Twisted Matrix Labs fournit de la documentation pour développer des
applications avec Twisted [59] et offre aussi des exemples de scripts [60] à partir desquels je me
suis inspiré pour implémenter la communication entre une station de météorologie et une machine
cliente distante.
Actuellement, pour lancer le script il suffit de lancer le client Twisted et de lui passer trois
paramètres : l’adresse IP de la station, le nom de la variable compteur à modifier et la nouvelle
valeur à attribuer au compteur. Voici ci-dessous un exemple de commande :
python twistedClient.py 192.168.1.11 temperatureInterval 55
Cette commande définit le nouvel intervalle de récolte de la température à 55 secondes pour la
station dont l’adresse IP est 192.168.1.11.
Un article de Stack Overflow [61] expliquant comment utiliser un reactor Twisted dans un thread
autre que le principal m’a été bien utile pour réussir à coder le thread. En effet, j’ai rencontré

Julien Brêchet
quelques problèmes pour réussir à faire communiquer le reactor avec le client Twisted jusqu’à ce
que je tombe sur cet article.
9.5.2.5 Installation d’un anémomètre avec sortie de tension analogique

Après la température, la pression, l’humidité et les données GPS, il a été décidé de mettre en place
un nouveau capteur permettant de calculer la vitesse du vent. L’anémomètre QS-FS01 a été choisi
car il possède une précision honnête de +/- 1m/s et que son prix est abordable (44.95 CHF). C’est
l’un des seuls anémomètres que j’ai trouvés dans cette gamme de prix et puisqu’il était disponible
sur le site d’Adafruit, j’en avais directement commandé un lors de la première phase du travail de
Bachelor lorsque j’avais acheté les autres capteurs pour éviter des frais de port supplémentaires.
Puisque la sortie de l’anémomètre QS-FS01 est analogique, j’ai dû commander des convertisseurs
analogique-numérique pour obtenir un signal numérique à partir de la tension de sortie de
l’anémomètre. J’ai sélectionné le convertisseur ADC MCP3008 [62] car il est bon marché (3.75$) et
car il offre une fréquence d’échantillonnage maximale de 200ksps [63] (200'000 échantillons par
seconde), ce qui pourrait s’avérer tout juste suffisant pour capturer des champs
électromagnétiques car 200ksps correspond à un échantillon toutes les 5 microsecondes. La figure
35 montre à quoi ressemble un convertisseur MCP3008 possédant 8 canaux d’entrées analogiques.
Figure 35 : Photo d'un MCP3008 trouvée sur le site officiel d'Adafruit [62]
L’ADC MCP3008 possède 8 canaux d’entrées analogiques étant chacun codés sur 10 bits. Les valeurs
converties en numérique vont donc de 0 à 1023 pour chaque canal. La communication entre l’ADC
et le Raspberry Pi se fait via une liaison SPI qui est un bus de données série synchrone et qui opère
en full duplex [64]. Le débit est aussi plus important qu’avec une liaison I2C.
Pour savoir comment connecter les pins de l’ADC avec ceux du Raspberry Pi, j’ai suivi le tutoriel
du MCP3008 écrit par Tony DiCola qui est disponible sur le site officiel d’Adafruit [65]. La
connectique est la suivante :

Julien Brêchet
Pin du Raspberry Pi Pin du MCP3008

3V3 VDD
3V3 VREF
GND AGND
GPIO18 CLK
GPIO23 (MISO) DOUT
GPIO24 (MOSI) DIN
GPIO25 CS/SHDN
GND DGND
Nous pourrions utiliser d’autres GPIO sur le Raspberry Pi que les pins GPIO18, 23, 24 et 25. Le choix
des GPIO que nous utilisons est effectué au niveau du logiciel de récolte des données (figure 36).
Figure 36 : Configuration des GPIO du Raspberry Pi utilisés pour communiquer avec l’ADC MCP3008
Une fois l’ADC MCP3008 et l’anémomètre QS-FS01 connectés, j’ai créé un nouveau thread pour
récolter la vitesse du vent récupérée par l’anémomètre. J’ai tout d’abord installé les paquets
nécessaires avec sudo apt-get build-essential python-dev python-smbus git puis j’ai téléchargé
la librairie du MCP3008 mise à disposition par Adafruit [66] et je l’ai ensuite installée sur le
Raspberry Pi avec la commande sudo python setup.py install. Pour tester le bon fonctionnement
de l’ADC, la librairie fournit des scripts de test.
Après avoir installé la librairie Python, j’ai pu coder le thread qui va récolter la vitesse du vent. Il
m’a fallu trouver les données du fabricant de l’anémomètre [67] pour pouvoir calibrer la vitesse en
fonction des données numériques qui sont reçues depuis l’ADC. Il m’a aussi fallu calculer à quoi
correspondait le résultat numérique reçu de l’ADC par rapport à la tension de sortie analogique de
l’anémomètre. Nous utilisons le canal d’entrée analogique 0 du MCP3008 pour recevoir la tension
l’anémomètre.
Figure 37 : Formule de conversion des données numériques brutes en vitesse du vent en m/s
La figure 37 indique que la valeur numérique brute retournée par l’ADC doit être multipliée par 3.3
(voltage de l’alimentation de l’ADC) puis divisée par 1023 pour obtenir la tension de sortie de
l’anémomètre (valeur numérique sur 10 bits). Ensuite, il faut appliquer la conversion du fabricant :
 Soustraire 0.4 car la tension initiale est de 0.4V lorsqu’il y a un vent nul
 Diviser le tout par 1.6 car la plage de la tension de sortie de l’anémomètre va de 0.4V à 2V
(la tension peut monter plus haut selon le fournisseur mais avec une perte de précision pour
le calcul de la vitesse du vent)
 Multiplier par 32.4 car une tension de 2V correspond selon le fournisseur à un vent de
32.4m/s

Julien Brêchet
A noter que la précision des valeurs récoltées n’a pas encore pu être testée car il n’y a pas de
soufflerie au sein de la HEIG. Il faudrait aller dans une entreprise possédant ce genre d’installations
pour pouvoir calibrer l’ADC et l’anémomètre et ainsi améliorer la précision des données. Idem pour
le capteur BME 280. Il existe sur le marché des dispositifs plus ou moins fiables qui ne coûtent pas
trop cher et qui peuvent nous donner à la fois la température, la pression barométrique, l’humidité
et même la vitesse du vent. Si un de ces dispositifs est reconnu comme étant fiable et qu’il ne
coûte pas trop cher, il serait envisageable d’en acquérir un pour effectuer le calibrage des
différents capteurs.
Avec un multimètre, j’ai pu vérifier que la tension de sortie de l’anémomètre correspond bien à
0.4V lorsque le vent est nul. Et pour que l’anémomètre fonctionne correctement, il faut l’alimenter
sur le 5V. Le 3.3V ne suffit pas.
9.5.2.6 Création d’une carte PCB avec Altium

Maintenant, tous les capteurs ont pu être installés et connectés sur une plaque de test. Certes, il
reste encore le capteur de champs électromagnétiques mais le capteur de l’étudiant en travail
Master est toujours en cours de développement et ne peut pas encore être utilisé.
La figure 38 représente tous les capteurs et toutes les connexions nécessaires à mettre en place
sur une plaque de test pour pouvoir récolter les données de vent, température, pression, humidité
ainsi que les informations GPS. Plus nous ajoutons de capteurs, plus le nombre de connexions
devient grand et plus la complexité du câblage devient élevée. Il peut vite arriver qu’un câble soit
débranché par inadvertance et qu’un rebranchement n’ait pas été fait correctement. C’est
pourquoi il a été décidé de créer une carte PCB afin que toutes les connexions soient gravées sur
une carte composée de couches de cuivre.
Figure 38 : Plaque de test avec tous les capteurs et toutes les connexions nécessaires
Pour créer un circuit imprimé, j’ai utilisé le programme Altium Designer pour lequel l’école m’a
donné une licence. Après avoir pris en main les fonctionnalités de base du logiciel, j’ai commencé
par dessiner le schéma de la carte. Une fois ce dernier terminé, j’ai commencé à concevoir le plan

Julien Brêchet
de la carte PCB puis quand les connecteurs étaient correctement placés, je suis passé à l’atelier
de la salle A03 où j’ai reçu de l’aide de Monsieur Claude Guinchard pour le paramétrage du
programme Altium et la conception du câblage entre les différents connecteurs. Le schéma et le
plan de la carte PCB sont fournis en annexes de ce rapport (document numérique de la dernière
version de la carte PCB uniquement).
Quand le schéma et le plan du circuit imprimé ont été terminés, je les ai envoyés à Monsieur
Guinchard qui a pu lancer la fabrication de la carte PCB. Les figures 39 et 40 montrent le résultat
final de la première carte PCB et la figure 41 nous montre à quoi ressemble une station
météorologique munie de la carte. Notons que la carte PCB est connectée au Raspberry Pi de façon
à ce que les capteurs soient situés sur le dessous.
Figure 39 : carte PCB face recto avec capteurs
Le câble d’alimentation (rouge) de l’anémomètre vient se connecter tout à droite du header à 3

pins (le plus proche du GPS), la terre (câble noir) vient se connecter au centre et la tension de
sortie représentant la vitesse du vent (câble bleu) se connecte à gauche. La carte PCB est câblée
de sorte que la tension de sortie de l’anémomètre arrive sur le canal d’entrée analogique 0 du
MCP3008.

Julien Brêchet
Figure 40 : PCB face verso
Figure 41 : Carte PCB installée sur la station Raspberry Pi
9.5.2.7 Développement d’une interface console utilisateur pour la gestion des stations
La manière d’utiliser le script de gestion des compteurs de récolte expliquée au chapitre 9.5.2.4
est fonctionnelle mais pas très conviviale pour un utilisateur lambda. En effet, si ce dernier n’a pas
l’habitude d’utiliser le script, il ne saura pas forcément combien de paramètres fournir en entrée

Julien Brêchet
ni dans quel ordre les donner, sans parler de connaître le nom exact de la variable qu’il aimerait
modifier.
Pour simplifier la tâche aux utilisateurs devant gérer les compteurs de récolte, j’ai implémenté
une interface console utilisateur en utilisant la librairie npyscreen qui est un framework pour la
programmation d'applications de terminaux ou de consoles [68]. npyscreen a été choisi car c’est un
framework simple d’utilisation et qu’il est compatible autant avec les systèmes d’exploitation
Raspbian que Windows. En effectuant mes recherches, j’ai découvert qu’il existait plusieurs
frameworks comme par exemple python-inquirer et Kivy. Mais python-inquirer n’est pas compatible
avec Windows et Kivy permet de créer des interfaces graphiques ergonomiques mais demande
beaucoup de temps à être maîtrisé. Le framework npyscreen est un juste compromis car il permet
de créer rapidement des interfaces consoles ergonomiques.
Pour installer npyscreen, j’ai cloné le dépôt sur GitHub [69] et j’ai installé la librairie avec la
commande sudo python setup.py install. Pour que le framework fonctionne sur Windows, j’ai aussi
dû télécharger la librairie Curses 2.2 [70] sur les machines Windows sur lesquelles nous allons
utiliser les consoles utilisateur npyscreen.
Pour concevoir l’interface console utilisateur, je me suis inspiré d’un exemple se trouvant dans la
documentation de npyscreen [68]. L’utilisateur remplit le champ de l’adresse IP de la station,
choisit la variable à modifier parmi une liste de compteurs existants (un seul choix possible) puis
définit la nouvelle valeur de la variable. Quand l’utilisateur a fini, il clique sur le bouton « OK » et
le formulaire npyscreen envoie une commande qui ouvre le client Twisted en utilisant les trois
paramètres entrés par l’utilisateur dans le formulaire de la console npyscreen. La figure 42
représente la console utilisateur et la figure 43 montre la réponse retournée par la station après
un changement fructueux de la valeur de la variable désirée.
Figure 42 : Console utilisateur avec laquelle on veut modifier l'intervalle de température de la station 192.168.2.11
Les valeurs entrées dans la console de la figure 42 correspondent à la commande

python twistedClient.py 192.168.2.11 temperatureInterval 1.55

Julien Brêchet
Figure 43 : Réponse reçue suite à un changement fructueux de la valeur du compteur
9.5.2.7.1 Traitement des données erronées entrées par l’utilisateur

 Si la nouvelle valeur n’est pas convertible en type float (si ce n’est pas un nombre), le
changement est refusé et la connexion est fermée
 Si la nouvelle valeur n’est pas supérieure à 0.0, l’erreur est affichée, le changement est
refusé et la connexion est fermée
 Si l’adresse IP n’est pas une IP valide d’une station existante, après un timeout de plusieurs
secondes la console nous indique que la connexion a échoué (figure 44)
 Si le nom de la variable compteur n’existe pas (dans le cas où nous utiliserions directement
le script sans passer par la console utilisateur), l’erreur est affichée et la connexion est
fermée

Julien Brêchet
Figure 44 : Message d'erreur faisant suite à l'envoi d'une adresse IP erronée
A noter que nous utilisons aussi des nombres de type float pour le nombre de logs maximal à stocker
dans un fichier. Cela a été décidé ainsi afin d’éviter d’effectuer des conversions de type
supplémentaires dans un souci de performance. L’utilisation de nombres décimaux ne pose
absolument aucun problème puisque le code vérifie à chaque écriture que le nombre de logs inscrits
dans le fichier est supérieur ou non au nombre maximal. Si oui, le fichier est fermé et envoyé sur
le serveur, sinon le thread continue d’écrire dans ce même fichier.
9.5.2.8 Configuration d’un routeur wifi

Après avoir échoué à configurer l’AP wifi Linksys pour obtenir une connexion à Internet via le réseau
de l’HEIG-VD, il a été décidé de configurer le Raspberry Pi 3 Modèle B+ en tant que routeur et AP
wifi qui met à disposition un réseau utilisable par les dispositifs du projet AKUNU. Pour mettre en
place cette configuration, je suis allé acheter une clef wifi USB au magasin Interdiscount d’Yverdon-
les-Bains et j’ai sélectionné la seule clef wifi compatible Linux. Le modèle de la clef est le D-LINK
DWA-131 révision E1 possédant une interface USB 2.0 (il n’y avait aucun modèle USB 3.0 compatible
Linux) et coûtant 39.95 francs suisses [71].
Pour installer le driver, je suis tombé sur un article du site ubuntu-fr.org [72] expliquant comment
connaître la version de révision de la clef wifi, E1 dans notre cas. Pour la version E1, le site nous
redirige vers un dépôt GitHub [73] expliquant comment installer le driver rtl8192eu pour faire
fonctionner la clef. J’ai utilisé cette version du driver car le pilote Linux officiel de la société
D-Link [74] ne supporte pas les plateformes Raspberry Pi.
Le README du dépôt GitHub du driver rtl8192eu explique clairement comment installer le driver.
Il faut tout d’abord modifier le fichier « Makefile » comme indiqué dans le README pour définir
que la plateforme est un Raspberry Pi. Ensuite, il faut installer les paquets dont nous aurons besoin
avec la commande sudo apt-get install git raspberrypi-kernel-headers build-essential dkms puis
ensuite ajouter le driver à DKMS en se plaçant à la racine du dossier cloné de GitHub avec la
commande sudo dkms add .

Julien Brêchet
DKMS est un framework utilisé pour pouvoir rebuilder le module lors de mises à jour du noyau Linux.
Une fois le pilote ajouté à DKMS, il faut builder et installer le driver avec la commande
sudo dkms install rtl8192eu/1.0
Attention ! Pour éviter des problèmes de version du kernel lors de l’installation du driver, il faut
tout d’abord mettre à jour le noyau Linux avec sudo apt-get update et sudo apt-get upgrade puis
ensuite redémarrer le Raspberry Pi.
Après avoir réussi à installer le driver de la clef wifi, j’ai utilisé la commande sudo lshw –c network
pour vérifier que la clef est maintenant détectée par le système ainsi que pour connaître son nom
logique d’interface. La figure 45 indique que la clef USB wifi utilise le driver rtl8192eu et que son
nom logique d’interface est wlan0.
Figure 45 : affichage des interfaces réseau existantes avec la commande lshw
Une fois le driver installé et la connectivité de la clef wifi testée, j’ai lu un article du site officiel
de Raspberry Pi sur comment configurer un Raspberry Pi en tant qu’AP wifi pour un réseau local
[75]. Il faut premièrement installer les utilitaires dnsmasq et hostapd avec apt-get puis arrêter les
deux services pour pouvoir les configurer :
sudo systemctl stop dnsmasq
sudo systemctl stop hostapd
Il faut éditer le fichier « /etc/dhcpcd.conf » pour définir l’adresse IP de chacune des interfaces
WLAN. La figure 46 ci-dessous affiche la configuration de la carte wlan1 utilisée comme point
d’accès wifi pour le réseau AKUNU-LAN2 et la configuration de l’interface wlan0 pour se connecter
au réseau Internet de chez moi. Si nous voulons utiliser le réseau de la HEIG-VD, il faut modifier
par conséquent la configuration de la carte wlan0.
Figure 46 : Configuration des interfaces WLAN
Pour permettre à des machines distantes de se connecter au réseau AKUNU sans devoir configurer
manuellement une adresse IP statique, il faut configurer le service dnsmasq pour mettre en place
un serveur DHCP avec une réservation d’une plage d’adresses IP. Pour ce faire, il faut éditer le

Julien Brêchet
fichier « /etc/dnsmasq.conf », préciser l’interface utilisée pour le réseau AKUNU, la plage

d’adresses DHCP, le masque de sous-réseau et le bail de réservation ou lease time en anglais (figure
47).
Figure 47 : Configuration du fichier dnsmasq.conf
Maintenant, nous pouvons configurer le logiciel du point d’accès sans-fil. Ce logiciel s’appelle
hostapd et permet d’établir un point d’accès wifi avec lequel nous allons créer le réseau AKUNU.
Pour configurer hostapd, il faut tout d’abord créer un nouveau fichier que nous allons appeler
« /etc/hostapd/hostapd.conf ». Ce fichier contient toutes les informations relatives au réseau
sans-fil AKUNU que nous voulons créer. Je me suis basé sur l’exemple de cet article [75].
interface=wlan1
driver=nl80211 #driver de la carte native du Raspberry Pi 3
ssid=AKUNU-LAN2 #nom du réseau AKUNU
hw_mode=g #utilisation de la norme 802.11g
channel=11 #canal 11
wmm_enabled=0
macaddr_acl=0 #pas de filtrage des adresses MAC
auth_algs=1 #désactive l’authentification ouverte
ignore_broadcast_ssid=0 #le SSID n’est pas masqué
wpa=2 #méthode d’authentification WPA2
wpa_passphrase=mdpWifi #consulter le document des informations de connexion
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP
Une fois la configuration du fichier hostapd.conf terminée, il faut préciser à hostapd qu’il doit
utiliser ce fichier par défaut. Pour ce faire, il faut éditer « /etc/default/hostapd » et ajouter la
ligne DAEMON_CONF="/etc/hostapd/hostapd.conf"
Maintenant que les services dnsmasq et hostapd sont configurés, ils peuvent être réactivés :
sudo systemctl start dnsmasq
sudo systemctl start hostapd
Ensuite, il faut activer la redirection (forwarding) des paquets IPv4 en dé-commentant la ligne
net.ipv4.ip_forward=1 dans le fichier « /etc/sysctl.conf ». Une fois cela fait, il faut ajouter une
règle de pare-feu pour créer une traduction NAT entre les interfaces wlan0 et wlan1 puis
optionnellement des règles permettant de filtrer le trafic allant du réseau connecté à Internet vers
le réseau AKUNU et vice-versa pour diminuer le risque d’intrusions dans le réseau.
-A POSTROUTING -o wlan0 -j MASQUERADE
-A FORWARD -i wlan0 -o wlan1 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i wlan1 -o wlan0 -j ACCEPT
Pour que la configuration des iptables soit rétablie après un redémarrage du Raspberry Pi, il faut
sauver la configuration dans un fichier qui sera rechargé au démarrage. Nous allons nommer le

Julien Brêchet
fichier iptables.ipv4.nat et nous allons le stocker dans le répertoire « /etc ».La commande est la
suivante : sudo sh -c "iptables-save > /etc/iptables.ipv4.nat"
Pour restaurer les règles iptables au démarrage de l’ordinateur, il faut ajouter la ligne
iptables-restore < /etc/iptables.ipv4.nat dans le fichier « /etc/rc.local » juste avant la ligne
exit 0. Le fichier rc.local permet de lancer des commandes au démarrage du Raspberry Pi.
Maintenant, il faut encore forcer l’activation du service hostapd au démarrage pour que le point
d’accès wifi AKUNU-LAN2 se lance automatiquement lors du démarrage du Raspberry Pi. Pour ce
faire, il faut forcer le service de démarrer au boot avec la commande
sudo update-rc.d hostapd defaults. Pour terminer, il faut redémarrer l’ordinateur et vérifier que
le point d’accès s’active automatiquement.
Lors de la configuration du point d’accès wifi, j’ai trouvé des compléments sur d’autres articles
tels que [76] et [77].
A noter qu’il est tout à fait possible d’utiliser l’interface eth0 en la branchant à un câble Ethernet
pour se relier à un réseau ayant accès à Internet. Mais étant donné que peu de salles à la HEIG-VD
sont munies de câbles Ethernet et de prises RJ45, il a été décidé d’utiliser une seconde interface
WLAN pour se connecter à un réseau possédant un accès Internet, d’où l’achat d’une clef USB wifi
(figure 48). J’ai d’ailleurs demandé à l’école une autorisation d’accès au réseau HEIG-Devices pour
pouvoir y connecter mon routeur wifi Raspberry Pi et ainsi disposer d’une connexion à Internet pour
les dispositifs du réseau AKUNU. La demande a été acceptée et j’ai dû modifier la configuration de
l’interface wlan0 dans le fichier dhcpcd.conf pour que l’interface prenne une adresse IP allouée
dynamiquement par le serveur DHCP de l’école.
Figure 48 : Clef USB wifi branchée sur le Raspberry Pi 3
9.5.2.9 Amélioration de la fonction d’envoi de fichiers sur le partage SMB

Parfois, la communication entre une station et le serveur de fichiers peut être altérée à cause
d’interférences dans les alentours ou parce que la bande passante disponible est faible (beaucoup
d’envois de fichiers simultanément sur le partage SMB). Si la communication est mauvaise, il se
peut parfois que la station échoue à envoyer un fichier de logs sur le serveur. J’ai donc implémenté
un mécanisme qui, si l’envoi du fichier échoue, retente de l’envoyer à nouveau après un certain
délai. Pour calculer ce délai, je me suis inspiré de ce que j’ai appris sur le protocole CSMA/CD qui
sert à gérer les collisions lors de l’utilisation du mode half-duplex sur un réseau Ethernet.
Si l’envoi d’un fichier échoue, le nombre d’échecs est incrémenté de 1 et le programme attend un
nombre de secondes correspondant à la formule 1 + random(0, 2^nombre d’échecs). Le

Julien Brêchet
programme attend une seconde plus un nombre aléatoire allant de 0 à 2 puissance le nombre
d’échecs. Par exemple, si l’envoi d’un certain fichier vient d’échouer pour la troisième fois, le
programme va attendre un temps aléatoire allant de 1 à 9 secondes. Des nombres aléatoires sont
utilisés pour éviter que si plusieurs envois produisent un échec en même temps, qu’ils retentent
leur chance à nouveau tous au même moment. Plus le nombre d’échecs est élevé, plus les chances
de retenter un envoi au même instant sont faibles et donc plus les chances de réussite de l’envoi
sont élevées.
9.5.2.10 Implémentation d’un graceful killer

Dans le cas où nous aimerions arrêter le script qui tourne en tâche de fond sur une station
(utilisation de la commande python twistedServer &), il faut entrer la commande ps –ef pour
consulter les programmes en cours d’exécution sur la station et pour trouver le pid du processus à
tuer. Une fois le pid trouvé, il faut utiliser la commande sudo kill <pid> pour arrêter le programme
de récolte des données.
J’ai implémenté une classe GracefulKiller qui permet d’instancier un killer qui va intercepter les
signaux SIGINT (signaux d’interruption comme par exemple CTRL+c) et SIGTERM (signaux de
terminaison envoyés par la commande sudo kill <pid>). Quand le killer intercepte un signal, il passe
son attribut killNow à True. Quand chacun des threads du programme de récolte de données arrive
en fin de boucle, il vérifie si le killer est activé et si c’est le cas, le thread ferme le fichier de logs
sur lequel il était en train d’écrire et appelle la fonction pour envoyer ce fichier sur le partage
SMB. Ensuite, le thread passe son état running à False et se termine.
Quand le killer est activé, le programme principal supprime les configurations GPIO utilisées, stoppe
le serveur Twisted en lui disant d’arrêter son reactor et lui donne l’ordre de stopper l’écoute sur
le port TCP qu’utilisait le reactor. Ainsi, il est possible de relancer à nouveau le programme de
récolte de données sans devoir redémarrer la station. Le fonctionnement du graceful killer est
démontré dans la figure 49 ci-dessous :
Figure 49 : Diagramme de flux démontrant le fonctionnement du graceful killer

Julien Brêchet
Si nous ne sommes pas dans la console avec laquelle nous avons lancé le script de récolte des
données (ce qui est très probable), nous ne pouvons pas voir les notifications envoyées par les
threads. Si nous voulons arrêter la station après avoir tué le programme, il faut faire attention à
attendre un intervalle de temps au moins aussi élevé que le plus grand intervalle d’attente entre
deux récupérations de données car le thread doit sortir de son sommeil pour vérifier que le killer
s’est activé. Par exemple, si le plus grand intervalle de récupération est celui de la localisation
GPS qui est défini à 10 minutes, pour être sûr que le thread ait eu le temps de se réveiller, de se
terminer proprement et d’envoyer le fichier de logs sur le serveur de fichiers, il faudrait attendre
au minimum 10 minutes entre l’enclenchement du killer et l’arrêt de la station météorologique.
De plus, il ne faut pas oublier de laisser le temps au programme d’envoyer les fichiers restants sur
le partage SMB du serveur. A la suite de ce travail de Bachelor, ce serait un des premiers points à
améliorer.
Lorsque nous voulons lancer à nouveau le programme de test, il faut faire attention à d’abord
modifier le numéro de version en éditant le script pour éviter d’écraser les fichiers de logs déjà
créés !
Si nous voulons tout de même tuer un programme de manière brutale, cela est possible en utilisant
la commande sudo kill -9 <pid> qui envoie un signal SIGKILL afin de provoquer la fin immédiate du
programme correspondant au pid.
Pour implémenter le killer, je me suis basé sur un exemple écrit par Mayank Jaiswal sur le site de
Stack Overflow [78]. J’ai aussi effectué de nombreuses recherches pour savoir comment forcer le
serveur Twisted d’arrêter d’écouter sur le port TCP qu’il utilisait et j’ai finalement trouvé comment
faire en me basant sur la documentation de Twisted et sur un poste d’un certain sajattack [79].
9.5.2.11 Création de la seconde version de la carte PCB

Dans cette nouvelle version, un nouvel ADC MCP3008 et un connecteur BNC femelle ont été ajoutés
pour pouvoir récolter des données à partir de l’antenne de capture de champs électromagnétiques
qui vient d’être terminée par l’étudiant en Master. N’importe quel autre capteur muni d’un
connecteur BNC pourrait aussi être testé.
J’ai décidé d’ajouter un ADC supplémentaire au lieu d’utiliser de nouveaux canaux sur le MCP3008
existant pour simplifier les tests de détection d’interceptions envoyées par le capteur. Par la suite,
si les tests s’avèrent concluants, il serait envisageable de n’utiliser qu’un seul MCP3008. Les parties
dédiées à la détection et au traitement d’interceptions se trouvent dans les deux prochains
chapitres. Le nouvel ADC est connecté à la station météorologique selon le tableau ci-dessous :
Pin du Raspberry Pi Pin du MCP3008

5V0 VDD
5V0 VREF
GND AGND
GPIO18 CLK
GPIO13 (MISO) DOUT
GPIO19 (MOSI) DIN
GPIO26 CS/SHDN
GND DGND

Julien Brêchet
La figure 50 ci-dessous montre à quoi ressemble la nouvelle version de la carte PCB :
Figure 50 : Nouvelle version de la carte PCB face recto
9.5.2.12 Création d’un thread pour récupérer les données du connecteur BNC
Premièrement, pour pouvoir détecter des interruptions envoyées par un capteur, j’ai installé la
librairie RPi.GPIO 0.6.3 [80] avec la commande pip install RPi.GPIO. Ensuite, pour récupérer les
données de l’antenne connectée en coaxial au BNC femelle de la carte PCB, j’ai configuré dans le
script Python les GPIO du Raspberry Pi pour que ce dernier puisse communiquer avec le nouvel ADC
qui vient d’être installé. J’ai aussi paramétré un GPIO qui est directement connecté au connecteur
BNC dans le but de pouvoir détecter une impulsion montante et ainsi déclencher une interruption.
La figure 51 ci-dessous représente les configurations mentionnées :
Figure 51 : Configuration des GPIO pour la communication entre le Raspberry Pi et le nouvel ADC
Les données en provenance de l’antenne de champs électromagnétiques vont être stockées dans
un buffer circulaire en attendant qu’une interruption ait lieu. Pour créer un buffer circulaire, j’ai
décidé d’utiliser une double-ended queue (deque) car c’est une collection très performante [81]
qui, lorsqu’elle ajoute un nouvel élément en fin de queue, supprime en même temps le plus ancien
élément se trouvant en tête de queue. L’utilisation d’une deque pour faire un buffer circulaire me
semble donc appropriée.
J’ai créé un thread bncPoller qui va écouter le canal 0 du nouvel ADC MCP3008 (celui relié au
connecteur BNC) et qui va ajouter la valeur récupérée à la fin du buffer circulaire (.append()) et
donc par la même occasion faire « coulisser » le buffer et écraser la valeur la plus ancienne. J’ai
aussi mis en place un système d’interruptions qui, quand il détecte un flux montant sur la pin
GPIO6, appelle une fonction qui va copier le buffer et notifier un thread electromagneticFields qui

Julien Brêchet
est chargé de l’écriture du buffer dans un fichier de logs. Le diagramme de flux de la figure 52
illustre le fonctionnement du système d’interruptions.
Figure 52 : Diagramme de flux illustrant le fonctionnement du système d'interruptions
9.5.2.13 Test des interruptions en provenance du connecteur BNC

Pour tester le fonctionnement des interruptions, j’ai utilisé un condensateur et une pile 9V. Je
charge le condensateur en le faisant toucher la pile (figure 53) et ensuite je le pose sur l’antenne
pour émettre un champ électrostatique (figure 54). La figure 55 quant à elle montre à quoi
ressemble l’antenne de champs électromagnétiques et comment elle est branchée au connecteur
BNC femelle du Raspberry Pi (voir le petit cercle rouge).
Figure 53 : Condensateur chargé sur une pile 9V

Julien Brêchet
Figure 54 : Création d'un champ électrostatique avec un condensateur chargé
Figure 55 : Antenne de champs électromagnétiques branchée au connecteur BNC femelle du Raspberry Pi
9.5.2.14 Création d’images pour les Raspberry Pi

Pour pouvoir facilement installer de nouvelles stations, j’ai procédé à la création d’une image du
Raspberry Pi AKUNU-station1. Un fichier .img est créé à partir de la carte SD d’AKUNU-station1 en
utilisant le logiciel Win32DiskImager qui est un logiciel de sauvegarde et de restauration d’images
compatible Windows [82].
Pour mettre en place une nouvelle station, il faut formater une nouvelle carte SD avec SD Card
Formatter et flasher l’image sur la carte en utilisant le logiciel Etcher. Une fois cela fait, il faut
connecter le nouveau Raspberry Pi 3 ou Zero W à un écran, un clavier et une souris, le démarrer
puis aller dans les paramètres modifier son nom en AKUNU-stationX où X correspond au numéro de
la station. Ensuite, il faut éditer le fichier « /etc/dhcpcd.conf » pour lui attribuer une adresse IP
statique. Quand ces deux opérations sont faites, il faut éteindre le nano-ordinateur et brancher
une carte PCB sur ses GPIO.

Julien Brêchet
Une image a aussi été créée à partir du Raspberry Pi faisant office de routeur wifi et de serveur de
fichiers au cas où celui-ci tomberait en panne. Tout comme pour les stations météorologiques, il
suffit de formater une carte SD, de flasher l’image dessus et de brancher la carte dans le Raspberry
Pi. Normalement pour le routeur wifi / serveur de fichiers, il n’y a aucune modification à faire car
actuellement, il est prévu d’utiliser uniquement un seul serveur.
Attention ! Il vaut mieux configurer un nouveau Raspberry Pi hors de portée du réseau wifi AKUNU
afin d’éviter que le nouveau nano-ordinateur prenne une adresse IP déjà existante et ne crée des
problèmes sur le réseau.
9.5.2.15 Création d’un logo AKUNU

Afin de donner une image au projet AKUNU, il pourrait être intéressant de créer un logo. Etant
donné que je ne possède aucune compétence en traitement d’image et que je ne maîtrise aucun
logiciel haut de gamme pour créer un logo, j’ai décidé de faire un petit logo tout simple avec
Microsoft Word. La figure 56 représente le logo en l’état actuel, c’est-à-dire lors du rendu du travail
de Bachelor le 27 juillet 2018.
Figure 56 : Logo actuel du projet AKUNU
9.5.3 Problème de chute momentanée du débit du wifi

En pleine phase de test, j’ai commencé à avoir une connexion wifi très lente et il m’était difficile
d’atteindre la station et le serveur de fichiers. Parfois, je n’avais même plus de connexion et les
Raspberry Pi étaient inatteignables sur le réseau. Après plusieurs investigations, j’en ai déduit que

Julien Brêchet
le problème provenait de la carte wifi native wlan1 du routeur Raspberry Pi et qu’elle se mettait
dans une sorte d’état en veille.
Avec la commande iwconfig, j’ai pu constater que le Power Management de la carte wlan1 était
activé. En utilisant la commande sudo iw wlan0 set power_save off [83], j’ai pu désactiver le
Power Management. J’ai ajouté cette commande dans le fichier « /etc/rc.local » pour
automatiquement désactiver le Power Management au démarrage du routeur. J’en ai fait de même
avec l’interface wlan0 de la station météorologique. Quant à la clef USB wifi du routeur, le Power
Management était déjà désactivé par défaut.
La figure 57 affiche la sortie de la commande iwconfig qui indique que le Power Management des
cartes WLAN est maintenant désactivé. Depuis lors, je n’ai plus rencontré de problème de
connexion sur le réseau AKUNU.
Figure 57 : Sortie de la commande iwconfig indiquant que le Power Management est désactivé
9.5.4 Tests de performance

Durant la dernière semaine de mon travail de Bachelor, j’ai mis en place une nouvelle station
météorologique avec un Raspberry Pi 3 que j’ai nommée AKUNU-station2. J’ai effectué des tests
de performance pour calculer la charge du CPU de chacune des stations ainsi que pour comparer
leurs performances en termes de vitesse de récolte de données. Etant donné que je ne possède à
l’heure actuelle qu’un seul anémomètre et qu’il n’y a qu’une seule antenne de champs
électromagnétiques, les tests effectués ne prennent pas en compte ces deux types de données.
Le tableau ci-dessous indique les pourcentages d’utilisation du CPU et de la RAM pour chaque
modèle en fonction des intervalles de récolte de données définis. Les utilitaires top et htop ont été
utilisés pour calculer les pourcentages d’utilisation du CPU et de la mémoire RAM.
A noter que le Raspberry Pi 3 possède plus du double de mémoire RAM que le Raspberry Pi Zero W
(927MB contre 433MB) ! Et il faut aussi savoir que le Raspberry Pi 3 possède 4 cœurs tandis que le
Pi Zero W est monocoeur. Le taux d’utilisation des CPUs du Raspberry Pi 3 indiqué dans le tableau
doit être divisé par 4 pour trouver le taux d’utilisation moyen par CPU.

Julien Brêchet
Température Pression Humidité Localisation Utilisation Utilisation

Modèle
[s] [s] [s] GPS [s] CPU [%] RAM [%]
Pi Zero W 120 120 120 120 100 18.7
Pi 3 120 120 120 120 101 14.7
Pi Zero W 60 60 60 60 100 18.8

Pi 3 60 60 60 60 103 14.8
Pi Zero W 1 1 1 1 100 18.8

Pi 3 1 1 1 1 124 14.9
Pi Zero W 0.1 0.1 0.1 0.1 100 21.9

Pi 3 0.1 0.1 0.1 0.1 134 16.29
Pi Zero W 0.01 0.01 0.01 0.01 100 22.4

Pi 3 0.01 0.01 0.01 0.01 175 16.31
Nous pouvons constater dans le tableau ci-dessus que malgré des fréquences de récolte
relativement faibles (120 secondes), le Raspberry Pi Zero W utilise déjà tout son CPU, dont au moins
95% alloués au programme de récolte de données. Le Pi 3 quant à lui utilise un CPU à fond mais en
possède encore trois autres qui fonctionnent à moins d’un pourcent chacun.
En augmentant les fréquences de récolte à une minute, il n’y a pas vraiment d’impact au niveau
de la mémoire utilisée. Au niveau CPU, le Pi Zero W est logiquement toujours à bloc tandis que le
Pi 3 est passé à 103% d’utilisation. En augmentant encore plus la fréquence avec maintenant une
récolte pour chaque type de donnée toutes les secondes, la mémoire n’est toujours pas vraiment
impactée mais nous pouvons apercevoir que le Pi 3 est maintenant passé à plus de 120% d’utilisation
CPU. En passant à 10 données par seconde pour chaque type, le pourcentage de mémoire utilisée
commence d’augmenter et le taux d’utilisation CPU du Pi 3 dépasse les 130%.
En passant à des fréquences allant au centième de seconde, l’utilisation de la mémoire subit encore
une augmentation mais elle est peu significative. L’utilisation CPU du Pi 3 augmente logiquement
mais reste bien en dessous des 200%. En diminuant drastiquement le nombre maximum de logs par
fichier sur le Raspberry Pi 3 de sorte à générer environ un envoi par seconde par type de donnée,
donc quatre envois sur le serveur de fichiers par seconde, j’ai réussi à faire monter le pourcentage
d’utilisation à 210%.
En paramétrant une récolte des données de température toutes les millisecondes et les autres types
à une minute ou plus, le Raspberry Pi Zero W n’arrive pas à récolter les données de température
plus rapidement qu’une fois toutes les 4-5 millisecondes (environ 4.9 millisecondes de moyenne).
Ce qui est bien trop lent pour pouvoir capturer des champs électromagnétiques générés par la
foudre. Le Pi 3 lui aussi ne récupère pas la température plus rapidement que le Pi Zero W, il est
parfois même plus lent !
Pour avoir une solution assez rapide qui puisse récolter les données de la foudre aux alentours de
la microseconde, il faudrait regarder du côté des plateformes Arduino qui sont réputées être de
meilleures solutions pour les systèmes temps réel. Ou sinon, il serait peut-être possible de concevoir
un élément intermédiaire disposant d’un buffer. Cet élément serait branché entre l’antenne de
champs électromagnétiques et le Raspberry Pi et permettrait à ce dernier de pouvoir lire plus
lentement les données récoltées lors de la détection d’un champ électromagnétique.

Julien Brêchet
En revenant aux tests concernant l’utilisation du CPU, grâce à ses quatre cœurs, le Raspberry Pi 3
supporte bien mieux que le Pi Zero W les grandes charges d’utilisation du script de récolte de
données lorsque les intervalles de récupération sont très rapides. La différence se remarque encore
plus lorsque le débit de fichiers envoyés sur le partage SMB est élevé. Le Pi Zero W a du mal à suivre
la cadence et il en résulte donc qu’il y a de nombreux échecs d’envois de fichiers, ce qui engendre
de nouvelles tentatives qui peuvent consommer une partie de la bande passante du réseau AKUNU.
Concernant la mémoire RAM, les tests démontrent que même avec des intervalles de récolte très
faibles, la mémoire utilisée par les Raspberry Pi 3 et Zero W ne dépasse pas les 25-30%. La RAM
n’est donc pas problématique au niveau des performances.
J’ai aussi pensé à calculer la consommation électrique réelle de chaque modèle de Raspberry Pi
mais je n’ai pas le matériel requis à disposition. J’ai effectué ces tests de performance lors de la
dernière semaine du travail de Bachelor, ce qui signifie que je n’ai malheureusement plus le temps
de chercher et de commander le matériel adéquat. Je ne le recevrais pas à temps de toute manière.
9.5.5 Améliorations futures

Ce travail de Bachelor est un projet de recherche qui va être repris par l’IICT et ses partenaires
sud-américains et sri lankais. De nouveaux fonds seront débloqués pour améliorer l’infrastructure
du réseau AKUNU. Les principales améliorations qui pourront être effectuées sont listées ci-
dessous :
 Mise en place d’un buffer intermédiaire sur des plateformes compatibles temps réel pour
pouvoir capturer au niveau de la microseconde les champs électromagnétiques générés par
la foudre
 Remplacement du wifi par une technologie de communication basse consommation telle
que LoRa, Sigfox, ZigBee, Bluetooth Low Energy etc. afin de pouvoir mettre les stations
météorologiques sur batteries
 Etude des batteries utilisables pour rendre les stations autonomes, actuellement il faudrait
des batteries énormes et coûteuses mais en mettant en place un protocole à faible
consommation à la place du wifi cela deviendrait plus abordable
 Calibrage des différents capteurs dans une salle disposant d’une infrastructure de test
 Mise en place d’une instance Cloud accessible par les météorologues et autres personnes
concernées par le projet AKUNU
 Développement sur l’instance Cloud d’une application web permettant d’analyser les
données récoltées
 Utilisation d’un système de temps haute précision (par exemple une horloge atomique) au
sein du réseau AKUNU pour pouvoir récolter les données des champs électromagnétiques
avec une précision en dessous de la microseconde
 Envoi de notifications évoluées par les stations concernant l’état de leurs threads de récolte
de données, possibilité de développement d’une fonctionnalité de notification dans
l’application web
9.5.6 Problèmes connus

9.5.6.1 Inversion des noms logiques des interfaces wlan
Parfois, au démarrage du routeur wifi Raspberry Pi, pour une raison inconnue la clef USB wifi prend
le nom wlan1 et la carte native le nom wlan0. Puisque les cartes sont inversées, les configurations
du service hostapd et les adresses IP définies ne correspondent pas. L’interface wlan0 est
normalement celle de la clef wifi et est connectée au réseau ayant un accès à Internet tandis que
la carte native prend le nom logique wlan1 et est connectée au réseau AKUNU.

Julien Brêchet
Pour être sûr que le routeur a démarré correctement, il faut regarder si le réseau AKUNU-LAN2
apparaît dans les réseaux wifi disponibles.
9.5.6.2 Détection difficile des satellites GPS dans certains bâtiments

Le capteur GPS et l’antenne UFL utilisés par la station météorologique ne disposent pas d’une
grande portée pour la détection des satellites. De ce fait, dans certains bâtiments avec des murs
épais et de nombreuses armatures métalliques comme à la HEIG-VD, il n’est parfois pas possible
d’obtenir une connexion avec des satellites et par conséquent le GPS ne peut pas nous retourner la
localisation de la station. Il faudrait acheter une antenne GPS plus puissante.

Julien Brêchet
10 Conclusion
La remise de ce rapport de projet conclut le travail de Bachelor que moi, Julien Brêchet, ai effectué
dans le cadre du projet de recherche AKUNU. De nombreuses recherches ont été effectuées sur les
capteurs, plateformes et technologies de communication existants et un réseau wifi AKUNU a été
mis en place. Dans ce réseau se trouvent actuellement plusieurs stations météorologiques, un
serveur de fichiers ainsi qu’un routeur wifi permettant aux dispositifs AKUNU de disposer d’un accès
à Internet.
Après que les différents capteurs aient été initialement testés sur une plaque de test, des cartes
PCB ont été conçues. Le résultat s’est avéré concluant et il est d’ailleurs prévu dans les semaines
suivant la remise de ce travail de faire construire de nouvelles cartes PCB afin de pouvoir les
envoyer aux instituts et universités concernés par le projet AKUNU.
Des tests de performance ont été effectués et il en résulte principalement que les plateformes
Raspberry Pi ne sont pas assez rapides pour récolter les champs électromagnétiques générés par la
foudre. Il faudrait utiliser une plateforme compatible temps réel (un modèle Arduino par exemple)
faisant office de buffer pour stocker les champs électromagnétiques capturés et qu’ensuite la
station Raspberry Pi vienne lire les données enregistrées. Il serait aussi intéressant de mettre en
place une horloge atomique ou une solution équivalente pour disposer d’un système de temps haute
précision au sein du réseau AKUNU afin d’avoir des données temporelles fiables dans le but de les
comparer avec d’autres instituts et entreprises. Mais la mise en place d’une solution de ce genre
peut coûter plusieurs milliers de francs !
Malgré un manque de précision temporelle et de rapidité de récupération des données, les
plateformes Raspberry Pi se sont montrées robustes et fiables concernant la récolte des autres
types de données. De nombreuses séries de tests ont été effectuées et après bon nombre
d’améliorations apportées au script de récolte de données et à la conception de cartes PCB pour
améliorer la connectivité des capteurs, l’infrastructure AKUNU peut fonctionner 24 heures sur 24
sans rencontrer le moindre problème. La mise en place d’un réseau AKUNU fiable et robuste peut
donc être considérée comme un succès !
Il sera possible par la suite d’utiliser d’autres protocoles de communication à faible consommation
afin de tenter de mettre les stations météorologiques sur batteries pour les rendre autonomes. Il
faudra aussi construire des boîtes de protection permettant d’isoler les plateformes sans toutefois
devoir altérer la valeur des données récoltées. Une boîte entièrement hermétique ne permettrait
par exemple pas de récupérer le vrai pourcentage d’humidité environnante. La mise en place d’une
instance Cloud est aussi prévue par la suite et des spécialistes back-end et front-end pourront
développer une application web qui permettrait d’analyser les données des fichiers de logs générés
par les stations. Le format des données est compatible CSV. Donc actuellement, le meilleur moyen
d’analyser les logs est d’aller sur le partage SMB du serveur de fichiers, de récupérer les données
et de les importer dans un fichier CSV pour pouvoir générer des graphiques.
Concernant mon expérience personnelle sur ce travail, j’ai décidé d’écrire mes scripts en Python
car c’est un langage que j’ai peu utilisé durant mes années d’études mais qui pourra m’être très
utile dans ma carrière professionnelle. J’ai perdu plusieurs heures au début de ce travail de
Bachelor pour commencer à maîtriser le langage mais je suis satisfait de l’expérience que j’ai
acquise. J’ai aussi apprécié de pouvoir toucher à plusieurs domaines que je ne connaissais pas
beaucoup. J’ai notamment trouvé intéressante la conception de cartes PCB avec le logiciel Altium.
De plus, Monsieur Guinchard et ses collègues m’ont expliqué des choses intéressantes au sujet du
processus de fabrication des cartes PCB. J’ai apprécié de toucher un peu au monde de
l’électronique, domaine auquel je m’intéresse mais dans lequel je ne me suis jamais vraiment

Julien Brêchet
plongé entièrement. De par mon métier d’informaticien, je suis beaucoup plus proche du matériel
propre à l’informatique, comme par exemple l’acquisition et le montage de différents composants
pour installer une tour d’ordinateur.
Je remercie encore une fois toutes les personnes qui ont participé au projet AKUNU en m’aidant
lors de différentes tâches ainsi que les personnes qui auront pris le temps de lire ce rapport de
travail de Bachelor. J’estime que j’ai effectué un bon travail et que maintenant le projet AKUNU
dispose d’une bonne base sur laquelle commencer de nouvelles recherches et de nouveaux
développements. Je passe maintenant le témoin à Monsieur Marcos Rubinstein et lui remets le
projet AKUNU entre ses mains.

Julien Brêchet
11 Références
[1] « Raspberry Pi Zero W », Raspberry Pi. [En ligne]. Disponible sur:
https://www.raspberrypi.org/products/raspberry-pi-zero-w/. [Consulté le: 05-juin-2018].
[2] « Comparatif des modèles de Raspberry PI | Tableaux comparatifs », SocialCompare. [En
ligne]. Disponible sur: http://socialcompare.com/fr/comparison/raspberrypi-models-
comparison. [Consulté le: 05-juin-2018].
[3] « Raspberry Pi 3 Model B+ », Raspberry Pi. [En ligne]. Disponible sur:
https://www.raspberrypi.org/products/raspberry-pi-3-model-b-plus/. [Consulté le: 05-juin-
2018].
[4] « Arduino - Introduction », Arduino. [En ligne]. Disponible sur:
https://www.arduino.cc/en/Guide/Introduction. [Consulté le: 05-juin-2018].
[5] maxpeigne, « Différence entre Arduino et Raspberry Pi ? » [En ligne]. Disponible sur:
http://forums.futura-sciences.com/electronique/699229-difference-entre-arduino-raspberry-
pi.html. [Consulté le: 05-juin-2018].
[6] « Arduino M0 », Arduino. [En ligne]. Disponible sur: https://store.arduino.cc/arduino-m0.
[Consulté le: 05-juin-2018].
[7] « Arduino Due », Arduino. [En ligne]. Disponible sur: https://store.arduino.cc/arduino-due.
[8] « Top 12 Raspberry Pi alternatives (2018 edition) », ZDNet. [En ligne]. Disponible sur:
https://www.zdnet.com/pictures/top-12-raspberry-pi-alternatives-2018-edition/7/.
[9] « Adafruit BME280 I2C or SPI Temperature Humidity Pressure Sensor », Adafruit. [En ligne].
Disponible sur: https://www.adafruit.com/product/2652. [Consulté le: 05-juin-2018].
[10] « Passive GPS Antenna uFL - 9mm x 9mm -2dBi gain », Adafruit. [En ligne]. Disponible sur:
https://www.adafruit.com/product/2460. [Consulté le: 05-juin-2018].
[11] « Antennes GPS », TRAKGPS. [En ligne]. Disponible sur:
http://www.trakgps.com/fr/index.php/information/articles-localisation-gps/67-antennes-
gps. [Consulté le: 05-juin-2018].
[12] « Adafruit Ultimate GPS Breakout - 66 channel w/10 Hz updates », Adafruit. [En ligne].
[13] « Anemometer Wind Speed Sensor w/Analog Voltage Output », Adafruit. [En ligne].
[14] « Sigfox », Wikipédia. 28-mai-2018.
[15] « Coverage | Sigfox », SigFox. [En ligne]. Disponible sur:
https://www.sigfox.com/en/coverage. [Consulté le: 05-juin-2018].
[16] « Sigfox Technology Overview | Sigfox », Sigfox. [En ligne]. Disponible sur:
https://www.sigfox.com/en/sigfox-iot-technology-overview. [Consulté le: 05-juin-2018].
[17] SIGFOX, Sigfox Network Architecture. .
[18] « IEEE 802.15.4 », Wikipédia. 22-mars-2018.
[19] « ZigBee », Wikipédia. 02-févr-2018.
[20] « Our Members | Zigbee Alliance », ZigBee. [En ligne]. Disponible sur:
http://www.zigbee.org/zigbeealliance/our-members/. [Consulté le: 05-juin-2018].
[21] « Zigbee 3.0 | Zigbee Alliance », ZigBee. [En ligne]. Disponible sur:
http://www.zigbee.org/zigbee-for-developers/zigbee-3-0/. [Consulté le: 05-juin-2018].
[22] « Zigbee PRO | Zigbee Alliance », ZigBee. [En ligne]. Disponible sur:
http://www.zigbee.org/zigbee-for-developers/zigbee-pro/. [Consulté le: 05-juin-2018].
[23] M. A. Moridi, Y. Kawamura, M. Sharifzadeh, E. K. Chanda, M. Wagner, et H. Okawa,
« Performance analysis of ZigBee network topologies for underground space monitoring and
communication systems », Tunn. Undergr. Space Technol., vol. 71, p. 201‑209, janv. 2018.
[24] V. Iordache, M. Minea, et R. A. Gheorghiu, « Considerations for using ZigBee technology in
vehicular non-critical applications », 2017, p. 853‑856.
[25] « Z-Wave », Wikipédia. 18-févr-2018.

Julien Brêchet
[26] B. Ray, « Z-Wave Vs. Zigbee », Link-Labs, 21-nov-2017. [En ligne]. Disponible sur:
https://www.link-labs.com/blog/z-wave-vs-zigbee. [Consulté le: 05-juin-2018].
[27] « About Z-Wave Technology », Z-Wave Alliance. [En ligne]. Disponible sur: https://z-
wavealliance.org/about_z-wave_technology/. [Consulté le: 05-juin-2018].
[28] « Z-Wave Global Regions | Silicon Labs ». [En ligne]. Disponible sur:
https://www.silabs.com/products/wireless/mesh-networking/z-
wave/benefits/technology/global-regions. [Consulté le: 05-juin-2018].
[29] « Understanding Z-Wave Networks, Nodes & Devices | Vesternet ». [En ligne]. Disponible
sur: https://www.vesternet.com/resources/technology-indepth/understanding-z-wave-
networks/. [Consulté le: 05-juin-2018].
[30] « Bluetooth », Wikipédia. 11-mai-2018.
[31] « Topology Options | Bluetooth Technology Website », Bluetooth.com. [En ligne].
Disponible sur: https://www.bluetooth.com/bluetooth-technology/topology-options.
[32] « Bluetooth à basse consommation », Wikipédia. 20-avr-2018.
[33] « IEEE 802.11 », Wikipédia. 09-mars-2018.
[34] « IEEE 802.11ah », Wikipédia. 28-janv-2018.
[35] « Global System for Mobile Communications », Wikipédia. 25-mars-2018.
[36] « General Packet Radio Service », Wikipédia. 14-nov-2016.
[37] D. Nussbaum, « Le débit des téléphones portables : de la 1G à la 4G », Futura Tech, 11-
déc-2015. [En ligne]. Disponible sur: https://www.futura-
sciences.com/tech/dossiers/telecoms-histoire-telephone-portable-annees-80-nos-jours-
1944/page/5/. [Consulté le: 07-juin-2018].
[38] « Universal Mobile Telecommunications System », Wikipédia. 28-févr-2018.
[39] « UMTS frequency bands », Wikipedia. 12-mars-2018.
[40] « LTE (réseaux mobiles) », Wikipédia. 29-mai-2018.
[41] « LTE Advanced », Wikipédia. 10-mars-2018.
[42] « Samba (informatique) », Wikipédia. 25-avr-2018.
[43] « Server Message Block », Wikipédia. 19-déc-2017.
[44] « Samba: Set up a Raspberry Pi as a File Server for your local network », The MagPi
Magazine, 02-juin-2017. .
[45] F. Boender, « Store credentials in file for use with smbclient », Coderwall, 25-févr-2016.
[En ligne]. Disponible sur: https://coderwall.com/p/bkpiyg/store-credentials-in-file-for-use-
with-smbclient. [Consulté le: 14-juin-2018].
[46] « xDevs.com | Using BME280 temperature/humidity/pressure sensor with Raspberry Pi ».
[En ligne]. Disponible sur: https://xdevs.com/guide/thp_rpi/. [Consulté le: 14-juin-2018].
[47] « Kuman RPi GPIO Breakout Expansion Kit For Raspberry PI with 3.5 Inch LCD Screen , T-
type expansion board + 400 points Tie Points Solderless Breadboard + 40 pin IDE male:
Amazon.fr: High-tech ». [En ligne]. Disponible sur: https://www.amazon.fr/Kuman-
Expansion-Raspberry-Solderless-
Breadboard/dp/B074DV8DKR/ref=sr_1_2?ie=UTF8&qid=1525347075&sr=8-
2&keywords=Raspberry+Pi+Gpio+Kit. [Consulté le: 14-juin-2018].
[48] Adafruit, Adafruit_Python_GPIO: Library to provide a cross-platform GPIO interface on
the Raspberry Pi and Beaglebone Black using the RPi.GPIO and Adafruit_BBIO libraries.
Adafruit Industries, 2018.
[49] Adafruit, Adafruit_Python_BME280: Python Driver for the Adafruit BME280 Breakout.
Adafruit Industries, 2018.
[50] « I2C », Wikipédia. 17-mai-2018.
[51] « Setting Everything Up | Adafruit Ultimate GPS on the Raspberry Pi | Adafruit Learning
System », Adafruit. [En ligne]. Disponible sur: https://learn.adafruit.com/adafruit-ultimate-
gps-on-the-raspberry-pi/setting-everything-up. [Consulté le: 14-juin-2018].

Julien Brêchet
[52] « Using UART instead of USB | Adafruit Ultimate GPS on the Raspberry Pi | Adafruit
Learning System ». [En ligne]. Disponible sur: https://learn.adafruit.com/adafruit-ultimate-
gps-on-the-raspberry-pi/using-uart-instead-of-usb. [Consulté le: 14-juin-2018].
[53] « UART », Wikipédia. 12-juin-2018.
[54] D. Mandle, « Getting GPSd to work with Python and Threading », Things I’ve Figured Out,
06-sept-2012. .
[55] « Raspberry Pi Time », Autonomic Guru, 08-nov-2016. [En ligne]. Disponible sur:
https://autonomic.guru/gps-time-on-raspberry-pi/. [Consulté le: 03-juill-2018].
[56] « Pulse par seconde », Wikipédia. 12-févr-2018.
[57] « NTP: ntpq output explained | TECH.kulish.com », 30-oct-2007. .
[58] « Twisted », Twisted Matrix Labs. [En ligne]. Disponible sur:
https://twistedmatrix.com/trac/wiki. [Consulté le: 09-juill-2018].
[59] « Documentation – Twisted », Twisted Matrix Labs. [En ligne]. Disponible sur:
https://twistedmatrix.com/trac/wiki/Documentation. [Consulté le: 09-juill-2018].
[60] « Downloads – Twisted », Twisted Matrix Labs. [En ligne]. Disponible sur:
https://twistedmatrix.com/trac/wiki/Downloads. [Consulté le: 09-juill-2018].
[61] Glyph, « Twisted - How to run a Twisted server in a non-main thread », Stack Overflow,
16-oct-2012. [En ligne]. Disponible sur: https://stackoverflow.com/questions/12917980/non-
blocking-server-in-twisted/12924751. [Consulté le: 09-juill-2018].
[62] A. Industries, « MCP3008 - 8-Channel 10-Bit ADC With SPI Interface », Adafruit. [En ligne].
Disponible sur: https://www.adafruit.com/product/856. [Consulté le: 09-juill-2018].
[63] « 2.7V 4-Channel/8-Channel 10-Bit A/D Converters with SPI Serial Interface | Application
Notes », p. 40, 2008.
[64] « Serial Peripheral Interface », Wikipédia. 12-avr-2018.
[65] T. DiCola, « MCP3008 | Raspberry Pi Analog to Digital Converters | Adafruit Learning
System », Adafruit. [En ligne]. Disponible sur: https://learn.adafruit.com/raspberry-pi-
analog-to-digital-converters/mcp3008. [Consulté le: 11-juill-2018].
[66] Adafruit_Python_MCP3008: Python code to use the MCP3008 analog to digital converter
with a Raspberry Pi or BeagleBone black. Adafruit Industries, 2018.
[67] chinaplccenter.com, « QS-FS | Application notes in English ». .
[68] « An introduction to npyscreen — npyscreen documentation », Readthedocs. [En ligne].
Disponible sur: http://npyscreen.readthedocs.io/introduction.html. [Consulté le: 09-juill-
2018].
[69] npcole, Repository GitHub de la librarie npyscreen. 2018.
[70] C. Gohlke, « Python Extension Packages for Windows - Curses ». [En ligne]. Disponible sur:
https://www.lfd.uci.edu/~gohlke/pythonlibs/#curses. [Consulté le: 16-juill-2018].
[71] « D-LINK Netzwerkadapter - Interdiscount », Interdiscount. [En ligne]. Disponible sur:
https://www.interdiscount.ch/fr/ordinateurs-logiciel/r%C3%A9seau/accessoires-
r%C3%A9seau--C526000/d-link-netzwerkadapter--P0000371099. [Consulté le: 16-juill-2018].
[72] « dwa-131 [Wiki ubuntu-fr] », Wiki Ubuntu-fr. [En ligne]. Disponible sur:
https://doc.ubuntu-fr.org/dwa-131. [Consulté le: 16-juill-2018].
[73] M. Bergmark, rtl8192eu-linux-driver: Drivers for the rtl8192eu chipset for wireless
adapters (D-Link DWA-131 rev E1 included!). 2018.
[74] « DWA-131 REV_E Drivers », D-Link. [En ligne]. Disponible sur:
ftp://files.dlink.com.au/products/DWA-131/REV_E/Drivers/. [Consulté le: 16-juill-2018].
[75] « Setting up a Raspberry Pi as an access point in a standalone network (NAT) - Raspberry Pi
Documentation », Raspberry Pi. [En ligne]. Disponible sur:
https://www.raspberrypi.org/documentation/configuration/wireless/access-point.md.
[Consulté le: 16-juill-2018].
[76] E. Scalafiotti, « Turn a RaspBerryPi 3 into a WiFi router-hotspot », Edo Scalafiotti, 17-juin-
2016. .
[77] Soren, « How-To: Turn a Raspberry Pi into a WiFi router », Raspberry Pi HQ, 04-déc-2013. .
[78] M. Jaiswal, « python - How to process SIGTERM signal gracefully? », Stack Overflow. .

Julien Brêchet
[79] sajattack, « twisted port.stopListening() doesn’t stop? », GitHub. [En ligne]. Disponible
sur: https://github.com/riptideio/pymodbus/issues/19. [Consulté le: 22-juill-2018].
[80] « RPi.GPIO », PyPI. [En ligne]. Disponible sur: https://pypi.org/project/RPi.GPIO/.
[81] aaronasterling, « python - efficient circular buffer », Stack Overflow. [En ligne].
Disponible sur: https://stackoverflow.com/questions/4151320/efficient-circular-buffer.
[82] « Win32DiskImager - Ubuntu Wiki », Wiki Ubuntu. [En ligne]. Disponible sur:
https://wiki.ubuntu.com/Win32DiskImager. [Consulté le: 23-juill-2018].
[83] M. Heuberger, « Bug #1394163 “Unable to turn powersave for wlan0 off” : Bugs : linux
package : Ubuntu », Launchpad.net. 21-nov-2014.
12 Liste des symboles et des abréviations

GPIO : Global Purpose Input/Output
HAT : Hardware Attached on Top
CSI : Camera Serial Interface
BLE : Bluetooth Low Energy
DSI : Display Serial Interface
PoE : Power over Ethernet
I2C : Inter-Integrated Circuit
SPI : Serial Peripheral Interface
GPS : Global Positioning System
UFL : connecteur RF coaxial miniature pour les signaux haute-fréquence
RF : Radio Frequency
LNA : Low Noise Amplifier ou amplificateur faible bruit en français
RTC : Real Time Clock
PPS : Pulse-Per-Second signal
PRN : PseudoRandom Noise
TTL : Transistor-Transistor Logic
UART : Universal Asynchronous Receiver Transmitter
LPWAN : Low Power Wide Area Network
ISM : Industriel, Scientifique, Médical
LoRa : Long Range, technologie LPWAN utilisée dans le monde de l’internet des objets
D-BPSK : Differentially encoded Binary Phase Shift Keying
LR WPAN : Low Rate Wireless Personal Area Network
IEEE : Institute of Electrical and Electronics Engineers
CSMA/CA : Carrier Sense Multiple Access with Collision Avoidance
CSMA/CD : Carrier Sense Multiple Access with Collision Detection
IoT : Internet of Things
AES : Advanced Encryption Standard
AODV : Ad hoc On-Demand Vector routing, protocole de routage réactif
FFD : Full Function Device
RFD : Reduced Function Device
UIT : Union Internationale des Télécommunications, siège situé à Genève
NIST : National Institute of Standards and Technology
SGIP : Smart Grid Interoperability Panel
UHF : Ultra Haute Fréquence, bande du spectre électromagnétique comprise entre 300 et 3’000MHz
U-NII : Unlicensed National Information Infrastructure

Julien Brêchet
GSM : Global System for Mobile communications, 2G

GPRS : General Packet Radio Service, 2.5G
EDGE : Enhanced Data rates for GSM Evolution, 2.75G
UMTS : Universal Mobile Telecommunications System
IMT : International Mobile Telecommunications
E-GSM : Extended GSM
LTE : Long Term Evolution, 4G
UTC : Temps Universel Coordonné
SMB : Server Message Block
CIFS : Common Internet File System
UNC : Universal Naming Convention
SDA : Serial Data Line
SCL : Serial Clock Line
NTP : Network Time Protocol
APT : Advanced Package Tool
MIT : Massachusetts Institute of Technology
ADC : Analog to Digital Converter
sps : samples per second
PCB : Printed Circuit Board ou circuit imprimé en français
AP : Access Point
MISO : Master Input Slave Output
MOSI : Master Output Slave Input
DKMS : Dynamic Kernel Module Support
RAM : Random Access Memory
CPU : Central Processing Unit
13 Liste des figures

FIGURE 1 : RASPBERRY PI ZERO W TROUVÉ SUR LE SITE OFFICIEL RASPBERRYPI.ORG .............................................................................. 14
FIGURE 2 : RASPBERRY PI 3 B+ TROUVÉ SUR LE SITE OFFICIEL RASPBERRYPI.ORG .................................................................................. 15
FIGURE 3 : ARDUINO M0 TROUVÉ SUR LE SITE OFFICIEL ARDUINO.CC ................................................................................................. 16
FIGURE 4 : ARDUINO DUE TROUVÉ SUR LE SITE OFFICIEL ARDUINO.CC................................................................................................. 16
FIGURE 5 : CAPTEUR ADAFRUIT BME 280 TROUVÉ SUR LE SITE OFFICIEL ADAFRUIT.COM ....................................................................... 17
FIGURE 6 : ANTENNE PASSIVE AVEC CONNECTEUR UFL TROUVÉE SUR LE SITE OFFICIEL ADAFRUIT.COM ..................................................... 18
FIGURE 7 : ADAFRUIT ULTIMATE GPS BREAKOUT SUR UNE PLAQUE DE TEST TROUVÉ SUR LE SITE OFFICIEL ADAFRUIT.COM ........................... 19
FIGURE 8 : ANÉMOMÈTRE AVEC TENSION DE SORTIE ANALOGIQUE TROUVÉ SUR LE SITE OFFICIEL ADAFRUIT.COM ........................................ 20
FIGURE 9 : ARCHITECTURE LORAWAN SIMPLIFIÉE SELON THETHINGSNETWORK.ORG ............................................................................ 21
FIGURE 10 : COUVERTURE DU RÉSEAU SIGFOX SELON LE SITE OFFICIEL [15]......................................................................................... 22
FIGURE 11 : ARCHITECTURE SIGFOX TROUVÉE SUR UNE VIDÉO YOUTUBE DE L'ENTREPRISE [17] .............................................................. 23
FIGURE 12 : APERÇU SOUS FORME DE PILE POUR LA TECHNOLOGIE ZIGBEE 3.0 [21] ............................................................................. 25
FIGURE 13 : 3 DIFFÉRENTES TOPOLOGIES ZIGBEE EXPLIQUÉES DANS L'ARTICLE [23] .............................................................................. 27
FIGURE 14 : COUVERTURE DU RÉSEAU Z-WAVE SELON [28] ............................................................................................................ 28
FIGURE 15 : TABLEAU MONTRANT LES PROTOCOLES WIFI EXISTANTS AINSI QUE LEURS CARACTÉRISTIQUES PRINCIPALES ................................ 30
FIGURE 16 : COMPARATIF DES DÉBITS DES DIFFÉRENTES NORMES DE RÉSEAUX TÉLÉPHONIQUES TROUVÉ SUR [37]....................................... 31
FIGURE 17 : EXEMPLE DE TOPOLOGIE WLAN POUR LE RÉSEAU AKUNU ............................................................................................ 34
FIGURE 18 : DIAGRAMME DE FLUX EN BLOC INDIQUANT COMMENT LES DONNÉES SONT RÉCOLTÉES ET STOCKÉES ........................................ 35
FIGURE 19 : POINT D'ACCÈS LINKSYS WIRELESS G .......................................................................................................................... 36
FIGURE 20 : CONFIGURATION DE L'INTERFACE WLAN0 DANS LE FICHIER DHCPCD.CONF .......................................................................... 37
FIGURE 21 : PARAMÉTRAGE DU PARTAGE SMB ............................................................................................................................. 38
FIGURE 22 : SERVEUR DE FICHIERS RASPBERRY PI 3 B+ ................................................................................................................... 38
FIGURE 23 : CONTENU D'UN KIT D'EXTENSION GPIO TROUVÉ SUR AMAZON [47] ................................................................................ 40

Julien Brêchet
FIGURE 24 : CODAGE D'UN BIT I2C TROUVÉ SUR WIKIPÉDIA [50]...................................................................................................... 41

FIGURE 25 : VÉRIFICATION QUE LA COMMUNICATION I2C FONCTIONNE AVEC LE CAPTEUR...................................................................... 41
FIGURE 26 : EXEMPLE D'UNE TRAME UART TROUVÉ SUR WIKIPÉDIA [53] .......................................................................................... 42
FIGURE 27 : BRANCHEMENT DES CAPTEURS BME 280 ET GPS SUR LA PLAQUE D'ESSAI......................................................................... 43
FIGURE 28 : AJOUT D'UNE ANTENNE PASSIVE UFL 9MM X 9MM POUR AMÉLIORER LA DÉTECTION DES SATELLITES ...................................... 44
FIGURE 29 : DIAGRAMME DE FLUX EN BLOC ILLUSTRANT LE FONCTIONNEMENT DU NOUVEAU PROCESSUS DE RÉCOLTE DES DONNÉES .............. 46
FIGURE 30 : NOUVELLE TOPOLOGIE DU RÉSEAU WLAN AKUNU ...................................................................................................... 48
FIGURE 31 : CONFIGURATION PAR DÉFAUT DU DAEMON GPSD .......................................................................................................... 49
FIGURE 32 : AJOUT DU SIGNAL PPS POUR LE GPS ......................................................................................................................... 50
FIGURE 33 : AJOUT DES SOURCES GPS ET PPS POUR NTP .............................................................................................................. 50
FIGURE 34 : AFFICHAGE DE LA SORTIE DE LA COMMANDE NTPQ -NP................................................................................................... 51
FIGURE 35 : PHOTO D'UN MCP3008 TROUVÉE SUR LE SITE OFFICIEL D'ADAFRUIT [62] ........................................................................ 52
FIGURE 36 : CONFIGURATION DES GPIO DU RASPBERRY PI UTILISÉS POUR COMMUNIQUER AVEC L’ADC MCP3008 ................................. 53
FIGURE 37 : FORMULE DE CONVERSION DES DONNÉES NUMÉRIQUES BRUTES EN VITESSE DU VENT EN M/S ................................................ 53
FIGURE 38 : PLAQUE DE TEST AVEC TOUS LES CAPTEURS ET TOUTES LES CONNEXIONS NÉCESSAIRES .......................................................... 54
FIGURE 39 : CARTE PCB FACE RECTO AVEC CAPTEURS ..................................................................................................................... 55
FIGURE 40 : PCB FACE VERSO .................................................................................................................................................... 56
FIGURE 41 : CARTE PCB INSTALLÉE SUR LA STATION RASPBERRY PI ................................................................................................... 56
FIGURE 42 : CONSOLE UTILISATEUR AVEC LAQUELLE ON VEUT MODIFIER L'INTERVALLE DE TEMPÉRATURE DE LA STATION 192.168.2.11 ........ 57
FIGURE 43 : RÉPONSE REÇUE SUITE À UN CHANGEMENT FRUCTUEUX DE LA VALEUR DU COMPTEUR .......................................................... 58
FIGURE 44 : MESSAGE D'ERREUR FAISANT SUITE À L'ENVOI D'UNE ADRESSE IP ERRONÉE ........................................................................ 59
FIGURE 45 : AFFICHAGE DES INTERFACES RÉSEAU EXISTANTES AVEC LA COMMANDE LSHW ...................................................................... 60
FIGURE 46 : CONFIGURATION DES INTERFACES WLAN ................................................................................................................... 60
FIGURE 47 : CONFIGURATION DU FICHIER DNSMASQ.CONF .............................................................................................................. 61
FIGURE 48 : CLEF USB WIFI BRANCHÉE SUR LE RASPBERRY PI 3 ........................................................................................................ 62
FIGURE 49 : DIAGRAMME DE FLUX DÉMONTRANT LE FONCTIONNEMENT DU GRACEFUL KILLER ................................................................ 63
FIGURE 50 : NOUVELLE VERSION DE LA CARTE PCB FACE RECTO........................................................................................................ 65
FIGURE 51 : CONFIGURATION DES GPIO POUR LA COMMUNICATION ENTRE LE RASPBERRY PI ET LE NOUVEL ADC ...................................... 65
FIGURE 52 : DIAGRAMME DE FLUX ILLUSTRANT LE FONCTIONNEMENT DU SYSTÈME D'INTERRUPTIONS ...................................................... 66
FIGURE 53 : CONDENSATEUR CHARGÉ SUR UNE PILE 9V .................................................................................................................. 66
FIGURE 54 : CRÉATION D'UN CHAMP ÉLECTROSTATIQUE AVEC UN CONDENSATEUR CHARGÉ .................................................................... 67
FIGURE 55 : ANTENNE DE CHAMPS ÉLECTROMAGNÉTIQUES BRANCHÉE AU CONNECTEUR BNC FEMELLE DU RASPBERRY PI ........................... 67
FIGURE 56 : LOGO ACTUEL DU PROJET AKUNU............................................................................................................................. 68
FIGURE 57 : SORTIE DE LA COMMANDE IWCONFIG INDIQUANT QUE LE POWER MANAGEMENT EST DÉSACTIVÉ ........................................... 69

Julien Brêchet
14 Annexes
Les documents annexes au rapport de projet sont les suivants :
 Page d’annonce des annexes

 Planification des tâches du travail de Bachelor
 Diagramme de GANTT de la planification
 Journal de travail de la seconde phase du travail de Bachelor
 Schéma Visio de l’ancienne topologie WLAN
 Schéma Visio de la nouvelle topologie WLAN
 Diagramme Visio du fonctionnement du GracefullKiller
 Diagramme Visio du fonctionnement du système d’interruptions
 Diagramme Visio de l’ancien processus de récolte de données
 Diagramme Visio de la nouvelle version du processus de récolte de données
 *Librairie Adafruit_Python_GPIO
 *Librairie Adafruit_Python_BME280
 *Librairie Adafruit_Python_MCP3008
 *Librairie Twisted
 *Librairie npyscreen
 *Fichier WHL de Curses 2.2 pour Windows 64 bits
 *Driver rtl8192eu pour Linux
 Notes d’application de l’anémomètre QS-FS01
 Notes d’application du capteur BME 280
 Notes d’application de l’Adafruit Ultimate GPS
 Notes d’application du convertisseur analogique-numérique MCP3008
 Script de récolte de données twistedServer.py
 Script twistedClient.py
 Script npyscreenClient.py
 Affiche du travail de Bachelor
 Manuel d’installation
 Manuel utilisateur
 Document contenant les informations de connexion
 *Schéma de la carte PCB
 *Plan de la carte PCB
 *Logo AKUNU
 *Image 20180724_AKUNU-server.img
 *Image 20180724_AKUNU-station1.img
* = version numérique uniquement

Julien Brêchet
15 Signature
Je soussigné, Julien Brêchet, étudiant de troisième année de la filière Réseaux et Services au sein
de la HEIG-VD d’Yverdon-les-Bains, confirme avoir réalisé seul mon travail de Bachelor et avoir cité
les sources que j’ai utilisées dans les références du rapport.
Julien Brêchet

Brêchet Julien

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Brêchet Julien

Transféré par

Droits d'auteur :

Formats disponibles

AKUNU

Réseau mondial de capteurs atmosphériques

Etudiant : Julien Brêchet

Yverdon-les-Bains, jeudi 26 juillet 2018

AKUNU – rapport de projet -2- 26.07.2018

1 Clause de confidentialité liée au travail de Bachelor

AKUNU – rapport de projet -3- 26.07.2018

AKUNU – rapport de projet -4- 26.07.2018

AKUNU – rapport de projet -5- 26.07.2018

5 Cahier des charges

AKUNU – rapport de projet -6- 26.07.2018

AKUNU – rapport de projet -7- 26.07.2018

AKUNU – rapport de projet -8- 26.07.2018

AKUNU – rapport de projet -9- 26.07.2018

7 Table des matières

AKUNU – rapport de projet - 10 - 26.07.2018

AKUNU – rapport de projet - 11 - 26.07.2018

capteurs météorologiques au fur et à mesure afin de se rapprocher le plus possible de la récolte de

9.1.2 Spécifications des plateformes

9.1.3 Spécifications des capteurs

9.1.4 Spécifications des technologies

AKUNU – rapport de projet - 12 - 26.07.2018

9.1.5 Analyse des plateformes existantes

9.1.5.1.1 Raspberry Pi Zero W

 1 processeur monocoeur d’une fréquence de 1GHz

AKUNU – rapport de projet - 13 - 26.07.2018

Figure 1 : Raspberry Pi Zero W trouvé sur le site officiel raspberrypi.org

Selon le site de comparaison socialcompare.com [2], le Raspbery Pi Zero W consomme seulement

9.1.5.1.2 Raspberry Pi 3 Modèle B+

 1 processeur Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC @ 1.4GHz

AKUNU – rapport de projet - 14 - 26.07.2018

Figure 2 : Raspberry Pi 3 B+ trouvé sur le site officiel raspberrypi.org

9.1.5.2 Modèles Arduino

 1 microcontrôleur ATSAMD21G18, 48pins LQFP

AKUNU – rapport de projet - 15 - 26.07.2018

Figure 3 : Arduino M0 trouvé sur le site officiel arduino.cc

9.1.5.2.2 Arduino Due

Figure 4 : Arduino Due trouvé sur le site officiel arduino.cc

9.1.5.3 Autres plateformes

AKUNU – rapport de projet - 16 - 26.07.2018

9.1.6 Analyse des capteurs existants

9.1.6.1 Adafruit BME 280

9.1.6.2 Antenne GPS passive UFL 9mm x 9mm

 Interface IPX UFL

AKUNU – rapport de projet - 17 - 26.07.2018

9.1.6.3 Adafruit Ultimate GPS Breakout

AKUNU – rapport de projet - 18 - 26.07.2018

9.1.6.4 Anémomètre avec sortie de tension analogique QS-FS01

AKUNU – rapport de projet - 19 - 26.07.2018

9.1.6.5 Capteur de champ électromagnétique

9.1.7 Analyse des technologies de communication existantes

9.1.7.1 Technologies LPWAN

AKUNU – rapport de projet - 20 - 26.07.2018

Figure 9 : architecture LoRaWAN simplifiée selon thethingsnetwork.org

La figure 9 ci-dessus décrit de manière simplifiée le fonctionnement de l’infrastructure de la

AKUNU – rapport de projet - 21 - 26.07.2018

auraient relayé le message du périphérique. Ensuite il envoie le message à l’application à laquelle

Figure 10 : Couverture du réseau Sigfox selon le site officiel [15]

AKUNU – rapport de projet - 22 - 26.07.2018

AKUNU – rapport de projet - 23 - 26.07.2018

9.1.7.2 Technologies LR WPAN

 Formation d’un réseau de type étoilé ou maillé

 1 canal 868MHz disponible en Europe, débit maximal théorique de 20kbps

AKUNU – rapport de projet - 24 - 26.07.2018