When the Grid Goes Down, Your Crew Needs to Stay Found

There’s a gap in most off-grid communication plans that nobody talks about.

People spend considerable time and money on radios, repeaters, antenna setups, and go-bags. They test their gear on clear days with good line of sight. Everything works. They feel prepared.

Live / Near-Live Off-Grid Mesh Tracking

Then they think about the actual scenario they’re preparing for — and if they think hard enough, they arrive at a problem that most of their gear doesn’t solve.

It’s not “can my devices talk to each other.” It’s something more specific: what happens to my operational picture when a device goes offline?

A team member’s battery dies. Someone powers down to conserve. A runner goes quiet for reasons you don’t know yet. In every one of those cases, most mesh systems give you the same answer: that device disappears. No last position. No last heading. No indication of where they were when contact was lost. Just an absence where a person used to be.

That gap is what this experiment was designed to expose — and to show what it looks like when a system actually solves it.

The Experiment

The setup was straightforward. A small package — a waterproof container with a LoRa communicator inside and a few other items for good measure — would be driven approximately eight miles out to a remote wooded location. Once there, it would be hidden, the communicator inside would be powered off, and I would drive home.

The question the experiment was designed to answer: after the communicator powering off, would other devices in the cluster still know where it was?

A set of mesh communicators

A secondary question, arguably more interesting: if a device that had been powered off for the entire operation powered on at home, would it immediately know where the package was — even though it had been offline the whole time?

No cell service at the drop location. No internet connection involved at any point. Just LoRa radio and mesh firmware doing its job.

What Most Mesh Systems Do

Before getting into what happened, it’s worth understanding the standard model.

Most LoRa mesh systems — including well-regarded open-source options with large communities — operate on what you might call a presence model. Devices announce themselves when they’re active. Other devices hear those announcements and update their map. When a device stops transmitting, the network stops knowing about it.

This is fine for a lot of use cases. If you’re building a neighborhood mesh network for casual communication, real-time presence is probably all you need. You’re not running field operations. Nobody is going dark intentionally.

But for coordinated operations — supply runs, search and rescue staging, any scenario where people are moving independently and may lose power or go deliberately silent — the presence model has a meaningful failure mode. The moment someone goes dark, your coordinator loses them. Not just their live position. Their last known position. Everything.

Package dropped — team notified

The coordinator’s screen goes from “runner is at grid C4 heading northeast at 35mph with 40% battery” to nothing.

That’s the gap.

A Different Approach: Mesh Memory

The firmware I’ve been running — Blackout Comms, developed by Altware Development LLC — takes a different architectural approach that its developers call mesh memory.

The concept is that the cluster itself, not any individual device, holds the operational state. Every node in the cluster continuously retains and propagates the last known state of every other device: position, heading, speed, battery level, and RF connectivity data between all device pairs. That information doesn’t live on one device. It lives in the mesh — distributed across every active node, continuously updated, always available to any device that asks for it.

New device receives “mesh memory”

When a device goes offline, it doesn’t disappear from the cluster’s knowledge. It freezes. Its last known state — everything the cluster last saw from it — remains in the mesh, carried by every active node, available to anyone in the cluster who needs it.

And here’s the part that was most interesting to verify: that knowledge is delivered to devices that join the cluster later. Even devices that were powered off during the entire operation receive the full cluster state the moment they come online.

New device now knows where the package was dropped

The cluster, not the device, is the memory.

The Drop

The drive out was uneventful. Both communicators — the one on the dashboard and the one in the package — were visible as moving dots on the Blackout Comms Live app, which was screen-recording throughout. Eight miles of rural roads, no cell signal for the last several miles, both devices tracking cleanly the whole way.

Dropping off the hidden package — under watch of remote team

At the drop location I buried the package under leaves and debris in the treeline, deep enough that it was invisible from more than a few feet away. Before powering the communicator off, I sent a broadcast from the device:

“Package is down. Going dark.”

A few seconds later, that message appeared on the BC Live map back home — anchored to the exact geographic location of the drop. The network had received and logged it.

Then I powered off the communicator. Its dot froze on the map. Last known position: the treeline, eight miles out. Last known heading. Last known speed. Battery level at time of last contact. All of it still visible on the coordinator’s screen at home.

I drove back. During the drive, the screen recording showed my dot moving away from the frozen package dot — two dots separating, one heading home, one staying put in the woods.

[embed]Off-Grid Care Package Drop-off Demo

The Reveal

At home, I had a third communicator that had been powered off since before I left. It had no knowledge of anything that happened. It wasn’t part of the drive out, wasn’t online when the package was dropped, didn’t receive the broadcast.

I powered it on.

It booted normally. And within moments of joining the cluster, it displayed the last known position of the package communicator — eight miles out, in the treeline, at the exact coordinates where I’d buried it.

New device has the position of the drop

