IMA4 2016/2017 P32

De Wiki de Projets IMA
Révision datée du 19 avril 2017 à 14:13 par Amachere (discussion | contributions) (Semaine 9)

Cahier des charges

Présentation générale du projet

Contexte

L'expansion de l'utilisation des objets connectés permet de nos jours d'accéder à des données ou de contrôler aisément d'autres systèmes connectés à distance. Les objets connectés sont de plus en plus déployés mais leur sécurité n'est pas toujours testée. Par conséquent, de nombreuses informations sensibles sont susceptibles de transiter en permanence par le biais de multiples plages de fréquences.


Ceci amène donc un questionnement sur la sécurité des transferts de données entre la multitude d'objets connectés actuellement.


Objectif du projet

L'objectif de ce projet est de réaliser un brouilleur d'ondes radiofréquence dans la bande des 868 MHz capable de bloquer les communications LoRa.


Description du projet

A l'aboutissement du projet, nous devrions être capable de détecter une communication LoRa dans la bande des 868 MHz, et de la brouiller elle seule, sans incidence sur les autres communications sur d'autres fréquences du réseau LoRa.

Pour ce faire, nous devrons réaliser un montage réalisant un brouillage sur la plage 863-870Mhz afin d'empêcher toute communication LoRa, en envoyant du bruit électronique sur toute la plage de fréquence.

Pour la suite du projet, nous perfectionnerons ce montage pour qu'il puisse détecter une communication LoRa à une fréquence donnée (grâce au "join-request message" de 18 octets envoyés par le end-point/node, ou bien grâce aux informations données dans le préambule des paquets), afin d'envoyer des données erronées et de bloquer uniquement cette communication.

Si le temps et le budget le permettent, nous pourrons aussi être amenés à brouiller la plage de fréquences autour des 433 MHz (aussi utilisé par le réseau LoRa).

Choix techniques : matériel et logiciel

Afin de réaliser ce système, nous allons utiliser un microcontrôleur cc430 muni d'un transceiver cc1101, d'un récepteur LoRa(868MHz) communicant via protocole SPI avec le microcontrôleur, 2 antennes, une batterie, quelques LEDs.

Calendrier prévisionnel

Liste des tâches à effectuer

  1. Documentation sur le réseau LoRa
    1. moyen de transmission
    2. format de modulation
    3. trame des paquets
  2. Réalisation du premier montage brouillant toute la plage
    1. contrôler l'émetteur RF du cc430
    2. programmer un bruitage sur la plage 863-870MHz
    3. test et optimisation
  3. Ajout d'un récepteur LoRa pour détecter et brouiller une seule communication
    1. contrôler le récepteur LoRa avec le cc430 par protocole spi
    2. détecter une communication LoRa à une fréquence donnée
    3. contrôler l'émetteur RF afin de brouiller cette communication de manière brutale
    4. brouiller cette communication en tentant de changer les données du paquet
    5. test et optimisation

Calendrier

Avant le 19/12/16 - Élaboration du Cahier des charges et remplissage du Wiki

Avant fin Janvier - Complément du Cahier des Charges et listage du matériel nécessaire pour le projet

Répartition sur le S8 - 120h: Réalisation de la 1ere fonction (45h) / Réalisation de la 2e fonction (45h) / Test et débuguage (30h)

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
Cahier des charges / Wiki 4h 2h 3,5h 4h 1h 1h
Documentation sur le réseau LoRa 6h 1,5h 2h
1ère fonction 2h 1h 8h 6h 6h
2ème fonction
Test et débuguage 1h 1h 1h

Avancement du Projet

Phase préparatoire

Jeu 15/12/16

  • Rendez-vous de mise au point du cahier des charges avec les trois encadrants (M. Boé, M. Vantroys et M. Redon)
  • Elaboration du cahier des charges

Semaine 1

23/01/17 - 29/01/17

  • Revue du Cahier des Charges
  • Recherches approfondies sur les modes de transmissions du réseau LoRa
  • Recherche de matériel

Semaine 2

