Réf : / AU : 2021-2022

Université de Sousse

Ecole Nationale d’Ingénieurs de Sousse

Département Électronique Industrielle

Mémoire de Projet de Fin d'Études
Présenté en vue de l’obtention du

Diplôme National d’Ingénieur en Génie Electronique

Industrielle
Etude et développement d’un concentrateur LoRa
Réalisée par : Ahmed BEN LAKHEL
Au sein de Telnet Holding

Soutenu le 08/09/2022 devant le jury :

Président : Mme. Hajer KOUKI, ENISo

Rapporteur : Mr. Mossaad BEN AYED, ENISo
Encadrant académique : Mme. Hajer CHTIOUI, ENISo
Encadrant professionnel : Mr. Makrem BENABDALLAH, Telnet Holding
Encadrant professionnel : Mr. Saber OUESLATI, Telnet Holding
© Ahmed 2022
 Signature de l’encadrant

Signature et cachet

ENISo Page 1
 Remerciements

Les plus grands remerciements sont à Dieu, qui m’a guidé tout au long de mon parcours
académique pour pouvoir arriver à cette phase finale et présenter mon travail réalisé au cours
de ces six derniers mois.
Je remercie ma mère et ma sœur. Ma famille a tout donné pour que j’excelle et je réussisse
mon projet dans les meilleures conditions. Mes grandes gratitudes à mon père qui a tout
sacrifié pour que je devienne ingénieur. Je dédie ce travail à eux et j’espère être toujours à la
hauteur de leurs attentes.
Je tiens à remercier mes encadrants professionnels Mr. Saber OUESLATI, Mr. Makrem
BENABDALLAH et toute l’équipe "Space-innovation" pour avoir cru en moi et offert cette
opportunité au sein de cette entreprise.
Je remercie ensuite mon encadrant académique, Mme. Hajer CHTIOUI pour ses conseils et
surtout ses encouragements tout au long de six mois. Mme. Hajer était présent lors de chaque
étape et a bien suivi mon avancement de A jusqu’à Z.
Chers membres du jury ; madame Hajer KOUKI : maître assistante à l’École nationale
d’ingénieurs de sousse, monsieur Mossaad BEN AYED : maître assistant à l’École nationale
d’ingénieurs de sousse, mes chers amis, mes chers professeurs, mes enseignants depuis le
cycle primaire jusqu’au cycle d’ingénieurs, mes collègues à Telnet Holding, merci pour votre
support et vos aides.

À vous tous,
Je dédie ce travail.
Ahmed BENLAKHEL

ENISo Page 2
 BREF

Résumé :
Ce travail s’inscrit dans le cadre du projet de fin d’études pour l’obtention du diplôme d’ingénieur
en génie électronique industrielle au sein de l’école nationale d’ingénieurs de Sousse pour
l’année universitaire 2021-2022. Ce projet consistait à étudier et à développer un concentrateur
LoRa afin de l’intégrer dans une solution connectée : Le concentrateur supporte une application
C pour gérer les communications entre les noeuds et le satellite. Cette application est déployée
sur une plate-forme linux à travers une compilation croisée en utilisant un environnement et des
outils (SDK) dédiés à cette opération. La plate-forme linux personnalisée est crée à partir du
Yocto. Enfin, nous avons réussi de gérer la communication du concentrateur avec les différents
objets.
Mots clés : Programmation C, Linux embarqué, Modulation LoRa, Carte concentrateur,
LoRa-Net, Libpredict, Yocto.

Abstract :
This work is part of the end-of-studies project for obtaining the engineering degree in industrial
electronic engineering within the National School of Engineers of Sousse for the academic year
2021-2022. This project consisted in studying and developing a LoRa concentrator in order
to integrate it into a connected solution : The concentrator is supporting the C application to
manage the communications between the nodes and the satellite, this application is deployed on
a linux platform through cross-compilation using an environment and tools (SDK) dedicated to
this operation. The linux platform is created using Yocto.
Finally, we succeeded to manage the communication of the concentrator with the different
objects.
Key-words : C programming, embedded Linux, LoRa modulation, Concentrator Card, LoRa-Net,
Libpredict, Yocto.

ENISo Page 3
 TABLE DES MATIÈRES

LISTE DES FIGURES 8

LISTE DES TABLEAUX 9

INTRODUCTION GÉNÉRALE 10

1 Contexte Général 12
1.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2 Établissement académique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.2 Département électronique industrielle . . . . . . . . . . . . . . . . . . 13
1.3 Organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.1 Historique et organisation générale de l’entreprise . . . . . . . . . . . 13
1.3.2 CHALLENGEONE . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4 Présentation de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.4.1 Contexte du projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.4.2 Problématique traitée et objectifs . . . . . . . . . . . . . . . . . . . . . 16
1.5 Méthodologie de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.5.1 Méthodologie Waterfall . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.5.2 Justification du choix méthodologique : . . . . . . . . . . . . . . . . . 18
1.6 Notions principales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.6.1 Internet des Objets (IoT) . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.6.2 Développement linux embarqué . . . . . . . . . . . . . . . . . . . . . 23
1.7 CONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2 Étude préliminaire 25
2.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2 LoRa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.1 Chaîne émetteur-récepteur . . . . . . . . . . . . . . . . . . . . . . . 25

ENISo Page 4
TABLE DES MATIÈRES

2.2.2 Trame LoRa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.2.3 Paramètres de transmission LoRa . . . . . . . . . . . . . . . . . . . . 29
2.3 Projet Yocto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.2 Caractéristiques du projet Yocto . . . . . . . . . . . . . . . . . . . . . 32
2.3.3 Défis du projet Yocto . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.4 Analyse de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.4.1 Marché . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.4.2 Concurrences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4.3 Critiques de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.5 Analyse des besoins et étude des spécifications . . . . . . . . . . . . . . . . . 36
2.5.1 Spécification fonctionnelle . . . . . . . . . . . . . . . . . . . . . . . . 36
2.5.2 Spécification non fonctionnelle . . . . . . . . . . . . . . . . . . . . . . 37
2.6 CONCLUSION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3 Conception du concentrateur 39
3.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2 Conception préliminaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.1 Architecture globale . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.2 Architecture logique . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3 Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3.1 Conception matérielle . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3.2 Conception logicielle . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4 Réalisation du concentrateur 53
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2.2 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.3 Aperçu sur le travail réalisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3.1 Montage des différents composants . . . . . . . . . . . . . . . . . . . 58
4.3.2 Application C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3.3 Compilation croisée . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3.4 Génération de la distribution linux pour la carte cible . . . . . . . . . . 60
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

ENISo Page 5
TABLE DES MATIÈRES

CONCLUSION GÉNÉRALE 65

BIBLIOGRAPHIE 66

Netographie 67

ENISo Page 6
 LISTE DES FIGURES

1.1 Département électronique industrielle . . . . . . . . . . . . . . . . . . . . . . 13

1.2 Telnet Technocentre situé aux Berges du Lac . . . . . . . . . . . . . . . . . . . 14
1.3 CHALLENGEONE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.4 Méthodologie Waterfall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.5 Consommation, Puissance, Taille et Prix des objets connectés . . . . . . . . . . 20
1.6 Protocoles utilisés dans l’IoT en fonction du débit et de la portée . . . . . . . . 21
1.7 Utilisation du FDMA en LoRa . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.8 Utilisation de l’étalement de spectre en LoRa . . . . . . . . . . . . . . . . . . 23

2.1 Chaîne émetteur-récepteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.2 Un Chirp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3 Occupation spectrale d’une transmission LoRa . . . . . . . . . . . . . . . . . 28
2.4 Symboles transmis en modulation LoRa en SF2 (cas théorique) . . . . . . . . . 28
2.5 Structure de trame LoRa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6 SenseCAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.7 MCF-LW13MIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.8 Solution des concurrents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.9 Solution de Telnet Holding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.1 Architecture globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2 Carte raspberry pi compute module 3+ . . . . . . . . . . . . . . . . . . . . . . 43
3.3 Beaglebone AI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4 Ultra96-V2 personnalisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.5 Orange Pi Zéro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.6 Lorawan tm concentrator card mini pcie lrwcc2-mpcie-868 . . . . . . . . . . . 44
3.7 LoRa GPS HAT Single Channel LoRa GPS module User Manual . . . . . . . 44
3.8 Diagramme de blocs de la conception logicielle . . . . . . . . . . . . . . . . . 46
3.9 Flow chart du concentrateur LoRa . . . . . . . . . . . . . . . . . . . . . . . . 46
3.10 Flow chart du concentrateur LoRa . . . . . . . . . . . . . . . . . . . . . . . . 47

ENISo Page 7
LISTE DES FIGURES

3.11 Flow chart du traitement des données . . . . . . . . . . . . . . . . . . . . . . . 48

3.12 TLE du satellite challenge one . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.13 Flow chart de la prédiction satellitaire . . . . . . . . . . . . . . . . . . . . . . 50
3.14 Compilation croisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.15 Yocto project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.1 La carte raspberry pi compute module 3+ . . . . . . . . . . . . . . . . . . . . 54

4.2 La carte d’extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.3 Lorawan tm concentrator card mini pcie lrwcc2-mpcie-868 . . . . . . . . . . . 55
4.4 FTDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.5 Terminal GNU/Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.6 minicom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.7 Eclipse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.8 Le montage des composants . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.9 Photo réelle du montage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.10 Configuration des paramètres RF . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.11 Compilation croisée de l’application . . . . . . . . . . . . . . . . . . . . . . . 60
4.12 Configuration du fichier local.conf . . . . . . . . . . . . . . . . . . . . . . . . 61
4.13 Configuration du fichier bblayers.conf . . . . . . . . . . . . . . . . . . . . . . 62
4.14 Génération de l’image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.15 Résultats expérimentaux de la réception des paquets LoRa . . . . . . . . . . . 63

