Le concept #

Il est intéressant de savoir si un objet connecté est bien reçu ou non par une passerelle.

Pour cela, le processeur lora envoie sa position toutes les 10 secondes par exemple. Si la trame est reçue par une passerelle lorawan du maillage local, le serveur du fablab la recevra et pourra la traiter.

En bout de traitement de la trame, Grafana, grâce à son extension GéoMap, montrera une carte OpenStreetMap à un point horodaté montrant l’endroit où le système était localisé quand il a été reçu par une passerelle du maillage local.

De cette manière, en déplaçant le traqueur GPS, on voit sur la carte jusqu’où il est reçu. Ce sera une bonne indication pour savoir si le maillage est efficace.

La visualisation des données GPS #

La carte Grafana est visible ici

Si l’on vous demande une connexion, l’identifiant est « invite » et le code est « invite« .

La carte est mise à jour lorsque le module GPS envoie ses information de position.

Exemple d’un déplacement autour d’une passerelle Lora DRAGINO DLOS8N placée « indoor » . La fréquence de travail est de 868Mhz avec quelques milli watts en émission pour le transmetteur mobile Lora. D’où l’obligation de positionner les antennes des passerelles Lora de manière très dégagée car en milieu urbain le rayon de réception se rétrécit vite à quelques centaines de mètres.

Dans cet exemple, le signal a été reçu jusqu’à 230m et de manière fugitive à 500m, puis retrouvé à 220m.

L’action de Grand Paris Sud et l’écosystème LoRaWAN #

Grand Paris Sud affiche une volonté claire de développer les usages numériques sur son territoire, notamment autour des réseaux bas débit pour les objets connectés.
Dans ce cadre, le déploiement d’un maillage LoRaWAN constitue un levier particulièrement intéressant : peu énergivore, longue portée, robuste, et bien adapté aux besoins des collectivités comme des acteurs locaux.

Un tel maillage permet de connecter des objets répartis sur de larges zones urbaines ou périurbaines sans recourir à des infrastructures lourdes ou coûteuses, tout en conservant une excellente autonomie énergétique côté capteurs.

Le réseau Lora et le protocole LoRaWAN #

Le réseau Lora s’inscrit dans cette logique de déploiement LoRaWAN à l’échelle d’un territoire.
Il repose sur le protocole LoRaWAN, un standard ouvert largement utilisé dans le monde de l’Internet des objets (IoT).

Rappels sur le protocole LoRaWAN #

LoRaWAN est caractérisé par :

• une communication longue portée (plusieurs kilomètres en zone dégagée),
• un débit faible, mais suffisant pour des données de capteurs,
• une excellente autonomie (plusieurs années sur batterie),
• un fonctionnement en étoile : les objets communiquent directement avec les passerelles, sans routage intermédiaire.

Les passerelles reçoivent les trames radio et les transmettent vers un serveur réseau, qui se charge :

• de l’authentification des objets,
• de la déduplication des trames (plusieurs passerelles peuvent recevoir la même émission),
• de la redistribution des données vers les applications.

À quoi peut servir un réseau LoRaWAN territorial ? #

Un réseau comme Lora peut être utilisé pour connecter une grande variété d’objets :

Exemples d’usages concrets #

• capteurs environnementaux (température, humidité, qualité de l’air),
• suivi de consommation (eau, gaz, électricité),
• capteurs de présence ou d’occupation,
• supervision d’équipements urbains,
• stations météo locales,
• suivi d’objets mobiles (véhicules, vélos, balises GPS),
• projets pédagogiques et expérimentaux dans les fablabs et établissements scolaires.

Dans le cadre du projet décrit ici, le tracker LoRa + GPS permet précisément de valider la couverture réelle du réseau, en conditions terrain, bien au-delà de simples cartes théoriques.

La notion de maillage LoRaWAN #

Le maillage LoRaWAN ne fonctionne pas comme un réseau maillé classique (mesh), mais plutôt comme une superposition de zones de couverture.

• Plus il y a de passerelles, plus la réception est fiable.
• Une même trame peut être reçue par plusieurs passerelles simultanément.
• Le serveur réseau choisit automatiquement la meilleure liaison pour les réponses éventuelles.

En déplaçant le tracker GPS, on obtient donc une vision très concrète de la qualité du maillage, rue par rue, quartier par quartier.

