Swiss Meshtastic User

[Haflinger73]

Yes, then let’s continue here on GitHub.
This thread is aimed at all Meshtastic users in Switzerland. Ideas, locations of routers, discussions about the settings of the nodes, construction instructions, everything has space here.

Here is the latest version of “Swiss Mesh Netiquette” as a link: https://is.gd/vokKqU
Please share this guide/information in your region, it is written in German, French and English.

73&55 Haflinger73

[v7o73]

For all those who are wondering why Discours is no longer available, here is the official explanation
https://github.com/orgs/meshtastic/discussions/1#discussion-7379712

[orbiter5]

It's so simple: no routing = no traffic!

[shalberd]

@orbiter5 are you referring to the moving of discussions from Discourse to Github? I am afraid I do not follow / understand you.
If you are discussing the Meshtastic role "Router": Wrong, there is traffic being routed and forwarded with Device Role "Client":
https://meshtastic.org/blog/choosing-the-right-device-role/
"Despite the apparent baggage of the term Client in some technological contexts, Clients in Meshtastic do actually repeat / route messages. Unfortunately in the past this has caused some confusion, landing some individuals to incorrectly choose the ROUTER role."

[v7o73]

When I look at the Meshtastic map of Switzerland, I've noticed for some time, that there are many more connections between the nodes in the Lower Valais and Lake Geneva basins, showing the relationships between them.
Why is this not the case in the Mittelland and eastern Switzerland?
Is anyone familiar with this?
https://meshtastic.liamcottle.net/?lat=46.282867339816505&lng=366.9831848144532&zoom=11#

[FJF130]

My understanding is that a lot of information displayed on liamcottle.net is collected through some of the devices that are connected via MQTT protocol. Such devices are marked as green dots in the map. Last time I checked the northern part of Switzerland shows almost no green dots, only blue dots. There is a reason for this. In order not to block bandwith with unimportant telemetry data the community in northern Switzerland agreed to limit telemetry to an absolute minimum. Every user should follow the following “Swiss Mesh Netiquette” see link: https://is.gd/vokKqU
Users in other regions may not (yet?) experience issues as we experienced in the northern parts of Switzerland.
Topology and low numbers of participants may be reasons to have a limited number of nodes actually connected via MQTT over Internet in order to be connected with other groups at all. One shoud know MQTT related settings very well before one enables it in order not to consume/block to much bandwith.
More knowledgable readers please feel free to correct my statements.

[mariotti]

Hoi all,

I just got into meshtastic and Lora.

I was reading the “Swiss Mesh Netiquette” and I found that we need to add a case: moving nodes.

I bring this example as I got a T-watch-s3 and a t-echo. Actually also a t-deck and a t-beam, but I want to
focus on the first 2 as they are going to be most probably my first application.

An almost tracking system for my child, with a special communication channel.
I give details in the appendix but the matter of fact is that with these devices you can have
moving LoRa nodes.

So in the Device Roles section I'd add a case:

Case C) Moving devices

As a starting point I'd set them to CLIENT_MUTE

This should grant that anybody with a LoRa watch is not interfering with a stable network.

But this is my first opinion. Some open questions might be:

• In remote sites, might a moving device increase reach?

• If LoRa starts to be use as rescue channel, should not all climbers have a CLIENT set up?

For example I read that PMR (PMR446 WalkieTalkie) starts to be used ... :( only now:

• in german: https://www.sac-cas.ch/de/die-alpen/im-notfall-auf-empfang-33257/
• in italian: https://www.sac-cas.ch/it/le-alpi/comunicazioni-demergenza-33257/
  (no english version)

In this specific case, I would add a note that in the mountains, you MUST use CLIENT.

As I just started these are mainly my personal considerations.

What do you think?

A+
F

[MeshTrafficObserver]

Hoi Mariotti,

Thank you for your input and comments about our "Swiss Mesh Netiquette."

The Netiquette we created is meant to apply to "normal nodes." While there are certainly many additional scenarios, the idea is to give newcomers a quick and simple overview. Adding too many details might discourage people from reading it.

While I completely agree with you that moving nodes should preferably be set to Client_Mute, I don’t agree that nodes in the mountains should be set to Client.

I understand your point that in remote areas, every node set to Client might potentially increase the chances of connecting to the network. However, mountains are everywhere here. We’d end up in the same situation we started with: every node in a car, backpack, or pocket would send out DeviceMetrics and Positions every few minutes into the mesh. To make doubly sure, people would also set the Hops to 7, so even users 150 km away would be disturbed.

Did you check out this video? https://www.youtube.com/watch?v=htjwtnjQkkE
With the current routing algorithm, nodes in poor positions act more like traps than they help to extend the mesh.

In general, I would never rely on Meshtastic as a reliable emergency system.
For mountain use, my preferred options would be:
• A smartphone with the Rega app
• An official emergency radio to access the two Rega channels
• VHF ham radio (if you’re licensed)
• Devices like SPOT, Garmin, or iPhone with satellite capability

73 de Matthias

[mariotti]

Hoi Matthias,

We are in full agreement :)

I just started with LoRa, and not exactly a mountaineer :)

It was more not to simply close the discussion with, just set it to "client_mute".
I was just wandering if in deep valleys you can have reach issues. But you clarified the point.

Yet, with these new devices I would still propose a point C :)

Thanks a lot for your infos!

I do not think we need to discuss right now the point C inclusion.
As I see we are not yet too many using LoRa.

Thanks again
Fabio

[MeshTrafficObserver]

Latest "Mesh Traffic" Graphics

Attached are the latest traffic graphics from the "Mesh Traffic Observer" node in Basel.

This time, it took a bit longer to prepare. The output of the Meshtastic Python CLI changed several times, which broke my script's ability to read the data. I adjusted the parser once, but the second time it was just too much trouble.

Now, a Raspberry Pi runs an MQTT broker that provides the data exactly how my script needs it. A big thank-you to Jean-Marc for sharing his MQTT script - it was very helpful.

Oh, and by the way, my Heltec device stubbornly refuses to get the time from the NTP server. I had to replace the timestamp in the JSON (outside of the payload) with the system time. My trust in the constantly changing firmware versions has not increased because of this…

Anyway, here are the latest data:

https://drive.google.com/drive/folders/1vNUbksbY7vqEE4apPSPC5ItU47RTsft9

Time period: 6 days (Monday to Saturday, November, 11th - 16th)

The overview graphics show all nodes whose transmissions were received more frequently than every 2 hours (based on the median). The graphics include a short explanation text with suggested settings.

Additionally, I’ve created individual graphics for all your nodes. You can find your node by sorting them by "long_name."

It’s nice to see that quite a few people have switched their nodes to "Client_Mute." We’re now up to about 20 nodes.

73 de Matthias

[MeshTrafficObserver]

Thank you both :)

@FJF130
Yes, that’s exactly what I’ve done on FB several times over the past few months. I’m not sure if the issue was with the link itself or the fact that I posted similar images and explanation text repeatedly. I’ve sent it over the mesh, and if you think it’s helpful, feel free to share the link to the mesh as well. I’ll give it another try with new data in a few weeks.

@salfare
I’ve noticed the same issue with my own node. It only improved when I upgraded to 2.5.0. I actually compared 2.4.3 with 2.5.0 using identical settings (NodeInfo every 3 hours) a few months ago. It seemed like the interval scaling, which depends on the number of active nodes, finally worked in 2.5.0. Additionally, I vaguely recall a bug in the 2.4.x firmware (something related to milliseconds) that caused NodeInfos to fire far too often.

That said, I can’t explain why the latest data shows my main node sending out NodeInfo only once in six days—it doesn’t seem right. I suspect it’s incorrect. The data collection method and observer node settings were different this time.

Previously:
Observer node (MTO): client_mute, hop1, data read via meshtastic cli --listen.

For the latest analysis:
Observer node (MTO): client_mute, hop0, TX-off, sending data via MQTT to a Raspberry Pi.

I’m still not sure how of if these changes have affected the dataset.

