Underwater acoustic communication carries digital messages through water as sound. For an autonomous underwater vehicle (AUV), it provides a way to exchange status, selected sensor data, and mission instructions while submerged. Its defining constraints are limited throughput, propagation delay, and a changing acoustic channel. Those constraints favor onboard autonomy with intermittent supervision over a control scheme that depends on immediate replies.
The useful system boundary runs from the operator's application to the vehicle's mission software. A modem receiving a packet is only one step: the vehicle must also decode the message, decide whether it is still valid, and report what it did. WHOI's ros_acomms documentation illustrates this complete transport path and its use for AUV redirection and telemetry.
On This Page
- From mission software to sound and back
- Why the water changes the link
- Calculate response time before choosing a data rate
- Define interfaces and command behavior
- What JANUS does for interoperability
- Diagnose failures by where the message stops
- Match communications to the vehicle's job
From mission software to sound and back
An acoustic modem converts digital data into an acoustic signal and recovers data from received sound. A typical vehicle installation combines a host computer, modem processing electronics, a transmit power amplifier, and a transducer that couples the signal into the water. Reception may use that transducer or a separate hydrophone array. The other endpoint has a compatible acoustic installation on a vessel, buoy, another vehicle, or a fixed node.
The physical hardware must work as a set. WHOI's Micromodem installation guidance distinguishes single-channel and array reception and documents amplifier/transducer matching. A connector that fits is insufficient evidence that voltage, frequency response, or receiver configuration matches.
Modulation is the rule that maps data onto sound. Frequency-shift keying (FSK) uses changes in frequency; phase-shift keying (PSK) uses changes in phase. The receiver applies the corresponding decoding process, including any supported error correction. Both ends need compatible settings; selecting a nominal frequency alone does not establish a working link.
Above the hardware, the transmit path is:
- Mission software creates a message, such as a revised survey instruction.
- An encoder packs its fields into a compact representation.
- A queue selects what to send, and a medium-access controller allocates a transmission opportunity.
- The modem sends the acoustic packet.
- The remote modem and decoder recover the fields for the receiving application.
This sequence follows the ros_acomms architecture. It shows why a fast onboard network does not remove an underwater bottleneck: messages can accumulate before they ever reach the transducer. For telemetry, consider replacing superseded status reports with the newest value. For commands, preserve identity and disposition so an operator can distinguish a pending instruction from a rejected one. These are application design choices, not automatic modem features.
Why the water changes the link
Sound loses energy through spreading and absorption. Absorption increases with frequency, so extending range and increasing available bandwidth pull the design in different directions. The water also changes the route: refraction bends sound paths, while surface and seabed reflections create multiple arrivals of the same transmission.
Those delayed copies can overlap symbols, making decoding difficult even when a signal is detectable. Relative motion creates Doppler effects that change the received waveform. A modem must acquire the packet and compensate for channel distortion; hearing energy in the expected band does not establish successful data reception.
Fox and colleagues' underwater network modeling paper shows how source depth, receiver depth, and the sound-speed profile change predicted packet performance. Its simulated results describe specified environments, not a universal range map.
For an installation review, ask for performance across the mission's depth and separation envelope. A single maximum-range figure conceals whether the path is horizontal or vertical and how the endpoints move. More transmit power also cannot correct an incompatible waveform or a message rejected by the application.
Calculate response time before choosing a data rate
NOAA gives approximately 1,500 meters per second as a representative speed of sound in seawater. Actual propagation depends on the water column. Using that approximation, an illustrative straight 3,000-meter acoustic path takes 2 seconds each way.
One-way propagation time = path length / sound speed = 3,000 m / 1,500 m/s = 2.0 s.
A reply cannot return in less than about 4 seconds from propagation alone in this simplified scenario. Packet transmission, decoding, scheduling, and any retry add time. This is an editorial calculation, not a measured modem result or a prediction for a refracted path.
Keep three quantities separate:
- Packet rate: the rate stated for a particular waveform and packet definition.
- Useful throughput: application data delivered per elapsed second after overhead and losses.
- Command response time: elapsed time until the operator receives the confirmation needed to proceed.
The WHOI Micromodem overview makes the distinction concrete. Its Rate 5 table lists a burst rate of 5,388 bits per second, while an example single-channel system delivers 3,343 bits per second. That example assumes no acknowledgment, 115k-baud host interfaces, and immediate host response to modem data requests. It does not establish throughput for another receiver, firmware configuration, or mission.
For procurement, request a timing trace for the intended packet size, acknowledgment policy, range, and number of nodes. Ask where timing starts and ends. A transfer ending at the receiver's serial port does not measure how long the vehicle takes to accept a command.
Define interfaces and command behavior
Integration needs an agreement at several boundaries. At the electrical interface, establish the actual modem's power requirements and host connection. For the serial-host system documented by WHOI, serial timing is part of the throughput budget. At the software interface, specify message identifiers, field sizes, units, coordinate references, and version handling. At the mission interface, decide which commands are permissible in each vehicle state.
The ros_acomms research preprint describes compact field encoding, fragmentation of large messages, and acknowledgment with retransmission. Those mechanisms help move data, but they do not define what a particular mission command means.
For example, an integrator might define a survey-update message with a command identifier, issue time, expiry time, coordinate reference, and requested action. The vehicle could then report separate states for receipt, acceptance, and completion. This is an illustrative interface design, not an existing standard message definition.
That separation resolves two common ambiguities. A transport acknowledgment can establish that a packet arrived without proving the vehicle executed it. Conversely, a missing acknowledgment leaves uncertainty about delivery; repeating a non-idempotent command could repeat its action. An idempotent operation has the same intended effect when repeated. Use command identifiers and duplicate handling where repetition would matter.
Also define what happens when communication stops. A mission may permit continued survey, a rendezvous, or a controlled recovery, depending on the operating area and vehicle capability. Choose and exercise that behavior before deployment. Automatic surfacing is unsuitable wherever overhead obstacles or ice prevent a safe ascent.
What JANUS does for interoperability
JANUS provides a common acoustic signaling method for underwater systems. NATO's 2017 announcement describes contacting devices, announcing their presence, and helping organize a network. It identifies applications including environmental information exchange and maritime monitoring.
For current context, CMRE's 2025 annual report states that a new version of STANAG 4748, the JANUS physical standard, was released in 2024. It also records the establishment of a JANUS Support Team in 2025. These are documented milestones; the report does not prove implementation by any particular modem.
Treat interoperability as a demonstration requirement. Ask suppliers to identify the implemented standard version, acoustic band, supported messages, and any subsequent data-transfer protocol. Then demonstrate an exchange between the actual endpoints. Shared signaling does not by itself prove that mission applications interpret commands identically, or that command authentication and replay protection are present. Establish those capabilities separately.
Diagnose failures by where the message stops
Begin with the last confirmed event along the message path. A transmitter reporting success, a receiver decoding a packet, and a vehicle completing a task are different observations.
The following troubleshooting table combines WHOI's installation and transport documentation with the channel behavior modeled by Fox and colleagues. The diagnostic steps are engineering interpretations, checked September 7, 2026; symptoms can have more than one cause.
| Observed symptom | Possible explanation | Next check |
|---|---|---|
| The host queues data, but no transmit event follows | Driver, addressing, scheduling, or modem configuration problem | Compare host queue records with modem events before changing acoustic settings |
| A signal is detected, but packets fail to decode | Waveform mismatch, multipath, motion, or interference | Confirm both configurations, then compare reception under controlled geometry and noise conditions |
| Reception degrades when onboard equipment runs | Acoustic or electrical interference | Compare receiver noise spectra with suspect equipment enabled and disabled |
| Delivery works in one direction only | Different receive capability, noise, power, or geometry at the endpoints | Inspect and test each direction independently |
| Packets arrive, but commands have no effect | Decoder mismatch, expiry, or mission-state rejection | Inspect decoded fields and application disposition |
| Status arrives intact but is old | Queue backlog, retries, or insufficient airtime | Compare creation and receive timestamps and review queue priority and expiry |
WHOI specifically warns that switching supplies and other onboard equipment can interfere with sensitive receivers. Its guidance also calls for in-water transducer testing and appropriate hearing protection. Follow the hardware instructions: a dry-air experiment is not a substitute for a correctly loaded underwater installation.
A useful sea trial should retain the conditions behind each result: geometry, depth, vehicle motion, active equipment, waveform, message size, and traffic load. Measure both successful delivery and data age. Otherwise, a high delivery fraction may hide a queue that supplies information too late to use. Include power measurements over the planned transmit, receive, and idle schedule: repeated retries may improve delivery while consuming energy and airtime needed elsewhere.
Match communications to the vehicle's job
For a survey AUV, acoustics can support supervisory updates while bulk sensor records remain onboard. NOAA's 2019 REMUS 600 expedition account describes submerged acoustic communication, satellite status reporting at the surface, and a high-speed cable for downloading data after recovery. These are complementary paths in a documented system, not interchangeable bandwidth claims.
For environmental monitoring, fixed instruments and mobile vehicles can exchange compact observations through an acoustic network. For multiple vehicles, the scheduling problem grows: a message's priority must be considered alongside other nodes' traffic and the time needed for replies. The network should be evaluated with its intended population, not only as a quiet two-modem link.
Define the messages the mission actually needs, their maximum useful age, and the behavior allowed during silence. Then evaluate acoustic hardware, transport software, and application responses together. The decisive result is a timely, correctly interpreted exchange under representative conditions, supported by a vehicle that can handle the intervals between exchanges.
Sources
- WHOI, ros_acomms Overview: software documentation for message flow, queues, scheduling, and vehicle use.
- WHOI, Installation, Testing, Troubleshooting: hardware configurations, interference, packet handling, and transducer testing.
- Fox et al., Underwater Acoustic Communications Performance Modeling in Support of Ad Hoc Network Design: research on environmental effects and modeled network performance, 2007.
- NOAA, How far does sound travel in the ocean?: sound speed and propagation context.
- WHOI, Micromodem: packet-rate definitions and configuration-specific throughput examples.
- Gallimore et al., ROS Message Transport over Underwater Acoustic Links with ros_acomms: research preprint describing encoding, fragmentation, and reliable transport.
- NATO, A new era of digital underwater communications: official 2017 description of JANUS functions and applications.
- CMRE, Maritime Unmanned Systems Enablers, Annual Report 2025: institutional record of the 2024 JANUS revision and 2025 support team.
- NOAA, Seafloor Mapping with the REMUS 600 Autonomous Underwater Vehicle: operator account of communications and data retrieval during the 2019 demonstration.
Last checked: September 7, 2026.