Open source, fablabs et réseaux ouverts #

L’un des grands intérêts de LoRaWAN est son ouverture :

• le protocole est public,
• de nombreuses briques logicielles sont open source,
• il est possible de déployer un réseau libre et gratuit, parallèle ou complémentaire aux réseaux opérés.

Dans un contexte fablab ou associatif, cela permet :

• d’installer des passerelles LoRaWAN ouvertes,
• d’héberger son propre serveur réseau ou applicatif,
• de mutualiser l’infrastructure entre plusieurs projets,
• de favoriser l’innovation locale et l’expérimentation.

Un maillage ouvert, bien documenté et partagé, peut devenir une ressource numérique commune, au service des citoyens, des écoles, des associations et des collectivités.

---

Conclusion #

Le couplage d’un module LoRa et d’un GPS, associé à une chaîne de traitement moderne (serveur LoRaWAN, base de données, Grafana et GeoMap), constitue un outil simple mais extrêmement puissant pour :

• évaluer l’accessibilité réelle aux passerelles,
• qualifier l’efficacité d’un maillage LoRaWAN,
• appuyer des décisions de déploiement ou d’extension du réseau.

Ce type de démarche illustre parfaitement comment des technologies ouvertes, associées à des initiatives locales comme celles de Grand Paris Sud et des fablabs, peuvent contribuer à un numérique territorial maîtrisé, utile et partagé.

Construction #

Le système est simple. Il s’articule autour d’un module lora et d’un module GPS Néo 6M qui communique avec ses ports TX et RX et ceux du module lora htcc-ab02a de Heltec.

🧪 Maquette d’essai GPS LoRa sur plaque à trous #

Cette maquette a pour objectif de valider rapidement le fonctionnement d’un ensemble GPS + LoRa, avant toute intégration définitive sur circuit imprimé ou boîtier.
Elle permet de tester à la fois :

• la réception GPS,
• la transmission LoRa,
• la consommation électrique,
• et la cohérence des données affichées localement et transmises vers l’infrastructure logicielle.

---

Les éléments principaux de la maquette #

La maquette est construite sur une plaque d’essai à trous (breadboard), ce qui permet :

• des modifications rapides,
• des essais comparatifs,
• une visualisation claire des liaisons.

On y distingue trois blocs principaux :

📡 Module LoRa HTCC-AB02 #

Le cœur du système est un module LoRa HTCC-AB02 (CubeCell), qui intègre :

• un microcontrôleur basse consommation,
• un transceiver LoRa,
• une alimentation adaptée aux usages longue durée.

C’est ce module qui :

• reçoit les données GPS,
• les encode,
• les transmet via LoRa vers TTN.

Un petit écran OLED est connecté au module afin d’afficher en local :

• l’identifiant du module,
• la tension batterie,
• la latitude,
• la longitude,
• l’altitude.

Cela permet un diagnostic immédiat, sans dépendre du réseau.

---

🛰️ GPS externe NEO (antenne déportée) #

Un module GPS de type NEO est utilisé, avec :

• une antenne GPS externe, indispensable pour une bonne réception,
• un positionnement libre sur la plaque d’essai.

Ce GPS fournit :

• latitude,
• longitude,
• altitude,
• via une liaison série classique.

---

🔌 Alimentation et instrumentation #

L’alimentation est distribuée via la plaque d’essai.
La tension batterie est mesurée par le module LoRa et affichée à l’écran (ici autour de 4,0 V), ce qui permet :

• de vérifier la stabilité,
• d’anticiper les tests d’autonomie.

---

Connexions entre les modules #

🔄Liaison GPS ↔ LoRa #

Le GPS est relié directement en UART au module LoRa :

• TX GPS → RX LoRa
• RX GPS → TX LoRa
• Masse commune

Aucune interface complexe n’est utilisée à ce stade :

• pas de bus I²C,
• pas de SPI,
• uniquement une liaison série fiable et éprouvée.

👉 Ce choix simplifie le décodage et limite les sources d’erreur lors des essais.

---

ℹ️ À propos de la résistance visible #

Une résistance est visible sur le montage.
À ce stade :

• elle n’intervient pas dans la communication GPS
• elle n’est pas utilisée pour le fonctionnement courant

Elle est prévue pour un usage ultérieur :

