Reprise du message précédent :
Sur Rhône-Alpes (01, 07, 26, 38, 42, 69 - mais aussi 03, 43, 73 et Suisse), Gaulix expérimente Meshcore.
Je vais tester de flasher mon Heltec ce soir, et je pense que je vais dépenser quelques euros dans une station fixe (avec panneau solaire) + 2/3 devices mobiles.

Ici c'est plat, urbanisation plate (max R+1) et étalée, beaucoup de forêt.
Chaque amélioration de portée est appréciée. D'où des premiers tests pas foufous sur Meshcore par chez nous pour l'instant.
Ca implique de densifier les répéteurs, avec probablement plus de zones blanches qu'en Meshtastic Long_mod.
Pour l'instant peu de clients/messages donc tout va bien, mais je ne suis pas super serein sur le futur.

 
C'est flou, c'est ou ici ?  

C'est clair.
 
Le bon choix est un mix entre SF, CR et BW adapté à l’environnement. Le LongFast était sans doute parfait à l’origine pour les grands territoires US et ue ferme tous les 25 km. Gaulix est une approche de radioamateurs en faisant fi de l’air-time : les ondes doivent voyager le plus loin possible. Cependant, les messages se perdent par collision de paquets.  
 
Avec la multiplication des nœuds Meshtastic, le preset qui saute aux yeux aujourd’hui pour des pays européens est MediumFast, choisi d'ailleurs par les italiens et une partie des suisses.
 

J’ai un avis mesuré sur Meshcore. C’est tout nouveau tout beau, hype et désinformations
 
MC se voudrait devenir un grand réseau social qui utilise un support de transmission autre que le net ou la téléphonie. Il ne faut pas rêver, vu la bande passante et la puissance d’émission autorisées.
 
Les deux systèmes ne fonctionnent pas fondamentalement de manière différente. MC utilise aussi le routage par inondation pour déterminer le chemin à emprunter entre les répéteurs.
 
Le principal reproche à MT est la limite de 7 sauts alors que MC en permet 64. D’après ce que j’ai compris, MT a introduit le Zero-Cost Hops pour les routeurs, ce qui permet même d’aller au-delà de 64 sauts.
 
Par ailleurs, depuis la version 2.6, une nouvelle forme de routage appelée Next-Hop Routing a été introduite pour les messages directs. Cela signifie que si une confirmation d’un message direct arrive, les nœuds se souviennent de l’itinéraire pour les transmissions ultérieures.
 
Je passe les discussions sur la License MITT de MC où il m’est difficile de trier le bon grain de l’ivraie.
 
MT souffre d’un preset inadapté avec la multiplication des nœuds, principalement en France avec LongModerate, des rôles de nœud pas toujours pertinents et des télémétries trop bavardes. Il convient de mettre à jour régulièrement son matériel pour profiter des dernières évolutions et améliorer la diffusion.
 
Le côté positif est que MC oblige l’équipe de développeurs MT à s’ouvrir.  
 

Si tu savais... Je suis même surpris que depuis le temps et toutes les photos que j'ai posté, tu n'aies pas mon adresse exacte

C'est pour ça que je teste activement les 2 avant de me lancer tête baissée dans l'une ou l'autre des solutions.
La limite à 7 sauts me bloque un peu dans MT,notamment parce que j'ai bon espoir de pouvoir contacter des membres de ma famille via LoRa... mais ça risque d'être compliqué en moins de 7 sauts.
Je ne voudrais pas non plus lancer ma commune dans un projet bancal où on n'arrive à contacter personne, (mais les problèmes se présentent de tous les côtés) :
- par manque de sauts
- par manque de portée
- par sur-utilisation airtime

 
Le mieux le réseau MT est coordonné par zone / région, le plus de client il y aura et le moins de sauts sera nécessaire.
L'une des bonnes pratiques : -> une zone condensé de Client = 3 sauts-> une zone périphérique à la zone condensée = 5 sauts-> les nodes aux extrémités de la zone condensée et celle périphérique = 7 sauts** il faut limiter au max les clients à 7 sauts

