sciencemastodon.com is one of the many independent Mastodon servers you can use to participate in the fediverse.
A mastodon instance designed primarily for science journalists and scientists. Those who wish to join: to avoid significant delays in accepting your application please let us know your real name, your affiliation, and your area of expertise. Thank you!

Administered by:

Server stats:

165
active users

#reticulum

9 posts6 participants0 posts today

To receive by #radio #reticulum #rnode #announces on #lora radio one needs to have the same 4 radio parameters as the announce: #frequency #bandwidth #spreadingfactor SF #codingrate CR
-> #meshchat permits any number of #rnode interfaces !
To hear the most announces, does it make sense & is it possible to set up several e.g. 5 #lora #radios with same frequency: 869.525 MHz
bandwidth: 250 kHz but
each with different SF & CR? Would one be able to receive more announces that way? Would it work?

Are there any projects to run a single radio to serve as a repeater/router for both #meshtastic and #meshcore ? (Courtesy tag to #reticulum )

Cool to see healthy competition between projects and all but it's a shame to have to run two radios to support both projects.

Alternatively, meshtastic is a more mature project so it might be better for them to add a routing layer.

The upcoming 0.9.4 release of Reticulum will include a series of significant improvements to system resource utilization. Work has been focused on the core I/O handling and internal in-memory data structures. This has resulted in substantial reductions in both memory consumption, thread counts and CPU utilization, especially noticeable on nodes with many interfaces or connected clients.

Lighter Memory Footprint
The in-memory table structures have been optimized significantly, and disk caching added for data that doesn't need to stay loaded in resident memory. Memory cleanup, path table management and table entry purging has also been overhauled and optimized.

The net result is a reduction in resident memory load of approximately 66%. As an example, one testnet node with 270 interfaces and around 800 concurrently active links incurred a memory load of 710 MB on rnsd version 0.9.3.



With the new optimizations in 0.9.4, memory load stabilizes at a much lighter 230 MB under similar conditions.



These improvements are of course going to be most noticeable on well-connected transport nodes, but even for small or singular application-launched instances, the improvements are important, and contribute to the goal of running even complex RNS applications on very limited hardware.

Faster I/O Backend
A new backend for handling interface I/O, and shipping packets off to the RNS transport core, has also been added in this upcoming release. It uses kernel-event based I/O polling, instead of threads for reading and writing the underlying hardware (or virtual) devices. This approach is much faster, and of course decreases processing time wasted in multi-threading context switches significantly.

On RNS 0.9.3, the example node from before utilized around 275 threads, but on version 0.9.4, everything is handled by a mere 6 threads, grand total. That includes all the threads of RNS, like those needed for running memory maintenance, managing storage and caching, and other backend handling.



Additionally, the new I/O backend uses abstract domain sockets for communication between different RNS applications on the same system, offering a slight, but still welcome performance improvement. More importantly, though, using domain sockets for intra-RNS instance communications makes it much easier to handle several different RNS instances running on the same system, as these can now simply be given human-readable namespaces, making config file management and complex setups a lot more manageable.

To run several isolated RNS instances on the same system, simply set the instance_name parameter in your RNS config files. You can verify that your instance is indeed running under the correct namespace (here the default system namespace) by using the rnstatus command, which should give you output such as the following:

Shared Instance[rns/system]
  Status    : Up
  Serving   : 3 programs
  Rate      : 1.00 Gbps
  Traffic   : ↑8.61 GB   798.45 Kbps
              ↓11.51 GB  859.64 Kbps

In this initial release, the new I/O backend is available on Linux and Android. The plan is to extend it to Windows and macOS in future releases, but since these operating systems have different ways of interacting with kernel event queues, it makes sense to stage the deployment a bit, and make sure that everything is working correctly before adding support for these as well.

Lower CPU Load
The improvements to memory structure, increased I/O efficiency and decreased thread counts all contribute to lowering the CPU load required to run Reticulum. Especially the much decreased need for context switching makes a positive difference here, and this is very noticeable on systems that handle very large numbers of interfaces or connected clients.

The testnet node referred to in this post is a small single-core VM, that handles between 250 to 320 interfaces, and between 700 to 1,000 active links at any given time. Even on such a small machine, CPU usage rarely spikes above 15%, and long-time load average is essentially always at 0.01.

While there is still many more options to work on, for even better performance and lower resource utilization, this work is a big step forwards in terms of immediately useful scalability, and the ability to deploy even large and complex Reticulum-based systems and applications on very modest hardware, such as low-power SBCs and embedded devices.

#reticulum #performance #networking #meshnetworks