• identification matérielle du module,
• différenciation de plusieurs balises,
• ou détection d’un numéro de module par lecture analogique.

👉 Elle est donc volontairement ignorée dans le fonctionnement actuel.

---

Fonctionnement global de la maquette #

Le fonctionnement est volontairement simple et robuste :

1. Le GPS acquiert une position et calcule latitude, longitude et altitude.
2. Les données sont envoyées en série au module LoRa.
3. Le module LoRa :
   • affiche les informations sur l’écran OLED,
   • encode les données,
   • transmet les trames via LoRa.
4. Les données sont ensuite récupérées côté réseau (TTN), traitées et stockées.

La maquette permet ainsi de valider toute la chaîne, du signal satellite jusqu’à la base de données.

---

Intérêt de la plaque d’essai pour ce type de projet #

Ce montage sur breadboard présente plusieurs avantages clés :

• modification rapide du câblage,
• ajout ou suppression de composants sans dessoudage,
• observation directe du comportement réel,
• excellente base pour le débogage matériel et logiciel.

C’est une étape essentielle avant :

• la conception d’un PCB,
• la réduction de taille,
• l’optimisation énergétique.

---

✅ Conclusion #

Cette maquette d’essai constitue une plateforme de validation complète pour un module GPS LoRa :

• architecture simple,
• séparation claire des fonctions,
• instrumentation locale (écran),
• transmission distante fiable.

Elle permet de confronter rapidement la théorie à la réalité du terrain, avant toute industrialisation ou déploiement longue durée.

Le programme téléversé dans le module Lora #

Le code est disponible sur MASTER-htcc-ab02a_gps_neo6m_lorawan

On peut utiliser Visual Studio Code et son extension PlatformIO qui intègre aussi un module d’intelligence artificielle (IA) pour corriger votre code .

🧠 Description détaillée du programme “Tracker GPS LoRaWAN (HTCC-AB02 + GPS NEO + OLED)” #

Ce programme transforme un module CubeCell HTCC-AB02 (ASR6502) en tracker GPS LoRaWAN. Il lit en continu les trames NMEA d’un GPS externe, en extrait latitude/longitude/altitude via TinyGPS++, mesure la tension batterie, affiche les informations sur un OLED SH1107, puis envoie périodiquement une trame LoRaWAN vers TTN.

L’architecture est organisée autour de trois blocs fonctionnels :

1. Acquisition : lecture UART du GPS + décodage TinyGPS++
2. Présentation locale : affichage OLED des valeurs utiles
3. Transmission : construction d’une trame binaire compacte (12 octets) et envoi LoRaWAN (OTAA)

---

Dépendances et bibliothèques #

Le programme s’appuie sur :

• LoRaWan_APP.h : framework LoRaWAN spécifique CubeCell (gestion du join, send, cycle, sleep, etc.)
• TinyGPS++.h : parseur NMEA (décode position, satellites, altitude, validité…)
• Wire.h + HT_SH1107Wire.h : driver I2C de l’écran OLED SH1107

L’écran est instancié ainsi :

SH1107Wire oledDisplay(0x3c, 500000, SDA, SCL, GEOMETRY_128_64, GPIO10);

• adresse I2C : 0x3c
• fréquence I2C : 500 kHz
• géométrie : 128×64
• pin reset : GPIO10

---

Matériel cible et ports utilisés #

GPS sur UART1 (Serial1) #

Le GPS NEO est lu via Serial1 à 9600 bauds :

static const uint32_t GPSBaud = 9600;
Serial1.begin(GPSBaud);

Le code lit les octets disponibles et les passe à TinyGPS++ :

gps.encode(Serial1.read())

TinyGPS++ met à jour en interne :

• gps.location.lat() / .lng()
• gps.altitude.meters()
• gps.satellites.value()
• gps.location.isValid() (validité du fix)

OLED alimenté via Vext #

Le module CubeCell fournit une broche Vext (alimentation externe commutable).
Le programme active Vext au démarrage :

void VextON() { pinMode(Vext, OUTPUT); digitalWrite(Vext, LOW); }

Sur CubeCell, la logique est :

• LOW = ON
• HIGH = OFF

👉 Ça permet d’alimenter l’OLED (et éventuellement d’autres périphériques) uniquement quand nécessaire.

---

Structure du programme #

Le fichier contient :