Il faut que les routeurs à max 1 sauts soient mutuellement en favoris = se coordonner
* idem pour le gag des Client_Base & les routeurs : il faut que chacun soit favoris de l'autre à max 1 saut
(mais que le Client_Mute ait en favoris le Client_Base en direct)
... et il faut le firmware 2.7.17.9058cce Alpha

Avec firmware 2.7.17.9058cce Alpha.

Intéressant le coup des routeurs favoris les uns des autres pour faire un espèce de backbone.

Dans ma campagne les nœuds les mieux placés risquent d'être soit en plein centre (église, château d'eau,...) soit en périphérie isolés, ce qui d'après ce que j'ai pu lire jusqu'à présent est déconseillé pour un rôle de routeur.

Par exemple on imagine les châteaux d'eau de x communes, au centre des communes, ça ferait une bonne vase pour des routeurs favoris entre eux... Mais avec le risque qu'ils se prennent 99% du trafic et donc en cas de crise tombent très vite à cause du duty-cycle.

Avec MT, rien n'est figé ; avec une bonne coordination, le mesh évolue correctement.

Il est tout à fait envisageable, dans un premier temps, de mettre un rôle Client_Base sur églises / château d'eau, sur lesquels des Client_Mute les mettent en favoris ou encore de le mettre en Routeur_Late.
Puis dans un second temps, ce Node au centre d'une zone, en rôle Client Infrastructure (mode client en cochant la case infrastructure pour ne pas qu'il reçoivent de message)

Le role Routeur n'est à installer qu'à partir de 500m d'altitude mini, tout évitant d'en avoir un autre à moins de 100km (120km idéalement) en ligne de vue.

Je me pose une question : ça donne quoi du Lora dans l'eau ?
 
Si je veux faire un réseau de capteurs étanches dans un lac par exemple, ça se transmet bien, comme dans l'air ?

 
Je n'ai aucune expérience précise mais ce que j'imagine :
- propagation eau <-> eau, éventuellement ça peut peut-être fonctionner. Les ondes se propageant en général très bien dans l'eau, il faut juste voir ce qu'il faut en terme de matériel, je ne suis pas sûr qu'une antenne classique fonctionne (aucune idée).
- propagation eau <-> air : ne fonctionne pas ou très très mal. Peut-être quelques cm/m avec un peu de chance
- le plus logique : sondes dans l'eau, remontées vers une boîte à la surface avec l'antenne aérienne qui va bien.
- au dessus de l'eau la propagation est généralement bonne car il n'y a pas d'obstacle. Il faut juste éventuellement monter un poil pour compenser le rayon de courbure de la terre si tu as des très grandes distances.

 
Routeur_late sur un château d'eau, ce qui me chagrine c'est qu'en long_moderate -> 240 124 messages par heure et après terminé. En cas de crise j'ai peur que ça soit bloquant. Vu que c'est le nœud le mieux placé que tout le monde captera probablement, il va répéter absolument tous les messages.
 
C'est quand même dommage que la techno ne permette pas d'émettre/écouter avec différents presets en même temps, ça serait super pratique. Genre par défaut tout est en short_turbo (ou équivalent) et s'il n'y a pas de confirmation de réception (ou d'écoute d'un autre relai pour les messages vers les canaux) hop ça réémet en medium_fast, puis si besoin en long_fast et ainsi de suite.
Ou que certains liens soient en long_moderate (grandes distances par ex) et d'autres en short...
Peut-être la prochaine génération de puces

C’est un peu bizarre ce que tu indiques
.. quelles sont tes sources ?
... elles datent de quand, avec quelle version de firmware ?!

Pourquoi parler de Long Moderate ?
Pourquoi "240 messages par heure et après terminé" ??

Router_Late ne passe en action QUE si d'autres n'ont pas répété/propagé le message

 
 
La dernière fois que j'ai voulu, cela ne marchait pas. J'ai la version offline https://sx1272-lora-calculator.soft [...] ownloading
 
