Localisation de LoRa par DToA Implémentation sur FPGA Thèse de Bachelor présentée par Monsieur Sebastien CHASSOT pour l’obtention du titre Bachelor of Science HES-SO en Ingénierie des technologies de l’information avec orientation en Informatique matérielle septembre 2017 Professeur responsable Andrès UPEGUI
90
Embed
Localisation de LoRa par DToA · Thèse de Bachelor présentée par Monsieur Sebastien CHASSOT pour l’obtention du titre Bachelor of Science HES-SO en Ingénierie des technologies
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Localisation de LoRa par DToA
Implémentation sur FPGA
Thèse de Bachelor présentée par
Monsieur Sebastien CHASSOT
pour l’obtention du titre Bachelor of Science HES-SO en
Ingénierie des technologies de l’information avec orientation en
Informatique matérielle
septembre 2017
Professeur responsable
Andrès UPEGUI
printemps 2017 Session de bachelor
INGÉNIERIE DES TECHNOLOGIES DE L’INFORMATION
ORIENTATION – INFORMATIQUE MATERIELLE
ETUDE DE FAISABILITE DE L'IMPLEMENTATION D'UN GATEWAY LORA AVEC DES CAPACITES DE LOCALISATION PAR DTOA
Descriptif :
Dans la norme LoRa il est prévu de supporter un système de localisation basé sur le principe de «Difference Time of Arrival». Ce type de localisation à différence d'une méthode « Time of Flight » tel que présent sur les systèmes GPS, n'a pas besoin de gérer un timestamp précis du côté du dispositif à localiser, car le temps d'envoi du message n'est pas pris en compte par l'algorithme. C'est seulement du côté du gateway récepteur que ces timestamps doivent être gérés avec une haute précision afin de faire une trilatération basée sur la différence de temps de réception d'un message émis par un dispositif. Même si prévu dans la norme, les gateways actuels ne permettent pas de faire cette localisation car pour chaque message reçu, le timestamp attribué a une résolution de 1ms. Ce qui est largement insuffisante pour faire la localisation. Le but de ce projet est d'explorer la faisabilité d’implémenter un tel système basé sur une carte USRP B200, basé principalement sur un circuit RF, un ADC, une FPGA Spartan-6, et une interface USB-3. Deux principaux défis sont identifiés :
- Gestion du timestamp : à l'aide d'un signal de référence PPS fournie par un GPS, un système de compteurs devra gérer des timestamps avec une précision connue sur plusieurs cartes (2 cartes dans ce projet). Dans un premier temps ce timestamp sera validé avec la détection d'un événement simple.
- Traitement du signal LoRa: le but sera d'identifier plusieurs techniques pour identifier l'arrivée d'un signal LoRa basé sur l'entête du chirp. Cette détection servira à déclencher la capture du timestamp pour remplacer l’événement simple de l'item précédant. Le décodage de toute la trame reste hors de la porte de ce travail.
Travail demandé :
Pendant ce travail de diplôme l'étudiant devra :
- Analyser et comprendre l'architecture FPGA et le code C++ fournis avec la carte USRP B200.
- Proposer une solution matériel pour la gestion des timestamps. La valider sur la FPGA en utilisant deux USRP B200.
- Proposer aux moins deux méthodes pour détecter l'arrivé d'un signal LoRa : (1) Une méthode « naïve » qui permettra de valider la gestion de timestamps et qui nous permettra d'obtenir de résultats préliminaires. Cette méthode « naïve » aura certainement des limitations importantes para rapport à la distance ou à la fiabilité. (2) Un méthode qui pourra se baser soit sur un analyse fréquentielle ou sur une corrélation temporelle.
- Implémentation de la méthode naïve sur la FPGA.
- Validation et analyse de la deuxième méthode à l'aide de Matlab. Si la complexité de l'algorithme et le temps à disposition le permettent, implémentation sur FPGA.
- Tester le système afin d'obtenir de résultats.
Candidat : Professeur(s) responsable(s) :
M. Chassot Sébastien UPEGUI ANDRES
Filière d’études : ITI En collaboration avec :
Travail de bachelor soumis à une convention
de stage en entreprise : non
Travail de bachelor soumis à un contrat de
confidentialité : non
Printemps 2017Session de bachelor
Résumé :
L’internet des objets (IoT) est en pleine expansion. Les applications se multiplient. Une société suisse Semtech a innové en sortant sur le marché une solution sans-fil permettant de communiquer sur de grandes distances tout en consommant très peu d’énergie. Ces transcievers connus sous le nom de LoRa (contraction de long et range), permettent de transmettre de petits messages de quelques octets sur plusieurs dizaines de kilomètres.
Un besoin récurrent dans les applications IoT est la localisation des objets. Généralement on utilise un GPS et l’objet communique sa position. Avec LoRa il y a des inconvénients à faire cela. Un GPS met plusieurs dizaines de secondes à acquérir sa position et consomme beaucoup pour y arriver. On perdrait tous les avantages de LoRa en utilisant un GPS.
Il serait dès lors très intéressant de pouvoir localiser ces objets (LoRaMote) autrement. Ce travail a pour but d’étudier la faisabilité d’une localisation par « Difference Time of Arrival ». Une onde radio se propage aux environs de 2/3 de la vitesse de la lumière et parcourt 5m en environ 20 ns (20 milliardièmes de seconde). Ce temps tout en étant très petit devrait être mesurable, c’est du moins ce que ce travail tente d’évaluer. Si les résultats sont concluants, ce projet pourrait évoluer en utilisant plusieurs récepteurs synchronisés (gw0, gw1, gw2). Il serait dès lors possible de déterminer la position de la source d’émission (LoRaMote) en fonction des différents temps de réception.
Les récepteursdétectent un signal au tempst1, t2 et t3
Par trilatération de 3 temps et en connaissantla position desrécepteurs,on retrouve les coordonnées de l’émetteur dans le plan à l’intersection des 3 cercles
La difficulté est de synchroniser les récepteurs afin qu’ils partagent la même heure. Une montre à quartz retardant d’une s/an perd 31ns/s. Même synchronisées deux horloges, vont très vite dériver. La solution est d’utiliser le réseau GPS dont on peut extraire un signal périodique (PPS – pulse per second) avec une précision inférieure à la ns où que l’on se trouve sur terre.
La dernière difficulté est de détecter et reconnaître un instant précis dans la modulation LoRa afin d’y apposer un timestamp. L’algorithme est implémenté dans un FPGA afin de garantir les contraintes de temps, indispensables pour obtenir une bonne précision.
Candidat : Professeur(s) responsable(s) :
M. CHASSOT SEBASTIEN Upegui AndrèsFilière d’études : ITI
En collaboration avec : Travail de bachelor soumis à une convention
de stage en entreprise : nonTravail de bachelor soumis à un contrat de
confidentialité : non
Remerciements
Je tiens tout d’abord à remercier l’ensemble des professeurs de la filière ITI.Par leur enthousiasme et leur savoir, ils auront participé à rendre ces étudespassionnantes et particulièrement enrichissantes.
Un grand merci également à tous ceux qui m’ont aidé et soutenu durant laréalisation de ce travail de Bachelor. Notamment :
Andrès Upegui, professeur à l’hepia, pour avoir suivi mon travail ainsi que poursa grande disponibilité et ses conseils avisés.
Mickaël Hoerdt, professeur à l’hepia, qui a suivi mon travail de semestre auCERN et qui a soufflé l’idée de ce travail.
Tous les assistants et plus particulièrement Adrien Lescourt pour ses précieuxconseils.
Christian Bessat, ingénieur de recherche à l’hepia, toujours très serviable etd’une très grande efficacité.
7.1 Schéma temps de propagation d’une onde . . . . . . . . . . . . . . . . . . . . 37
8.1 Déphasage de deux signaux PPS générés par deux GPSDO . . . . . . . . . . 408.2 Déphasage de deux signaux PPS générés simultanément depuis le simulateur 418.3 Dérive temporelle avec synchronisation par simulateur . . . . . . . . . . . . . 428.4 Dérive temporelle avec synchronisation par simulateur (avec un autre couple
L’extension d’Internet aux objets physiques, connue sous le nom de l’Internet des objets(IoT 1) va grandissant. On rencontre dans notre quotidien de plus en plus d’objets connectéstels que des capteurs, les smartphones, des montres, la domotique (ampoules, interrupteurs,stores, électroménagers...). On parle pour la prochaine décennie de 150 milliards d’objetsconnectés[24].
Pour qu’un objet soit dit connecté, il doit avoir une connexion avec Internet. Certains objetsutilisent un lien filaire mais une grande partie utilise des liens sans fil.
La société suisse Semtech a innové en matière de solutions sans-fil (radio fréquence (RF)) ensortant sur le marché des transcievers permettant de communiquer sur de grandes distancestout en consommant très peu d’énergie. Ils sont connus sous le nom de LoRa (contractionde long et range) et permettent de transmettre de petits messages de quelques octets surplusieurs kilomètres voir dizaines de kilomètres (même en milieu urbain) et ceci pendantplusieurs années tout en n’étant alimentés que par une simple batterie.
Ces performances ouvrent de nouveaux horizons. Là où un lien était inenvisageable il y apeu, il est aujourd’hui possible de déployer des objets connectés.
La possibilité d’émettre sur de grandes distances avec une faible consommation 2 ouvre denouvelles perspectives. En contre-partie, un duty-cycle limité à 1% 3 et une modulation stablemais lente font que LoRa permet uniquement un lien pour de brefs messages espacés dans letemps 4.
Historique
Le 29 décembre 2016, Matt Knight présente au Chaos Communication Congress (33C3 )le premier reverse engineering de la couche physique de LoRa[8]. Jusque là, n’existait quela documentation incomplète de Semtech. Depuis, les blogs décrivant la modulation LoRafleurissent sur Internet (comme une page très détaillée sur revspace.nl)[21]. On trouveégalement plusieurs projets d’implémentations logiciel (applications Software Defined Radio)de LoRa et de la couche LoRaWAN.
Cet événement m’a grandement influencé dans le choix de ce sujet et évidemment beaucoupaidé dans mes recherches.
1.1 Le besoin de localisation
Beaucoup d’applications ont besoin de localiser les objets (pour les réseaux LoRa, on appelleles objets Mote ou LoRaMote). Généralement, l’objet dispose d’un GPS 5 et transmet saposition en même temps que ses data. Avec un LoRaMote ce n’est pas intéressant. Si le choixd’une application s’est porté sur LoRa, c’est pour répondre à une contrainte de distanceou d’économie d’énergie. Le réseau GPS utilise le principe du Time of flight (TOF). Lessatellites émettent des messages et c’est le récepteur qui calcule activement sa position. Ces
1. Internet of Things (IoT)2. Au détriment du temps de transmission3. Partage de l’utilisation de la bande passante avec les autres usagers. Le temps d’émission total ne doit
pas dépasser 1% soit 36 secondesheure.4. Limité à quelques octets.5. Global Positioning System (GPS).
calculs nécessitent beaucoup de ressources et de temps. En résumé, le GPS n’est pas du toutadapté aux applications basse consommation.
Quand on souhaite économiser temps et énergie, on restreint la communication au strictminimum et on évite les data inutiles en émettant des messages courts.
Il serait dès lors très intéressant de pouvoir localiser ces LoRaMotes en utilisant une autretechnologie.
Ce travail a pour but d’étudier la faisabilité d’une localisation par «Difference Time ofArrival».
1.2 Principe DToA
Une onde radio se propage à environ 2/3 de la vitesse de la lumière. En simplifiant légèrement,on peut estimer que cette vitesse de propagation est constante dans l’air. Une onde parcourt1 mètre en 4 − 5ns 6.
Si la vitesse de propagation est constante 7, un temps peut être associé à une distance. Orretrouver la position d’un objet en partant de 3 (ou plus) positions connues et trois distancesest utilisé depuis longtemps. Cette branche de la géométrie s’appelle la trilatération[26] etles équations ne posent pas de problème particulier.
Le GPS repose sur ce principe ; en connaissant la position des satellites et le temps qu’unsignal met à atteindre le récepteur à localiser (TOF).
Ce besoin de localisation a bien été compris par l’industrie. Semtech développerait actuel-lement un service de localisation. On trouve d’ailleurs une mention intéressante dans ladocumentation de Semtech :
Ranging / Localization
An inherent property of LoRa is the ability to line arly discriminate betweenfrequency and time errors. LoRa is the ideal modulation for radar applications andis thus ideally suited for ranging and localization applications such as real-timelocation services[20].
Ce travail étudie la faisabilité d’un tel système. Dans un premier temps il s’agit d’explorer unsystème comprenant deux récepteurs et détectant les différences de temps de réception d’unpaquet LoRa. Il pourrait être étendu à un plus grand nombre de récepteurs et permettraitde localiser un LoRaMote dans l’espace.
6. 4 à 5 milliardièmes de secondes7. Ce que nous supposons dans ce travail.
2 Architecture
Dans un système DToA, nous travaillons avec des temps. Ces temps ne correspondent pasexactement à des distances puisque nous ne connaissons pas le temps qu’a mis l’onde àparcourir la distance entre le LoRaMote et les récepteurs et il n’est pas nécessaire de leconnaître. Une différence de temps suffit à déduire une distance. Pour ça, il faut que lesrécepteurs soient synchronisés entre-eux.
Deux horloges distantes ne peuvent avoir exactement la même heure et c’est là que se trouvela première difficulté : synchroniser les récepteurs malgré leur éloignement. Une montre àquartz retardant d’une s/an perd 31ns par seconde 1. Donc, même en mettant les récepteursà l’heure, ils vont très vite dériver les uns par rapport aux autres. La solution choisit pourpallier ce problème est d’utiliser le réseau GPS dont on peut extraire un signal périodique à1[Hertz] (PPS) avec une précision inférieure à la ns 2. Les récepteurs sont resynchroniséstoutes les secondes sur l’heure «Universal Time Coordinated (UTC)» quel que soit leuremplacement sur terre.
La deuxième difficulté est de détecter le signal émit par un émetteur LoRa et de timestamper 3
cet événement aussi précisément que possible. Un paquet LoRa de 32 octets peut prendreplus d’une seconde pour être transmis 4. Il ne suffit pas de le détecter, il faut définir un pointprécis (infinitésimal) dans cette modulation afin de conserver une résolution de l’ordre de la[ns].
Le système se compose d’un compteur synchronisé par GPSDO 5, d’un déclencheur d’évé-nements (détection d’un paquet LoRa) et de l’envoi du timestamp vers un cloud pour êtrecomparé avec d’autres timestamp et d’effectuer la localisation de la source par trilatéra-tion. Un des avantages est que le système n’implique aucune modification du côté desLoRaMotes 6.
Figure 2.1 – Architecture du système
1. Une erreur de +7m par seconde2. La plage de précision théorique va de 12 ps ou plus suivant la précision du device générant le signal.3. Associer l’événement à une heure précise.4. Avec un Spreading Factor de 12 et une Bande passante de 125KHz, Tt = 212125·10−3·42symb = 1.376[s]5. Global Positioning System Disciplined Oscillator (GPSDO)6. On peut localiser un LoRaMote sans qu’il le sache. Il y a donc des considérations éthiques à prendre en
compte en mettant en place un tel système.
Chassot Sebastien, , septembre 2017 11/90
2.1 SDR
Ce travail implique des contraintes particulières et nous avons utilisé des récepteurs SoftwareDefined Radio (SDR). Ce type de device sert à échantillonner un signal RF à haute vitesseet à fournir un stream traité au niveau logiciel.
Si l’on prend l’exemple d’un LoRaMote que l’on peut considérer comme une boîte noire,un message est reçu via son antenne et on a accès à un buffer contenant le payload de cemessage. Le passage d’une onde RF à une suite d’octets a été effectué dans un ASIC 7. Toutela complexité de la démodulation, du contrôle des parités, de la redondance d’informationest cachée.
En SDR, nous avons accès au signal lui-même et il est donc possible de ré-implémenter auniveau logiciel ce qui se passe dans un ASIC. C’est donc un outil parfaitement adapté à destests ou du prototypage.
Le SDR utilisé a de plus l’avantage d’embarquer un FPGA 8. Ce composant contient unsystème logique qui numérise et transporte le signal vers un host. Il a de plus l’avantaged’être re-programmable et il est donc possible d’en changer le comportement et faire du«traitement de signal». Le signal peut donc être traité de façon logiciel par un host maiségalement en temps réel par le FPGA. C’est ce choix qui a été retenu pour garantir lescontraintes de temps critiques de ce projet. Le SDR est connecté à un host en USB3.0, orl’USB partage le temps de transfert entre tous les périphériques 9. Ces data passent de pluspar les buffers du kernel avant d’être accessibles dans le user space et de pouvoir être traités.Il n’était dès lors par sûr qu’il soit possible de garantir les contraintes de temps en traitant leflux au niveau du host. Sans compter qu’un OS non realtime peine à garantir des contraintesde temps inférieures à quelques centaines de micro-secondes. Le FPGA par contre transportele flux d’acquisition vers le host, on peut y placer un compteur à la fréquence de son horlogeet implémenter un algorithme qui trigge sur un événement du flux d’acquisition avec unefaible latence.
2.2 Mesure du temps (compteurs)
Sur un OS ordonnancé de type POSIX, la résolution est de 10−6 seconde 10. Aucunechance de réaliser un système DToA sur un PC. C’est pourquoi, le compteur est im-plémenté sur un FPGA et est re-synchronisé toutes les secondes en utilisant le réseauGPS 11.
7. Application-specific integrated circuit (ASIC)8. Field-programmable gate array (FPGA)9. Pour du SDR on utilise le mode Bulk Streams
10. On peut espérer au mieux un tick de 700 à 900ns.11. Le problème de consommation du GPS ne concerne que les émetteurs pas le système DToA.
Figure 2.2 – Système composé de deux récepteurs et d’un simulateur
— 1 carte de développement simulant un signal GPS (Basys3[1], Xilinx Artix-7).— 2 cartes GPS (shield LoRa/GPS pour RaspberryPi[3]).— 2 cartes de développement servant de compteurs (Basys3[1], Xilinx Artix-7).— 2 cartes d’acquisition SDR (USRP B200[16]).— 1 émetteur LoRa pour tester et valider le système (waspmote[9]).
3 Description du matériel
3.1 Carte SDR USRP B200
Cette carte permet de traiter tous types de signaux RF entre 70MHz et 6GHz avecune bande passante de 56MHz. Elle est connectée au host en USB3.0 et une API 1 per-met de récupérer et traiter le signal en temps réel ou de le sauvegarder pour un post-traitement.
L’USRP peut également émettre un signal pré-enregistré ou généré en temps réel. Dansce travail il n’est pas nécessaire d’émettre ; c’est pourquoi le transmitter n’est pas détailléici.
Son architecture est principalement composée d’un transciever (AD9364 pour l’acquisi-tion/transmission du signal), un FPGA (Spartan 6, contrôlé par l’API) et d’un Cypress FX3(pour le transport en USB3.0).
Figure 3.1 – Architecture générale de la carte USRP B200
Les sources de l’API[17], du FPGA[19] et le firmware du Cypress FX3 [18] sont disponiblessur github et les manuels utilisateurs ainsi que la documentation de l’API sont sur le site dufabricant[16].
Le composant AD9364 a été développé par Analog Devices en collaboration avec EttusResearch 2.
Il s’agit d’un ASIC, comprenant un tranciever et un Analog-to-Digital Converter (ADC)haute vitesse d’une profondeur de 12bits, faisant le lien entre le monde de la RF et celui dunumérique.
Figure 3.2 – Bloc diagramme du tranciever
Le signal provenant de l’antenne est d’abord amplifié puis mixé avec la fréquence de la PLL 3
afin d’être ramené en bande de base. Après un filtre passe-bande 4 le signal est échantillonné 5.L’acquisition peut monter à 60Msample/s et sort deux échantillons signés, I (réel) et Q(imaginaire) d’une profondeur de 12bits chacun.
L’AD9364 sort les échantillons sur 24 pins et peut transmettre de trois façons différentes.Soit comme un lien simple de 12bits parallèles (12 pins utilisées), soit en double lienascendant/descendant (2x12bits parallèles) ou en Low Volt Differencial Signal (LVDS) (12paires différentielles). La communication peut être half-duplex ou full-duplex en utilisant6 paires ascendantes et 6 paires descendantes. L’horloge peut être utilisée sur le flancmontant en Single Data Rate (sdr) ou en Double Data Rate (ddr) sur les flancs montants etdescendants.
L’AD9364 a une machine d’état interne (Wait, Sleep, Tx, Rx, FDD 6 et Alert). Elleest pilotée via un bus SPI tout comme le sont la fréquence de la PLL 7, le gain et lefiltre.
3.1.1 Cypress FX3 (USB)
Le cypress FX3 est un périphérique qui fait le lien entre l’USB3.0 d’un host et un SoC 8
(CPU, ASIC, DSP ou FPGA). Il intègre la couche physique de l’USB3.0 ainsi qu’un micro-contrôleur ARM 32bits 9 permettant de développer un traitement spécifique à une application(RTOS). Cypress met à disposition un environnement de développement. C’est cet environ-nement qu’Ettus a utilisé pour produire le firmware RTOS prenant en charge le protocolecommun à tous ses produits, l’«USRP Hardware Driver (uhd)» afin d’uniformiser sonAPI.
2. Producteur de l’USRP B200.3. Phase-Locked Loop (PLL).4. Utilisé généralement comme un filtre passe-bas5. Le signal numérisé peut être traité par un filtre FIR (128 taps) non représenté6. état rx+tx7. PLL.8. System on Chip (SoC)9. ARM926EJ-S
Le microcontrôleur est principalement utilisé pour configurer un DMA 10 qui s’occupe desmouvements mémoires entre les différentes FIFO. Un bus bidirectionnel GPIF II 11 relie leFX3 au FPGA.
Avec ce type d’architecture il est possible d’atteindre des capacités de transfert supérieures à400Mb/s.
3.1.2 Le FPGA Xilinx Spartan6
Le cœur du système est implémenté sur un Spartan6 XC6SLX75 12, l’un des plus gros de lagamme Spartan6 de Xilinx. Contrairement à ce qu’on pourrait imaginer il n’embarque pasde Softcore mais uniquement des blocs logiques.
Au début de ce travail, il était prévu de faire toute l’implémentation des algorithmes à ceniveau. Une grosse partie de mon travail a donc consisté à faire du reverse-engineering surl’IP core embarqué. Devant la complexité de l’environnement et le manque de temps, il afallu explorer d’autres solutions et se résoudre à utiliser plusieurs FPGA 13 et ré-écrire unepartie de la logique en repartant de zéro.
3.2 Les cartes Basys3 (FPGA)
Pendant la phase de développement et face à la complexité il a fallu diviser le problème enplus petites tâches, les résoudre, les valider et ensuite les assembler.
Pour commencer les essais, nous n’avions pas de GPS ; une alternative provisoire a donc étéde générer un signal PPS depuis une carte de développement. Par la suite, il a fallu simulerla réception d’un paquet LoRa. Plutôt que d’attendre d’avoir fini l’algorithme de détection, ilétait plus simple de le simuler avec un bouton et de le visualiser avec une LED. Sur l’USRP,il n’y a pas de bouton et chaque compilation prend 15 minutes.
Les cartes de développement Basys3 comprennent toute une série d’interfaces. Des boutons,des switchs, des LEDs, des 7-segments, des GPIOs, l’UART,...Elles sont rapidement devenuesindispensables pour valider une idée ou afficher un résultat (en faisant clignoter une LEDpar exemple). Petit à petit, elles ont été intégrées au projet et une partie des algorithmes afinalement été implémenté dessus.
Le FPGA embarqué est un Artix-7 de Xilinx. L’outil de développement est Vivado 14. LeFPGA fonctionne d’origine à 100Mhz (On peut le faire tourner plus vite) alors que leSpartan-6 lui fonctionne à 50MHz. Les cartes Basys3 offrent donc une meilleure résolutiontemporelle pour ce projet.
10. Direct Memory Access (DMA)11. General Programmable Interface v2 utilisé par Cypress12. 74637 Logic Cells, 11662 Slices et 3096Kb de BRAM.13. Les cartes Basys314. Vivado remplace ISE pour les FPGA sortis après les Spartan
3.3 Le récepteur GPS
Ce projet nécessite de synchroniser plusieurs USRP B200 (une pratique courante en SDRet l’USRP est prévu à cet effet). L’horloge interne est générée par un quartz mais on peututiliser un oscillateur externe de meilleure qualité 15.
Il est aussi possible d’ajouter sur l’USRP un GPSDO[15]. Cette option a l’avantage d’êtreparfaitement supportée par API mais elle coûte aussi chère que la carte. Pour ce travailexploratoire nous avons utilisé un GPS basic sortant un signal PPS tout en gardant à l’espritque les résultats pourraient être améliorés par l’utilisation de matériel plus précis. Le GPSDOd’Ettus n’est pas documenté et nous avions espoir qu’il serait possible de faire fonctionner lacarte avec un autre GPS. Sur le schéma de la carte, on voit qu’il y a deux interfaces série.L’un pour les trames NMEA 16 (gps_txd_nema) et un deuxième (gps_rxd, gps_rxd). Cedeuxième interface, non conventionnel, est utilisé pendant l’initialisation de l’USRP pourcommuniquer avec le GPS.
Figure 3.3 – Connexion GPSDO sur USRP B200
N’ayant ni documentation ni module, il aurait fallu se baser sur les sources de l’API pourcontourner ce mécanisme et tromper la carte. L’API est commune à tous les produits USRPet comprendre sont fonctionnement aurait nécessité beaucoup de temps sans garantie derésultats.
La shield Dragino LoRa/GPS Hat est faite pour être montée sur Rasberry Pi. Elle comprendun GPS basé sur un MTK MT3339[7] et un transciever LoRa 17. Il n’y a pas besoin deRaspberry Pi pour l’utiliser ; l’alimenter suffit pour récupérer un signal PPS. Il y a égalementun interface UART pour les trames NMEA[25]. Comme le travail est fait en intérieur, desantennes externes placées sur le rebord de la fenêtre ont été utilisées 18. Malgré cela, les joursde pluie, le GPS n’arrivait pas à acquérir de signal.
15. Il y a une entrée 10MHz prévue pour (connecteur SMA).16. Les GPS utilisent un protocole standardisé (NMEA) pour afficher les coordonnées calculées.17. SX1276 transceiver non utilisé dans ce travail.18. Avec 5m de câble
4 Environnement de développement
Les principaux outils utilisés sont ; Les librairies uhd d’Ettus (pour l’utilisation de l’USRP),les outils Xilinx ISE et Vivado pour les FPGA, GNURadio[6] et Matlab. Les scripts sontécris en python ou en bash.
4.1 Les outils USRP
L’un des points forts de l’USRP est que l’on a accès à tout le code source sur github.
Le dépôt principal contient le code des librairies (uhd), le firmware du Cypress FX3, celui duFPGA et des outils (Benchmark, tests, tests unitaires).
La plupart des distributions GNU/Linux récentes ont dans leurs dépôts les librairies uhd et uneversion précompilée du firmware FX3 et du bitstream pour le FPGA.
À chaque première utilisation de l’USRP, les firmwares sont reflashé sur la carte 1. Cetteméthode est très pratique quand on travaille sur le firmware. J’ai utilisé des liens symboliquesvers la dernière version compilée. Avec cette méthode, il y a moins de risque de confusionentre la version embarquée et celle de développement.
Comme les sources sont disponibles, le travail de développement a été fait sur un fork desdépôts git et en conservant git comme système de versioning. Pour éviter que de nouveauxcommits changent le comportement des outils, j’ai travaillé dans une nouvelle branche enn’utilisant plus la mainline. Pour le développement et les modifications apportées au projet,j’ai modifié les Makefile (cmake) de façon à toujours pouvoir compiler l’ensemble du projetoriginal et les modifications apportées.
Compiler le projet ne pose pas de problème particulier, il suffit d’avoir un environnement dedéveloppement correctement configuré (GCC et binutils).
Modification côté host
L’utilisation de l’USRP peut demander beaucoup de ressources au host en fonction dutype d’acquisition. Quand le taux d’échantillonnage dépasse les 20Ms, l’OS n’arrive plusà consommer le stream entrainant des pertes de données. Pour pallier ce problème, il fautdonner une priorité plus haute aux outils d’acquisitions. En modifiant les priorités du kernel,les acquisitions jusqu’à 50Ms n’ont plus de pertes de données 2.
À cette vitesse, l’écriture du flux sur un disque dur n’est possible que pendant quelquesdizaines de secondes 3. Dans notre cas, le flux est redirigé vers /dev/null puisqu’il n’y a pasde traitement logiciel.
1. Ils ne sont pas stockés dans une mémoire de la carte.2. Avec 32 bits par échantillon, le flux est de 200Mb/s sans compter l’overhead du protocole de transport.3. Le temps de saturer les buffers du kernel.
Pour ce travail, le signal est sur-échantillonné 4 afin de garder un maximum de précisionpour l’algorithme de détection. Il est donc nécessaire de pouvoir exploiter pleinement lacarte.
4.1.1 Le SDK de Cypress
Le firmware du FX3 a été écrit par Ettus et il est dans le dépôt mais il faut le SDK 5 deCypress pour le compiler. Il suffit de le télécharger et copier les dossiers ; common, lpp_sourceet u3p_firmware dans le dépôt github du projet puis de le patcher.
cd uhd.git/firmware/fx3/common/
$ patch -p2 < ../b200/fx3_mem_map.patch
$ make
Le firmware est compilé et il suffit de débrancher/rebrancher l’USRP pour qu’il soit mis-à-jourà l’initialisation de la carte.
4.1.2 Les SDK de Xilinx
ISE
Pour ce qui est du FPGA, il faut installer ISE WebPACK[28] de Xilinx pour pouvoirle recompiler. Le code est entièrement écrit en verilog alors que nous avons étudié leVHDL et il m’a fallu une période d’adaptation avant d’être à l’aise avec ce nouveau lan-guage.
Le projet utilise des Makefile et des scripts Tcl pour générer le bitstream. La compilationprend une quinzaine de minutes ce qui implique d’être méticuleux dans son travail et de bienvérifier avant de lancer la compilation. Les outils d’ISE sont utiles pour visualiser le projetmais les modifications dans ISE sont écrasées lors de la compilation.
Pour avoir plus de souplesse pendant le développement, j’ai écris un script qui lance lacompilation et sauvegarde les logs ainsi que le résultat de la compilation dans un dossier dont lenom comprend la date, l’heure, l’id du comit, ainsi qu’un commentaire (ex. ./2017.07.12-11 :15-agde4e_commentaire/ ). En ayant l’historique de tous les builds, il est possible de vérifier uneancienne version ou faire rapidement un roll-back en cas de problème.
Vivado
L’outils ISE n’est plus développé depuis octobre 2013. Xilinx l’a remplacé par Vivado pourtoutes les nouvelles générations de FPGA. Il est nettement plus convivial et support la familleArtix mais pas la famille Spartan qui nécessite toujours ISE.
Ce projet utilisant deux familles de FPGA il a fallu jongler entre ces deux SDK.
4. D’après Shannon, le taux d’échantillonnage doit être le double de la bande passante du signal soit 1Mspour LoRa.
Chipscope Pro est un outils de debug proposé par Xilinx. Il s’agit d’une IP que l’on peutajouter dans le code du FPGA et sur laquelle on peut se connecter en JTAG 6 afin devisualiser l’état de signaux internes.
L’utilisation de Chipscope Pro nécessite une licence il a donc fallut utiliser le serveur delicence de l’hepia. Sous Vivado, il y a moyen de debugger via l’USB 7 et l’IP n’est plusChipscope mais ILA (Integrated Logic Analyzer).
Figure 4.1 – Platform cable USB de Xilinx
Il faut également un driver, une application pour la connexion (iMPACT) et un client(analyzer) pour gérer les conditions de trigger et visualiser les signaux. Le driver n’estdisponible que sous RedHat et Windows 8. J’ai finalement réussi à l’installer sous arch linuxau prix de lourds efforts.
4.3 GNURadio
GNURadio[6] a été initié en 2001, dans le cadre du projet GNU 9. C’est une suite d’outils et unframwork de traitement de signal et plus particulièrement de signaux radio 10.
GNURadio supporte très bien les cartes USRP d’Ettus et permet de prototyper rapidementune application SDR. Il travaille en connectant des blocs comme des filtres (FIR), des sourcesde bruits gaussien, des Fast Fourier Transform (FFT), des mixers ou des opérateurs (addition,soustraction, produit). Les résultats peuvent être affichés sous diverses formes (waterfall,diagramme de phase, terminal,fichiers,...). Les blocs sont écris en C,C++ avec des wrappersen python.
Figure 4.2 – Exemple d’utilisation de GNURadio
GNURadio ne rentre pas dans le cadre de ce travail mais c’est cet outil qui a permis de faireles acquisitions vers un fichier pour analyse avec Matlab.
On trouve maintenant des implémentations de LoRa et de LoRaWAN et des exemplesd’émissions/réceptions[14] avec des cartes SDR.
6. Joint Test Action Group (JTAG).7. Si la carte est prévue pour.8. Il y a une dépendance à la librairie windrv qui comme son nom le laisse supposer, n’est pas très bien
supportée sous GNULinux.9. Les outils GNU de la Free Software Foundation à l’origine de GNU/linux.
Comme mentionné plus haut, la carte USRP B200 fait partie d’une famille de produits.Ettus a uniformisé sa gamme par l’utilisation de couches d’abstractions. On trouve uneAPI commune aux différents matériels puis une implémentation spécifique à chaque de-vice.
Ce code serait le même quel que soit le type de matériel ; instancier une carte, acquérir unflux et définir le taux d’échantillonnage.
Quand une carte B200 est instanciée, l’API va uploader le bitstream 1 sur le FPGA, maistoutes les cartes n’ont pas de FPGA. L’API propose des méthodes génériques mais cache lesspécificités du matériel.
On trouve également ce genre d’abstractions plus profondément dans l’API. Par exemple il ya des méthodes liées au transport mais ces méthodes font abstraction de la couche physiqueutilisée (USB ou ethernet).
L’API est très bien documentée 2 mais l’architecture matérielle ne l’est pas (hormis le schémade la carte). Une grande partie de mon travail a consisté à comprendre les liens entre lematériel, le code du FPGA et l’API. Il aurait sans doute fallu bien plus de temps pour maîtrisercet environnement et exploiter pleinement les fonctionnalités de l’API.
Il était prévu au départ d’implémenter tout le système sur l’USRP. Tous les éléments sont là ;le compteur, le signal RF et le support pour un GPS. Il ne reste plus qu’à trouver un moyende communiquer entre le FPGA et le host pour faire remonter l’information de détectiond’un paquet LoRa.
5.1 Architecture de l’IP core
Le FPGA comprend trois principaux blocs :
— Un bloc communiquant avec l’ADC (b200_io).— Un bloc central (b200_core) sur lequel s’est concentré mon travail.— Un bloc gérant l’interface GPIF II qui relie le FPGA au contrôleur USB (contrôle +
FIFO).
Ces blocs sont reliés par différents bus.
1. Le code du FPGA2. La documentation est basée sur doxygen et est compilée. Elle correspond donc exactement à la version
utilisée.
Chassot Sebastien, , septembre 2017 23/90
— un bus GPIF II 3 32 bits transférant toutes les trames entre l’USB et le FPGA.— 6 bus AXI-stream[27] 64 bits (3 pairs) 4.— 1 bus wishbone[12] 32 bits utilisé pour communiquer entre les différents blocs internes 5.
Figure 5.1 – Architecture des bus USRP B200
5.2 Les registres internes
On trouve dans le FPGA plusieurs blocs radio_ctrl à différents niveaux. Ces blocs reçoivent leflux AXI-stream dédié au contrôle et les relayent sur un bus wishbone. Ils possèdent égalementun deuxième bus AXI-stream pour la lecture des registres (readback). Chaque bloc radio_ctrlcontrôle un certain nombre de registres.
Chaque registre a un bus d’adresses (8bits) et un bus de data (32bits). Si son adressecorrespond, il met à jour sa valeur, les autres registres ne font rien.
La relecture est un peu plus complexe puisqu’un registre est utilisé comme sélecteur d’unmultiplexeur. On sélectionne le registre à lire depuis l’API. Le bus AXI-stream 6 a unemachine d’état qui revoit une trame vers le host.
Figure 5.2 – Architecture du readback des registres
3. Bus utilisé par Cypress pour ses contrôleurs USB.4. Bus de Xilinx.5. Bus open source.6. Qui arbitre les différents bus AXI-stream.
On trouve au niveau de l’API et du code verilog les adresses des différents registres 7.
localparam SR_CORE_SPI = 8;
localparam SR_CORE_MISC = 16;
localparam SR_CORE_COMPAT = 24;
localparam SR_CORE_GPSDO_ST = 40;
localparam SR_CORE_SYNC = 48;
localparam SR_LORA_TEST = 56; // usage attempt
localparam RB32_CORE_SPI = 8;
localparam RB32_CORE_MISC = 16;
localparam RB32_CORE_STATUS = 20;
localparam RB32_CORE_PLL = 24;
Listing 5.2 – Adresses des registres
Le code verilog comprend des exemples commentés d’usages des user_register.
// Set this register to put a test value on the readback mux.
Après plusieurs tentatives infructueuses, il s’avère que ces registres ont été récemment retiréde l’API 8.
Source trouvée sur le forum Ettus[4].
Apr 28, 2017 ; 11 :04pm Re : [USRP-users] writing to user settings registerOliver-I just went through all this myself. Unlike the N210 and older etti the userregisters are no longer exposed in the API so while you can "turn" stuff on in theFPGA image there are no implementations exposed in the B200 api.
Jeffrey Long, auteur de ce message, m’a très gentillement envoyé des exemples d’utilisationdes users_register. Malheureusement, nous avions abandonné cette voie et le travail étaittrop avancé pour re-tenter l’utilisation de ces registres.
5.3 Le compteur VITA time
L’USRP propose une gestion de l’heure accessible depuis l’API. L’heure est encodée sur 64bits. Les 32 bits de poids fort représentent la seconde et les 32 bits de poids faible la fractionde seconde. Cette représentation de l’heure a pour origine la spécification du protocole detransport VITA 9 et sa gestion est faite dans b200_core.
B200 Vita time (timekeeper)
radio_legacy contient un bloc dont la fonction est de synchroniser vita_time avec un signalPPS. La source de ce signal est soit un signal externe 10, soit un signal généré en interne 11
ou le signal venant du GPS.
Figure 5.3 – Architecture compteur, PPS et LoRa
8. L’API ne propose pas d’accès direct aux registres. Ce sont des méthodes privées qui ont été retirées.9. Un protocole de transport spécifique aux applications SDR (VITA Radio Transport Protocol for SDR
Architectures).10. connecteur sma de la carte B200.11. Basé sur la clock interne avec la dérive y liée.
Figure 5.4 – Schéma du bloc timekeeper
La source du PPS est sélectionnée via un registre. L’écriture dans ce registre est faite par l’APIquand le GPS est détecté. Il n’y a pas de méthode pour gérer le GPS 12, il est géré automati-quement par l’API. N’ayant pas le GPS d’origine, une autre solution a été de contourner lemultiplexeur en connectant directement le signal PPS au timekeeper.
À l’origine, le signal vita_time n’est utilisé que dans radio_legacy, il a fallu modifierles entrées/sorties du bloc afin de le rendre accessible au niveau supérieur ou se trouvelora_detect.
5.4 Les échantillons IQ
L’ADC a une profondeur de 12 bits mais le bloc b200_io ajoute 4 bits et concatène la partieréelle (I ) et imaginaire (Q) dans un signal 32 bits. Ces data restent sous cette forme et sontmis à disposition du host tel quel. Cette uniformité a facilité le test des algorithmes dansMatlab sans avoir à faire de conversions.
Ce signal étant disponible dans le bloc b200_core, il était facile de le connecter au bloclora_detect. C’est ce flux qui est utilisé par l’algorithme implémenté. Pour obtenir ce flux, ilfaut en parallèle, «démarrer» la carte, c’est-à-dire instancier la carte depuis l’API, régler lafréquence et le sample rate.
5.5 Les GPIOs
Une autre façon d’interagir avec l’extérieur sans passer par l’API est d’utiliser des General-Purpose Input/Output (GPIO)s.
12. Il y a une méthode mais elle échoue si le GPS ne répond pas.
Figure 5.5 – Schéma GPIO USRP B200
Après avoir tenté d’utiliser les GPIOs décrites sur le schéma de la carte sans succès 13, il s’avèreque la raison est que la version des cartes B200 (Rev 4 ) n’ont pas de GPIO.
// GPIO Header J504 - 10 pin 0.1" 3.3V.
// Only present on Rev6 and later boards...these pins unused on Rev5
// and earlier.
// NOTE: These pins are allocated from complimentry pairs and could
// potentially be used
// as differential style I/O.
`ifdef TARGET_B210
inout [7:0] fp_gpio,
`endif
Listing 5.5 – Commentaire sur les GPIOs
Finalement, il y a un interface UART disponible dont les pins sont routées sur la carte. Cetinterface a permis d’avoir un signal entrant (utilisé pour déclencher des évènements depuisl’extérieur à des fins de debug) et un signal sortant une pulse, signalant la détection d’unpaquet LoRa.
5.6 Les modifications apportées au FPGA
Après analyse du code verilog, il fallait trouver le bon endroit pour intégrer un algo-rithme. Le bloc b200_core est le plus adapté. Une partie des signaux nécessaires sontà ce niveau et ceux manquants sont accessibles en modifiant les entrées/sorties de quelquesblocs.
Il a tout d’abord fallu écrire un bloc en VHDL et l’instancier dans b200_core en verilog puismodifier les Makefile pour qu’il soit compilé et accessible au projet.
Au début, l’idée était de récupérer le compteur et de stocker sa valeur dans un registreaccessible depuis l’API quand une détection à lieu. L’USB n’ayant pas d’interruption, il étaitprévu pour vérifier le principe de faire du polling sur le registre.
13. Il n’y a qu’un schéma pour toutes les cartes de la famille B2x0.
Figure 5.6 – Schéma du bloc lora_detect initial
Modifications finales du FPGA B200
Aux vues des difficultés rencontrées avec les registres et le GPS et du manque de temps nousavons décidé de transférer une partie du système sur un deuxième FPGA. L’API est toujoursutilisée pour configurer le SDR, démarrer une acquisition avec un sample rate de 50MHz.Le FPGA a un nouveau bloc lora_detect dans lequel on peut implémenter n’importe quelalgorithme et un signal est sorti sur une pin (anciennement UART) de la carte quand unpaquet est détecté.
Figure 5.7 – Schéma du bloc lora_detect final
Le compteur et la lecture des timestamp est déporté sur un deuxième système, une carteFPGA (Basys3 ).
5.7 Chipscope Pro
Le seul moyen de vérifier et debugger l’état des signaux dans le FPGA est d’utiliser une probe.Heureusement, dans le bloc b200_core il y a un exemple commenté d’utilisation de chipscope.Je n’ai pas réussi à instancier le chipscope en VHDL c’est pourquoi j’ai sorti un bus 128bitsdu bloc lora_detect et l’ai utilisé au niveau du b200_core 14.
14. Certain signaux sont nommés in et out (dans le code verilog) alors que ce sont des mots réservés enVHDL.
5.7.1 Alimentation du chipscope
La carte USRP B200 a un footprint pour un connecteur JTAG mais il n’est pas soudé. Nousen avons ajouté un mais se connecter dessus était impossible 15.
En faisant quelques mesures sur la carte, il s’avère qu’il n’y pas d’alimentation 3.3V et doncpas d’alimentation sur le JTAG.
Figure 5.8 – Schéma régulateur de tension secondaire
En remontant le circuit, il s’avère qu’il n’y a pas non plus de 3.7V . La raison est que lerégulateur principal a une pin (SHDN_SW ) pilotée par une GPIO du contrôleur CypressFX3.
Figure 5.9 – Schéma régulateur de tension principal
Pour alimenter le circuit il a fallu recompiler le firmware du FX3 avec la modificationsuivante.
Listing 5.6 – Modification du firmware Cypress FX3
On n’imagine pas au premier abord qu’il faille patcher un firmware pour pouvoir debugger leFPGA sans que ce ne soit documenté. La raison est sans doute une économie d’énergie enutilisation normale. L’utilisation du FPGA est un usage avancé de l’USRP B200 et n’estdonc pas documenté.
15. Avec un Platform Cable USB II de Xilinx.
5.7.2 Mesures avec chipscope
Arriver à se connecter au JTAG 16 a grandement facilité la suite du travail. En probant les si-gnaux du bloc lora_detect on peut vérifier le comportement interne du FPGA.
Listing 5.7 – Exemple de signaux internes à tester
Il est ainsi possible de vérifier l’algorithme sur une acquisition réelle en visualisant l’état dessignaux (ici en triggant sur un flanc montant de detection LoRa).
Figure 5.10 – Exemple d’utilisation du chipscope (vue d’un spectrogramme en parallèle)
La détection se fait quand le seuil de 25000000 est dépassé. On peut contrôler que c’est bience qui s’est passé dans le FPGA.
16. JTAG
6 Compteur et simulateur sur Basys3
La gestion des timestamps est implémentée sur une Basys3. Le format du compteur est64bits (32bits secondes et 32bits fraction de seconde 1). Les secondes sont affichées sur des7-segments 2 et permettent de contrôler visuellement la synchronisation des compteurs entreeux.
Lorsqu’un événement se produit sur une entrée (une pulse) la valeur du compteur est placéedans un registre et ce timestamp est envoyé sur l’UART.
Il y a deux sources d’événements possibles ; depuis la carte USRP B200 ou depuis unémulateur.
Pour la synchronisation des compteurs il y a également deux sources ; le PPS du GPS ou celuid’un générateur émulant un signal PPS 3. Là encore, des switchs permettent de sélectionnerune source ou l’autre.
Figure 6.1 – Interface compteur Basys3
6.1 Envoi des timestamps en UART
Le plus simple à mettre en œuvre pour accéder aux timestamps était l’UART. Il est facileavec un script de les logger dans un fichier ou de les traiter.
L’UART, utilisé est celui du projet OpenCores, l’«UART 16550 core»[13]. Son utilisation n’apas posé de problèmes particuliers.
Les valeurs de timestamp sur l’UART comprennent 20 octets ; 16 octets pour la valeur duregistre, un délimiteur sec,frac et 2 caractères de fin de ligne CR/LF). À 115200bauds, lenombre maximal de timestamp que l’on peut transmettre est de 720s−1 ce qui est suffisantdans un premier temps.
1. Le compteur va de 0 à 10e8 et 27bits auraient suffit.2. La valeur est affichée en hexadécimal.3. Un signal PPS est une pulse d’une période de 1Hz et d’une durée de 40ms (en général).
L’émulateur n’a d’autres fonctions que de tester le système. Il a 8 sorties PPS simulées et 8sorties d’évènements synchrones.
Les évènements sont activés manuellement par un bouton ou avec un switch en modeautomatique générant 100 pulses par seconde.
Figure 6.2 – Interface simulateur Basys3
7 Agrégation des timestamp ettrilatération
La trilatération ne rentre pas dans le cadre de ce travail, néanmoins les timestamps ontbesoin d’être comparés. En l’état actuel, les détecteurs sont proches mais un système réelimpliquerait qu’ils soient éloignés de plusieurs centaines de mètres ; il faudra d’une manièreou d’une autre regrouper les données pour les comparer.
Un moyen rapide d’y arriver est d’envoyer depuis chaque système les mesures sur Internet.MQTT [11] est un protocole léger et facile à mettre en œuvre, il est basé sur l’envoi de petitsmessages en mode publisher/subscriber. Les détecteurs publient leurs mesures qui peuvent êtrerécupérées depuis n’importe où. MQTT a une forte latence mais jusqu’à quelques dizainesde messages par seconde ; il convient très bien.
Un script est lancé sur chaque système de détection.
Listing 7.2 – Exemple de message transmis au broker MQTT
L’avantage de cette méthode est que l’architecture n’est pas prédéfinie. Un nombre quelconquede détecteurs peut être utilisé. Plus tard, un sens sera donné à ces données. Actuellement,le JSON ne contient que le timestamp. Idéalement, la détection devrait être couplée à unedémodulation de la trame complète. L’émetteur pourrait être identifié en lisant le payloaddes messages. La couche de transport (LoRaWAN) a un header identifiant l’émetteur et uncompteur de frame 1. Avec ces informations, on peut déterminer quels sont les messages à
1. La partie utilisée pour le routage de LoRaWAN n’est pas chiffrée.
Chassot Sebastien, , septembre 2017 35/90
comparer. Un service pourrait récupérer les mesures de tous les messages au header identiqueset les localiserait en fonction des coordonnées géo-temporelles de réceptions. Plus le nombrede récepteurs serait grand plus la trilatération serait précise.
Trois coordonnées géo-temporelles permettent de localiser un point dans un plan 2. Avecune quatrième, on peut également déterminer l’élévation. Toutes les coordonnées supplé-mentaires peuvent permettre d’affiner la localisation. On peut faire une trilatération pourchaque combinaison de 3 ou 4 mesures et prendre le centre de gravité de tous ces résul-tats.
En ne définissant pas d’architecture dès le début, le système pourra facilement évoluer dansle futur.
Actuellement, le système est composé de deux détecteurs. Un script s’abonne au brokerMQTT et récupère les messages à traiter.
Listing 7.3 – Script analysant les timestamp avec MQTT
Quand deux timestamps sont reçus, ils sont comparés et le résultat affiché. La librairie geopypermet de faire des opérations sur les coordonnées comme mesurer les distances entre lesrécepteurs (ici un exemple hypothétique).
=======================================
Server started
=======================================
Listen to MQTT topic : lora_dtoa_topic
=======================================
=============================================
Location : prairie (46.209828, 6.135596)
Timestamp : 16.137763760 s
Location : liotard (46.209205, 6.134255)
Timestamp : 16.137763780 s
Distance entre les gateway : 124m
---------------------------------------------
Différence : 20 [ns] (env. 5m d´erreur)
=============================================
=============================================
Location : prairie (46.209828, 6.135596)
Timestamp : 16.198758160 s
Location : liotard (46.209205, 6.134255)
Timestamp : 16.198758180 s
Distance entre les gateway : 124m
---------------------------------------------
Différence : 20 [ns] (env. 5m d´erreur)
=============================================
2. L’intersection de trois sphères non alignées est un point.
7.1 Calcul de la distance
La transformation d’une différence de temps en distance est relativement triviale.
Figure 7.1 – Schéma temps de propagation d’une onde
Ce que nous savons, c’est qu’au temps tx, quand le récepteur 1 a détecté l’onde, elle a encoreparcouru dt · vonde avant d’atteindre le récepteur 2. Comme nous connaissons la position desrécepteurs dans l’espace, nous déduisons que :
s = 2x + (t2 − t1)vonde = 2x + dt · vonde
et que la position du LoRaMote est :
x =s − (dt · vonde)
2
À noter que quand dt · vonde = s ⇐⇒ x = 0, on ne peut déterminer la position duLoRaMote. L’émetteur doit nécessairement être entre les deux récepteurs (sinon impossiblede déterminer tx). Si x = 0 c’est que l’onde a pu parcourir une distance quelconque avantd’être détectée 3.
La précision des distances dépend directement de la précision des mesures de temps et del’erreur ξ.
Quand dt est petit, l’erreur est prépondérante alors que s’il est grand, l’erreur devientnégligeable.
En l’état actuel, localiser un émetteur n’a de sens que pour des distances de l’ordre de 100m(à moins d’utiliser du matériel plus précis). En dessous, la précision ne sera sans doutes pasassez fine et au-delà de quelques kilomètres on sera confronté à un signal très dégradé qu’ilsera difficile de détecter.
3. Il faudrait plus de récepteurs pour lever le doute.
8 Synchronisation de systèmes distants
8.1 Principe de l’algorithme
Le flanc montant du signal PPS est considéré comme fiable pour resynchroniser les systèmes.Or le GPS ne peut fournir ce signal que s’il reçoit les satellites, ce qui n’est pas toujours lecas. Pendant ce travail, les jours de pluie et malgré les antennes placées à l’extérieur 1, lesGPS n’arrivaient pas à locker le signal des satellites 2.
La synchronisation des compteurs repose sur un principe simple et s’inspire de celui del’USRP. Il y a deux compteurs ; l’un comptant les secondes et un second les fractions deseconde. Comme le DToA n’a besoin que de différence de temps, il n’y a pas besoin de tempsabsolu mais juste que les compteurs soient dans la «même seconde».
Le compteur fracsec est incrémenté à chaque coup d’horloge et prend des valeurs de [0 à108 − 1]. Quand sa valeur atteint 5 · 107, on place dans un registre la valeurs de la prochaineseconde. Si un signal PPS arrive le compteur est écrasé par la valeur registresec +0fracsec (lafracsec vaut zéro à cet instant). Si ce signal n’arrive pas, le compteur fonctionne normalement(avec sa dérive). Tant que la dérive ne dépasse pas ±0.5[s], le compteur est resynchronisé dansla «même seconde». Ce cas pourrait arriver si le signal PPS était perdu pendant plusieursjours, ce qui est peu probable.
L’USRP fonctionne de la même manière ; une méthode écrit la valeur que prendra lecompteur dans un registre et cette valeur sera effective lorsqu’un événement se produit.Il n’est pas possible de régler correctement l’heure depuis le host puisque la commandepasse par l’USB et qu’on ne peut savoir le temps qu’elle mettra à arriver dans le FPGA.La librairie uhd/host/lib/usrp/gpsd_iface.cpp traite les trames NMEA depuis l’OS. Quandle GPS est activé et qu’un temps valide est reçu, ce temps incrémenté d’une seconde estécrit dans un registre 3 et le compteur interne prend cette valeur au flanc montant du PPSsuivant.
Basé sur ce principe le compteur s’est révélé parfaitement fiable. Il reste que le compteur faitdes sauts à chaque synchronisation. Si un paquet LoRa arrive en même temps que le PPSil y a un risque qu’un compteur soit resynchronisé alors qu’un autre ne le soit pas encore.Cette erreur est inévitable avec une telle architecture mais n’est pas pire que les erreurs liéesaux dérives de l’oscillateur (comme nous le verrons plus bas).
La meilleure solution serait d’utiliser un oscillateur asservit. Le décalage entre la valeur ducompteur et le PPS serait utilisé comme rétroaction sur le quartz. En jouant sur sa températureavec un corps de chauffe 4 et une isolation thermique 5, on peut augmenter ou diminuer safréquence plutôt que d’avoir ces sauts de synchronisation[23].
1. Les antennes sont placées sur un rebord de fenêtre.2. Les GPS ont généralement un signal externe appelé lock signifiant que les trames UART sont valides
ou ne le sont pas.3. Le temps d’écriture est bien inférieur à la seconde.4. Une résistance ou un transistor.5. Oven controlled crystal oscillator (OCXO).
Chassot Sebastien, , septembre 2017 39/90
8.2 Mesures d’erreurs des sources de synchronisation
Précision des signaux PPS des shield Draguino LoRa/GPS
Le module choisi embarque un MTK MT3339[7]. D’après la datasheet le signal PPS à latolérance suivante.
— Typical accuracy : ±10ns
Le GPSDO proposé par Ettus n’a pas pu être testé mais annonce un jitter de ±50ns.Vu son prix et une compensation en température 6 cette valeur est certainement plus réa-liste.
Mesures du GPSDO et du simulateur
Afin de quantifier les sources d’imprécisions, il est important de vérifier les hypothèses. Lesmesures effectuées sur deux shield, donnent un déphasage allant de 0ns à ±70ns 7. En général,une carte est en avance sur l’autre mais parfois le déphasage s’inverse. Ces valeurs dépassentlargement les ±10ns annoncés par le fabricant.
Figure 8.1 – Déphasage de deux signaux PPS générés par deux GPSDO
Pour évaluer la précision théorique et s’affranchir des problèmes d’acquisition GPS enintérieur on utilise aussi le signal du simulateur. En théorie, le signal devrait être bienplus précis. La fréquence de 1Hertz ne l’est pas mais le signal devrait arriver «en mêmetemps».
On trouve néanmoins un petit déphasage.
6. Temperature compensated crystal oscillator (TCXO)7. Peut-être même plus.
Figure 8.2 – Déphasage de deux signaux PPS générés simultanément depuis le simulateur
Le déphasage est d’environ de 4ns par contre le taux de montée est relativement médiocre(15ns 8). Ce taux de montée est en partie dû à la qualité des câbles utilisés. L’origine auraitégalement pu être imputé au FPGA mais passer le slew rate 9 des pins à FAST n’y a rienchangé.
8.3 Méthodologie de tests
Le simulateur peut envoyer des évènements en continu à une fréquence de 100Hz. Avec100 mesures par seconde on peut mettre en évidence les variations entre les deux comp-teurs.
8.4 Dérive temporelle entre deux compteurs synchroniséspar simulateur
Les résultats montrent que les différences sont nulles juste après la synchronisation puis lescompteurs divergent. La dérive n’est pas stochastique mais linéaire. Son origine est forcémentliée aux fréquences d’horloges.
8. Mesuré à 10%-90%.9. Il est possible d’imposer des contraintes aux pins du FPGA comme par exemple un taux de montée
plus rapide.
Figure 8.3 – Dérive temporelle avec synchronisation par simulateur
On peut remarquer que la progression n’est pas complètement linéaire mais en forme d’escalier.Cela est dû à la résolution de l’horloge. La différence est stable pendant quelques mesuresavant d’atteindre 10ns et se stabiliser à un nouveau seuil. On remarque également quelquespics. Ces variations sont normales dans un système mais il est intéressant de noter qu’ils nedépassent pas les 10ns.
Une dérive stable est une bonne chose puisque des solutions pour la réduire sont envisageables.Comme par exemple un étalonnage avec une compensation.
Table 8.1 – LUT facteurs de correction pour un dtmax = 300ns
ou une fonction :
dtcompensated = dtmeasured(1 −dtmax
rate)
Tolérance des quartz
Le premier couple de carte utilisé pour les mesures donnait des dérives d’environ 1700ns s−1.En testant d’autres cartes les résultats sont identiques pour ce qui est de la linéarité maisl’écart au bout d’une seconde varie significativement.
Figure 8.4 – Dérive temporelle avec synchronisation par simulateur (avec un autre couplede cartes)
Les écarts de plusieurs cartes prises au hasard sont de {250, 600, 800, 1200, 1700}ns s−1.
On voit la disparité due aux composants. Ce taux d’erreur est bien inférieur à ce qu’il pourraitêtre. Le quartz DSC1033[10] utilisé sur la carte Basys3[2] a une tolérance de ±50ppm 10.À une fréquence de 100MHz l’erreur pourrait être de ±5000clk s−1 par carte soit jusqu’à10000 cycles d’horloge de décalage entre deux cartes.
Il est donc possible d’obtenir de meilleurs résultats et réduire cette dérive par l’utilisationd’un oscillateur de bonne qualité compensé en température[23].
À noter que les mesures ont été faites après avoir laissé chauffer les composants quelquesdizaines de minutes.
8.5 Avec ou sans synchronisation
Perte de synchronisation
Voici ce qui se passe quand la synchronisation ne s’effectue plus.
10. Température comprise entre -20°C et + 70°C.
Figure 8.5 – Comparaison de la dérive avec ou sans synchronisation
La synchronisation a eu lieu 3 fois. La dérive a été ramenée à zéro puis la synchronisation estinterrompue et les systèmes divergent.
Resynchronisation
Dans cet exemple, on voit très bien ce qui se passe quand le signal de synchronisation dusimulateur est interrompu. Les systèmes divergent, puis quand le signal arrive à nouveau, leshorloges se resynchronisent.
Figure 8.6 – Perte de synchronisation et reprise
8.6 Dérive temporelle entre deux synchronisations parGPSDO
Maintenant que les mécanismes sont plus clairs, vérifions ce qui se passe quand la sourcede synchronisation n’est plus unique (simulateur) mais vient de deux GPSDO utilisant leréseau GPS.
Figure 8.7 – Dérive temporelle avec synchronisation par GPSDO (positive)
Nous retrouvons cette forme en dents de scie mais cette fois il y a une composante continueliée au déphasage des signaux PPS.
Figure 8.8 – Dérive temporelle avec synchronisation par GPSDO (négative)
Cette composante continue peut être positive ou négative ce qui n’est pas étonnant pour dessystèmes indépendants.
Compensation logicielle
La dérive peut être réduite en soustrayant une compensation. Juste après la synchronisationla compensation est faible puis elle augmente. On arrive à supprimer presque complètement lacomposante linéaire. L’erreur est de l’ordre de ±5m avec une synchronisation par simulateur.Pour obtenir ce résultat, il faut faire une calibration des cartes.
Figure 8.9 – Dérive temporelle avec synchronisation par simulateur et compensation logi-cielle
L’erreur est de l’ordre de ±10m en situation réelle (GPS).
Figure 8.10 – Dérive temporelle avec synchronisation par GPSDO et compensation logicielle
Conclusion sur les compteurs
Ces résultats sont très encourageants. Il faut encore tenir compte de l’erreur dans la précisionde la détection mais quelques dizaines de mètres d’erreur sur un kilomètre offrent déjà uneinformation significative.
Voyons comment associer ces résultats avec la détection d’un paquet LoRa en traitant unsignal RF.
9 LoRa modulation
LoRa utilise une modulation par étalement de spectre (Spread Spectrum (SS)). Le principeest de répartir l’information sur toute la bande passante ce qui minimise les effets du bruit.Souvent les modulations basées sur SS utilisent des séquences prédéfinies (pseudo-random)comme par exemple le Bluetooth 1.
Dans le cas de LoRa on utilise une porteuse qui se déplace en permanence. La séquencepseudo-random est remplacée par une simple suite de fréquences 2. Cette technique appeléeCompressed High Intensity Radar Pulse (chirp), est inspirée des radars 3 militaires et civils.La porteuse est un signal qui augmente en fréquence en allant de fmin à fmax à une vitessedfdt
déterminée 4.
Figure 9.1 – Exemple de chirp (fréquence)
Si l’on observe comment la fréquence de la porteuse évolue dans le temps on voit quele signal f(t) est en forme de dents de scie. Quand la fmax est atteinte, elle reprend àfmin.
Figure 9.2 – Evolution de la fréquence en fonction du temps
1. Saut de fréquence dans la bande 2.4GHz.2. C’est une forme de séquence prédéfinie et c’est pourquoi LoRa est dans la bande 867-870MHz dédiée
aux modulations par SS.3. Le signal émit est du même type.4. fmin et fmax représente les bornes de l’occupation en fréquence du signal
Chassot Sebastien, , septembre 2017 47/90
Un mélange de FSK et de chirp
La modulation FSK 5 est relativement commune ; chaque symbole est représenté par unefréquence différente. En faisant une FFT 6 on obtient des pics correspondant aux symbolesencodés.
f(symb) ∈{
fs0, fs1, ..., fsn−1
}
LoRa fait exactement la même chose mais mixe une modulation FSK avec le chirp. On obtientune modulation par «saut de chirp». En pratique le chirp va sauter du chirp représentant lesymbole actuel vers celui du prochain symbole.
En mixant un chirp et une fréquence représentant le symbole, on obtient la modulationLoRa.
Figure 9.3 – Exemple de mixage du chirp et d’une fréquence fixe
Le nouveau signal sort de la bande d’émission (aliasing), il est donc replié et filtré etprend cette forme caractéristique que l’on retrouve dans le spectrogramme d’un signalLoRa.
Si le nombre de symbole est de 256 (2SF ) chacun est représenté par un chirp propre. Pour lesymbole n, le chirpn va de :
fdébut =(
fmin +n
bp
)
à ffin =(
fmax +n
bp
)
%bp
Figure 9.4 – Exemple de modulation de symboles
5. Frequency-Shift Keying (FSK)6. FFT
Effet du bruit
Même avec un rapport signal sur bruit (SNR) très faible il est possible de reconstruire lesignal. En théorie il suffit d’une coordonnée (f, t) pour déterminer quel chirpn unique passepar ce point.
Figure 9.5 – Exemple de signal très bruité
En sachant qu’un symbole peut s’étendre sur plusieurs millisecondes, on comprend mieuxpourquoi cette modulation est extrêmement résistante au bruit.
Démodulation
Que se passe-t-il quand un up-chirp ou un symbole est mixé avec un down-chirp ?
Figure 9.6 – Exemple de mixage du down-chirp et d’un symbole
On retrouve précisément une modulation FSK. Il suffit donc de faire une FFT sur le signalmixé pour reconnaître le symbole.
Voici à quoi ressemble le spectrogramme d’un court message.
Figure 9.7 – Exemple de transmission
9.1 Canal de communication
En pratique le canal de communication va être défini par plusieurs constantes sur lesquellesl’émetteur et le récepteur se sont préalablement entendus.
Ces constantes sont :
— l’occupation en fréquence (Bande Passante (BP)).— la fréquence du channel.— le Spreading Factor (SF 7).
L’occupation en fréquence
LoRa occupe une bande de 125, 250 ou 500KHz. Une plus grande bande passante améliore latransmission (meilleur étalement du spectre). En contre-partie, la vitesse df
dtétant fixe, les sym-
boles vont durer plus longtemps avec un «temps de vol» qui va s’allonger 8.
Le channel
LoRa peut exploiter 8 channels dans la bande UHF 9. En Europe aux alentours de 868MHzet aux États-Unis 915MHz. Le duty cycle doit rester inférieur à 1%.
Le spreading factor
Le SF est une valeur comprise entre 7 et 12 déterminant le nombre de symboles enco-dés :
Nbsymboles = 2SF (de 128 à 4096)
La BP est donc divisée en Nbfréquences et à chaque fin de période de symbole (Ts), un sautde chirpsn est opéré vers le chirpsn+1 du nouveau symbole.
La vitesse du chirp ( dfdt
) est également déterminé par la valeur du SF.
rate =BP
2SF=
df
dt
La période Ts est également fonction du SF et de la BP :
7. Sreading Factor (SF)8. Donc il y a également un impact sur le duty cycle9. Dans la bande Industrial Scientific and Medical radio bands (ISM)
Ts =2SF
BP[s]
Plus le SF est élevé, plus le symbole est maintenu longtemps. Le temps de transmission aug-mente mais en contrepartie la communication est plus résistante au bruit.
Sur-encodage, whitening et parité
Si le saut vers un nouveau symbole est proche du précédent, il y a un risque de ne pasarriver à les distinguer 10. Pour éviter cela LoRa utilise la technique du code de Gray[22]. Lemessage original est considéré comme un code de Gray. Dans un code de Gray, deux valeursconsécutives n’ont qu’un bit de différence. En appliquant l’opération inverse, on s’assureque deux symboles n’ayant qu’un bit de différence ne seront pas envoyés l’un à la suite del’autre.
Le message est également randomisé en faisant un XOR avec une séquence pseudo randompartagée par l’émetteur et le récepteur (Whitening) 11. On réduit ainsi l’envoi de suite desymboles identiques.
Pour la correction d’erreur, une parité est également ajoutée tous les nbits.
Toutes ces opérations sont réversibles. Le récepteur les ré-applique et retrouve le messageoriginal.
9.2 Quelques chiffres significatifs
Le bit rate d’un paquet LoRa
Avec un SF de 7 (125KHz), on obtient un bitrate de 27343 bits/s alors qu’un SF de 12 et unebande passante de 500KHz ne permet de transmettre que Rb = 366 bits/s 12.
Rb = SF ·BP
2SF[bits/s]
La période symboles
Avec un SF de 12 (125KHz), le temps d’un symbole est de Ts = 32.768[ms] alors qu’avec unSF de 7 (500KHz) le temps n’est plus que de Ts = 0.256[ms].
Ts =2SF
BW[s]
10. Le seuil de détection d’un changement dans la machine d’états du récepteur risque de ne pas êtreatteint.
11. Cette séquence a été découverte par reverse engineering et présenté par Matt Knight[8]12. Bite rate sans tenir compte des symboles de parité.
Le «temps en vol» d’un message
Si l’on tient compte du préambule et de la parité, pour un message de 32 symboles il faut50 symboles transmis 13.
Tvol = 50 ·2SF
BP[s]
Le même message peut être transmis en 1.63[s] avec un SF de 12 (125KHz) ou en 0.0128[s]avec un SF de 7 (500KHz).
Rapport temps/distance d’une onde électromagnétique
Une onde RF à une vélocité à peu près égale au 2/3 de la vitesse de la lumière, soit environ200000000[ms−1] d’où on peut déduire les ordres de grandeurs suivants :
1 m ⇐⇒ 5 ns
1 ns ⇐⇒ 0.2 m
10 ns ⇐⇒ 2 m
20 ns ⇐⇒ 4 m
En comparaison, le temps entre deux échantillons de l’ADC est de 20ns et l’horloge ducompteur à une période de 10ns. On comprend ainsi mieux la relation entre les erreurs demesures et les erreurs de localisation. Une distance de 50m est parcourue en 250ns et il faut50000ns pour parcourir 10Km. Arriver à une résolution de 100 − 200ns en ferait un systèmefonctionnel.
Ce sont ces grandeurs, très approximatives, qui ont été utilisées dans ce travail explora-toire. Il faudrait évidemment prendre des valeurs plus précises pour une application enproduction.
Voyons maintenant comment utiliser ces informations pour rechercher un bon algorithme dedétection.
13. Ce nombre peut changer en fonction du type de parité et de la longueur du préambule.
10 Recherche d’un algorithme
Pour qu’un système soit fonctionnel, il faudrait prendre en compte la détection de tousles SF, toutes les BP et détecter plusieurs LoRaMotes en même temps. Dans un premiertemps je me suis concentré sur un channel sur lequel on reçoit un signal de SF et BPdéterminés.
Lors de la réception d’un paquet une phase de synchronisation a lieu. Elle permet dereconnaître le début d’une transmission et de rentrer dans la machine d’états mais passeulement ; elle sert à synchroniser le récepteur sur le chirp de l’émetteur et à mettre en phasele downchirp qui va permettre de démoduler la suite du message. Les sauts de fréquences(fmax =⇒ fmin) vont également permettre de synchroniser la période Ts avec le début destemps symboles.
On retrouve une suite de nup−chirp suivit de 2down−chirp. Le nombre de upchirp peut variermais est communément de 8. La synchronisation, elle, est toujours composée de 2 downchirppuis suivent les symboles proprement dit.
Figure 10.1 – Exemple de préambule
Figure 10.2 – Spectrogramme du préambule (6+2)
Ce travail a pour but de timestamper un instant précis dans la réception d’un paquet LoRa.La phase de préambule est commune à tous les messages et sert à synchroniser l’émetteuret le récepteur. C’est donc dans cette zone qu’on cherchera à identifier un point précisreconnaissable.
10.1 Implémentation logiciel d’un simulateur
Pour vérifier les hypothèses et inspiré par un exemple d’algorithme en Matlab (blog SakshamaGhoslya)[5], j’ai ré-implémenté un modulateur/démodulateur en Python 1. Ce modèle permetde générer un signal modulé, un down-chirp, de les mixer et de comparer ce résultat avec lesacquisitions.
1. En utilisant Scipy, Numpy et matplotlib.
Chassot Sebastien, , septembre 2017 53/90
Figure 10.3 – Exemples générés par le simulateur
On retrouve bien les seuils correspondant aux symboles démodulés.
10.2 La fréquence d’exécution de l’algorithme
Un algorithme peut opérer dans le domaine temporel mais également dans le domainefréquentiel. Ce que nous cherchons est d’identifier une position dans le flux et déclencher lamémorisation du timestamp. Il n’est pas nécessaire de le faire instantanément mais s’il y aune latence elle doit impérativement être la même sur tous les systèmes. Un FPGA permetde garantir qu’un algorithme prend toujours le même nombre de coups d’horloge et sa latenceest donc stable.
L’algorithme peut être fait en comparant un échantillon au suivant mais généralement ontravaille sur un certain nombre d’échantillons (une fenêtre).
On peut utiliser des fenêtres juxtaposées mais généralement on superposera plus ou moinsles fenêtres.
Figure 10.4 – Juxtaposition des fenêtres
La fréquence à laquelle est exécuté l’algorithme dépend de la taille de la fenêtre et del’offset.
frequencedetection =samplerate · (offset)
windowsize
Quand l’offset = windowsize, la fréquence est de :
frequencedetection =samplerate
windowsize
et quand l’offset → 1, la fréquence tend vers :
frequencedetection = samplerate
Exécuter l’algorithme pour chaque nouvel échantillon (50millions/sec) demanderait trop deressources. Il va donc certainement falloir trouver un compromis entre la taille de la fenêtreet l’offset.
Figure 10.5 – transition up-chirp/downchirp
Ici la 1ère et la 4ème figures sont respectivement un up-chirp et un down-chirp alors que lesautres sont des transitions. Cet exemple montre un cas idéal où la fenêtre ne comprendqu’une fréquence (la fenêtre est parfaitement superposée avec la période Ts) mais ce ne serajamais le cas en pratique.
10.3 Première approche naïve (domaine temporel)
Nous savons qu’un signal à 868MHz n’est pas forcément un paquet LoRa mais c’est unévénement qu’on peut facilement détecter.
Vu que la modulation ne varie pas en amplitude, le module de chaque échantillon devraitêtre relativement constant.
‖amplitude‖ =√
I2 + Q2
Il suffit de fixer un seuil et de trigger dès que ce seuil est dépassé par n échantillonssuccessifs 2. Les samples sont sur 32bits (16bits I et 16bits Q) donc il suffit de faire attentionaux overflows.
Cet algorithme a été implémenté sur le FPGA avec succès. Comme attendu, les performancesne sont pas très bonnes. En regardant une acquisition de signal dans le domaine temporel,on peut remarquer que l’amplitude du signal suit une certaine pente.
Figure 10.6 – Exemple d’un signal échantillonné (un paquet LoRa)
Le seuil doit être au dessus du bruit et en dessousde l’amplitude supposée. Le seuil est donc atteintpendant cette phase de montée. Avec l’atténuationdu signal dû à la distance, l’amplitude ne sera pas lamême sur deux récepteurs éloignés. La détection sefait en des temps légèrement différents ; ce qui induitune erreur de mesure.
En jouant sur les gains au niveau des récepteurs onpeut améliorer la détection mais ça reste du brico-lage. Par contre cet algorithme est fait dans le do-maine temporel directement sur le signal. Il offre ledouble avantage d’être léger et facile à implémen-ter.
Cette algorithme reste relativement stable. En simulation, ajouter du bruit gaussien à lacapture ne fait varier la détection que de quelques échantillons 3. On obtiendrait égale-ment de bon résultat en normalisant le signal mais c’est compliqué de le faire en tempsréel 4.
2. Une fenêtre de taille n et d’offset = 1.3. ±50[sample] avec un bruit de 80dB.4. Il faut une fenêtre suffisamment grande.
Mesures
Les mesures effectuées tendent à prouver qu’un système DToA est possible.
Un émetteur a été placé à 5m des deux détecteurs et émet un paquet LoRa toutes les 3s.Voici ce que donne l’histogramme de 40 mesures.
Figure 10.7 – Exemples générés par le simulateur
On semble retrouver une distribution gaussienne centrée en zéro même si elle n’est pas trèsnette. Le système est en outre très vite perturbé. Il suffit de bouger un détecteur pour queles résultats varient beaucoup plus. Les tests ont été effectués en intérieur et les mesures sontsensibles aux obstacles. Il suffit de toucher une antenne pour que dt dépasse 3µs. Les deuxUSRP ont le même gain 5, mais le moindre changement donne des écarts de plusieurs µs. Lapreuve de principe est faite mais ne fonctionnerait pas aussi bien si les détecteurs étaientéloignés. Il faut donc chercher d’autres algorithmes plus fiables.
10.4 Utiliser la phase (domaine temporel)
Sur le diagramme de constellation on voit les échantillons tourner autour d’un cercle de rayonégal à l’amplitude. On remarque également la spirale (montée en amplitude).
5. Le gain du Low Noise Amplifier (LNA) interne.
Figure 10.8 – Inversion de chirp
Sur une acquisition on peut remarquer un changement de phase offrant une caractéristiquequi pourrait être identifiable.
Figure 10.9 – Changement de phase Figure 10.10 – Exemple de point remar-quable
On peut imaginer un algorithme basé sur une mesure angulaire.
θ1 < θ2 < (...) < θn−1 < θn > θn+1 > θn+2
Les angles croissent puis le phénomène s’inverse. En combinant cette caractéristique avec uneamplitude (inversion & amplitude>trigger ) on peut déclencher un évènement.
J’ai essayé de mettre en place un algorithme basé sur ce principe sans résultat. Cette partiedu signal ressemble à un passage par une fréquence de 0Hz ; or je n’ai pas retrouvé ce paternsur le modèle. La fonction utilisée dans le modèle théorique est scipy.signal.chirp() et diffèreapparemment de celui produit par un émetteur.
10.5 Produit de convolution (domaine temporel)
Une idée serait de faire un produit de convolution dans le domaine temporel avec commeréférence une partie du signal facile à reconnaître. Une difficulté est de faire une convolutionavec un signal non normalisé (en raison des différences de gains). Nous ne sommes pas sûrsnon plus que la corrélation fonctionnera sur différent modèles d’émetteurs. Mais il y a aussiune contrainte liée au matériel.
On peut placer les échantillons dans un buffer circulaire et le comparer à un signal stockédans un Block RAM. La difficulté va être de faire le produit de convolution en parallèle. Onpeut accéder à la mémoire de façon séquentielle mais pas massivement en parallèle ; il faudraitpipliner le produit de convolution. Réaliser ce type d’algorithme nécessiterait d’utiliserplusieurs cycles d’horloge et donc d’augmenter l’offset de la fenêtre.
10.6 Inversion de chirp (domaine fréquentiel)
En faisant une FFT sur le signal, on remarque que la fréquence va de gauche à droite pendantle up-chirp puis s’inverse pendant le down-chirp. Cet événement pourrait aussi servir derepère temporel. L’idée serait de rentrer dans une machine d’états (up-chirp) puis, dès qu’ily a n échantillons inversés successifs, le trigger est déclenché.
Par contre, la fréquence de détection serait au mieux égale à celle des FFT.
10.7 En détectant une transition (domaine fréquentiel)
Une dernière approche plus prometteuse serait d’utiliser une FFT et d’y chercher unetransition.
Figure 10.11 – FFT glissante
Faire une FFT revient à observer le signal pendant un laps de temps. Comme le chirpvarie pendant ce laps de temps, on retrouve une forme carrée. Faire la somme de cesfréquences revient à calculer l’énergie du spectre. Quand la fenêtre est à cheval entre deuxchirps! (chirps!), on voit un deuxième carré apparaître. En faisant la somme de chacun deces carrés, on obtient leur énergie respective. Le ratio des deux devrait correspondre à laposition dans la fenêtre.
x =∑
freq1∑
freq0
=a
b
La position serait x · windowsize. En augmentant le nombre de FFT on trouve un ensemblede position (x0, x1, ..., xn−1).
Un algorithme pourrait accumuler n mesures et en faire une moyenne
x =1n
n−1∑
i=0
xi · windowsize − i · offset
La valeur x est un décalage par rapport à la valeur du compteur (ref).
Cet algorithme n’a pas été testé pour des questions de temps mais il offrirait un boncompromis. La fenêtre devrait être plutôt grande (pour englober la transition) et l’offsetdéterminerait le nombre de mesures n. Le rapport ne dépend pas du gain mais uniquementdes fréquences.
11 Conclusions
Ce travail exploratoire s’articule autours de deux volets ; La synchronisation de systèmesdistants et l’identification d’un point précis dans un flux d’acquisition en temps réel.
Pour ce qui est de synchroniser des systèmes distants, l’objectif est pleinement atteint. Laqualité de l’horloge est très importante puisque les erreurs viennent principalement là. Avecun bon oscillateur l’erreur viendrait du GPS mais là encore on peut trouver du matériel plusprécis. La limite vient donc des moyens qu’on se donne et non d’une limitation de l’approcheelle-même. À noter que les compteurs ont été placés côte-à-côte parce qu’il est très difficilede les tester autrement. On suppose donc que le système garde sa précision grâce au réseauGPS.
Du côté de la détection le résultat est plus mitigé ; coupler un transciever et un FPGA estclairement une bonne approche. La partie SDR n’est pas indispensable. Il suffirait d’un ADCet d’un circuit ramenant le signal en bande de base. Il peut dès lors être intéressant de prendrele temps de développer un algorithme sur un FPGA puisque la tâche est très répétitive etdemande de bien maîtriser la latence. Néanmoins, la question de l’algorithme n’est pas réglée.Par manque de temps je n’ai fait que des propositions qu’il reste à explorer. Nous savions dèsle début qu’il n’y aurait pas le temps d’implémenter un algorithme robuste. L’algorithme naïffonctionne mais n’est pas suffisant. Il faut continuer les recherches.
On trouve sur Internet une multitude d’informations sur la trilatération. Une fois les co-ordonnées et distances connues, le calcul est trivial. La position des récepteurs peut êtreconnue à quelques mètres près et notre système DToA permet d’avoir les distances. Enaccumulant suffisamment d’informations on peut affiner la localisation. Avec un émetteurenvoyant plusieurs messages par minute, on obtient rapidement beaucoup de mesures et onpeut faire un traitement sur ces «big data». Il reste à voir comment déployer le système.Centraliser les data avec MQTT est une piste mais dans tous les cas, c’est une questiond’architecture logiciel qui ne remet pas en cause le principe du DToA.