LPWAN Meshes: ClusterDuck Protocol - Purpose-Built for Emergencies
The ClusterDuck Protocol (CDP) was where my mesh networking journey truly began. The story behind Project OWL (Organisation, Whereabouts, and Logistics)—students building emergency communication networks after Hurricane Maria—resonated deeply, highlighting a technology designed not for hobbyists or industry, but for saving lives when infrastructure fails. While I found its concepts “much better thought through” from the outset, the project’s slow pace and patchy hardware support meant my personal involvement never truly moved beyond some initial tinkering.
While I’ve since moved to more robust platforms for my general needs, CDP remains highly relevant for its intended purpose. In this post, I’ll explore what makes CDP unique, where it excels, and why I ultimately chose different tools for my own deployments while still respecting what CDP does well.

What is ClusterDuck Protocol?
CDP is an open-source, decentralised mesh networking protocol specifically designed for emergency communications and disaster response. It was created by Project OWL to provide resilient communication when traditional infrastructure—cell towers, internet, power grid—fails or is unavailable.
The protocol uses LoRa radio on ESP32 hardware to create rapidly deployable mesh networks. But unlike general-purpose mesh platforms, CDP is optimised for specific scenarios: hurricanes, floods, earthquakes, wildfires, and other disasters where communication infrastructure is compromised.
The architecture consists of three node types:
- DuckLinks - Simple, battery-powered nodes that form the mesh
- MamaDucks - Gateway nodes with additional capabilities (GPS, data storage)
- PapaDucks - Internet-connected nodes that bridge to external networks
This hierarchical design reflects CDP’s mission: get information from affected areas to response coordinators as quickly as possible.

