IMA4 2018/2019 P70 : Différence entre versions

De Wiki de Projets IMA
m (→‎Semaine 2)
(→‎Feuille d'heures)
 
(362 révisions intermédiaires par 2 utilisateurs non affichées)
Ligne 183 : Ligne 183 :
 
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.
 
- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.
  
−
- Une multitude de PCB qui seront nos objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)
+
- Une multitude de PCB qui seront utilisés comme objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)
 
   
 
   
  
Ligne 208 : Ligne 208 :
  
 
{| class="wikitable"
 
{| class="wikitable"
−
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
+
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Heures S11 !! Heures S12 !! Heures S13+ !! Total
 
|-
 
|-
 
| Analyse du projet  
 
| Analyse du projet  
−
| 0
+
|3
−
| 8
+
|8
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 
|
 
|
 +
|-
 +
| Recherches
 +
|1
 +
|3
 +
|3
 +
|3
 +
|6
 +
|3
 +
|3
 +
|3
 +
|4
 +
|3
 +
|4
 +
|0
 +
|0
 +
|0
 
|
 
|
 +
|-
 +
|Prise en main de GnuRadio
 +
|0
 +
|4
 +
|4
 +
|4
 +
|3
 +
|2
 +
|3
 +
|2
 +
|1
 +
|1
 +
|1
 +
|0
 +
|0
 +
|0
 
|
 
|
 +
|-
 +
|Configuration Xbee
 +
|0
 +
|2
 +
|2
 +
|1
 +
|1
 +
|2
 +
|2
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 
|
 
|
 +
|-
 +
| Préparation expérimentale (écriture de codes et scripts...)
 +
|0
 +
|0
 +
|2
 +
|3
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 
|
 
|
 +
|-
 +
|Expériences
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 +
|1
 +
|3
 +
|3
 +
|5
 +
|0
 +
|0
 +
|0
 
|
 
|
 +
|-
 +
| Etude et interprétation des résultats
 +
|3
 +
|8
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 
|
 
|
 +
|-
 +
|Total
 +
|4
 +
|15
 +
|9
 +
|8
 +
|7
 +
|8
 +
|8
 +
|0
 +
|0
 +
|0
 +
|0
 +
|0
 
|
 
|
 
|
 
|
 
|
 
|
 
|}
 
|}
 +
 +
 +
A partir de la semaine 10/11, nous n'avions plus trop de notions du temps passé sur notre projet. Nous préférons être honnête et ne rien mettre plutôt que de mettre de fausses heures !
  
 
==Prologue==
 
==Prologue==
Ligne 233 : Ligne 358 :
  
  
−
'''Choix des émetteurs/récepteurs''' :
+
=== Choix des émetteurs/récepteurs ===
  
−
Nous avons décidé que nos objets connectés communiquerons dans deux '''bandes de fréquences ISM''', l'une à '''900 MHz''' grâce à des modules Digi Xbee et l'autre à '''2,4 GHz''' par le moyen de modules émetteurs Bluetooth. On rappellera que les Digi Xbee et les émetteurs/récepteurs Bluetooth seront pilotés par des ATMEGA 2560.
+
Nous avons décidé que nos objets connectés communiqueront dans deux '''bandes de fréquences ISM''', l'une à '''900 MHz''' grâce à des modules Digi Xbee et l'autre à '''2,4 GHz''' par le moyen de modules émetteurs Bluetooth. On rappellera que les Digi Xbee et les émetteurs/récepteurs Bluetooth seront pilotés par des ATMEGA 2560.
  
 
Les Xbee ne communiqueront pas entre eux et émettront en continu les mêmes données car ils le peuvent, alors que les émetteurs/récepteurs Bluetooth devront s'échanger des données si on veut pouvoir observer un quelconque signal autour de la fréquence de leurs porteuses.  
 
Les Xbee ne communiqueront pas entre eux et émettront en continu les mêmes données car ils le peuvent, alors que les émetteurs/récepteurs Bluetooth devront s'échanger des données si on veut pouvoir observer un quelconque signal autour de la fréquence de leurs porteuses.  
  
 
On voudra observer premièrement, si avec deux objets dans les '''mêmes''' conditions (donc même µc et même émetteur), on peut ou non '''distinguer une différence'''. Ceci est fondamental pour la suite des expériences, puisque si les deux émettent à la même fréquence, on pourra faire varier plusieurs paramètres afin de trouver '''des clés''' (des signes) qui pourraient aider à l'identification du matériel.
 
On voudra observer premièrement, si avec deux objets dans les '''mêmes''' conditions (donc même µc et même émetteur), on peut ou non '''distinguer une différence'''. Ceci est fondamental pour la suite des expériences, puisque si les deux émettent à la même fréquence, on pourra faire varier plusieurs paramètres afin de trouver '''des clés''' (des signes) qui pourraient aider à l'identification du matériel.
 +
 +
Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).
  
 
''On planifie alors pour la semaine suivante de réussir à faire émettre, en utilisant simplement des breadboards pour commencer, nos Xbee et modules BT et observer quelque chose grâce à notre SDR.''
 
''On planifie alors pour la semaine suivante de réussir à faire émettre, en utilisant simplement des breadboards pour commencer, nos Xbee et modules BT et observer quelque chose grâce à notre SDR.''
  
 
==Semaine 2==
 
==Semaine 2==
 +
 +
 +
=== Configuration des modules XBee ===
  
 
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux :  
 
Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux :  
Ligne 253 : Ligne 383 :
 
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div>
 
<div style="padding:15px;color:#ffffff;background-color:#23241F;font-family:Consolas">minicom -b 9600 -D /dev/ttyUSB0</div>
 
<br/>
 
<br/>
−
On active l'echo local dans minicom, histoire de pouvoir voir ce que l'on envoi par liaison série au XBee ('''CTRL+A''' puis '''E''').
+
On active l'echo local dans minicom, afin de pouvoir observer ce qui a été envoyé par liaison série au XBee ('''CTRL+A''' puis '''E''').
  
 
Pour commencer le paramètrage il faut taper ''' +++ ''' rapidement. Le XBee nous répond OK, cela veut dire que nous sommes dans le mode configuration et que nous pouvons utiliser les commandes '''AT'''. (Redirection vers la liste des commandes AT XBee [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).
 
Pour commencer le paramètrage il faut taper ''' +++ ''' rapidement. Le XBee nous répond OK, cela veut dire que nous sommes dans le mode configuration et que nous pouvons utiliser les commandes '''AT'''. (Redirection vers la liste des commandes AT XBee [https://cdn.sparkfun.com/assets/resources/2/9/22AT_Commands.pdf]).
Ligne 301 : Ligne 431 :
 
Puis on fait de même avec le deuxième XBee (ID 5001).
 
Puis on fait de même avec le deuxième XBee (ID 5001).
  
−
Voilà, lorsque on envoi des caractères par liaison série, la LED '''Tx''' de 5000 s'allume et la Led '''Rx''' de 5001 s'allume elle aussi. Cela signifie que l'envoi de donnée par onde radio s'effectue correctement.
+
Voilà, lorsque on envoie des caractères par liaison série sur 5000, la LED '''Tx''' de 5000 s'allume et la Led '''Rx''' de 5001 s'allume elle aussi. Cela signifie que l'envoi de donnée par onde radio s'effectue correctement.
  
  
 
Maintenant que les XBee émettent et reçoivent, on peut commencer les mesures avec notre SDR. Mais avant cela il va falloir bien se familiariser avec le logiciel GNU RADIO qui est assez difficile à prendre en main.
 
Maintenant que les XBee émettent et reçoivent, on peut commencer les mesures avec notre SDR. Mais avant cela il va falloir bien se familiariser avec le logiciel GNU RADIO qui est assez difficile à prendre en main.
 +
 +
=== Première prise en main du logiciel GNURADIO ===
 +
 +
Installation de GNU radio avec les fonctions + drivers pour HackRF :
 +
 +
sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf
 +
 +
 +
 +
Le bloc Osmocom Source sert de "passerelle" entre le logiciel et la SDR, il permet de transmettre les informations récupérées par le HackRF afin qu'on puisse les traiter avec d'autres bloc de fonctions.
 +
 +
Si on veut pouvoir récuperer les données il faut passer l'argument ''hackrf=0'' dans la box périphérique du bloc Osmocom.
 +
 +
Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.
 +
 +
 +
[[Fichier:ScreenGnuRadio.png|Interface de GNURadio]]
 +
 +
==Semaine 3==
 +
 +
===Premières observations===
 +
 +
Cette semaine nous a permis d'effectuer notre première expérience. L'utilisation des deux Xbees nous a permis d'observer l'impact des Xbee sur le champ électromagéntique environnant.
 +
 +
Si on analyse le spectre environnant grâce au module FFT de GNU Radio, lorsque les Xbee communiquent entre eux, on peut apercevoir un pic caractéristique propre.
 +
En effet, lors de l'emission d'un message sur le port série, on a un pic qui se dégage du spectre d'amplitude -20dBm. Ce pic est caractéristique au canal de communication choisi et configuré sur le Xbee.
 +
Néanmoins, le signal est perturbé par le bruit environnant.
 +
L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude.
 +
Il faut noter que la norme IEEE 802.11 impose au Wi-Fi l'utilisation d'une bande passante s'étalant de 2.4 GHz à 2.5 GHz.
 +
 +
La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.
 +
 +
Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.
 +
 +
<!-- [[Fichier:Channel135001.png|thumb|400 px]] -->
 +
<!-- [[Fichier:channel135000.png|thumb|none|400 px]] -->
 +
<div><ul>
 +
<li style="display: inline-block;"> [[Fichier:XBeeCh13.png|Spectre de l'environnement autour du XBee|thumb|none|400 px]] </li>
 +
<li style="display: inline-block;"> [[Fichier:XBeeCh13SND.png|Lors de l'envoi de données au XBee voisin|thumb|none|400 px]] </li>
 +
</ul></div>
 +
 +
 +
On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz.
 +
Il nous est maintenant nécessaire d'analyser de plus près les signaux et leurs fréquence centrale dans la bande perçue au dessus de -20dB.
 +
 +
On réeffectuera une expérience en zone isolée des signaux parasites.
 +
 +
==Semaine 4==
 +
 +
Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.
 +
 +
En somme, nous étions confrontés à de nombreuses interrogations. Le fonctionnement du Xbee étant assez simple et la sécurité du protocole Zigbee étant moindre, y a t-il possibilité de démoduler le signal émis afin de développer nos études ?
 +
 +
==Semaine 5==
 +
<div>
 +
[[Fichier:Switchchannel pyscript.PNG|upright=0.8|thumb|right|Script Python]]
 +
 +
Après réflexion et consultation de nos encadrants, nous nous sommes rendu compte que la démodulation prévue lors de la semaine 4 n'aiderait pas à répondre à la problématique de notre sujet ! 
 +
 +
Afin de mieux visualiser les signaux des Xbee , on décide d'automatiser le processus d'envoi sur le port série des données vers le Xbee. C'est à dire concevoir un programme Python qui automatisera l'envoi de données et le changement de channel à intervalle de temps régulier (Changement toutes les 10 secondes).
 +
 +
L'utilisation de Minicom '''n'était pas du tout la meilleure solution''' pour faire émettre les Xbee.
 +
 +
 +
Après quelques essais, on remarque que lorsque le Xbee émet sur le channel 13, il émet à environ 2,445GHz au lieu d'émettre à 2,415GHz soit une différence de 30MHz : Ceci n'est pas important, car ce que l'on souhaite remarquer c'est un éventuel décalage de la fréquence centrale entre deux Xbee différents. Si les deux Xbee n'ont pas la même frequence centrale on pourra conclure que la '''fréquence centrale''' de la porteuse du Xbee n'est pas '''une des clés''' permettant d''''identifier''' cet émetteur/récepteur.
 +
 +
 +
 +
 +
 +
 +
 +
 +
</div>
 +
 +
==Semaines 6 et 7==
 +
 +
Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.
 +
 +
Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.
 +
 +
[[Fichier:PlancheXPtest.jpg|thumb|right|Planche prototype]]
 +
 +
Tout d'abord, nous avons paramétré la fréquence centrale de capture du HackRF. En effet, bien que le HackRF dispose d'une large bande passante, afin de se focaliser sur la porteuse, il est indispensable de configurer le HackRF en conséquence.
 +