30/01/17 - 05/02/17

  • Précisions sur le cahier des charges
  • Listage du matériel
  • Recherche et détermination de solutions technologiques possibles pour les fonctions demandées

Semaine 3

06/02/17 - 12/02/17

  • validation du matériel

Nous allons utiliser un cc430f5137 (MCU+RF) monté sur une carte optimisée pour les communications autours de 868Mhz. Nous pouvons commencer à étudier son fonctionnement, particulièrement celui du module RF (cc1101). Nous avons aussi récupéré des exemples de code en c sur le site de Texas Instrument et d'un projet IMA5 de l'an passé.

Semaine 4

13/02/17 - 19/02/17

  • Recherche de solutions pour répondre à la 1ère fonction (brouiller la plage 863-870Mhz).

Après une lecture approfondie de la datasheet du module RF du cc430, nous avons choisi d'utiliser la fréquence de base du module (pouvant être définie grâce aux registres) couplée au registre CHANNR. Cela nous permettra de modifier plus facilement la fréquence de la porteuse, en suivant la formule suivante : Rampe.png.

Nous pourrons alors balayer la plage de fréquence en changeant la valeur de CHANNR.

Semaine 5

27/02/17 - 05/03/17

A l'aide de la datasheet du cc1101 (datasheet_cc1101 pages : 70 à 95), nous avons défini les registres du module RF de la manière suivante (sachant que la fréquence du quartz est de 26MHz, soit Fxosc=26MHz) :

  • La fréquence de base a été fixée à 862,999MHz en suivant la formule donnée dans la data sheetCarrier formula.png

ce qui nous a donné les valeurs FREQ2=0x21, FREQ1=0x31 et FREQ0=0x3A (FREQ=2 175 290).

  • Nous avons suivi la formule Chanspace formula.png afin d'avoir un espacement entre les cannaux d'environ 100Khz

ce qui nous a donné MDMCFG1=0x02 (CHANSPC_E=2) et MDMCFG0=0x00(CHANSPC_M=0).

  • Pour le moment, nous avons choisi le mode de modulation AM, nous avons donc initialisé les registres MDMCFG2=0x30 (mode ASK/OOK) et FREND0=0x50(patable=0 donnant le mode ASK).
  • Nous avons créé une bibliothèque RFconfig.h regroupant les valeurs de tous les registres :


#include <cc430f5137.h>
#include <stdint.h>
#include <msp430.h> 

//863-870Mhz => 26MHz crystal and high VCO recommended

//MDMCFG0.CHANSPC_M=0 & MDMCFG1.CHANSPC_E=2 ==> chann spacing~100kHz

//start at 863 Mhz stop at 870
//FREQ=00 10 00 01 00 11 00 01 00 11 10 10
//FREQ2=0x21   FREQ1=0x31   FREQ0=0x3A
//CHANNR from 0 to 69 


#define SMARTRF_CC430F5137_H
#define SMARTRF_RADIO_CC430F5137

