Voir la source de Réalisation d'une chambre anéchoïque

__TOC__
<br style="clear: both;"/>

=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 ==

[[Fichier:AnechoicChamber.jpg|thumb|400px|Petite Chambre Anéchoique]]

<U> Aspect matériel : caractéristiques physiques de la chambre anéchoique</U>

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 : 

<center><math>H \ge \lambda/2</math></center>

D’un point de vue matériau, la conductivité est équivalent à :
							
<center><math>\sigma = L/RS </math></center>

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 :

<center><math> A (dB) = P_{TX(dBm)} - P_{RX(dBm)} </math></center>

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.



<U> Les différents critères d’identifications électromagnétiques </U>


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.


<I> La démodulation est elle une piste intéressante à exploiter ? </I>

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.



<U> Les utilitaires à utiliser </U>

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 ===

[[Fichier:Gnuradio.png|thumb|400px|left|Structure en bloc du programme de balayage de fréquences]]
[[Fichier:Freqdetect.png|thumb|400px|left|Signal détécté à la fréquence 2.48GHz à 2.52GHz pour une bande passante de capture de 10MHz]]

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 : 

 <nowiki>

"""
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])

</nowiki>


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 : 


 <nowiki>

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])

</nowiki>


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.



=== 

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.