ENISo Page 8
LISTE DES TABLEAUX

LISTE DES TABLEAUX

1.1 Bandes de fréquence libres et utilisations . . . . . . . . . . . . . . . . . . . . . 21

3.1 Les spécifications des cartes de développement . . . . . . . . . . . . . . . . . 42

3.2 Les spécifications des modules LoRa . . . . . . . . . . . . . . . . . . . . . . . 45
3.3 Traitement des données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

ENISo Page 9
 INTRODUCTION GÉNÉRALE

La révolution numérique devient chaque jour plus évidente. Tout devient numérique et
connecté à Internet [1,2]. L’Internet of Things (IoT) décrit le réseau de terminaux physiques,
les « objets », qui intègrent des capteurs, des softwares et d’autres technologies en vue de se
connecter à d’autres terminaux et systèmes sur Internet et d’échanger des données avec eux. Ces
terminaux peuvent aussi bien être de simples appareils domestiques que des outils industriels
d’une grande complexité. Avec plus de 7 milliards de terminaux IoT connectés aujourd’hui, les
experts s’attendent à ce que ce nombre passe à 10 milliards d’ici 2020 et 22 milliards d’ici 2025.

L’apparition de l’IoT suit le développement des différents protocoles de communication.

La communication LoRa (long range) est une technologie de modulation RF pour les réseaux
étendus à faible puissance (LPWAN) correspond à la couche physique du modèle OSI. LoRa
permet des communications longue distance avec un faible débit. Une caractéristique clé des
solutions basées sur LoRa est la consommation d’énergie ultra-faible, ce qui permet la création
d’appareils fonctionnant avec des batteries pouvant durer jusqu’à 10 ans.

Les humains ne sont pas aptes à relever le défi de surveiller une grande quantité de données
et ça explique la nécessité de traitement de données et l’importance de l’interaction machine-machine.
Cependant, Ces interactions ont besoin d’être intelligentes et d’avoir un haut niveau d’indépendance.
Cette évolution touche beaucoup de domaines, y compris l’agriculture. le concept correspond à
une nouvelle façon d’organiser les moyens de production. Cette nouvelle industrie s’affirme la
convergence du monde virtuel, de la conception numérique, de la gestion des produits vers les
objets du monde réel.

Ce projet aura pour objectif de développer une application C qui sera déployée sur une
plate-forme Linux personnalisée permettant de recevoir des messages LoRa par un module
concentrateur à partir les nœuds LoRa et d’interpréter les données pour les traiter et les transmettre
vers le satellite au moment du son passage en utilisant le protocole LoRaNet. afin d’exploiter les
données au niveau du cloud en utilisant des algorithmes de machine learning et de deep learning
pour réagir sur l’état de champ agricole selon le besoin des clients.

ENISo Page 10
INTRODUCTION GÉNÉRALE

Le premier chapitre présente une revue générale sur l’organisme d’accueil Telnet Holding
et le cadre général du projet. Il présente aussi la méthodologie du travail proposée et les notions
principales. Le deuxième chapitre est consacré à évoqué les technologies utilisées et présente
une étude de l’existant du concentrateur sur le marché. Nous allons analyser le fonctionnement
de notre système. Le troisième chapitre propose une conception logicielle et matérielle. Nous
allons choisir les matériels à utilisées qui répond aux exigences préétablies et nous allons
faire des organigrammes pour l’application C. Finalement le quatrième chapitre est dédié à
la réalisation de l’application C et de la distribution Linux personnalisée, ainsi que les Tests et
la validation du fonctionnement du concentrateur.

ENISo Page 11
Chapitre

1
Contexte Général

1.1 INTRODUCTION

Avant d’entamer notre projet, nous commençons par présenter l’environnement du Telnet
Holding dans lequel il a été réalisé. Ainsi, les produits et les services que l’entreprise a développé.
Dans ce qui suit, nous décrirons le contexte du sujet et les stratégies que nous avons mené et
enfin nous allons présenter les concepts générales.

1.2 Établissement académique

1.2.1 Présentation

L’école nationale d’ingénieurs de Sousse (ENISo) a été créée en juillet 2005 pour répondre
à un besoin national des ingénieurs, et la formation a été basé sur 3 spécialités d’ingénierie
innovantes ; Mécatronique (Meca), Électronique Industrielle (EI) et Informatique Appliquée
(IA). En 2017-2018, deux nouveaux champs ont été ajoutés ; Génie Télécommunications Embarquées
(GTE) et Mécanique et Productique (MP). Ces spécialités permettent à l’ENISo de se distinguer
parmi les autres écoles nationales d’ingénieurs. Chacune des cinq formations propose des compétences
polyvalentes pour faciliter l’insertion professionnelle de nos ingénieurs. Les différents programmes
d’études proposés visent à former des ingénieurs des étudiants ayant de solides connaissances
de base pour s’adapter en permanence à l’évolution de la technologie.

ENISo Page 12
CONTEXTE GÉNÉRAL

1.2.2 Département électronique industrielle

Le département électronique industrielle offre une formation polyvalente centrée autour de

l’électronique, systèmes électriques et informatique. Il forme des ingénieurs RD, des ingénieurs
d’études, des chefs de projets, des ingénieurs des méthodes et d’industrialisation, ingénieurs
qualité, ingénieurs de production, des ingénieurs conseil, etc. Les secteurs d’activité sont le
contrôle industriel, la conception de systèmes électroniques, l’industrie automatisme, diagnostic,
maintenance, sécurité, intégration d’industriels embarqués, systèmes électroniques, etc...
La formation est dispensée sous forme de cours, de travaux dirigés et travaux pratiques, projets
modules, projet semestriel, projet de fin d’année et projet de fin d’études en dernière semestre.

F IGURE 1.1 – Département électronique industrielle

1.3 Organisme d’accueil

1.3.1 Historique et organisation générale de l’entreprise

Nous avons réalisé ce projet de fin d’études au sein de Telnet Holding. Telnet Holding fut
fondée en 1994 sous la dénomination TELECOM NETWORKS ENGINEERING afin d’offrir
des services de développement software et hardware, des services d’ingénierie produit et de
conseil à ses clients.Les dates clés du groupe Telnet sont :
- 1995 : Premier Contrat signé avec un groupe international : SAT, filiale de SAGEM
- 1998 : Certification ISO 9001 pour le management de la qualité

ENISo Page 13
CONTEXTE GÉNÉRAL

- 2004 : Implantation en France de la filiale ”Telnet Consulting”

- 2013 : Constitution d’une nouvelle filiale nommée ”Telnet Innovation Labs”
- 2021 : Lancement du satellite ”Challenge ONE”

F IGURE 1.2 – Telnet Technocentre situé aux Berges du Lac

Telnet offre des services dans les domaines suivants :

- Télécommunication et multimédia
- Aérospatiale
- Paiement Électronique
- Industrie
Ce projet a été réalisé au sein de l’activité Aérospatiale de Telnet Holding.

1.3.2 CHALLENGEONE

CHALLENGEONE est le projet Ambitieux du Groupe TELNET qui vise à développer une
nouvelle activité Aérospatiale pour devenir un fournisseur de solutions innovantes pour l’IoT.
« ChallengeOne » vise à démontrer les capacités d’un satellite placé en orbite terrestre basse
« LEO » à capturer les données des terminaux LoRa en utilisant la même puissance qu’une
transmission terrestre classique. L’idée serait de fournir ainsi une couverture étendue de ces
terminaux au-delà des limites du réseau terrestre. Le satellite « ChallengeOne » jouera le rôle
d’une passerelle LoRa placée en orbite dans l’espace, et de ce fait sera capable de recevoir les

ENISo Page 14
CONTEXTE GÉNÉRAL

données qui lui sont destinées et émises par les terminaux au sol. Point d’entrée au domaine «
Space for IoT ».

F IGURE 1.3 – CHALLENGEONE

1.4 Présentation de projet

Cette section présente la problématique ainsi que le contexte général et la portée du projet.
Nous verrons tout au long de cette partie les différents facteurs que nous devons prendre en
considération afin de construire le concentrateur IoT.

1.4.1 Contexte du projet

Ce projet a été élaboré dans le cadre de mon stage de fin d’études, étape finale pour l’obtention
du Diplôme National d’ingénieur en Electronique Industrielle de l’Ecole Nationale d’ingénieurs

ENISo Page 15
CONTEXTE GÉNÉRAL

de Sousse en Tunisie (ENISo). Le stage s’est déroulé sur une période de 6 mois à compter du
1er février 2022, durant laquelle j’ai construit un concentrateur IoT.

1.4.2 Problématique traitée et objectifs

• Problématique :
En 2016, L’organisation des Nations Unies pour l’alimentation et l’agriculture lance
un programme de développement durable et parmi de les objectifs du ce programme
est de mettre fin à la faim et à l’insécurité alimentaire parce que le manque au niveau
de la production et du maintenance agricole est devenu plus remarquable dans le
contexte de la population croissante. Cependant, les champs agricoles ne sont pas
assez accessibles au réseau internet pour développer des solutions connectées.
Le satellite Challenge One est un moyen d’offrir cette accessibilité, mais vu que
la bande passante de la transmission au satellite est trés petite. Le traitement des
données au niveau du concentrateur est primordial dans le but de filtrer les messages
LoRa reçus à travers les noeuds et de transmettre seulement les messages utiles.
• Objectifs :
Telnet Holding intervient pour développer un concentrateur IoT, pour l’intégrer
dans une solution intelligente et connectée que nous allons développer. Cette solution
consiste à :
- Prendre des mesures à partir du champ agricole à travers des capteurs.
- Transmettre les données au concentrateur afin de les traiter.
- Exploiter les données du Sol, Météorologie et Environnement au niveau du cloud.
- Réagir sur l’état du champ à travers des systèmes automatiques, afin d’améliorer
la sécurité, la qualité et la quantité de la production.