[mariotti]

Just out of curiosity @FJF130 who are the FB users? I mean which app, project, device?
I find it strange that they cannot reach github at this stage. What are they using?

[salfare]

Update after upgrading my nodes to 2.5.11.8e2a3e5 Beta.
the amount of Nodeinfos went down dramatically:

in Releasenotes Meshtastic Firmware 2.5.11.8e2a3e5 Beta I found:
🚀 Enhancements --> Disable automatic NodeInfo request when NodeDB is full by @GUVWAF in

I think that caused the high number of Nodeinfos sent previously.

[hb9eue]

MTO: The Link you sent over the mesh was how I found your document, it was very helpful and also got me to upgrade the firmware on and settings my several nodes. Interresting, I have been active since years and in the beginning there were no nodes rechable. Now I constantly at the max limit of 100 neighbors.

[MeshTrafficObserver]

@hb9eue Thanks, I'm glad our document was of help. Yes, the Mesh became indeed quite busy

[Haflinger73]

Thank you Matthias for your work. I discovered 1-2 of my routers in your list. They rebooted shortly after the OTA update and lost all their information. I'll climb the hills and give them names again. For those interested, here is the link to our Meshtastic Switzerland FB group: https://www.facebook.com/groups/771317178261325

73&55 Halfinger73 Simon

[FJF130]

Hi Fabio,
I fully understand if someone does not like FB groups. However, with currently almost 200 participants the reach of the Meshtastic Schweitz group is currently far bigger than GitHub discussions or discord.
If we would want to become "independent" from Facebook or even the internet things become cumbersom. Eventhough ther is quite some interest in Meshtastic, not many are willing to contribute with funding our own website, infrastructure (servers) or even taking responsibility for running and managing discussion forums/bulletin boards as an admin.
So as one of the admins I invite you for now (until we have good alternatives available) tojoin us on Facebook (even as a read-only user) and not miss on what's going on in the swiss mesh....Meet you there! :-)

[mc-hamster]

Hi Fabio, I fully understand if someone does not like FB groups. However, with currently almost 200 participants the reach of the Meshtastic Schweitz group is currently far bigger than GitHub discussions or discord. If we would want to become "independent" from Facebook or even the internet things become cumbersom. Eventhough ther is quite some interest in Meshtastic, not many are willing to contribute with funding our own website, infrastructure (servers) or even taking responsibility for running and managing discussion forums/bulletin boards as an admin. So as one of the admins I invite you for now (until we have good alternatives available) tojoin us on Facebook (even as a read-only user) and not miss on what's going on in the swiss mesh....Meet you there! :-)

Speaking as someone who has been building online communities since the '90s ... you have the right approach. You, as someone who is building a community, you will find where the outliers are and eventually find a way to bring them in. The ethos you build within your community will extend beyond the the confines of what you are doing. Focus on ethos and you will maintain your influence.

[mariotti]

Hoi all, I did not want to start a semi political discussion, we can continue it in a different place if needed.

I was just suggesting that FB might not be a community for everybody.
Me personally, I had to close FB when looking for a job, as it was highly suggested.
At present only linkedIn is used with only professional infos.

You gonna lose me there :( .

@mc-hamster you should be about my age then ;)

As soon as we go back to tech things here, I can survive without FB :)

Cheers
F

[mc-hamster]

Hoi all, I did not want to start a semi political discussion, we can continue it in a different place if needed.

I was just suggesting that FB might not be a community for everybody. Me personally, I had to close FB when looking for a job, as it was highly suggested. At present only linkedIn is used with only professional infos.

You gonna lose me there :( .

@mc-hamster you should be about my age then ;)

As soon as we go back to tech things here, I can survive without FB :)

Cheers F

I'm not on FB either.

:)

[shalberd]

I am not on Facebook either. Greetings from fox 71, Swiss knife valley

[mariotti]

JIC, this is my zuerich view:

What I do not understand is a list of node with like 5 hops aways. While my settings are set to 3.

[mariotti]

