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 :-)

[Haflinger73]

As expected, medium_fast has created subnetworks. What barely worked on long_fast doesn't work on medium, which naturally causes some users to be dissatisfied. We should try to reconnect these areas to the Swiss mesh.

We can't simply insert a SIM card into the device and access the existing infrastructure.

WE ARE THE MESH, so it takes more effort in certain areas to make it work.

Attached is a PDF with the functions of the individual device roles.

https://drive.google.com/file/d/1p8M-uI-Ozn-Bv_kCiFrEhlskZVio9t2Z/view?usp=sharing

We currently have too many routers in the network in inconvenient locations, which torpedo routing.

Best regards, Simon Haflinger73

[White-Whizard]

Hoi Simon, I am not sure if someone mentioned that already. But, thank you very much (merci!) for the hard and lot's of work you are investing into the SwissMesh 👍🏼.

[Haflinger73]

This is just meant to be helpful for newbies or users who aren't as familiar with the subject matter as we are. Many people buy a node and are surprised that nothing works, so they quickly mount a router on the roof.

[pferreir]

As expected, medium_fast has created subnetworks.

Can you clarify this, please? Does this mean we should all stick to long_fast?

[Haflinger73]

No, that means that new connections must now be created in certain areas > physical nodes on mountaintops.
Meshtastic (long_fast) was originally developed for a maximum of 50-80 nodes. The more nodes, the more data traffic (messages, telemetry, etc.). The transmission time in long_fast is too slow for the number of devices we currently operate in Switzerland; the frequency is "congested."
If users now continue to communicate on long_fast, this also puts a strain on the "faster" medium_fast network.
We all operate on 869.525 MHz.
You can't order anyone to use medium_fast, but it would be better not to have two systems running side by side.
Regards, Simon

[PatrickDch]

So you are suggesting to use medium_fast? Position Guemligen Client. Beste Gruessi

[Haflinger73]

Yes, definitely medium-fast. Thanks to three times the faster transmission time compared to long-fast, we simply have more "free space" on the frequency. In Gümligen near Muri, medium connections should also be good. Tomorrow I'll set up a temporary node on Schwengimatt to help a colleague in Burgdorf.

[pferreir]

I switched to medium_fast but cannot reach anyone.

[Haflinger73]

Short update on medium_Mesh
Northwestern Switzerland has established itself as medium.
Yesterday, the nodes in Central Switzerland were added. More and more nodes are also appearing in the Lake Zurich area.

Unfortunately, large parts of Eastern Switzerland and Lake Constance are still missing.
I've tried several times with my French-speaking colleagues and have received no response. Is anyone from French-speaking Switzerland here who could clarify the situation?
Some meshers from Valais would also be participating. However, without the Plaine Morte router, this is currently not possible.

Here is the link to the latest mesh netiquette.
https://drive.google.com/file/d/14Wd3UXRfnrliED6sUjJXb7UYsQ3iZCbp/view?usp=drive_link

Best regards, Simon Haflinger73

[PatrickDch]

Merci for the update, Simon 👌🏼 - GU73

[pferreir]

I'm in Geneva. Tried to switch to medium_fast the other day, but couldn't contact anyone. At least in the Geneva area, we would need the Salève and Onex routers to switch in order to make it possible for everyone to communicate.

[shalberd]

@pferreir oui, si vous pouviez contacter et convaincre les utilisateurs de Suisse romande des avantages de changer les routeurs elévés aux montagnes vers medium_fast, ça serait formidable.

[RCGV1]

Visiting Switzerland and decided to boot up my node on Schilthorn, got a ton of nodes on long fast. I also tried medium fast and I got more activity, got qsl from Haflinger Medium, 42d0 (not full node info), and 9b1f. Seems like Schilthorn is a good router location 😉.

[RCGV1]

I run the Bay Area Mesh in California USA, we switched to Medium Slow 6 months ago and were able to build out a supper reliable network which covers a vast distance. Check out what settings we recommend for our mesh

https://bayme.sh/docs/getting-started/recommended-settings/

[shalberd]

Ah, cool, yes, you were mentioned at https://meshtastic.org/blog/why-your-mesh-should-switch-from-longfast/ as well and what was written there inspired us here in Switzerland, too, when we were grappling with LONG_FAST. In the end, we decided on medium_fast preset and the intervals mentioned in the PDF I linked above. Our intervals for position updates, telemetry etc are recommended to be spaced out over an even longer timeframe. Over here in Europe, we only have one frequency slot on EU_868 and a per-device rolling 10% duty cycle limit TX (6 minutes per hour TX limit per device). We try to keep MQTT and topics on MQTT to an absolute minimum ...

[RCGV1]

Hi there, I received your message and suggestion via Channel 0 MEDIUM_FAST in Steinen, SZ. So, not too shabby, not bad at all. In any case: I know that there is a node up there on Schilthorn, just not sure whether it is medium_fast preset or not or still in operation: Schilthorn BE Node, long_fast or Medium_Fast? https://ibb.co/ksjV7CRk Greetings from Steinen, SZ: CB User fox 71 / Sven