#define SMARTRF_SETTING_IOCFG2     0x29 //default 
#define SMARTRF_SETTING_IOCFG1     0x2E //default
#define SMARTRF_SETTING_IOCFG0     0x02 //assert if TX fifo above trsh
#define SMARTRF_SETTING_FIFOTHR    0x07 //default (0x0F may be better)
#define SMARTRF_SETTING_SYNC1      0xD3 //default
#define SMARTRF_SETTING_SYNC0      0x91 //default
#define SMARTRF_SETTING_PKTLEN     0xFF //default (disabled by PKCTRL0 set to 0x05)
#define SMARTRF_SETTING_PKTCTRL1   0x04 //default
#define SMARTRF_SETTING_PKTCTRL0   0x05 //normal pkt format, variable pkt lenght
#define SMARTRF_SETTING_ADDR       0x00 //default (device address)
#define SMARTRF_SETTING_CHANNR     0x00 //0 (will be incremented in main.c)
#define SMARTRF_SETTING_FSCTRL1    0x0F //default (IF frequency)
#define SMARTRF_SETTING_FSCTRL0    0x00 //default (freq offset)
#define SMARTRF_SETTING_FREQ2      0x21 /*freq*/
#define SMARTRF_SETTING_FREQ1      0x31 //868Mhz
#define SMARTRF_SETTING_FREQ0      0x3A /*freq*/
#define SMARTRF_SETTING_MDMCFG4    0x8C //default (BW=203KHz)
#define SMARTRF_SETTING_MDMCFG3    0x22 //default (data rate)
#define SMARTRF_SETTING_MDMCFG2    0x30 // ASK/OOK,no sync-word
#define SMARTRF_SETTING_MDMCFG1    0x02 // 2 bytes preamble, chanspc_e=2
#define SMARTRF_SETTING_MDMCFG0    0x00 //chanspc_m=0
#define SMARTRF_SETTING_DEVIATN    0x47 //default (no effet on ASK/OOK mode)
#define SMARTRF_SETTING_MCSM2      0x07 //default timeout disable
#define SMARTRF_SETTING_MCSM1      0x18 //stay in TX mode
#define SMARTRF_SETTING_MCSM0      0x18 //autocal when going in TX or RX
#define SMARTRF_SETTING_FOCCFG     0x36 //default (frenquency offset not used)
#define SMARTRF_SETTING_BSCFG      0x6C //default
#define SMARTRF_SETTING_AGCCTRL2   0x03 //default (maximum possible gain)
#define SMARTRF_SETTING_AGCCTRL1   0x40 //default
#define SMARTRF_SETTING_AGCCTRL0   0x91 //default
#define SMARTRF_SETTING_WOREVT1    0x87 //default
#define SMARTRF_SETTING_WOREVT0    0x6B //default
#define SMARTRF_SETTING_WORCTRL    0xF8 //default
#define SMARTRF_SETTING_FREND1     0x56 //default
#define SMARTRF_SETTING_FREND0     0x50 //patable=0 -> ASK
#define SMARTRF_SETTING_FSCAL3     0xE9 //smartRF studio
#define SMARTRF_SETTING_FSCAL2     0x2A //high VCO choosen
#define SMARTRF_SETTING_FSCAL1     0x00 //smartRF studio
#define SMARTRF_SETTING_FSCAL0     0x1F //smartRF studio
#define SMARTRF_SETTING_FSTEST     0x59 //default (test only)
#define SMARTRF_SETTING_PTEST      0x7F //default (test only)
#define SMARTRF_SETTING_AGCTEST    0x3F //default (test only)
#define SMARTRF_SETTING_TEST2      0x81 //smartRF studio
#define SMARTRF_SETTING_TEST1      0x35 //smartRF studio
#define SMARTRF_SETTING_TEST0      0x0B //default

Semaine 6

06/03/17 - 12/03/17

  • Nous avons préparé un premier code réalisant une rampe sur la plage 863-870MHz. Ce code est basé sur une boucle infinie qui incrémente le registre chann de 0 à 69 (pour passer de 863 à 870Mhz) et envoie des paquets 0xFF grâce aux fonctions ChangeChannel(chann) et send_comand().
#include <msp430.h>
#include <stdint.h>

#include "RF1A.h"
#include "RF_Connection.h"
#include "PMM.h"
#include "ports.h"
#include "RFconfig.h"

#define BUFFER_SIZE		1	// maximum size of data sent by rf

#define PWM_PERIOD		255
#define DELAY 10000


volatile uint8_t buffer[BUFFER_SIZE];
volatile uint8_t temp[NB_BANGLES][2];
volatile uint8_t fin[NB_BANGLES][NB_BANGLES-1];

//useless
void packet_received(void)
{

}


void send_cmd(void)
{
  buffer[0] = 0xFF;
  rf_transmit((uint8_t *)buffer, 2);
}