@garthvh, kinda asynchronous (I mean, if I want to reach the 7 hops node, i'd need the same hops settings?).

If you please have a bit of time, I'd like to understand this.

Can you suggest any specific reading?
If I have the option, I would prefer readings, no YouTube.

Thanks a lot in advance
A+
F

[MeshTrafficObserver]

Hi Mariotti

For the sake of simplicity the answer is yes, you would need to set hop to 7 too.
In reality your message may however take another route, maybe in this case it travels only 4, 5 or 6 hops.
Whether or not your message is received at the target at all, is a completely different story.

See hop count
https://meshtastic.org/docs/configuration/tips/

A message knows who the target node is but not how to get there.
https://meshtastic.org/docs/overview/mesh-algo/

There are ideas to make it more sophisticated and directed but I think it's not implemented.
https://github.com/orgs/meshtastic/discussions/8
meshtastic/firmware#2856

The higher your hop setting the further your transmission is traveling.
Your node is however not only sending your text messages but as well NodeInfo, Telemetry and Position messages. The higher your hop setting the more the mesh is pouted with transmissions which are not critical but block the mesh.
In addition you relay other useless transmissions (if you are a CLIENT) from other node further then you would do with hop 3.

There is one frequency we all use when using Long_Fast as primary channel. A node is not transmitting when it hears another node sending. Therefore it's important to keep the traffic low and users are recommended to kep the setting at 3.

[Haflinger73]

Thanks Matthias for your answer,
I can't add anything. Meshtastic was not built to connect entire countries, the idea was to enable small groups (50, max. 80 nodes) to communicate.
In Switzerland we have (estimatedly) long since exceeded the 500 node limit.
If only a fraction of Hops 3+ and telemetry data are transmitted every 15 minutes, the mesh will “implode”.
That's why mesh netiquette is so important, many people stick to it.
But here in Aargau I read so many French messages from Valais, Neuchâtel and Geneva that are sent with 5-6 hops.
Either we cut the connection to the Plain Morte and the western Jura heights, create our own German-Swiss channel (I'm not a fan of the "Röstigraben") or our French colleagues also accept the 3 hops limit.

[mariotti]

Thanks @MeshTrafficObserver , this is a bit more clear. while I knew the first documents, I'll spend some time on the new propositions. I enjoyed the "for simplicity" part ;)

I think it is anyway fine for broadcasting, i.e. I do not need to go to 7 hops as I might just be a receiver.
I mean for the original question. This of course depends on the application.

@Haflinger73 in practice we keep up a list of nodes that a device can use.(* if close enough)

Just tonight, I got a private (unwanted) conversation, on LongFast in ZH region.
I think we need to change target.

We use meshtastic because is fantastic, not because we need to keep up a specific network.

I will be with you about "netiquette".

Thanks all,
I think we will meet here again anyway
A+
F

[mariotti]

JIC: With MQTT in theory you can reach your friends in the other part of the world. As soon as you are in the same channel.

[PeterFausH]

Started couple of days ago with old ttn hardware into meshtastic. Works fine but I'm an alien.
Located in high altitude of blackforest having Feldberg in the back and plain view to the alpes, all seen nodes are Swiss or France located.
Seeing nodes 220km away, I noticed I would have a prominent location.
Thanks to the netiquette sent out as link in longfast I immediately reduced noise produced from my tests.
Still experimenting with power solution to have my node outside, I will show up in a couple of days again.
Any suggests what doing with this nice position?
My target is a small local family group as we don't have mobile support here.
Actually I'm able using my private mqtt-server to provide messages in our family-channel.
Just to let you know, I'm located in Germany without any German nodes around, so that's why I'm commenting here.
Peter

[MeshTrafficObserver]

Hoi Peter

Welcome to the Mesh World.
Did you try "Long Moderate" instead of "Long Fast"? I think the German Nodes in this area ( e.g. "Blauen") switch all to LM.

Grüsse,
Matthias

[PeterFausH]

Thanks, will give it a try!

[PeterFausH]

Tried it immediately until today and had no response using LongModerat.
Will stay at LongFast and screw up the swiss guys.

[PeterFausH]

this could be my range if using the desired install position. As you see, it is mainly going into the south and this is why i get notice from the swiss nodes. Will continiue if the new 18650s arrive.

here my potition marked in the mestastic map:

would someone have benefits if this would be a router ?
regards
Peter

[MeshTrafficObserver]

Hi Peter
hihi, ok. No worries, one more we take ;)
No, I don't think it would make sense to place a router there. We have the Sonnenberg, and Simon's HRxx Routers (and some other ones) covering this area very well.
73 de Matthias

P.S. sent you a direct message via the Mesh

[Haflinger73]

Hello Peter, I think we already had contact via the Mesh.
Yes, as Matthias wrote, the Rhine Valley is relatively well covered, but your location is a great addition. But I would run it as a client. Here is a map with the coverage of my HR routers (01,02,04,06) HR05 temporarily out of service. Supplemented with the router Küssaburg and Sonnenberg (I don't know the exact location/height/antenna).

Kind regards, Simon Haflinger73

[PeterFausH]

yes, we had mesh contact already. Actually the desired node is located around the building as i'm still experimenting with power source. A brand new 3,5W solar panel is not enough to keep the node running. So i will have to have 18650s als 1s2p. Due to lack of understanding how to secure and how to select a proper BMS it will take a few more days to have the node up on the mountain running.
By the way, this is my node-page: https://nc-x.com/meshtastic-nodes
Regards
Peter (Hotzenwald_969c, V1lora_0384, dbpf_144c)

[Haflinger73]

From my own experience (HR-Routrer), a 5W module is sufficient in our latitudes if you can point it to the south and don't have much shade. But I saw that you are using a Heltec V3 in your router. This will only just work with a >20W PV cell. The esp32 chips simply need too much energy compared to an nrf52 chip.
By the way, you don't have to take us Swiss into account: "aus Rücksicht auf die Schweizer Anwender", but it is counterproductive to use too many routers for routing, as this forces messages to lose hops via the router if, for example, they come from Küssaburg directly to Basel.
And yes, I also notice with CB radio that it is not easy to get across the Black Forest, but you are of course very welcome in the Swiss community.

[Haflinger73]

Hello Peter, I just saw your gmx email today, but I can't reply (encryption...) I wrote dbpf on your node. Greetings Simon

[PeterFausH]

Please tell me that i'm not the only one who had trouble with text messages today.
Did receive lot of nodes all day, but since around 10.30 no text messages until late evening.
Peter

[MeshTrafficObserver]

I turned on my Mesh Traffic Observer in Basel again and recorded the traffic over the last 6 days. There was quite a lot happening on the mesh.

During this time, 441 different nodes were online, and my node database now lists a total of 1063 nodes. However, I did not receive complete data from all of these nodes. That's why the number of nodes shown in the summary graphics is sometimes lower.

The hop setting has shifted. Although "3" is still the most common, "7" has increased significantly.

As always, you can view the data on my Google Drive. There is also an individual graphic for every node that was received.

https://drive.google.com/drive/folders/1vNUbksbY7vqEE4apPSPC5ItU47RTsft9

As a new feature, I have now listed the air utilization for nodes with a value of 4.5 and above (median air_util_tx).
These nodes are operating at or above the duty cycle limit.

73 de Matthias

[White-Whizard]

Hoi here

short question. I (Guemligen) have been offline more or less for 4 weeks due to a node failure. Now I reconnected everything, waited 3 days, but I can not see any other nodes. Which is strange because I am sure everything is as it has been before. (Antenna, Cabel, what ever)
Has something groundbreaking changed in 2.5.20 in the last 4 weeks, what I have not recognized?

Looking forward to your replies.

Bestes Grüssli

My Channel/LoRa config attached:

"lora": { "usePreset": true, "region": "EU_868", "hopLimit": 3, "txEnabled": true, "txPower": 27, "sx126xRxBoostedGain": true, "ignoreMqtt": true, "modemPreset": "LONG_FAST", "bandwidth": 0, "spreadFactor": 0, "codingRate": 0, "frequencyOffset": 0.0, "channelNum": 0, "overrideDutyCycle": false, "overrideFrequency": 0.0, "paFanDisabled": false, "ignoreIncoming": [], "configOkToMqtt": false

[vididuc]

Hi all

I'm new to meshtastic.
I noticed meshtastic through crankk. I'm running a a crankk gateway.
The crankk community implemented a meshtastic integration (firmware).
I got a Heltec V3 and flshed the crankk-meshtastic firmware.
Are we allowed to discuss about crankk-meshtastic firmware in this discussion thread?

Regards
V

[Haflinger73]

FYI: In Aargau, some of my routers (HR routers) were updated with Jean-Marc's custom firmware.
https://github.com/CamFlyerCH/meshtastic-firmware-mod/releases/tag/2.6.5_HopLimit5only
These only forward messages configured by nodes with StartHops 5 or lower. Unfortunately,
I lost router HR04 in the process. I'll replace it on Thursday, April 10th.
We'll see how this update pans out.
One more thing: when checking the routers on site, airtime times of over 5% were recorded, even though no Override Duty Cycle is enabled....

[shalberd]

One more thing: when checking the routers on site, airtime times of over 5% were recorded

I think airtime TX / AirUtilTX has a one-to-one relationship to duty cycle max. 10% per hour, on a rolling basis. That explains why AirUtilTX can be anything up to 10%, I believe.

[shalberd]

In the Schwyz Swiss Knife valley / Schwyzer Talkessel, someone is operating a Router node up high on the mountain below Wildspitz that reaches the entire Schwyz valley, including Schwyz, Steinen, even Brunnen probably and also reaches up towards Sattel. As well as towards Zugersee. The node is named "Esel".

So, for new nodes in the Schwyz Swiss Knife valley, we should really let the node named "Esel" do its job and not create any other nodes with role "Router".

Later on this year, to get further on to Uri, we might install a router node somewhere high up near Seelisberg, we will see.

Swiss knife valley users: please, refrain from configuring your devices as router, cause spirit 71 already did so and it is doing a fantastic job. Also, to avoid packets being transmitted and received multiple times by end user's devices (Num Rx dupe), please set your devices to role client_mute (which is really more akin to client passive towards other nodes' packets) in the Swiss knife valley, especially if you are in the trenches between houses or behind the window in a house. Otherwise, an occasional client on a very elevated location (grain or mill tower) is ok.

https://www.youtube.com/watch?v=htjwtnjQkkE

https://meshtastic.org/blog/choosing-the-right-device-role/

https://meshtastic.org/docs/configuration/radio/device/#roles

Best regards

fox 71

[MeshTrafficObserver]

The past two days, I had the MTO running again. The time period was from Friday 11:00 AM to Sunday 11:00 AM.
During this period, 238 individual nodes were received in Basel. The complete node list now includes a total of 1,161 nodes.

I have uploaded your data (the overview and your individual graphics) to the gDrive:
https://drive.google.com/drive/folders/1vNUbksbY7vqEE4apPSPC5ItU47RTsft9

It seems there are still quite a few nodes operating with rather old firmware.
In my last post, I mentioned how this impacts, for example, the NodeInfo transmissions.
Perhaps the following users could indicate which firmware they are currently using:

Birch-RPT
AX1
BREMCOM-01
BREMCOM-02
SolarRouter01
SolarRouter02
HB9Y Plain Morte

Philipp recently updated the "Sonnenberg" to the latest version. The difference is remarkable — the persistent NodeInfo transmissions have disappeared. Many thanks for that 😀👍

Enjoy reviewing your nodes.
73, Matthias

[shalberd]

Bremcom is somewhere close to Bremgarten ... that node came up strong on the Autobahn going south from Zurich. Question is, who is maintaining those :-)

[shalberd]

@CamFlyerCH about evaluating device metrics during testing of a router nearby:

Instead of your modification related to 0 hop telemetry, would an alternative for me, if I do not want to have any firmware modifications,
to just set hop limit to 1 on the router on top of the mountain? For the duration of e.g. airUtilTX % monitoring, that would be feasible, correct?
Sure, that would mean that for the duration of testing, anything like NodeInfo would also be only spread around at level 1, but is that a problem during testing? I would think "no".

[CamFlyerCH]

You can set a router to hop limit 0. This does not affect how he routes packets. The only issue is, that nodes further away can't see the router's long and short name in a traceroute.

[PatrickDch]

Hoi everyone. Anyone knows "Belpberg" Router_Late? I am more or less disconnected from the Mesh after it came up 6 days ago.

I will try to contact it while MeshWalking.

Beste Gruesse

[PatrickDch]

Actually you answered the solution to my problem already in your last post. Have just seen it. Sorry for that. I thought it was Belpberg because the traceroute ended there. My actual problem seems to be that I can't reach "grat" router anymore. - Gümligen_MEDIUM GU73 !435a9c8c / merci fürs antworten

[shalberd]

Hi @PatrickDch @MeshTrafficObserver @Haflinger73, do you know who manages Grat Router grat - 2.6.4 !f1d56c41 near Thun, somewhere near Stockhorn?

Similar to other high-altitude mountain routers, because it is set to Router, it prematurely grabs hops from really far away like Waldenburg BL near Vogelberg (4437/1) and 5233/1 near Villigen AG.

It would be great if, for BL, SO, AG, Grat router would first give other Nodes a chance to transmit/rebroadcast, then rebroadcast a little delayed, meaning if Grat Router were set to device role ROUTER_LATE.

See https://github.com/orgs/meshtastic/discussions/24#discussioncomment-14397405

We have already done that with most of the SZ LU ZG NFN mountain nodes; set them to ROUTER_LATE with very good results.

Also, any node still on 2.6.4 should update to the current stable version 2.6.11. NextHopRouting in 2.6.4 had a bug in it where device roles ROUTER, ROUTER_LATE would not relay / rebroadcast direct messages (NextHopRouter.cpp). It was fixed in 2.6.11 or 2.6.10.

meshtastic/firmware#6904

[PatrickDch]

Sorry, tried to figure it out but... nope... I have no clue. 😌

[MeshTrafficObserver]

@shalberd nope, sorry. I checked the node number (4057295937) and the name in FB, but could not find any postings. The router has 3 hops, GPS is set rather unprecise. More I can't unfortunately not see.

[CamFlyerCH]

Hi @PatrickDch @MeshTrafficObserver @Haflinger73, do you know who manages Grat Router grat - 2.6.4 !f1d56c41 near Thun, somewhere near Stockhorn?

Since it is near to me I tried many times to find out who manages it with no success. 😒

[MeshTrafficObserver]

Hoi everyone,

Here is a new mesh statistics report from Northwestern Switzerland. This time, I’ve also included individual graphs for your nodes again. You can sort the graphs by (long) name (if known in my log file) to find your node. The individual node graphs are in the “Per Nodes Graphs” folder, the overview graphs are in “Summary Graphs.”

Time period: July 13–19, 2025 (7 days)
Data points: almost 35,000
Individual nodes: 224

https://drive.google.com/drive/folders/1vNUbksbY7vqEE4apPSPC5ItU47RTsft9

The "READ-ME" PDF has been updated. It explains the graphs in more detail and includes background info. It now also contains French and English translations.

In the "Summary Graphs" folder, you will also find a new PDF: "Intervall_position_transmissions_19Jul25"
Unlike the graphs, this PDF lists only position broadcasts that were sent actively, not those that were requested by another node. This allows for a better understanding of the interval settings used (indicated as "median" in hh:mm:ss in the table).

Our recommendation for fixed nodes to use long intervals (> 2 hours) for position broadcasts is unfortunately being ignored more and more.
Maybe some nodes were underheated during reflow soldering and developed a narcissistic personality disorder 😉 — which I feel sorry for — but it’s really not necessary for fixed nodes to send their position every few minutes.

Please check your node settings and adjust them if needed.

Also a reminder: only use SmartPosition in special cases (e.g., when hiking).
The idea of SmartPosition is good — but in practice, it doesn’t really work well.

I’ve attached a graph from a node using SmartPosition and getting GPS data from a phone.
Since the phone moves with the owner and sometimes has better, sometimes worse reception, it constantly triggers new position broadcasts.
The problem is not the precision of the location — the problem is that the node goes nuts and keeps flooding the network with useless updates.

So please consider to use fixed intervals and turn off SmartPosition.

Wishing you all a nice Sunday.
73 de Matthias

[Mictronics]

Hi Matthias,

I am impressed of your mesh statistics an plan to do the same for our Bavarian mesh. Would like to ask if you can elaborate a view things.

The graphs only show nodes whose transmissions occur more frequently than every 2 hours and whose transmission distribution has a Gini coefficient of < 0.5

I assume the Gini coefficient is calculated for each packet type over the measurement periode?

Does it makes sense to calculate the Gini for all packet types of a single nodes transmission and take its value to include or exclude from the "bad" nodes list?

How you create the plots? I am struggling to get the median into the plot.

Here are view (bad) examples I have so far:

Someone running obviously running Meshsense and hammering traceroutes:

Fixed station obviously with SmartPosition enabled:

Fixed station running very old firmware where no scaler applies:

The number in the title is the Gini for all packet types of this node.

About my setup:

• Orange Pi Zero3 SBC with Waveshare Pico Lora module
• Meshtastic native service on DietPi Linux
• Python mesh-observer code that is parsing the meshtasticd debug log line by line
• sqlite3 database for data storage

The mesh-observer code is also visualizing the Mesh based on the trace route information in the debug log:
https://www.mictronics.de/bayern-mesh/

[MeshTrafficObserver]

Hi Mictronics

Thanks. I’m glad I could give you some idea.
Your graphs look very nice too - and even more I'm impressed by your network thingi.

I assume the Gini coefficient is calculated for each packet type over the measurement periode?

It's calculated for each individual node and its transmission type
For e.g. the position summary plot: from first position transmission of node x to last position transmission of node x

Does it makes sense to calculate the Gini for all packet types of a single nodes transmission and take its value to include or exclude from the "bad" nodes list?

The original idea was to exclude nodes from the summary plots in case they did not show a consisten transmission pattern. E.g. someone walks the dog with smarposition on, firing positions like crazy for 2h, but thereafter only have a few positions transmissions sent over the next few days. The median value for the intervall would be very much misleading and there would be far to many nodes to fit on the plot.

The gini filter is only active in the summary plots. In the node specific plots (the ones you generated too) there is no gini or 2h filter. It shows all transmissions.

Thinking about it now it could be discused if using "first and last" position transmission during measurement periode (regardless of node) would make more sense. But I did not want to compare the nodes to each other but have them assessed individually.

How you create the plots? I am struggling to get the median into the plot.

Well… that a good questions.
I’m not a programmer. I'm coming from the ham radio analog homebrew side and was simply very interested if ChatGPT could help with that. The data analysis and graphs for meshtastic are more my personal learning path how to write proper prompts and see what else could be analyzed - rather than evolving my limited programming skills. But it’s only a small area of my hobby and free time is limited…

What has been important was to plot invisible ghost dots in case there is no transmission of a specific type (it always messed up the alignment (for hours and hours…..)). Have a look at the script snippet. These two parts generate the summary and the individual graphs. Hope it helps you.

One question to you. In your graphs you have «Host Metrics». What is this and how is it different to the «Device Metrics»? Would you mind sending me a JSON block showing such a transmission and it’s payload? I think I have not seen this when logging the MQTT data.

Let me know if you have any other questions.
73 de Matthias

P.S. like you R&S you used for your antennas :)

