Berlin Chaos Mesh Forum

https://github.com/meshcore-dev/MeshCore/releases/tag/companion-v1.12.0

Kern-Änderungen in v1.12.0

Neue unterstützte Boards
– Thinknode M6
– Thinknode M3
– RAK3401
– RAK11310
– Meshtiny

Low-Power / Energie-Management
– nRF low power recovery manager – ein Mechanismus zur Verbesserung der Energieeffizienz und Wiederaufnahme aus stromsparenden Zuständen.

BLE neu gedacht
– Bluetooth-Code komplett neu geschrieben

WiFi / Serielle Stabilität
– Fixes für WiFi-Serial

Kontakte & Daten
– Contacts-DB kann alte Einträge überschreiben – neue Nachrichten bekommt man auch trotz voller DB

️ Neue Einstellungen
– buzzer quiet – stiller Alarm
– gps enabled – GPS standardmäßig nutzbar
– gps interval – konfigurierbare GPS-Intervalle

Wir treffen uns jeden zweiten Mittwoch im Monat in der c-base um 19 Uhr um über LoRa Meshes zu sprechen!

Ha, dachtet ihr euch so! Wir treffen uns nicht in der c-base! Diesmal nutzen wir den langen Abend, um zum Fernsehturm (und auf den Müggelturm) in den Müggelbergen zu wandern. Dort schicken wir Nachrichten in den Mesh und verstecken Nodes in der Wildness.

Treffpunkt: 17:30 Uhr (pünktlich) Straßenbahnhaltestelle Wendenschloß (Start 18:00 Uhr, Sonnenuntergang 21:28, Dämmerung 22:17)

Route: Wendenschloß - Kanonenberg - Müggelturm - Fernsehturm (circa 5km eine Richtung) und zurück (circa 10km gesamt)

Wer keine Lust auf wandern hat, kann auch mit dem Auto zum Müggelturm fahren und dort zu uns zu stoßen.

Mitbringen:

• feste Schuhe
• Flasche Wasser
• Snacks
• Powerbank
• soviele Nodes und Antennen wie ihr tragen wollt

Koordination:

• #berlinmesh (Meshcore, UK/Narrow)
• BerlinMesh (Meshtastic, MediumFast, PSK Nmh7EooP2Tsc+7pvPwXLcEDDuYhk+fBo2GLnbA1Y1sg=)

PotatoMesh v0.6.0 kann jetzt auch Meshcore!

Live: https://potatomesh.net/

Release: https://github.com/l5yth/potato-mesh/releases/tag/v0.6.0

Berlin Meshtastic nutzt das MediumFast preset. Und stellt sicher, dass ihr Hops auf 7 setzt.

Eine empfohlene Konfiguration für Berlin findet ihr auf Codeberg:

https://codeberg.org/berlinmesh/meshtastic/src/branch/main/berlin.yml

@Bo sagte in Neu im LoRa-Game...:

Gibt es zum Beispiel einen Discord‑Server

Ein Großteil der @meshtastic und @meshcore Nutzer sind Discord gegenüber eher abweisend eingestellt.

Wir wollen ja krisensicher sein, daher haben wir einen Matrix Space, kein Discord: https://matrix.to/#/#berlinmesh:c-base.org - funktioniert aber ähnlich.

@Timo_V sagte in Neu im LoRa-Game...:

Kleiner Hinwris noch: Die Heltecs sind sehr verbreitet in D, da gut zu bekommen, haben aber einen ESP32 als chip, der mehr verbraucht als Geräte mit nrf52 Chip.

Das ist ein wichtiger Hinweis. Ich habe mal ein Lilygo T-Echo Lite (NRF52) mit einem Heltec V4 jeweils an eine 1000mAh Batterie gesteckt und der Unterschied ist sehr groß. Auf dem T-Echo bekomme ich 24-26h Laufleistung, auf dem V4 nur 7-8h.

Moin Moin, danke fürs aufsetzen.

Ich schlage zwei Dinge vor: einmal können wir das hier eigentlich auch alles auf Deutsch halten, weil die meisten das wahrscheinlich verstehen oder lernen, und zum anderen würde ich die folgende Logik fürs Forum vorschlagen:

• Organisation: Diskussionen zu Initiative, Treffen, und allgemeiner Koordinierung
• Meshtastic
• Meshcore
• Reticulum
• Off Topic

Ich denke nicht, dass wir ein extra Forum für Announcements brauchen aktuell. Und Reticulum würde ich jetzt einfach auch schonmal mitdenken.

Auch brauchen wir vorerst mal keine Subforen, wie z.B. Firmware. Das kann erstmal weg und ich würde das bei Bedarf organisch wachsen lassen und bei Bedarf anpassen.

Was meint ihr?