Design Philosophy
CDP’s design reflects lessons learned from real disaster scenarios:
Rapid Deployment
Nodes should be deployable in minutes by anyone—no technical expertise required. Throw them out of a helicopter, hand them to community members, mount them on drones. They need to work immediately.
Battery Operation
When the power grid fails, nodes run on batteries. CDP optimises for this reality with aggressive power management and low duty cycles.
Minimal Infrastructure
No pre-existing network required. Nodes form a mesh autonomously, finding each other and establishing routes without configuration.
Information Flow
The protocol prioritises getting information from the field to decision-makers. Location data, status updates, and critical messages flow toward gateway nodes and then to emergency response systems.
Resilience
Individual node failures shouldn’t bring down the network. People can move around with nodes, nodes can fail, and the mesh should adapt and continue functioning.
These principles create a system optimised for chaos—exactly what’s needed in disaster scenarios.
Hardware and Implementation
CDP typically uses ESP32 boards with LoRa transceivers—similar hardware to MeshTastic, often literally the same boards. A T-Beam or Heltec LoRa 32 can run CDP firmware.
However, Project OWL also provides purpose-built hardware:
ClusterDuck Kits
Pre-assembled nodes designed for disaster deployment. Ruggedised, waterproof, with integrated antennas and batteries. Drop one from a drone and it starts working.
DuckLink Devices
Minimalist nodes for field deployment. Just enough hardware to forward messages, optimised for cost and power efficiency.
Gateway Hardware
More capable devices with GPS, larger batteries, solar charging, and cellular/satellite backhaul for connecting to external networks.
The hardware ecosystem is less diverse than MeshTastic’s but more purpose-specific. These aren’t hobbyist toys—they’re tools designed for field deployment in harsh conditions.
Software and User Experience
The CDP firmware and tools reflect the protocol’s emergency focus:
Simple Configuration
Nodes need minimal setup. Flash firmware, optionally set a node ID, and deploy. The mesh self-organises.
Web Portal
MamaDuck and PapaDuck nodes host a web interface accessible via WiFi. First responders can see network status, message logs, and node locations without special software.
Message Handling
The protocol includes store-and-forward messaging. Messages propagate through the mesh toward gateway nodes, even if the entire path isn’t available when first sent.
Data Aggregation
Gateway nodes collect and aggregate data from the mesh—locations of deployed nodes, status updates, messages from the field—and forward it to emergency response systems.
The user experience prioritises simplicity for people who aren’t mesh networking experts but need to get information during a crisis.
Real-World Deployments
CDP has been deployed in numerous disaster scenarios:
Hurricane Response
After hurricanes in Puerto Rico and the US Gulf Coast, CDP networks provided communication in areas where cell towers failed.
Wildfire Evacuations
Networks deployed during California wildfires enabled communication for evacuation coordination and status updates.
Earthquake Recovery
Following earthquakes, CDP networks helped locate survivors and coordinate relief efforts.
Community Preparedness
Various communities have deployed CDP networks proactively, maintaining them for use when needed.
These deployments validate the protocol’s core mission: providing communication when nothing else works.
Strengths
Based on my experience and observation of real deployments, CDP excels at:
Emergency Readiness
The protocol is optimised for the chaos of disasters. Nodes work with minimal setup, mesh formation is automatic, and the system degrades gracefully when things go wrong.
Deployment Speed
You can have a functioning network in minutes. Hand out nodes, power them on, done. For emergency scenarios, this speed matters enormously.
Simplicity
Users don’t need to understand mesh routing, radio parameters, or networking concepts. The system just works, or fails in obvious ways.
Purpose-Built Hardware
The ruggedised, purpose-built hardware survives conditions that would destroy hobby electronics. Waterproof, impact-resistant, designed for harsh environments.
Community Focus
The protocol explicitly supports community deployment and coordination. It’s not just about individual communication but about collective response.
Why I Moved On
Despite CDP’s conceptual strengths, which I found “much better thought through” than other early options, it ultimately wasn’t the right fit for my ongoing needs, largely due to its slow development and patchy hardware support that limited my personal progress beyond tinkering:
Limited General-Purpose Use
CDP is optimised for emergencies. For day-to-day communication, property monitoring, or general mesh networking, it’s over-specified in some ways and under-specified in others.
Security Model
The focus on rapid deployment and broad accessibility means security isn’t as robust as I wanted for permanent deployments. There’s encryption, but it’s not the cryptographic foundation you find in Reticulum.
Customisation Constraints
The protocol is designed for a specific use case. Bending it to other purposes means fighting its design rather than working with it.
Application Ecosystem
The software ecosystem is focused on emergency response. For building custom applications, sensor networks, or general data exchange, other platforms provide better tools.
Network Persistence
CDP networks are designed to be deployed when needed, used during an emergency, and then potentially dismantled. For permanent installations with different requirements, other protocols are better suited.
Where CDP Truly Shines
CDP isn’t trying to be all things to all people, and that’s a strength. It excels specifically for:
First Responders
Fire services, emergency medical, search and rescue—teams that need reliable communication in disaster zones.
Disaster Preparedness
Communities in disaster-prone areas can pre-position CDP nodes and infrastructure, ready to activate when needed.
Humanitarian Response
NGOs and relief organisations working in areas with limited or compromised infrastructure.
Temporary Events
Large outdoor events in areas without adequate cell coverage—music festivals, sporting events, expeditions.
Training and Drills
Emergency response training benefits from realistic communication scenarios. CDP provides that without requiring actual disasters.
If your need matches these scenarios, CDP is likely your best option. It’s been proven in real emergencies, refined through actual deployments, and continues to evolve based on field experience.
Comparison to Other Platforms
Having used multiple mesh technologies, here’s how CDP compares:
vs. MeshTastic
MeshTastic is more general-purpose, has broader hardware support, and a larger community. CDP is more focused, with purpose-built tools for emergency scenarios. For disasters, CDP wins. For general use, MeshTastic wins.
vs. MeshCore
MeshCore offers more flexibility and better scalability for permanent, complex deployments. CDP offers better simplicity and faster deployment for temporary emergency networks.
vs. Reticulum
Reticulum provides much stronger security and privacy, transport independence, and flexibility. CDP provides simpler deployment and purpose-built emergency tools.
Each platform reflects different design priorities. CDP chose emergency readiness over flexibility, deployment speed over customisation, simplicity over power-user features.
Getting Started with CDP
If CDP sounds right for your needs:
- Review Project OWL documentation - https://www.project-owl.com/
- Start with existing hardware - T-Beam or similar ESP32+LoRa boards
- Flash CDP firmware - Available on GitHub
- Test deployment - Start with a few nodes to understand behaviour
- Plan for your scenario - How will nodes be deployed? Where are gateways? How does data reach coordinators?
For organisations, Project OWL offers training, consulting, and purpose-built hardware. For individuals and communities, the open-source firmware and off-the-shelf hardware provide an accessible starting point.
CDP’s Future
The protocol continues evolving based on real-world deployments. Recent additions include:
- Satellite integration - Connecting remote meshes via Starlink or Iridium
- Sensor integration - Environmental monitoring during disasters
- Improved power management - Extending battery life for longer deployments
- Enhanced routing - Better handling of mobile nodes and changing topology
Project OWL remains committed to the emergency communications mission, refining CDP based on lessons from each deployment.
My Verdict
CDP represents purpose-driven design at its best. Rather than trying to be everything, it focuses on a critical need—emergency communication—and does it well.
While my journey led me to more robust and feature-rich platforms for general mesh networking, I still acknowledge CDP’s unique value. Though my personal involvement never moved beyond tinkering due to its earlier development pace and hardware limitations, I maintain an awareness of CDP and its potential. If disaster strikes and traditional communications fail, the core principles of CDP make it a relevant consideration for rapid, emergency communication response.
For anyone involved in emergency preparedness, disaster response, or community resilience planning, CDP deserves serious consideration. It’s been proven in real scenarios, backed by a committed community, and continues improving based on field experience.
The fact that I chose different tools for my day-to-day needs doesn’t diminish CDP’s value. It just reflects that different tools suit different jobs. CDP knows its job and does it well.
Next week, I’ll conclude this series with a detailed comparison across all four platforms, including a ranking matrix based on five key parameters: Range & Coverage, Security, Ease of Use, Scalability, and Resilience. This should help you cut through the details and make an informed decision for your specific needs, keeping in mind the lessons learned from both the initial promise and the practical limitations of each technology.
Comments
Be the first to comment! Reply to this post from your Mastodon/Fediverse or Bluesky account, or mention this post's URL in your reply. Your comment will appear here automatically via webmention.
Follow this blog on Mastodon at @gaggl.com@web.brid.gy or on Bluesky at @gaggl.com