En second lieu, pour éviter une variation du RSSI (Received Signal Strength Indication) et de la puissance du signal, nous devions mettre en place une prototype de "planche expérimentale" sur laquelle devaient être fixés nos différents modules (l'antenne de reception et les Xbees).
 +
 +
La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.
 +
 +
Chaque Xbee est identifié par un chiffre (1 ou 2). En effet, l'attribution de ces chiffres sera définitive pour ne pas perturber la cohérence des expériences.
 +
Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.
 +
 +
 +
===Expérience : Le XBee 1 émetteur directement connecté en série au PC===
 +
 +
 +
[[Fichier:GrapheGNURadio01.png|thumb|left|150px|Schéma simple d'étude fréquentielle et temporelle]]
 +
 +
 +
Cette expérience est la première mettant en place un contexte (un seul Xbee émetteur connecté en série au PC, le deuxième Xbee étant inactif) et nous permettra d'étudier le plus de cas possibles.
 +
 +
Nous avons tout d'abord commencé par un graphe GNURadio simple permettant l'observation du spectre et du signal et la variation de la fréquence d'étude.
 +
 +
Le script python a été réécrit afin que le XBee puisse émettre une chaîne de caractère "HELLO" * 1024. En effet, même si la fréquence de balayage du module HackRF peut être grandement augmentée, il faut éviter d'aller au dessous de 0.01s, finissant par consommer de manière considérable les ressources octroyées par le CPU le cas échéant.
 +
Le fait d'augmenter la taille de la chaine de caractère permet de mieux synchroniser l'étude en temps réel avec la capture des données.
 +
 +
Nous avons donc émis les données sur le canal 20 (14 en hexadécimal), soit la fréquence centrale est à 2.450GHz selon la norme Zigbee.
 +
 +
 +
<B><U>Etude fréquentielle</U></B>
 +
 +
L'étude fréquentielle est similaire à celle réalisée auparavant.
 +
 +
 +
<div center><ul>
 +
<li style="display: inline-block;">[[Fichier:Spectrefreq2.png|thumb|center|750px|Spectre fréquentiel au canal 14]]</li>
 +
<li style="display: inline-block;">[[Fichier:Spectrogram.png|thumb|center|250px|Spectrogramme]]</li>
 +
</ul></div>
 +
 +
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz.
 +
 +
D'autre part, l'ensemble des fréquences qui dessinent le spectre s'étalent sur une large bande de fréquence. En effet, cette technique d'étalement appelée DSSS (Direct-Sequence Spread Spectrum) utilisé par les modules XBee permet au signal d'être moins sensible aux interférences et aux brouillages. En outre, même si la puissance du spectre dans sa globalité reste la même, la densité spectrale elle diminue considérablement, rendant le signal plus "discret".
 +
La différence de puissance entre le lobe principal et les premiers lobes secondaires sont de 30 dB, ce qui est aussi commun au DSSS.
 +
 +
Le spectrogramme témoigne aussi de l'étalement du signal sur un peu plus de 6 MHz (3MHz de par et d'autre de la fréquence centrale).
 +
 +
 +
<B><U> Etude temporelle </U></B>
 +
 +
[[Fichier:Signal temporel.png|thumb|left|500px|Signal observable centré à 2.450GHz lors de l'émission]]
 +
 +
Le signal ici est séparé en deux composantes car il s'agit d'un signal complexe. Nous avons supposé en premier temps qu'il s'agissait du signal principal décalé de 180°, ce qui n'était pas le cas.
 +
Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante.
 +
Le signal observable témoigne d'une modulation bien spécifique au XBee. En effet, on peut observer des sauts de phase à différents points, qui correspondent à une modulation par changement de phase (modulation QPSK ou Quadratic Phase-Shift Keying). Ce sont ces sauts de phases qui permettent la transmission des bits.
 +
Les changements de phase s'il y a se font toutes les µs. En outre, on peut observer un décalage (offset) entre la composante Q et la composante I de µs/2 (propre à la modulation OQPSK).
 +
 +
Nous avons décidé d'enregistrer ces données brutes dans un fichier et nous l'avons étudié avec Audacity, logiciel open-source de son, et donc de signaux ! L'inconvénient avec l'interface graphique QT de GNURadio est son manque de précision lors d'un dézoom sur le signal en temps réel. Audacity permet de palier à celà !
 +
En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.
 +
 +
Le paquet XBee est constitué d'un premier header (header physique) de 6 octets :
 +
- la séquence de préambule (4 octets) constitué de 32 bits à 0
 +
 +
- l'indice de début du paquet fixé à 0x7A (1 octet)
 +
 +
- la longueur du paquet (1 octet);
 +
 +
d'un header MAC (7 à 27 octets en fonction des informations de l'adresse), d'un bloc FCS de fin de paquet (2 octets) et l'ensemble des données (de 1 à 104 octets).
 +
 +
 +
[[Fichier:Signal2.png|thumb|right|400px|On observe graphiquement qu'un paquet est transmis en 3846µs]]
 +
[[Fichier:PacketXBee.png|400px|thumb|right|Paquet XBee]]
 +
 +
 +
Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS.
 +
Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en <B><I>chips</I></B>.
 +
Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips).
 +
Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).
 +
 +
Les signaux reçus par l'antenne HackRF étaient deux sinusoïdes modulées en phase et qui s'étalaient sur une période d'environ 3840µs (3846µs graphiquement mais il y a possibilité d'erreur à l'echelle du µs).
 +
Sachant qu'un octet correspond à 64µs, on a :
 +
 +
 +
<center><math>N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets</math></center>
 +
 +
 +
L'analogie peut être effectuée entre paquet Ethernet et paquet ZigBee. En effet, la taille limite des données d'un paquet est de 104 octets. La chaîne de caractère n'étant qu'envoyée par paquet, le paquet observé n'est que de 120 octets, ce qui est cohérent avec les caractéristiques du XBee.
 +
 +
 +
 +
<div><ul>
 +
<li style="display: inline-block;"> [[Fichier:Hello1024secs.png|thumb|none|Temps de transmission de la chaîne de caractères "HELLO" 1024 fois]] </li>
 +
<li style="display: inline-block;"> [[Fichier:AudacitySignal2.png|thumb|none|51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois]] </li>
 +
</ul></div>
 +
 +
==Semaine 8==
 +
 +
L'étude des signaux posait réellement problème de par le fait qu'une grande partie de la capture faite n'était que purement le bruit sans signal (utile plus tard pour l'étude du SNR).
 +
Prenons l'exemple d'un paquet de 21 octets (un paquet contenant une seule chaîne de caractères HELLO). Le signal s'étalerait en théorie sur 21*64 chips soit 672 chips. Sachant que la modulation est une modulation QPSK, on s'étale sur un temps de 672µs.
 +
En effet, le Xbee transmet toutes les 100ms.
 +
Donc qu'une partie du signal nous est utile.
 +
 +
Nous avons donc décider d'écrire un script qui nous permettrait d'étudier le signal dans de meilleures conditions, et donc de le filtrer.
 +
 +
Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction <B><I>File Sink</I></B> du compagnon GNURadio. Néanmoins, les fichiers obtenus sont des fichiers binaires assez lourds (environ 500Mo pour une capture de 3s), ce qui est un réel problème et qui implique le filtrage du signal.
 +
 +
La bibliothèque numpy pour python nous permet en outre directement d'importer les échantillons des signaux, les traduisant du binaire à un format cible (complexe flottant 64 bits) dans un Array par le biais de la fonction:
 +
 +
<code> f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64) </code>
 +
 +
La première solution pour réduire ce signal était d'imposer un threshold directement sur le signal, supérieur au bruit, mais qui conduirait à une perte d'une partie du signal à étudier.
 +
La deuxième solution qui a été retenue était tout simplement de calculer l'amplitude et la phase du signal et appliquer ce même threshold à l'amplitude.
 +
 +
== Semaine 9 et 10==
 +
 +
A partir de la semaine 10 nous avons procéder aux expériences pour avoir suffisamment de données et en tirer des conclusions.
 +
 +
Lorsqu'on fait une acquisition d'un signal xbee , on peut maintenant via un script traiter cette acquisition et récupérer seulement les parties qui nous intéressent : A savoir la partie réelle et la partie imaginaire, l'amplitude du signal et enfin la phase du signal.
 +
 +
Exemple ci dessous après acquisition + traitement de notre xbee n°2 :
 +
 +
<div><ul>
 +
<li style="display: inline-block;"> [[Fichier:Traitement xbee2.png|thumb|right|redresse=2|Signal Xbee2 post-traitement ]] </li>
 +
<li style="display: inline-block;"> [[Fichier:Constellation xbee2.png|thumb|right|redresse=2|Diagramme de constellation xbee2 après utilisation de LightSignal]] </li>
 +
</ul></div>
 +
 +
 +
L'utilisation du script LightSignal permet de retirer toutes les phases en dehors du signal. Ainsi, on peut caractériser le diagramme de constellation comme un diagramme propre à la modulation QPSK.
 +
 +
<nowiki>
 +
#include <iostream>
 +
import scipy
 +
import numpy
 +
import sys
 +
 +
def binToComplex64(name):
 +
    threshold=0.10
 +
    tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)
 +
    tmp2=scipy.fromfile(open(name), dtype=scipy.complex64)
 +
   
 +
    f2 = open(name+"_filtre", "w+")
 +
    f = open(name+"_PhaseMeg_filtre","w+")
 +
   
 +
    p=1
 +
    size=tmp.__len__()
 +
    size2=tmp2.__len__()
 +
   
 +
    if size > size2:
 +
        size=size2
 +
 +
   
 +
    ground=False
 +
    newListSignal=[]
 +
    newListMagnPh=[]
 +
    for val in range(0,size):
 +
        if(val>=(size/100)*p):
 +
            print(str(p)+" %")
 +
            p=p+1
 +
        if(tmp[val].real>threshold):
 +
            if(ground==True):
 +
                for i in range(0,1000):
 +
                    newListSignal.append(numpy.complex64(0))
 +
                    newListMagnPh.append(numpy.complex64(0))
 +
                ground=False
 +
            newListSignal.append(tmp2[val])
 +
            newListMagnPh.append(numpy.complex64(tmp[val].real+tmp[val].imag*0.3j))
 +
        else:
 +
            ground=True
 +
   
 +
    tmp=numpy.asarray(newListMagnPh)
 +
    tmp.tofile(f)
 +
    tmp2=numpy.asarray(newListSignal)
 +
    tmp2.tofile(f2)
 +
 +
 +
def main():
 +
    try:
 +
        binToComplex64(sys.argv[1])
 +
    except IndexError:
 +
        print("Donnez le nom du fichier\n")
 +
    except IOError:
 +
        print("Le fichier n'existe pas\n")
 +
 +
 +
 +
if __name__=='__main__':
 +
    main()
 +
 +
</nowiki>
 +
 +
 +
Le diagramme de constellation témoigne de nouveau du type de modulation utilisé par le module XBee.
 +
En effet, on observe quatre points de part et d'autre des axes de quadrature et d'inphase.
 +
 +
==Semaine 11==
 +
 +
Nous avons décidé cette semaine d'étudier, ce qui est selon pour nous, l'une des pistes fondamentales de notre projet, et plus particulièrement de l'étude de nos signaux : le rapport signal bruit.
 +
 +
L'objectif de cette semaine et de celle à venir était, à partir du signal acquis par le hackrf, d'effectuer le calcul du SNR (signal-to-noise ratio) tel que :
 +
<center><math>SNR =\frac{P_{signal}}{P_{bruit}}</math></center>
 +
 +
Le script python qui nous a permis de communiquer entre les deux shields Xbee se verra amélioré afin de faire plusieurs acquisition des signaux lors de la communication entre les Xbee, effectuer une moyenne statistique, et de même lorsqu'il n'y a pas de communication.
 +
 +
Nous avons essayé d'approcher le SNR directement depuis l'interface de GnuRadio par le biais de l'utilitaire graphique et le langage en bloc, néanmoins nous procéderons à l'étude de ce rapport avec Scilab ou Matlab.
 +
 +
 +
==Semaines supplémentaires==
 +
 +
 +
===Expérience : Variation de l'amplitude===
 +
 +
<B><U>Contexte</U></B> :
 +
 +
<I> Le XBee1 emet une chaîne de caractères HELLO*256 </I>
 +
 +
L'objectif de cette expérience est d'étudier le temps de variation de l'amplitude du signal entre l'état où le signal n'est pas reçu et l'état où le signal est réceptionné et donc l'amplitude constante.
 +
 +
<B><U>Résultats </U></B> :
 +
 +
A 20MHz de fréquence d'echantillonage, le temps de variation moyen est de 3 échantillons, soit 0.15µs, pour toutes les captures faîtes.
 +
 +
<B><U>Conclusion sur l'expérience </U></B> :
 +
 +
L'expérience n'a pas été concluante. Même si elle nous a permis de voir quelques différences (probablement provoquées pas des erreurs de capture et d'analyse), le HackRF nous limite beaucoup sur ce point de vue là. En effet, la fréquence d'échantillonage étant limitée à 20MHz, le HackRF n'est pas suffisamment précis pour capturer un nombre d'échantillons nous permettant de confirmer une quelconque hypothèse.
 +
 +
 +
<B><U>Code python utilisé pour l'étude du signal</U></B> :
 +
 +
<nowiki>
 +
def etudeAmplitude(name, liste_temps):
 +
 +
    threshold_0=0.05 # Threshold
 +
    threshold_1=0.4
 +
    max_transition_time=50 #O
 +
 +
    amppha=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)
 +
 +
    p=1
 +
    size=amppha.__len__()
 +
   
 +
    debut=1
 +
    tps_variation=0
 +
 +
 +
    transition=False # Vérifie si le signal est en transition ou stable
 +
 +
    for val in range(debut,size):
 +
        if(val>=((size-debut)/100)*p):
 +
            print(str(p)+" %")
 +
            p=p+1
 +
 +
        if(amppha[val].real>threshold_0 and amppha[val].real<threshold_1): # Phase de transition du signal
 +
            if(transition==False):
 +
                transition=True
 +
            tps_variation=tps_variation+1
 +
 +
        elif(transition==True and amppha[val].real>threshold_1):
 +
            if(amppha[val].real>=amppha[val-1].real-amppha[val-1].real*0.05 and amppha[val].real<=amppha[val-1].real+amppha[val-1].real*0.05): # L'amplitude du signal est stable
 +
                if(tps_variation < max_transition_time):
 +
                    liste_temps.append(tps_variation)
 +
 +
                transition=False
 +
                tps_variation=0
 +
            else:
 +
                tps_variation=tps_variation+1
 +
        else:
 +
            transition=False
 +
            tps_variation=0
 +
</nowiki>
 +
 +
===Expérience : Temps de calcul du FCS entre le XBee1 et et le XBee2===
 +
 +
<B><U>Contexte 1</U></B> :
 +
 +