1.5 Méthodologie de travail

Dans cette section nous présentons la méthode qui organise la démarche de travail ainsi que
les critères du choix méthodologique.

ENISo Page 16
CONTEXTE GÉNÉRAL

1.5.1 Méthodologie Waterfall

C’est la méthode de gestion du projet traditionnelle et la plus linéaire possible. On va

retrouver plusieurs phases dans cette méthode, et chaque phase dépend de la phase précédente,
et nécessite d’être claire et validée. En effet, un changement de conception en plein milieu du
développement pourrait avoir un coût élevé et un impact assez fort [URL6].

F IGURE 1.4 – Méthodologie Waterfall

Nous allons donc retrouver les phases suivantes :

a) Exigences : Phase d’ateliers, réunions, analyse des besoins afin de présenter le projet.
b) Analyse : Phase de spécifications, où nous avons rédigé des documents qui vont détailler.
l’application, fonctionnement et techniquement.
c) Conception : Définition et mise en place de l’architecture matérielle et logicielle.
d) Mise en oeuvre : Implémention de l’application (phase de développement).
Phase de développement : Nous allons développer notre propre distributions Linux personnalisées
pour l’architecture Raspberry Pi module compute 3+, en utilisant The Yocto Project.
Phase d’acquisition des données : Au cours de cette phase, le système acquiert des données
brutes provenant de diverses sources :
Des données sont prises par le réseau de capteurs sans fils ; c’est-à-dire les nœuds LoRa.
Phase de traitement : Cette phase consiste à sélectionner les données nécessaires et non répétitives
pour gagner l’énergie nécessaire pour la transmission.
Phase de transmission : Dans cette phase, nous allons transmettre les données traitées vers le
satellite à travers le protocole LoRaNet, afin de l’exploiter au niveau du cloud.

ENISo Page 17
CONTEXTE GÉNÉRAL

e) Validation : Phase de test de l’application avec éventuellement des correctifs à apporter (on
appelle cela la phase de recette).
f) Mise en service : Mise à disposition de l’outil afin d’effectuer la mise en production pour les
utilisateurs finaux.

1.5.2 Justification du choix méthodologique :

Nous avons choisi l’adoption de la méthode Waterfall pour la réalisation de notre projet
parce qu’elle présente plusieurs avantages dont nous citons principalement :
• La simplicité des processus.
• La clarté de la définition des règles.
• L’augmentation de la productivité.
• L’organisation personnelle.
• L’amélioration de la communication.

1.6 Notions principales

Ce projet englobe des technologies et des notions essentiels qui sont mentionnés et définis
dans les sous-sections suivantes.

1.6.1 Internet des Objets (IoT)

L’internet des objets (Internet Of Things en anglais (IoT)) a été utilisé pour la première
fois par l’ingénieur britannique Kevin Ashton en 1999 pour définir un système où les objets
physiques sont connectés à internet [URL7]. Pour plus de clarté, il s’agit de systèmes capables
de créer et transmettre des données afin de créer de la valeur pour les utilisateurs à travers
divers services (agrégation, analytique, etc.). Ce terme désigne également selon l’UIT (Union
Internationale des Télécommunications) « une infrastructure mondiale pour la société de l’information,
qui permet de disposer de services évolués en inter-connectant des objets (physique ou virtuels)
grâce aux technologies de l’information et de la communication inter-opérables existantes ou

ENISo Page 18
CONTEXTE GÉNÉRAL

en évolution » [URL7]. Le terme IoT est en plein essor ces dernières années et son émergence
est entrain de bouleverser de plus en plus de nombreux secteurs (santé, agriculture, industrie,
automobile, etc.) et il s’articule autour de 5 composants essentiels qui sont, respectivement
[URL7] :
• Les objets (capteurs).
• Le réseau (connectivité).
• Les données.
• Les informations.
• Les applications d’exploitation.
L’Internet des objets promet ainsi une forte plus-value à chaque organisme. En connectant
objets, personnes et environnements, il devient possible de développer des améliorations qui
ne pourront être que bénéfiques. Les principaux bénéfices que peut avoir une entreprise dotée
d’un système IoT sont [URL8] :
• Amélioration de la productivité : l’IoT permet la surveillance, le monitoring et le contrôle des
différents processus, ce qui optimise les différentes opérations qui augmentent la productivité
et l’efficacité.
• Analyses prédictives : grâce à la collecte de nombreuses données, les nouvelles technologies de
l’IoT permettent d’examiner les patrons récurrents et contribuent à l’analyse prédictive qui peut
être principalement utilisée en maintenance. Ces informations précises vont servir à améliorer
les processus et les services existants.
• Rapidité d’action : les données permettent de suivre en temps réel et même à distance les
systèmes mis en place. Elles facilitent l’optimisation des interventions de maintenance, mais
aussi donnent un avantage stratégique à l’entreprise dans le suivi de l’évolution des marchés.
• Diminution des erreurs humaines : grâce à la complémentarité des technologies comme l’intelligence
artificielle, l’IoT permet de minorer les erreurs humaines dues à des tâches mondaines ou
répétitives.

ENISo Page 19
CONTEXTE GÉNÉRAL

D’une façon générale, les systèmes électroniques peuvent être caractérisés par leur consommation,
leur puissance de calcul, leur taille et leur prix [3]. Dans le cas spécifique des systèmes embarqués
utilisés dans l’IoT, nous pouvons affecter le poids suivant à chacune des caractéristiques :

F IGURE 1.5 – Consommation, Puissance, Taille et Prix des objets connectés

Comparés aux autres systèmes électroniques, les systèmes embarqués utilisés dans l’IoT possèdent
donc :
- Une faible consommation
- Une faible puissance de calcul
- Une petite taille
- Un prix faible
La figure 1.6 présente les protocoles existantes dans le monde l’IOT (Internet Of Things) que
nous pouvons classer en fonction de leur bande passante et de leur portée.

ENISo Page 20
CONTEXTE GÉNÉRAL

F IGURE 1.6 – Protocoles utilisés dans l’IoT en fonction du débit et de la portée

Nous nous intéressons aux protocoles longue portée, faible débit et très faible consommation.
L’ensemble de ces réseaux sont dénommés LPWAN : Low Power Wide Area Network. Ce
graphique ne montre pas la consommation pour lesquelles les deux protocoles LoRa et Sigfox
sont sans contestation les plus performants. En Europe, certaines bandes de fréquence sont
libres d’utilisation. Cela signifie qu’ils sont autorisées et gratuites à utiliser, donc le tableau 1.1
montre ces fréquences :

TABLE 1.1 – Bandes de fréquence libres et utilisations

Fréquences Quelques utilisations

13.56 Mhz RFID, NFC

433 MHz Talkie-Walkie, télécommande, LoRa

868 MHz Sigfox, LoRa

2.4 Ghz WiFi, Bluetooth, Zigbee

5 Ghz WiFi

ENISo Page 21
CONTEXTE GÉNÉRAL

Quel que soit le protocole utilisé, le support de transfert de l’information est l’air, car tous les
protocoles de l’IoT sont Wireless. Le support doit être partagé entre tous les utilisateurs de
telle façon que chacun des dispositifs Wireless ne perturbe pas les autres. Pour cela une bande
de fréquence est allouée. Par exemple pour la radio FM la bande de fréquence va de 87,5 Mhz
à 108 Mhz. Dans leur bande de fréquence les dispositifs peuvent se partager le support de
différentes manières :
- FDM (Frequency Division Multiplexing) : Les machines utilisent des canaux fréquentiels pour
séparer leurs transmissions. Le LoRa utilise ce mode de partage, c’est-à-dire que la bande libre
des 868 Mhz est découpée en plusieurs canaux où chaque machine peut dialoguer.

F IGURE 1.7 – Utilisation du FDMA en LoRa

- TDM (Time Division Multiplexing). Dans ce mode de transmission, les machines

transmettent par intermittence afin de laisser libre le canal à tour de rôle. Le LoRa utilise ce
mode de partage. En revanche les machines ne sont pas synchronisés, donc des collisions
peuvent survenir.

- CDMA (Code Division Multiple Access) : Dans ce mode de transmission, les machines
transmettent en même temps, sur le même canal. La conséquence de ce type de transmission est
appelée "étalement du spectre". Le LoRa utile un mode de transmission dont les propriétés sont
assez similaires au CDMA.

ENISo Page 22
CONTEXTE GÉNÉRAL

F IGURE 1.8 – Utilisation de l’étalement de spectre en LoRa

=> Les dispositifs LoRa ont le choix entre plusieurs canaux pour émettre. Sur un canal
choisi, ils peuvent transmettre à plusieurs, en même temps. Le protocole LoRa utilise une
modulation très similaire à la méthode de partage CDMA (pour autant, on ne pourra pas dire
que le LoRa utilise le CDMA). Afin de comprendre la pertinence de ce mode de partage du
support, nous allons valider le fonctionnement du mode CDMA dans le prochain paragraphe.
Au chapitre 3, nous expliquerons dans le détails la modulation LoRa.

