← All posts
Series NearWave Series — Part 1 of 6

Why Use Sound as a Data Transport Layer

·
nearwaveaudioprotocolsystems

This is the first post in a series about NearWave — a system for transmitting data between devices using sound. Before getting into modulation schemes, frame structures, or DSP, I want to explain why this exists and why audio is a viable transport layer for real data.

The Problem

Most data transfer between nearby devices assumes a shared network. Wi-Fi, Bluetooth, AirDrop, NFC — all of them require protocol negotiation, pairing, or infrastructure. They work well when they work. But there are environments where they don’t:

  • Air-gapped systems — machines deliberately disconnected from any network
  • Restricted facilities — environments where wireless radios are disabled or monitored
  • Cross-platform friction — transferring a snippet between a Linux terminal and an iPhone shouldn’t require a cloud service
  • Field conditions — no access point, no cellular coverage, no shared network segment

In these situations, the problem isn’t bandwidth. It’s connectivity. You need to move a small amount of data — a key, a config block, a URL, a token — and there’s no channel available.

Why Audio

Every device with a speaker and a microphone already has a unidirectional communication channel. Laptops, phones, tablets, embedded boards with audio output — the hardware is already there. No pairing. No handshake over a radio protocol. No shared network.

Sound has useful properties for short-range data transfer:

  • Universality — audio hardware exists on virtually every computing device
  • No infrastructure — no router, no access point, no Bluetooth stack
  • Physical locality — sound attenuates rapidly, which creates a natural boundary for the transmission
  • Auditability — you can hear it (or choose not to, in ultrasonic mode)

The tradeoffs are real. Bandwidth is low — tens to hundreds of bits per second, not megabits. Noise degrades the signal. Hardware differences between speaker and microphone affect fidelity. But for small payloads in constrained environments, those tradeoffs are acceptable.

What Makes It Non-Trivial

Playing a tone is easy. Building a reliable data transfer system over audio is not.

The signal passes through a DAC, a speaker, an air gap with ambient noise, a microphone, and an ADC before any processing begins. Each step introduces distortion, latency, and potential data loss. The system has to handle:

  • Frequency detection — resolving which tone is playing at any given moment, with sub-millisecond precision
  • Synchronization — knowing exactly when a transmission starts and where frame boundaries are
  • Error correction — recovering from bit flips caused by noise without retransmission (there’s no back-channel)
  • Encoding efficiency — fitting useful data into severely limited bandwidth

This isn’t a networking problem in the traditional sense. It’s a signal processing problem with protocol design layered on top.

Design Constraints

NearWave operates under constraints that shape every decision in the system:

  1. Unidirectional — no acknowledgment, no retransmission. The sender transmits; the receiver either gets it or doesn’t.
  2. Low bandwidth — the channel supports roughly 100–500 bits per second depending on the profile.
  3. Noisy medium — ambient sound, hardware variation, and room acoustics all affect the signal.
  4. Cross-platform — must work with whatever audio hardware the OS exposes, without specialized drivers.

These constraints rule out approaches that assume reliable delivery, high throughput, or bidirectional communication. What’s left is a system that must be correct by construction — compression to minimize what’s sent, error correction to survive noise, and structured framing to make synchronization deterministic.

What This Series Covers

The rest of this series walks through how NearWave is built:

  • Part 2 — Modulation: converting bits into audio frequencies using FSK
  • Part 3 — Protocol: frame structure, synchronization, CRC, and error correction
  • Part 4 — Detection: using the Goertzel algorithm for efficient frequency detection
  • Part 5 — Pipeline: how encoding, modulation, DSP, and decoding fit together
  • Part 6 — Performance: throughput, latency, compression, and real-world tradeoffs

Each post focuses on a specific layer of the system and the engineering decisions behind it.