LoRa Messenger

De Wiki LOGre
Aller à la navigation Aller à la recherche

Projet initié par : Philippe,
et mené par : Pascal, Yannick, Oliv', Jean-Pierre, Alexandre, Christophe, Camille, et d'autres.


Projet en cours.

But de ce projet

- J'ai en projet de faire un système de maillage de nœuds LoRa pour de la communication de type « texto », en décentralisé, sans LoRaWAN, chaque nœud pouvant être passerelle pour transmettre un message à plus longue distance par rebonds successifs.

- Pascal a proposé de m'aider, il est beaucoup plus compétent que moi dans le domaine en tant que radio-amateur, et il a déjà fait un projet pas trop éloigné, dans lequel il utilise un relais LoRa posé en montagne pour transmettre à une distance sensiblement plus grande que le device-to-device LoRa en rase-mottes.

État de l'art - Problématique

Choix d'une « distribution », d'une architecture

Premiers échanges du 17 novembre au 5 décembre 2022

Suite à la conférence d'Oliv', que je remercie au passage, j'envisage d'étudier la fabrication d'un système de messagerie basée sur LoRa. Je suppose que pour faire du point à point, genre SMS ou talkie-walkie textuel, il faut rester au niveau de LoRa et pas de LoRaWAN ?

Je trouve par exemple ceci : https://www.instructables.com/LoRa-Messenger-for-Two-Devices-for-Distances-Up-to/ C'est un module qui s'occupe juste de la communication entre 2 noeuds, avec pour interface un smartphone et une connexion USB.

Est-ce que vous connaissez d'autres projets similaires ? Il existe peut-être des modules LoRa plus au goût du jour que celui-ci ou des trucs encore plus simples à configurer ? Des remarques, commentaires, suggestions ? Connais tu Meshtastic ? Je ne sais pas ci tu recherche ce type de maillage. Christophe.

Non je ne connaissais pas, mais ça ressemble à ce que j'avais en tête... en mieux. Je vais regarder cela. Si je vois bien tout un protocole de communication en réseau est défini. Le routage se fait en inondation. Simple, il sature rapidement le canal radio. Il devrait fonctionner a peu près jusque 5 relais. Le routage configuré à distance me semble plus adapté, jusqu'à une trentaine de relais. Car les relais à terre ont une couverture très stable. Pascal.

Ça n'utilise pas les règles de radio-amateurs comme le projet qui a été discuté jeudi dernier ? Avec la licence, gratuite, toutes les bandes radioamateur sont utilisables avec des relais, en clair, et vers internet. La puissance autorisée (500W en UHF) atteint confortablement la lune. Pas possible de chiffrer et d'émettre depuis internet. Pascal.

Je vois que la payload est encryptée. Les bandes ISM sont libres en puissance limitée, ce qui suffit avec un point haut. J'ignore si le chiffrement et les relais sont libres en France. Maintenant, dans le cas d'utilisation d'une crise, on peut s'attendre à certains compromis. Pascal.

L'interface utilise un smartphone, une app Android ou IOS, et une liaison type BT, ou alors le système (?) Ils réduisent les coûts de clavier et d'écran dédié. Pascal.

La communication à longue distance se fait en utilisant les devices les plus proches comme relais ? Du coup est-ce qu'un module identique aux autres placé sur une falaise de Chartreuse avec un panneau solaire serait autonome (sans IHM) et permettrait de couvrir la vallée de Grenoble à Chambéry par exemple ? Le dégagement du point haut impacte directement la portée. Les tests de cet été en Grésivaudan montrent qu'au moins deux relais sont nécessaires pour couvrir le trajet Grenoble - Chambéry. Pascal.

Bref, ça a l'air beaucoup plus avancé que le petit projet que j'avais identifié pour du point à point sur Instructables, et où je me disais que la mise en place de relais LoRa serait nécessaire pour couvrir une zone géographique plus large. Mais ça semble être un peu plus onéreux et carrément plus complexe à construire et configurer... (?) Le relais solaire du Saint-Eynard coûte environ 40 €, batterie, panneau solaire, 18650, antenne et boîtier compris. Pascal.

L'avantage du projet Instructables est sa simplicité, pour démarrer, et son coût très modeste (pas de batterie, écran, clavier... puisque tout cela est pris en charge par le smartphone ou le PC connecté en usb. Discussion à poursuivre.

Je trouve le système meshtastic bien pensé, avec ses limites. Pascal

Roh, on l'a évoqué Jeudi dernier 😄 Dans les projets que je connais, mais il doit y en avoir d'autres :

Oliv'

Reste le firmware, et l'architecture de communication. J'aurais peut-être dû commencer par là, car cela peut conditionner le choix des éléments hardware. tu écrivais la semaine dernière "Je trouve le système meshtastic bien pensé, avec ses limites. " Tu pourras développer un peu ? Avantages, et limites ? Je regarde les autres fw et on en disculte. (Pascal)