1.6.2 Développement linux embarqué

Linux embarqué est l’utilisation de noyau Linux et les pilotes (drivers) des composants qui
sont disponibles (open source) dans les systèmes embarqués. Le développement linux embarqué
offre beaucoup des bénéfices :
- Possibilité de réutiliser les composants de nombreuses fonctionnalités ; protocoles et matériels
sont prise en charge, permet de se concentrer sur la valeur ajouté sur le produit.
- Faible coût : Aucune redevance unitaire, outils de développement gratuit aussi, mais bien sûr
déployer Linux coûte du temps et des efforts.
- Contrôle total : Vous décidez quand mettre à jour les composants dans votre système, pas de
verrouillage du fournisseur, ce qui sécurise votre investissement.

ENISo Page 23
CONTEXTE GÉNÉRAL

- Test facile des nouvelles fonctionnalités : Pas besoin de négocier avec un tiers vendeurs,
explorez simplement de nouvelles solutions, libéré par la communauté.
- Qualité : Votre système est construit sur des bases (noyau, compilateur, bibliothèque C, utilitaires
de base...), de nombreux open Source les applications sont également de bonne qualité.
- Soutien communautaire : Peut obtenir un très bon soutien de la communauté si vous l’abordez
avec un attitude constructive.
- Participation aux travaux communautaires : Possibilité de collaborer avec des pairs et opportunités
au-delà des barrières de l’entreprise.

1.7 CONCLUSION

Au cours de ce chapitre, nous avons présenté le concept global du projet démontrant le

soutien académique et professionnel pour ce stage et nous avons parlé de la problématique et
des solutions du projet ainsi que de ses exigences et de la méthodologie que nous avons adoptée
pour atteindre nos objectifs.

ENISo Page 24
Chapitre

2
Étude préliminaire

2.1 INTRODUCTION

Avant de commencer tout travail, il est primordial de mettre le projet à réaliser dans son
cadre technique en définissant les différentes notions et concepts théoriques et en présentant
les différents outils à utiliser dont la compréhension et la maîtrise sont indispensables pour la
réalisation du projet.

2.2 LoRa

La technologie LoRa est parmi les technologies de LPWAN. Dans les sous-sections suivantes
nous allons montrer les caractéristique de la modulation LoRa.

2.2.1 Chaîne émetteur-récepteur

Les chaînes d’émetteur et du récepteur effectuent également certains traitements supplémentaires.

La chaîne d’émission LoRa effectue le Whitening, le codage de Hamming, Interleaving et le
mappage de Gray avant le chirp (modulation). Le récepteur effectue le démappage de Gray,
la deinterleaving, le décodage de Hamming et le dewhitening [5], comme indique la figure
FIGURE 2.1 :

ENISo Page 25
ÉTUDE PRÉLIMINAIRE

F IGURE 2.1 – Chaîne émetteur-récepteur

Les composants de la chaîne émetteur-récepteur sont décrits dans la suite afin de découvrir
le rôle du chaque élément :
a) Whitening : est un XOR des bits d’information avec une séquence pseudo-aléatoire. La
séquence de Whitening que LoRa utilise cna et a été dérivée de la matrice de Whitening.
b) Codage avec correction d’erreurs : LoRa prend en charge quatre taux de codage correcteur
d’erreurs (ECC). Correction d’erreurs (ECC) CR appartient à (4 / 5 , 4 / 6 , 4 / 7 , 4 / 8). Pour les
trois taux les plus bas, LoRa utilise des codes de Hamming (k, n) avec k = 4 et n appartient à 6,
7, 8, où k est la longueur des données et n la longueur des mots de code. Le code de Hamming
(4, 6) est une version identique du code standard (4, 7), tandis que le code de Hamming (4, 8)
est une version étendue. Pour CR = 4 / 5 , LoRa utilise un code à contrôle de parité pair au lieu
d’un code Hamming.
c) Interleaving : LoRa utilise un interleaver diagonal pour distribuer les erreurs de bit (jusqu’à
SF) résultant d’une erreur de symbole sur plusieurs mots de code ECC. La combinaison d’Interleaving
avec l’ECC conduit à une probabilité plus élevée de mots de code correctement décodés.
d) Mappage de Gray : LoRa utilise un code Gray inverse pour le mappage des bits en symboles.
pour passer des bits aux symboles. Ainsi, une erreur de symbole qui qui confond un symbole
avec l’un de ses symboles adjacents (également appelée erreur de démodulation ±1) n’entraîne

ENISo Page 26
ÉTUDE PRÉLIMINAIRE

qu’une erreur d’un seul bit, qui peut toujours être corrigée par les codes de Hamming avec CR =
4/7 et CR = 4/8 à l’aide de la technologie CRT. Cette propriété est particulièrement utile si CFO
ou STO ne peuvent pas être entièrement récupérés, ce qui conduit généralement à des erreurs
de démodulation.
e) Modulation LoRa (Chirp) : La modulation LoRa utilise l’étalement de spectre pour transmettre
ses informations. Mais au lieu d’utiliser des codes d’étalement (CDMA), elle utilise une méthode
appelée Chirp Spread Spectrum. La finalité est toujours la même : avoir plusieurs transmissions
dans le même canal. La conséquence sur le spectre est aussi la même : cela provoque un
étalement du spectre.
Le signal émis par la modulation LoRa est un symbole dont la forme de base est représentée
ci-dessous. Son nom (Chirp) vient du fait que ce symbole est utilisé dans la technologie Radar
(Chirp : Compressed High Intensity Radar Pulse).

F IGURE 2.2 – Un Chirp

La figure FIGURE 2.3 décrit l’occupation spectrale d’une transmission LoRa. Donc les
paramètres fréquentiels d’une transmission sont :
- La fréquence de départ est la fréquence centrale du canal moins la Bande Passante divisée par
deux et la fréquence de fin est la fréquence centrale du canal plus la Bande Passante divisée par
deux.

ENISo Page 27
ÉTUDE PRÉLIMINAIRE

- Le canal F channel est la fréquence centrale.

- La bande occupée autour de F channel est la bande passante (BW).

F IGURE 2.3 – Occupation spectrale d’une transmission LoRa

Lors de l’émission, les bits sont regroupés en paquets de SF bits. Ensuite, chaque paquet est
représenté par un symbole particulier parmi les 2**SF formes possibles. Entre tous ces
symboles, la seule différence est qu’ils partent tous d’une fréquence particulière, désignant
ainsi le paquet de bits.
- Exemple théorique de modulation SF2 à 868,1 MHz, avec une bande passante de 125 kHz.
Chaque symbole représente 2 bits.

F IGURE 2.4 – Symboles transmis en modulation LoRa en SF2 (cas théorique)

2.2.2 Trame LoRa

Un paquet LoRa est composé par :

- Préambule : la première partie d’un paquet LoRa est le préambule , qui consiste en un nombre
variable N de upchirps. La valeur par défaut pour N est 8, mais toutes les longueurs de préambule

ENISo Page 28
ÉTUDE PRÉLIMINAIRE

plage N appartient à (6, . . . , 65535) sont valides, permettant au récepteur de se synchroniser.

- Identifiants réseau : Après le préambule, le paquet contient deux symboles d’identification
de réseau. les symboles d’identification de réseau sont modulés comme (x, N-x), où x est
l’identifiant du réseau, et qu’ils doivent avoir une distance minimale de trois pour différents
réseaux afin d’éviter problèmes causés par ±1 erreurs de démodulation. Cependant, les identifiants
de réseau observés étaient en fait de la forme (x, x).
- Downchirps : Après les identifiants de réseau, il y a deux Downchirps des symboles de
synchronisation quart de fréquence.
- En-tête (facultatif) : le paquet continue avec un en-tête optionnel, qui contient des informations
sur la longueur du paquet, le taux de code, la présence d’une redondance cyclique contrôle
(CRC) et une somme de contrôle. Si l’en-tête n’est pas présent, les paramètres du récepteur
doivent être configurés manuellement.
- Payload et CRC : Enfin, la dernière partie du paquet est les données et un CRC facultatif de
16 bits. La longueur maximale les données est de 255 octets.

F IGURE 2.5 – Structure de trame LoRa

2.2.3 Paramètres de transmission LoRa

Pour permettre des transmissions simultanées, les nœuds LoRa sont configurés en utilisant
des paramètres distincts : facteur d’étalement (SF), largeur de bande (BW), taux de codage (CR)
et la puissance de transmission (TP) , ce qui permet plusieurs possibilités de configuration (6720
combinaisons possibles)[4]. Les performances du réseau dépendent largement de la configuration
de ces paramètres. Chaque ensemble de paramètres a un effet direct sur le débit (DR), le
temps de transmission (ToA), la sensibilité en réception définie par le rapport signal sur bruit
(SNR) ou par l’indicateur de force du signal reçu (RSSI) (plus le RSSI «Received Signal
Strength Indication » est élevé, plus la sensibilité en réception est bonne) et par conséquent
la consommation d’énergie (E).

ENISo Page 29
ÉTUDE PRÉLIMINAIRE

a) Facteur d’étalement (SF) : Nombre de bits transmis dans un symbole :