In Meshtastic, wir nutzen TEST und SOS als Test- und Notfall-Kanäle. Das sind andere Kanäle als Test, test, tEST, usw, da die Zuordnung in der Firmware case-sensitive ist.

Wen es interessiert: Aus dem Private Key (PSK) und dem Kanal-Namen wird eine ID zwischen 0 und 255 generiert, die über den Mesh mit ausgesendet wird und womit die entsprechenden Knoten dann feststellen können, ob sie angesprochen wurden oder nicht.

Nicht zu verwechseln mit den Kanälen 0-7, die man manuell konfigurieren kann. (Hier ist das Protokoll etwas umständlich entworfen.)

Alle Channels für Berlin sind im Detail auf Codeberg dokumentiert:

https://codeberg.org/berlinmesh/meshtastic/src/branch/main/CHANNELS.md

Schickt der dann Reticulum Pakete über Meshtastic oder wie kann man sich das vorstellen? Und was ist der Vorteil gegenüber RNode direkt? Weil man dann beides benutzen kann?

Vielleicht können wir ja mal im März ein Reticulum-spezifisches Meetup machen.

Als Fortführung der Diskussion in https://forum.chaosmesh.net/topic/16/regionen-in-meshcore/9

Und der Nutzung der folgenden Scopes https://meshcore-de.fyi/meshcore:allgemeines:regions:reale-regions-in-repeatern#berlin_brandenburg

Mache ich folgenden Gegenvorschlag zur Konsolidierung:

1. Kanäle: Public, #berlin, #brandenburg und wir lösen uns vom Kanal #berlinbrandenburg
2. Scopes: de, de-ost, de-bebb und wir trennen uns von dem Konzept, dass de-bb und de-be eigene Scopes brauchen

Das sähe dann so aus

• Public: de oder de-ost je nach Geschmack
• #berlin: de-bebb
• #brandenburg: de-bebb
• keine starke Meinung zu Berzirken und Landkreisen, aber auch die würde ich alle entfernen

Begründung:

1. Einfachheit: zu kompliziert all die Scopes überall zu verwalten und zu kommunizieren
2. Geografie: es gibt kaum einen Mehrwert Berlin und Brandenburg zu trennen, vor allem z.B. weil Berlin viel Infrastruktur hat, die ein de-bb Scope nicht nutzen kann und "außen rum" geroutet werden muss.

Ich werde das auch am 13.05. im Berlin Chaos Mesh Meetup in der c-base vorschlagen und beim MC Treffen am 04.06. bei D20 auch nochmal diskutieren wollen.

Themen: Meshtastic, Meshcore, Reticulum, und andere LoRa- und Mesh-fähige Ideen.

Immer jeden zweiten Mittwoch im Monat in der C-Base. Nächstes Treffen: 11.02.2026 um 19 Uhr.

Eintritt frei, keine Anmeldung nötig, es gibt eine Bar mit Getränken - https://c-base.org/

Letztes mal hatten wir die Idee von Berlin Mesh als Koordinierungsforum diskutiert. Gerne können wir auch technische Themen vertiefen dieses mal.

Schlagt vor, was ihr machen wollt!

Edit: Resultat siehe hier: Reticulum Berlin 869.475MHz 125kHz SF 7 CR 5 TX 22

https://forum.chaosmesh.net/topic/72/preset-reticulum-berlin-869.475mhz-125khz-sf-7-cr-5?_=1781805711484

Diskussion dazu hier im Thread.

Ok, dann wie folgt?

• Organisation: Koordination von Initiativen, Treffen, Strukturen und kollektiver Entscheidungsfindung
• Meshtastic: Offene Diskussionen rund um Meshtastic-Netze, Nutzung und Weiterentwicklung
  • Apps & Tools: Software, Visualisierung, Auswertung und Integrationen für Meshtastic-Netze
  • Firmware: Entwicklung, Builds, Konfigurationen und Firmware-Modifikationen
• Meshcore: Diskussionen zum Meshcore-Stack, Architektur und praktischen Einsatz
  • Apps & Tools: Werkzeuge, Clients und experimentelle Anwendungen für Meshcore
  • Firmware: Low-Level-Entwicklung, Protokolle und Embedded-Implementierungen
  • Repeater Admins: Betrieb, Wartung und Koordination von Meshcore-Repeater-Infrastruktur
• Reticulum: Autonome Netzwerke, Routing-Philosophie und Anwendungen auf Reticulum-Basis
  • (Firmware wird hier nicht benötigt)
• Hardware: LoRa-Geräte, Antennen, Stromversorgung und experimentelle Eigenbauten
• Sonstiges LoRa: Alternative LoRa-Stacks, Protokolle und unabhängige Funkprojekte
• Off-Topic: Alles, was nicht passt, aber gesagt werden muss