int main(void)
{
  unsigned char chann=0x00;
  WDTCTL = WDTPW + WDTHOLD;   // Stop WDT
  rf_init();
  ReceiveOff();
  _BIS_SR(GIE);	 

  while(1)
    {
      ChangeChannel(chann);
      send_cmd();
      if(chann>=69) 
	{
	  chann=0x00;
	}
      else
	{
	  chann++;
	}
      __delay_cycles(DELAY);
    }
  return 0;
}


  • Après quelques corrections du code nous avons pu le compiler grâce au Makefile.
  • Avec la commande (exécutée en root) et le montage suivants, nous avons upload le main sur le cc430.
mspdebug rf2500 "prog main"

Montage001.png

Semaine 7

13/03/17 - 19/03/17

Nous avons commencé les premiers tests sur l'analyseur de spectre afin de vérifier que le code fonctionne bien.

  • Dans un premier temps, nous avons essayé une fréquence fixe pour voir la calibration du cc430.

862.png Avec un exemple à 862Mhz, on remarque bien que les registres ont bien été initialisés et que la carte émet à la fréquence demandée.

  • Ensuite nous avons testé le code effectuant le balayage sur la plage de fréquence 863-870Mhz, en augmentant le sweep time de l'analyseur de spectre pour voir les différentes fréquences auxquelles la carte émet.

Sweep.png En observant de 861 à 872 Mhz sur l'écran de l'analyseur, on peut voir que le code effectue bien le balayage.

  • La puissance d'émission de la carte étant faible, nous avons essayé de l'augmenter en modifiant certains registres notamment ceux que l'on peut optimiser à l'aide du logiciel smart RF studio. Cependant, nous pensons qu'il faudra changer l'antenne patch actuelle de la carte pour une antenne SMA.
  • Nous avons aussi tenter de brouiller les communications d'autres groupes de projet utilisant des modules LoRa. Ces derniers étant configuré à 433Mhz nous avons dû changer la fréquence de notre carte. Le brouillage ne fonctionnait pas mais notre carte étant optimisée pour une émission autour de 868Mhz, les résultats n'étaient pas pertinents.

Semaine 8

20/03/17 - 26/03/17

  • Nous avons emprunté 3 modules SX1276 monté sur une carte NUCLEO-F401RE à M. Vantroys afin de pouvoir tester notre carte sur une communication LoRa à 868Mhz

Lorambed.png

  • Le code utilisé pour le test a été récupéré sur le forum des développeurs du site mbed.com. C'est un code "ping pong" effectuant une communication continue entre deux modules LoRa à une fréquence de 868Mhz. Il nous a suffit d'utiliser le compilateur du site (qui regroupe toutes les bibliothèques nécessaires) en indiquant que la carte utilisée est une F401RE pour que le binaire produit soit compatible. La carte NUCLEO étant reconnu comme un système de fichier par linux, pour la flasher il faut la monter en usb à l'aide des commandes fdisk et mount puis de copier le binaire dedans avec la commande cp.

Fichier:Lora pingpong.zip

  • Une fois les modules NUCLEO flashés, la communication LoRa est établie dès que deux modules sont alimentés. Nous avons donc branché en usb deux modules sur deux machines différentes afin d'observer la communication dans des terminaux. La communication se fait bien, l'un envoie "ping" tandis que l'autre envoie "pong" lorsqu'il reçoit "ping". Malheureusement, comme nous l'avions prédit, notre carte a une puissance d'émission trop faible et ne parvient pas à brouiller.
  • Après plusieurs changements dans le code du cc430, n'ayant pas de résultats positifs, nous avons diminuer la puissance d'émission des modules LoRa en changeant un header dans le code lora_pingpong.cpp. En passant cette puissance de 14dBm à 6dBm, nous sommes parvenus à brouiller la communication.

Semaine 9