LoRa compte 6 SF différents : 7, 8, 9, 10, 11, 12. Les communications radio avec différents SF
sont orthogonaux les unes aux autres, ce qui permet de séparer les transmissions en utilisant
différents SFs. Ce paramètre est pertinent pour la technique d’étalement du spectre. Dans le
spectre étalé, plus la valeur de ce paramètre est élevée plus le récepteur est capable de réduire le
bruit du signal. Ainsi, plus la valeur choisie est élevée, plus la durée de transmission est longue,
mais aussi plus la portée radio est grande puisque la sensibilité du récepteur est meilleure. En
outre, les transmissions simultanées excluant l’orthogonalité entraînent une perte de tous les
paquets (collision), sauf si l’une de ces transmissions utilise une puissance de transmission
(TP) beaucoup plus élevée conformément à la condition SNR (rapport signal sur bruit) (le
signal reçu a au moins 6 dB de plus que les autres signaux). Celui-ci éliminera toutes les autres
transmissions et sera le seul à être reçu. Ce phénomène est appelé effet de capture .
b) Bande passante (BW) :
La valeur de la bande passante (BW) indique la largeur de bande utilisée pour le signal de
transmission.il existe 8 canaux définis dans la bande de 868 MHz de l’Europe avec trois différentes
bandes passantes possibles : 125 KHz, 250 KHz et 500 KHz. Si une transmission rapide est
nécessaire, une valeur de 500 KHz est préférable. Mais si une portée plus longue est nécessaire,
la valeur de 125 KHz doit être configurée. Moins la largeur de bande, plus le temps de transmission
est long, mais aussi meilleure la sensibilité (mesurée par RSSI).
c) Taux de codage (CR) :
LoRa utilise le code correcteur d’erreur FEC pour améliorer la robustesse de la connexion sans
fil. Ce type de codage se traduit par des bits supplémentaires dans la charge utile de la couche
physique de LoRa, qui est contrôlée par le paramètre CR. Le modem LoRa utilise le CR pour
assurer une protection accrue contre les salves d’interférences et les erreurs de décodage. LoRa
permet aux paramètres CR d’être réglé à 4/5 , 4/6 , 4/7 ou 4/8 où les 4 bits utiles sont codés
respectivement par 5, 6, 7 ou 8 bits de transmission. Plus le taux de codage est faible ( 4/8 ),
plus la fiabilité est grande, mais plus la durée de transmission est élevée. Le CR est réglé par
défaut à 4/5.

ENISo Page 30
ÉTUDE PRÉLIMINAIRE

d) Puissance de transmission (TP) :

Comme la plupart des radios sans fil, les émetteurs-récepteurs LoRa permettent également
d’ajuster la puissance de transmission (TP), en changeant radicalement la couverture radio
et l’énergie nécessaire pour transmettre un paquet. En augmentant la TP, par exemple, de -4
à +20 dBm, la consommation d’énergie passe de 66 mW à 396 mW en utilisant l’émetteur-
récepteur RFM95. Ainsi, une TP plus élevée augmente le rapport signal/bruit (SNR) au prix
d’une augmentation de la consommation d’énergie de l’émetteur. Mais l’augmentation de la
portée radio pourrait également entraîne une augmentation des interférences et du taux de
collision.

2.3 Projet Yocto

La plupart des utilisateurs et développeurs GNU/Linux utilisent des distributions classiques

(UBUNTU, Fedora, OpenSuse, etc.), afin de créer un poste de travail qui peut aller de la simple
bureautique au développement (C/C++, Java, Python, etc.) en intégrant des outils comme «
eclipse ». De même, l’espace occupé par une distribution classique est relativement important
(plusieurs Go, voire plusieurs dizaines de Go) à cause des composants installés.
Dans un autre point, depuis plusieurs années, GNU/Linux est utilisé pour des solutions industrielles
(embarqués, IoT, etc.). La principale différence correspond à l’empreinte mémoire utilisée ainsi
qu’à la puissance du matériels (CPU, RAM, Stockge, etc.), c’est pour cela l’utilisation des
distributions classiques (pré-compilées) dans les systèmes embarqués n’est pas recommandée et
que l’on préfère plutôt créer l’image du système à partir des sources de composants en utilisant
un outil dédié dit outil de construction (build system) [9].
Parmi les outils de construction les plus utiles et les plus performants qui peuvent être utilisés
pour créer des images personnalisées à base linux pour les systèmes embarqués, nous citons le
projet Yocto que nous présentons en détails dans les sous-sections qui suivent.

ENISo Page 31
ÉTUDE PRÉLIMINAIRE

2.3.1 Définition

Le projet Yocto est un projet de collaboration open source, sponsorisé par la fondation
Linux (Linux foundation), qui aide les développeurs à créer des systèmes basés sur Linux
personnalisés dédiés aux systèmes embarqués quelle que soit l’architecture matérielle du produit
utilisé [URL10].
Dans le même point, il est plus qu’un système de construction, le projet Yocto fournit un
ensemble d’outils flexibles et un environnement de développement qui permet aux développeurs
des systèmes embarqués à travers le monde de collaborer via des technologies partagées, des
piles de logiciels, des configurations et les meilleures pratiques utilisées pour créer des images
Linux personnalisées [URL10].

2.3.2 Caractéristiques du projet Yocto

Le projet Yocto possède de nombreuses caractéristiques dont nous citons principalement

[URL10] :
• Indépendance de l’architecture : le projet Yocto prend en charge les architectures ARM, MIPS,
PPC et autres. La plupart des fournisseurs de puces créent et fournissent des Board Support
Package (BSP) qui prennent en charge leur matériel.
• Flexibilité : les entreprises utilisent le projet Yocto de différentes manières. Un exemple est de
créer une distribution Linux interne en tant que base de code que la société peut utiliser dans
plusieurs groupes de produits. Grâce à la personnalisation et à la superposition, un groupe de
projets peut tirer parti de la distribution Linux de base pour créer une distribution qui répond
aux besoins de leurs produits.
• Adéquation parfaite aux appareils embarqués et aux contraintes de l’IoT : Contrairement à une
distribution Linux complète, il est possible d’utiliser le projet Yocto pour créer exactement ce
dont on a besoin pour les systèmes embarqués. Pour plus de clarté, le projet Yocto nous permet
d’ajouter uniquement le support de fonctionnalités ou les packages dont nous avons absolument
besoin pour notre système.

ENISo Page 32
ÉTUDE PRÉLIMINAIRE

• Images et transfert de code en toute simplicité : la sortie du projet Yocto peut facilement passer
d’une architecture à l’autre sans passer à de nouveaux environnements de développement.

2.3.3 Défis du projet Yocto

Le projet Yocto présente également quelques défis à surmonter dont nous citons principalement
[10] :
• Travailler dans un environnement cross-build peut sembler inconnu. En effet lors du développement
de code à exécuter sur une cible, la compilation, l’exécution et les tests effectués sur la cible
réelle peuvent être plus rapides que l’exécution d’une génération BitBake sur un hôte de développement,
puis le déploiement de binaires sur la cible pour le test. Bien que le projet Yocto prend en
charge les outils de développement sur la cible, l’étape supplémentaire consistant à réintégrer
les modifications dans l’environnement de génération du projet Yocto est toutefois requise.
• Les temps de construction initiaux peuvent être importants : En effet les longs temps de
construction initiaux sont malheureusement inévitables en raison du grand nombre de packages
initialement construits à partir de zéro pour un système Linux pleinement fonctionnel. Cependant,
une fois cette génération initiale est terminée, le mécanisme de cache à état partagé (sstate)
utilisé par le projet Yocto empêche le système de reconstruire des packages qui n’ont pas été
"touchés" depuis la dernière génération. Le mécanisme « sstate » réduit considérablement les
délais de génération successifs.

2.4 Analyse de l’existant

2.4.1 Marché

L’agriculture est devenue un centre d’intérêt pour les ingénieurs du monde, et nous sommes
intéressés par l’intégration de la technologie dans ce domaine afin d’améliorer la production
agricole et surtout d’assurer la sécurité nécessaire pour les champs. Notre solution consiste à
fournir un bon environnement pour la croissance des plantes à travers les données que nous
aurons reçues et les décisions que notre système aura prises ; c’est-à-dire nous allons assurer

ENISo Page 33
ÉTUDE PRÉLIMINAIRE

l’automatisation de la maintenance agricole, même nous aurons fait des observations et des
analyses sur la croissance des plantes pour prédire les maladies et réagir sur elles.

2.4.2 Concurrences

Ce type des concurrents ont réussi de construire des concentrateurs IoT, basée sur le réseau
LoRaWAN dans le domaine d’agriculture [URL11].
* SEEED Studio :La passerelle SenseCAP LoRaWAN est basée sur le protocole LoRaWAN®,
applicable à la collecte et à la surveillance de données environnementales à faible consommation
et à longue distance dans des scénarios tels que l’agriculture intelligente et la ville intelligente,
etc. En tant que dispositif central du réseau LoRa, la passerelle est utilisée pour collecter des
données à partir de différents nœuds de capteur et transmettre les données au portail SenseCAP
via un câble 4G ou Ethernet.

F IGURE 2.6 – SenseCAP

* mcf88 : MCF-LW13MIO est un appareil qui transmet l’état de ses 16 entrées et contrôle 8
sorties via le réseau LoRaWAN™. Toutes ces entrées et sorties sont isolées galvaniquement. Il
peut être utilisé pour le contrôle de processus industriels, la domotique, le traitement de l’eau,
l’irrigation agricole et des applications similaires.

ENISo Page 34
ÉTUDE PRÉLIMINAIRE

F IGURE 2.7 – MCF-LW13MIO

2.4.3 Critiques de l’existant

D’après l’étude économique que nous avons faite, nous avons constaté que les concentrateurs
IoT existants sont intégrés dans une solution non performante, puisque la plupart des champs
agricoles ne sont pas accessible par la connexion internet (3G, 4G, Ethernet. . .).

F IGURE 2.8 – Solution des concurrents

