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

[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

[FJF130]

Very nice piece of work.
Thank you very much.
I am not sure though how many users from the FB actually will find their way to this specific GitHub Discussion.if you are not allowed to publish a link to it. Would you feel comfortable to post the graphics in a FB-Post for those who do not know how to access GitHub?

[salfare]

Thanks for the amazing work!
as I see my node "stargate" relatively prominent in the nodeinfo category, I started to analyse.
following the netiquette, I configured 10800 as nodeinfo broadcast since long time ago, for testing purposes sometimes reduced to 7200.
btw: stargate is a rak4631 currently on 2.4.0.46d7b82. newer releases have been tested but often resulted in spontaneous loss of configuration.

what I observed is that the node broadcasts in exactly the configured interval.
what contributes significantly (more than 95%) to the high number of nodeinfo messages, are "directed" nodeinfos i.e. not broadcasted but directly addressed to another node. Often this is triggered by previous messages for example a position or telemetry messages from nodeX and my node then immediately sends a nodeinfo addressed to nodeX.

has anybody observed similar behaviour ? could the cause be that the nodedb is flooded by to many nodes and therefore needs to be refreshed often?

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

[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

[mariotti]

"this" => github discussions

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

:)