Meshtastic

Ideas for future developments: a recap

A personal summary about ideas I’ve been gathering and discussing with other community members.

Reticulum
Despite still in alpha since 2018, Reticulum poses itself as a game changer in LoRa-based networks. Its approach resembles OTR (off the record messaging) featuring perfect forward secrecy, self-pairing and configuration, anti-tampering and easily allowing to switch from LoRa to BLE or WiFi as transmission medium.
A con is that it needs at least 1kbps, probably a bit less if properly configured. Super low-speed data transmissions would be left over.
Read more

Hardware
Basically readapting @Corvus board to Meshtastic needs. It will support solar charging, safe discharge, thermal management (thermistor or fully-fledged environmental sensor like the AHT11 or BME280 to monitor for possible leaks) and fuel gauge.
Other possible additions are:

  • a microSD card holder to store Reticulum cached handshakes
  • a GPS for (positional) anti-tampering and accurate clock sync
  • RTC (less power-hungry than GPS)
  • NFC support for fast pairing

Remote management
As headless nodes will generally be quite far from each other, a way to remotely monitor and manage their settings could be very handy, by either transferring the whole config file or just a single param (wifi:true, ble:false). Mavlink protocol can be source of inspiration.
Read more

State of charge dependant behaviour
Expanding @myself248 idea, Meshtastic nodes can have different behaviours according to the battery power. If over a certain threshold, they act as repeaters, otherwise turn into a quiescent mode waiting for user input. Obviously headless repeater nodes won’t have such feature.
Read more

BLE/WiFi escalation
If a cluster of nodes happens to be within a certain geographically-limited area, the inner nodes could switch to a faster communication medium such as BLE or WiFi.

2 Likes

btw - the qmesh author also had a good idea related to this:

Just wanted to add a few details regarding Reticulum. The requirement for 1kbps is not set in stone, a few hardcoded timing assumptions depend on it currently, but it was always my intention to dynamically allocate those timings before moving out of alpha anyways.

There’s a usability consideration to this as well though, since on very slow links, like 100bps, the initial key exchange (announce) and link setup would take a long time (probably around 45 seconds, if I remember correctly). It should be possible to do that on a faster channel though, and then switch the link to a slow interface afterwards.

Another note that might be of interest to you is that the current Reticulum implementation in Python will serve as a reference implementation for a version written in C or Go, so it will be possible to include as a library for microcontrollers and embedded devices.

2 Likes

+++

Heartbeat
Send a sync signal across the whole mesh network at a certain time to find out new nodes as well as map those ones that are still working.

PPT Voice Transmission
Use a special compression algorithm supporting low datarates to send audio over LoRa
Read More