[Mictronics]

Hi Matthias,
For the host metrics see: Host Metrics
They are transmitted with port number 67 - Telemetry.
I am not sure whether this is visible in MQTT. As said, I am parsing the debug output of one node. They are so much more informations inside than what you can receive via MQTT or even the Meshtastic CLI API.

For example all the trace route packets are visible in debug even when the sniffing node is not affected. That's btw how I create the mesh visualisation.

Thanks for your feedback, much appreciated. I will keep fiddling...
/Michael

[Mictronics]

@matthias
Got everything written up. Maybe it's useful for your guys in Swiss.
Check https://github.com/Mictronics/mesh-observer

The result can be seen here: https://www.mictronics.de/bayern-mesh/

[MeshTrafficObserver]

@Mictronics

Hoi Michael
Concrats - very nice :)

Couple of questions:

Assuming that your method can as well track (but not decipher) transmissions outside the primary channel, are there many nodes sending on privat channels? If so, can you estimate from your data the ration between transmission load on primary versus sum of private channels? Just curious to get an estimate what could come on top of what I see with my MQTT method.

Could you please elaborate a bit more on the "Host Metrics"?
I have difficulties to understand why a node (let's say mine) would send out my "free system RAM", "free space on root" etc. information over the radio network? Is this a real RF transmission over the radio network, if so, would you know its purpose? I don't get it from the telemetry.proto.

[Mictronics]

One could filter for something like that: [Router] No suitable channel found for decoding, hash was 0x2c!
This is a clear indicator for either a channel message, where the channel is not configured (hence no PSK) or a DM.
Another indicator for DM is like [Router] Received routing from=0x433e0fbc, id=0x69e0275a, portnum=48, payloadlen=14944
An undefined port number with large payloadlen.
Could parse that into stats as well.

For the host metrics I have to check a few things. What puzzles me, since you brought this up, is the fact that such packet can be seen in all plots with telemetry (either one) and always at the same time. I wonder if that is a meshtasticd native service thing. Have to dig into the firmware code.

[Mictronics]

Indeed, host metrics are a meshtasticd native service thing. Emitted only by such nodes, and in that case the app seems to have a log category for that.
So you should see that in regular telemetry also via MQTT, but I guess native Linux nodes are a very rare thing.

Anyway, my stats needs a fix here because the host metrics shouldn't be present in any plot.

[Mictronics]

So the problem with my wrong stats is how modules are logged.
For a telemetry packet of any kind, coming in with port number 67, the firmware tries to find what type of telemetry it is. For each (module) try a wantsPacket=1log line is created and this is what I am parsing and counting for the stats.

In this example the telemetry packet was environment, but the firmware tries host metrics and device telemetry module before it finds environment.

DEBUG | 18:12:47 3156 [Router] Module 'HostMetrics' wantsPacket=1
INFO  | 18:12:47 3156 [Router] Received HostMetrics from=0x17819f35, id=0xa1a8add0, portnum=67, payloadlen=32
DEBUG | 18:12:47 3156 [Router] Module 'HostMetrics' considered
DEBUG | 18:12:47 3156 [Router] Module 'DeviceTelemetry' wantsPacket=1
INFO  | 18:12:47 3156 [Router] Received DeviceTelemetry from=0x17819f35, id=0xa1a8add0, portnum=67, payloadlen=32
DEBUG | 18:12:47 3156 [Router] Module 'DeviceTelemetry' considered
DEBUG | 18:12:47 3156 [Router] Module 'EnvironmentTelemetry' wantsPacket=1
INFO  | 18:12:47 3156 [Router] Received EnvironmentTelemetry from=0x17819f35, id=0xa1a8add0, portnum=67, payloadlen=32
INFO  | 18:12:47 3156 [Router] (Received from 9F35): barometric_pressure=971.479065, current=-19.100000, gas resistance=0.000000, relative_humidity=34.882812, temperature=20.299999
INFO  | 18:12:47 3156 [Router] (Received from 9F35): voltage=4.088000, IAQ=0, distance=0.000000, lux=0.000000, white_lux=0.000000
INFO  | 18:12:47 3156 [Router] (Received from 9F35): wind speed=0.000000m/s, direction=0 degrees, weight=0.000000kg
INFO  | 18:12:47 3156 [Router] (Received from 9F35): radiation=0.000000##R/h
DEBUG | 18:12:47 3156 [Router] Module 'EnvironmentTelemetry' considered

Here the telemetry was device and host metrics was tried first.

DEBUG | 18:13:38 3208 [Router] Module 'HostMetrics' wantsPacket=1
INFO  | 18:13:38 3208 [Router] Received HostMetrics from=0x391985cc, id=0xc799517b, portnum=67, payloadlen=28
DEBUG | 18:13:38 3208 [Router] Module 'HostMetrics' considered
DEBUG | 18:13:38 3208 [Router] Module 'DeviceTelemetry' wantsPacket=1
INFO  | 18:13:38 3208 [Router] Received DeviceTelemetry from=0x391985cc, id=0xc799517b, portnum=67, payloadlen=28
INFO  | 18:13:38 3208 [Router] (Received from 85cc): air_util_tx=2.146250, channel_utilization=17.440001, battery_level=101, voltage=4.296000

Time to fine tune the parser...

[MeshTrafficObserver]

Oh I see... thanks for looking into it.
Reminds me when I initially used the output from "meshtastic --noproto" to generate my stats. I gave up on this method when fimware updates changed the format of the output more then once.

[Mictronics]

Parser fixed. Plots are looking now much more plausible.
Added also the stats for encrypted/decoded packets. Based on the decoded packets either for a configured channel or DM vs. encrypted packets where PSK is missing.

[MeshTrafficObserver]

80/20 very interesting, thanks for the addition breakdown

[tht]

Hi,

A few friends and I have been bringing up nodes around the Aarau/Olten area. We started on the Long-Fast preset, like many others, and had a few successful direct links—even bridging over 10 km without line of sight. It worked but wasn’t very reliable, though.

We then learned about Medium-Fast and switched our nodes. You may have seen us as “HB9HBD-*”, “HB9GZW-*”, and another node in Dulliken. It seems we’re at the edge of the mesh: although we can see 130+ nodes, actual communication is effectively impossible.

Whenever I send a direct message, I receive an “ACK from another node,” but the message never reaches the recipient. Messages to Medium-Fast don’t seem to get through either.

We’d rather not go back to Long-Fast—we want to be part of the larger mesh. Our node locations are already as good as they can be, with fiberglass 5 dBi antennas on rooftops. What else can we try? Our area feels like a dark spot for Meshtastic, and if we can establish a stable link to the wider mesh, our nodes could add real value.

Currently the experience is quite disappointing.

[tht]

@shalberd: Thanks Sven. Your work is highly anticipated. We did some tests and yes, there is a clear improvement visible.

I'm able to reach from Lostorf to Bieberstein without the packets being caught by a Router:

Also, the connection to LagMesh is way more realistic:

Here you see 15AG8097DZhb (another Router!) intercepting the packet. This "Router" configuration seems to be broken, at least for Swiss topology. I would recommend to change the Netiquette to ban "ROUTER" completely.

As I've said, it's better but still not useable. I assume the current issue is the node on my roof which I need to connect to the mesh. It seems to reboot quite often:

As soon as there is a new firmware-release I'll climb up there and re-flash (with clearing the config). I hope this helps. It is a SenseCAP Solar Node and battery level was never below 90%. If time allows I'll upgrade to an alpha-firmware in a few days.

[shalberd]

As soon as there is a new firmware-release I'll climb up there and re-flash (with clearing the config)

I have 2.6.11 running on a SenseCap solar with no reboots occurring. Before you flash a new firmware, try exporting your configuration (file), then doing a factory reset ... kinda like a config overwrite, and re-importing your configuration.

About the poor documentation on how the buttons work etc, I found this to be very helpful: https://youtu.be/smQe7G0Bbsk?t=418

[tht]

Still no luck on my side. I upgraded the firmware to an Alpha release but I still see these reboots every few hours and communication is only rarely possible. It works better than before but still not useable.

For now I'll try again to fix this reboot issue and will also let the node on the roof for the time being. Maybe another firmware will help to improve the situation for us. I'll keep testing and updating the node. As of today, Meshtastic is a disappointment for us. I love the idea and highly appreciate the effort of the devs and you guys maintaining all these nodes. It has so much potential if it gets more reliable.

[shalberd]

Still no luck on my side. I upgraded the firmware to an Alpha release but I still see these reboots every few hours and communication is only rarely possible. It works better than before but still not useable.

Hi Thomas @tht , I can tell from my Sensecap Solar P1: using e.g. Android client, in the radio configuration, scroll down to "Backup and restore" and click on Factory Reset. Or in German: Geräteeinstellungen, scroll down to Sichern & Wiederherstellen, Click "Auf Werkseinstellungen zurücksetzen". After that, re-flash the firmware and see if that helps. Specifically, use https://github.com/meshtastic/firmware/releases/tag/v2.6.11.60ec05e

I downloaded
firmware-nrf52840-2.6.11.60ec05e.zip unzipped it, then dragged file firmware-seeed_solar_node-2.6.11.60ec05e.uf2 to the mounted drive. As of now, I really only recommend firmware 2.6.11 with that particular Seed Solar Node ...

Truly, my Seed Solar P1 has never rebooted, running very stable.

I agree that in many ways, Meshtastic is still work in progress. There are some ideas for firmware 3.0 like that one:
meshtastic/firmware#6199 (reply in thread)
The area around Seattle is very fragmented, too, in terms of topography and makes optimal routing difficult.
https://en-gb.topographic-map.com/map-vh39m/Puget-Sound/?zoom=8

[shalberd]

Hi @tht @Haflinger73
about from Losdorf to Lägern, why it got intercepted by Router Mythen before, the recent blog contributor on ROUTER_LATE, ROUTER etc. has an explanation why Mythen grabbed the hop first:

In the case of your red and green nodes, if your trace between them went via the ROUTER nodes first, it went that way because the destination node could not hear the original sender directly. This could be due to a number of factors - terrain obstruction, RF interference, simultaneous transmission, etc. It may also be that there is an asynchronous path there, where the RF setup is such that they can communicate directly in one direction, but not the other.
Looking at mapping for those particular sites, it does appear that there is some terrain in the way between them - perhaps that is the issue in the particular case you have illustrated above?
no direct line of sight.

https://github.com/orgs/meshtastic/discussions/409#discussioncomment-14527208

https://meshtastic.org/blog/

The poster agreed though that placement of Routers needs to be thought about very carefully, and he agrees that too many routers make the mesh make unnecessary round trips / detours.

So what we have been doing at NFN inner Switzerland, setting the major mountain nodes to ROUTER_LATE, except so far Grosser Mythen, which is still on Router, is definitely a good thing.

I also asked about placement of nodes on a lateral valley side, higher up, East - West or North - South but not all 4 directions.
Whether Client was good there. He said that it could happen deep inside a valley that the next hop is a node down in the valley, so the Client higher up on a valley side, being very considerate, never retransmits. So, for those cases, he said, ROUTER_LATE is still preferred.

I don't know. I think that we can say is, in our topography: It does not make sense to, cutting in line, first priority, make ROUTER nodes grab traffic from Client nodes in the great plains / Mittelland, even if there are some minor obstructions between them.
So. ROUTER_LATE for mountain nodes is still preferred and definitely the way to go.
About Quertäler / lateral valleys, like I will do soon at Fellilücke UR / Fellital up north and anterior Rhine valley / Rheinschlucht above Sedrun / Cuolm da Vi, he has got a point of ensuring an additional, delayed retransmit via ROUTER_LATE towards Andermatt and Chur from 2200m high, instead of being caught between two nodes at the bottom of the valley only.
So, I will probably set Cuolm da Vi
https://s.geo.admin.ch/ivsqs9dtxvk4
and Fellilücke
https://s.geo.admin.ch/xkl65av77nf1
to ROUTER_LATE.
Both are sufficiently high up, and give Clients with direct line of sight down at the bottom of the valleys a first chance of transmit and receive / acknowledge, too.

Sven

[shalberd]

I have recently been to Chur and noticed that in Chur, there was no way to successfully send out a message .... neither on MEDIUM_FAST nor on LONG_FAST. The situation seems to get better when driving towards Zurich around Bad Ragaz and Landquart, on MEDIUM_FAST and sent from the train.
Would be cool if we were able to get a node on Chäserrugg above Walensee https://s.geo.admin.ch/dp5ft6jih0av
I will definitely put up a node in the Rhine valley near Distentis, Cuolm da Vi (Role Client, due to lateral valley), this September or October, with official approval.
https://s.geo.admin.ch/okgtcz8kcjmv

My soon-to-come FronalpStock SZ node (Role Client at first) should also improve coverage to Uri / Andermatt. That node, too, is installed with official approval. https://s.geo.admin.ch/czfja05uyfyw

[zjosua]

Here's the nodes I saw hiking in the Churfirsten - Alvier range. Setting was always on MEDIUM_FAST.

Even without seeing which of these nodes were reached without hops, the map shows no nodes after Sargans in the direction of Landquart - Chur. These should be easily reachable from the Alvier region.

I've also summited some 3'000m peaks in Engadina Bassa and brought the Meshtastic device on two different days. Again only on MEDIUM_FAST, not a single node was seen. I didn't try to get anything sent out, but since I spend around 90 minutes on the summit for SOTA activations, that should be plenty of time to pick up any nodes in the region.

[zjosua]

I was on Glegghorn (summit altitude 2246m, located 8km north of Landquart) yesterday. The summit has line of sight to Chur.
The only nodes south of me were the Rätia66 Relais in Valzeina and someone in Trimmis.

The person in Trimmis texted me to say that they were only connected to the mesh thanks to my node being configured as client while I was on the summit.
Apparently there is something wrong with the Rätia66 Relais. It is in a great location, but it seems that there really aren't any nodes in Chur on MEDIUM_FAST.

[shalberd]

@zjosua about Glegghorn north of Landquart: thank you for having tried and reporting here. Regarding Chur, yes, there is definitely a node missing there. As of now, we have nodes further towards Ilanz in Valata near Obersaxen and then two node by the NFN group at Cuolm da Vi and at Fellilücke / Felli gap for connection up north to SZ, ZG etc. The Cuolm da Vi node could potentially be very useful for Chur nodes, too. Someone needs to start setting up a device role ROUTER_LATE node in a high, strategic location above the city of Chur. Oksaberg or so ..

[Haflinger73]

Hi everyone, sorry for the delay.
I was enjoying my 10-week sabbatical and traveling abroad (Croatia/Romania).
I find the Router_Late topic very interesting.
Yes, we do have too many routers (and some of them are located in completely unsuitable places > ETH).
I myself have "problems" with a mesh network operator in Dang******, Germany, who operates almost all of his nodes as routers.
Unfortunately, he doesn't respond to any messages, and I suspect he's using the "Store & Forward" function, which requires certain nodes to be configured as routers: https://meshtastic.org/docs/configuration/module/store-and-forward-module/
To avoid constantly losing 2-3 hops, I have these nodes set to "Ignore" in the app (like the Elrir router), and I don't see any other option at the moment.
It seems that Router_Late works well and doesn't appear to have any disadvantages.
If that's the case, I'll revise the netiquette guidelines and the fact sheet regarding node role selection.
73&55 Haflinger73

[shalberd]

seems that Router_Late works well and doesn't appear to have any disadvantages.
If that's the case, I'll revise the netiquette guidelines and the fact sheet regarding node role selection.
73&55 Haflinger73

Yes, both from a code logic perspective as well as from practical impact in our scenarios, one can safely say: ROUTER_LATE for nodes up on high mountains accessible from all sides. Because ROUTER_LATE always rebroadcasts packets, but does not cut in line / grab hops before other nodes, like clients in the "Mittelland" or in general any clients.
https://meshtastic.org/docs/configuration/radio/device/#roles
ROUTER_LATE
"Infrastructure node that always rebroadcasts packets once but only after all other modes, ensuring additional coverage for local clusters."

Aside from that, on high buildings or hills that have good exposure from all sides, Client is the best device role.
Actually, as mentioned, on Fronalpstock SZ, even Client does a phenomenal job so far.

[Haflinger73]

I've posted the topic in our Facebook group with almost 480 members.
3-4 routers have already changed roles.

Here's the text from the post:

Does the "Router" role make sense for the Swiss topography/node density?
A brief digression into the history of Meshtastic. In 2019, Kevin Hester developed a Lora communication system to ensure communication for hikers and paragliders in remote areas.
The system was designed for 50-80 nodes. The node roles emerged: client, router, and over time, a few more.
Routers are designed to forward messages from high-altitude points over long distances (LF 150km+ MF 120km+).
But does this work with our high node density, high mountain nodes, and "short" distances in Switzerland?
Sven Fox71 (github alias shalberd) has taken a closer look at the topic, as the firmware update 2.6 introduces a new form of routing called "Next-Hop Routing" for direct messages. This means that as soon as an acknowledgment for a direct message arrives, the nodes remember the route for subsequent transmissions.
With our fantastic mountain routers at 1500-2000 meters above sea level in central Switzerland, many routings from clients (including those in Aargau and Zurich) that are actually within line of sight were routed via these "well-located" routers, as they are always the first to forward the packet.
Pointless hops were generated that weren't necessary.
In consultation with the developers of Meshtastic (meshtastic/firmware#6904 (comment)), the recommendation was that the "Router" role is not recommended in most locations in Switzerland, as the nodes can cover too large an area.
Recommendation:
Run all nodes with the "Router" role on Router_Late (for truly mountain nodes) or as clients.
This allows us to drastically reduce the hop count and also reduce the channel load caused by unnecessary packet transmissions.
The NFN nodes in central Switzerland have already completely switched over, and I will also switch over my two routers in Basel and on the Schwyberg (France) in due course (a one-day trip).
Please also share this information with your network partners via the mesh (and other channels) with known router operators.
If you don't have success with these people, there is still the option of setting these nodes to "ignore" in the app. This means they won't be considered in the routing, at least not on the outward journey.
The fact sheet: Meshtastic Netiquette and Role Distribution will also be updated and made available to you.
73&55 Haflinger73

[shalberd]

Another suggestion: because we have HB* Users in our midst, it'd be good to emphasize that @tht FYI for the HAM community: User HAM-Mode shall not be enabled. That is, in terms of underlying source code, is_licensed on EU_868 always needs to be false, slider to the left, because 868 Mhz ISM range is not an amateur radio band. That is the default anyways, just a little misleading.
https://meshtastic.org/docs/configuration/radio/user/#is-licensed-ham
The HAM name itself can be used, of course, as long name: https://meshtastic.org/docs/configuration/radio/user/#long-name
I really like how Meshtastic on EU_868 / 869.525 Mhz captures the imagination and radio spirit of both CB voice radio enthusiasts as well as HAM HB9 and HB3 licensed people. Beautiful.

[MeshTrafficObserver]

@shalberd @Haflinger73 Thank you both, I will update the netiquette in the following days and explain the why for router-late (with Simon's illustration).

@shalberd Before adding a comment about the HAM mode, what's you're concern with it? Does it disable the 10% duty cycle or only take away the power limit?

[shalberd]

@MeshTrafficObserver correct, duty cycle. The Admin-Module, which sets settings in firmware, sets

config.lora.override_duty_cycle = true

if

owner.is_licensed = true

https://github.com/meshtastic/firmware/blob/develop/src/modules/AdminModule.cpp#L1332

Very bad and a real config trap even for HAM HB* users who in good faith enable HAM user mode via the slider to the right ...

It is also that way becoming less useful for HAM users interested in EU_868, because then, their network is disconnected.
Plus, EU_868 is not an official HAM radio band, nowhere in Europe.

On the other hand, just using the HAM call sign as long name is fine, but definitely not enabling user HAM mode.

I am more concerned about duty cycle than I am about power limit dBi, because both CB and HAM people can modify the LoRa power limits, and never ever should on EU_868. But an automatic setting of duty cycle limit ignore to true is really bad, in case that HAM mode is enabled, on EU 868. In addition, contrary to what a Danish HAM once thought, even on EU_433 in Switzerland, which can be used in HAM mode, duty cycle limit applies, while power limits are higher.
So that firmware admin module logic that turns off Lora config duty cycle limit (override true) when in HAM mode is just plain wrong and a config trap, doesn't matter whether whether EU_433 or EU_868.

Also, in other parts of the firmware, the node, if is_licensed: true, does not forward packages anymore it cannot decrypt in the common channel 0, rendering it useless. Also, no node-level private / public keys for direct messaging are generated ...

I hope I am making sense, sometimes too source-code oriented.

[tht]

Thanks @shalberd for this reminder. As far as I know all encryption will be disabled as soon as you enable the licensed operator mode. As our default channel is encrypted (with a well-known key) it should not be possible to participate in the mesh when enabling this setting. It may still be possible that your node forwards a packet but you'll not be able to participate in the chat on the default channels.

Still, it's a good idea to also mention this in the Netiquette.

[shalberd]

it should not be possible to participate in the mesh when enabling this setting

Correct, since firmware 2.6, that separation is there between licensed traffic and unlicensed traffic. Kinda neat for 433 Mhz, in my view (the comments in the files section are pretty well-written even for people that don't care for reading source code logic):

meshtastic/firmware#6068
meshtastic/firmware#6361

Still, on EU_868, this is merely a safeguard and 869.525 Mhz is not an amateur radio band in Switzerland, as opposed to 433 Mhz.
So, on EU_868, never turn on HAM user mode. You can take part as a HAM user, set your HB name as long name, just really don't
turn on HAM mode / is_licensed: true. It does not add any value to 868 Mhz ISM.

Side note:
On EU_433, watch out and double-check in LoRa settings that the "override duty cycle" is set to false / slider to the left.
The U.S. people really don't care too much for our duty cycle regulations, it seems ...

[shalberd]

On the topic of Router vs Router_Late, the term Router itself, the focus of router (timing more than placement), see this recent blog post:

https://meshtastic.org/blog/demystifying-router-late/

I also added a comment in the discussion section https://github.com/orgs/meshtastic/discussions/409#discussioncomment-14523768

[Haflinger73]

It's a shame there haven't been any posts here for a while. But it's encouraging to see the growth of the Medium Mesh network. Eastern Switzerland has several dedicated users who want to suspend router nodes, and Western Switzerland is also increasingly switching to Medium.

Apart from a few "resistant" or unreachable colleagues, all routers have switched to Router_Late. Sven, who is also active here, has noticed that we have a lot of duplicate packets in the mesh because Router_Late forwards everything without checking, even if it has already sent the same packet. Therefore, the request is: In areas with a high Router_Late density, please set the less exposed nodes to Client mode. These nodes will check what they have already seen and will no longer forward it.

Furthermore, several nodes in French-speaking Switzerland are burdening the mesh with unnecessary transmissions. Many private channels are being operated, with a maximum of 7 hops, and some are using MQTT downstream.
Yes, of course Meshtastic allows it, but the Americans have a much wider bandwidth in their ISM band than we do in Europe/Switzerland, which leads to problems for us.

[Haflinger73]

We are also working on a revised version of the Meshtastic Netiquette.
The router issue is being addressed, and Client_Base is a topic.
Generally, new features that put a strain on the mesh network are being covered.
This will be available soon to help users optimize their mesh network.

73&55 Haflinger73 Simon

[PatrickDch]

Thank you, looking forward to it ☺️ - GU73

[Haflinger73]

Duplicate packets that burden the mesh
Since we are constantly working to optimize the mesh, Sven Fox71 noticed that in Central Switzerland, around 60% of packets (messages/telemetry) are duplicates, meaning messages that have been repeated multiple times by the mesh.

This is primarily due to routers (which are no longer used in Switzerland) and Router_Late, as these roles, unlike clients, do not check their history to see if they have already received/forwarded the same packet.

It is unclear to what extent Client_Base (which also operates within the "early rebroadcast window") also repeats packets.

Have you noticed any improvements in routing/message delivery when using your Client_Base role? If not, please switch your Rofe node back to the "Client" role.

How to monitor duplicates on your own device:
On Android, you can enable service notifications in your phone's settings > Notifications > App notifications > Meshtastic > Notification categories > Enable service notifications. At the top of the screen, "Connected: 129 online" will appear. For example, on the right, you can use the small arrow to "expand" the notification. (Sorry, I don't know how well Google Translate translates the Android menus.)
For iOS, someone here can surely describe the path as well, if that option is available on Apple devices.

On my home node, between 40-50% of packets are duplicated and therefore uselessly, thus consuming bandwidth.

Conclusion:

In areas with a high density of router_late, set some nodes to client mode. Check the favorites list on your client base nodes to ensure that only your home nodes are listed, or switch the parent node back to client mode.

Let's see how things develop.

[shalberd]

I will switch Fronalpstock SZ back to CLIENT mode some time soon this December because Gottertli above Brunnen SZ, and in general nodes in the Brunnen SZ area, as opposed to Fronalpstock, seems to be the main point of travel to best reach Fellilücke UR.
This should already decrease package duplicates in the Schwyz Talkessel area.
Will continue to monitor.
Another important task we have for next year is to change node Mythen from Router to Client.

[RCGV1]

Hello, I visited Switzerland earlier this year and I am still subscribed to this thread. I am extremely confused about the choice to not use router role. In our mesh in the Bay Area we use chains of mountaintop routers (with the new zero hop code in 2.7) to slingshot packets long distances and router_lates to fill in gaps. This seems weird to me that router_late is the main infrastructure in this mesh.

[Haflinger73]

Hi Benjamin, the reason we're doing without routers is quite simple.
Due to the topography with its extremely high mountains, connections between clients in valleys 50-80km away in the lowlands, which would actually be in direct contact, were routed through multiple mountain routers, drastically increasing the number of hops.
We're not completely foregoing Router_Late, but in areas with too many Router_Late values, we have an extremely high number of duplicate packets (>60% of packets), since the router roles don't check if the packets have already been seen.
Router_Late at the corners of the mesh, or at the beginning and end of a valley, definitely makes sense, also with regard to zero hops.
You mustn't forget, in Europe we have one Band with 125kHz bandwidth on the frequency 869.525MHz on the ISM band! You in the USA have 64 bands with 125kHz. on 915MHz. We have to use every opportunity to reduce the load on the mesh.
Furthermore, we have a duty cycle of 10%, which I believe is also unregulated in your area.
The transmission power is also limited to 27 dBm ERP.
I think that should explain a lot...

[microteq]

Hi

I’m currently working on an emergency app for hikers that is based on Meshtastic technology. The prototype has been working well so far, except for the small issue with the propagation of public keys, which I have asked about separately in the developer forum.

Now I still need to make a decision, which is honestly quite difficult for me. To ensure that an emergency call gets through reliably, I would prefer to keep the radio network as much to myself as possible, which is why the app is currently running on the LONG_MODERATE frequency band. However, in that case the app is completely dependent on nodes (Seeed or Wizmesh cards) that are carried by other hikers within radio range.

If I were to switch to MEDIUM_FAST, the app could benefit from existing nodes/routers. However, this comes with the risk that in an emergency the network might already be overloaded by other users, and the emergency call might therefore not get through.

What is your opinion on this?

[shalberd]

Hi Martin, @neukommmartin good to hear from you. This is fox 71. I agree that in GR, MEDIUM_FAST density is low and associated channel utilization as well.

Hi microteq, Just one thing to keep in mind from our mountain node perspective: because we noticed mountain node channel utilization sometimes being above 30%

https://www.reddit.com/r/meshtastic/comments/1hqh5c7/can_we_have_an_in_depth_explanation_of_this_image/

in the "Funkmetriken" / Device metrics logs, we decided to keep device rebroadcast mode to LOCAL_ONLY, meaning only messages and packets on the well-known primary channel 0 with the well-known pre-shared-key, as well as direct messages, are forwarded.
https://github.com/meshtastic/firmware/blob/v2.7.15.567b8ea/src/modules/RoutingModule.cpp#L13
I am speaking of a lot of the hill nodes in AG, HR*, as well as my NFN fox 71 nodes on high mountains.

Private secondary channels, in reality more user groups with separate keys, are fine, but with the constraints of almost all LoRa EU_868 presets having only one frequency slot, it becomes next to impossible to transmit every private channel and associated packets there is. Going to shorter presets would not change that assertion, because with people using MQTT downlinks and multiple channels / secondary groups, the channel util will always be high when selecting rebroadcast mode "all".

As for public keys: there is no mechanism for public key updates as of now. That is due to man-in-the-middle concerns on the side of the developers and protocol key exchange issues, I think.
When elements like the node public / private key change, but also when e.g. only part of the long name changes, both nodes have to delete themselves mutually and wait to re-appear in order for direct messages to work again.

Overall, what I'm saying: if you use completely own nodes and don't expect the larger mesh to also support you, all is fine.
If you expect the entire mesh to forward packets for you, you might sometimes not get that far, for the reasons outlined.
Essentially, we are working with that New Hampshire Mesh speaks of as option 1 https://nhmesh.com/guides/channel-setup

[microteq]

Thank you both very much for your information.

@shalberd
This is interesting, let me try to understand: To prevent my app from being burdened by other messages, I have assigned its own PSK to channel 0 (SOS channel). This way, only messages that truly come from the app are visible on that channel. On the secondary channels, I allow private messages - for example, if a hiking group has to split up due to an emergency and the members still need to stay in contact with each other.

Am I understanding correctly that, in this case, switching to MEDIUM-FAST doesn’t benefit me, because none of the app’s messages are routed anyway by the existing routers?

[shalberd]

To prevent my app from being burdened by other messages, I have assigned its own PSK to channel 0 (SOS channel)

Yes, that is the "going private completely" option, good to do it that way with your own PSK on channel 0.

Am I understanding correctly that, in this case, switching to MEDIUM-FAST doesn’t benefit me, because none of the app’s messages are routed anyway by the existing routers?

That is correct.

I'd say almost all of your mountain and hill nodes have a setup with channel 0 and the default pre-shared-key / PSK.
ONLY rebroadcast mode ALL forwards all packages, regardless of differing encryption keys.
It might be that there are still mountain nodes with rebroadcast mode ALL, but even then, those nodes run into
channel util issues and duty cycle limits. Cause there are over 800 nodes on medium_fast channel 0, well-known key, now.

So yes, we unfortunately cannot forward your messages on channel 0, with your own, custom key, on our network.
Every mountain node would have to be configured with your channel 0 key, which is not possible because we rely on the well-known key.

If you want to use the larger mesh for forwarding on medium_fast, you have to go with the default pre-shared-key on channel 0.

[microteq]

ok, many thanks for your detailed explanation :-)

[shalberd]

no problem. what is good about your using LONG_MODERATE or LONG_SLOW:

Both presets use a different frequency slot / frequency on EU_868, 869.4625 Mhz instead of 869.525 for the rest of the presets, so, you have the bandwidth for yourself.

Can be seen / made clear via the frequency slot calculator: https://meshtastic.org/docs/overview/radio-settings/#frequency-slot-calculator.

Also, a while ago, that article helped me understand better: https://nhmesh.com/guides/channel-setup

Also, as a tip, stay with the default role CLIENT, it is just fine. No need for either Router or Router_Late.

[beeekey]

Hi

I got into Meshtastic and Meshcore at the beginning of Dezember. I was not so happy to find the only point to discuss topics regarding the swiss mesh only on github.

So i setup a forum which we could use. I happily invite you to continue discussions in a better organized way on https://forum.swiss-mesh.ch/.

Kind regards
beeekey

[Panaetius]

I came across https://forum.mesh-schweiz.ch/ last week, not sure who runs it and it doesn't seem to have been mentioned here before.

[beeekey]

I didn't notice it. But it looks like it is swiss german oriented and I hope we can reach all the different languages of Switzerland with the new one.