Sensor Data Over Reticulum: LXMF, Propagation Nodes, and the Low-Power Case
LPWAN Meshes: Reticulum, Where I Landed covered Reticulum as a communications stack: transport-agnostic, cryptographically addressed, built for chat and file transfer over LoRa, packet radio, or whatever medium is available. This post is narrower on purpose: it breaks down the specific mechanics of moving a sensor reading, not a conversation, through Reticulum: which delivery method to pick, what a reading actually costs in packets and bits per second, and what already exists in the open-source community to build on rather than reinvent.
Sensor Data Is a Different Traffic Pattern Than Chat
A chat message is sent once, by a human, who generally wants to know it arrived. A sensor reading is sent on a timer, by a device that will send another one in 10 minutes regardless of whether the last one was ever picked up. It is small (a temperature and a battery voltage is a handful of bytes), frequent relative to a human’s typing speed, and tolerant of delay in a way a conversation is not. Nobody minds if a soil moisture reading from three o’clock arrives at half past three instead.
Reticulum was not built around this pattern specifically, it was built as a general-purpose networking stack, and the earlier deep dive already covers its addressing scheme (every Destination is a cryptographic identity, derived from a public key, with no separate address book) and its transport-agnostic interface layer. What follows assumes that background and builds on top of it: LXMF, the Lightweight Extensible Message Format, is the layer Reticulum applications actually use to move data between destinations, and it turns out to fit sensor telemetry closely, once you know which of its delivery methods to reach for.
LXMF’s Three Delivery Methods, and Which One a Sensor Should Use
LXMF supports three distinct ways to get a message from one destination to another, and the choice matters for a battery-powered sensor node in a way it doesn’t for a phone.
Link-based delivery is the default. The sender first establishes an encrypted Reticulum Link to the destination (a three-stage handshake: link request, link proof, verification) and then sends the message over that link, encrypted with an ephemeral AES-128 key derived via ECDH on Curve25519. This is the right choice when a node has several things to say at once, a burst of readings, a firmware log, because the link’s setup cost gets paid once and amortised across every message sent while it stays open.
Opportunistic delivery skips the link entirely. The message is embedded directly in a single Reticulum packet and sent. There is no handshake, no link table entry, no keepalive to maintain, just one packet, addressed and gone. For the common sensor case, one small reading, sent on a timer, with no follow-up message expected for another 10 minutes, this is almost always the better fit. Setting up and tearing down a link for every isolated reading is paying handshake overhead you don’t need. Because a compact sensor payload fits comfortably within the standard 255-byte single-frame limit of LoRa modulation, opportunistic delivery avoids multi-packet radio fragmentation altogether.
Group delivery encrypts the message with a symmetric key shared by everyone in a Reticulum GROUP destination, useful when the same reading needs to reach several listeners at once (a shed sensor reporting to both a local dashboard and a phone), but it is the least relevant of the three for a single sensor talking to a single collector.
The concrete numbers make the opportunistic-for-telemetry case plainly:
- A Reticulum Link costs three packets, 297 bytes total, to establish.
- Keeping a link open afterward costs roughly 0.44 bits per second, negligible on its own, but only worth paying if you’re actually going to use the link for more than one message.
- For a genuinely one-way reading, using a Single destination directly with Reticulum’s low-level Packet API, bypassing LXMF’s link machinery altogether, avoids the 297-byte setup cost entirely. A Plain destination (Reticulum’s unencrypted type) is not an option here regardless, since plain destinations are only reachable directly and never routed over multiple hops, which rules them out for anything but a sensor sitting one hop from its collector.
What Actually Carries the Reading
An LXMF message’s payload is msgpack-encoded and carries four things: a timestamp, optional content, an optional title, and an optional Fields dictionary. That last field is the part that matters here. Fields is an open, arbitrary key/value structure, and it is exactly the mechanism Sideband (the reference LXMF client, covered below) uses to carry structured telemetry: a sensor reading rides inside what is, at the protocol level, an ordinary LXMF message, with the temperature, humidity, or battery voltage sitting in Fields rather than in the human-readable content string.
The minimal pattern for sending any LXMF message, direct from the upstream LXMF library, is this:
import LXMF
lxm_router = LXMF.LXMRouter()
message = LXMF.LXMessage(destination, source, "This is a short, simple message.")
lxm_router.handle_outbound(message)A sensor reading extends the same call by populating fields instead of, or alongside, the content string:
message = LXMF.LXMessage(
destination,
source,
content="",
fields={"temperature_c": 21.4, "battery_v": 3.71},
)
lxm_router.handle_outbound(message)There is no separate sensor-telemetry protocol to learn here. It’s the same LXMessage object every chat client uses, with the payload shaped differently.
Propagation Nodes: Store-and-Forward for a Sleeping Device
The other Reticulum mechanism worth understanding for telemetry specifically is the Propagation Node. When Propagation Nodes exist on a network, they peer with each other by default and synchronise messages, building an encrypted, distributed message store that any endpoint can retrieve from when it comes back online. Messages stay encrypted throughout, readable only by the intended recipient.
This is a direct fit for a duty-cycled sensor. A node that wakes, takes a reading, sends it opportunistically, and goes straight back to sleep doesn’t need its collector to be listening at that exact moment, the same store-and-forward resilience that lets email survive an offline mailbox, running without a company operating the mail server. Whether a given deployment actually needs a Propagation Node depends on whether the collector is reliably reachable directly: on a small property with one gateway node, probably not; across a mesh where the collector might be several unpredictable hops away and offline at odd times, a Propagation Node removes that timing dependency entirely.
Reticulum’s Announce mechanism, which is how destinations become discoverable on the network in the first place, is deliberately bandwidth-capped: by default, no more than 2% of available channel capacity goes to processing announces, and any individual announce stops being retransmitted after 128 hops. A network of quiet, infrequently-announcing sensor nodes stays well inside that budget without any special tuning.
Where This Actually Gets Used
The temperature-and-battery-voltage example above is deliberately generic. It’s worth grounding it in something more concrete: a remote conservation and tourism property, the kind that runs multi-day 4WD trips and dark-sky astronomy sessions across a station-sized block with patchy to nonexistent mobile coverage for most of it. None of what follows requires anything beyond the mechanisms already covered, it’s the same opportunistic delivery and the same Propagation Nodes, aimed at problems that have nothing to do with chat.
Vehicle check-ins, for staff and guests alike. A tour vehicle running station tracks for most of a day is, for most of that day, out of mobile range entirely. A small Reticulum node in the vehicle, an RNode paired with a phone, or a dedicated low-power board, can announce a position and a short status field on a timer: fields={"lat": -34.02, "lon": 140.71, "status": "ok", "fuel_pct": 58}, sent opportunistically, no link, no acknowledgement expected. A Propagation Node back at the homestead, mains-powered and always on, collects whatever check-ins it hears as vehicles move in and out of range across the day, so staff build a running picture of who’s where without needing a live connection to every vehicle at once. This is not a replacement for a satellite phone or a personal locator beacon (PLB), those remain the actual emergency escalation path, and no mesh network should be trusted as the sole safety system in genuinely remote terrain. What it replaces is the alternative of no positional information at all between scheduled radio check-ins, the gap where a vehicle running late is just a vehicle running late until someone gets worried enough to go looking.
Site conditions before anyone drives out. A dark-sky astronomy program run from a remote lodge faces a recurring, practical decision: load guests into a vehicle and drive out to the observation site tonight, or hold off because cloud is building. A basic weather sensor node at the observation site, temperature, humidity, a simple visibility proxy, reporting back to the lodge every few minutes over opportunistic LXMF answers that question from the office before anyone leaves. It’s the same pattern as a soil moisture sensor deciding whether to run irrigation, just deciding whether to run a tour instead.
Water and yards, not just vehicles. The same property is almost certainly also a working pastoral block underneath the tourism, bores, troughs, and gates spread across an area too large to check by driving past each one daily. A trough-level float switch or a gate sensor is exactly the low-duty-cycle, delay-tolerant reading this whole piece has been describing, and the same Propagation Node covering vehicle check-ins can just as easily hold water-infrastructure readings until someone’s in range to collect them.
Interpretive content without a signal. The same mechanism works in reverse for guests rather than staff. A fixed Reticulum destination at a trailhead, a waterhole, or a site of cultural significance can hold structured content, a story, an ecological note, a citation, that a guide’s or a guest’s phone running Sideband queries locally when in range, with no internet connection anywhere in the chain. It’s a short step from a sensor answering a query about temperature to a destination answering a query about what happened at this particular spot, the same request-and-respond shape, aimed at interpretation instead of telemetry.
What Already Exists, Rather Than What You’d Have to Build
None of the above requires custom infrastructure. The Reticulum community already has working tools that do most of this out of the box:
- Sideband is the reference LXMF client for Android, Linux, and macOS, and it ships with a distributed telemetry system: over 20 built-in sensor types, a plugin system for adding custom ones, and remote telemetry querying with the same cryptographic authentication Reticulum uses for everything else. For anyone wanting to get a reading moving across a Reticulum network today without writing protocol code, Sideband’s telemetry plugins are the fastest path there.
- RTNode-HeltecV4 is standalone Reticulum Transport Node firmware for the Heltec V4 board, worth knowing about as an example of dedicated, always-on infrastructure hardware, the kind of thing you’d run as a fixed relay or Propagation Node host, rather than a phone running Sideband in someone’s pocket.
- openCom-Companion is an LXMF client built around the OpenCom family of open-hardware RNode-class radios, useful if the goal is a purpose-built device rather than a repurposed phone or development board.
- awesome-reticulum is a curated, actively updated catalogue of the wider project community, worth bookmarking rather than trying to track independently.
Where This Leaves You
Reticulum doesn’t give you a sensor-telemetry protocol out of the box, it gives you the primitives (Destinations, Links, LXMF’s delivery methods, the Fields dict, Propagation Nodes) and leaves the specific shape of a telemetry deployment up to you. That is a genuine trade-off against something more opinionated. Part two of this series looks at MeshCore, which takes a different approach: a purpose-built sensor node role, a standard payload encoding, and a pull-based query model designed around telemetry specifically, rather than general-purpose messaging repurposed for it.
Neither approach is trying to displace LoRaWAN where centralised, carrier-grade infrastructure makes sense. What is described above is protocol mechanics and pilot testing for scenarios where connectivity assumptions fail; part three examines the distinct operational strengths of mesh architectures versus LoRaWAN’s centralised model.
Part one of three. Next: . Related reading: LPWAN Meshes: Reticulum, Where I Landed for Reticulum’s full architecture, and LPWAN Meshes: MeshCore, Moving Beyond the Ad-Hoc for MeshCore’s.
Sources
- Reticulum Network Stack, What is Reticulum? and Understanding Reticulum. Link handshake cost, Destination types, Announce bandwidth caps, low-bandwidth design targets.
- markqvist, LXMF. Delivery methods, message structure, Propagation Node behaviour, the upstream code example.
- markqvist, Sideband. Distributed telemetry system, built-in sensor types, plugin architecture.
- jrl290, RTNode-HeltecV4. Standalone Transport Node firmware.
- liberatedsystems, openCom-Companion. LXMF client for OpenCom open-hardware radios.
- lorien, awesome-reticulum. Curated project list.
Webmentions
❤️ Liked by 1 person
Want to comment? Reply to this post from your Mastodon/Fediverse account, or mention this post's URL in your reply. Your comment will appear here automatically!
Have your own blog? Send a webmention
to https://webmention.io/gaggl.com/webmention