IMA4 2018/2019 P70
Sommaire
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
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 ?
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.
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 nos 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 | Total |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Analyse du projet | 3 | 8 | 0 | 0 | 0 | 0 | 0 | x | ||||
| Recherches | 1 | 3 | 3 | 3 | 6 | 3 | 3 | x | ||||
| Prise en main de GnuRadio | 0 | 4 | 4 | 4 | 3 | 2 | 3 | x | ||||
| Configuration Xbee | 0 | 2 | 2 | 1 | 1 | 2 | 2 | x | ||||
| Total | 4 | 15 | 9 | 8 | 7 | 8 | 8 | x |
Prologue
Semaine 1
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 :
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 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.
Semaine 3
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.
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
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.
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.
Le XBee 1 émetteur directement connecté en série au PC
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 14, soit la fréquence centrale est à 2.420GHz selon la norme Zigbee.
Etude fréquentielle
L'étude fréquentielle est similaire à celle réalisée auparavant.
Tout d'abord, on peut observer sur l'analyseur de spectre GNURadio que la fréquence centrale est située 2.450GHz. Nous n'avons pas trouvé la raison mais il s'agit sûrement d'un décalage au niveau applicatif.
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
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.
Nous avons décidé d'enregistrer ces données brutes dans un fichier et nous l'avons étudier 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).
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 :
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.
// À continuer : calculs pour connaître la taille du paquet à partir du signal //
Semaine 8
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 :
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.
Néanmoins, 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.