• Un en-tête très documenté (objectifs, format trame, matériel)
• Des fonctions utilitaires (conversion, extraction de fraction)
• La fonction centrale prepareTxFrame() qui :
  • lit batterie
  • lit GPS (si valide)
  • prépare trame binaire appData[]
  • met à jour l’écran OLED
• Une configuration LoRaWAN (OTAA/ABP, clés, région, cycles, etc.)
• Un setup() d’initialisation hardware + écran + GPS
• Une loop() basée sur la machine d’état LoRaWAN du framework

---

Encodage des données : trame LoRaWAN 12 octets #

La trame envoyée (appDataSize = 12) est conçue pour être compacte et facile à décoder côté serveur (Node-RED / TTN / Influx).

Batterie (2 octets) #

Tension en millivolts sur 16 bits, big-endian :

uint16_t batteryVoltage = getBatteryVoltage();
appData[0] = (uint8_t)(batteryVoltage >> 8);
appData[1] = (uint8_t)batteryVoltage;

Latitude (4 octets) et longitude (4 octets) #

Le programme sépare :

• un octet “partie entière” ((uint8_t)gps.location.lat())
  • 3 octets de fraction (6 décimales * 10^6), stockée sur 24 bits

appData[2] = (uint8_t)(gps.location.lat());
appData[3] = frac_lat >> 16;
appData[4] = frac_lat >> 8;
appData[5] = frac_lat;

appData[6] = (uint8_t)(gps.location.lng());
appData[7] = frac_lng >> 16;
appData[8] = frac_lng >> 8;
appData[9] = frac_lng;

La fraction provient de :

int fracPart(double val, int n){
  return (int)((val - (int)(val)) * pow(10, n));
}

Le abs() est utilisé pour éviter les valeurs négatives sur la fraction.

Remarque importante (technique) : cette méthode suppose implicitement des coordonnées positives (France OK). Si un jour tu veux gérer longitude Ouest ou latitude Sud, il faudra ajouter le signe ou utiliser un encodage signé.

Altitude (2 octets) #

Altitude en mètres, signée (int16_t) big-endian :

int16_t altitude = (int16_t)gps.altitude.meters();
appData[10] = (uint8_t)(altitude >> 8);
appData[11] = (uint8_t)altitude;

Cela permet des altitudes négatives (ex : sous le niveau de la mer).

Cas GPS non valide #

Si gps.location.isValid() est faux :

• l’OLED affiche “GPS: waiting…”
• tous les octets GPS + altitude sont mis à zéro
• seule la tension est réellement informative

---

Affichage OLED : rôle et contenu #

L’OLED sert d’interface de debug terrain : on peut vérifier “en local” ce qui sera transmis.

Dans prepareTxFrame() l’écran est mis à jour avec 5 lignes :

1. Module : “lora-03”
2. Bat : tension batterie en mV
3. Lat : latitude 6 décimales
4. Lng : longitude 6 décimales
5. Alt : altitude en mètres (1 décimale)

Exemple :

oledDisplay.drawString(0, 0, "Module: lora-03");
sprintf(line2, "Bat: %d mV", batteryVoltage);
sprintf(line3, "Lat:%.6f", gps.location.lat());
sprintf(line4, "Lng:%.6f", gps.location.lng());
sprintf(line5, "Alt:%.1fm", gps.altitude.meters());

Puis affichage effectif :

oledDisplay.display();
delay(3000);

👉 Ce délai de 3 s rend l’affichage lisible, mais ralentit volontairement le cycle CPU. (Sur un tracker à ultra-basse conso, on pourrait le réduire ou afficher uniquement à la demande.)

---

Configuration LoRaWAN (OTAA, EU868, duty cycle) #

Le programme est prévu en OTAA.

Les identifiants OTAA sont définis dans le code :

• devEui[] (ici “lora-03”)
• appKey[]
• appEui[] (mis à zéro)

Il y a également des clés ABP (nwkSKey, appSKey, devAddr) présentes dans le fichier, mais elles ne sont pas utilisées si le mode OTAA est actif.

Période d’envoi #

La variable de cycle est :

uint32_t appTxDutyCycle = 15000;

Donc un envoi toutes les ~15 s (avec un petit aléa ensuite).

Le framework calcule le prochain cycle :

txDutyCycleTime = appTxDutyCycle + randr(0, APP_TX_DUTYCYCLE_RND);
LoRaWAN.cycle(txDutyCycleTime);