A device that was offline the whole time, that had never been near the drop location, that hadn’t received any direct transmission from the package communicator — immediately knew where it was.

This is what the mesh memory architecture delivers in practice. The cluster had been carrying that information the whole time. When the new device asked, the mesh answered.

The Recovery

The second drive out used the BC Live app as the only navigation. No cell GPS, no Google Maps, no downloaded offline maps. Just the cluster’s last known position of the package communicator, displayed on the app’s map, and dead reckoning to get there.

Using mesh memory to locate the package

Finding it wasn’t difficult. The coordinates were accurate enough to narrow the search to a small area. Once I was within range, the hidden package became findable with a few minutes of looking.

I retrieved the communicator from the package, sent a second broadcast:

“Package secure. En route home.”

Then I powered the communicator back on. Its dot came back to life on the map. For the drive home, both dots moved together — my device and the recovered package device, traveling the same road, visible simultaneously to any cluster member watching.

What This Tells Us About Off-Grid Coordination

The experiment isn’t really about buried packages. It’s about a class of operational problem that shows up in any coordinated off-grid scenario.

No cell or internet needed, just mesh memory

Supply runs. A runner goes dark — battery, deliberate power-down, or something you don’t know yet. Without mesh memory, your coordinator has nothing. With it, the coordinator has a frozen last known position, a heading, a speed, and a battery reading that tells them whether to wait or send someone.

Distributed staging. Equipment or supplies are cached at a remote location. The device left with the cache eventually powers down. Weeks later, a team member who was never near the cache needs to find it. Mesh memory means that team member’s device knows exactly where it is the moment it joins the cluster.

Multi-team operations. Team A and Team B are deployed separately. Team B has a device that went dark during the operation. Team A’s members, who were never near Team B’s device, still have its last known position — because the mesh carried that information to them through nodes they did encounter.

New arrivals. Someone joins an active operation mid-way. Their device boots and immediately receives the full operational picture — every active device’s current position, every offline device’s last known state, every broadcast sent during the operation. No briefing, no catch-up. Immediately operational.

In every one of these cases, the difference between a mesh that has memory and one that doesn’t is the difference between a coordinator who is informed and one who is guessing.

A Note on the Broader Landscape

Meshtastic, which most readers in mesh networking communities will be familiar with, is an excellent system for what it’s designed to do. The open-source community around it is active and technically sophisticated, the hardware support is broad, and for open community mesh networks it’s hard to beat.

What Meshtastic doesn’t implement — and to be fair, wasn’t specifically designed to implement — is persistent mesh memory. When a device goes offline in a Meshtastic network, its last known state isn’t retained and propagated. The presence model works for the use cases Meshtastic was built around.

The distinction matters for the class of coordinated operational use cases described above. It’s not that one system is better in some general sense. It’s that they’re designed for different things. If your use case involves devices that go dark and a coordinator who needs to remain informed despite that — mesh memory is the architectural requirement, and it’s worth understanding which systems implement it before you find yourself in the field without it.

Another distinction is that Blackout Comms employs unpredictable frequency hopping. Rather than sitting on a single frequency that can become saturated or suffer from interference, Blackout Comms constantly changes frequencies, unpredictably, to get around interference and jamming.

Building for This

If this kind of capability interests you, the practical path is straightforward. Blackout Comms runs on accessible hardware — Lilygo T-Deck, Lilygo Pager, Heltec v4, T-Beam Supreme, T-Beam 1W, and more— devices that are inexpensive and available at many online electronics suppliers. They don’t require specialist knowledge to acquire or assemble. A complete small cluster is achievable for a few hundred dollars.

Supported mesh devices

The Blackout Comms Live Android app, which handled the monitoring throughout this experiment, is free and open source. It connects to any BC communicator via Bluetooth and gives you the live cluster map, offline device positions, broadcast messages, and mesh graph.

Blackout Comms Live companion app

The Blackout Comms firmware itself requires a license for the root device — the device that creates and administers the cluster. Member devices don’t require individual licenses.

Full documentation is at chatters.io.

The Bigger Question

The gap I described at the beginning — what happens to your operational picture when a device goes offline — isn’t a hypothetical concern. It’s the failure mode that shows up in exactly the scenarios people are preparing for. Not the good days when everything is working and everyone is reachable. The days when batteries die, people go quiet, and a coordinator needs to make decisions without complete information.

Mesh memory doesn’t eliminate uncertainty. A last known position is not a live position. A frozen dot is not a person checking in. But it is something rather than nothing, and in a real coordinated scenario, that difference is significant.

The package was eight miles out, buried in the woods, powered off. Every device in the cluster knew where it was.

That’s the capability. Whether you need it is a question only your specific use case can answer.

The author develops Blackout Comms, an off-grid mesh communication system for private clusters. Documentation and hardware guides are available at chatters.io. The Blackout Comms Live companion app is free and open source.