Réalisation d'une chambre anéchoïque
Sommaire
Présentation générale
- Nom du projet : Réalisation d'une chambre anéchoïque de mesure
- Stagiaire : Souheib KHINACHE
Projet
Le sujet
L'objectif de ce projet est de concevoir une mini-chambre anéchoïque qui nous permettra la mesure de l'empreinte électromagnétique d'un objet connecté. En effet, l'atout d'une chambre anéchoïque est de proposer une certaine isolation vis à vis des perturbations et du bruit ambiant, que ce soit de l'extérieur (signaux étrangers parasites etc...), comme de l'intérieur (reflexion électromagnétique). Ainsi, les signaux d'un objet connecté peuvent être étudiés et analysés de manière optimale, et ainsi nous pouvons proposer par la suite la mise en place d'une "fiche caractéristique" d'un objet connecté liée à son empreinte électromagnétique.
Il est donc nécessaire d'avoir un recul sur la partie physique (la structure de la chambre anéchoïque, la dimension du matériau absorbant...), mais aussi et surtout sur la partie analyse électromagnétique (réalisation d'une sonde).
Cahier des charges
Contexte :
Le marché des objets connecté est un marché récent et en plein essor. La communication entre les différents objets s'établit de différents moyens, tissant une toile d'informations dans notre environnement. La technologie sans-fil s'impose dans le quotidien et il est difficilement possible de s'imaginer un avenir sans qu'ils y aient une influence. Ils ont le point commun de créer un nuage électromagnétique environnant, support de l'information. Néanmoins, hormis pour la phase de modulation/démodulation du signal, la couche physique n'est pas réellement utilisée comme source d'information. En outre, les objets connectés 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, influence le schéma électromagnétique, et peuvent influencer l'information certes, mais aussi le support de transmission.
C'est donc cette influence sur ce support de transmission (ici le champ électromagnétique) qui sera étudiée.
Objectif :
L'objectif est de concevoir une chambre anéchoïque qui permette l'analyse et l'étude d'un objet connecté. Il y aura donc un travail d'un point de physique (conception de la structure en fonction du signal, matériau etc...) et un travail de traitement de signal.
Ces études pourront être suivies directement sur un navigateur et les empreintes électromagnétiques enregistrées dans une base de données, afin de pouvoir approximer si possible la possibilité de la reconnaissance matériel par étude du champ électromagnétique.
Besoins fonctionnels :
Afin de pouvoir mener à bien le projet, le matériel nécessaire à l'étude :
- une antenne et un module Radio Logicielle (ou SDR) afin de traiter le signal reçu : ce qui sera utilisé est un HackRF. En effet, c'est l'une des SDR les plus disponibles sur le marché, assez documentée et compatible avec de nombreux utilitaires,
- de protection ou absorbeur électromagnétique,
- de matériau pour la structure de chambre anéchoïque,
- d'objets connectés à utiliser pour les tests,
- d'un ordinateur.
Une éventualité est d'intégrer un module Raspberry avec une distribution Linux compatible mais tout dépend de l'avancement du projet.
Contraintes :
L'une des contraintes principales à étudier est la limitation matérielle pour la chambre anéchoïque. En effet, la forme et la structure des absorbeurs dépendent des ondes émises par l'objet test. Il est donc nécessaire de trouver et choisir correctement les matériaux et de dimensionner correctement la chambre anéchoïque pour prévenir au mieux des signaux parasites.
Ce qui nous mène à une seconde contrainte : les perturbations électromagnétiques. Bien que l'objectif est de prévenir ces perturbations, la partie analyse et traitement de signal se fera avant l'élaboration de la chambre, et donc dans un environnement portentiellement sujet au bruit (reflexion électromagnétique de l'objet, perturbations parasites...).
Résultats attendus :
L'objectif final serait d'obtenir une structure fonctionnelle, que ce soit d'un point de physique comme analyse, le plus autonome possible et intuitif quant à son utilisation.
Etudes
Aspect matériel : caractéristiques physiques de la chambre anéchoique
La chambre anéchoique doit pouvoir mesurer l’empreinte électromagnétique d’un objet connecté et ainsi l’inscrire dans une base de données.
Mesure dans la bande ISM: 868 MHz et 2.4 - 2.5GHz
La réalisation d’une chambre anéchoïque nécessite l’utilisation d’un matériau absorbant de forme pyramidale. La forme de la structure pyramidale dépend de la longueur d’onde de l’onde à absorber afin de minimiser le bruit de reflexion.
La hauteur de la structure pyramidale doit être plus élevée que la moitié de la longueur d’onde du signal à recevoir, soit :
D’un point de vue matériau, la conductivité est équivalent à :
tel que L est la longueur du recouvrement, R la résistivité du matériau et S l’épaisseur du recouvrement.
La performance d’absorption est ainsi définie par :
A désigne le taux d'absorption de la chambre anéchoïque Le matériau utilisé pour la chambre anéchoique a aussi un impact sur la performance d’absorption. En effet, l’expérience effectuée à la figure 4 du document [1] montre qu’un absorbeur sans carbon est moins performant qu’un absorbeur avec carbone. Néanmoins, l’absorbeur chargé d’un complexe à base de carbone a un coût plus élevé.
L’épaisseur de l’absorbeur a un rôle déterminant quant à la performance d’absorption.
Dans notre cas, il s’agit de l’absorption dans les bandes ISM 868MHz et 2.4-2.5GHz.
Soit des longueurs d’ondes respectives de 34.5cm et 12.5cm
Les pyramides doivent donc avoir une hauteur de 18cm minimum pour prendre en compte les deux bandes de frequences.
Les différents critères d’identifications électromagnétiques
Les objets connectés peuvent être caractérisés par :
- la fréquence de la porteuse, permettant de savoir quel type d’antenne transmet l’information - la bande passante autour de la porteuse qui caractérise l’information à transmettre et le type de modulation par exemple - la taille du message (aspect temporel), qui caractérise le type de paquet à transmettre - le rapport signal-bruit, qui défini la puissance de transmission de l’antenne, et permet ainsi d’avoir un aperçu sur l’antenne
Ces caractéristiques permettent d’avoir une idée de quelle est l’antenne qui transmet l’information. Néanmoins, comment peut on avoir une idée l’aspect matériel antérieur à l’antenne ? Plusieurs possibilités, cependant à l’état expérimentales peuvent apporter une idée potentielle du matériel qu’il y a derrière l’antenne : - l’aspect CEM : les fuites électromagnétiques du matériel peuvent être un réel indice sur l’aspect informatique et electronique du module à étudier - le temps de calcul du FCS : à la suite du projet IMA4, il a été vu que le temps entre les fragments de paquets peuvent apporter des informations sur le matériel.
La démodulation est elle une piste intéressante à exploiter ?
Dans notre cas, la démodulation n'est pas une nécéssité quand à l'étude à faire mais peut être une piste. En effet, la démodulation se rapporte à l'information, et si l'objet n'est pas connu (on ne le suppose pas connu), le démoduler serait compliqué. Néanmoins la piste n'est pas à écarter.
Les utilitaires à utiliser
L’utilisation du langage Python ne permet d’avoir un système de capture optimal d’un point de vue performance.
Néanmoins GNURadio embarque directement un block module permettant d’étudier et d’interpréter les signaux.
D’autre part, il peut être intéressant d’utiliser la librairie SoapySDR qui permet d’interfacer les modules SDR (HackRF One dans notre cas).
Il s’agirait au cours de ce projet de constituer une chambre anéchoique qui puisse étudier l’empreinte d’un materiel connecté, de pouvoir le comparer à un ensemble d’empreintes installé dans une base de données, et obtenir un taux de similitude et ainsi permettre une possible reconnaissance matérielle.
Cette comparaison permettra de définir si l’objet fait partie de la base de données, le cas non-écheant, la chambre anéchoique enregistrera ses caractéristiques dans la base de données.
Elaboration du projet
Réalisation sur GNURadio
Le premier objectif que je vais me fixer est de balayer à l’aide du hackrf une large bande de fréquence afin de détecter les potentiels signaux.
Il est nécessaire d’imposer un treshhold qui n’est pas choisi aléatoire, qui plus est dans le cas d’une chambre anechoique.
Pour celà, je vais utiliser GNURadio, langage de blocs, auquel je combinerai mon analyse via python.
En effet, GNURadio propose un bloc utilitaire permettant d’implémenter un code python afin d’interpréter en quasi temps réel les signaux, le temps réel étant fondamental pour ce projet sachant que la chambre anéchoique doit analyser assez rapidement les signaux.
Pour celà, on établit une structure en blocs permettant et le balayage fréquentiel et la detection de signaux. Pour celà, le bloc Fonction Probe nous permet de capturer un signal et le stocker dans une variable.
Ce signal étant un nombre flottant, il représente la fréquence à étudier.
On construit le bloc Variable Frequency à partir du code python suivant :
"""
Fonction bloc permettant de translater la fréquence de capture
"""
import numpy as np
from gnuradio import gr
class blk(gr.sync_block):
def __init__(self, frequency_start=0.800e9, frequency_end=2.6e9, frequency_step=0.01e9): # Arguments par défaut
"""arguments to this function show up as parameters in GRC"""
gr.sync_block.__init__(
self,
name='Variable Frequency', # Intitulé du bloc
in_sig=None, # Pas d'entrée
out_sig=[np.float32] # Sort un signal flottant qui est la fréquence
)
assert (frequency_end > frequency_start), "Frequency End doit être supérieure à Frequency Start"
# if an attribute with the same name as a parameter is found,
# a callback is registered (properties work, too).
self.frequency_start = frequency_start
self.frequency_end = frequency_end
self.frequency_step = frequency_step
self.current_frequency = 0
def get_current_frequency(self):
return self.current_frequency
def work(self, input_items, output_items):
self.current_frequency = (self.current_frequency + self.frequency_step)%(self.frequency_end - self.frequency_start)
output_items[0][:] = self.frequency_start + self.current_frequency
return len(output_items[0])
A chaque appel du bloc, la fréquence est incrémentée du pas choisi en paramètre.
Le bloc Signal Detector quant à lui permet d'étudier et d'afficher les fréquences sur lesquelles un signal est reçu. Les paramètres à prendre sont un threshold à imposer afin de considérer qu'un signal est bien reçu :
import numpy as np
from gnuradio import gr
class blk(gr.sync_block): # other base classes are basic_block, decim_block, interp_block
"""Embedded Python Block example - a simple multiply const"""
def __init__(self, threshold=0.02, frequency=2.5e9): # only default arguments here
"""arguments to this function show up as parameters in GRC"""
gr.sync_block.__init__(
self,
name='Signal Detector', # will show up in GRC
in_sig=[np.float32],
out_sig=[np.float32]
)
# if an attribute with the same name as a parameter is found,
# a callback is registered (properties work, too).
self.threshold=threshold
self.frequency=frequency
def work(self, input_items, output_items):
"""example: multiply with constant"""
tmp_freq=self.frequency
mag_center_freq=input_items[0][0]
if(mag_center_freq > self.threshold):
print("Signal détécté à la fréquence : "+ str(tmp_freq) + " d'amplitude : " + str(mag_center_freq) )
return len(output_items[0])
L'algorithme est simple, et peut être amélioré. C'est ce que nous avons décidé de faire en mettant en place une FFT du signal.
Néanmoins, comme prévu, Python et GNURadio ne nous permettent pas d'avoir un signal temps réel et il y a un réel décalage entre ce qui reçu et l'étude. La FFT du signal en temps réel nécessite grandement l'appel du CPU qui plus est en schéma blocs associé à du Python.
Nous avions donc opté pour une seconde solution, celle de la capture, de l'enregistrement dans un fichier et de l'analyse post-capture.
Mais dans le contexte de la chambre anéchoïque, il n'était pas assez judicieux de faire du post-capture, surtout si ça prend plusieurs minutes.
Nous avons donc choisi d'utiliser la librairie SoapySDR, qui elle permet une réelle modulation au niveau langage, nous permettant ainsi d'implementer notre structure d'analyse en C et de gérer la mémoire et les flux d'informations de manière plus optimale.
Introduction à la librairie SoapySDR
La limitation imposée par GNURadio m’a conduit à changer de modèle et de travailler avec SoapySDR, librairie multi-langages et compatible avec plusieurs modules SDR, dont le HackRF. Ainsi, la structure d’analyse peut-être implémentée en C, ce qui est un réel plus-value dans notre cas. En effet, Python en plus de la couche logiciel offerte par GNURadio peuvent potentiellement rendre l’execution plus longue dû à la consommation du CPU. En outre, je suis plus familier avec le langage C, je saurai donc au mieux gérer les différentes problématiques. Il m’a fallut pas mal de temps (et de lecture de documentations) pour saisir les différentes subtilités de la librairie. En effet, contrairement à GNURadio, je n’avais pas l’habitude d’utiliser la librairie SoapySDR qui est assez complexe. J’ai donc réimplémenté le code de balayage fréquentiel et detection de signaux en C par le biais de la librairie SoapySDR. Après test, j’ai pu observé l’efficacité de la librairie via la vitesse d’execution.
Git de la librairie SoapySDR :
https://github.com/pothosware/SoapySDR/wiki
J’ai par ailleurs utilisé la librairie FFTW3, librairie permettant une approche efficace de la transformée de Fourier d’un signal :
Avant de poursuivre la partie traitement du signal, j'ai décidé de continuer l'étude de la chambre anéchoïque afin de la réaliser au plus vite
Etude de la chambre anéchoïque
Comme dit dans le cahier des charges, la chambre anéchoïque doit permettre d’effectuer la mesure sur un signal pouvant s’étaler sur un intervalle de fréquences de 850 MHz à 2.5GHz. En outre, elle doit isoler au mieux la capture des signaux extérieurs ainsi que des reflexions intérieures provoquées par les murs. En effet, nous devons tenir compte de nombreux critères vis à vis de la réalisation de la chambre. Bien qu’elle ne peut être parfaite, on essaiera de l’optimiser au mieux afin d’isoler au maximum le DUT (ou Device Under Test) des perturbations exérieures et intérieures.
Différents critères ont été étudiés, et je me suis basé sur des documents de recherches pour la définition de ces critères.
Le matériau de l’absobant
L’absorbant est la matière qui est contenue dans l’enceinte des chambres anéchoïques ou accoustiques que l’on trouve dans des lieux d’études, d’expérimentations ou scientifiques. Je devais définir le type d’absorbant à utiliser (le matériau), mais aussi la dimension. C’est en effet l’absorbant qui permet d’éviter la réflexion du signal sur les parois internes du mur. Après étude, j’ai opté pour un absorbant en polyurethane avec imprégnations de carbone, de forme pyramidale avec les dimensions suivantes :
Distance entre antenne émettrice et réceptrice
Afin d’optimiser la réception du signal, l’antenne réceptrice devrait se retrouver à la même hauteur que l’antenne émettrice sur le plan d’emission. Selon les documents étudiés, de nombreuses contraintes sont à prendre en compte, dépendant de la dimension de l’antenne et la longueur d’onde par exemple. En me basant sur les documents de recherches et les critères de Rayleigh et Fraunhoffer, j’en ai conclu que dans le cas d’un intervalle de fréquence dont la borne inférieure est égale à 868MHz, il faudrait une distance minimale de 172cm. La dimension de la structure devra prendre en compte cette distance.
La structure
La structure qui emboîte le tout devra elle absorber les ondes extérieures (ainsi que les potentielles ondes parasites restantes provenant de la reflexion intérieure) : il s’agit d’une structure disposant des mêmes caractéristiques qu’une cage de Faraday. De même que pour l’absorbant, le matériau et l’epaisseur définissent l’efficacité d’absorption de la cage. Ici, on prendra une structure en fer de 1mm d’épaisseur ou une structure en contreplaqué avec un tissu métallisé (0.1mm à 0.2mm). L’utilisation des joints au niveau des ouvertures permet d’éviter des pertes et des phénomènes de diffraction.
Ces caractéristiques définies, la boîte/chambre anéchoïque peut être maintenant réalisée.
Implémentation du processus de capture des signaux
Durant les semaines ayant suivies la conceptualisation de la boîte anéchoïque, je me suis focalisé sur l'élaboration et l'implémentation des scripts permettant la capture des signaux. Il ne s'agit pas là de capturer tout ce que l'antenne capte. Pour optimiser par la suite la reconnaissance de signaux, il est nécessaire de trier les données en amont. Pour celà, la capture se déroulera en trois étapes :
- on configure le module de capture
- on effectue balayage fréquentiel sur des intervalles fixés par l'utilisateur pour détecter un signal ou des signaux potentiels et on enregistre les fréquences pour lesquelles un signal est capté
- et on effectue un enregistrement plus long en se fixant sur les fréquences où un signal a été détecté.
Bien que sur le papier ces étapes peuvent paraître triviales, ça n'est pas le cas. En effet, en fonction de la fréquence d'échantillonage du signal, la capture de signaux peut conduire à des problématiques systèmes sur la gestion de certaines ressources (CPU, écriture sur le disque...), et il est nécessaire d'optimiser au mieux cette phase de balayage, sinon l'abandon de l'utilitaire GNURadio au profit de la librairie Soapy perd de son sens.
Configuration du HackRF
La librairie SoapySDR permet de configurer le HackRF afin qu'il puisse répondre aux contraintes imposé par le cahier des charges.
Avant de démarrer la configuration du module SDR, la librairie doit pouvoir le reconnaître. Soapy est une librairie open-source, et il est libre à tout utilisateur ou producteur de rendre compatible son antenne SDR avec elle. Il est nécessaire de disposer d'un plugin propre à l'antenne SDR si il est existant, ce qui est le cas pour le HackRF. Le plugin est accessible via le repertoire Git suivant :
https://github.com/pothosware/SoapyHackRF
git clone https://github.com/pothosware/SoapyHackRF.git cd SoapyHackRF mkdir build cd build cmake .. make sudo make install
L'installation des utilitaires faîte, il est temps de passer à la configuration du module.
SoapySDR permet de lister les différents modules SDR connectés au système. On vérifie tout d'abord que notre HackRF One est bien visible par la librairie en listant l'ensemble des Devices via la fonction SoapySDRDevice_enumerate.
A partir du nom du drive utilisé comme critère de recherche, on associe notre module HackRF.
On génère un handle vers le device choisi à partir des caractéristiques données SoapySDRDevice_make.
Ceci étant fait, on définit les différents paramètres : fréquence de capture (échantillonage du signal), la bande passante de capture, la fréquence, le gain et le mode de gain. Les fonctions de configuration du module HackRF sont intuitives, simples à utiliser et de la forme :
SoapySDRDevice_set[Parameter]([DeviceHandle], [RX/TX], [Channel], [Value], ...)
Si le module SDR le permet, SoapySDR gère le full-duplex et permet d'emettre et recevoir en même temps via différents flux. Dans notre cas, un flux à la réception suffit. Il faut le créer avec la fonction SoapySDRDevice_setupStream, fonction qui retourne un pointeur de type SoapySDRStream* et on active ce même flux via SoapySDRDevice_activateStream.
Balayage fréquentiel
Le système balaye les fréquences indiquées par l'intervalle ou les intervalles définis par l'utilisateur. Il peut décider de balayer l'intégralité de la bande au dessus de 868MHz (dans les limites du modules SNR), comme il peut très bien ne prendre qu'une partie de cette intervalle. Pour celà, on a défini une fréquence de balayage, qui permet de définir combien de temps le module doit rester sur la même fréquence avant de basculer à celle qui suit. Le pas fréquentiel lui aussi est défini comme constante et peut être modifié (ce qui serait intéressant serait de permettre à l'utilisateur de choisir la fréquence de balayage et le pas via des arguments lors de l'execution du programme de détection de signal).
Une fois la fréquence configurée dans le module, on effectue la FFT (Fast Fourier Transform) du nombre d'échantillons défini par le biais de la librairie FFTW3.
Le signal étant un nombre complexe, la FFT l'est aussi. Les complexes gérés par FFTW sont 2 tableaux de 2 double, soit 4 fois la taille d'un double. On défini un plan pour la FFT via la fonction fftw_plan_dft_1d et on execute la FFT sur le plan défini avec fftw_execute à chaque fois en cas de besoin afin de la mettre à jour (la FFT prend en paramètres un pointeur d'entrée et de sortie qui sont respectivement les échantillons du signal et ce qui sera la FFT).
Si la moyenne de la FFT se situe au dessus du threshold défini, on considère la présence d'un signal potentiel et on enregistre la fréquence dans un tableau.
Enregistrement des signaux
Une fois le processus de balayage effectué, on procède à la phase d'enregistrement des signaux. A partir du tableau de fréquences établi, on enregistre pour une durée X l'environnement électromagnétique en se plaçant sur chacune des fréquences définies auparavant. Pour lire le flux et stocker son contenu, on utilise la fonction SoapySDRDevice_readStream.
Afin d'éviter les pertes de vitesse lors de l'exécution du programme, on doit éviter d'écrire en continu dans le disque dur. On sera sinon confronté à un problème d'overflow. En effet, si le flux de capture est actif et n'est pas lu assez rapidement, le buffer dans lequel sont enregistrés les échantillons du signal n'est pas vidé et les données sont écrasées, ce qui conduit à une perte de précision. Pour éviter celà :
- on stocke les échantillons dans la RAM pendant la durée de la capture,
- une fois celle-ci terminée, on désactive le flux,
- on vide la mémoire,
- on écrit dans le disque,
- on change de fréquence,
- et on réactive le flux...
On effectue ceci pour toutes les fréquences détéctées.
Pour une fréquence d'échantillonnage de 10MHz et pour une durée d'une seconde, on peut atteindre un fichier de taille conséquente. Il est donc nécessaire de faire attention à la durée de la capture.
Analyse de signaux via Machine Learning
Il existe de nombreux critères d'identification d'un signal : la fréquence de la porteuse, de l'information et le type de modulation s'il s'agit d'un signal modulé, son rapport signal-bruit, le temps de transmission du signal etc...
Ces critères peuvent être intéressants à étudier. Mais humainement parlant, il est difficile de définir un profil de signal juste à la vue de son spectre fréquentiel ou temporel. Un signal contient de nombreuses informations et il est très probable que dans le cadre d'une étude, certaines seront omises.
Pour palier à celà, on va définir une machine d'apprentissage qui, à partir d'une banque de données en entrée, va essayer de définir ou catégoriser le signal d'étude. Le principe de Machine Learning va nous permettre à partir d'une étude statistique de répondre à cet objectif.
Préparer nos données d'études
Tout d'abord, les données qui nous servent de base doivent être correctement organisées. Chaque échantillon d'étude doit faire la même taille. L'apprentissage dans notre cas est supervisé : chaque échantillon de la base de données est connu et est associé à une empreinte (Type de modulation, bande passante etc...). On va tout d'abord sectionner le signal et ne garder que les zones où il y a un signal (retirer toutes les zones mortes et garder les zones pour lesquelles l'amplitude du signal est supérieure à un threshold) afin d'alléger les données.
On séparera les différentes sections du signal par un échantillon dont l'amplitude est nulle. En effet, ces sections seront divisées en sous-sections dont chacune est de taille X. Afin de minimiser les erreurs d'étude, l'échantillon nul permet de ne pas avoir de sous-section chevauchant deux sections de signal. Les sous-sections que des signaux continus.