Ich denke Hardware könnte gut ein extra Forum sein. Und sonstiges LoRa könnte auch mal Thema werden, e.g., LoRaWAN oder neue Protokolle in Zukunft.

Resultat der Diskussion: https://forum.chaosmesh.net/topic/54/reticulum-config-für-berlin-tbd

Reticulum Berlin Preset:

• Frequenz 869.475MHz
• Bandbreite 125kHz
• Spreading Factor 7
• Coding Rate 5

[[RNode Reticulum Berlin]]
  type = RNodeInterface
  enabled = yes
  frequency = 869475000
  bandwidth = 125000
  spreadingfactor = 7
  codingrate = 5
  txpower = 22

Letztes Meetup waren 14 Leute da, wenn zum Basteln 12-18 Leute kommen, würde ich einfach mal 20 Sets einplanen (falls mal was kaputt geht).

Pro set zwei Antennen (1x SMA Kabel, 1x IPEX Kabel, 2x SMA Connector, 2mm Messingdraht). Jeder kann 2x 868 MHz Antennen bauen, aber nicht jeder kann 433 MHz Antennen bauen (sonst reicht der Draht nicht).

Materialkosten: 7 Euro (zwei Antennen)

20 Sets für 40 Antennen (ohne Schablone): 139,94 Euro

139.94 / 40 * 2 = 6,997 Euro pro Set (für 2 Antennen, ergo 3,49 pro Antenne)

Danke alle fürs zahlreiche Erscheinen! Wir haben 20 Sets komplett verlötet, die Planung ging auf.

So, diese Woche ist schonwieder soweit! Aus aktuellem Anlass möchte ich noch zwei andere Theme vorschlagen:

• Meshcore regionen & channel
• PotatoMesh für Meshcore & Reticulum

@io_kassel sagte:

Ich hatte gelesen es gibt noch einen Umzug?

Moin und willkommen! Der Umzug ist schon passiert, wir bleiben jetzt hier auf der Domain!

@io_kassel sagte:

Wie findest du die Idee mit dem Podcast?

Finde ich gut. Ich bin zwar schon länger hier im Mesh unterwegs, aber gehöre definitiv nicht zur ersten Generation. Also kommt drauf an, wie weit ihr zurück gehen wollt in der Historie.

Ich finde ja die Berliner Entwicklung an sich auch schon ganz spannend, von Meshtastic LongFast zu MediumFast und jetzt mit recht großem Momentum zu Meshcore.

Ich persönlich unterstütze keine Option, die außerhalb des 500-mW-Bands liegt oder auf MeshCore sitzt. Beides ist nicht zukunftssicher.

869,700 liegt komplett außerhalb von 869,400–869,650. Dort sind nur <5 mW erlaubt. Das heißt: volle Leistung aufgeben, genau die Prämisse, mit der wir angefangen haben. Fällt raus.

869,5875 und 869,525 sitzen beide auf dem Meshcore Block (869,587-869,649). Unterschiedliche Präambeln machen daraus keine Orthogonalität; das ist PHY, nicht Layer 3, und verhindert nur Fehl-Sync. Co-Kanal-Energie hebt trotzdem den Noise Floor und frisst Pakete, bei gleichem Spread Factor direkt. Und Meshcore wächst, wer sich heute auf deren Frequenz legt, muss in einem Jahr umziehen, wenn der Verkehr dort zunimmt.

Was übrig bleibt; volle Leistung, 125 kHz, MeshCore frei: ist weiterhin nur das Fenster 869,4625 bis 869,524. Darin liegt 869,475. Das bleibt mein Vorschlag.

Wenn das SDR dieses Fenster wirklich verrauscht zeigt, dann stehen die Anforderungen im Konflikt, und wir entscheiden offen: Leistung runter oder MeshCore-Überlapp in Kauf nehmen.

Ich denke ich unterstütze die Initiative im Prinzip, aber ich persönlich werde mich da jetzt zurückhalten.

Ich finde den 1. April sportlich, zumal ihr ja selber zugebt, dass der Upstream Code noch nicht fertig ist.

So große Probleme haben wir doch nicht im Mesh, dass wir das jetzt überstürzen müssen, oder?

Ich würde dem ganzen 4-5 Monate Zeit geben und erstmal den ganzen Repeatern erklären, wie Regions funktionieren und dann anfangen den Companions zu erklären, dass sie scopen müssen.

Für letzteres muss vor allem auf App-Seite eine bessere UX geschaffen werden, weil sonst viele Neueinsteiger und Umsteiger abhängen, die das Feature gar nicht oder zu spät entdecken und dann denken, dass Meshcore nicht funktioniert, weil ihre unscoped Messages nicht durchkommen.

Also wie gesagt, ich unterstütze Regions und Scopes, aber ich verstehe nicht warum das jetzt so schnell gehen muss, vor allem bevor Apps und Firmware auagereift sind.