27/03/17 - 02/04/17

  • Même si le brouillage ne s’effectue qu'à puissance réduite, nous avons cherché à l'optimiser.
    • Nous avons premièrement réalisé que le mode de modulation choisi au départ (ASK) n'était pas adapté au brouillage d'une communication LoRa. Nous avons donc essayé le mode GFSK qui est le plus proche du format de modulation du réseau LoRa. Nous avons aussi essayé les modes 2FSK et 4FSK qui sont relativement proches du GFSK. Nous en avons conclu que le mode de modulation à utiliser est GFSK.
    • Ensuite, nous avons réduit la plage de fréquence balayée par le cc430 afin de voir si il y avait une influence sur le brouillage. Nous avons remarqué que le brouillage était plus efficace pour un balayage de 866 à 870 Mhz (au lieu de 863-870 initialement)
    • Dans le même ordre d'idée, nous avons décidé de réduire le nombre d'incrémentations du registre CHANN afin d'augmenter la rapidité du balayage. Pour ce faire nous avons augmenté la taille de chaque canal, passant de 100kHz à 200kHz.
    • La puissance d'émission de la carte a été changé dans la fonction iuegc, afin d'être maximale
    • Enfin, nous avons augmenté le nombre de paquets à envoyé.

Nouvelle bibliothèque RFconfig.h :

#include <cc430f5137.h>
#include <stdint.h>
#include <msp430.h> 

//863-870Mhz => 26MHz crystal

//MDMCFG0.CHANSPC_M=0 & MDMCFG1.CHANSPC_E=2 ==> chann spacing~100kHz

//start at 863 Mhz
//FREQ2=0x21   FREQ1=0x31   FREQ0=0x3A
//high VCO FSCAL2=0x2A

//867 : 21589A
//866 : 214EC2
//865 : 2144EA


//for 433Mhz : freq=0x10A766 and low vco (FSCAL2=0x0A)
//432 : 0x109D8E

//gfsk, 866, chann space ~200k, high vco currently


#define SMARTRF_CC430F5137_H
#define SMARTRF_RADIO_CC430F5137

#define SMARTRF_SETTING_IOCFG2     0x29 //default 
#define SMARTRF_SETTING_IOCFG1     0x2E //default
#define SMARTRF_SETTING_IOCFG0     0x02 //assert if TX fifo above trsh
#define SMARTRF_SETTING_FIFOTHR    0x07 //default (0x0F may be better)
#define SMARTRF_SETTING_SYNC1      0xD3 //default
#define SMARTRF_SETTING_SYNC0      0x91 //default
#define SMARTRF_SETTING_PKTLEN     0xFF //default (disabled by PKCTRL0 set to 0x05)
#define SMARTRF_SETTING_PKTCTRL1   0x04 //default
#define SMARTRF_SETTING_PKTCTRL0   0x05 //normal pkt format, variable pkt lenght
#define SMARTRF_SETTING_ADDR       0x00 //default (device address)
#define SMARTRF_SETTING_CHANNR     0x00 // (will be incremented in main.c)
#define SMARTRF_SETTING_FSCTRL1    0x06 //default 0f (IF frequency)
#define SMARTRF_SETTING_FSCTRL0    0x00 //default (freq offset)
#define SMARTRF_SETTING_FREQ2      0x21 /*freq*/
#define SMARTRF_SETTING_FREQ1      0x4E //866
#define SMARTRF_SETTING_FREQ0      0xC2 /*freq*/
#define SMARTRF_SETTING_MDMCFG4    0x8C //default (BW=203KHz)
#define SMARTRF_SETTING_MDMCFG3    0x83 // data rate
#define SMARTRF_SETTING_MDMCFG2    0x13 // GFSK 
#define SMARTRF_SETTING_MDMCFG1    0x22 // 2 bytes preamble, chanspc_e=2
#define SMARTRF_SETTING_MDMCFG0    0xF8 //chanspc_m=248
#define SMARTRF_SETTING_DEVIATN    0x47 // default 47khz deviation
#define SMARTRF_SETTING_MCSM2      0x07 //default timeout disable
#define SMARTRF_SETTING_MCSM1      0x18 //stay in TX mode
#define SMARTRF_SETTING_MCSM0      0x18 //autocal when going in TX or RX
#define SMARTRF_SETTING_FOCCFG     0x36 //default (frenquency offset for demodulation)
#define SMARTRF_SETTING_BSCFG      0x6C //default
#define SMARTRF_SETTING_AGCCTRL2   0x07 // (maximum possible gain)
#define SMARTRF_SETTING_AGCCTRL1   0x77 //
#define SMARTRF_SETTING_AGCCTRL0   0x91 //default
#define SMARTRF_SETTING_WOREVT1    0x87 //default
#define SMARTRF_SETTING_WOREVT0    0x6B //default
#define SMARTRF_SETTING_WORCTRL    0xF8 //default
#define SMARTRF_SETTING_FREND1     0x56 //default
#define SMARTRF_SETTING_FREND0     0x10 //patable=0 (useless for gfsk) 
#define SMARTRF_SETTING_FSCAL3     0xE9 //smartRF studio
#define SMARTRF_SETTING_FSCAL2     0x2A //high VCO choosed
#define SMARTRF_SETTING_FSCAL1     0x00 //smartRF studio
#define SMARTRF_SETTING_FSCAL0     0x1F //smartRF studio
#define SMARTRF_SETTING_FSTEST     0x59 //default (test only)
#define SMARTRF_SETTING_PTEST      0x7F //default (test only)
#define SMARTRF_SETTING_AGCTEST    0x3F //default (test only)
#define SMARTRF_SETTING_TEST2      0x81 //smartRF studio
#define SMARTRF_SETTING_TEST1      0x35 //smartRF studio
#define SMARTRF_SETTING_TEST0      0x09 //

