Inspiration

Getting lost or injured in the backcountry is dangerous when there’s no cell signal to call for help. We wanted a way for hikers to stay connected to the outside world even in areas with zero cellular or Wi-Fi coverage.

Breadcrumbs was inspired by the idea of leaving a trail of “crumbs” as you go—small, cheap devices you drop along your path that form a relay network. If something goes wrong, you can send an SOS or other message hop-by-hop back to a gateway that has internet, so someone can get help or at least know where you were last.

We wanted it to be lightweight, battery-friendly, and easy to use: drop nodes when the signal gets weak, and let the system tell you when and which crumb to drop next.

What it does

  • Builds an off-grid relay network — You carry several ESP32 “crumb” nodes in a pouch (we call the pouch Bread). As you hike, you drop crumbs along the trail. They talk to each other and to the pouch using ESP-NOW (peer-to-peer Wi-Fi), no routers or infrastructure needed.

  • Smart drop timing — The pouch measures how strong the last-dropped crumb’s signal is (RSSI). When the signal stays weak for a short time, it tells the next crumb to blink so you know which one to take out and drop. Spacing is driven by real signal strength, not a fixed timer.

  • In-pouch feedback — When a crumb is back in the pouch (strong RSSI), the pouch can tell that crumb to turn its LED off so you’re not blinking the wrong one.

  • Emergency messaging — Messages (e.g. SOS) can be sent along the chain. When a message reaches a gateway crumb near connectivity, it can be forwarded to the internet (webhook, SMS, or API).

  • Return guidance — Crumbs can blink in sequence to help you follow the same path back out.

How we built it

  • Hardware: ESP32 DevKit boards as crumbs and one as the Bread (pouch controller). We use the same ESP-NOW protocol for both “crumb ↔ Bread” and “crumb ↔ crumb” so everything stays simple and low-power.

  • Bread (pouch) firmware: State machine that tracks which crumb to drop next, listens for ESP-NOW beacons from all crumbs, records RSSI per crumb, and sends RELEASE (blink / “drop me”) or IN_POUCH (LED off) to the right crumb by ID. Drop order and crumb MACs are configured to match our hardware (see hardware/MACs.md).

  • Crumb firmware: Each crumb (A, B, C, D) runs the same logic with a different CRUMB_ID: send beacons to the Bread on a fixed interval, and handle RELEASE (LED on) and IN_POUCH (LED off) from the Bread. All use the same Bread MAC and WiFi channel so the pouch can see every crumb.

Challenges we ran into

  • Packet loss and unreliable links — ESP-NOW is connectionless: packets can be dropped with no built-in retry. In the field, weak signal or interference meant critical messages (e.g. RELEASE or SOS) sometimes never arrived. We overcame this by implementing acknowledgements (ACKs) on send and receive: the sender retries until it gets a confirmation that the message was received, so we know the message got through even when some packets are dropped.

  • Duplicate messages from retries — Once we added retries and ACKs, the same message could be delivered more than once. We had to add deduplication (e.g. by message ID) so that each logical message was only processed once, even if multiple copies arrived over the air.

  • MAC and channel alignment — ESP-NOW only works if both sides use the same channel and correct peer MACs. We had to make sure every crumb used the Bread’s MAC (not another crumb’s) and that Bread and all crumbs used the same WiFi channel (e.g. channel 1). Mixing these caused “can’t sense” issues until we locked them down and added the check script.

Accomplishments that we're proud of

  • Unified Bread ↔ crumb protocol — One clear set of message types (RELEASE, IN_POUCH, BEACON) and one Bread MAC so that any crumb can work with the same pouch firmware.

  • RSSI-based drop timing — Deciding when to drop the next crumb based on real signal strength (and telling the user which crumb to drop via LED) instead of a fixed timer makes the system more adaptable to terrain and distance.

  • Consistent firmware across A/B/C/D — All four crumbs run the same logic with only CRUMB_ID and board identity differing; that made debugging and demos much easier and ensured Bread “works with all the other crumbs.”

  • Documentation and checks — MACs, routing, and protocol are documented; the check script gives confidence that Bread and crumbs stay aligned before flashing or demoing.

What we learned

  • Networking and reliability — We implemented acknowledgements when sending and receiving so we can ensure a message is actually received even when packets are dropped. Senders retry until they get an ACK, and receivers confirm delivery. That made the system much more reliable in real conditions where the link is lossy.

  • ESP-NOW is strict about peers and channel — Correct peer MAC and a shared WiFi channel are mandatory; small mistakes (e.g. using another crumb’s MAC instead of Bread’s) break communication in subtle ways.

  • State machines help on the pouch — Modeling Bread’s behavior (init → wait → drop next → track signal → done) made the logic clearer and easier to extend (e.g. different drop orders or thresholds).

What's next for Breadcrumbs

  • Generic WiFi packets and any app — We want to support sending any generic WiFi packet over the trail, not only messages from our own app. That way you could send a message from Discord, Telegram, or any other existing app; the gateway would forward it hop-by-hop along the breadcrumb chain, and replies could come back the same way. The trail becomes a transparent link so you use whatever tools you already use.

  • Longer range and robustness — Experiment with ESP-MESH or LoRa for better range and more reliable multi-hop in rough terrain.

  • GPS and mapping — Log GPS at each drop and visualize the breadcrumb trail on a map for rescue or trip review.

Built With

Share this project:

Updates