The image has some text on it maybe you can find the owner that way.

[Haflinger73]

Sorry was shortly not "OnAir"


Greetings Simon Haflinger73

[RCGV1]

Some pictures

![Uploading 463026931...]

[shalberd]

@CamFlyerCH
Background: I am building firmware for LTO battery chemistry, mostly so that I get correct voltage and battery percentage readings:

@slintak explains:
"To get the correct battery percentage and icon display, you’ll need to compile the Meshtastic firmware yourself with LTO support enabled. This is done by adding the following line to the variants/rak4631/variant.h file:

#define CELL_TYPE_LTO

As far as I know, the official Meshtastic flasher doesn’t yet offer builds with different battery profiles, so it has to be done manually."

no problem, I did that based on
git checkout tags/v2.6.11.60ec05e
but when I build firmware myself (RAK4631 in my case), I get two files as output:
firmware.hex and firmware.uf2

How can I produce an nRF52 OTA / Update-over-Bluetooth
https://meshtastic.org/docs/getting-started/flashing-firmware/nrf52/ota/
xxx-ota.zip file from that?
In the regular firmware releases, I see that zip file contains:
firmware.bin
firmware.dat
and a manifest file, kind of like that in content:

{
    "manifest": {
        "application": {
            "bin_file": "firmware.bin",
            "dat_file": "firmware.dat",
            "init_packet_data": {
                "application_version": 4294967295,
                "device_revision": 65535,
                "device_type": 82,
                "firmware_crc16": 17034,
                "softdevice_req": [
                    182
                ]
            }
        },
        "dfu_version": 0.5
    }
}

[CamFlyerCH]

Hello Sven @shalberd
Yes, this .ZIP file is exactly the file I then flash in DFU mode with the nRF Connect software from my Android phone.
Should work fine !

[shalberd]

Hi @CamFlyerCH my current problem is that when I do my own firmware build
https://meshtastic.org/de/docs/development/firmware/build/#build
I only get the two files as output, but not the DFU Update / -ota zip.

Wie kann ich solch ein -ota.zip erstellen für over the air updates? Nach VS Studio Code PlatformIO: Build bekomme ich nur die 2 Dateien firmware.hex and firmware.uf2.

Hat es dafür ein Programm oder Script, also um das -ota Zip an sich zu erstellen aus firmware.hex z.B.? Ich baue ja gerade meine minim modifizierte Firmware mit Batteriestatus-Info für LTO Akku. Möchte aber gerne via Bluetooth / Over the air diese custom Firmware drauftun auf den Node.

exactly the file I then flash in DFU mode with the nRF Connect software

Ja, mit dem Standard-Fimrware-Download und -ota zip dort drin kein Problem, bin auch sehr ein Fan von diesem Mechano. Nur eben mit meiner eigenen in VS Code gebauten Firmware bekomme ich dieses -ota zip leider nicht.

I will try with this script manually:
https://github.com/meshtastic/firmware/blob/master/bin/build-nrf52.sh

[shalberd]

Problem solved ... I had a trailing, superfluent space in my Meshtastic folder name and once I removed that space, the commands and scripts worked fully:

$ pwd
/Meshtastic/firmware
$ ./bin/build-nrf52.sh rak4631

Checking size .pio/build/rak4631/firmware.elf
Building .pio/build/rak4631/firmware.hex
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [==        ]  19.2% (used 47756 bytes from 248832 bytes)
Flash: [========  ]  82.8% (used 674888 bytes from 815104 bytes)
Generating UF2 file
Converting to uf2, output size: 1350144, start address: 0x26000
Wrote 1350144 bytes to /Meshtastic/firmware/.pio/build/rak4631/firmware.uf2
Building .pio/build/rak4631/firmware.zip
Zip created at .pio/build/rak4631/firmware.zip
======================================================================================= [SUCCESS] Took 47.27 seconds =======================================================================================

Environment    Status    Duration
-------------  --------  ------------
rak4631        SUCCESS   00:00:47.271
======================================================================================= 1 succeeded in 00:00:47.271 =======================================================================================
Generating NRF52 dfu file
Generating NRF52 uf2 file
Converting to uf2, output size: 1350144, start address: 0x26000
Wrote 1350144 bytes to release//firmware-rak4631-2.6.11.60ec05e5.uf2
Copying hex file

[shalberd]

@CamFlyerCH I would like to use your initial hop limit modifications in this recent, stable beta release:

git checkout tags/v2.6.11.60ec05e

Why 2.6.11? Well, in ROUTER, ROUTER_LATE and REPEATER mode since 2.5.x, there had been a pretty grave error regarding direct messages / next hop routing message forwarding, that has been fixed in 2.6.11.

meshtastic/firmware#6904

https://github.com/search?q=repo%3ACamFlyerCH%2Fmeshtastic-firmware-mod%20Do0HopTelemetry&type=code

Questions:

1. Contrary to your comment in the source code, HOP_LIMITER is for LOCAL_ONLY and KNOWN_ONLY rebroadcast mode, right?
2. What is the reasoning / idea behind Do0HopTelemetry?
3. which files do I need to edit definitely? Just MeshTypes.h and router.cpp?
4. With MEDIUM_FAST, do we still need that additional limitation, ability to filter out packages to be forwarded depending on start hop count? I'd tend to say: yes. Of course, it'd be much better if the max hop limit in Meshtastic in general were reduced to 5 instead of 7 :-)

There have been a few changes to router.cpp recently, but I think this idea for our duty_cycle restricted, well-exposed routers,
to set rebroadcast mode to LOCAL_ONLY and to also not rebroadcast packages with extremely high initial hop counts is a good compromise, even though meshtastic maintainers, with their much more comfortable US regulatory and frequency situation perspective, never caught onto it, never merged it.

[CamFlyerCH]

I update my modded firmware to the newest source. You can pull it from https://github.com/CamFlyerCH/meshtastic-firmware-mod
Before compiling check / set the parameters in src\mesh\MeshTypes.h:

#define HOP_LIMITER 5
#define Do0HopTelemetry true

I think right now 5 is a good value IF you want to limit incoming by setting rebroadcast mode to LOCAL_ONLY (or KNOWN_ONLY).
(This is the way I implemented the remote possibility to enable or disable the MAX_HOP limit.)
The 0-hop of telemetry has the following goals I wanted to have for me:

• I want to receive telemetry from my remote router often.
• I receive my router directly, so there is no need to have these packets of my router re-sent by other nodes. No one very likely cares about that information anyway.
• I think its OK for a router to be "heard" also by nodes that are not directly receiving it. So also remote nodes can the the given name of the router in a trace route. It depends on your use case if you like this too for your node.

[shalberd]

Understood, thank you, I can see your reasoning very clearly now, it helped me, together with your code.

Q: The HOP_LIMITER value does not affect direct messages and their inital hop value evaluation when forwarding, does it? i.e. NextHopRouter.cpp ...

I still need to find out more / understand the interplay of NextHopRouter, ReliableRouter and Router
https://github.com/search?q=repo%3Ameshtastic%2Ffirmware+NextHopRouter&type=code

Thank you in particular for your explanation on your use case of 0 hop telemetry. A great compromise between Bluetooth / WLAN having too-low range for that use case (operator too far away from the router node node) and still being able to see telemetry data a little more often at close range / at 0 hops, without impacting the whole mesh negatively.

Awesome work! If you ask me, that, configurable in the App, too, should be part of Meshtastic officially, as an option. I am involved in open source projects, so yeah, it takes a lot of time and understanding by the official maintainers. So maybe not all hope is lost.

[shalberd]

@PatrickDch @CamFlyerCH I raised this point again in the related discussion

https://github.com/orgs/meshtastic/discussions/288

[shalberd]

about blocking packets with 5 or more hops vs blocking / ignoring nodes per device, the ignore list, see the comment here:

https://github.com/orgs/meshtastic/discussions/288#discussioncomment-13700662

Certainly, the ability to persist ignoring nodes (leading to no directing of packages to those ignored nodes and no packets from them being re-transmitted) is great to have, especially for our router operators out there that know what they're doing.

The contributor / maintainer also hinted that it might be a good idea in our Mesh to place a node named "update firmware to 2.6.11+" on the mesh to spread the word and improve stability.

We could even put a short url to the Netikette in a node name :-)

Plus, we could have a node on long_fast that says "switch to medium_fast".

What do I plan on my router: no firmware modification for now, just close monitoring of AirUtilTX. Possibly device rebroadcast mode "LOCAL_ONLY" instead of "ALL".

And firmware latest / 2.6.11.60ec05e Beta.

@CamFlyerCH I made a pitch for your idea of 0 hop telemetry / sensor etc. metrics for them to consider making that optionally configurable https://github.com/orgs/meshtastic/discussions/288#discussioncomment-13700815

The aim should be for as much useful stuff to be in the main codebase, not having to use forks.

[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

[CamFlyerCH]

I manage the router "Belpberg Chutzen". But why this router, that is running for weeks now, should have a negative impact for you to communicate with other nodes is unclear to me. But to answer that I need more details like your node name and a detailed problem description.

[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

[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.

[shalberd]

@tht today, almost all NFN Nodes in Inner Switzerland area were reconfigured from ROUTER to ROUTER_LATE. Can you, HB9HBD and HB9GZW, try out Direct Messaging to e.g. LagMesh or DO-79 once more, please? Also, please try some traceroutes to nodes you or your rooftop nodes can see directly with 0 hops and let me know the results. Hopefully, at least some of the "extremely remote ping pong" is resolved by now. Mythen node will follow soon, the change to ROUTER_LATE ....

@Haflinger73 I don't know who manages Elrir Router and ETH Router ... would be great if Elrir, on that small mountain around Schaffhausen, could switch to either ROUTER_LATE or CLIENT from ROUTER.

Also, ETH Router should really switch to CLIENT mode. ETH is a great institution, it grabs and attracts talent even without an overly "grabbing" ROUTER role ;-) Not sure who manages the ETH Router node either.

[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]

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.

[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 ...