Puis mise en veille :

LoRaWAN.sleep();

---

Initialisation (setup) #

Le setup() :

1. démarre Serial (debug)
2. initialise la carte (boardInitMcu())
3. configure des GPIO, active Vext
4. initialise l’OLED
5. affiche un écran “lora-03” pendant 5 s
6. affiche “tout est OK” pendant 2 s
7. démarre Serial1 pour le GPS

On a donc un “self-test visuel” très pratique au démarrage.

---

Boucle principale (loop) et machine d’état LoRaWAN #

La loop() est construite autour de la machine d’état deviceState du framework CubeCell :

• DEVICE_STATE_INIT : init LoRaWAN
• DEVICE_STATE_JOIN : join OTAA
• DEVICE_STATE_SEND : prépare trame + send
• DEVICE_STATE_CYCLE : planifie prochaine émission
• DEVICE_STATE_SLEEP : sommeil

La particularité (importante) : cette machine d’état n’est exécutée que lorsque gps.encode() retourne vrai (donc quand TinyGPS++ “termine” le décodage d’une phrase).

Schéma :

while (Serial1.available() > 0) {
  if (gps.encode(Serial1.read())) {
    switch(deviceState) { ... }
    return;
  }
}

👉 Conséquence pratique : tant que le GPS “cause” correctement (NMEA), la machine d’état s’exécute très régulièrement.
C’est cohérent pour un tracker “GPS-driven”.
Si un jour tu veux que le join LoRaWAN se fasse même sans GPS, on déplacerait la machine d’état hors de ce if (gps.encode()).

---

Points clés pour l’article (à mettre en avant) #

• Trame binaire courte (12 octets) : optimisée pour LoRaWAN, simple à décoder côté serveur.
• Affichage local : parfait pour valider un fix GPS, la tension, l’altitude avant même d’ouvrir Grafana.
• Cycle + sleep : le framework CubeCell gère la planification et la mise en veille, ce qui prépare bien les futurs tests d’autonomie.
• Extensible multi-modules : le code contient déjà des variantes commentées (ex. lora-04), ce qui facilite la duplication.

🛰️ Suivi GPS d’un module LoRa avec Node-RED et TTN #

Cet article décrit le fonctionnement d’un flow Node-RED dédié à la réception, au décodage et au stockage des données GPS émises par un module LoRa (LoRa-03), en s’appuyant sur The Things Network (TTN) et InfluxDB pour la persistance, puis Grafana pour la visualisation.

L’objectif est de disposer :

• de la position GPS (latitude, longitude, altitude),
• de la tension d’alimentation du module,
• des indicateurs radio (RSSI, SNR),
  le tout de manière fiable et exploitable dans le temps.

Réception des trames LoRa depuis TTN #

Pour récupérer le « flow » NodeRed ici

Le point d’entrée du flow est le nœud :

eu1.cloud.thethings.network

Il assure :

• la connexion au cluster TTN (EU1),
• la réception des messages uplink envoyés par le module LoRa-03,
• la transmission du message brut TTN (JSON complet) dans le flow Node-RED.

Un nœud de type debug (“arrivée du serveur TTN”) permet de visualiser ponctuellement le contenu des trames reçues pour le diagnostic.

Sélection du module LoRa concerné #

Le nœud commuter (switch) joue un rôle clé :

• il filtre les messages selon l’end_device_id,
• il achemine uniquement les messages du module LoRa-03 vers ce flow GPS,
• il prépare l’extension future vers d’autres modules (ex. LoRa-04).

👉 Cette séparation évite toute confusion entre plusieurs balises LoRa actives simultanément.

Décodage des données GPS (latitude, longitude, altitude)

Le cœur du traitement se fait dans la fonction :

lat long et altitude

Cette fonction :

• récupère le tableau d’octets decoded_payload.bytes fourni par TTN,
• reconstruit :
  • la latitude (degré + fraction sur 3 octets),
  • la longitude (degré + fraction sur 3 octets),
  • l’altitude (entier signé sur 16 bits, big-endian),
• normalise les valeurs pour une utilisation directe.

Le résultat est regroupé dans un seul message :

{
  "latitude": …,
  "longitude": …,
  "altitude": …
}

Ce choix est volontaire :

