FSKHTTP turns text into tones, then turns tones back into text.

A Modern Web Lab for an Old Signaling Idea

Frequency-shift keying is one of the classic ways to move digital information over a signal path. Instead of representing data with voltage levels alone, FSK represents symbols by changing frequency. One tone can mean a binary mark, another tone can mean a space, and a receiver can recover the bitstream by detecting which tone arrived during each symbol window.

That makes FSK easy to teach, easy to hear when it is in the audible band, and surprisingly useful as a building block. It shows up historically in telephone modems, caller ID style signaling, amateur radio, industrial HART instrumentation, emergency alert tones, and other systems where a simple tone channel can survive imperfect transmission.

What FSKHTTP Does Today

The public FSKHTTP site is still early, but the core loop works. A visitor can open the browser tool, type a text message, generate an FSK-encoded WAV file, play it back, download it, and decode it back into text. The same flow is exposed as service endpoints: POST /encode converts text into a WAV response, POST /decode accepts a WAV upload and returns decoded text, GET /health reports service health, and GET /metrics exposes operational metrics.

The code is published as the open-source absginc/fskhttp project. The service wraps the ggwave tone modem library in a REST interface, keeping the lower layer focused on byte-to-tone and tone-to-byte conversion while higher layers can decide how to handle identity, compression, encryption, routing, or logging.

That is the useful shape of the project. It is not trying to replace TCP/IP or become a magic high-bandwidth transport. It is a controlled FSK modem service that can be dropped into a stack when someone wants tone generation, tone recovery, test fixtures, offline demonstrations, or an acoustic side channel they can reason about.

Why Autonomous Agents Make This Interesting Again

Two human callers need speech because humans understand speech. Two autonomous voice agents do not necessarily need to keep speaking in natural language after they discover each other. They might exchange structured state more efficiently through a machine-readable acoustic burst, then switch back to speech for the human listener.

That is the idea behind the broader wave of "agents talking to agents" experiments. A phone call, browser tab, meeting room, or voice pipeline already carries audio. FSKHTTP gives us a simple way to test whether a short message can ride over that audio path, be decoded by another process, and return to normal interaction without requiring the entire stack to share a private network connection.

Out-of-Band Communication, Not Just Nostalgia

Out-of-band communication means the data moves somewhere other than the primary channel. In a web system, that might mean a browser speaker and microphone. In a field system, it might mean a current loop, a radio audio path, or a monitoring feed. In a lab, it might mean a WAV file that carries a payload through a pipeline that does not otherwise accept JSON.

That is where FSK stays relevant. The method is simple enough to inspect with ordinary audio tools. It is visible in a waveform, audible when using human-range tones, and tunable when experimenting with symbol rate, frequencies, noise, silence, and error behavior. For teaching, demos, and repeatable tests, that simplicity is a feature.

The Ultrasonic Question

The same idea becomes more sensitive when the tones move near or above the top of normal human hearing. Human hearing is usually described around 20 Hz to 20 kHz, with real-world high-frequency sensitivity varying by age, device, volume, and environment. A tone that many adults do not notice may still be detectable by a microphone or another sensor path.

That raises the privacy question: is your phone emitting or receiving signals you do not hear? The honest answer is conditional. A phone can emit audio through a speaker if software plays it. A phone can receive audio if an app or browser context has access to the microphone or another usable sensor path. Researchers and regulators have documented ultrasonic beacon systems used for cross-device tracking, including cases where mobile apps listened for codes embedded in nearby media. That does not mean every phone is constantly doing it. It does mean inaudible or barely audible signaling is real enough to deserve testing, disclosure, and controls.

FSKHTTP is useful here because it makes the mechanism visible. Instead of treating acoustic tracking like folklore, engineers can generate tones, inspect the waveform, decode known payloads, test what browsers and devices actually capture, and decide what consent and detection rules belong in a production system.

Use Cases Worth Testing

The first use case is education. FSK is easier to understand when a student can type a phrase, see the waveform, hear the tones, decode the file, and compare what changed when the message or audio path changed.

The second use case is agent coordination. A voice agent could send a short structured marker over an audio channel: session ID, tool handoff, capabilities, request status, or a "switch to data mode" signal. It would not need to carry a full conversation in tones to be useful.

The third use case is monitoring and security research. Acoustic beacons, ultrasonic signals, and other side channels need practical test tools. If a business wants to know whether an environment, browser, app, meeting room, or device path can emit or receive hidden tones, a controlled modulator and demodulator is a good starting point.

The fourth use case is odd but practical integration. A system may accept audio but not arbitrary network requests. A controlled tone payload can sometimes cross boundaries where a normal API call cannot. That should be used carefully, with consent and logging, but it is a real systems pattern.

What We Are Watching Next

The next useful work is measurement. Which browsers preserve the tones? Which microphones clip or filter them? Which meeting tools suppress them as noise? How high can frequencies go before consumer devices stop reproducing or receiving them reliably? What symbol rates survive common codecs? What does an acceptable consent model look like when a page or app intentionally emits a machine-readable tone?

Those questions are why this project belongs in the ABSG project list even before it is polished. FSKHTTP is not only a small tool. It is a test bench for a category of communication that sits between audio engineering, privacy, autonomous agents, and old-school modem design.

Research Notes

For this project note, ABSG reviewed public references on FSK and AFSK, HART/Bell 202 style industrial signaling, emergency alert tone encoding, and ultrasonic cross-device tracking risk. Good starting points include the FSKHTTP GitHub repository, the FieldComm Group explanation of HART FSK, the National Weather Service SAME directive, the FTC SilverPush warning letters announcement, and the EuroS&P paper Privacy Threats through Ultrasonic Side Channels on Mobile Devices.

The design lesson is straightforward: tone transmission is legitimate engineering, but hidden tone transmission can become tracking. FSKHTTP gives ABSG a small, inspectable tool for both sides of that line.