Pour cela notre concentrateur va transmettre les données vers le satellite au moment de son
passage en utilisant le protocole LoRaNet, comme indique le synoptique du système dans la
Figure 2.9 :

ENISo Page 35
ÉTUDE PRÉLIMINAIRE

F IGURE 2.9 – Solution de Telnet Holding

2.5 Analyse des besoins et étude des spécifications

Cette section à pour objectif de présenter les caractéristiques du concentrateur de point de

vue fonctionnelle et non-fonctionnelle.

2.5.1 Spécification fonctionnelle

Cette sous-section désigne l’ensemble d’informations décrivant en détail le comportement

des fonctionnalités et sous-fonctions de la solution cible, en conformité avec les besoins du
client collectés. Donc les fonctions du concentrateur sont :
- Récolter des messages LoRa qui sont mesurés par les capteurs.
- Traiter les données reçues par le concentrateur.

ENISo Page 36
ÉTUDE PRÉLIMINAIRE

- Transmettre les données liées à chaque état du champ vers le satellite lors d’un passage
du satellite afin d’offrir une accessibilité aux champs qui ne sont pas couverts par le réseau
Ethernet, 3G, 4G . . ., et pour éviter les latences des communications et le surcharge des serveurs.
- Automatiser la maintenance agricole. Nous allons réagir sur l’état du champ agricole, en
utilisant des systèmes automatiques intelligents, selon les mesures collectées.

2.5.2 Spécification non fonctionnelle

Les exigences non fonctionnelles sont celles qui sont importantes voire critiques aux yeux
des utilisateurs et qui assurent le bon fonctionnement du système.
a) Fiabilité : Le système doit fonctionner en continu pendant de nombreuses années sans
erreurs, et dans certains cas, réparer eux-mêmes les erreurs quand elles arrivent. C’est pourquoi
les logiciels sont toujours développés et testés avec plus d’attention et pour cela :
- Le concentrateur est capable de fonctionner correctement dans un milieu où les corps solides
(la poussière . . .) sont fréquents et l’humidité est très importante.
- Le concentrateur fonctionne dans une marge de température très importante.
- Le concentrateur admet une résistance aux UV anti-vieillissement.
- Le concentrateur change la source d’alimentation entre le réseau et la batterie lors l’interruption
de réseau.
- Le système est robuste sous les interférences RF.
- Le poids de l’appareil est léger.
- La consommation énergétique est très faible.
b) Sécurité : Est une approche stratégique pour protéger les logiciels exécutés sur les systèmes
embarqués contre les attaques et donc :
- Le concentrateur supporte une Distribution Linux personnalisée qui est très sécurisée.
c) Méthode d’installation : Le concentrateur peut être câblé et utilisé :
- En montage mural ou sur poteau.
d) Complexité : Le systéme est composé par un bloc logiciel et un bloc matériel :
- Le concentrateur requière un faible encombrement dans une petite surface.

ENISo Page 37
ÉTUDE PRÉLIMINAIRE

- La carte de développement intègre un processeur, une mémoire et des interfaces E/S.

- Le projet supporte un système d’exploitation et une application C.
e) Performance : Le concentrateur doit être très performant pour servir un nombre important
des nœuds, pour cela :
- Le processeur doit être rapide et il doit contenir une grande variété de dispositifs programmables
pour manipuler des applications multi-threading.
- La mémoire a une grande capacité de stockage pour stocker les ressources nécessaires.

2.6 CONCLUSION

Dans ce chapitre, nous avons défini les différents concepts théoriques dont la compréhension
est nécessaire pour la réalisation de notre projet, et nous entamons la partie analyse et spécification
des différents besoins à satisfaire lors de la mise en œuvre de notre solution.

ENISo Page 38
Chapitre

3
Conception du concentrateur

3.1 INTRODUCTION

Après avoir terminé la phase d’analyse et de spécification des besoins, nous abordons la
phase suivante du processus du développement qui est l’étude conceptuelle. Dans ce chapitre,
nous détaillons deux phases importantes qui sont, respectivement, la phase de conception générale
et celle relative à la conception détaillée. Pour chaque phase, nous avons choisi de détailler
seulement les étapes les plus importantes.

3.2 Conception préliminaire

Ce projet aura pour objectif de développer une solution qui sera déployée sur une plateforme
Linux permettant de faire le traitement des messages LoRa récoltés par un concentrateur LoRa
et transmettre ces données vers le satellite au moment de son passage en utilisant le protocole
LoRaNet.

3.2.1 Architecture globale

Dans la figure 3.1, nous illustrons les composants principales du système et montrons l’interaction
entre les différents composants physiques qui le constituent afin d’associer chaque spécification
à son composant. Le concentrateur est composé de trois blocs :
- Le premier bloc correspond aux composants Hardware : La carte de développement + carte de
concentrateur.
- Le deuxième bloc correspond au software de concentrateur : Distribution linux personnalisée

ENISo Page 39
CONCEPTION DU CONCENTRATEUR

qui supporte une application C.

- Le troisième bloc correspond à la fabrication mécanique d’une boîtier sous les normes IP66
qui assure une protection contre les intrusions et les jets directs à haute pression.
=> Nous allons concentrer juste sur les blocs hardware et software.

F IGURE 3.1 – Architecture globale

3.2.2 Architecture logique

Cette sous-section représente la manière et la logique du développement du concentrateur

qui se déroule essentiellement en trois grandes étapes, à savoir :
- La première étape correspond à la conception et développement de l’application C en utilisant
le pilote du concentrateur LoRa.
- La deuxième étape correspond à la cross-compilation du projet avec un outil de compilation
pour l’architecture de la carte raspberry pi compute module 3+ "aarch64" pour la carte cible.
- Quant à la troisième étape, elle correspond à la création et à la génération d’une image linux
personnalisée avec la couche de l’application C sous l’environnement YOCTO pour la cible.

ENISo Page 40
CONCEPTION DU CONCENTRATEUR

3.3 Conception détaillée

Cette section sera consacrée à la conception détaillée de notre système. Nous commençons
ainsi par la présentation de la composition matérielle du concentrateur. Ensuite, nous modélisons
l’aspect logiciel du système via un flowchart de l’application aussi via la description du la
distribution linux personnalisée.

3.3.1 Conception matérielle

Dans cette sous-section nous allons faire une étude comparatif pour chaque composant du
système à travers les spécifications techniques du chaque composant :

a) Choix de carte de développement :

Notre application consiste à faire un concentrateur IoT, donc nous avons besoin d’une carte
qui peut supporter une grande mémoire pour stocker des données environnementales. Mais, le
choix doit étre limité par le cout du produit. À partir du tableau comparatif réalisé TABLE 3.1,
La carte beaglebone AI est efficace pour les modèles des visions par ordinateur, elle admet une
mémoire de stockage amovible eMMC flash. La carte Orange Pi Zero supporte une mémoire
SDRAM très faible. La carte Ultra96-V2 est très couteuse. Dans notre cas, la carte Raspberry
pi compute module 3+ est la plus efficace par rapport à notre application :
- Cout raisonnable
- Vitesse de calcul très important (64 bits à 1.5 GHZ)
- Flexibilité au niveau de la mémoire de stockage (Carte SD)
- SDRAM LPDDR4 de 1 Go

ENISo Page 41
CONCEPTION DU CONCENTRATEUR

TABLE 3.1 – Les spécifications des cartes de développement

ENISo Page 42
CONCEPTION DU CONCENTRATEUR

- Raspberry Pi 3+ :

F IGURE 3.2 – Carte raspberry pi compute module 3+

- Beaglebone AI :

F IGURE 3.3 – Beaglebone AI

- Ultra96-V2 personnalisée :

F IGURE 3.4 – Ultra96-V2 personnalisée

ENISo Page 43
CONCEPTION DU CONCENTRATEUR

- Orange Pi Zéro : :

F IGURE 3.5 – Orange Pi Zéro

b) Choix du module LoRa :

Les cartes concentrateur nous permettent de construire et d’intégrer notre concentrateur IoT
dans la solution générale, ils sont capables de capter les messages LoRa transmis à partir les
noeuds. Les figures 3.6 et 3.7 montrent 2 types du concentrateur :

F IGURE 3.6 – Lorawan tm concentrator card mini pcie lrwcc2-mpcie-868

F IGURE 3.7 – LoRa GPS HAT Single Channel LoRa GPS module User Manual

ENISo Page 44
CONCEPTION DU CONCENTRATEUR

Pour valider le choix du module LoRa, le tableau 3.2 présente une comparaison aux niveaux
des spécifications :

TABLE 3.2 – Les spécifications des modules LoRa

3.3.2 Conception logicielle

Un concetrateur LoRa a la capacité de recevoir et de transmettre des paquets LoRa (données

reçues des nœuds) au satellite, il se compose d’un module concentrateur avec des capacités
multi-canaux connectés par les broches d’entrée/sortie à usage général (GPIO) au Raspberry
Pl. Une fois qu’il capte les paquets de données envoyées par les nœuds désignés qui ont été
verrouillés sur sa gamme de fréquences, par une méthode de "sélection de fréquence”, le concentrateur
traite et transmet les messages traités au satellite. Dans la figure suivante, nous allons présenter
le diagramme de bloc de la partie logicielle du système :

ENISo Page 45
CONCEPTION DU CONCENTRATEUR

F IGURE 3.8 – Diagramme de blocs de la conception logicielle

a) Application C :