• une seule mesure InfluxDB,
• un timestamp unique,
• une exploitation Grafana beaucoup plus simple (cartographie, jauges, graphiques).

Stockage de la position GPS dans InfluxDB #

Les données GPS sont ensuite envoyées vers InfluxDB via le nœud :

[v1.x] localhost:8086 / lora gps-03

Caractéristiques :

• une mesure unique gps-03,
• des champs :
  • latitude
  • longitude
  • altitude
• horodatage automatique côté InfluxDB.

Ce schéma est idéal pour :

• l’affichage cartographique (Geomap Grafana),
• l’historique de déplacement,
• l’affichage de l’altitude instantanée.

Préservation des octets LoRa pour les mesures “parallèles” #

Comme la fonction GPS remplace volontairement msg.payload (pour simplifier l’écriture Influx/Grafana), on ajoute un nœud intermédiaire avant la branche GPS :

SAUVE_BYTES

Son rôle :

• copier decoded_payload.bytes dans une zone durable du message (msg.bytes),
• permettre aux fonctions annexes (température, tension, etc.) d’extraire leurs données sans dépendre de msg.payload (qui peut changer).

Principe :

• msg.bytes devient la référence unique et stable pour toutes les extractions par octets.

Mesure complémentaire : température DHT22 (tempDHT) #

En parallèle du GPS, le flow traite la température DHT22 transmise sur les 2 derniers octets de la trame.

Fonction dédiée : tempDHT #

Cette fonction :

• lit le tableau d’octets depuis msg.bytes,
• extrait la température sur 2 octets (int16 signé, big-endian),
• applique l’échelle ×10 (ex : 234 → 23,4°C),
• prépare un msg.payload propre pour InfluxDB (uniquement des nombres).

Résultat injecté :

{
  "temperature": …
}

👉 Le point important est volontaire : tempDHT ne propage pas le JSON TTN, elle fabrique un payload minimal, compatible InfluxDB (évite les erreurs du type [object Object]).

Stockage InfluxDB de la température #

La température est écrite dans une mesure dédiée (par exemple) :

• mesure : temp-03
• champ : temperature

Ce schéma est optimal pour Grafana :

• requête simple,
• pas d’ambiguïté sur les champs,
• affichage immédiat en “Time series” avec l’unité °C.

Mesures complémentaires : tension et qualité radio #

En parallèle du GPS (et sur le même principe de “payload minimal”), le flow traite d’autres informations essentielles :

🔋 Tension d’alimentation

Fonction :
lora-03 tension

• extraction de la tension mesurée sur le module,
• écriture dans une mesure InfluxDB dédiée (ex. lora-03-tension),
• surveillance de l’autonomie et de l’état énergétique.

📶 Qualité radio

Deux fonctions dédiées :

• RSSI : force du signal reçu
• SNR : rapport signal/bruit

Elles permettent :

• d’évaluer la qualité de la liaison LoRa,
• d’anticiper des problèmes de couverture,
• de corréler position / qualité radio.

Visualisation et exploitation #

Grâce à cette structuration :

Grafana peut afficher :

• la position GPS sur carte,
• la trace des déplacements,
• l’altitude sous forme de jauge ou graphique,
• la température du boîtier GPS (courbe),
• la tension et les indicateurs radio dans le temps.

Le flow est évolutif :

• ajout d’un LoRa-04 déjà prévu,
• duplication simple pour d’autres balises,
• mutualisation TTN / Influx / Grafana.

---

✅ Conclusion #

Ce flow Node-RED illustre une chaîne complète et robuste :

LoRa → TTN → Node-RED → InfluxDB → Grafana

• pensée pour la lisibilité, la maintenance et l’évolution,
• adaptée à des usages terrain (balise GPS mobile, essais radio, suivi d’objets),
• avec séparation claire des fonctions (GPS, tempDHT, tension, RSSI, SNR),
• et regroupement cohérent des données GPS dans une seule mesure.

La stratégie “payload minimal pour Influx” (une mesure = des champs numériques propres) garantit la stabilité à long terme, tout en permettant d’ajouter facilement de nouveaux capteurs/indicateurs.

📊 Visualisation des données GPS LoRa dans Grafana #

Cet article décrit comment Grafana exploite les données issues d’un module LoRa GPS (LoRa-03), stockées dans InfluxDB, afin de fournir :

