fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software.
If you wish to join, contact us for an invite.
@fishingdev@richardwonka@fidepus#reticulum via #nomadnet also serves pages like #webpages which is a powerful & stable manner of providing up to date information in emergencies. Can for example provide automated #webcams over #lora#radio#mesh#network#reticulum allows for data transfer of sound and images and so is ideal for emergency communication over #radio#lora Saying it is too complex is like saying internet it too complex for emergencies. #rns is even simpler than internet & robust
Immer noch "Das ist dann wohl im Stream untergegangen." oder "Habe ich leider nicht gesehen". Deshalb heute noch einmal "da capo"
---
Alles unter einem Dach, die 3. ¯\_(ツ)_/¯
Über meine Idee, eine deutschsprachige Community für Mesh-Netzwerke wie Meshtastic, LXMF (Reticulum), MeshCore und weitere auf Discord zu erstellen, war ich ja nie so richtig glücklich.
Aber alle aktuellen und auch die zukünftigen Mesh-Netzwerke unter „einen Hut“ zu bringen, war und ist nun einmal, sowohl aus administrativer (!) als auch aus Nutzersicht, sinnvoll.
Mir wurde dann die Idee zugetragen (danke noch einmal dafür!), dies doch mit einem Space und Unterräumen auf Matrix zu realisieren. Diese Möglichkeit kannte ich bisher noch nicht, hatte sie aber gleich aufgegriffen und in die Tat umgesetzt.
Tatsächlich gefällt mir diese Lösung doch wesentlich besser, als die Umsetzung auf einem Discord-Server.
Jedes der drei oben genannten (Mesh) Systeme hat sicherlich seine Vor- und seine Nachteile. Reticulum kombiniert allerdings einige der (mir!) wichtigen Funktionen:
Es legt einen großen Wert auf Sicherheit (Verschlüsselung). Wer also Messenger wie #Session, #Threema oder #Signal statt #WhatsApp bevorzugt, lieg mit Reticulum (Sideband) sicherlich auch nicht falsch.
Reticulum ist dezentral (!) und selbstorganisierend. Andere Mesh-Netzwerke, die neben der Funkanbindung (LoRa), noch Zugänge untereinander über einen #MQTT-Server anbieten, funktionieren nur, solange diese Server online und nicht überlastet sind. Sideband lässt sich auch ganz einfach über das Internet nutzen und wenn dies ausfallen sollte, gibt es ja auch noch
LoRa (Funk) Verbindungen für Not- und Krisensituationen. Es lassen sich so einfach und mit kostengünstiger Hardware lokale Netzwerke aufbauen.
Ob ich also an einem PC mit Interzugang sitze, oder mein Smartphone mit Mobilfunkanbindung (oder eben auch mit einem über Bluetooth verbundenen LoRa Device) nutze, ich bin dann Teil des Netzwerkes und kann auf all diesen Geräten erreicht werden und Nachrichten versenden.
Ich weiß jetzt nicht mehr genau, wer diese Frage eigentlich gestellt hatte, aber ich hoffe, diese Erklärung hilft weiter.
Über meine Idee, eine deutschsprachige Community für Mesh-Netzwerke wie Meshtastic, LXMF (Reticulum), MeshCore und weitere auf Discord zu erstellen, war ich ja nie so richtig glücklich.
Aber alle aktuellen und auch die zukünftigen Mesh-Netzwerke unter „einen Hut“ zu bringen, war und ist nun einmal, sowohl aus administrativer (!) als auch aus Nutzersicht, sinnvoll.
Gestern wurde mir dann die Idee zugetragen (danke noch einmal dafür!), dies doch mit einem Space und Unterräumen auf Matrix zu realisieren. Diese Möglichkeit kannte ich bisher noch nicht, habe sie aber gleich aufgegriffen und heute in die Tat umgesetzt.
Tatsächlich gefällt mir diese Lösung doch wesentlich besser, als die Umsetzung auf einem Discord-Server.
The document is titled “IN RE: DELETE, DELETE, DELETE”
The document is a Public Notice from the Federal Communications Commission (FCC) titled DA-25-219A1, released on March 12, 2025. It announces the FCC’s initiative to review and eliminate unnecessary regulations as part of a deregulatory agenda.
Key Points: • Purpose: The FCC seeks public input on identifying regulations that may no longer be necessary or that impose unnecessary burdens on businesses. • Deregulatory Focus: The notice aligns with Executive Orders (14192 and 14219) which emphasize reducing regulatory obstacles and encouraging investment in telecommunications infrastructure and innovation. • Comments & Reply Deadline: • Initial comments due by April 11, 2025. • Reply comments due by April 28, 2025. • Evaluation Factors: • Cost-benefit analysis: Are there FCC regulations where costs exceed benefits? • Effectiveness over time: Have some regulations failed to meet their intended purpose? • Technological & market changes: Are there rules that are outdated due to advancements in technology? • Barriers to entry: Do regulations disproportionately impact small businesses? • Legal context changes: Have legal rulings (such as the Supreme Court’s Loper Bright decision overturning Chevron deference) altered the regulatory landscape?
Call for Public Input • The FCC invites detailed comments on specific rules that should be repealed or modified, considering factors such as: • Unnecessary compliance costs. • Regulatory barriers to competition. • Changes in the broader regulatory framework.
Submission & Filing Process • Comments should be submitted via the FCC’s Electronic Comment Filing System (ECFS). • Paper filings are accepted through designated FCC addresses.
This review aims to streamline regulations, promote competition, and align FCC policies with current market and technological realities.
MeshCore is a multi platform system for enabling secure text based communications utilising LoRa radio hardware. It can be used for Off-Grid Communication, Emergency Response & Disaster Recovery, Outdoor Activities, Tactical Security including law enforcement and private security and also IoT sensor networks.
Ich hatte irgendwo einmal gelesen, dass die Ursache des Fehlers “Critical Fault #3” bei einem Meshtastic Device, in der Hardware zu finden sein könnte.
Heute habe ich dann, nachdem der bestellte Ersatz für das “Xiao ESP32-S3 + Wio-SX1262 Kit” angekommen ist, den alten von dem Expansionsboard heruntergenommen - und siehe da. Eine der Verbindungsleisten war dann wohl doch nicht mehr so ganz in Ordnung. Mit dem neuen Kit funktioniert das Device wieder einwandfrei.
In den kommenden Tagen werde ich dann vielleicht einmal versuchen, wie in diesem Git-Repository (https://github.com/landandair/RNS_Over_Meshtastic) beschrieben, RNS-Over-Meshtastic einzurichten, um eine Brücke zwischen Reticulum und Meshtastic Systemen aufzubauen.
Ich habe jetzt den Außensensor an den Raspberry angeschlossen. Von dem I²C -Anschluss des Raspberrys an einen Adapter, dem “SparkFun QwiicBus - EndPoint” (https://www.berrybase.de/sparkfun-qwiicbus-endpoint), der die Signale dann über ein 10 Meter langes LAN-Kabel überträgt und auf der Gegenseite wieder andersherum an den Sensor führt.
So kann ich auch größere Entfernungen überbrücken und der BME280 funktioniert immer noch störungsfrei.
Da Reticulum großen Wert auf Sicherheit legt, kann ich auch entscheiden, wer diese Daten auf seinem Node sehen darf und wer nicht.
Es war sehr viel (wirklich sehr viel) Versuch und Irrtum, ich hatte ja immerhin vorher noch nie mit Python gearbeitet, aber schlussendlich hat es sich gelohnt - das Plugin funktioniert (nicht zuletzt wegen einer Rohvorlage von Mark).
Damit habe ich es innerhalb eines Tages geschafft, die Hardware einzurichten und das Plugin „hinzubasteln“.
Morgen weder ich dann noch den Außensensor über zwei “I²C zu LAN Adapter” an den Raspberry anschließen, und dann war es das auch - erst einmal
Es ist ja alles nicht so einfach, aber mit ein wenig Geduld - Teil 2
Ich habe mittlerweile den BME280 an den Raspberry angeschlossen, und kann, nachdem ich die erforderlichen Bibliotheken installiert habe, ein (bereits vorhandenes) Skript aufrufen, dass die Daten ausliest.
Jetzt muss ich nur noch diese Daten bei Aufruf des Skripts in eines der Beispiel-Telemetrie-Plugins schreiben lassen, und dann wäre es fertig.
Mal sehen, ob ich das vielleicht (!) auch noch hinbekomme, denn ich kann gar kein Python ¯\_(ツ)_/¯
Has anyone investigated the possibility of building a LoRa-like low-power transceiver for 49.82-49.90 MHz band for use as an #RNode? This might have greater range in rural, tree-covered areas that limit 800/900 MHz signal propagation.
The 49.82 MHz to 49.90 MHz band allows for personal hobby transmitters up to 100mw output with any modulation as long as the modulation stays within the 49.82-49.9 MHz band. This provision within Part 15 opens up opportunities for 49 MHz beacons, provided an effective antenna is used.
§ 15.235 Operation within the band 49.82–49.90 MHz. (a) The field strength of any emission within this band shall not exceed 10,000 microvolts/meter at 3 meters. The emission limit in this paragraph is based on measurement instrumentation employing an average detector. The provisions in §15.35 for limiting peak emissions apply. (b) The field strength of any emissions appearing between the band edges and up to 10 kHz above and below the band edges shall be attenuated at least 26 dB below the level of the unmodulated carrier or to the general limits in §15.209, whichever permits the higher emission levels. The field strength of any emissions removed by more than 10 kHz from the band edges shall not exceed the general radiated emission limits in §15.209. All signals exceeding 20 microvolts/meter at 3 meters shall be reported in the application for certification. (c) For a home-built intentional radiator, as defined in §15.23(a), operating within the band 49.82–49.90 MHz, the following standards may be employed: (1) The RF carrier and modulation products shall be maintained within the band 49.82–49.90 MHz. (2) The total input power to the device measured at the battery or the power line terminals shall not exceed 100 milliwatts under any condition of modulation. (3) The antenna shall be a single element, one meter or less in length, permanently mounted on the enclosure containing the device. (4) Emissions outside of this band shall be attenuated at least 20 dB below the level of the unmodulated carrier. (5) The regulations contained in §15.23 of this part apply to intentional radiators constructed under the provisions of this paragraph. (d) Cordless telephones are not permitted to operate under the provisions of this section.
Got this new LilyGo T-Echo device yesterday with #meshtastic firmware. Promptly reflashed it with #reticulum#RNode firmware 1.81. I paired this RNode with my phone running #Sideband. I finally stumbled across the "Popular RNode Settings" page in Mark's wiki on github. Now I have my RNodes operating on 914.875 MHz with a spreading factor of 8 so they'll be more likely to #mesh with other people's RNodes in the 900 MHz #ISM band. Looking forward to #wardriving some of the areas I frequent with this new RNode.
I converted my third #meshtastic node to an #RNode today so I can use it as a future portable/mobile node. My #Linux#hamradio shack PC has both an RNode and high-speed TCP connectivity and is acting as a dedicated bridge between my RNode-based reticulum network and the public internet TCP-based #reticulum network. I tweaked the mode settings on the different interfaces in the ./reticulum/config files to use the #gateway and #boundary modes were appropriate. You can see the modes on the status page at https://reticulum.n7ekb.net.
For #nomadnet I setup a second node so that my rnode-based network has it's own node on the #hamradio shack PC. Look for "N7EKB's RNode Network Node" and "N7EKB's TCP Network Node" in the announce stream on the #Nomad Network.
The screenshot is of Liam Cottle's #MeshChat program running on my #Fedora#Linux laptop connected to the TCP Server interface of my #hamradio shack PC. MeshChat is an AWESOME program Liam!
HRCC talks about deregulating encryption.
für Reticulum / Sideband
