P18 Localisation of quadrotors : Différence entre versions
(→Feuille d'heures) |
(→Avancement du Projet) |
||
| Ligne 278 : | Ligne 278 : | ||
===<span style="color:#4169E1">'''Phase préparatoire'''</span>=== | ===<span style="color:#4169E1">'''Phase préparatoire'''</span>=== | ||
| − | ''[[Jeu | + | ''[[Jeu 21/09/17 - Ven 22/09/17]]'' |
| − | *Rendez-vous de mise au point du cahier des charges avec les | + | *Rendez-vous de mise au point du cahier des charges avec les encadrants/intervenants (M. ZHENG Gang et M. DAGHER Roudy) |
*Elaboration du cahier des charges | *Elaboration du cahier des charges | ||
| + | *Elaboration de la page Wiki (préparation de la mise en page et présentation du sujet) | ||
| + | *Préparation du travail sous forme de Mind Map | ||
===<span style="color:#4169E1">'''Semaine 1'''</span>=== | ===<span style="color:#4169E1">'''Semaine 1'''</span>=== | ||
| − | ''[[ | + | ''[[28/09/17 - 29/09/17]]'' |
*Revue du Cahier des Charges | *Revue du Cahier des Charges | ||
| − | * | + | *Lecture et recherches sur les technologies adaptées |
| − | * | + | *Construction de la suite de la Mind Map |
| + | |||
| + | ////// | ||
===<span style="color:#4169E1">'''Semaine 2'''</span>=== | ===<span style="color:#4169E1">'''Semaine 2'''</span>=== | ||
Version du 28 septembre 2017 à 07:25
Cahier des charges
Présentation générale du projet
Contexte
Dans un monde de plus en plus connecté, de nombreux drones sont déployés pour diverses applications comme l'espionnage, la surveillance, la cartographie de lieux et la livraison de colis. Les technologies nécessaires pour contrôler ces drones sont des sujets de recherche actuels.
Le contrôle de ceux-ci passe tout d'abord par la maîtrise de leur position dans l'espace. Le développement des applications liées à l'utilisation de drones nécessite un travail important sur la localisation spatiale d'objets connectés.
De plus, dans un souci d'utilisation, il est essentiel de développer des interfaces logicielles permettant d'exploiter ces données.
Objectif du projet
L'objectif de ce projet est de développer une interface logicielle permettant de traiter en temps réel les informations de localisation d'un drone et de balises, dans le but de définir leur localisation dans l'espace, en intérieur.
Description du projet
Pour réaliser le contrôle de drones, la première étape importante est de donner ses informations de position. Le but du projet est de développer une interface logicielle permettant de localiser le drone en temps réel en intérieur. Le drone se déplace dans un environnement dans lequel ont été installées de multiples balises. Il est équipé d'une carte, lui permettant de recevoir les distances relatives entre lui-même et les balises, sur laquelle différents algorithmes vont être implémentés pour effectuer la localisation en temps réel. Le projet requiert des compétences en développement hardware (Crazyflie 2.0, voir https://wiki.bitcraze.io/) et software (langage C/C++/Python/Javascript/HTML...).
Il se divise en 4 étapes principales, qui sont:
- 1) Choisir les technologies utilisées
- 2) Choisir l'architecture (OS / APIs)
- 3) Développer les différentes parties du projet
- 4) Intégrer et connecter les différentes parties du projet
La localisation étant en intérieur, le protocole GPS n'est donc pas assez précis pour les applications ciblées. La mise en place d'un tel dispositif permettrait grâce à l'utilisation d'un algorithme d'estimer avec une bonne précision les positions en intérieur d'une balise centrale (appelée Tag) et de balises (appelées Anchor). Le Tag scanne en temps réel la distance relative aux différentes balises, et il nous est retourné la position des balises et du Tag grâce à l'algorithme de localisation.
Le projet se compose de 3 parties:
- Collect & parse: collecter les données envoyées par les balises en communiquant avec un serveur et récupérer les données adéquates par un tri
- Localise: déterminer la matrice de position des balises et du Tag en traitant les données récupérées
- Display: développer l'interface homme machine pour afficher, étudier et utiliser les données traitées
Nous travaillerons dans un premier temps dans une optique temps différé avant de travailler en temps réel. Cela nous permettra d'acquérir des données utiles et réutilisables en aval.
A l'aboutissement du projet, nous devrions être capable via l'interface homme machine développée d'afficher précisément la position spatiale des balises ainsi que du Tag, grâce àl'utilisation d'un algorithme de localisation et des données récupérées, et d'afficher d'autres données relatives au déplacement du Tag ou des balises dans l'espace.
Si le temps le permet, nous pourrons aussi être amenés à adapter et utiliser l'interface développée pour l'utilisation d'un drone.
Sujet originel
To achieve the control of quadrotors, the first important task to give its position information. This project is to develop a software(GUI) to localize the quadrotors in real-time. The quadrotor is flying in an environment where several transmitters have been installed. The quadrotor is equipped with a deck to receive the relative distances between the deck and all transmitters, based on which different algorithms will be implemented to realize the real-time localization. The candidates need to have both experiences on hardware (Crazyflie 2.0, see https://wiki.bitcraze.io/) and software development (C/C , Python…).
Calendrier
Avant le 29/09/17 - Élaboration du Cahier des charges, de la liste des tâches et du calendrier prévisionnel
Avant fin Octobre - Serveur de collecte et début du développement de l'interface logicielle
Avant fin Décembre - Interface logicielle
A la fin du PFE - Intégration finale des différentes parties (Serveur de collecte des données & Serveur de localisation & Interface logicielle)
Répartition du volume de travail (***h):
- Recherche sur les technologies à utiliser (**h)
- Développement du serveur de collecte de données (**h)
- Réalisation de l'interface logicielle (Web//Logiciel/Application) (**h)
- Intégration des différentes parties (**h)
- Test et débuguage (**h)
Choix techniques : matériel et logiciel
Afin de développer ce dispositif, nous allons utiliser une Raspberry Pi 3 associée à une carte réceptrice, qui communique avec 4 balises composées chacune d'un microcontrôleur et d'une carte émettrice radio (UWB5C) et alimentées par batteries. La carte réceptrice joue le rôle du drone à localiser et communiquera les données émises par les balises vers l'ordinateur via Bluetooth.
Calendrier prévisionnel
Liste des tâches à effectuer
A modifier
- Documentation sur le réseau LoRa
- moyen de transmission
- format de modulation
- trame des paquets
- Réalisation du premier montage brouillant toute la plage
- contrôler l'émetteur RF du cc430
- programmer un bruitage sur la plage 863-870MHz
- test et optimisation
- Ajout d'un récepteur LoRa pour détecter et brouiller une seule communication
- contrôler le récepteur LoRa avec le cc430 par protocole spi
- détecter une communication LoRa à une fréquence donnée
- contrôler l'émetteur RF afin de brouiller cette communication de manière brutale
- brouiller cette communication en tentant de changer les données du paquet
- test et optimisation
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 | Après les vacances | Total |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Cahier des charges / Wiki | 2h | 1h | 1h | 0,5h | 0,5h | 0,5h | 0,5h | 0,5h | 0,5h | 0,5h | 7,5h | ||
| Documentation sur le réseau LoRa | 2h | 4h | 1,5h | 4h | 11,5h | ||||||||
| Documentation sur le matériel | 1h | 3h | 2h | 3h | 1h | 1h | 1h | 12h | |||||
| Recherche de solution pour la fonction 1 | 2h | 1,5h | 2h | 2h | 7,5h | ||||||||
| Recherche de solution pour la fonction 2 | 2h | 1h | 2h | 2h | 7h | ||||||||
| Initialisation des registres | 3h | 3h | 2,5h | 8,5h | |||||||||
| Code 1ère fonction | 1,5h | 3h | 3h | 4h | 11,5h | ||||||||
| Code 2ème fonction | 3h | 2h | 2h | 1h | 8h | ||||||||
| Optimisation/Correction fonction 1 | 1h | 2h | 2h | 2h | 7h | ||||||||
| Optimisation/Correction fonction 2 | 2h | 4h | 6h | ||||||||||
| Tests et mesures | 1h | 2h | 3h | 2h | 3h | 5h | 16h | ||||||
| Modification de la carte | 3h | 3h |
Avancement du Projet
Phase préparatoire
- Rendez-vous de mise au point du cahier des charges avec les encadrants/intervenants (M. ZHENG Gang et M. DAGHER Roudy)
- Elaboration du cahier des charges
- Elaboration de la page Wiki (préparation de la mise en page et présentation du sujet)
- Préparation du travail sous forme de Mind Map
Semaine 1
- Revue du Cahier des Charges
- Lecture et recherches sur les technologies adaptées
- Construction de la suite de la Mind Map
//////
Semaine 2
- 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
- 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 vu l'utilisation de ces codes sur un projet IMA5 de l'an passé.
Semaine 4
- 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 : 
.
Nous pourrons alors balayer la plage de fréquence en changeant la valeur de CHANNR.
Semaine 5
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 sheet
ce qui nous a donné les valeurs FREQ2=0x21, FREQ1=0x31 et FREQ0=0x3A (FREQ=2 175 290)
- Nous avons suivi la formule
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 :
#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
- 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];
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"
Semaine 7
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.
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.
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 connectée en SMA.
- Nous avons aussi tenté de brouiller les communications d'autres groupes de projet utilisant des modules LoRa. Ces derniers étant configurés à 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
- Nous avons emprunté à M. Vantroys 3 modules SX1276 montés sur des cartes NUCLEO-F401RE afin de pouvoir tester notre carte sur une communication LoRa à 868Mhz
- 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 reconnue 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.
- 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 sur 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 efficacement.
- Les modules peuvent aussi communiquer en modulation FSK, dans ce cas notre système arrive à effectuer le brouillage. Néanmoins, il serait plus intéressant de parvenir à brouiller la communication LoRa.
- Après plusieurs changements dans le code du cc430, n'ayant pas de résultats positifs, nous avons diminué 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 entre les deux modules LoRa.
- En parallèle, nous avons commencé à rechercher des solutions pour la fonction 2. Un pseudo code est donné sur le site ti.com (pseudo_code_frequency_scanning) qui permet de faire un scan sur une plage de fréquence et de récupérer la fréquence ou le signal reçu est le plus fort. Ce code pourra être écrit en C puis incorporé dans notre main pour détecter une communication et la brouiller.
Semaine 9
- 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 (ce mode fonctionne aussi pour brouiller la modulation FSK)
- 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 CHANNR 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ée dans la fonction WritePATable (appelée par rfinit() dans le main), afin d'être maximale (12dBm)
- Enfin, nous avons augmenté le nombre de paquets à envoyer
Nouvelle bibliothèque RFconfig.h :
#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];
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); //led1 allumée quand le cc430 est 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); //led2 s'allume toutes les 2 rampes
}
else
{
chann++;
}
__delay_cycles(DELAY);
}
return 0;
}
Fonction WritePATable :
void WritePATable(void)
{
unsigned char valueRead = 0;
//while(valueRead != 0x03) // Output Power: -30 [dBm]
//while(valueRead != 0x25) // Output Power: -12 [dBm]
//while(valueRead != 0x2D) // Output Power: -6 [dBm]
//while(valueRead != 0x8D) // Output Power: 0 [dBm]
//while(valueRead != 0xC3) // Output Power: 10 [dBm]
while(valueRead != 0xC0) // Output Power: Maximum [dBm]
//while(valueRead != 0xC6) // Output Power(default): 8.8 [dBm]
{
/* Write the power output to the PA_TABLE and verify the write operation. */
unsigned char i = 0;
/* wait for radio to be ready for next instruction */
while( !(RF1AIFCTL1 & RFINSTRIFG));
//RF1AINSTRW = 0x7E03; // PA Table write (burst), Output Power: -30 [dBm]
//RF1AINSTRW = 0x7E25; // PA Table write (burst), Output Power: -12 [dBm]
//RF1AINSTRW = 0x7E2D; // PA Table write (burst), Output Power: -6 [dBm]
//RF1AINSTRW = 0x7E8D; // PA Table write (burst), Output Power: 0 [dBm]
//RF1AINSTRW = 0x7EC3; // PA Table write (burst), Output Power: 10 [dBm]
RF1AINSTRW = 0x7EC0; // PA Table write (burst), Output Power: Maximum [dBm]
//RF1AINSTRW = 0x7EC6; // PA Table write (burst), Output Power(default): 8.8 [dBm]
/* wait for radio to be ready for next instruction */
while( !(RF1AIFCTL1 & RFINSTRIFG));
RF1AINSTR1B = RF_PATABRD; // -miguel read & write
// Traverse PATABLE pointers to read
for (i = 0; i < 7; i++)
{
while( !(RF1AIFCTL1 & RFDOUTIFG));
valueRead = RF1ADOUT1B;
}
while( !(RF1AIFCTL1 & RFDOUTIFG));
valueRead = RF1ADOUTB;
}
}
Semaine 10
- 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.
- 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.
- Nous avons codé la fonction de scan en c et l'avons incorporé dans le main
- Cette fonction autorise le module à entrer en mode RX pour recevoir les communications. Elle incrémente ensuite le canal pour parcourir la plage 863-870MHz afin de détecter une communication. Toute les incrémentations, la variable rssi récupère la valeur contenue dans le registre qui correspond à la valeur du RSSI. Cette valeur étant en binaire complément 2, elle est convertie en dBm et placée dans un entier. Enfin, si cette valeur est supérieur à la valeur maximale déjà mesuré ou à un palier prédéfini (ici 0dBm), on stocke le numéro du canal correspondant qui sera utilisé dans le main par la suite.
fonction de scan :
void freq_scan(void)
{
unsigned char rssi;
long rssi_dbm;
unsigned char chan_scan=START_FREQ_CHAN;
long rssi_max=0; //scan will take communication above 0dbm
set_color(led1, 0x00, 0x00, 0x00, led2, 0x00); //led2 blue while scanning
ChangeChannel(chan_scan);
ReceiveOn(); //enable RX
while((Strobe(RF_SNOP) & 0x70) != 0x10); //make sure RX is ready
while(chan_scan<STOP_FREQ_CHAN)
{
ChangeChannel(chan_scan);
rssi = ReadSingleReg(RSSI); //define in cc430f5137.h RSSI=0x34 corresponding to addr of rssi value
if (rssi >= 128)
{
rssi_dbm = (long)((long)( rssi - 256) / 2) - RSSI_OFFSET;
}
else
{
rssi_dbm = (rssi / 2) - RSSI_OFFSET;
}
if(rssi_dbm>rssi_max)
{
rssi_max=rssi_dbm;
chan_jam=chan_scan-10; //start jamming 2Mhz below max dbm received
}
chan_scan++;
Strobe( RF_SFRX); //flush the RX FIFO
}
set_color(led1, 0x00, 0x00, 0x00, 0x00, 0x00);
}
nouveau main :
int main(void)
{
unsigned char chan_main=0x00;
port_mapping();
WDTCTL = WDTPW + WDTHOLD; // Stop WDT
rf_init(); //reset, setVcore & patable
_BIS_SR(GIE);
set_color(led1, 0x00, 0x00, 0x00, 0x00, 0x00); //led1 on if cc430 powered
int i;
while(1)
{
freq_scan();
ReceiveOff();
chan_main=chan_jam;
if (chan_main != 0) //jam only if a communication xas detected with freq_scan
{
for(i=0 ; i<(20*NUM_JAM_RAMP) ; i++) //ramp start 2Mhz below chan_jam and stop 2Mhz above
{
ChangeChannel(chan_main);
if (chan_main>= (chan_jam+20))
{
send_cmd();
chan_main=0x00;
led2=led2^0x10;
set_color(led1, 0x00, 0x00, led2, 0x00, 0x00); //led2 blink red every two ramp of jamming
}
else
{
send_cmd();
chan_main++;
}
}
}
chan_main=0x00;
__delay_cycles(DELAY);
}
return 0;
}
header :
#define DELAY 100 //300us #define DELAY_RSSI 10 //30us #define START_FREQ_CHAN 15 #define STOP_FREQ_CHAN 50 //scanning 863-870Mhz with 200khz steps #define RSSI_OFFSET 74 //cf datasheet #define NUM_JAM_RAMP 50 unsigned char chan_jam=0x00; unsigned char led2=0x10; unsigned char led1=0x10;
Après les vacances
- Nous avons effectué des tests pour vérifier si la fonction de scan fonctionne. Malheureusement, le cc430 n'a pas l'air de détecter de communications. La fréquence des modules LoRa a été fixée à 868MHz en mettant le header LORA_FHSS_ENABLE à false (ceci désactive le glissement de fréquence) pour faire des tests dans des conditions plus optimales. Cependant, le cc430 ne détecte toujours aucune communication.
- Nous avons donc vérifié plusieurs éléments du code : la conversion en dBm du registre RSSI, la lecture dans le registre, le temps de mise à jour du registre RSSI.
- D'après le pseudo-code fourni par texas instrument, et ce que nous avons pu lire sur les forums des développeurs, la conversion fonctionne. Nous avons tout de même essayé d'autre moyens de conversion, mais aucune de ces méthodes n'a permis au cc430 de détecter une communication.
- En ce qui concerne la lecture dans le registre, nous avons effectué des tests en lisant dans d'autres registres et en allumant une led, nous en avons conclu que la fonction ReadSingleReg fonctionne. Nous nous sommes donc portés sur l'adresse de ce registre, en vérifiant la bibliothèque cc430f5137.h, nous avons constaté que la variable RSSI était bien définie dans les adresses de registres.
- Enfin, d'après les datasheets du cc430 et du cc1101, le registre RSSI met un certain temps a s'actualiser, ce temps peut être calculé et dépend de la taille des paquets reçus. Ne pouvant pas connaître pas la taille des paquets de la communication que l'on cherche à brouiller à l'avance, nous avons décidé de fixer un temps d'attente 2 fois supérieur au temps caractéristique (~15us), soit 30 micro seconde.
- Malgré ces essais et corrections de code, nous ne sommes pas parvenus à faire fonctionner la détection de communication.