Serais-tu partant pour tester cela ? Un des avantages serait peut-être de pouvoir s'intégrer dans la communauté Meshtastic et profiter de l'expérience de ce réseau... oui en tant qu’utilisateur. A vérifier comme développeur. (Pascal).

Si on part là-dessus, et avec un hardware préconisé sur leur site, ce sera un peu plus cher que d'assembler un MCU avec un module LoRa. Mais ça peut simplifier les choses. Une option serait le T-Beam intégrant slot-batterie, OLED, LoRa, GPS... (28$) , ou le TTGO LoRa (20$), comme celui que j'ai mais en 433 MHz (il faut lui ajouter un circuit de charge de batterie), mais ici encore, on maîtrise mal les taxes et duty... :-( Sinon on doit pouvoir utiliser Meshtastic avec d'autres éléments hardware ? J'ai porté rapidement 2 FW T-Beam vers un ESP32 + module Lora avec une interface SPI. (Pascal).

Je vois au passage que mon TTGO est en 866 MHz puisque je l'avais pris pour LoRaWAN. Donc pas idéal même pour des tests si on prend les autres terminaux en 433. 😕 A performance égales, la bande 433 passe mieux. (Pascal).

Autre option, parmi les propositions de Oliv', https://disaster.radio/ , qui n'est pas loin du cas d'usage que j'avais en tête (même si j'avais rien de vraiment précis) : une catastrophe naturelle dans la région, électricité et énergies indisponibles, comment on fait pour gérer les urgences ? J'apprécie l'archi et l'interface android.Le routage mesh me semble bavard. Le BLE me semble pas vraiment adapté.Un routage à la demande et le web en WiFi me semblent de meilleurs choix. On peut en discuter. Éventuellement, un itinéraire dans le message, saisi manuellement, pourrait suffire.(Pascal).

Pour utiliser ce firmware, un hardware pré-configuré comme ceci pourrait être pertinent. Mais en fait, j'ai l'impression que l'architecture est complexe, avec un serveur central par lequel passent les messages, des clients, et des middleware... le fait d'avoir un serveur central du réseau ne semble pas très résilient, mais j'ai peut-être mal compris. Pas d'internet, pas de cloud. Sans internet on se retrouve en off-grid. (Pascal).

Bref, voilà où j'en suis, commentaires et suggestions bienvenus, pour constituer une liste de courses qui amène un ensemble techniquement cohérent, facile à configurer, à tarif raisonnable, et facile à sourcer...

Tu trouveras ci dessous mes réflexions. Évidemment un FW fiable sur étagère nous ferait gagner du temps. Je penche pour la solution suivante : 

   - module ESP32 avec chargeur et Wifi + LoRa SPI + BMS + boitier 18650 et circuit imprimé. A mon avis, c'est actuellement la plus économique.
   - Les relais solaire sont en point haut. Ils assurent la couverture.
   - Chemin manuel de relais en relais contenu dans le message. Simple, la solution n'exige pas d'algorithme ni de configuration de routage. Le chemin est à la charge de l'utilisateur, qui sait s'adapter à l'état du réseau.
   - Terminal utilisateur avec serveur Web Wifi. Plusieurs utilisateurs utilisent simultanément le terminal.
   - La conservation des messages reçus est à la charge des utilisateurs.

Pascal

Salut Philippe, Je suis tombé par hasard sur deux projets qui se rapprochent de ce que tu veux faire : 

   Qmesh: description et code
   Cellsol

Écran : tout dépend de ce que tu veux faire; utilisation d'un téléphone comme interface ou le device doit se suffire à lui même ? L'ESP8266 est largement capable de supporter ce que tu veux faire, mais avec l'ESP32 c'est moins galère en deep sleep, ça devrait consommer moins (vérifier les chiffres), et tu as du BLE pour communiquer avec un téléphone sans avoir à brancher de câble USB dessus. Batterie: selon ton envie non ? Et si tu choisis de brancher ton device au téléphone, peut-être pas besoin ? Module LoRa: Il y a la série "E5" chez Seeedstudio qui doit pouvoir être expédiée plus facilement. J'ai demandé à quelqu'un chez RAK si ils n'ont pas une autre façon d'expédier, je vais peut-être aussi leur commander deux/trois choses. Sinon la société Murata fait aussi des modules intéressants, certainement disponible chez Mouser et consorts. Fréquence: je serais parti en 868 MHz pour pouvoir être compatible avec du LoRaWAN, si jamais les cartes servent en Europe, mais à vous de choisir

Oliv'

Deuxième temps : du 6 au 18 décembre 2022

Résumé de ce que je retiens des échanges précédents, puis proposition de commande groupée pour les intéressés.

En regardant divers projets de ce type, il semble que Meshtastic soit le plus avancé. On partirait donc là-dessus.

Les choix à arbitrer : 

   * 433 ou 868 MHz ?
       - 868 semble être le standard pour LoRaWAN, donc utilisable pour du simple LoRa.
       - 433 est autorisé aussi sans licence dans notre région (continent) et utilisé par les radioistes, ce qui génère des risques de se trouver étouffé sous une antenne radio "un peu plus puissante" que notre piti device LoRa.
       - 433 pourrait en théorie porter un poil plus loin, mais si peu...
       - Par ailleurs un module LoRa en 868 pourra être recyclé sur un projet LoRaWan si besoin.
       ==> Il semble donc que l'on s'oriente vers du 868 MHz.

   * Acheter une carte "all included", ou se faire un montage en assemblant des composants élémentaires, module LoRa, antenne, MCU de type ESP32, batterie+BMS, éventuellement petit écran, et panneau solaire.
       - Le premier critère est le prix. Les premières cartes toutes faites que l'on avait vues étaient entre 20 et 40€, alors que l'assemblage LoRa+ESP32+BMS peut être fait à partir de composants AliExpress entre 7 et 10€. Sur un proto c'est pas un gros problème, mais si l'on envisageait de fabriquer une petite série de terminaux, diviser par 2 ou 3 le prix global prend de l'intérêt.
       - Il y a en particulier sur AliExpress des modules tout prêts, avec même le firmware Meshtastic pré-installé, mais ça coûte dans les 40€ pièce.
       ==> l'option récemment proposée par Pascal, un ESP32+LoRa intégré, avec antenne mais sans écran je crois, et sans boîtier de pile ni bms.
       - Cela doit pouvoir fonctionner ainsi si alimenté par le smartphone en USB (dixit Oliv') quand tu veux juste communiquer. Mais dans ce cas il ne servira pas de relais lorsque déconnecté du smartphone, donc ajouter une alimentation "permanente" pour assurer le service de "relais" peut être intéressant.
       - Donc compléter a minima par une batterie 18650, à recharger lorsque nécessaire, ou maintenue en charge par un PV et un BMS.

Un ensemble possible : - ESP + LoRa + Antenne : https://fr.aliexpress.com/item/32850086038.html (13,20€) - BMS : https://fr.aliexpress.com/item/1005003192132429.html (0,20€) - PV : https://fr.aliexpress.com/item/32874460660.html (3,60€) - support de batterie: https://fr.aliexpress.com/item/1005004486418738.html (0,50€) Le tout à placer dans une boîte ad-hoc, étanche si on veut la laisser au soleil... et à la pluie.

Cela devrait suffire pour faire quelques protos (?). Si j'oublie un truc, ou d'autres idées ou propositions n'hésitez pas !

Composants

Voir aussi pour les caractéristiques des différents modèles : https://github.com/Xinyuan-LilyGO/LilyGo-LoRa-Series

Électronique

Par Pascal :

J'ai trouvé des infos intéressante sur le site https://meshtastic.org/

Mes protos sont dérivés du Ttgo Lora V1, le FW Meshtastic devrait être compatible sans retouche.

J'utilise :

Mes protos utilisent une plaque à trous et des fils.

J'ai regardé les modules Lora qui intègrent le micro contrôleur. Meshtastic supporte le stm32wl5e qui a une puce lora en mezzanine. Probablement les modules avec ce microcontrôleur.

Quelqu'un a déjà fait faire des circuits imprimés ?

Pascal

Pour les modules je ne suis pas à jour, tu peux regarder chez RAK avec le firmware modem: https://docs.rakwireless.com/Product-Categories/WisDuo/RAK3172-Module/Quickstart/#product-configuration, je peux t'en prêter un si tu veux.Le RAK4200 doit aussi pouvoir le faire. Je crois que la puce ST a aussi un firmware AT, à voir si c'est uniquement LoRaWAN ou LoRa aussi, NUCLEO-WL55JC2. Sinon en carte toute prête tu peux regarder l'Arduino MKR WAN 1300. Oliv'

Suite à notre discussion de jeudi dernier, voici ce que je trouve...

MCU :

bien chers pour un ESP32 sans LoRa. Bien vérifier la carte contient un composant BMS. Car une surveillance de tension du firmware peut avoir un bug. J'ai entendu que des batteries LI-ION qui ont été détruites. Je fais confiance à l'ESP32 lite V1.0. Il a un chargeur d'accu 5V et une LED. https://fr.aliexpress.com/item/1005001798732324.html J'ajoute un module LoRa, un boitier 18650 et un BMS. Pascal.

de plus, j'ai un ttgo T3 LoRa32 qui me reste. Ça devrait me permettre de commencer à voir si j'arrive à installer un firmware en attendant les autres éléments (?). Il est dans les prix, Il intègre un SX1276 à 433MHz. J'utilise depuis un an ces modules LoRa RA-02 vendus par 5. https://fr.aliexpress.com/item/1005003814965939.htm Pascal.

Les questions techniques, pour faire les terminaux de communication...

  • écran utile, ou pas ? A mon avis l'écran est très inspiré des montages des années 80. De nos jours, l'interface wifi vers smartphone ou tablette offrent plus de souplesse pour la saisie, le copier coller et le scroll entre autres. Un serveur web dans l'ESP avec quelques pages suffisent. Pascal.
  • esp8266 suffisant ou ESP32 préférable ? Les FW que je connais sont passés à l'ESP32. Psacal.
  • connecteur d'alimentation ou alimentation par le port usb, moyennant un boost en sortie de batterie ? Tous les circuits que je rencontre et que je réalise sont en 3.3V avec un Li-Ion 3.6V et un chargeur USB. Pascal.
  • mieux si batterie intégrée ou pas ? A mon avis, le support 18650 offre la meilleure autonomie avec des accus chargés interchangeables à portée de main. Pascal.
  • si batterie intégrée, le "bms" y est-il en général ou il faut prévoir de l'ajouter ? J'ai toujours un BMS avec un Li-Ion, sinon gare à la durée de vie. Il est souvent intégré à l'accu. Les éléments 18650 que j'utilise en sont dépourvus. Un modèle 1S 1.5A suffit.

J'utilise ces BMS vendus par 10. https://fr.aliexpress.com/item/1005003192132429.html Pascal.

Module LoRa 433MHz, à associer à l'ESP : Oliv' proposait le RAK3172, il a l'air bien documenté, et tarif raisonnable (6$), pourquoi pas ? Juste... les frais de port sont assez élevés (25$), et ils mentionnent un "import duty tax" qui n'est pas explicitée... donc si on garde ce fournisseur on fera une commande groupée !! Ou si tu as d'autres propositions ? Si c'est possible de modifier le firmware du STM32, le module pourrait s'utiliser sans carte microcontrôleur externe. J'utilise depuis un an ces modules LoRa RA-02 vendus par 5. Ils ont une interface SPI. https://fr.aliexpress.com/item/1005003814965939.htm Pascal.

"Circuit de charge" de batterie, versus "carte de protection", versus "BMS" : quelle différence ? Par exemple

versus

versus

versus

J'y comprends encore pas grand chose.

  • 'xS" signifie qu'on y branche x piles en série ? oui. S2 = 2 éléments en série, S3 = 3 éléments en série, ... , S12 = 12 éléments en série. Pascal.
  • et dans ce cas, il y a toujours des points de connexion intermédiaires pour gérer l'équilibrage de charge de chaque élément ? Je ne les vois pas toujours sur les cartes ci-dessus. Ils sont visibles. Ils s'appellent B-, B1, B2, ... , B+. Pascal.
  • '40A' signifie que ça supporte 40 ampères max en décharge (??) Oui.
  • 'balance' et 'Enhance' sur la 2e référence, ça change quoi ? Balance égalise la charge, je ne connais pas enhance, il me parait marketing. Pascal.

Certains montages intégrant un TP4056 assurent à la fois le rôle de chargeur ET de BMS. (Francis) Je comprends dans cette phrase qu'il ne suffit pas qu'un module intègre le TP4056 pour gérer correctement la décharge. Du coup la question que j'essaie de résoudre depuis plusieurs jours, est la suivante : "Est-ce que ce circuit fait l'affaire ?"... https://fr.aliexpress.com/item/1005004581200820.html Philippe

Oui (Francis)

Oui, car ils intègrent un transistor pour couper la batterie de la charge quand la tension descend trop bas. On les reconnaît souvent car les bornes batterie et charge sont différentes. Oliv'

Consommation

Yves Pratter a écrit : 

  La v1.3 semble ne pas exister sans écran, disons que je ne trouve pas pour l'instant.

Tu peux enlever l'écran et l'utiliser dans un autre projet. Mais si tu veux une utilisation à terme sans smartphone c'est utile de le garder. Mais c'est quoi qui consomme sur la carte ? ça vient de l'ESP ? Comment être économe en courant ? Comparison between Lora V1.3 and Lora V1.0 : 1.Product low power design 2.Optimize LORA RF circuit 3.Add battery voltage detection Pin IO35

Source : http://www.lilygo.cn/prod_view.aspx?TypeId=50060&Id=1253&FId=t3:50060:3 En fait Liligo a plusieurs produits similaires. Je le confondait avec le TTGO T-Beam qui a un récepteur GNSS ! >http://www.lilygo.cn/products.aspx?TypeId=50060&FId=t3:50060:3&pageindex=2

Côté conso, l'écran du TTGO est allumé, il est actif en permanence, et mon testeur USB annonce entre 50 et 60 mA. Donc il faudrait voir aussi comment gérer correctement la conso... Pour le device final, mas sûr que l'écran intégré soit vraiment utile... peut-être, mais indispensable certainement pas. Donc si on prenait un device avec écran il faudrait voir comment le désactiver. (Philippe).

Il y a un réglage pour l’écran, le mien s’éteint au bout de 10 minutes je crois, il faudra voir ce que ça change pour la consommation. (Yannick) Oui, je l'ai passé à 60s, mais quand il s'éteint ça ne change pas grand chose à la conso semble-t-il... (Philippe)

Les tests que j'ai faits la semaine dernière (10 décembre) m'ont permis de faire tourner le TTGO et Meshtastic qui envoyait un paquet toutes les minutes (vu dans les logs), pendant 40h. Noter que en situation d'autonomie élec, le facteur limitant sera probablement de maintenir le smartphone capable de dialoguer avec le TTGO Meshtastic ! (Philippe)

Je serais intéressé pas le résultat d'une expérience : imaginons que pour une raison ou une autre les capteurs solaires ne soient pas en mesure de recharger l'accu.... (mettre un cache devant) l'accu va se décharger et tel qu'il est sans protection (https://fr.aliexpress.com/item/1005001636454870.html) il va passer en dessous de 2.5v et destruction assurée. Avec le bms il va couper. Quand on est arrivé à cet état, on enlève le cache des panneaux pas en plein soleil mais dan un ciel sous nuages. Le 4096 va recharger l'accu le bms va à nouveau libérer la fourniture de courant MAIS les panneaux ne vont pas assez débiter pour un démarrage correct du micro-contrôleur qui va être dans une situation où il est dans l'impossibilité de lancer un programme interne donc il ne pourra pas se mettre en deepsleep... et même si après la pluie vient le beau temps et un ensoleillement suffisant pour alimenter le microcontrôleur ET l'accu seule un reset manuel du microcontrôleur lui permettra de se relancer correctement. C'est ce que j'ai expérimenté... 

Est-ce que ton montage fera bien pareil ?

J'ai imaginé de bloquer le micro par un KA75330 sur la pin reset mais il a un hystérésis trop faible... Pas trouvé (au sens achat par pièce unique à un prix raisonnable et surtout un port du même style : chinois ou rs particulier le WE) de puce ayant une valeur de bascule plus haute comme 3.6v permettant d'avoir une batterie assez chargée pour que le micro démarre correctement.

Pour l'instant j'ai contourné l'obstacle de façon fonctionnelle mais qui augmente la consommation électrique : un digispark (qui démarre à 3.3v), consomme peu et dont le programme lit la tension et à celle qui me convient avec un mosfetP libère l'alim vers le montage (ou même en fonction de cette tension à des montages divers) en fonction de celle-ci. Francis

Avec un FW optimisé, l'ESP LoRa consomme environ 15mA en réception et 160mA en émission. J'ai mesuré 5 jours d'autonomie avec une cellule 18650 (capacité non précisée). Pascal

Voir aussi : https://fr.wikipedia.org/wiki/LoRaWAN#Consommation_%C3%A9nerg%C3%A9tique

Antennes

Pour une « base » on peut utiliser une antenne performante de 12 éléments 1/2 lamba (1,60 m) J’ai une antenne réalisée par Pawel pour le projet OGN.

D’autres antennes sont proposées sur la page du projet Open Glider Network.

Yves

Divers

Au fait, quel est le satellite HAM qui permet de recevoir et renvoyer des paquets Lora ? (Yves) Je cherche le lien vers le satellite amateur LoRa, c'est du 433. 73 de F5TLA. (Pascal)

Tests

Meshtatstic propose une configuration de test entre modules : https://meshtastic.org/docs/settings/moduleconfig/range-test

Voir ici des programmes de tests tout prêt : https://github.com/StuartsProjects/SX12XX-LoRa

Câblage

BMS

J'aimerais bien comprendre le système d'alimentation du TTGO T3_V1.6 dont je dispose pour mes tests.

Je l'alimente souvent par l'USB pour les tests, mais comment l'alimenter correctement par batterie ? On avait prévu un BMS... est-il vraiment utile, ou la carte intègre-t-elle nativement tout ce qu'il faut ?

Il y a un petit connecteur sous la carte, où l'on est sensé connecter une pile 18650. Mais pas clair comment est géré cet accu...

Sur le github de Lilygo, je trouve le schéma : https://github.com/Xinyuan-LilyGO/LilyGo-LoRa-Series/blob/master/schematic/T3_V1.6.pdf On y trouve un circuit "TP4054" : http://igotalongdomainname.com/data/uploads/tp4054-42pdf.pdf (si j'ai bien identifié, le composant est marqué "LTH7B") Sur le schéma on voit aussi le connecteur qui serait de type "PH-2-WO". Du coup si je connecte l'accu sur ce connecteur, est-ce que le TP4054 gère correctement la charge et la décharge de l'accu ? Et de quelle manière, avec quelles tensions de seuils ? J'ai un peu de mal de décoder la datasheet du TP4054 ... :-(

Il y a une courbe de "Complete charge cycle", mais je ne vois pas beaucoup d'infos sur la décharge...

Je vois "VUV" qui est défini comme le "Vcc Undervoltage Lockout Threshold" qui est en "typic" 3.6V : est-ce cela la tension minimale acceptée pour l'accu ? Mais il y a aussi "VMSD" le VCC Undervoltage Lockout Threshold, qui a deux valeurs, selon PROG Pin Rising ou PROG Pin falling, à 3.5V ou 2.0V, ce qui signifie ?

Et en première ligne du tableau, il semble accepter en entrée entre 4V et 9V...

Donc ensuite, est-ce que l'on peut connecter un panneau solaire 6V sur l'entrée de l'interrupteur principal (SK-12D02) de la carte (équivalent à l'alime de la prise µUSB), qui semble connectée directement sur le "VBUS" "5V" donc "VCC" du TP4054 ?

Philippe

Flashage du firmware

Flasher le firmware Meshtastic

Sous Windows (?)

Chez moi ce soir, sur cette carte tout neuve, j'ai réussi. Voici ce que j'ai fait :

  • Sur le site https://meshtastic.org/ "Install Serial Drivers", ESP32...
  • j'ai vérifié le driver "Silicon Labs CP210x USB to UART Bridge";
  • Flash Firmware / ESP32 / Web-based Installer Tlora-v2-1-1.6 (ça ressemble un peu aux réf de ma carte)
  • j'ai sélectionné la version firmware "V2.0.3.09fe616" et "wipe and reinstall device"

Et c'est passé avec succès.

Sous Debian en CLI

https://meshtastic.org/docs/software/python/flasher Installer python3, pip et venv : 

python3       # version >= 3.6
apt update
apt upgrade
apt install -y python3 python3-pip python3-venv

Installer Meshtastic Flasher

  1. change to a directory where you want to create a python virtual environment
mkdir some_dir
cd some_dir
  1. if the following command fails, it might tell you what package to install
python3 -m venv venv
  1. activate the python virtual environment
source venv/bin/activate
  1. your prompt should change - it should include "(venv) in the front
  2. upgrade pip
pip install --upgrade pip
pip install meshtastic-flasher

Running Meshtastic Flasher 

meshtastic-flasher

The Meshtastic Flasher will flash the latest firmware on esp32 and nrf52 devices. This is a newly developed application (as of February 1, 2022), so there may be some issues discovered as it is tested by users. Il y a 3 étapes : 

   1. Click the GET VERSIONS button to get the versions available (from GitHub). Malheureusement, il n’y a pas à ce jour (15/01/2023) de version correspondant à 1.6.xx
   2. Click the DETECT DEVICE button to determine the port and device variant connected. Là non plus, on ne trouve pas le composant T3 qu’on a acheté ; on se rabat sur le modèle XXX
   3. Click the FLASH button to flash the version selected using the port selected to the device. Ça marche mais il y a des erreurs. ??? Et la ligne de commande ne se déconnecte pas à la fin...

Fin pour Debian

Suite de Philippe

J'ai ensuite pu m'y connecter en BT à partir du smartphone via l'appli Meshtastic. Là j'ai saisi mon "nom", qui a modifié mon Id de connexion semble-t-il, j'ai aussi choisi la "région" --> EU_868.

Il me reste à voir comment configurer les canaux de communication, et autres paramètres... J'ai un peu de mal d'interpréter les infos sur le smartphone et sur l'écran du TTGO. Il y a #LongFast-I , avec un QR-code associé, qui est peut-être un canal par défaut (?) La géolocalisation doit être possible via le GPS du tél, mais je ne sais pas si elle est transmise juste aux membres du même canal, ou à tout le réseau ? Pour l'instant je me sens seul 😛 dans la région : Sur la carte je me vois, avec comme légende "Philippe ?" (y compris le '?'.

Côté conso, l'écran du TTGO est allumé, il est actif en permanence, et mon testeur USB annonce entre 50 et 60 mA. Donc il faudrait voir aussi comment gérer correctement la conso... Pour le device final, mas sûr que l'écran intégré soit vraiment utile... peut-être, mais indispensable certainement pas. Donc si on prenait un device avec écran il faudrait voir comment le désactiver.

Changement de canal

Nouveau canal créé.

C'était "difficile", car le changement de canal est verrouillé par sécurité. Il faut donc trouver le cadenas au milieu de l'écran... Ça va mieux en lisant le manuel ;-) J'ai donc créé un canal "LOGre" accessible via le lien suivant (à ouvrir avec l'appli Meshtastic), ou aussi transmissible aux membres du réseau par un QR-code généré dans l'appli (qui pointe au même endroit). https://meshtastic.org/e/#CikSIEThdjBVvFZ_lwp2qtYFjZvg6hylApkR505ohKcI2EF5GgVMT0dyZRIKCAE4A0ADSAFQGw

Tests de communication

Suite à l'impulsion de Pascal, et avec Yannick et Camille, on a testé Meshtastic --> la solution semble opérationnelle, malgré quelques comportements parfois instables. On pense donc essayer de configurer ce réseau dans la région.

Suite à quelques essais et échanges ce jeudi soir 15 décembre à La Casemate, on a décidé de partir sur une carte intégrée, la même sur laquelle on a fait les premiers tests ce jeudi : https://fr.aliexpress.com/item/32872517875.html

On a finalement réussi à démarrer les 3 cartes et à se connecter à 3 personnes sur le même canal, avec envoi de quelques mini-messages sans grande imagination (glop, burp, etc...). On a pu aussi envoyer un message direct à une personne connectée, sans passer par un broadcast sur le canal. Par contre, je crois qu'on n'a pas encore tout compris sur la configuration. Des fois le bluetooth ne répond pas des fois oui, des fois on ne peut pas partager sa localisation, des fois oui, l'appli IOS est assez différente de l'appli Android, pas sûr de quand et comment le device se met en veille et comment il se réveille, etc. --> Encore un peu de boulot pour que ce soit maîtrisé et donc fiable.

Voici le montage de test qui tourne chez moi depuis ce matin, avec 2 petits panneaux "3V - 180mA" en série.

Meshtastic & 2 PV.jpg

Couverture

Pour les essais, je suis partant pour installer en point haut un relais sur batterie autour de Grenoble. Le relais solaire du Saint-Eynard coûte environ 40 €, batterie, panneau solaire, 18650, antenne et boîtier compris. Pascal

Très intéressant ces échanges. Si vous souhaitez je suis prêt à mettre un relais avec antenne 13db du côté de la cote st André si une liaison est possible avec la cuvette en passant par la chartreuse. J ai une omni ou directive de dispo. (Christophe)

Est-ce que quelqu'un sait s'il serait possible d'installer un relais sur le fort des 4 seigneurs ? Toujours propriété du CEA qui chercherait à s'en séparer ? (Jean-Pierre)

Si jamais vous avez une carte en trop je suis preneur pour en faire un relais à Meylan, bien placé avec une bonne antenne externe. Par contre vous confirmez que vous êtes partis sur du 868 MHz ? (Oliv')

Normalement Pascal va préparer des relais en 868MHz, qui devraient être placés sur des points hauts de la vallée. Comme discuté jeudi dernier, pour couvrir la vallée du Grésivaudan, de la métro de Grenoble à Pontcharra, il en faudra probablement un de chaque côté de la vallée. Pascal me parlait de la Tour Sans Venin qui couvrirait très bien Echirolles, et il proposait aussi Revel, qui pourrait couvrir de Sassenage à Seyssins d'un côté, et jusque Crolles de l'autre côté. Il pense que de Tencin je pourrais capter la Tour Sans Venin puisque je l'ai à vue... mais ça fait loin quand même, il faudrait que je m'installe sur le toit à côté de la cheminée qui supporte l'antenne râteau !! Après on pourrait chercher où mettre un relais sur le Plateau des Petites Roches, qui devrait voir celui de Revel et couvrir ensuite toute la rive gauche de jusque Pontcharra. Tout cela c'est sans compter que chaque terminal peut aussi être configuré pour servir de relais dans le maillage Meshtastic, donc si il y a un bon réseau de devices connectés, pas besoin de relais supplémentaires. Néanmoins des relais en points hauts amélioreront de tout façon la couverture de manière très importante.

Comment les paramètres LoRa affectent la portée

Lu sur Github https://github.com/StuartsProjects/SX12XX-LoRa/blob/master/What%20is%20LoRa.md

Après avoir établi une bande passante LoRa pratique, disons 62,5 kHz, nous pouvons utiliser cette base pour examiner comment le facteur d'étalement affecte la portée et le temps de transmission d'une charge utile de 20 octets.

Les facteurs d'étalement les plus faibles donneront les débits de données les plus élevés et les paquets les plus courts en termes de temps, ce qui à son tour est plus économe en batterie. Le facteur d'étalement le plus bas que nous considérerons est 7.

Supposons que nous utilisions une bande passante de 62,5 kHz et un facteur d'étalement de 7, ce qui donnera un débit de données équivalent de 2734 bps, selon l'outil 'LoRa Calculator' de Semtech. Le temps mis pour transmettre nos 20 octets est de 98 ms. Supposons que c'est notre base et que dans une zone urbaine typique la limite de réception est de 500 m.

Si nous passons au facteur d'étalement 12, le débit de données chute à 146 bps et le temps de transmission monte à 2,2 secondes, il s'agit donc d'un paquet lent. L'avantage du facteur d'étalement plus élevé est significatif, nous avons maintenant environ 14 dB de gain de signal supplémentaire. Cela équivaut à 5 fois plus de portée, donc notre 500 m s'étend maintenant à 2,5 km. L'outil 'LoRa Calculator' fournit les chiffres de gain de signal pour différentes combinaisons de facteur d'étalement et de bande passante.

Une distance 5 fois plus longue peut ne pas sembler beaucoup, mais appréciez la différence que cela peut faire pour la puissance de transmission requise pour couvrir la distance supplémentaire. Si nous transmettions à 10 mW et que cela nous donnait la portée de 500 m, pour couvrir 5 fois plus de portée simplement en augmentant la puissance d'émission, il faudrait un émetteur émettant 25 fois les 10 mW ou 250 mW.

Débits de données

Le débit de données le plus rapide dont un appareil LoRa UHF SX127x est capable est de 37 500 bps. Le débit de données le plus bas est de 18 bps, mais la bande passante à ce débit, 7,8 kHz, serait difficile à utiliser. Optimisation du faible débit de données

Lors de la réception d'un paquet de données, le récepteur se verrouille sur le préambule du paquet afin de synchroniser le décodage des données suivantes. Pendant la durée de réception des paquets, seule une faible variation de fréquence du signal transmis est autorisée. Si la fréquence de l'émetteur dérive de plus d'environ 1,5 % de la bande passante LoRa utilisée, il peut y avoir des erreurs de réception de paquets.

Malheureusement, il y aura une petite quantité de dérive de fréquence pendant la transmission causée par le dispositif LoRa dans le chauffage de l'émetteur car l'appareil dissipe la puissance utilisée par l'émetteur. L'échauffement provoque une légère dérive de la fréquence de l'oscillateur à quartz. Plus la puissance d'émission est élevée, plus l'échauffement est important et plus la dérive de fréquence est importante. En mode longue portée, où les paquets peuvent prendre une seconde ou plus à envoyer, l'effet de chauffage est alors plus important.

Des problèmes similaires peuvent survenir lorsque la différence de fréquence entre l'émetteur et le récepteur se produit en raison du décalage Doppler qui peut se produire dans les communications entre des véhicules se déplaçant rapidement, par exemple. Pour contourner ces problèmes, pour les paquets qui sont lents à transmettre et qui ont un temps de symbole de 12 ms ou plus, un indicateur d'optimisation est défini. Si vous utilisiez une bande passante de 62,5 kHz, l'indicateur d'optimisation doit être défini sur un facteur d'étalement de 10 et plus.

RSSI contre SNR

Les appareils LoRa peuvent fournir à la fois l'indication de la force du signal reçu (RSSI) et le rapport signal sur bruit (SNR) d'un paquet reçu. Alors que vous pourriez être tenté d'utiliser le RSSI comme indicateur de la force du signal reçu, pour les signaux faibles, c'est-à-dire ceux qui approchent de la panne, le RSSI est un mauvais indicateur.

En pratique, le SNR rapporté est un indicateur beaucoup plus utile d'une défaillance de liaison imminente. Si la limite SNR pour le facteur d'étalement que vous utilisez est de -10 dB, un paquet reçu signalant un SNR de -4 dB est à moins de 6 dB de l'échec. Des mesures de distance simples à effectuer peuvent montrer qu'avec 6 dB (10-4) de marge de liaison de signal restante, vous pouvez vous attendre à recevoir un paquet à environ deux fois la distance.

Limites SNR pour le facteur d'étalement.

SF7 -7.5dB SF8 -10dB SF9 -12.5dB SF10 -15dB SF11 -17.5dB SF12 -20dB

Exploitation des données en télémétrie

Sur l'appareil d'arrivée, si celui-ci ne communique qu'en WiFi avec le réseau local, activer la fonctionnalité MQTT de façon à ce que les messages passent du LoRa au serveur MQTT (par défaut). Pour récupérer ensuite les messages sur un serveur, on peut installer Node-RED https://nodered.org/ ou Mosquito.

Commande groupée

Après sondage rapide, il nous faut une dizaine de TTGO, qui seront partagés entre Camille (3), Jean-Pierre (3), Philippe (2), Fred (1), éventuellement Yannick (1?). Du coté des frais de port, ils s'envolent au delà de 9 exemplaires. Je vais passer une commande de 7 et Camille en commande 3 de son côté. Si quelqu'un en veut quelques unités complémentaires, dites-le rapidement... soit j'en ajoute 1 ou 2, soit c'est Camille si il n'a pas encore passé sa commande.

Je commande aussi des petits BMS 1S de ce type, qui devraient permettre de fonctionner sur batterie avec charge par USB et/ou petit panneau solaire. Je m'en prends un lot de 5 en micro-USB. Il est aussi dispo en USB-C. Si quelqu'un en veut dites-le aussi...

Enfin, je vais prendre un lot de panneaux solaires 6V 250mA. L'idée est de maintenir un niveau de charge à un device en autonomie sur 2 ou 3 jours par exemple. Je me garderai 4 panneaux, les 6 autres seront dispos, dites-moi qui en veut ??

Par ailleurs, je ne pense pas qu'un panneau de cette puissance crête suffise pour alimenter un relais de manière fiable toute l'année, donc pour les relais, soit il faudra acheter plus puissant, soit en mettre au moins deux (?).

Chronologie

  • 22/01/2023 : premiers tests à distance (>5km), entre Alexandre et Philippe
  • 18/12/2022 : lancement de la commande groupée
  • 15/12/2022 : premiers tests à 3 modules à la Casemate à quelques mètres
  • 06/12/2022 : jusqu'à cette date, premiers échanges sur la messagerie
  • 14/11/2022 : lancement du projet par Philippe.
  • 10/11/2022 : 3e soirée LoRa - LoRaWAN animée par Oliv'
Récupérée de « https://wiki.logre.eu/index.php?title=LoRa_Messenger&oldid=23699 »