Cette application est réalisé afin de contrôler le flux de données RX/TX en se basant sur la
prédiction du passage de satellite lorsqu’il est visible par le concentrateur. Lors de la réception,
le thread du traitement des données va faire des opérations afin de déduire les valeurs nécessaires.
Le thread de la prédiction satellitaire a pour objectif de déterminer le moment du passage pour
envoyer les données filtrées au satellite. Si le satellite n’est pas visible les messages vont être
stockés au niveau de la mémoire locale.

F IGURE 3.9 – Flow chart du concentrateur LoRa

ENISo Page 46
CONCEPTION DU CONCENTRATEUR

Nous avons créé un protocole de communication entre les noeuds et le concentrateur basé
sur la composition de la trame LoRa pour assurer une réception sécurisé à travers l’identifiant
du noeud et le code d’authentification. Le fonctionnement du concentrateur est décrit dans la
figure suivante :

F IGURE 3.10 – Flow chart du concentrateur LoRa

- Le filtrage des données agricoles est nécessaire pour assurer une communication stable
entre le concentrateur et le satellite afin d’extraire les valeurs fondamentales pour faire le calcul

ENISo Page 47
CONCEPTION DU CONCENTRATEUR

de l’evapotranspiration journalière par l’approche de PENMAN-MONTEITH. La flow chart

suivante présente le déroulement des processus de traitement pour obtenir les messages LoRa
utiles à transmettre :

F IGURE 3.11 – Flow chart du traitement des données

ENISo Page 48
CONCEPTION DU CONCENTRATEUR

Pour chaque itération, le buffer de la réception va être subir à des opérations pour déduire
Les valeurs utiles des mesures qui sont indiquées dans le tableau suivant :

TABLE 3.3 – Traitement des données

Grandeurs Valeurs utiles

Rayonnement solaire Valeur cumulée

Vitesse du vent Valeur moyenne

Pluie Valeur cumulée

Humidité d’air Valeur moyenne

Humidité du sol Valeur moyenne

Débit d’eau Valeur instantané

Conductivité Valeur moyenne

Température Min/MAX

- Nous allons utiliser la bibliothèque C "libpredict" qui nous permet de prédire les orbites
des satellites basée sur les TLE (CODAGE EN TWO LINES). Tout satellite est caractérisé par
un code à 2 lignes, permettant après exploitation la localisation du satellite.

F IGURE 3.12 – TLE du satellite challenge one

Ce code très précis est présenté ci-dessous et apparaît sur 3 lignes :

Ligne 1 : 11 caractères maximum pour le nom.
Ligne 2 : 69 caractères pour des renseignements généraux.
Ligne 3 : 69 caractères sur les paramètres orbitaux.
Grâce à ce code, il est possible de visualiser les trajectoires des satellites avec une très grande
précision, compte tenu des perturbations gravitationnelles (dues à J2, J3, J4 , luni-solaire) et du

ENISo Page 49
CONCEPTION DU CONCENTRATEUR

freinage atmosphérique résiduel. La prédiction est basée sur :

+ Création de l’objet orbital : nécessite la ligne 1 et la ligne 2 du TLE.
+ Création de l’objet observateur : dépend des valeurs de la longitude et de la latitude.
La prédiction est décrite à travers la flow chart présentée dans la figure 3.13 :

F IGURE 3.13 – Flow chart de la prédiction satellitaire

b) Compilation croisée du projet :

Cette phase est basée sur des lignes de commande sur un système Linux x86 avec un outil
de compilation pour la carte raspberry pi compute module 3+ "aarch64". La chaîne d’outils
de développement logiciel simple peut consister en un compilateur et un éditeur de liens (qui
transforment le code source en un programme exécutable ), des bibliothèques (qui fournissent
des interfaces avec le système d’exploitation ) et un débogueur (qui est utilisé pour tester
et déboguer les programmes créés). La figure 3.14 va présenter les outils nécessaires afin
de réaliser la compilation croisée qui va générer des bibliothèques et des fichiers binaires
exécutables par la carte cible :

ENISo Page 50
CONCEPTION DU CONCENTRATEUR

F IGURE 3.14 – Compilation croisée

c) Distribution Linux Personnalisée :

Pour générer l’image pour la carte cible, nous avons besoin de créer tout d’abord une
source, c-à-d nous allons préparer l’environnement Yocto Project. Nous allons commencer par
les couches de base nécessaires pour pouvoir travailler avec Yocto.

F IGURE 3.15 – Yocto project

Le premier composant dont nous avons besoin est Poky. Poky est la distribution de référence
de Yocto Project et une collection de calques qui sont préfixés par meta-. Il contient le système
de construction Open-Embedded (BitBake et OE-Core) ainsi qu’un ensemble de métadonnées
pour vous permettre de commencer à construire votre propre distribution. Ce sont les composants
de base en place. Et pour prendre en charge notre appareil cible (Raspberry Pi compute module

ENISo Page 51
CONCEPTION DU CONCENTRATEUR

3+), nous devons cloner le meta-raspberrypi. Le meta-raspberrypi couche a une dépendance

supplémentaire sur le meta-openembedded qui est une collection des couches. Nous allons
copier la couche meta-security puisque elle fournit des outils de sécurité, des outils de durcissement
pour les noyaux Linux et des bibliothèques pour la mise en œuvre de mécanismes de sécurité.
L’environnement crée nécessite une configuration initiale selon nos besoins, donc c’est très
primordial de préparer l’environnement de construction (Build) en utilisant un script fourni par
Poky. Nous allons ajouter quelques couches à notre environnement, et nous allons inclure les
recettes fournies par ces couches à notre environnement de construction :
- meta-python : Cette couche est destinée à être la maison des modules python pour OpenEmbedded.
Elle depend de Openembedded-core/ meta-oe.
- meta-networking : Cette couche est destinée à être un point central pour les paquets et la
configuration liés au réseau. Elle devrait être utile directement au-dessus de oe-core et complimente
meta-openembedded. Elle devrait être principalement utile aux groupes suivants :
+ Toute personne construisant un petit périphérique réseau (par exemple, un routeur /
pont /commutateur domestique).
+ Toute personne souhaitant ajouter des services réseau à son appareil (par ex. tout ce qui
pourrait bénéficier d’un petit serveur ftp/tftp).
- meta-multimedia : cette couche depend de Openembedded-core/ meta-oe.
- meta-perl : Cette couche fournit des recettes courantes liées à perl, telles que les bibliothèques
perl dans le réseau complet d’archives Perl. Elle depend que de openembedded-core.

3.4 Conclusion

A travers ce chapitre, nous avons présenté une vue conceptuelle du notre projet. A ce stade,
nous pouvons passer à la phase de réalisation de la solution proposée qui fera l’objet du chapitre
suivant.

ENISo Page 52
Chapitre

4
Réalisation du concentrateur

4.1 Introduction

Le présent chapitre a pour objectif l’illustration de la phase d’implémentations de la solution

proposée et la démonstration du travail réalisé qui est l’aboutissement des étapes précédentes
débutant de l’étude préliminaire jusqu’à la conception.

4.2 Environnement de travail

Nous présentons dans cette section l’environnement matériel et logiciel qui ont contribué à
la réalisation du notre projet.

4.2.1 Environnement matériel

Le développement du concentrateur est basé sur un environnement matériel très important.

a) Carte Raspberry pi compute module 3+ :

Nous avons utilisé pour la mise en œuvre de la solution une carte Raspberry pi compute
module 3+. Raspberry pi compute module 3+ est, en fait, une carte de développement qui
supporte un SoC Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64 bits à 1,2 GHz et 1 Go
de SDRAM LPDDR2, ainsi qu’un périphérique Flash eMMC. Tout cela est intégré sur une
petite carte (67,6 mm × 31 mm) qui s’insère dans un connecteur SODIMM DDR2 standard.
La mémoire Flash est connectée directement au processeur sur la carte, mais les interfaces
de processeur restantes sont disponibles pour l’utilisateur via les broches du connecteur. Vous
bénéficiez de toute la flexibilité du SoC BCM2837 (ce qui signifie que beaucoup plus de GPIO

ENISo Page 53
RÉALISATION DU CONCENTRATEUR

et d’interfaces sont disponibles qu’avec un Raspberry Pi standard), et la conception du module

dans un système personnalisé devrait être relativement simple.

F IGURE 4.1 – La carte raspberry pi compute module 3+

Pour le développement, la carte d’extension présentée dans la figure suivante est nécessaire
pour accéder aux composants de la raspberry :

F IGURE 4.2 – La carte d’extension

b) Lorawan tm concentrator card mini pcie lrwcc2-mpcie-868 :

Un émetteur-récepteur SX1302 et deux SX1250 sont utilisés pour compléter un concentrateur

LoRa à huit canaux. La puce de bande de base numérique SX1302 est un moteur de traitement
de signal numérique très innovant équipé de 16 modulateurs, capables de démoduler 64 combinaisons
de paquets LoRa, et 2 séparés modulateurs. Le SX1250 est un émetteur-récepteur RF vers IQ
hautement intégré capable de prendre en charge plusieurs modulations systèmes sur les bandes
de fréquences ISM 150-960 MHz. Aussi, Le MCU STM32 sert de traducteur entre le SX1302

ENISo Page 54
RÉALISATION DU CONCENTRATEUR

et le Raspberry Pi lors de l’utilisation du mode USB. Le MCU convertit les données USB qu’il
reçoit du Raspberry Pi en SPI tout en parlant au SX1302 et vice versa.

F IGURE 4.3 – Lorawan tm concentrator card mini pcie lrwcc2-mpcie-868

c) Ordinateur portable :

L’implémentation de la solution a été réalisée sur un ordinateur ayant la configuration

