1. Initiation: Users start a Wardriving session on their mobile device to map connectivity. Once connected via Bluetooth to a MeshCore companion, the session is geolocated and authorized against known companions (active within the last 60 days). Sessions are regulated by "slot" availability to minimize mesh traffic.

2. The Drive: The app sends messages over the mesh at timed intervals containing GPS coordinates. These messages are ingested by letsmesh.net observers and forwarded via MQTT to MeshMapper servers.

3. Listening: Simultaneously, the wardriving companion listens for repeaters rebroadcasting the message. It packages this data (location, power, noise floor, repeater IDs, raw packets) and sends it to the MeshMapper backend API.

4. Processing & Status: The engine correlates the MQTT ingestion with the companion's local data to determine coverage status:

• BIDIR (Bidirectional)
  Message received by the mesh AND the companion heard it repeated. 2-way communication confirmed.
• TX (Transmit Only)
  Message received by the mesh, but the companion heard no repeats. 1-way communication (outbound).
• DEAD
  Message NOT received by the mesh, but the companion heard a local repeat. Repeaters exist but aren't fully integrated.
• DROP (Dropped)
  Message NOT received by the mesh and NO repeats heard. No connectivity.

5. Passive RX: Independently, if the companion hears unrelated mesh traffic (RX), this is also mapped, indicating at least inbound connectivity.

6. Visualization: Data is layered on the map (BIDIR on top, DROP on bottom). Users can toggle layers for repeaters, coverage, and topographic/dark modes. A Noise Heatmap is generated using delta comparisons against a user's baseline noise floor to identify interference sources.

This data helps focus infrastructure improvements and monitor network health. Happy mapping!