Nouveau main.c :

#include <msp430.h> 
#include <stdint.h>
#include "RF1A.h"
#include "RF_Connection.h"
#include "PMM.h"
#include "ports.h"
#include "RFconfig.h"
#include "led_commands.h"
#define BUFFER_SIZE		10	// maximum size of data sent by rf
#define PWM_PERIOD		255
#define DELAY 5000 //15ms  


volatile uint8_t buffer[BUFFER_SIZE];
volatile uint8_t temp[NB_BANGLES][2];
volatile uint8_t fin[NB_BANGLES][NB_BANGLES-1];
//useless
void packet_received(void)
{
}
// Any other commands are for RSSI measurement
void send_cmd(void)
{
  buffer[0] = 0xFD;
  buffer[1] = 0xAA;
  buffer[2] = 0xFF;
  buffer[3] = 0x11;
  buffer[4] = 0xFF;
  buffer[5] = 0x66;
  buffer[6] = 0xFF;
  buffer[7] = 0x33;
  buffer[8] = 0x1F;
  buffer[9] = 0xF8;
  rf_transmit((uint8_t *)buffer, 2);
}
int main(void)
{
  port_mapping();
  unsigned char chann=0x00;
  unsigned char led2=0x10;
  WDTCTL = WDTPW + WDTHOLD;   // Stop WDT
  rf_init(); //reset, setVcore & patable
  ReceiveOff();
  _BIS_SR(GIE);
  set_color(0x10, 0x00, 0x00, 0x00, 0x00, 0x00); //led 1 s'allume sous tension
  while(1)
    {
      ChangeChannel(chann);
      send_cmd();
      if(chann>=20) //866-870

{ chann=0x00; led2=led2^0x10; set_color(0x10, 0x00, 0x00, led2, 0x00, 0x00); //led 2 s'allume toutes les 2 rampes }

      else

{ chann++; }

      __delay_cycles(DELAY);
    }
  return 0;
}

Semaine 10

03/04/17 - 09/04/17

  • La puissance d'émission étant trop faible pour brouiller la communication entre les 2 modules LoRa, nous avons décidé de changer l'antenne de la carte. Il a fallu couper l'antenne patch à l'aide d'une scie afin de souder un connecteur SMA.

Cc430antenne.png

  • Grâce à cette nouvelle antenne, la communication peut maintenant être brouillée à une puissance de 10dBm (contre 6 auparavant). Mais il faut que la carte reste relativement proche d'un des modules.
  • Pour réussir le brouillage quand les modules LoRa sont à leur puissance maximale (14dBm), il faudra sûrement ajouter un amplificateur entre la sortie de la carte et son antenne.

Fichiers Rendus

Fichier:Code fonction 1.zip