(mais ca marche plus sous mon wine, j'ai viré les .NET et j'ai une connexion internet ... discutable, donc j'arrive pas à reinstaller pour tester )
J'ai les même valeurs que toi (et pas celles du site semtech)
 

 
Le LoRa support le débit continu. Je suppose que c'est ta question.

 
- long_mod : parce que c'est ce que gaulix utilise/recommande par défaut. 2.9 secondes par message (cf posts de Bersac fin de page précédente) / 10% de duty cycle = 600 360 secondes par heure -> 360/2.9 = 124 messages par heure max.
- routeur_late répète toujours, même si ça a déjà été rémis par d'autres clients.
 
sources :
https://meshtastic.org/docs/configuration/radio/device/
Router_late : Infrastructure node that always rebroadcasts packets once but only after all other modes, ...
et tests sur https://k2xap.radio/meshtastic/managed-flooding
 
D'ailleurs on voit un cas (en cliquant sur B) ou malgré une configuration cohérente avec seulement les clients qui servent réellement, on n'arrive pas à contacter un nœud pourtant à 3 sauts (O) parce que S a réémis le dernier saut vers d'autres nœuds que celui du destinataire et que ça a été entendu par T qui annule donc son envoi alors qu'il aurait pu joindre O. J'avais vaguement déduit que si on ne mettait que des client on évitait ce genre de souci, mais en fait non

En théorie, dans le cas de LongModerate avec un ToA de 2,9 s environ, un nœud peut émettre ou réémettre 124 transmissions par heure du fait de la limite règlementaire ; en passant, c'est 10 fois plus en MF.
 
Cependant, les modems LoRa sont half duplex ; ils ajoutent un délai entre (édit) émission et réception. Par ailleurs, MT ou MC font leur sauce et ajoutent encore du temps.
 
Le nombre réel max de messages transmissibles par un nœud est donc difficile à estimer précisément, sans mesures. Je partirais au doigt mouillé sur 60 à 80 par heure dans mon exemple.
 

Merci pour ton retour. Regarde plutôt mon dernier tableau posté en FP. La formule de calcul a dû changer depuis.
 
Edit 2 : l'estimation ci-dessus montre les limites, même avec des répéteurs. MC ne fera pas de miracles.
 
J'en profite pour poster un bréviaire trilingue suisse sur les bonnes pratiques à adopter pour améliorer collectivement un réseau.

Oulala je ne sais plus calculer 10% d'une heure. My mistake, c'est en effet 124 messages par heure, encore pire.

Sinon, pour revenir sur le choix du preset, ça dépend vraiment de la configuration terrain.
Comme dit plus haut, chez moi ou c'est plat + forêt, le besoin d'un max de distance est réel si on veut couvrir par exemple des zones blanches en forêt. Donc un preset genre LM est tentant, parce que ça répond bien à ce besoin. Les communes sont espacées, l'étalement urbain important...
A l'inverse, dès que tu es dans un centre un peu plus dense où il est facile de mettre des nœuds sur les mats d'antennes TV existants tous les 500m, c'est clair que ça n'a pas de sens d'être en LM, autant parce que la densité de population augmente (donc potentiellement les messages) que par le besoin de portée.
 
C'est donc forcément compliqué de choisir un preset. Je pense que le LM de gaulix faisait sens notamment au début, où avec peu d'utilisateurs, la surcharge n'est pas un souci et autant profiter d'une portée plus grande pour le même prix (moins de répéteurs).
Et quand l'utilisation commence à augmenter, ça se corse, mais en général on a naturellement plus de "répéteurs" aussi, donc un maillage plus dense, donc c'est plus facile de basculer sur un preset plus rapide.

On n'a pas évoqué pour le moment l'entête que rajoutent MT/MC à chaque message. Le preamble, c'est indépendant, du LoRa pur.
 
Dans cet entête, on doit avoir les id source et destination, le numéro de canal, le nb saut limite, RSSI/SNR,  ... lien. Ca doit bien peser quelques octets tout ça, qui viennent limiter le nombre de messages par heure et par node, d'où mes valeurs conservatrices.
 

Gaulix est l'AZERTY du clavier, le SECAM de la TV et j'en passe Il y a toujours de bonnes explications !
 
Malheureusement Gaulix risque d'avoir raison de MT en France pour un gain qui reste à voir par rapport à du MT MF.
 
Edit, le nom de l'organisme m'est revenu. Parmi les détracteurs de Gaulix chez les radio-amateurs, certains pensent que l'initiative viendrait des gens de FNRASEC/ADRASEC qui voudraient se faire un réseau de com d'urgence à bon compte, d'où EMCOM.

Mais, non !
... il répète uniquement si un autre node ne l’a pas fait.
 
Avec Meshtastic  
-> les différents modes dépendent du nombre de node.
-> on commence par LF puis avec une bonne coordination, on fixe un objectif MF.

source ?
c'est pourtant clair dans la doc non ?
Un client ne répète pas s'il entend qu'un autre nœud réémet un message qu'il vient d'entendre mais les routeurs si.

Oui, le problème intervient lorsque 2 nodes intermédiaires sont cachés l'un de l'autre. L'explication en exemple :
 
A envoie un message à D. Il est reçu par B et C mais B et C ne se voient pas. Ils vont tous les deux réémettre. Les deux transmissions vont se chevaucher sur la bande passante et donc entrainer une collision => résultats possibles : perte du paquet, retransmissions supplémentaires, voire saturation du canal.
 

Oui c'est ce que j'ai posté un peu plus haut.
 
Mais je ne comprends pas pourquoi augur1 dit qu'un routeur_late ne répète pas forcément systématiquement alors que la doc dit explicitement que si.

Tu parles de cette doc ?
 

non, celle que j'ai mis en lien plus haut, mais ton lien dit la même chose : routeur_late répète toujours (les exceptions évoquées sont mineures).
 
Sinon j'ai repensé à ton tableau cette nuit : on est d'accord qu'il s'agit du temps d'émission d'un message le plus long qu'il puisse être ? c'est-à-dire avec autant de caractères qu'autorisé.
J'ai repensé à ça parce que par exemple j'ai fait des traceroutes en moins de 6 secondes en LM, et des ping en moins d'une seconde (aller-retour) en Meshcore... donc je me suis dit : hum c'est pas cohérent avec le tableau, mais j'imagine que c'est parce qu'un ping par exemple ne contient quasiment rien en payload. Message plus court donc temps d'émission plus court. C'est ça ?

Le Time on Air est le temps d'occupation du canal, les ondes radio se déplaçant à la vitesse proche de celle de la lumière.

Je ne sais pas ce que mesure traceroute précisément mais effectivement, si le payload est petit, le ToA baisse.

• Pour un payload de 20 en Gaulix par exemple, on obtient un ToA de 987 ms.
• Pour 30 -> 1,2 s
• Pour 40 -> 1,5 s
• Pour 50 -> 1,9 s
• Pour 60 -> 2,16 s

J'avais pris un payload de 86 car le site portugais  mentionnait que c'était une moyenne mesurée sur un échantillon 3700 échanges (en bas de page).

86 octets c'est ça et cela me semble plutôt cohérent pour de vrais échanges :
Salut, j'utilise Meshtastic, c'est vraiment génial. Qu'en penses-tu ? Quel matériel ??

Edit : voici ce que je comprends. L'option traceroute mesure le chemin aller et retour entre deux nœuds, pas forcément direct d'ailleurs. "Duration" affiché en bas est le temps qu'à mis la requête à s'exécuter complètement. Il englobe plusieurs délais, pas seulement le temps que met le message pour parcourir les nœuds ni celui de la transmission radio. D'autres s'ajoutent, introduits par l'application par exemple, les collisions, ...

C'est quand même énorme comme ToA, cela va pas tarder à légiférer.
Quelqu'un a un SDR pour voir un peu dans les zones denses ?

Mais que fait donc la commission européenne, non mais allo quoi
 
C'est la limite du système. C'est pour cela qu'il convient de prendre avec recul certaines affirmations sur l'intérêt de Meshcore vs Meshtastic. Tout est dans les bons réglages du modem LoRa.
 
MC ou MT ne seront jamais des réseaux nationaux alternatifs aux supports de com traditionnels comme certains le laissent croire.
 
 
 

Il y a d’un côté les docs et de l’autre la réalité du terrain, à partir de mi novembre 2025.

Contrairement au rôle ROUTER classique qui est un "prédateur" de l'airtime (il coupe la parole aux Clients pour répéter le message en priorité), le ROUTER_LATE est un "gentleman".

• Son but : Assurer la couverture ("combler les trous" ) sans écraser les communications existantes ni provoquer de tempêtes de diffusion.
• Sa philosophie : "Je répète le message uniquement si les autres (Clients, Routeurs, Répéteurs) ne semblent pas avoir fait le travail, ou je le fais plus tard pour assurer la redondance."

.... en Théorie.

Le Fonctionnement Technique (La gestion des "Slots" )
Pour comprendre le fonctionnement "réel", il faut visualiser comment Meshtastic gère le temps avant de répéter un message (le rebroadcast). Cela se joue sur des fenêtres de temps (slots) :

• Slot 0 (Prioritaire) : Réservé aux REPEATER et ROUTER. S'ils entendent un message, ils le répètent presque immédiatement. S'ils le font, les CLIENT "entendent" cette répétition et annulent souvent la leur pour éviter le doublon.
• Slot 1 (Standard) : C'est là que les CLIENT opèrent généralement.
• Slot 2 (Tardif - Le domaine du ROUTER_LATE) : C'est ici que ce nouveau rôle intervient.

Le comportement observé fin 2025/début 2026 :
Le ROUTER_LATE écoute pendant les premiers slots.
   1.S'il n'entend aucune répétition du message par un autre nœud (ni Routeur, ni Client), il va diffuser le message dans son créneau tardif.
   2. S'il entend une répétition, il ne s'annule pas toujours (contrairement au Client standard), mais il décale son action pour garantir que le message passe, agissant comme une couche de "béton" supplémentaire pour fiabiliser le réseau, au prix d'une latence accrue.
 
Pourquoi cette expérimentation massive ces derniers mois ?
Entre novembre 2025 et janvier 2026, trois facteurs ont poussé à l'adoption et au test de ce rôle :

• La "Guerre des Routeurs" : Trop d'utilisateurs configurent leur nœud de fenêtre en ROUTER "pour aider", ce qui sature la fréquence. ROUTER_LATE est la réponse technique recommandée pour ces nœuds intermédiaires : utiles mais pas critiques.
• La fonctionnalité "Fallback" (Repli) : Une fonctionnalité expérimentale (discutée notamment dans les tickets GitHub #8378) visait à faire passer automatiquement les ROUTER abandonnés (non mis à jour ou non administrés) en ROUTER_LATE après un certain temps. L'idée est d'éviter que de vieux nœuds "zombies" ne monopolisent le réseau.
• L'amélioration du "Flood Routing" : Les développeurs ont cherché à affiner l'algorithme de routage par inondation (Managed Flood Routing) pour qu'il soit plus intelligent dans les zones denses (villes).

Les limites et réalités du terrain
L'expérience utilisateur sur ces trois mois a révélé plusieurs points cruciaux :

• Latence accrue : Comme son nom l'indique, c'est "Late". Pour des messages urgents ou du suivi en temps réel, ce nœud introduit un délai perceptible. Ce n'est pas idéal pour un saut critique.
• Consommation batterie : Le nœud doit rester en écoute active et traiter les paquets plus longtemps avant de décider d'émettre ou non. Il consomme donc plus qu'un CLIENT ou CLIENT_MUTE.
• Le paradoxe du bruit : Dans certaines versions bêta de décembre 2025, le ROUTER_LATE avait tendance à répéter les messages même si le réseau était déjà saturé, simplement "plus tard", ce qui transformait une congestion immédiate en une congestion étalée dans le temps (bruit de fond).

Belle explication, merci

Pour la compléter, chaque slot ou fenêtre de contention pour reprendre la terminologie MT est donc un temps d’attente. Il est généré aléatoirement par le nœud, pour éviter de façon probabiliste que deux nodes émettent le même message. Chaque slot a une plage de valeurs possibles définies selon la priorité, non recouvrable avec d’autres slots.
 
C'est le flooding contrôlé.
 
Les gens de la radio appellent ce temps d’attente un backoff.  

Heu... oui... donc il répète quoi, juste plus tard.
"il ne s'annule pas toujours mais il décale son action" j'appelle ça répéter.

"Pas toujours"
= annule la plupart du temps, sauf si ...  
 
Nuance !

Que je comprenne alors, il s'annule quand exactement ? Sources ?
Parce que c'est franchement difficile de savoir s'il répète ou non puisque par essence la majorité du temps le message sera diffusé avant (en donc reçu et indiqué comme tel) avant que le routeur_late envoie son message.
Donc sur un traceroute par exemple ça ne sera pas lui qui apparaîtra dans la liste. Lors d'un envoi de message on verra qu'il a été relayé par d'autres...

Voici ce que j'ai compris, peut-être mal, dans le fonctionnement normal de Router_Late :

• S’il n’entend personne, il retransmet dans la fenêtre de contention normale (comme un client).
• S’il entend quelqu’un, il décale sa retransmission dans la fenêtre de contention late.

Il retransmet donc toujours, dans des fenêtres de contention qui peuvent être différentes, hormis les exceptions citées où il annule la retransmission.
 
En passant, j'ai un nœud par lequel passe nombre de mes liaisons. Il est invisible dans la liste mais je le vois en Traceroute. A priori, il doit être réglé en Router ou Router_Late avec un hop = 0, ce qui le rend invisible d'après mes lectures. c'est bien cela ?
 
Edit : depart, tu as quoté le mauvais message dans ton dernier

On est d'accord.la doc est claire. Je veux bien accepter autre chose mais va falloir sourcer.

Doc :
While ROUTER_LATE will normally rebroadcast everything it hears, there are some specific exceptions:

   If the packet arrives with a hop limit of zero. These packets are considered to have reached the end of the line, and are not supposed to be passed on any further.
    If the TX (transmit) queue is full, and another packet arrives that is both eligible for rebroadcast, and has a higher priority than the lowest-priority packet in the TX queue, then the lowest-priority packet in the queue is discarded. This typically happens on busy meshes, or meshes that use a slower modulation configuration. ROUTER_LATE is particularly prone to this, because it stores deferred packets in the TX queue while waiting for the opportunity to transmit them during the late contention window.

Les exceptions sont mineures : hops expirés ou queue pleine et nouveau message plus important à envoyer.
Do'c en pratique il répète toujours.
Je ne comprends pas le laïus de 3km augur1.

augur1 dit avoir constaté un fonctionnement différent que celui attendu lorsque Router_Late n'entend personne, => fenêtre Late :
 

Source, entre autres : https://github.com/meshtastic/Discu [...] t-14523768

"This has the effect of ensuring that ROUTER_LATE will politely 'give way' to other nodes, thereby preserving the normal routing behaviour of the mesh. Other than the obviously higher airtime used, the impact of deploying a ROUTER_LATE node is identical to as if a CLIENT were deployed at that location."
** et il y a encore d’autres subtilités à partir du firmware 2.7.15.xx

// je suis en train de tester Seed Wio Tracker L1 Pro et comparer au WisMesh Pocket V2
... on comprend bien pourquoi ce Seed est 2x moins cher que le Rak !!

• plastique très cheap
• bouton reset sur le côté gauche (très con de l'avoir mis ici ; inutilisable en déplacement)
• antenne sort avec un trou, donc SMA femelle (ou alors ce serait du RP-SMA Male) // le boitier a une entrée SMA Male ( ou RP-SMA Femelle )
• temps d'acquisition des autres Node extrêmement long comparé aux Rak, au même endroit
• niveau de reception et émission tres mauvaise comparé au Rak

... le Rak voit 90 Node quand le Seed n’en voit que 34.

Grose deception ; à ne pas recommander sous peine de dégoûter de nouveaux utilisateurs au Mesh.

Ce dialogue de sourds
Oui c'est ce que dit la doc :
Il ecoute et :
- Si il n'entend aucun client il émet comme un client (slot 1)
- s'il entend un client émettre il attend et émet ensuite en slot 2

Non mais bon, si tu insistes...

À noter que les doc avant mi novembre 2025 sont en partie obsolète avec les firmware supérieurs à 2.7.15xx

Donc, comme tu l'as écrit plus haut, Router_Late passe toujours dans la fenêtre Late, c'est bien ça que tu as constaté ?
 
Pour ce qui est des nodes que tu cites, c'est vraiment dommage d'implémenter une batterie LiPo vs un bon classique 18650. C'est pour ça que j'ai monté des Faketec.