WiFi Walkie Talkies

Rationale and Sources of Inspiration
We wanted to create a project that incorporated topics covered in labs as well as new elements.
Utilizing the Pico W as an audio transmitter/receiver, essentially transforming units into
walkie-talkies, accomplished this goal. Additionally, the devices are able stream music when in
receive mode using a PC to broadcast the audio data.
The use of a DAC for audio sampling was a core component
of the birdsong and Galton Board Labs, and played a fundamental role in our final project. The
use of the RP 2040
ADC input pins, introduced in the Galton Board lab, was a significant aspect of our project as
well. However,
the realm of Wi-Fi connection and UDP communication was a topic not covered during the labs,
which we thought would be fun to explore. The dual broadcast/receive functionality adds extra
complexity, with both devices able
to toggle between modes. The concept of state change was a fundamental aspect of labs 1 and 2,
which served as a source of inspiration for this feature.
Dr. Adams' lecture on UDP communication and the accompanying demo code on the
course website
were a helpful
starting point.
Logical Structure & Tradeoffs
The primary software/hardware tradeoffs involve managing network overhead while maintaining the
high sampling rate of 44.1KHz. Although this rate
exceeds the sampling rate needed to capture the full human vocal range, it is optimal when
streaming music and adds an extra constraint to the project for the sake of a challenge.
The architecture carefully separates timing-critical real-time operations (handled by the ISR)
from bursty network I/O (managed by cooperative protothreads), using double-buffering on the
transmit path and a thread-safe circular queue on the receive path to decouple these domains.
Audio packets of 1024 samples (11.6 ms, 2048 bytes) are transmitted approximately 86 times per
second, balancing network efficiency against latency. The receive buffer holds 8192 samples
(~185 ms), providing substantial tolerance for WiFi jitter at the cost of end-to-end latency. A
low-pass filter with 5-6 kHz cutoff is applied to microphone input to reduce noise while
preserving voice intelligibility. The system runs entirely on a single core with lock-free
synchronization primitives, prioritizing audio timing integrity over network responsiveness—a
necessary tradeoff given the RP2040's resource constraints. While uncompressed PCM transmission
is bandwidth-intensive, it minimizes CPU overhead and latency, making it suitable for real-time
voice communication where the ~200 ms total system latency (buffering + network + processing)
remains acceptable for conversational use.
Background Mathematics & System Architecture
Sample rate: 44,100 Hz | Stereo: 2 samples captured per ISR call (duplicated mono) | Buffer
size: 1024 samples (512 stereo pairs)
Time to fill buffer: 1024 samples / (2 samples/ISR * 44,100 Hz) ≈ 11.6 ms
Packets per second: 1000 ms / 11.6 ms ≈ 86 packets/second