ESP32 LoRa Mesh for Disaster Zones

ESP32 LoRa Mesh for Disaster Zones

ISEF Category: Embedded Systems

Ready to Turn This Idea Into a Real Project?

This guide was put together with the help of AI research tools to give you a solid starting point. But a competitive science fair project lives in the details: refining your research question, fine-tuning your variables, analyzing your data, and presenting your findings like a seasoned scientist.

For next steps tailored to your interests, skill level, and timeline, work one-on-one with a MehtA+ mentor. Learn more about MehtA+ Science & Engineering Research Mentorship →

Subcategory: Networking and Data Communications  ·  Difficulty: Advanced  ·  Setup: University Lab  ·  Time: Full Year

The Hook

After an earthquake, the first thing that often fails is communication. Cell towers can go down, power can vanish, and roads can block rescue teams. A small mesh network can keep messages moving even when the usual internet cannot. Your project can test whether a delay-tolerant design really helps.

What Is It?

A delay-tolerant mesh protocol is a set of rules that lets small devices pass messages from node to node, even when the network is broken or slow. Think of it like a relay team. If one runner cannot reach the finish line, the baton still moves through other runners until it gets there.

ESP32 boards are low-cost microcontrollers with built-in wireless features, and LoRa is a radio system that can send data far while using little power. That mix makes them a good fit for disaster zones, where devices may need to run on batteries and communicate over long distances. Your project asks whether a custom routing rule can keep messages moving better than a simple direct-send setup.

OMNeT++ is a simulation tool that lets you model how packets move through a network before you build hardware. A 10-node testbed then gives you real-world proof that the idea works outside the simulator. That combination makes the project stronger, because you can compare theory, simulation, and physical results.

Why This Is a Good Topic

This is a strong science fair topic because you can measure real network behavior, not just build a gadget. You can test packet delivery, delay, hop count, and energy use under different topologies and failure cases. The project connects to emergency response, which gives it clear real-world value. You can also learn how engineers model networks, build testbeds, and compare simulation results with hardware data.

Research Questions

  • How does node spacing affect packet delivery in a delay-tolerant ESP32 LoRa mesh?
  • What is the effect of adding more relay nodes on end-to-end message delay?
  • Does a delay-tolerant routing rule improve delivery rate after simulated node failures?
  • To what extent does topology type change network resilience in a city-scale post-earthquake model?
  • Which message buffer size gives the best trade-off between delivery rate and latency?
  • How does terrain or building density in a city map change LoRa mesh performance?

Basic Materials

  • ESP32 development boards, 10 or more.
  • LoRa transceiver modules matched to the ESP32 boards.
  • USB data cables for each board.
  • Breadboards or perfboards for temporary wiring.
  • Jumper wires in assorted lengths.
  • Rechargeable batteries or USB power banks.
  • Laptop for coding and data logging.
  • MicroSD cards or another local storage method for test logs.
  • Basic multimeter for checking power and continuity.
  • Local city map or floor plan data for network layout planning.

Advanced Materials

  • ESP32 development boards, 10 or more.
  • LoRa modules with known frequency band and antenna match.
  • Soldering tools and prototyping boards for stable node assembly.
  • Battery monitor or power measurement hardware.
  • Laptop or workstation with OMNeT++ installed.
  • GNU Octave or Python for simulation analysis.
  • Network traffic capture tools for packet tracing.
  • Signal strength meter or spectrum analyzer access.
  • 3D-printed or laser-cut enclosures for repeatable node placement.
  • GIS or topology data for realistic city modeling.

Software & Tools

  • OMNeT++: Simulates packet flow, node failures, and topology changes before you build hardware.
  • Python: Cleans logs, plots latency and delivery rate, and runs statistical tests.
  • ImageJ: Measures node placement from photos or maps when you need consistent spacing checks.
  • GNU Octave: Fits curves and compares simulation outputs with testbed data.
  • QGIS: Helps you turn city maps into realistic network layouts for simulation.

Experiment Steps

  1. Define the network problem you want to solve, such as message delivery after node loss or blocked routes.
  2. Choose one main variable to change first, such as node density, relay placement, or failure rate.
  3. Build a simulation model that matches a real city or campus layout closely enough to test your routing idea.
  4. Plan control conditions that compare your delay-tolerant protocol against a simpler baseline route.
  5. Design a hardware testbed that mirrors the simulation assumptions, so you can compare both results fairly.
  6. Decide how you will measure success, such as delivery ratio, latency, hop count, and battery cost.

Common Pitfalls

  • Treating the simulator and the hardware testbed as if they are identical, which makes the final comparison weak.
  • Changing node placement between trials, which confuses the effect of the routing protocol with the effect of geometry.
  • Ignoring packet loss caused by walls, interference, or distance, which can make the mesh look better in simulation than in real life.
  • Using only delivery rate as the success metric, which misses latency and battery cost.
  • Testing too many variables at once, which makes it hard to tell whether routing, topology, or buffer size caused the result.

What Makes This Competitive

A competitive version of this project would do more than prove that a mesh works. You would compare a new routing rule against a baseline in several realistic city layouts, then test whether the same trend appears on hardware. Strong analysis would include confidence intervals, failure-case testing, and a clear reason why one design wins. If you can connect simulation assumptions to real node behavior, your project starts to look like engineering research.

Project Variations

  • Test the same mesh idea on a school campus map instead of a city block to see how building layout changes delivery.
  • Compare LoRa mesh performance with Wi-Fi mesh performance under the same failure scenarios.
  • Study how different message priorities, such as rescue alerts versus routine updates, change network congestion and delay.

Learn More

  • OMNeT++ Community Site: Find documentation, tutorials, and model examples for network simulation.
  • NIH PubMed: Search review articles on delay-tolerant networking, disaster communications, and wireless mesh routing.
  • NASA Open Source Software Catalog: Explore free engineering tools and simulation-related project ideas.
  • NOAA Disaster Information Resources: Review real-world disaster communication needs and emergency planning context.
  • MIT OpenCourseWare: Search networking and wireless systems courses for lecture notes on routing, packets, and network design.
  • IEEE Xplore Abstracts: Search recent peer-reviewed papers on LoRa mesh networking and delay-tolerant protocols, then read abstracts and available open-access papers.

For next steps tailored to your interests, skill level, and timeline, work one-on-one with a MehtA+ mentor. Learn more about MehtA+ Science & Engineering Research Mentorship →

To discover more projects, visit the MehtA+ Science Fair Project Discovery Hub​ →

Shopping Cart