SkyMesh · DNHacks 2026 · Team prototype

A shared sky.
Powered by phones.

Turn phones into acoustic drone sensors. Detect on the device, share compact readings, and compute the picture independently at each node.

Edge ML / Distributed sensing / Operator interface
Next.js · TypeScript · ONNX Runtime Web · FastAPI · Leaflet

Open SkyMesh ↗ · Operator workspace ↗

The actual SkyMesh Fly.io landing page: retro gray enrollment panel, local detection and privacy indicators, microphone join button, and ASCII mascot.
The actual product at skymesh-hongnoul.fly.dev, captured September 7, 2026. This is the phone enrollment screen before microphone permission, not the simulation sandbox.

01 / The idea

Instead of asking one central sensor to hear everything, let many small sensors contribute what they hear. SkyMesh explores that idea with hardware people already have: their phones.

Built as a team project for the DNHacks 2026 defense track presented by Second Front Systems. The prototype brings together acoustic classification, a replicated sensor log, local fusion, and an operator workspace.

02 / From sound to a shared picture

  1. Listen locally. Microphone audio becomes a mel-spectrogram in TypeScript. An ONNX CRNN classifier runs in the browser and produces a drone-confidence score. Audio stays on the phone.
  2. Share readings, not recordings. Nodes gossip compact sensor records to neighbors and maintain their own copies of the log.
  3. Compute independently. Each node derives its own fused picture from the readings it has received. The operator view is not a privileged server-side answer.
  4. Make the network visible. The workspace brings enrollment, participant placement, topology, confidence, and link-failure controls beside the map.

Distributed computation does not mean serverless transport. The browser demo uses a WebSocket relay for delivery. Direct radio links are a hardware direction, not a demonstrated browser capability.

03 / Watch the synthetic demo

Secondary reference: a silent recording of the local synthetic sandbox, about 15 seconds. The built-in demo creates five synthetic sensors and a route, then starts the simulated drone. One sensor acquires a contact and the report spreads through the mesh. This demonstrates the planning interface, not live microphone detection or real-world accuracy.

The sandbox is deliberately separate from the live session. Its synthetic contacts never become microphone readings. That distinction also guides the operator interface: connection health, sensor confidence, and scenario notices communicate different things.

04 / A workspace for real participants

SkyMesh operations workspace in its empty-session state, showing a participant map, enrollment QR code, confidence panel, and topology controls.
The deployed Fly.io operations workspace, captured in a separate empty session with its relay connected. No phones were admitted and no sensor readings were fabricated. Imagery © Esri, Maxar, Earthstar Geographics.

My contribution

My recorded work includes integrating the hardware viewer into the sensor and operations interfaces, adding a separate node simulation-alert channel, and verification work covering simulation alerts alongside live ONNX sensing. The detector, mesh, and operator experience are presented here as a team-built system, not a solo project.

05 / What this prototype does not prove

SkyMesh is not a field-validated counter-drone system. The fusion model needs real-room calibration before position estimates can be trusted. Simulation coverage and contact timing are properties of the simulated scenario, not measured deployment performance.

Local sensing and replicated state are distinct from message delivery: losing the relay interrupts browser-to-browser transport. A live multi-phone demonstration also needs HTTPS, microphone permission, and a running relay, the live product links above open its enrollment and operator interfaces. The separate recording illustrates only the synthetic planning sandbox.