suivante :
• Système d’exploitation : UBUNTU 20.04.
• Mémoire centrale : 16 Go.
• Processeur : Intel Core i7.
• Disque Dur : 1 To.

d) FTDI :

L’utilisation d’un FTDI assure une communication série entre l’ordinateur et la carte raspberry
pi afin de faire la configuration à travers une console.

F IGURE 4.4 – FTDI

ENISo Page 55
RÉALISATION DU CONCENTRATEUR

4.2.2 Environnement logiciel

Cette section est consacrée à la présentation des différentes technologies et logiciels utilisés
pour le développement du concentrateur.

a) Terminal GNU/Linux :

C’est un programme qui émule une console dans une interface graphique comme indique la
figure 4.5, il permet de lancer des commandes. Il est parfois plus simple de taper une commande
que d’effectuer des manipulations demandant beaucoup de clics de souris dans une interface
graphique.

F IGURE 4.5 – Terminal GNU/Linux

b) Minicom :

Minicom est un programme de contrôle de modem et d’émulation de terminal pour les

Unix-like. Il peut être comparé à HyperTerminal dans Windows. Ce programme a été écrit
par Miquel van Smoorenburg d’après le populaire Telix pour MS-DOS. Minicom apporte une
émulation totale ANSI et VT100, un langage de script externe, et d’autres choses encore. Il est
souvent utilisé dans notre projet pour la connexion et l’affichage du terminale de notre image
personnalisé. La figure 4.6 est une capture qui présente l’interface du minicom :

ENISo Page 56
RÉALISATION DU CONCENTRATEUR

F IGURE 4.6 – minicom

b) Eclipse IDE :

Eclipse est une plate-forme du développement libre, où nous avons développé l’application
C.

F IGURE 4.7 – Eclipse

ENISo Page 57
RÉALISATION DU CONCENTRATEUR

4.3 Aperçu sur le travail réalisé

Dans cette section, nous détaillons les différentes parties réalisées tout au long de la mise en
œuvre de notre solution que nous illustrons via des captures d’écran.

4.3.1 Montage des différents composants

Durant la phase de réalisation, développement et de test de notre projet, nous avons utilisé
le montage illustré par la figure 4.8 :

F IGURE 4.8 – Le montage des composants

La figure 4.9 donne une vision réelle et plus claire sur le montage utilisé dans notre projet.

F IGURE 4.9 – Photo réelle du montage

ENISo Page 58
RÉALISATION DU CONCENTRATEUR

4.3.2 Application C

Au niveau de l’application, la configuration des paramètres du transmission et du réception

LoRa est très importantes. La figure 4.10 présente la configuration des paramètres RF :

F IGURE 4.10 – Configuration des paramètres RF

4.3.3 Compilation croisée

La compilation croisée de l’application et du pilote du concentrateur a pour objectif de

construire l’application et de gérer un ficher binaire exécutable, ainsi les bibliothèques nécessaires

ENISo Page 59
RÉALISATION DU CONCENTRATEUR

pour configurer le hardware du concentrateur en utilisant un SDK (Software Development Kit)

spécifique à la carte raspberry pi.

F IGURE 4.11 – Compilation croisée de l’application

4.3.4 Génération de la distribution linux pour la carte cible

L’utilisation d’une distribution classique (précompilée) dans notre système embarqué n’est
pas recommandée à cause de l’empreinte mémoire utilisée ainsi qu’à la puissance du matériels
(CPU, RAM, Stockge, etc.), c’est pour cela on préfère plutôt créer l’image du système à partir
des sources de composants en utilisant le projet Yocto. Pour cela, et avant d’entamer la phase
de développement de l’application, nous présentons dans cette partie, les étapes de génération
de notre image linux personnalisée pour notre carte cible Raspberry Pi sous l’environnement
Yocto qui doit être adapté aux spécificités de notre projet. En effet, la génération de l’image se
fait en plusieurs étapes dont nous citons principalement :
- Produire une image standard avec Yocto.

ENISo Page 60
RÉALISATION DU CONCENTRATEUR

- Configurer l’image produite par Yocto.

Avant d’entamer la phase du configuration de notre image et avant de commencer la phase de
développement de notre application, nous préparons en premier lieu, une image standard pour
émulation sur notre cible. Cette dernière doit être une image bootable sur l’architecture ARM
et en particulier sur notre carte cible.
Après l’étape de génération, nous entamons la phase de configuration de l’image, nous éditerons
en premier lieu notre fichier local.conf pour ajuster les répertoires de stockage temporaires, pour
ajouter des utilisateurs et configurer leurs mots de passe et pour personnaliser le nom d’hôte de
la machine, nous ajouterons ensuite, des utilitaires dont les recettes sont présentes dans Poky,
puis des packages se trouvant dans des layers externes à télécharger.

F IGURE 4.12 – Configuration du fichier local.conf

Nous éditerons, ainsi notre fichier bblayers.conf pour ajouter les répertoires nécessaires de
notre projet dont les quelles le projet Yocto construire notre image. La figure ci-dessous illustre
toutes les configurations faites au cours du construction de notre image linux.

ENISo Page 61
RÉALISATION DU CONCENTRATEUR

F IGURE 4.13 – Configuration du fichier bblayers.conf

Après les configurations, nous générons l’image de la carte Raspberry Pi comme indique la
figure suivante en exécutant bitbake :

F IGURE 4.14 – Génération de l’image

La figure 4.15 présente les résultats expérimentaux de la réception des paquets LoRa envoyés
par les noeuds.

ENISo Page 62
RÉALISATION DU CONCENTRATEUR

F IGURE 4.15 – Résultats expérimentaux de la réception des paquets LoRa

Nous avons réussi de recevoir les trames qui sont envoyées par les noeuds, et nous avons
interprété les données de taille 34 octets. Ainsi, nous avons affiché les caractéristiques de la
chaîne transmission-réception.

ENISo Page 63
RÉALISATION DU CONCENTRATEUR

4.4 Conclusion

Dans ce chapitre, nous avons présenté les étapes de la réalisation de notre projet. En effet,
après avoir présenté l’environnement matériel et logiciel, nous avons validées le bon fonctionnement
de notre application.

ENISo Page 64
 Conclusion et perspectives

L’objectif de ce projet était l’étude et le développement d’un concentrateur IoT pour l’intégrer
dans une solution IoT pour l’agriculture.

Pour réaliser ce projet, nous avons commencé par effectuer une étude approfondie des
différents concepts théoriques liés, respectivement, au agriculture, à la modulation LoRa, au
Linux embarqué, au prédiction satellitaire, au projet Yocto. A partir de cette étude, nous avons
pu conclure les fonctionnalités que nous devons concevoir et implémenter pour satisfaire les
besoins de la société Telnet Holding. Partant de la spécification et l’analyse des besoins à
satisfaire, nous avons pu définir par la suite l’architecture de notre solution, et détaillé sa
conception. Après avoir terminé avec la phase de conception, nous avons passé à l’implantation
de notre système et nous avons réussi à réaliser un montage réel qui nous a permis de tester et
valider le bon fonctionnement des différentes fonctionnalités mises en oeuvre afin d’obtenir des
résultats expérimentaux.

Au lieu d’utiliser la solution IoT standard, le système que nous avons développé offre une
solution plus adéquate qui consiste à collecter toutes les informations nécessaires et à traiter les
données reçues permettant de suivre l’état d’un champ agricole à distance.

En guise de conclusion, nous pouvons dire que nous avons réussi via le travail qui a été
réalisé à répondre aux différents objectifs initialement visés. Toutefois, notre solution peut être
améliorée davantage par l’intégration d’une partie permettant de traiter les données d’une façon
intelligente via l’utilisation des nouvelles techniques de l’intelligence artificielle.

ENISo Page 65
 BIBLIOGRAPHIE

[1] Evans, D. The Internet of Things How the Next Evolution of the Internet Is Changing
Everything. CISCO White Pap. 2011, 1, 1.

[2] Patel, M. ; Shangkuan, J. ; Thomas, C. What’s New with the Internet of Things ?
Disponible en ligne :
https ://www.mckinsey.com/industries/semiconductors/our-insights/
whats-new-with-the-internet-of-things (accessed on 16 August 2019).

[3] Sylvain, M. LoRa - LoRaWAN et l’Internet des Objets. L’université Savoie Mont. Blanc

[4] Norhane, B. Gestion de la qualité de service (QoS) dans un réseau LoRaWAN avec
mobilité. Disponible en ligne :
https ://hal.archives-ouvertes.fr/tel-03283203

[5] Joachim, T. ; Orion, A. ; Paul, M. ; Alexios, B. ; Andreas, B. An Open-Source LoRa

Physical Layer Prototype on GNU Radio. Telecommunication Circuits Laboratory, École
polytechnique fédérale de Lausanne, Switzerland Department of Electrical Engineering,
Eindhoven University of Technology, The Netherlands.

ENISo Page 66
 Netographie

[URL6] https ://www.wimi-teamwork.com/fr/blog/methode-waterfall-guide-introduction-debutants/

consulté le 20/02/2022

[URL7] https ://www.digora.com/fr/blog/definition-iot-et-strategie-iot, consulté le 01/03/2022.

[URL8] https ://www.intesens.com/les-benefices-de-liot/, consulté le 03/03/2022.

[URL9] https ://medium.com/smileinnovation/introduction-à-yocto-db56a550ae51, consulté

le 25/03/2022.

[URL10] https ://www.yoctoproject.org/docs/, consulté le 30/03/2022.

[URL11] https ://www.thethingsnetwork.org/marketplace/products/devices, consulté le 10/02/2022.

ENISo Page 67