So, seems like most UK people are going for 867.5MHz, 125kHz, spreading factor 9, coding rate 5. That frequency by my reading has a 25mW EIRP limit in the UK. I've set up my RNode on that with a high gain omni that should cover most of West Oxfordshire. Anyone want to see if they can spot it? #reticulum

I'm also going to set up a Tor service to reach this node. Currently I've just got it pointed at testnet but feels like having at least country-level "central" nodes is sensible.

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.

Hier der neue Link zu diesem Matrix-Space:

🔗 matrix.to/#/#mesh-netzwerke-de

Sorry für das Durcheinander!

At the risk of igniting some controversy, but hopefully stimulating debate, I’d like to ponder the question: #Meshtastic and #LoRa mesh networks in general, #MeshCore, #Reticulum etc. … Are they “Amateur Radio”? #HamRadio - I know the technical UK answer “No, unless on 433MHz with the “Licensed Operator” setting on, with amateur license; no encryption, so no Reticulum allowed”. I’ll leave the question a bit open like that without further qualifications. Please boost for visibility! 73 Matt

Wouldn't it be nice if you could have a real telephone, that wasn't wiretapped by default?

Encrypted, decentralized and truly peer-to-peer voice calls and telephony over Reticulum is now a reality with the newly released LXST framework. Because it uses Reticulum for data transport, LXST voice calls require no intermediary servers or accounts anywhere. Anyone with an LXST-enabled device or software client can call anyone else - as long as there is a network connection between the devices.

Using the efficient hybrid mesh routing of Reticulum, this also means that your calls aren't routed anywhere they shouldn't be. If you call an endpoint in the same building, the telephones connect directly, and not over somebody elses VoIP server in another country.



These two prototypes are fully functional telephones, that can dial to and receive calls from any other LXST endpoint. It takes about 20 minutes to assemble one, and it's built from completely standard and readily available components, obtainable from common electronics vendors.

Initial client support is already implement in the Sideband application for desktop, the command line application rnphone, and of course the physical telephone implementation.

Like other Reticulum-based protocols, authentication and encryption is handled by the self-sovereign identity layer in Reticulum. This means that you truly own your addresses, and that you can move around to anywhere in the network (or another network altogether) and still be reachable for anyone else. If you have an LXST "number", nobody can take it away from you, and there is no phone service provider to pay for the privilege of keeping it.

The system provides high-quality, real-time full-duplex voice calls between endpoints, and uses only open source software components. This includes the voice codecs, which can real-time switch between OPUS (for high quality) and Codec2 (for ultra low bandwidth) without any frame loss.

But LXST was not only designed for telephony and voice calls. In fact, it is a general purpose secure signal transport framework, that allows sending any type of analogue or digital signal over Reticulum networks, either efficiently encoded or completely uncompressed. The protocol currently supports transporting up to 32 simultaneous signal carriers with up to 128-bit floating point precision in a single stream.

It also supports transmitting digital signalling and control data in-band with the carried signal frames. This allows creating almost any kind of real-time application.

At this early stage of development, the framework includes ready-to-use primitives for telephony, signal input, output and mixing, and network transport. Future development will focus on even more primitives such as:

- Real-time distributed radio communications
- Decentralized 2-way radio systems, similar to (but more flexible than) trunked systems such as DMR and P.25
- Media broadcasting for information content such as podcasts and digital broadcast radio that anyone can set up and use
- And many more useful and interesting applications

If you want to dive deeper into this, there is more information available on the LXST source repository and in discussion threads. It's still very early days for LXST, but if you're interested in this kind of thing, it might be a good time to jump in.

#reticulum #lxst #sideband #privacy #security #voip #opensource

A #rnode build for #reticulum using a #raspberrypi5 and #geekwormx1206 #ups for a #carnode or #solarnode
loramesh.org/subpages/upsrnode
Running #meshchat , four #liion #21700 5000 mAh batteries seem to run the #rak4631 and Pi for at least 24 hours. The device can be re-charged using #usbc or 9 to 18 V DC at up to 3 A via a jack or other connector. The rnode shuts down cleanly when batteries run out & re-starts when power is back, whereupon the batteries charge at the same time in #passthroughcharging

Replied in thread

@mrkaran Great insights & a pleasure to read. I have used #nixos as my main machine for a few years & its main advantage is that it won't let me mess it up because I do not install anything other than via the configuration.nix. Your post has given me a view on how to use it properly.
My big question: how can one #package something to get it into the nixOS search.nixos.org/packages
? I am happy to do the work but no micro step by step guide seems available. I am thinking of #reticulum #meshchat

search.nixos.orgNixOS Search

Meshtastic - MeshCore - Reticulum: Warum Sideband (Reticulum) zurzeit meine №1 ist

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