<I> Le XBee1 et XBee2 sont alimentés sur 5V VCC par USB (connecté à l'ordinateur)</I>
 +
 +
<I> Le XBee1 et XBee2 disposent du firmware : 10EF </I>
 +
 +
<I> Le XBee1 est d'abord emetteur et le XBee2 est recepteur puis inversement. Aucun paquet ACK n'est renvoyé de la part du recepteur </I>
 +
 +
On transmet la chaine de caractère HELLO 256 fois toutes les 1 secs
 +
Les données étant assez conséquentes, le Xbee transmet plusieurs fragments du paquet.
 +
L'objectif de cette expérience est d'étudier le temps entre chaque fragment d'un paquet.
 +
L’espace de temps entre chacun des paquets permet de calculer le FCS (frame check sequence) afin de minimiser les erreurs de transmission.
 +
 +
 +
<div><ul>
 +
<li style="display: inline-block;"> [[Fichier:ChecksumGraphe.png|thumb|left|redresse=2|Les différents temps à mesurer]]  </li>
 +
</ul></div>
 +
 +
 +
Néanmoins, l’étude de ces “temps morts” se voit entravée par le fait que le module HackRF ne permette pas d’obtenir un signal clair sur plus de 5 secondes.
 +
En outre, pour 5 secondes d’étude et pour une fréquence d’échantillonage de 20MHz (soit un temps Te=5.10e8), on compte 100.000.000 d’échantillons.
 +
Le CPU lors de la capture était grandement sollicité, ce qui explique le fait que la capture soit compromise.
 +
Pour régler ce problème, on a écrit un script shell de capture.
 +
Ce script consiste à:
 +
<br>- effectuer une capture d’une durée de 1 sec
 +
<br>- d’enregistrer la capture
 +
<br>- d’effectuer un traitement de ces paquets par un algorithme python en étudiant le temps entre chacun des fragments. Ce temps sera obtenu en nombre d’échantillons, défini avec un seuil d’acceptation absolu entre 150.000 et 300.000 échantillons (pour bien capturer ces temps intermédiaires et pas les temps provoqués par des signaux parasites ou du bruit), et pour affiner l’étude, on impose un seuil d’erreur de +-10% autour de la moyenne. La moyenne est calculée en continue
 +
<br>- l’ensemble des valeurs obtenues sont enregistrées dans un fichier
 +
<br>- on réeffectue la capture …
 +
 +
On répète le processus un certains nombre de fois afin d’obtenir un nombre de valeurs nous permettant de nous conforter sur l'issue de l'expérience (environ 1000 valeurs)
 +
 +
La capture et l'étude de chacun des modules dure une à deux heures.
 +
 +
<B><U>Résultats :</U></B>
 +
 +
Dans le cas du XBee1 (à gauche) et du XBee2 (à droite), voici les résultats obtenus :
 +
 +
<div><ul>
 +
<li style="display: inline-block;"> [[Fichier:Xbee1Graphe256.png|thumb|left|redresse=2|On peut observer des pics caractéristiques à l'envoi]] </li>
 +
<li style="display: inline-block;"> [[Fichier:XBee2Graphe256.png|thumb|left|redresse=2|Les mêmes pics caractéristiques confirment un comportement non-aléatoires du module]] </li>
 +
</ul></div>
 +
 +
 +
XBee1 :
 +
 +
<U>Moyenne</U> : 259675,81
 +
 +
<U>Ecart-type</U> : 8369.7417
 +
 +
<U>Variance</U> : 70052576.
 +
 +
 +
XBee2:
 +
 +
<U>Moyenne</U> : 258762.58
 +
 +
<U>Ecart-type</U> : 9165.4097
 +
 +
<U>Variance</U> : 84004736.
 +
 +
 +
Les graphes présentent le nombre de répétitions des temps de calcul de fragements.
 +
 +
On peut voir des pics spécifiques à certains points dans les deux expériences. Ces pics sont caractéristiques et au module XBee, et à la chaîne de caractère HELLO. Les deux expériences étant effectuées dans le même contexte,
 +
 +
De même que pour le second Xbee, on retrouve des pics bien distincts à certains points.
 +
 +
En outre, on peut voir que ces pics bien distincts se rapprochent de ceux du premier Xbee.
 +
Néanmoins, même si la moyenne varie que très peu par rapport aux deux Xbee, la variance est assez différente.
 +
 +
Pour confirmer ces observations, il est peut être nécessaire de répéter la même expérimentation sur un nombre d'échantillons plus grand.
 +
 +
Ainsi, afin de confirmer la conjecture, on décide de faire d’autres captures.
 +
 +
 +
En superposant les deux graphes (Xbee1 en rouge et Xbee2 en bleu), on peut voir qu'il y a moins de dispersion dans le cas du XBee1, plus centré sur des valeurs précises, contrairement au Xbee2.
 +
 +
 +
[[Fichier:XBee1Xbee2Graphe.png|thumb|left|redresse=2]]
 +
 +
 +
 +
 +
 +
 +
 +
Pour les deux nouveaux échantillons, on a les caractéristiques suivantes :
 +
 +
<U>Xbee1 sur 1688 échantillons</U>
 +
 +
<U>Moyenne</U> : 260230.3
 +
 +
<U>Ecart-type</U> : 8427.3923
 +
 +
<U>Variance</U> : 71020941
 +
 +
 +
<U>Xbee2 sur 1722 échantillons</U>
 +
 +
<U>Moyenne</U> : 259899.41
 +
 +
<U>Ecart-type</U> : 9831.5106
 +
 +
<U>Variance</U> : 96658601
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
[[Fichier:SignalAT328.png|thumb|right|Signal observé dans le cas de l'ATMega328p]]
 +
 +
 +
<B><U>Contexte 2</U></B> :
 +
 +
<I> Le XBee1 est connecté à un Arduino ATMega328p par le biais d'un shield Libelium </I>
 +
 +
<I> Le XBee1 dispose du firmware 10EF </I>
 +
 +
<I> On envoie exactement les mêmes données que précédemment, la chaîne de caractères HELLO*256 toutes les 0.5s </I>
 +
 +
Hormis l'amplitude du signal qui paraît plus faible lors de la transmission par ATMega328p, le message transmis ne change PAS. Même si nous avons fait en sorte que la periode de transmission soit la même que pour l'expérience précédente, elle n'affecte en rien l'issue de l'expérience car c'est le temps de division de paquet.
 +
 +
 +
 +
<B><U>Résultats</U></B> :
 +
 +
<div><ul>
 +
<li style="display: inline-block;"> [[Fichier:ATMega328.png|thumb|650px|Observation du temps de division d'un paquet dans le cas de l'ATMega328p]] </li>
 +
<li style="display: inline-block;"> [[Fichier:ATMega2560.png|thumb|650px|Observation du temps de division d'un paquet dans le cas de l'ATMega2560]] </li>
 +
</ul></div>
 +
 +
Pour les nouveaux échantillons, on a les caractéristiques suivantes :
 +
 +
<U>Xbee1 sur ATMega328p sur 706 échantillons</U>
 +
 +
<U>Moyenne</U> : 265818.58
 +
 +
<U>Ecart-type</U> : 4748.5965
 +
 +
<U>Variance</U> : 22549168
 +
 +
 +
<U>Xbee1 sur ATMega2560 sur 711 échantillons</U>
 +
 +
<U>Moyenne</U> : 262877.83
 +
 +
<U>Ecart-type</U> : 3675.037
 +
 +
<U>Variance</U> : 13505897
 +
 +
 +
On peut observer une distinction significative entre une transmission effectuée directement par la machine et la transmission depuis les modules composés d'un ATMega328p ou d'un ATMega2560. En effet, on n'observe pas les mêmes pics caractéristiques dans cette expérience comparé à l'expérience précédente. Même si la moyenne est quasi la même, l'ecart type est plus faible, ainsi que la variance. En outre, de même que pour l'expérience précédente, l'écart-type entre ATMega328p et ATMega2560 est aussi différent.
 +
 +
 +
 +
<B><U>Contexte 3</U></B> :
 +
 +
<I> Le XBee1 est dans les mêmes conditions que durant la première expérience </I>
 +
 +
<I> On change le firmware du XBee1 pour le 10ED </I>
 +
 +
 +
<B><U>Résultats</U></B> :
 +
 +
 +
[[Fichier:FW10ED.png|thumb|left|400px|Observation du temps de division d'un paquet lors du changement du firmware]]
 +
 +
 +
<U>Xbee1 sur 821 échantillons</U>
 +
 +
<U>Moyenne</U> : 259735.52
 +
 +
<U>Ecart-type</U> : 8501.3996
 +
 +
<U>Variance</U> : 72273796
 +
 +
 +
Après avoir changé le firmware, on a pu voir que les résultats ne changeaient pas par rapport à l'expérience témoin. On est même très proche des temps du XBee bien que l'expérience ne s'est pas faîte dans les mêmes conditions (pas au même endroit, donc possibilité de perturbations).
 +
On peut donc en conclure que le firmware n'a pas un impact sur le temps de calcul du FCS.
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
<B><U>Conclusion de l'expérience</U></B> :
 +
L’hypothèse qui est que la variance des temps "morts" entre chaque fragments de paquet, soit le temps de calcul du FCS pour le signal émis peut être considéré comme “clé” de distinction d’un module Xbee n'est donc pas à négliger.
 +
Le temps de calcul du FCS semble unique entre chaque paquet paraît une empreinte propre au matériel.
 +
 +
On peut même considérer que cette étude peut distinguer un module Xbee d'un autre électromagnétiquement parlant.
 +
 +
 +
 +
<B><U>Code python utilisé pour l'étude du signal</U></B>:
 +
<nowiki>
 +
 +
 +
def etudeSubdivPaquet(name, inter_time_values):
 +
 +
threshold = 0.30
 +
ground = false
 +
p=1
 +
 +
## On converti chacun des nombres binaires en complexe 64 (deux flottants 32 bits)##
 +
amppha=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)
 +
 +
 +
## On récupère la taille du tableau de complexes (taille du signal) ##
 +
size=amppha.__len__()
 +
 +
    debut=0
 +
    inter_time=0
 +
    min_limit=150000
 +
    max_limit=350000
 +
    accept_range=1./10. ## Permet de mettre un seuil d'intervalle d'acceptation
 +
    signalFnd=False
 +
 +
    for val in range(debut,size):
 +
        if(val>=((size-debut)/100)*p):
 +
            print(str(p)+" %")
 +
            p=p+1
 +
 +
        if(amppha[val].real>threshold):
 +
            if(ground==True):
 +
                if(signalFnd==True):
 +
                    if(len(inter_time_values)>0):
 +
                        moy=moyenne(inter_time_values)
 +
                        if(inter_time >= moy-accept_range*moy and inter_time <= moy+accept_range*moy):
 +
                            print("Yes "+str(inter_time))
 +
                            inter_time_values.append(inter_time)
 +
                        inter_time=0
 +
                    elif(inter_time>=min_limit and inter_time<=max_limit):
 +
                        inter_time_values.append(inter_time)
 +
                else:
 +
                    signalFnd=True
 +
                ground=False
 +
        else:
 +
            ground=True
 +
            if(signalFnd==True):
 +
                inter_time=inter_time+1
 +
 +
    if(len(inter_time_values)>0):
 +
        print("Moyenne "+ str(moyenne(inter_time_values)))
 +
</nowiki>
 +
 +
=== Rencontre avec Etienne Helluy Lafont ===
 +
 +
Bien que plusieurs pistes ont pu être explorées, notre manque d'expertise dans le domaine de la radio logicielle nous a fait défaut sur nos recherches. En effet, après avoir calculé le SNR d'un de nos signaux, nous nous sommes retrouvés avec des résultats assez incohérents. De nombreuses erreurs peuvent se glisser et nous avions besoin de conseils à ce sujet.
 +
 +
Etienne Helluy-Lafont est un doctorant qui fait sa thèse sur les sondes pour la détection d’intrusions dans les architectures réseau hétérogènes et massivement distribuées. Il développe un outil permettant d'analyser le spectre environnant, de donner des informations sur les signaux émis sur certains canaux et même de démoduler ces signaux. Son programme en C est flexible puisqu'il est adapté pour beaucoup d'antennes (Une des librairies qu'il utilise est SoapySDR [https://github.com/pothosware/SoapySDR/] qui possède des "codec" dont un pour notre HackRF !). Nous nous sommes servi de son outil afin d'avoir de bien meilleurs résultats quant aux expériences orientées SNR des Xbee.
 +
 +
 +
[[Fichier:SDRProgC.gif|center|Le programme sniffe l'environnement et renvoie les caractéristiques lors de la reception d'un signal]]
 +
 +
L'avantage de l'utilisation de l'application nous permet directement de nous focaliser sur les paquets correctement reçus et non les données parasites qui peuvent perturber l'antenne. En effet, le programme reste à l'écoute de l'environnement électromagnétique sur une bande de fréquence autour de la fréquence d'écoute du HackRF. Lors de la reception d'un signal, le programme démodule le signal et vérifie si le CRC (ou le FCS pour le Frame Check Sequence) et les données concordent. Si c'est le cas, le CRC nous renvoie 1. Il s'agit là alors d'un signal. L'utilisation ainsi de ce programme nous permet de ne pas obtenir de valeurs parasites pour le SNR et filtrer directement les informations qui nous sont intéressantes.
 +
 +
L'algorithme que nous avions écrit en Python est correct, néanmoins l'étude sur un signal enregistré requiert le chargement de l'intégralité du signal. Là où nos recherches se basent sur de la capture et du traitement post-capture, le travail d'Etienne se base sur un traitement du signal en temps-réel, ce qui nous permet ainsi de gagner un temps considérable.
 +
 +
 +
 +
 +
 +
 +
===Expérience : Variation du Rapport Signal Bruit en fonction de la distance de reception ===
 +
 +
<div><ul>
 +
<li style="display: inline-block;"> [[Fichier:FFTSNR.png|thumb|left|redresse=2|Calcul du SNR par FFT]] </li>
 +
<li style="display: inline-block;"> [[Fichier:Fenetre.png|thumb|left|redresse=2|Calcul du SNR par fenêtre glissante]] </li>
 +
</ul></div>
 +
 +
L'objectif de cette expérience était de visualiser comment le rapport signal bruit (ou SNR) varie en fonction de la distance.
 +
En effet, nous avions mis en suspens l'expérience qui consistait en la capture du SNR dû aux valeurs instables que l'on avait.
 +
 +
La première idée était de faire une FFT du signal et de calculer le rapport en prenant la moyenne de sa puissance sur une bande de 2.4MHz (1.2Mhz de part et d'autre de la fréquence de capture du HackRF).
 +
 +
Néanmoins, les caractéristiques du XBee (du point de vue de l'étalement spectral) rend le calcul du SNR imprécis. A la suite de la capture de signaux et de l'étude de ces mêmes signaux, les valeurs nous paraissaient incohérentes.
 +
 +
[[Fichier:SNRcalc.png|thumb|left|470px|Pics de SNR]]
 +
 +
 +
Nous avons donc procédé à une seconde méthode de calcul qui consiste à utiliser une fenêtre glissante de taille 2^k échantillons.
 +
Pour chaque échantillon du signal, on calculait le SNR tel que :
 +
 +
<center><math>SNR =\frac{P_{signal+bruit}}{P_{bruit}}=\frac{|A_{signal+bruit}|^2}{|A_{bruit}|^2}</math></center>
 +
 +
Dans notre cas, on a :
 +
 +
<center><math>SNR_x =20.log \frac{Moyenne(W_x[2^{k-1}:2^k])}{Moyenne(W_x[0:2^{k-1}-1])}</math></center>
 +
 +
W_x étant la fenêtre à l'échantillon x du signal, le rapport signal bruit est obtenu lorsqu'on a un pic.
 +
La fenêtre choisie doit être suffisamment grande pour avoir une précision optimale.
 +
On impose ainsi un threshold pour éviter des erreurs pouvant influencer les résultats de manière considérable.
 +
Ainsi, on obtient les valeurs SNR cherchées.
 +
 +
 +
Nous voulons donc vérifier si la mesure du SNR est une expérience pertinente pour l'identification du matériel. Nous allons prendre plusieurs XBee et mesurer le SNR à différentes distances de l'antenne SDR.
 +
 +
 +
 +
 +
 +
<B><U>Contexte 1</U></B> :
 +
 +
<I> Le XBee1 et XBee2 sont alimentés sur 3.3V VCC par USB (connecté à l'ordinateur)</I>
 +
 +
<I> Le XBee1 et XBee2  sont des modèles série s1</I> disposent du firmware : 10EF
 +
 +
<I> Le XBee3 et XBee4 sont des modèles XBeePro </I>
 +
 +
<I> Par défaut tous nos xbee disposent du même firmware (10EF), sauf si précisé que non </I>
 +
 +
<I> Nous cherchons à observer la différence entre le XBee1 et XBee2 dans la même situation. </I>
 +
 +
<I> Durant les expériences, le montage XBee1 connecté en USB sera le XBee témoin. </I>
 +
 +
 +
 +
 +
<B><U>Résultats</U></B> :
 +
 +
[[Fichier:PointsMoyenneXBee1Dist.png|thumb|left|470px|Les différentes valeurs du SNR acquises en fonction de la distance pour le XBee1]]
 +
 +
Dans notre cas, le modèle XBee1 connecté en série à notre machine nous a servi de composant témoin afin d'étudier les signaux des autres modèles. En effet, suite à la capture et l'étude des signaux, on peut voir que le nuage de points qui constitue notre graphe témoigne d'un phénomène électromagnétique ondulatoire quant au champ. Avec la distance, plus l'on éloigne le module, plus le rapport signal sur bruit diminue (le contraire nous aurait étonné). En outre, la variation ondulatoire peut être caractérisée par le champs éléctrique.
 +
 +
Nous avons décidé de refaire cette expérience avec les trois autres XBee directement connectés à notre machine.
 +
 +
[[Fichier:ALLXBEE comparaison SNR distance.png|thumb|right]]
 +
 +
De part les potentielles erreurs et les différentes perturbations électromagnétiques ambiantes, la valeur du SNR peut être affectée. Il n'est pas possible directement par les caractéristiques du rapport signal bruit d'effectuer le distinguo entre le XBee1 et le XBee2 (contrairement à l'expérience basée sur la subdivision de paquets). Cependant, les XBee3 et XBee4 présentent une caractéristique commune. Le SNR est beaucoup plus élevé.
 +
 +
En effet, le pic de courant d'un XBee est de 45mA à la transmission pour une alimentation de 3.3V en tension continu, tandis qu'un module XBee pro, le pic de courant atteint les 150mA. Cette différence électronique permet ainsi au XBee pro de communiquer sur une plus grande zone (750m contre 90m pour un XBee simple).
 +
 +
Ainsi, on peut conclure de cette expérience que le SNR est un élément témoin de la consommation énergétique d'un composant électrique (du moins de l'antenne).
 +
 +
 +
 +
 +
 +
[[Fichier:XBEE1 hardware comparaison SNR distance.png|thumb|400px|right]]
 +
 +
 +
 +
 +
<B><U>Contexte 2</U></B> :
 +
 +
<I> Le XBee1 est d'abord connecté à un Arduino UNO 328P par le biais d'un shield XBee Libelium puis est connecté à un Arduino Mega 2560 par le biais du même shield </I>
 +
 +
<I> Le XBee1 dispose du firmware : 10EF </I>
 +
 +
 +
<B><U>Résultats</U></B> :
 +
 +
On peut observer que même si l'unité de contrôle n'est pas l'ordinateur mais le micro-contrôleur (ici ATMega2560 et ATMega328P), le rapport signal bruit ne change pas réellement. Néanmoins, il était pour nous intéressant de noter qu'un léger gap se créé à 30 et 40 cm de la SDR entre la communication USB et la communication avec les micro-contrôleurs.
 +
 +
 +
[[Fichier:XBEE3 hardware comparaison SNR distance.png|thumb|400px|right]]
 +
 +
<B><U>Contexte 3</U></B> :
 +
 +
<I> L'expérience est similaire que pour le module XBee1 mais avec le XBee3 (pro) </I>
 +
 +
<I> Le XBee3 est d'abord connecté à un Arduino UNO 328P par le biais d'un shield XBee Libelium puis est connecté à un Arduino Mega 2560 par le biais du même shield </I>
 +
 +
<I> Le XBee3 dispose du firmware : 10EF </I>
 +
 +
 +
<B><U>Résultats</U></B> :
 +
 +
En outre, les résultats obtenus lors de l'expérience avec le XBee3 nous indique que le phénomène ondulatoire observé durant les tests précédents est moins souligné dans la communication avec les micro-contrôleur (toujours à 30 et 40cm) et celà après plusieurs tests.
 +
 +
Des tests plus précis auraient été plusieurs avantageux et nous auraient permis de trancher sur la décision de l'importance du SNR concernant la différenciation de différentes unités de contrôle.
 +
 +
 +
 +
[[Fichier:XBEE1 firmware comparaison SNR distance.png|thumb|400px|right]]
 +
 +
 +
<B><U>Contexte 4</U></B> :
 +
 +
<I> Le XBee1 ici est connecté en série et dispose dans un premier temps du firmware 10EF (le firmware le plus récent) </I>
 +
 +
<I> Après capture et expérimentation, on décide de réeffectuer la même chose avec le même XBee (XBee1) avec le firmware 10ED </I>
 +
 +
 +
 +
<B><U>Résultats</U></B> :
 +
 +
Les acquisitions étant faites dans les mêmes conditions, il semblerait que le changement de firmware ait un petit impact sur la puissance d’émission : Cette petite différence de décibel ne semble pas aléatoire puisqu’on peut clairement voir que la courbe orange reste toujours inférieure à la courbe bleue, or le niveau de bruit est resté inchangé.
 +
 +
 +
 +
 +
 +
 +
 +
 +
<B><U>Conclusion de l'expérience</U></B> :
 +
 +
'''Hardware''' : Les paquets émis via liaison série ont plus de puissance que ceux émis grâce aux arduino UNO et MEGA notamment à 10 cm, 40 cm et 50 cm. On remarque aussi une baisse du SNR moyen à 30 cm surtout en liaison série et ce, avec nos quatres XBEE. Coté ATMEGA , le SNR reste plutôt stable et décroit très doucement. Ainsi lors d’un calcul de SNR/Distance on pourra estimer si le XBEE est connecté au PC en liaison série ou à une ATMEGA quelconque selon si son SNR suit l’allure ou non de la courbe de la transmission classique.
 +
 +
''En cherchant des raisons à cela, on se demande si ce phénomène n’a pas un rapport avec la longueur d’onde du signal modulé : la longueur d’onde est de 12 cm à 2.455 GHz, et la distance 30 cm coïnciderait avec sa demi-longueur d’onde.''
 +
 +
Par le biais de ces mesures, on a pu démontrer que le matériel a un impact sur le SNR en fonction de la distance. A ce stade nous ne pouvons toujours pas déceler si le XBEE est géré par un microcontrôleur ATMEGA328P ou un ATMEGA2560.. Peut-être que l'étude du SNR selon le canal d'émission nous apportera des réponses?
 +
 +
'''Software''' : Il n'y a pas de différence notable à en sortir de l'expérience quant à la partie logicielle. Nous ne pouvons pas nous avancer sur l'influence du firmware sur la puissance du signal uniquement par cette expérience.
 +
 +
===Expérience : Variation du Rapport Signal Bruit en fonction du canal de fréquence===
 +
 +
 +
 +
L'expérience s'effectue de la même manière que précédemment. L'algorithme utilisé est le même. Néanmoins, nous verrons comme le SNR varie ici non pas en fonction de la distance mais en fonction du canal choisi. Pour celà, on choisira 3 canaux : le canal 0x11 (17), le canal 0x13 (19) et le canal 0x15 (21).
 +
En effet, ces canaux n'ont pas été choisis aléatoirement. Lors de nos études, on a observé le XBee Pro ne transmettait pas sur certains canaux particuliers.
 +
 +
Etait-ce dû à une erreur de manipulation ?
 +
 +
Afin d'être sûr, on a pris des canaux qui était communs aux deux modèles (série S1 et Pro).
 +
 +
 +
[[Fichier:ALLXBEE comparaison SNR freq.png|thumb|400px|left]]
 +
 +
<B><U>Contexte 1</U></B>:
 +
 +
<I>Les XBee1, XBee2, XBee3 et XBee4 sont connectés au PC et sont à 10 cm de l'antenne SDR. </I>
 +
 +
<I>Ils disposent du même firmware : 10ef </I>
 +
 +
<I>Les XBee transmettent d'abord sur le canal 0x11, sur le canal 0x13 et sur le canal 0x15 </I>
 +
 +
 +
 +
 +
<B><U>Résultats </U></B>:
 +
 +
Il n'y a pas réellement de conclusion à tirer dans ce contexte. On ne fait que confirmer la différence de SNR entre le XBee de série S1 et le XBee Pro, différence qu'on observait déjà lors de l'expérience précédente.
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
[[Fichier:XBEE1 hardware comparaison SNR freq.png|thumb|400px|left]]
 +
 +
<B><U>Contexte 2</U></B>:
 +
 +
<I>Les XBee1 est d'abord connecté au PC comme précédemment par shield. On le connecte par la suite à l'ATMega328p puis à l'ATMega2560. Il se trouve à 10 cm de l'antenne SDR. </I>
 +
 +
<I>Ils disposent du même firmware : 10ef </I>
 +
 +
<I>Les XBee transmettent d'abord sur le canal 0x11, sur le canal 0x13 et sur le canal 0x15 </I>
 +
 +
 +
 +
 +
<B><U>Résultats </U></B>:
 +
 +
On observe que le rapport Signal Bruit lors de la transmission sur PC est supérieur au SNR transmis par l'ATMega328p et l'ATMega2560.
 +
On observe en plus une légère différence entre celui de l'ATMega328p et l'ATMega2560. La puissance des microprocesseurs se reflèterait-elle sur le signal ?
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
[[Fichier:XBEE3 hardware comparaison SNR freq.png|thumb|400px|left]]
 +
[[Fichier:XBEE4 SNR freq.png|thumb|400px|left]]
 +
 +
 +
 +
 +
<B><U>Contexte 3</U></B>:
 +
 +
<I>Les XBee3 est d'abord connecté au PC comme précédemment par shield. On le connecte par la suite à l'ATMega328p puis à l'ATMega2560.</I>
 +
 +
<I>On réeffectue la même expérience avec le XBee4 </I>
 +
 +
<I>Ils disposent du même firmware : 10ef </I>
 +
 +
<I>Les XBee transmettent d'abord sur le canal 0x11, sur le canal 0x13 et sur le canal 0x15 </I>
 +
 +
 +
 +
 +
 +
<B><U>Résultats </U></B>:
 +
 +
On observe la même chose que pour le contexte précédent, il y a une différence entre le SNR du XBee3 témoin et de celui relié aux micro-contrôleurs. L'erreur n'est pas à négliger, car la distance peut grandement influencer sur l'amplitude du signal. On considère une marge d'erreur de +-0,2cm lors de cette expérience, celà même si les résultats ne s'opposent à ceux du contexte précédent.
 +
Pour le XBee3 et XBee4, les phénomènes sont semblables.
 +
Celà nous conforte dans l'identité d'une identité électromagnétique pour un matériel.
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
 +
<B><U>Conclusion de l'expérience </U></B>:
 +
 +
Après avoir comparé tous les graphes, on peut dire que systématiquement la puissance émise selon les canaux est la même pour chaque hardware :
 +
SNR_série > SNR_ATMEGA2560 > SNR_ATMEGA328
 +
Cependant, les courbes ne suivent pas un pattern caractéristique qui permettrait à l’aide à l’identification du matériel. Si par exemple deux XBEE émettent avec un hardware différent, on pourra seulement conclure « Les XBEE n’utilisent pas le même matériel pour émettre ». Dans un contexte particulier, on pourrait distinguer le nombre de modules sans néanmoins les identifier.
 +
 +
 +
 +
<B><U>Code python utilisé pour l'étude du signal</U></B>:
 +
<nowiki>
 +
 +
def SNRStudy(name):
 +
    tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)
 +
 +
    f = open(name+"_SNR_Values","a")
 +
 +
    p=1
 +
    size = tmp.__len__()
 +
    magnitude = (numpy.real(tmp)).tolist()
 +
 +
    threshold=10
 +
 +
    P=0
 +
    SNR_graph=[]
 +
    SNR=[]
 +
 +
    win_sz=64
 +
 +
    if(size>=win_sz):
 +
        for val in range(0,size-win_sz):
 +
 +
            if(val>=((size-win_sz)/100)*p): # Affiche l'état de l'étude
 +
                print(str(p)+" %")
 +
                p=p+1
 +
 +
            SNR_graph.append( 20*math.log((numpy.mean(magnitude[val + win_sz/2 : val + win_sz-1]))/(numpy.mean(magnitude[val+0 : val+win_sz/2-1])), 10) )
 +
 +
 
 +
 +
    size=len(SNR_graph)
 +
 +
    for i in range(1, size-1):
 +
        if (SNR_graph[i]>SNR_graph[i-1] and SNR_graph[i]>SNR_graph[i+1] and SNR_graph[i]>threshold):
 +
            SNR.append(SNR_graph[i])
 +
 +
 +
    tmp=numpy.asarray(SNR)
 +
    tmp.tofile(f)
 +
 +
 +
def main():
 +
    try:
 +
        SNRStudy(sys.argv[1])
 +
    #except IndexError:
 +
        #print("Donnez le nom du fichier\n")
 +
    except IOError:
 +
        print("Le fichier n'existe pas\n")
 +
 +
 +
</nowiki>
 +
 +
=Conclusion du projet=
 +
 +
Durant ce projet, nous avons cherché à determiner l'impact potentiel du matériel et informatique sur le champ électromagnétique. Dans l'idée commune, le signal émis par une antenne de même type est censé être le même, afin de le démoduler correctement au niveau de la reception. Néanmoins, il est très rare d'un point de physique d'avoir des signaux parfaitement identiques et celà dans les mêmes conditions expérimentales.
 +
 +
On a pu voir que de nombreux facteurs témoignaient de potentielles - et il est important de souligner le terme potentielles - caractéristiques uniques provoquées non pas par l'antenne émettrice, mais par le matériel et/ou le logiciel. En effet, les conjectures émises en conclusion des expériences ne peuvent être validées de manière absolue, mais sont néanmoins la preuve d'une réelle influence du matériel et sont selon nous des pistes à développer (le modèle de boîte noire se rapporte à notre projet).
 +
 +
Dans le cadre de notre projet, c'est l'antenne XBee qui a été étudiée.
 +
 +
A l'issue de ces expériences, nous avons pu mettre en évidence de nombreux points :
 +
 +
- les signaux émis par les XBee respectent les caractéristiques temporelles et fréquentielles données par leur datasheet (première expérience)
 +
 +
- le firmware ne semble pas avoir pas de réel impact sur les signaux, ni sur la variation d'amplitude
 +
 +
- le SNR témoigne de la puissance d'émission de l'antenne et permet de distinguer un module XBee Pro d'un module Xbee Série S1, permet aussi de différencier les signaux (sans nécessairement les identifier) et présente un potentiel gap entre un signal émis directement par série et un signal émis par un Arduino.
 +
 +
- le temps de fragmentation d'un paquet transmis ainsi que le calcul du FCS montre un schéma pouvant potentiellement être unique à tout un chacun des composants.
 +
 +
Nous aurions pu faire d'autres expériences pour nous conforter sur nos positions, néanmoins, nous n'avions pas trouvé d'autres d'idées qui pouvaient être réalisées avec nos outils (la variation de l'amplitude du signal nous a montré que le HackRF n'est pas exempt de défaut).
 +
 +
 +
Ce projet a été pour nous une expérience nouvelle. Là où la plupart des projets étaient plus orientés à la conception et la réalisation, avec un objectif bien défini, le notre lui était tout autre. En effet, l'approche était plus expérimentale et orientée vers la recherche.
 +
 +
Les premières pistes de ce projet, bien qu'elles ne soient pas à négliger, se basaient sur les fuites électromagnétiques dispersées par les différents composants électroniques et informatiques d'un système. Néanmoins, avec le matériel et les compétences actuelles, il nous aurait été difficile de mener à bien ce projet de recherche et de poursuivre nos idées.
 +
Ainsi, le fait d'étudier les signaux directement par canal direct et non annexe (pas de CEM), nous permettant de chercher des potentielles caractéristiques uniques (le terme utilisé étant les clés) était donc la piste privilégiée.
 +
 +
La difficulté n'en était pas amoindrie. De nombreux obstacles devaient être franchis.
 +
 +
Tout d'abord, il nous a été nécessaire de nous initier à la radio logicielle, qui était l'outil principal pour mettre en oeuvre nos idées. Néanmoins, hormis dans le cadre de la démodulation de signaux et dans celui du Hacking (attaque radio, par replay etc...), il y a très peu de documentation au niveau de la radio logicielle et reste un domaine peu accessible au grand public (matériel et conditions d'acquisition obligent). Le procédé de recherches et les expériences nous ont donc été propre.
 +
 +
Ce qui nous mène à la seconde difficulté : la mise en place du protocole de recherche. La caractérisation d'un signal ou d'une empreinte propre necessite de faire des tests qui peuvent mener ou alors à des pistes intéressantes voire concluantes, ou alors à des echecs.
 +
 +
Dans notre cas, tout ne nous permettait pas de développer le sujet.
 +
La rencontre de Etienne Helluy Lafont a été pour nous d'une grande aide et nous a permis de savoir si les pistes qui avaient été développées étaient pertinentes ou non.
  
 
=Documents Rendus=
 
=Documents Rendus=
 +
 +
 +
L'archive des scripts et codes utilisés :
 +
 +
[[Fichier:Scripts.zip]]
 +
 +
 +
Le rapport
 +
 +
[[Fichier:Rapport_projet_P70_2019.pdf]]
 +
 +
=Bibliographie et liens=
 +
 +
Datasheet XBee : https://www.sparkfun.com/datasheets/Wireless/Zigbee/XBee-Datasheet.pdf
 +
 +
Wiki GNURadio : https://wiki.gnuradio.org/index.php/Main_Page
 +
 +
Documentation Doxygen GNURadio (prototypes des fonctions python) : https://www.gnuradio.org/doc/doxygen/
 +
 +
HackRF One: https://greatscottgadgets.com/hackrf/

Version actuelle datée du 10 mai 2019 à 10:48

Impact du matériel et du logiciel sur le champ électromagnétique




Présentation générale

Projet : Impact du matériel et du logiciel sur le rayonnement électromagnétique

Nous proposons d'évaluer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et la consommation électrique.

Etudiants : Souheib KHINACHE et Antoine MOREAU

Encadrants : Alexandre BOE, Xavier REDON et Thomas VANTROYS

Description

L'internet des objets est un marché en plein essor. La communication entre les différents objets connectés crée un nuage de signaux autour d'eux. Ces derniers sont vus par les utilisateurs comme des boîtes noires : le fonctionnement se fait sans en connaître les composants matériels et logiciels. Néanmoins, ces objets, de par leurs propriétés électroniques, créent des fuites électromagnétiques impactant le champ environnant.

Bien qu'ils peuvent porter à débat sur l'impact sur la santé, ces signaux peuvent représenter de réelles sources d'informations sur l'aspect matériel et applicatif de l'objet.

Il serait donc intéressant d'avoir idée générale sur le fonctionnement du système en interprétant les ondes électromagnétiques émises par ce système.

Objectifs

Les principaux objectifs de ce projet seront donc de mesurer l'impact du matériel et du logiciel sur le rayonnement électromagnétique et sur la consommation électrique. Pour cela, l'outil potentiel avec lequel nous pourrions travailler serait une sonde de champ électromagnétique afin d'établir des mesures. Cependant, nous pourrions concevoir notre propre système de capture et d'interprétation à partir d'une antenne, de filtres de fréquences et d'un microcontrôleur (on commencera par un ATMega328P). Il sera nécessaire de prendre en compte les perturbations issues de notre appareil de mesure et d'en tenir compte.

On effectuera ainsi plusieurs expérimentations sur différents supports d'étude :

  • l'aspect "Hardware" en étudiant différents modèles pour un même type de shield
  • l'aspect calculatoire du matériel en se basant sur l'impact des microcontrôleurs en fonction du modèle (ATMega328P et ATMega2560)
  • l'aspect "Software", en étudiant l'impact du logiciel et du firmware d'un même composant (différents firmwares pour un même shield Wi-Fi)
  • l'aspect puissance des composants électroniques de gestion de puissance (ponts, hacheurs, onduleurs...).

L'étude des différentes informations se fera par traitement des signaux électromagnétiques et des spectres. Afin de mieux appréhender le problème, il nous est nécessaire de comprendre les phénomènes physiques issus de la notion d'électromagnétisme.

Ces études mèneront à une étape plus complexe : l'interprétation des signaux. En effet, l'un des objectifs de ce projet est de comprendre du mieux possible le fonctionnement d'un système sans y avoir accès directement, et donc dans ce contexte "traduire" un ensemble de signaux électromagnétiques.

On pourra en outre apporter un aspect visuel à l'étude en rajoutant une interface informatique.

Analyse du projet

Positionnement par rapport à l'existant

Bien qu'aux yeux de nombreuses personnes le bruit électromagnétique créé par les équipements électroniques du quotidien peut porter à controverse (débats concernant l'impact sur la santé par exemple), il peut être une source d'informations. De nos jours, les ondes électromagnétiques restent un vaste champ d'étude, sujettes à de nombreuses thèses et recherches au sein des laboratoires.

On peut prendre l'exemple de Milos Prvulovic, professeur à l'Institut Technologique de Géorgie, ayant simulé un contexte de cybercafé, dans lequel il place une antenne magnétique, un ordinateur portable cible et un ordinateur "espion". Il réussit, grâce aux signaux EM émis par l'impulsion de l'appui des touches clavier à capter un message écrit par un ordinateur cible.

Néanmoins, dans le quotidien, l'utilisation des sondes électromagnétiques se fait pour l'étude énergétique d'un système électronique (fuites électromagnétiques anormales, preuves d'une anomalie...) afin de respecter certaines normes législatives. Le code du travail par exemple réglemente et définit des valeurs seuils par le biais des articles R. 4453-3 et R. 4453-4.

Analyse du premier concurrent

NBM-520 de NARDA STS

NBM-TS, application des appareils NBM

NARDA STS est une entreprise qui fournit des outils de mesure. Elle met à disposition aux professionnels des sondes électromagnétiques. La NBM-520 est un appareil de la franchise, mesurant le champ électrique et magnétique. Elle donne des valeurs précises du champ électromagnétique ambiant sur une large bande. Elle propose différentes sondes modulables permettant une souplesse au niveau de l'étude en fonction des besoins, avec des sondes pouvant étudier des signaux de fréquence de 100kHz à 6GHz ou même de 300kHz à 50GHz (en fonction de la sonde choisie).

En outre, le dispositif peut se connecter en USB sur PC afin d'envoyer les données capturées et d'en faire une étude. Le dispositif propose un logiciel d'étude, NBM-TS, permettant d'observer du champ en fonction du temps, de la fréquence, de la position...

L'équipement est utilisé par l'ANF (l'Agence Nationale des Fréquences, agence gérant l'ensemble des normes autour des radiofréquences), et est donc un gage de qualité.


Avantages :

  • Large bande de fréquence
  • Matériel solide
  • Application fonctionnelle permettant l'étude et gestion des données
  • Possibilité d'étudier séparément champ électrique et magnétique

Inconvénients:

  • Impossible d'étudier les basses fréquences (appareils sous tension, bobinages...)
  • Prix élevé : à partir de 3100€
  • La cible de ce produit est surtout les professionels

Analyse du second concurrent

Une pita.

Comment mon pain à pita vole ta clé RSA ?

Une pita.


Des chercheurs israéliens ont découvert un moyen de capturer des clés de cryptage RSA, réputées comme inviolables, par le biais d'une pita... du moins avec un dispositif suffisamment petit pour être caché dans un pain à pita. Le dispositif, renommé PITA pour Portable Instrument for Trace Acquisition a la particularité de capturer les ondes radio électromagnétiques émanantes d'un PC, qu'il soit connecté à un réseau ou pas. Les différentes opérations du processeur sont identifiées en distinguant les différents modèles de l'activité radio sur le spectre EM.

Bien que la capture des clés RSA a été faite dans des conditions particulières (modification du processeur de l'ordinateur cible), il est néanmoins possible, selon les chercheurs, d'identifier quelle type d'activité est exercée par l'ordinateur ainsi que son état.


Un dessous de pita.


L'un des points importants concernant le dispositif est son coût : moins de 300 euros. L'appareil dispose :

  • d'un PC portatif (PC-on-a-stick) Rikomagic MK802 IV,
  • d'un recepteur radio SDR FUNcube Dongle Pro+
  • d'une antenne radio
  • d'une batterie
  • d'une antenne WiFi
  • d'une carte MicroSD
  • d'un adapteur d'antenne
  • et d'une pita.


Le dispositif aurait une portée de 50cm. Les chercheurs israéliens ont collaboré avec GNU Private Guard (logiciel de cryptage asymétrique) afin de protéger contre ces attaques les clés de cryptage.

Scénario d'usage du produit ou du concept envisagé

Scénario 1

Gérard a toujours le flair pour les bonnes affaires. Il a acheté une centaine de clés WiFi à un prix dérisoire sur AloXpresso afin de faire du profit à la revente. Le vendeur lui garantit que toutes les clés fonctionnent correctement. Gérard veut vérifier. Après vérification, 99 des clés sur 100 fonctionnent comme prévu. Gérard aimerait être sûr du disfonctionnement, mais Gérard n'est pas une pointure en informatique.

Coup de génie ! Il se rappelle qu'il dispose d'un dispositif qui capte les ondes EM et les interprète directement. C'est le moment de tester ça. Il remarque une anomalie sur le spectre. Il décide de contacter le revendeur pour lui signaler un disfonctionnement sur l'une des clé. Pas de soucis. Le vendeur, étant bon prince, lui envoie une autre clé USB et lui fait une ristourne.


Scénario 2

La police fait une perquisition chez un individu soupçonné de graves délits. Cela fait plusieurs mois que la brigade criminelle prépare l'intervention, et une fois sur les lieux ils arrêtent le soupçonné malfaiteur. Cependant avant de repartir, elle veut faire l'acquisition d'un maximum de preuves. Elle veut alors prendre l'essentiel des objets, dont certains objets éléctroniques connectés de l'individu dont elle pourra extraire les informations qui serviront à le faire tomber.

Par chance, elle dispose d'un petit outil qui scannera les signatures alentours des objets connectés, comme des téléphones cachés, clés USB wifi dissimulées dans le décor etc.. Et si le suspect avait modifié malignement un objet connecté banal pour l'utiliser autrement à ses fins, la police le découvrirait car elle possède une base de données de toutes les signatures spectrales des objets connectés sur le marché et celle de l'objet modifié ne collerait pas avec celle de la base de données.

Réponse à la question difficile

Comment étudier les signaux malgré les perturbations électromagnétiques ambiants et les faibles signaux des µC ?


Les signaux électromagnétiques des microcontrôleurs ou d'autres composants peuvent être faibles. Il y a une possibilité pour palier à ce problème, c'est de capter les signaux depuis une antenne émettrice que l'on rajoute à l'objet d'étude. Nous utiliserons un SDR (Software Defined-Radio) afin de capter les ondes radio et les étudier directement sur PC. Le filtrage s'effectuera ainsi de manière numérique. Plusieurs tests seront effectués pour le même objet à étudier (quand on parle d'objet, on évoque un ensemble de plusieurs composants, comme par exemple une alimentation, un micro-contrôleur et une antenne). Ainsi, de manière statistique, nous pourrons en déduire un pattern récurrent pour chaque expérience en les effectuant dans différents environnements (pourquoi pas une chambre anachoïque).


Préparation du projet

Cahier des charges

Nous souhaitons

  • Capter le signal émis par un objet connecté le plus précisément possible
  • Concevoir nos propres objets connectés tous différents mais basés sur un même modèle
  • Interpréter les spectrogrammes, faire une étude statistique des signaux émis par nos différents objets et en tirer des conclusions
  • Répertorier dans une base de données les signatures de nos objets , voire de quelques objets disponibles sur le marché

Choix techniques : matériel et logiciel

Choix logiciel :

- La distribution Linux Pentoo ou Kali pour traiter les signaux avec GNU RADIO (Suite logicielle dédiée à l’implémentation de radios logicielles et de systèmes de traitement du signal).

- FemtoOS pour l'OS des ATMEGA328P et ATMEGA2560


Choix Matériel :

- Plusieurs modules radios émetteurs

- Plusieurs microcontrôleurs ATMEGA328P et un ATMEGA2560

- Des alimentations identiques pour chaque PCB

- Un HackRF pour la réception des signaux

- Une antenne 50 Ohm pour le HackRF [1]

Liste des tâches à effectuer

Tout d'abord, nous devons préparer tout le matériel qui servira à faire nos tests. C'est à dire concevoir :

- Un ensemble SDR/PC qui traitera le signal reçu avec GNU RADIO.

- Une multitude de PCB qui seront utilisés comme objets connectés (Sur chacun d'entre eux on trouvera au minimum une antenne radio, un microcontrôleur et une alimentation)


Ensuite afin de récupérer une "signature" d'un de nos objets , il faudra faire plus de 50 analyses spectrales pour conclure statistiquement sur une bonne signature qui caractérisera l'objet.

Nous devons donc dans un second temps:

- Récupérer la signature de deux objets connectés identiques mais qui ont un firmware différent.

- Récupérer la signature de deux objets connectés identiques qui ont pour seule différence le microcontrôleur.

- Récupérer la signature de deux objets connectés identiques dont seul le PCB diffère.

Grâce à tous ces tests , nous pourrons conclure et voir l'impact qu'à le matériel ou le logiciel sur la signature d'un objet.


Enfin si les délais nous le permettent, nous pourrons réaliser un software qui cartographiera nos objets connectés dans la pièce grâce à la puissance de la signature reçue (Ce qui devrait être réalisable puisqu'à ce stade nous aurons une base de donnée des signatures).

Calendrier prévisionnel

Réalisation du Projet

Feuille d'heures

Tâche Prélude Heures S1 Heures S2 Heures S3 Heures S4 Heures S5 Heures S6 Heures S7 Heures S8 Heures S9 Heures S10 Heures S11 Heures S12 Heures S13+ Total
Analyse du projet 3 8 0 0 0 0 0 0 0 0 0 0 0 0
Recherches 1 3 3 3 6 3 3 3 4 3 4 0 0 0
Prise en main de GnuRadio 0 4 4 4 3 2 3 2 1 1 1 0 0 0
Configuration Xbee 0 2 2 1 1 2 2 0 0 0 0 0 0 0
Préparation expérimentale (écriture de codes et scripts...) 0 0 2 3 0 0 0 0 0 0 0 0 0 0
Expériences 0 0 0 0 0 0 0 1 3 3 5 0 0 0
Etude et interprétation des résultats 3 8 0 0 0 0 0 0 0 0 0 0 0 0
Total 4 15 9 8 7 8 8 0 0 0 0 0


A partir de la semaine 10/11, nous n'avions plus trop de notions du temps passé sur notre projet. Nous préférons être honnête et ne rien mettre plutôt que de mettre de fausses heures !

Prologue

Semaine 1

Le HackRF One

Durant cette semaine, nous avons continué nos recherches notamment sur le moyen de transmission de nos objets connectés. Nous avons confirmé notre choix de notre SDR : Monsieur Boé nous a confirmé que des HackRF seraient disponibles dans les laboratoires et qu'il pourrait nous en prêter un. On disposera donc d'une antenne puissante pour traiter les signaux émis par nos objets communiquants.

Il faudra coupler notre HackRF avec un logiciel appelé GNU RADIO qui est un logiciel très complet ( Pour information : la NASA a utilisé GNU RADIO afin de rétablir le contact avec une sonde spatiale abandonnée ). Afin de faire tourner ce logiciel libre, nous aurons besoin de la distribution Kali Linux, ex Backtrack.


Choix des émetteurs/récepteurs

Nous avons décidé que nos objets connectés communiqueront dans deux bandes de fréquences ISM, l'une à 900 MHz grâce à des modules Digi Xbee et l'autre à 2,4 GHz par le moyen de modules émetteurs Bluetooth. On rappellera que les Digi Xbee et les émetteurs/récepteurs Bluetooth seront pilotés par des ATMEGA 2560.

Les Xbee ne communiqueront pas entre eux et émettront en continu les mêmes données car ils le peuvent, alors que les émetteurs/récepteurs Bluetooth devront s'échanger des données si on veut pouvoir observer un quelconque signal autour de la fréquence de leurs porteuses.

On voudra observer premièrement, si avec deux objets dans les mêmes conditions (donc même µc et même émetteur), on peut ou non distinguer une différence. Ceci est fondamental pour la suite des expériences, puisque si les deux émettent à la même fréquence, on pourra faire varier plusieurs paramètres afin de trouver des clés (des signes) qui pourraient aider à l'identification du matériel.

Ces clés représentent différents facteurs potentiels d'identification du signal (le rapport signal-bruit en fonction de la distance par exemple...).

On planifie alors pour la semaine suivante de réussir à faire émettre, en utilisant simplement des breadboards pour commencer, nos Xbee et modules BT et observer quelque chose grâce à notre SDR.

Semaine 2

Configuration des modules XBee

Nous avons configuré deux XBee afin qu'ils puissent communiquer entre eux :

Les modules XBee ont été montés sur des platines d'interface USB/série de manière à ce qu'on puisse les paramétrer via le programme de contrôle minicom.

Dans le doute, on supposera que les XBee communiquent à 9600 Baud. On exécute la commande suivante :

minicom -b 9600 -D /dev/ttyUSB0


On active l'echo local dans minicom, afin de pouvoir observer ce qui a été envoyé par liaison série au XBee (CTRL+A puis E).

Pour commencer le paramètrage il faut taper +++ rapidement. Le XBee nous répond OK, cela veut dire que nous sommes dans le mode configuration et que nous pouvons utiliser les commandes AT. (Redirection vers la liste des commandes AT XBee [2]).

Comme nos XBee ont été utilisés auparavant, il a fallu les restaurer à l'état usine avec la commande ATRE.

Si on souhaite que des XBee puissent s'envoyer des données il faut qu'ils soient sur le même canal (commande ATCH) et aient le même PAN ID (commande ATID). Notre PAN ID sera BEE6 et le canal sera celui par défaut C.

Ensuite il faut leur donner une adresse de destination (ATDH & ATDL) qui sera l'adresse broadcast, pour ce faire on entre 

ATDH=0000
ATDL=FFFF

Enfin ATMY représente l'ID du XBee, notre premier XBee aura comme ID 5000 et le second 5001.

N'oublions pas de sauvegarder les paramètres avec ATWR.

On vérifie que tout a bien été pris en compte :

+++OK
ATID
BEE6
ATCH
C
ATDH
0
ATDL
FFFF
ATMY
5000
ATCN
OK


Puis on fait de même avec le deuxième XBee (ID 5001).

Voilà, lorsque on envoie des caractères par liaison série sur 5000, la LED Tx de 5000 s'allume et la Led Rx de 5001 s'allume elle aussi. Cela signifie que l'envoi de donnée par onde radio s'effectue correctement.


Maintenant que les XBee émettent et reçoivent, on peut commencer les mesures avec notre SDR. Mais avant cela il va falloir bien se familiariser avec le logiciel GNU RADIO qui est assez difficile à prendre en main.

Première prise en main du logiciel GNURADIO

Installation de GNU radio avec les fonctions + drivers pour HackRF : 

sudo apt-get install gqrx-sdr gnuradio gr-osmosdr hackrf


Le bloc Osmocom Source sert de "passerelle" entre le logiciel et la SDR, il permet de transmettre les informations récupérées par le HackRF afin qu'on puisse les traiter avec d'autres bloc de fonctions.

Si on veut pouvoir récuperer les données il faut passer l'argument hackrf=0 dans la box périphérique du bloc Osmocom.

Ci-dessous on peut voir le spectre environnant entre 2.44GHz et 2.460GHz grâce au bloc WX GUI FFT Sink.


Interface de GNURadio

Semaine 3

Premières observations

Cette semaine nous a permis d'effectuer notre première expérience. L'utilisation des deux Xbees nous a permis d'observer l'impact des Xbee sur le champ électromagéntique environnant.

Si on analyse le spectre environnant grâce au module FFT de GNU Radio, lorsque les Xbee communiquent entre eux, on peut apercevoir un pic caractéristique propre. En effet, lors de l'emission d'un message sur le port série, on a un pic qui se dégage du spectre d'amplitude -20dBm. Ce pic est caractéristique au canal de communication choisi et configuré sur le Xbee. Néanmoins, le signal est perturbé par le bruit environnant. L'expérience étant effectuée au sein de l'école, les signaux Wi-Fi perturberont l'étude. Il faut noter que la norme IEEE 802.11 impose au Wi-Fi l'utilisation d'une bande passante s'étalant de 2.4 GHz à 2.5 GHz.

La bande passante des modules Zigbee se décomposent en 16 canaux, allant de 2400 MHz à 2480 MHz par pas de 5 MHz.

Le canal ici utilisé est le canal 13 (3ème canal) de fréquence 2415 MHz.

  • Spectre de l'environnement autour du XBee
  • Lors de l'envoi de données au XBee voisin


On peut observer un pic de puissance lors de l'envoi d'une donnée en série à la fréquence 2.415 GHz. Il nous est maintenant nécessaire d'analyser de plus près les signaux et leurs fréquence centrale dans la bande perçue au dessus de -20dB.

On réeffectuera une expérience en zone isolée des signaux parasites.

Semaine 4

Cette semaine, nous avons principalement fait des recherches dans le but de mieux comprendre les signaux émis par le Xbee.

En somme, nous étions confrontés à de nombreuses interrogations. Le fonctionnement du Xbee étant assez simple et la sécurité du protocole Zigbee étant moindre, y a t-il possibilité de démoduler le signal émis afin de développer nos études ?

Semaine 5

Script Python

Après réflexion et consultation de nos encadrants, nous nous sommes rendu compte que la démodulation prévue lors de la semaine 4 n'aiderait pas à répondre à la problématique de notre sujet !

Afin de mieux visualiser les signaux des Xbee , on décide d'automatiser le processus d'envoi sur le port série des données vers le Xbee. C'est à dire concevoir un programme Python qui automatisera l'envoi de données et le changement de channel à intervalle de temps régulier (Changement toutes les 10 secondes).

L'utilisation de Minicom n'était pas du tout la meilleure solution pour faire émettre les Xbee.


Après quelques essais, on remarque que lorsque le Xbee émet sur le channel 13, il émet à environ 2,445GHz au lieu d'émettre à 2,415GHz soit une différence de 30MHz : Ceci n'est pas important, car ce que l'on souhaite remarquer c'est un éventuel décalage de la fréquence centrale entre deux Xbee différents. Si les deux Xbee n'ont pas la même frequence centrale on pourra conclure que la fréquence centrale de la porteuse du Xbee n'est pas une des clés permettant d'identifier cet émetteur/récepteur.





Semaines 6 et 7

Afin de mieux cerner le comportement électromagnétique des modules XBee, il nous est nécessaire de comprendre leur fonctionnement et le protocole Zigbee.

Cette semaine, nous avons cherché à souligner le parallélisme entre étude fréquentielle par le spectre et étude temporelle du signal.

Planche prototype

Tout d'abord, nous avons paramétré la fréquence centrale de capture du HackRF. En effet, bien que le HackRF dispose d'une large bande passante, afin de se focaliser sur la porteuse, il est indispensable de configurer le HackRF en conséquence. En second lieu, pour éviter une variation du RSSI (Received Signal Strength Indication) et de la puissance du signal, nous devions mettre en place une prototype de "planche expérimentale" sur laquelle devaient être fixés nos différents modules (l'antenne de reception et les Xbees).

La position des antennes les unes par rapport aux autres est fondamentale. Afin d'optimiser la reception, les antennes doivent être parallèles.

Chaque Xbee est identifié par un chiffre (1 ou 2). En effet, l'attribution de ces chiffres sera définitive pour ne pas perturber la cohérence des expériences. Leur position est aussi fondamentale. Ainsi, en fonction que le Xbee soit emetteur ou récepteur, il sera disposé différement sur la planche.


Expérience : Le XBee 1 émetteur directement connecté en série au PC

Schéma simple d'étude fréquentielle et temporelle


Cette expérience est la première mettant en place un contexte (un seul Xbee émetteur connecté en série au PC, le deuxième Xbee étant inactif) et nous permettra d'étudier le plus de cas possibles.

Nous avons tout d'abord commencé par un graphe GNURadio simple permettant l'observation du spectre et du signal et la variation de la fréquence d'étude.

Le script python a été réécrit afin que le XBee puisse émettre une chaîne de caractère "HELLO" * 1024. En effet, même si la fréquence de balayage du module HackRF peut être grandement augmentée, il faut éviter d'aller au dessous de 0.01s, finissant par consommer de manière considérable les ressources octroyées par le CPU le cas échéant. Le fait d'augmenter la taille de la chaine de caractère permet de mieux synchroniser l'étude en temps réel avec la capture des données.

Nous avons donc émis les données sur le canal 20 (14 en hexadécimal), soit la fréquence centrale est à 2.450GHz selon la norme Zigbee.


Etude fréquentielle

L'étude fréquentielle est similaire à celle réalisée auparavant.


  • Spectre fréquentiel au canal 14
  • Spectrogramme

Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz.

D'autre part, l'ensemble des fréquences qui dessinent le spectre s'étalent sur une large bande de fréquence. En effet, cette technique d'étalement appelée DSSS (Direct-Sequence Spread Spectrum) utilisé par les modules XBee permet au signal d'être moins sensible aux interférences et aux brouillages. En outre, même si la puissance du spectre dans sa globalité reste la même, la densité spectrale elle diminue considérablement, rendant le signal plus "discret". La différence de puissance entre le lobe principal et les premiers lobes secondaires sont de 30 dB, ce qui est aussi commun au DSSS.

Le spectrogramme témoigne aussi de l'étalement du signal sur un peu plus de 6 MHz (3MHz de par et d'autre de la fréquence centrale).


Etude temporelle

Signal observable centré à 2.450GHz lors de l'émission

Le signal ici est séparé en deux composantes car il s'agit d'un signal complexe. Nous avons supposé en premier temps qu'il s'agissait du signal principal décalé de 180°, ce qui n'était pas le cas. Après quelques recherches, cette séparation des composantes permet de transmettre deux fois plus de données sur la même bande passante. Le signal observable témoigne d'une modulation bien spécifique au XBee. En effet, on peut observer des sauts de phase à différents points, qui correspondent à une modulation par changement de phase (modulation QPSK ou Quadratic Phase-Shift Keying). Ce sont ces sauts de phases qui permettent la transmission des bits. Les changements de phase s'il y a se font toutes les µs. En outre, on peut observer un décalage (offset) entre la composante Q et la composante I de µs/2 (propre à la modulation OQPSK).

Nous avons décidé d'enregistrer ces données brutes dans un fichier et nous l'avons étudié avec Audacity, logiciel open-source de son, et donc de signaux ! L'inconvénient avec l'interface graphique QT de GNURadio est son manque de précision lors d'un dézoom sur le signal en temps réel. Audacity permet de palier à celà ! En outre, on peut voir que les paquets Xbee sont reconnaissables. En effet, le signal témoigne de la taille du paquet XBee.

Le paquet XBee est constitué d'un premier header (header physique) de 6 octets : - la séquence de préambule (4 octets) constitué de 32 bits à 0

- l'indice de début du paquet fixé à 0x7A (1 octet)

- la longueur du paquet (1 octet);

d'un header MAC (7 à 27 octets en fonction des informations de l'adresse), d'un bloc FCS de fin de paquet (2 octets) et l'ensemble des données (de 1 à 104 octets).


On observe graphiquement qu'un paquet est transmis en 3846µs
Paquet XBee


Comme dit plus haut, les signaux émis par le XBee connaissent un étalement sur le spectre par DSSS. Cet étalement s'effectue en divisant chaque symbole (correspondant à une série de 4 bits) transmis en chips. Chaque symbole, soit 4 bits, correspond à 32 chips, et donc 32 états binaires (1 octet correspond à 64 chips). Dans le cas de la norme ZigBee, la transmission de chacun des chips est synchronisé sur chaque µs (1 chip toutes les µs).

Les signaux reçus par l'antenne HackRF étaient deux sinusoïdes modulées en phase et qui s'étalaient sur une période d'environ 3840µs (3846µs graphiquement mais il y a possibilité d'erreur à l'echelle du µs). Sachant qu'un octet correspond à 64µs, on a :


N_{octets} =\frac{2*T_{signal}}{64*T_{chip}}=\frac{2*3.840*10^{-6}}{64*10^{-6}}=120 octets


L'analogie peut être effectuée entre paquet Ethernet et paquet ZigBee. En effet, la taille limite des données d'un paquet est de 104 octets. La chaîne de caractère n'étant qu'envoyée par paquet, le paquet observé n'est que de 120 octets, ce qui est cohérent avec les caractéristiques du XBee.


  • Temps de transmission de la chaîne de caractères "HELLO" 1024 fois
  • 51 Paquets XBee portent la chaîne de caractère "HELLO" 1024 fois

Semaine 8

L'étude des signaux posait réellement problème de par le fait qu'une grande partie de la capture faite n'était que purement le bruit sans signal (utile plus tard pour l'étude du SNR). Prenons l'exemple d'un paquet de 21 octets (un paquet contenant une seule chaîne de caractères HELLO). Le signal s'étalerait en théorie sur 21*64 chips soit 672 chips. Sachant que la modulation est une modulation QPSK, on s'étale sur un temps de 672µs. En effet, le Xbee transmet toutes les 100ms. Donc qu'une partie du signal nous est utile.

Nous avons donc décider d'écrire un script qui nous permettrait d'étudier le signal dans de meilleures conditions, et donc de le filtrer.

Chaque capture de signal effectuée est enregistrée dans un fichier par le biais du bloc fonction File Sink du compagnon GNURadio. Néanmoins, les fichiers obtenus sont des fichiers binaires assez lourds (environ 500Mo pour une capture de 3s), ce qui est un réel problème et qui implique le filtrage du signal.

La bibliothèque numpy pour python nous permet en outre directement d'importer les échantillons des signaux, les traduisant du binaire à un format cible (complexe flottant 64 bits) dans un Array par le biais de la fonction:

f = scipy.fromfile(open("Nom du fichier"), dtype=scipy.complex64)

La première solution pour réduire ce signal était d'imposer un threshold directement sur le signal, supérieur au bruit, mais qui conduirait à une perte d'une partie du signal à étudier. La deuxième solution qui a été retenue était tout simplement de calculer l'amplitude et la phase du signal et appliquer ce même threshold à l'amplitude.

Semaine 9 et 10

A partir de la semaine 10 nous avons procéder aux expériences pour avoir suffisamment de données et en tirer des conclusions.

Lorsqu'on fait une acquisition d'un signal xbee , on peut maintenant via un script traiter cette acquisition et récupérer seulement les parties qui nous intéressent : A savoir la partie réelle et la partie imaginaire, l'amplitude du signal et enfin la phase du signal.

Exemple ci dessous après acquisition + traitement de notre xbee n°2 :

  • Signal Xbee2 post-traitement
  • Diagramme de constellation xbee2 après utilisation de LightSignal


L'utilisation du script LightSignal permet de retirer toutes les phases en dehors du signal. Ainsi, on peut caractériser le diagramme de constellation comme un diagramme propre à la modulation QPSK. 

#include <iostream>
import scipy
import numpy
import sys

def binToComplex64(name):
    threshold=0.10
    tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)
    tmp2=scipy.fromfile(open(name), dtype=scipy.complex64)
    
    f2 = open(name+"_filtre", "w+") 
    f = open(name+"_PhaseMeg_filtre","w+")
    
    p=1
    size=tmp.__len__()
    size2=tmp2.__len__()
    
    if size > size2:
        size=size2

    
    ground=False
    newListSignal=[]
    newListMagnPh=[]
    for val in range(0,size): 
        if(val>=(size/100)*p):
            print(str(p)+" %")
            p=p+1
        if(tmp[val].real>threshold):
            if(ground==True):
                for i in range(0,1000):
                    newListSignal.append(numpy.complex64(0))
                    newListMagnPh.append(numpy.complex64(0))
                ground=False
            newListSignal.append(tmp2[val])
            newListMagnPh.append(numpy.complex64(tmp[val].real+tmp[val].imag*0.3j))
        else:
            ground=True
    
    tmp=numpy.asarray(newListMagnPh)
    tmp.tofile(f)
    tmp2=numpy.asarray(newListSignal) 
    tmp2.tofile(f2)
 

def main():
    try:
        binToComplex64(sys.argv[1])
    except IndexError:
        print("Donnez le nom du fichier\n")
    except IOError:
        print("Le fichier n'existe pas\n")



if __name__=='__main__':
    main()


Le diagramme de constellation témoigne de nouveau du type de modulation utilisé par le module XBee. En effet, on observe quatre points de part et d'autre des axes de quadrature et d'inphase.

Semaine 11

Nous avons décidé cette semaine d'étudier, ce qui est selon pour nous, l'une des pistes fondamentales de notre projet, et plus particulièrement de l'étude de nos signaux : le rapport signal bruit.

L'objectif de cette semaine et de celle à venir était, à partir du signal acquis par le hackrf, d'effectuer le calcul du SNR (signal-to-noise ratio) tel que :

SNR =\frac{P_{signal}}{P_{bruit}}

Le script python qui nous a permis de communiquer entre les deux shields Xbee se verra amélioré afin de faire plusieurs acquisition des signaux lors de la communication entre les Xbee, effectuer une moyenne statistique, et de même lorsqu'il n'y a pas de communication.

Nous avons essayé d'approcher le SNR directement depuis l'interface de GnuRadio par le biais de l'utilitaire graphique et le langage en bloc, néanmoins nous procéderons à l'étude de ce rapport avec Scilab ou Matlab.


Semaines supplémentaires

Expérience : Variation de l'amplitude

Contexte :

Le XBee1 emet une chaîne de caractères HELLO*256

L'objectif de cette expérience est d'étudier le temps de variation de l'amplitude du signal entre l'état où le signal n'est pas reçu et l'état où le signal est réceptionné et donc l'amplitude constante.

Résultats  :

A 20MHz de fréquence d'echantillonage, le temps de variation moyen est de 3 échantillons, soit 0.15µs, pour toutes les captures faîtes.

Conclusion sur l'expérience  :

L'expérience n'a pas été concluante. Même si elle nous a permis de voir quelques différences (probablement provoquées pas des erreurs de capture et d'analyse), le HackRF nous limite beaucoup sur ce point de vue là. En effet, la fréquence d'échantillonage étant limitée à 20MHz, le HackRF n'est pas suffisamment précis pour capturer un nombre d'échantillons nous permettant de confirmer une quelconque hypothèse.


Code python utilisé pour l'étude du signal : 

def etudeAmplitude(name, liste_temps):

    threshold_0=0.05 # Threshold
    threshold_1=0.4
    max_transition_time=50 #O

    amppha=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64) 

    p=1
    size=amppha.__len__()
    
    debut=1
    tps_variation=0 


    transition=False # Vérifie si le signal est en transition ou stable

    for val in range(debut,size):
        if(val>=((size-debut)/100)*p):
            print(str(p)+" %")
            p=p+1

        if(amppha[val].real>threshold_0 and amppha[val].real<threshold_1): # Phase de transition du signal
            if(transition==False):
                transition=True
            tps_variation=tps_variation+1

        elif(transition==True and amppha[val].real>threshold_1):
            if(amppha[val].real>=amppha[val-1].real-amppha[val-1].real*0.05 and amppha[val].real<=amppha[val-1].real+amppha[val-1].real*0.05): # L'amplitude du signal est stable
                if(tps_variation < max_transition_time):
                    liste_temps.append(tps_variation)

                transition=False
                tps_variation=0
            else:
                tps_variation=tps_variation+1
        else:
            transition=False
            tps_variation=0

Expérience : Temps de calcul du FCS entre le XBee1 et et le XBee2

Contexte 1 :

Le XBee1 et XBee2 sont alimentés sur 5V VCC par USB (connecté à l'ordinateur)

Le XBee1 et XBee2 disposent du firmware : 10EF

Le XBee1 est d'abord emetteur et le XBee2 est recepteur puis inversement. Aucun paquet ACK n'est renvoyé de la part du recepteur

On transmet la chaine de caractère HELLO 256 fois toutes les 1 secs Les données étant assez conséquentes, le Xbee transmet plusieurs fragments du paquet. L'objectif de cette expérience est d'étudier le temps entre chaque fragment d'un paquet. L’espace de temps entre chacun des paquets permet de calculer le FCS (frame check sequence) afin de minimiser les erreurs de transmission.


  • Les différents temps à mesurer


Néanmoins, l’étude de ces “temps morts” se voit entravée par le fait que le module HackRF ne permette pas d’obtenir un signal clair sur plus de 5 secondes. En outre, pour 5 secondes d’étude et pour une fréquence d’échantillonage de 20MHz (soit un temps Te=5.10e8), on compte 100.000.000 d’échantillons. Le CPU lors de la capture était grandement sollicité, ce qui explique le fait que la capture soit compromise. Pour régler ce problème, on a écrit un script shell de capture. Ce script consiste à:
- effectuer une capture d’une durée de 1 sec
- d’enregistrer la capture
- d’effectuer un traitement de ces paquets par un algorithme python en étudiant le temps entre chacun des fragments. Ce temps sera obtenu en nombre d’échantillons, défini avec un seuil d’acceptation absolu entre 150.000 et 300.000 échantillons (pour bien capturer ces temps intermédiaires et pas les temps provoqués par des signaux parasites ou du bruit), et pour affiner l’étude, on impose un seuil d’erreur de +-10% autour de la moyenne. La moyenne est calculée en continue
- l’ensemble des valeurs obtenues sont enregistrées dans un fichier
- on réeffectue la capture …

On répète le processus un certains nombre de fois afin d’obtenir un nombre de valeurs nous permettant de nous conforter sur l'issue de l'expérience (environ 1000 valeurs)

La capture et l'étude de chacun des modules dure une à deux heures.

Résultats :

Dans le cas du XBee1 (à gauche) et du XBee2 (à droite), voici les résultats obtenus :

  • On peut observer des pics caractéristiques à l'envoi
  • Les mêmes pics caractéristiques confirment un comportement non-aléatoires du module


XBee1 :

Moyenne : 259675,81

Ecart-type : 8369.7417

Variance : 70052576.


XBee2:

Moyenne : 258762.58

Ecart-type : 9165.4097

Variance : 84004736.


Les graphes présentent le nombre de répétitions des temps de calcul de fragements.

On peut voir des pics spécifiques à certains points dans les deux expériences. Ces pics sont caractéristiques et au module XBee, et à la chaîne de caractère HELLO. Les deux expériences étant effectuées dans le même contexte,

De même que pour le second Xbee, on retrouve des pics bien distincts à certains points.

En outre, on peut voir que ces pics bien distincts se rapprochent de ceux du premier Xbee. Néanmoins, même si la moyenne varie que très peu par rapport aux deux Xbee, la variance est assez différente.

Pour confirmer ces observations, il est peut être nécessaire de répéter la même expérimentation sur un nombre d'échantillons plus grand.

Ainsi, afin de confirmer la conjecture, on décide de faire d’autres captures.


En superposant les deux graphes (Xbee1 en rouge et Xbee2 en bleu), on peut voir qu'il y a moins de dispersion dans le cas du XBee1, plus centré sur des valeurs précises, contrairement au Xbee2.


XBee1Xbee2Graphe.png




Pour les deux nouveaux échantillons, on a les caractéristiques suivantes :

Xbee1 sur 1688 échantillons

Moyenne : 260230.3

Ecart-type : 8427.3923

Variance : 71020941


Xbee2 sur 1722 échantillons

Moyenne : 259899.41

Ecart-type : 9831.5106

Variance : 96658601







Signal observé dans le cas de l'ATMega328p


Contexte 2 :

Le XBee1 est connecté à un Arduino ATMega328p par le biais d'un shield Libelium

Le XBee1 dispose du firmware 10EF

On envoie exactement les mêmes données que précédemment, la chaîne de caractères HELLO*256 toutes les 0.5s

Hormis l'amplitude du signal qui paraît plus faible lors de la transmission par ATMega328p, le message transmis ne change PAS. Même si nous avons fait en sorte que la periode de transmission soit la même que pour l'expérience précédente, elle n'affecte en rien l'issue de l'expérience car c'est le temps de division de paquet.


Résultats :

  • Observation du temps de division d'un paquet dans le cas de l'ATMega328p
  • Observation du temps de division d'un paquet dans le cas de l'ATMega2560

Pour les nouveaux échantillons, on a les caractéristiques suivantes :

Xbee1 sur ATMega328p sur 706 échantillons

Moyenne : 265818.58

Ecart-type : 4748.5965

Variance : 22549168


Xbee1 sur ATMega2560 sur 711 échantillons

Moyenne : 262877.83

Ecart-type : 3675.037

Variance : 13505897


On peut observer une distinction significative entre une transmission effectuée directement par la machine et la transmission depuis les modules composés d'un ATMega328p ou d'un ATMega2560. En effet, on n'observe pas les mêmes pics caractéristiques dans cette expérience comparé à l'expérience précédente. Même si la moyenne est quasi la même, l'ecart type est plus faible, ainsi que la variance. En outre, de même que pour l'expérience précédente, l'écart-type entre ATMega328p et ATMega2560 est aussi différent.


Contexte 3 :

Le XBee1 est dans les mêmes conditions que durant la première expérience

On change le firmware du XBee1 pour le 10ED


Résultats :


Observation du temps de division d'un paquet lors du changement du firmware


Xbee1 sur 821 échantillons

Moyenne : 259735.52

Ecart-type : 8501.3996

Variance : 72273796


Après avoir changé le firmware, on a pu voir que les résultats ne changeaient pas par rapport à l'expérience témoin. On est même très proche des temps du XBee bien que l'expérience ne s'est pas faîte dans les mêmes conditions (pas au même endroit, donc possibilité de perturbations). On peut donc en conclure que le firmware n'a pas un impact sur le temps de calcul du FCS.








Conclusion de l'expérience : L’hypothèse qui est que la variance des temps "morts" entre chaque fragments de paquet, soit le temps de calcul du FCS pour le signal émis peut être considéré comme “clé” de distinction d’un module Xbee n'est donc pas à négliger. Le temps de calcul du FCS semble unique entre chaque paquet paraît une empreinte propre au matériel.

On peut même considérer que cette étude peut distinguer un module Xbee d'un autre électromagnétiquement parlant.


Code python utilisé pour l'étude du signal: 



def etudeSubdivPaquet(name, inter_time_values):

threshold = 0.30
ground = false
p=1

## On converti chacun des nombres binaires en complexe 64 (deux flottants 32 bits)##
amppha=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64) 


## On récupère la taille du tableau de complexes (taille du signal) ##
size=amppha.__len__()

    debut=0
    inter_time=0
    min_limit=150000
    max_limit=350000
    accept_range=1./10. ## Permet de mettre un seuil d'intervalle d'acceptation
    signalFnd=False

    for val in range(debut,size):
        if(val>=((size-debut)/100)*p):
            print(str(p)+" %")
            p=p+1

        if(amppha[val].real>threshold):
            if(ground==True):
                if(signalFnd==True):
                    if(len(inter_time_values)>0):
                        moy=moyenne(inter_time_values)
                        if(inter_time >= moy-accept_range*moy and inter_time <= moy+accept_range*moy):
                            print("Yes "+str(inter_time))
                            inter_time_values.append(inter_time)
                        inter_time=0
                    elif(inter_time>=min_limit and inter_time<=max_limit):
                        inter_time_values.append(inter_time)
                else:
                    signalFnd=True
                ground=False
        else:
            ground=True
            if(signalFnd==True):
                inter_time=inter_time+1

    if(len(inter_time_values)>0):
        print("Moyenne "+ str(moyenne(inter_time_values)))

Rencontre avec Etienne Helluy Lafont

Bien que plusieurs pistes ont pu être explorées, notre manque d'expertise dans le domaine de la radio logicielle nous a fait défaut sur nos recherches. En effet, après avoir calculé le SNR d'un de nos signaux, nous nous sommes retrouvés avec des résultats assez incohérents. De nombreuses erreurs peuvent se glisser et nous avions besoin de conseils à ce sujet.

Etienne Helluy-Lafont est un doctorant qui fait sa thèse sur les sondes pour la détection d’intrusions dans les architectures réseau hétérogènes et massivement distribuées. Il développe un outil permettant d'analyser le spectre environnant, de donner des informations sur les signaux émis sur certains canaux et même de démoduler ces signaux. Son programme en C est flexible puisqu'il est adapté pour beaucoup d'antennes (Une des librairies qu'il utilise est SoapySDR [3] qui possède des "codec" dont un pour notre HackRF !). Nous nous sommes servi de son outil afin d'avoir de bien meilleurs résultats quant aux expériences orientées SNR des Xbee.


Le programme sniffe l'environnement et renvoie les caractéristiques lors de la reception d'un signal

L'avantage de l'utilisation de l'application nous permet directement de nous focaliser sur les paquets correctement reçus et non les données parasites qui peuvent perturber l'antenne. En effet, le programme reste à l'écoute de l'environnement électromagnétique sur une bande de fréquence autour de la fréquence d'écoute du HackRF. Lors de la reception d'un signal, le programme démodule le signal et vérifie si le CRC (ou le FCS pour le Frame Check Sequence) et les données concordent. Si c'est le cas, le CRC nous renvoie 1. Il s'agit là alors d'un signal. L'utilisation ainsi de ce programme nous permet de ne pas obtenir de valeurs parasites pour le SNR et filtrer directement les informations qui nous sont intéressantes.

L'algorithme que nous avions écrit en Python est correct, néanmoins l'étude sur un signal enregistré requiert le chargement de l'intégralité du signal. Là où nos recherches se basent sur de la capture et du traitement post-capture, le travail d'Etienne se base sur un traitement du signal en temps-réel, ce qui nous permet ainsi de gagner un temps considérable.




Expérience : Variation du Rapport Signal Bruit en fonction de la distance de reception

  • Calcul du SNR par FFT
  • Calcul du SNR par fenêtre glissante

L'objectif de cette expérience était de visualiser comment le rapport signal bruit (ou SNR) varie en fonction de la distance. En effet, nous avions mis en suspens l'expérience qui consistait en la capture du SNR dû aux valeurs instables que l'on avait.

La première idée était de faire une FFT du signal et de calculer le rapport en prenant la moyenne de sa puissance sur une bande de 2.4MHz (1.2Mhz de part et d'autre de la fréquence de capture du HackRF).

Néanmoins, les caractéristiques du XBee (du point de vue de l'étalement spectral) rend le calcul du SNR imprécis. A la suite de la capture de signaux et de l'étude de ces mêmes signaux, les valeurs nous paraissaient incohérentes.

Pics de SNR


Nous avons donc procédé à une seconde méthode de calcul qui consiste à utiliser une fenêtre glissante de taille 2^k échantillons. Pour chaque échantillon du signal, on calculait le SNR tel que :

SNR =\frac{P_{signal+bruit}}{P_{bruit}}=\frac{|A_{signal+bruit}|^2}{|A_{bruit}|^2}

Dans notre cas, on a :

SNR_x =20.log \frac{Moyenne(W_x[2^{k-1}:2^k])}{Moyenne(W_x[0:2^{k-1}-1])}

W_x étant la fenêtre à l'échantillon x du signal, le rapport signal bruit est obtenu lorsqu'on a un pic. La fenêtre choisie doit être suffisamment grande pour avoir une précision optimale. On impose ainsi un threshold pour éviter des erreurs pouvant influencer les résultats de manière considérable. Ainsi, on obtient les valeurs SNR cherchées.


Nous voulons donc vérifier si la mesure du SNR est une expérience pertinente pour l'identification du matériel. Nous allons prendre plusieurs XBee et mesurer le SNR à différentes distances de l'antenne SDR.



Contexte 1 :

Le XBee1 et XBee2 sont alimentés sur 3.3V VCC par USB (connecté à l'ordinateur)

Le XBee1 et XBee2 sont des modèles série s1 disposent du firmware : 10EF

Le XBee3 et XBee4 sont des modèles XBeePro

Par défaut tous nos xbee disposent du même firmware (10EF), sauf si précisé que non

Nous cherchons à observer la différence entre le XBee1 et XBee2 dans la même situation.

Durant les expériences, le montage XBee1 connecté en USB sera le XBee témoin.



Résultats :

Les différentes valeurs du SNR acquises en fonction de la distance pour le XBee1

Dans notre cas, le modèle XBee1 connecté en série à notre machine nous a servi de composant témoin afin d'étudier les signaux des autres modèles. En effet, suite à la capture et l'étude des signaux, on peut voir que le nuage de points qui constitue notre graphe témoigne d'un phénomène électromagnétique ondulatoire quant au champ. Avec la distance, plus l'on éloigne le module, plus le rapport signal sur bruit diminue (le contraire nous aurait étonné). En outre, la variation ondulatoire peut être caractérisée par le champs éléctrique.

Nous avons décidé de refaire cette expérience avec les trois autres XBee directement connectés à notre machine.

ALLXBEE comparaison SNR distance.png

De part les potentielles erreurs et les différentes perturbations électromagnétiques ambiantes, la valeur du SNR peut être affectée. Il n'est pas possible directement par les caractéristiques du rapport signal bruit d'effectuer le distinguo entre le XBee1 et le XBee2 (contrairement à l'expérience basée sur la subdivision de paquets). Cependant, les XBee3 et XBee4 présentent une caractéristique commune. Le SNR est beaucoup plus élevé.

En effet, le pic de courant d'un XBee est de 45mA à la transmission pour une alimentation de 3.3V en tension continu, tandis qu'un module XBee pro, le pic de courant atteint les 150mA. Cette différence électronique permet ainsi au XBee pro de communiquer sur une plus grande zone (750m contre 90m pour un XBee simple).

Ainsi, on peut conclure de cette expérience que le SNR est un élément témoin de la consommation énergétique d'un composant électrique (du moins de l'antenne).



XBEE1 hardware comparaison SNR distance.png



Contexte 2 :

Le XBee1 est d'abord connecté à un Arduino UNO 328P par le biais d'un shield XBee Libelium puis est connecté à un Arduino Mega 2560 par le biais du même shield

Le XBee1 dispose du firmware : 10EF


Résultats :

On peut observer que même si l'unité de contrôle n'est pas l'ordinateur mais le micro-contrôleur (ici ATMega2560 et ATMega328P), le rapport signal bruit ne change pas réellement. Néanmoins, il était pour nous intéressant de noter qu'un léger gap se créé à 30 et 40 cm de la SDR entre la communication USB et la communication avec les micro-contrôleurs.


XBEE3 hardware comparaison SNR distance.png

Contexte 3 :

L'expérience est similaire que pour le module XBee1 mais avec le XBee3 (pro)

Le XBee3 est d'abord connecté à un Arduino UNO 328P par le biais d'un shield XBee Libelium puis est connecté à un Arduino Mega 2560 par le biais du même shield

Le XBee3 dispose du firmware : 10EF


Résultats :

En outre, les résultats obtenus lors de l'expérience avec le XBee3 nous indique que le phénomène ondulatoire observé durant les tests précédents est moins souligné dans la communication avec les micro-contrôleur (toujours à 30 et 40cm) et celà après plusieurs tests.

Des tests plus précis auraient été plusieurs avantageux et nous auraient permis de trancher sur la décision de l'importance du SNR concernant la différenciation de différentes unités de contrôle.


XBEE1 firmware comparaison SNR distance.png


Contexte 4 :

Le XBee1 ici est connecté en série et dispose dans un premier temps du firmware 10EF (le firmware le plus récent)

Après capture et expérimentation, on décide de réeffectuer la même chose avec le même XBee (XBee1) avec le firmware 10ED


Résultats :

Les acquisitions étant faites dans les mêmes conditions, il semblerait que le changement de firmware ait un petit impact sur la puissance d’émission : Cette petite différence de décibel ne semble pas aléatoire puisqu’on peut clairement voir que la courbe orange reste toujours inférieure à la courbe bleue, or le niveau de bruit est resté inchangé.





Conclusion de l'expérience :

Hardware : Les paquets émis via liaison série ont plus de puissance que ceux émis grâce aux arduino UNO et MEGA notamment à 10 cm, 40 cm et 50 cm. On remarque aussi une baisse du SNR moyen à 30 cm surtout en liaison série et ce, avec nos quatres XBEE. Coté ATMEGA , le SNR reste plutôt stable et décroit très doucement. Ainsi lors d’un calcul de SNR/Distance on pourra estimer si le XBEE est connecté au PC en liaison série ou à une ATMEGA quelconque selon si son SNR suit l’allure ou non de la courbe de la transmission classique.

En cherchant des raisons à cela, on se demande si ce phénomène n’a pas un rapport avec la longueur d’onde du signal modulé : la longueur d’onde est de 12 cm à 2.455 GHz, et la distance 30 cm coïnciderait avec sa demi-longueur d’onde.

Par le biais de ces mesures, on a pu démontrer que le matériel a un impact sur le SNR en fonction de la distance. A ce stade nous ne pouvons toujours pas déceler si le XBEE est géré par un microcontrôleur ATMEGA328P ou un ATMEGA2560.. Peut-être que l'étude du SNR selon le canal d'émission nous apportera des réponses?

Software : Il n'y a pas de différence notable à en sortir de l'expérience quant à la partie logicielle. Nous ne pouvons pas nous avancer sur l'influence du firmware sur la puissance du signal uniquement par cette expérience.

Expérience : Variation du Rapport Signal Bruit en fonction du canal de fréquence

L'expérience s'effectue de la même manière que précédemment. L'algorithme utilisé est le même. Néanmoins, nous verrons comme le SNR varie ici non pas en fonction de la distance mais en fonction du canal choisi. Pour celà, on choisira 3 canaux : le canal 0x11 (17), le canal 0x13 (19) et le canal 0x15 (21). En effet, ces canaux n'ont pas été choisis aléatoirement. Lors de nos études, on a observé le XBee Pro ne transmettait pas sur certains canaux particuliers.

Etait-ce dû à une erreur de manipulation ?

Afin d'être sûr, on a pris des canaux qui était communs aux deux modèles (série S1 et Pro).


ALLXBEE comparaison SNR freq.png

Contexte 1:

Les XBee1, XBee2, XBee3 et XBee4 sont connectés au PC et sont à 10 cm de l'antenne SDR.

Ils disposent du même firmware : 10ef

Les XBee transmettent d'abord sur le canal 0x11, sur le canal 0x13 et sur le canal 0x15



Résultats :

Il n'y a pas réellement de conclusion à tirer dans ce contexte. On ne fait que confirmer la différence de SNR entre le XBee de série S1 et le XBee Pro, différence qu'on observait déjà lors de l'expérience précédente.





XBEE1 hardware comparaison SNR freq.png

Contexte 2:

Les XBee1 est d'abord connecté au PC comme précédemment par shield. On le connecte par la suite à l'ATMega328p puis à l'ATMega2560. Il se trouve à 10 cm de l'antenne SDR.

Ils disposent du même firmware : 10ef

Les XBee transmettent d'abord sur le canal 0x11, sur le canal 0x13 et sur le canal 0x15



Résultats :

On observe que le rapport Signal Bruit lors de la transmission sur PC est supérieur au SNR transmis par l'ATMega328p et l'ATMega2560. On observe en plus une légère différence entre celui de l'ATMega328p et l'ATMega2560. La puissance des microprocesseurs se reflèterait-elle sur le signal ?





XBEE3 hardware comparaison SNR freq.png
XBEE4 SNR freq.png



Contexte 3:

Les XBee3 est d'abord connecté au PC comme précédemment par shield. On le connecte par la suite à l'ATMega328p puis à l'ATMega2560.

On réeffectue la même expérience avec le XBee4

Ils disposent du même firmware : 10ef

Les XBee transmettent d'abord sur le canal 0x11, sur le canal 0x13 et sur le canal 0x15



Résultats :

On observe la même chose que pour le contexte précédent, il y a une différence entre le SNR du XBee3 témoin et de celui relié aux micro-contrôleurs. L'erreur n'est pas à négliger, car la distance peut grandement influencer sur l'amplitude du signal. On considère une marge d'erreur de +-0,2cm lors de cette expérience, celà même si les résultats ne s'opposent à ceux du contexte précédent. Pour le XBee3 et XBee4, les phénomènes sont semblables. Celà nous conforte dans l'identité d'une identité électromagnétique pour un matériel.











Conclusion de l'expérience :

Après avoir comparé tous les graphes, on peut dire que systématiquement la puissance émise selon les canaux est la même pour chaque hardware : SNR_série > SNR_ATMEGA2560 > SNR_ATMEGA328 Cependant, les courbes ne suivent pas un pattern caractéristique qui permettrait à l’aide à l’identification du matériel. Si par exemple deux XBEE émettent avec un hardware différent, on pourra seulement conclure « Les XBEE n’utilisent pas le même matériel pour émettre ». Dans un contexte particulier, on pourrait distinguer le nombre de modules sans néanmoins les identifier.


Code python utilisé pour l'étude du signal: 


def SNRStudy(name):
    tmp=scipy.fromfile(open(name+"_PhaseMeg"), dtype=scipy.complex64)

    f = open(name+"_SNR_Values","a")

    p=1
    size = tmp.__len__()
    magnitude = (numpy.real(tmp)).tolist()

    threshold=10

    P=0
    SNR_graph=[]
    SNR=[]

    win_sz=64

    if(size>=win_sz):
        for val in range(0,size-win_sz):

            if(val>=((size-win_sz)/100)*p): # Affiche l'état de l'étude
                print(str(p)+" %")
                p=p+1

            SNR_graph.append( 20*math.log((numpy.mean(magnitude[val + win_sz/2 : val + win_sz-1]))/(numpy.mean(magnitude[val+0 : val+win_sz/2-1])), 10) )

  

    size=len(SNR_graph)

    for i in range(1, size-1):
        if (SNR_graph[i]>SNR_graph[i-1] and SNR_graph[i]>SNR_graph[i+1] and SNR_graph[i]>threshold):
            SNR.append(SNR_graph[i])


    tmp=numpy.asarray(SNR)
    tmp.tofile(f)


def main():
    try:
        SNRStudy(sys.argv[1])
    #except IndexError:
        #print("Donnez le nom du fichier\n")
    except IOError:
        print("Le fichier n'existe pas\n")

Conclusion du projet

Durant ce projet, nous avons cherché à determiner l'impact potentiel du matériel et informatique sur le champ électromagnétique. Dans l'idée commune, le signal émis par une antenne de même type est censé être le même, afin de le démoduler correctement au niveau de la reception. Néanmoins, il est très rare d'un point de physique d'avoir des signaux parfaitement identiques et celà dans les mêmes conditions expérimentales.

On a pu voir que de nombreux facteurs témoignaient de potentielles - et il est important de souligner le terme potentielles - caractéristiques uniques provoquées non pas par l'antenne émettrice, mais par le matériel et/ou le logiciel. En effet, les conjectures émises en conclusion des expériences ne peuvent être validées de manière absolue, mais sont néanmoins la preuve d'une réelle influence du matériel et sont selon nous des pistes à développer (le modèle de boîte noire se rapporte à notre projet).

Dans le cadre de notre projet, c'est l'antenne XBee qui a été étudiée.

A l'issue de ces expériences, nous avons pu mettre en évidence de nombreux points :

- les signaux émis par les XBee respectent les caractéristiques temporelles et fréquentielles données par leur datasheet (première expérience)

- le firmware ne semble pas avoir pas de réel impact sur les signaux, ni sur la variation d'amplitude

- le SNR témoigne de la puissance d'émission de l'antenne et permet de distinguer un module XBee Pro d'un module Xbee Série S1, permet aussi de différencier les signaux (sans nécessairement les identifier) et présente un potentiel gap entre un signal émis directement par série et un signal émis par un Arduino.

- le temps de fragmentation d'un paquet transmis ainsi que le calcul du FCS montre un schéma pouvant potentiellement être unique à tout un chacun des composants.

Nous aurions pu faire d'autres expériences pour nous conforter sur nos positions, néanmoins, nous n'avions pas trouvé d'autres d'idées qui pouvaient être réalisées avec nos outils (la variation de l'amplitude du signal nous a montré que le HackRF n'est pas exempt de défaut).


Ce projet a été pour nous une expérience nouvelle. Là où la plupart des projets étaient plus orientés à la conception et la réalisation, avec un objectif bien défini, le notre lui était tout autre. En effet, l'approche était plus expérimentale et orientée vers la recherche.

Les premières pistes de ce projet, bien qu'elles ne soient pas à négliger, se basaient sur les fuites électromagnétiques dispersées par les différents composants électroniques et informatiques d'un système. Néanmoins, avec le matériel et les compétences actuelles, il nous aurait été difficile de mener à bien ce projet de recherche et de poursuivre nos idées. Ainsi, le fait d'étudier les signaux directement par canal direct et non annexe (pas de CEM), nous permettant de chercher des potentielles caractéristiques uniques (le terme utilisé étant les clés) était donc la piste privilégiée.

La difficulté n'en était pas amoindrie. De nombreux obstacles devaient être franchis.

Tout d'abord, il nous a été nécessaire de nous initier à la radio logicielle, qui était l'outil principal pour mettre en oeuvre nos idées. Néanmoins, hormis dans le cadre de la démodulation de signaux et dans celui du Hacking (attaque radio, par replay etc...), il y a très peu de documentation au niveau de la radio logicielle et reste un domaine peu accessible au grand public (matériel et conditions d'acquisition obligent). Le procédé de recherches et les expériences nous ont donc été propre.

Ce qui nous mène à la seconde difficulté : la mise en place du protocole de recherche. La caractérisation d'un signal ou d'une empreinte propre necessite de faire des tests qui peuvent mener ou alors à des pistes intéressantes voire concluantes, ou alors à des echecs.

Dans notre cas, tout ne nous permettait pas de développer le sujet. La rencontre de Etienne Helluy Lafont a été pour nous d'une grande aide et nous a permis de savoir si les pistes qui avaient été développées étaient pertinentes ou non.

Documents Rendus

L'archive des scripts et codes utilisés :

Fichier:Scripts.zip


Le rapport

Fichier:Rapport projet P70 2019.pdf

Bibliographie et liens

Datasheet XBee : https://www.sparkfun.com/datasheets/Wireless/Zigbee/XBee-Datasheet.pdf

Wiki GNURadio : https://wiki.gnuradio.org/index.php/Main_Page

Documentation Doxygen GNURadio (prototypes des fonctions python) : https://www.gnuradio.org/doc/doxygen/

HackRF One: https://greatscottgadgets.com/hackrf/

Récupérée de « https://projets-ima.plil.fr/mediawiki/index.php?title=IMA4_2018/2019_P70&oldid=76043 »