• une lecture instantanée de l’altitude,
• une visualisation cartographique de la position et de la dispersion GPS dans le temps.

L’objectif n’est pas seulement l’affichage, mais la compréhension du comportement réel du GPS (stabilité, dérive, bruit, conditions de réception).

---

D’où viennent les données affichées par Grafana #

Grafana ne reçoit aucune donnée directement.
Il agit comme un client de visualisation qui interroge une base de données.

Dans ce projet, la chaîne est :

Module LoRa → TTN → Node-RED → InfluxDB → Grafana

Grafana va donc chercher ses données exclusivement dans InfluxDB, via une datasource configurée en InfluxQL.

---

Organisation des données dans InfluxDB #

Les données GPS du module LoRa-03 sont stockées dans une mesure unique :

gps-03

Cette mesure contient :

• latitude (float)
• longitude (float)
• altitude (int ou float)
• un timestamp InfluxDB automatique (temps de réception)

Cette organisation permet :

• des requêtes simples,
• des affichages synchronisés,
• une exploitation cohérente sur plusieurs panels.

---

Affichage de l’altitude instantanée (jauge) #

🎛️ Panel “Altitude” #

Le premier panel visible sur le dashboard est une jauge affichant l’altitude instantanée.

Requête InfluxQL typique : #

SELECT LAST(altitude) AS altitude
FROM "gps-03"
WHERE $timeFilter

Fonctionnement : #

• LAST(altitude) récupère la dernière valeur connue,
• $timeFilter s’adapte à la période sélectionnée (ex. 5 minutes),
• la jauge est mise à jour à chaque nouvelle trame GPS.

Intérêt : #

• lecture immédiate,
• vérification de cohérence (terrain plat / bâtiment / dénivelé),
• utile pour diagnostiquer des erreurs GPS ou des pertes de fix.

---

Visualisation cartographique des positions GPS #

🗺️ Panel Geomap #

Le deuxième panel est une carte Geomap, affichant l’ensemble des points GPS reçus sur une période donnée.

Requête InfluxQL utilisée : #

SELECT time, latitude, longitude
FROM "gps-03"
WHERE $timeFilter
ORDER BY time ASC

Paramétrage clé : #

• Location mode : Coords
• Latitude field : latitude
• Longitude field : longitude
• Layer : Markers
• Opacity élevée pour visualiser la densité

---

Pourquoi on observe un “nuage” de points #

Sur l’image, les points ne sont pas parfaitement superposés :
ils forment un nuage dense, sur quelques dizaines de mètres.

Ce phénomène est normal et très instructif :

• bruit intrinsèque du GPS,
• qualité variable de réception satellite,
• environnement (bâtiments, végétation),
• précision du module GPS embarqué.

👉 La carte ne montre pas un déplacement réel, mais la dispersion statistique de la position autour d’un point fixe.

---

Ce que Grafana permet d’analyser visuellement #

Grâce à ce type de dashboard, on peut :

• évaluer la stabilité du GPS,
• comparer différentes configurations (antenne, firmware),
• mesurer l’impact des conditions radio LoRa,
• valider la cohérence altitude / position.

Grafana devient ici un outil de métrologie, pas seulement d’affichage.

---

Synchronisation avec le sélecteur de temps #

Le sélecteur en haut à droite (ex. Last 5 minutes) agit sur :

• la jauge d’altitude,
• la carte GPS.

Cela permet :

• d’observer la position instantanée,
• de zoomer sur une période courte,
• ou au contraire d’élargir à plusieurs heures pour voir la dérive.

---

Architecture propre et évolutive #

Ce dashboard est conçu pour évoluer facilement :

• ajout d’un autre module GPS (LoRa-04),
• ajout de couches (RSSI, SNR, couleur par altitude),
• affichage de trajectoires ou de points récents uniquement.

La séparation claire :

• stockage (InfluxDB),
• traitement (Node-RED),
• visualisation (Grafana),

garantit une maintenance simple et une lecture fiable des données.

---

✅ Conclusion #

Grafana ne se contente pas d’afficher des chiffres :
il met en évidence le comportement réel d’un système GPS LoRa, dans ses conditions d’utilisation réelles.

Couplé à InfluxDB et Node-RED, il constitue un outil extrêmement puissant pour :

• tester,
• comparer,
• comprendre,
• et améliorer les performances d’une balise GPS connectée.