Every field in a data standard exists because something in the physical world forces it to. A deep-sea message carries a calibration date on every temperature value, a separate accuracy block for position, a pressure range that reaches past one thousand bar and a binary encoding for links that move a few hundred bits per second. None of those choices makes sense until you have a feel for the environment the data comes from. This chapter builds that feel. It is deliberately physical: depth zones, hydrostatic pressure, the temperature and chemistry envelope, the vehicles that operate down there, the sensors they carry, and the acoustics that dominate both communication and seafloor mapping.

You do not need an oceanography background. High-school physics is enough, and every formula is worked through with numbers. Where the WIA-ENE-040 documents or the shipped SDK get the physics wrong, the chapter says so and shows the correct version, because an implementer who copies a wrong formula into a validator will reject good data or accept bad data for years. Readers who already know the ocean can skim sections 1.3 to 1.5 and focus on the pitfalls in 1.1 and 1.2 and the link-budget reasoning in 1.6.

1.1 How the Standard Defines "Deep Sea"

The scope boundary: deeper than 200 m

WIA-ENE-040 applies to activity below 200 m. That boundary is not arbitrary. Roughly at that depth the continental shelf ends and the seafloor begins to fall away along the continental slope, and sunlight becomes too weak to support photosynthesis. The upper 200 m, the epipelagic zone, is where most coastal and surface oceanography happens, and it already has mature data practices of its own. The standard's §2.1 scope therefore starts where the environment becomes dark, cold, high-pressure and reachable only by specialised platforms.

The shipped TypeScript SDK still includes an EPIPELAGIC member in its DepthZone enum, and its getDepthZone() helper returns it for any depth under 200 m. That is useful: a vehicle's descent through the surface layer produces real telemetry, and the software must be able to label it. But records whose depth is shallower than 200 m fall outside the standard's normative scope, and a conformance reviewer may ask why they are in a WIA-ENE-040 archive at all. A reasonable rule is to keep them, labelled epipelagic, as part of a dive's continuous track, and not to treat them as deep-sea observations.

Two zoning schemes that coexist

The standard uses two different ways of cutting the ocean into depth zones, and the reader needs to hold both at once.

The pelagic scheme describes the water column: the open water a vehicle passes through. It is the scheme in ENE-040 §2.1 and in the SDK's DepthZone enum:

• mesopelagic: 200–1,000 m, the twilight zone where some sunlight still penetrates but not enough for photosynthesis;
• bathypelagic: 1,000–4,000 m, permanently dark water;
• abyssopelagic: 4,000–6,000 m, the water above the abyssal plains;
• hadopelagic: 6,000–11,000 m, the water inside ocean trenches.

The benthic scheme describes the seafloor itself: the habitat an organism lives on or a sample is taken from. ENE-040 §4 organises its environmental descriptions this way: the bathyal zone (200–4,000 m, the continental slope and rise), the abyssal zone (4,000–6,000 m, the great sediment plains) and the hadal zone (6,000–11,000 m, the trenches).

The two schemes coexist because they answer different questions. A CTD cast that measures temperature at 2,500 m over a 5,000 m-deep plain is in bathypelagic water, but nothing about it is bathyal, because the seafloor is 2,500 m further down. A sea cucumber collected on that plain is an abyssal organism, and saying it came from abyssopelagic water would be wrong: it was on the bottom, not in the water column. Water-column data wants the pelagic label; seafloor observations and samples want the benthic label. Where the seafloor is shallow, the two can disagree for the same depth number.

Why the depthZone field must say which scheme it uses

The specification itself shows why this matters. The organism-observation example in ENE-040 §12.3 contains "depthZone": "hadal", a benthic term, and §13 shows a records query with ?depthZone=hadal. Yet the SDK's DepthZone type only accepts pelagic values, so the correct SDK value for the same record would be hadopelagic. A strictly typed client will reject the spec's own example, and a server that indexes one vocabulary will return nothing for a query in the other.

Until a revision resolves this, implementers should make the scheme explicit. The simplest compatible approach is to keep depthZone as a string and add a sibling field that names the scheme. The layout below is this book's recommendation, not a normative part of v1.0:

{
  "location": {
    "latitude": 11.3750,
    "longitude": 142.5920,
    "depth": 8340,
    "depthZone": "hadal",
    "depthZoneScheme": "benthic"
  }
}

A validator can then check that the value belongs to the declared scheme: mesopelagic | bathypelagic | abyssopelagic | hadopelagic for pelagic, and bathyal | abyssal | hadal for benthic. It can also derive the pelagic label from the depth alone. The benthic label cannot be derived from depth alone, since it also depends on whether the record is on or near the seabed.

One more detail is boundary handling. The specification writes ranges as "200–1,000 m" without saying which zone owns 1,000 m exactly. The SDK uses half-open intervals (depth < 1000 is mesopelagic, 1,000 is bathypelagic), and that is the convention this book follows: each zone includes its shallower boundary and excludes its deeper one. Note also that §3.1 of the specification gives "abyssal plain" as 3,000–6,000 m, which does not match the 4,000 m boundary in §2.1 and §4. §3.1 is a glossary of landforms rather than a zoning table, so the §2.1/§4 boundaries should be used for classification.

1.2 Hydrostatic Pressure, Done Correctly

The formula

The pressure at depth h in a fluid of density ρ is the atmospheric pressure at the surface plus the weight of the water column above:

P(h) = Patm + ρ · g · h

With P_atm = 101,325 Pa (one standard atmosphere), a typical seawater density ρ ≈ 1,025 kg/m³ and standard gravity g = 9.80665 m/s², the term ρg is about 10,052 Pa per metre. One bar is 100,000 Pa, so every metre of seawater adds about 0.1005 bar. This gives the familiar rule of thumb: about one bar per ten metres, plus roughly one bar of atmosphere at the surface.

Two units dominate deep-sea data. Engineers use bar or MPa (1 MPa = 10 bar). Oceanographers use decibar (1 dbar = 0.1 bar), and conventionally report sea pressure, which excludes the atmosphere. The decibar is popular because a sea pressure in dbar is numerically close to depth in metres. Phase 1 messages carry pressure in bar. As later chapters show, integration with repositories that expect dbar requires a factor-of-ten conversion and a clear statement of whether the atmosphere is included.

Worked example: 3,547 m

The Phase 1 sample messages place their vehicle at a depth of 3,547.2 m. At 3,547 m:

• gauge (sea) pressure = 1,025 × 9.80665 × 3,547 ≈ 35.65 MPa ≈ 356.5 bar ≈ 3,565 dbar;
• absolute pressure = 356.5 + 1.013 ≈ 357.6 bar ≈ 35.8 MPa.

At that depth every square centimetre of hull carries a load of about 365 kgf, which puts tens of tonnes on a patch the size of a palm. That load drives the engineering of every housing, connector and penetrator, and it is why a pressure sensor's calibration date matters as much as its reading.

The sample message itself reports "pressure": 354.72 bar at 3,547.2 m, a few bar below the formula. Treat the numbers in specification examples as illustrative. A validator that cross-checks pressure against depth should use a tolerance of a few percent rather than expect exact agreement, because real instruments, real density profiles and real latitudes all shift the result.

Where constant density stops being good enough

Seawater is slightly compressible, so its in-situ density increases with depth, and gravity varies with latitude. The constant-density formula therefore underestimates pressure at great depth, by about one percent at abyssal depths and nearly three percent in the deepest trenches. The internationally adopted method is the TEOS-10 equation of seawater, available as the Gibbs SeaWater (GSW) toolbox. Its p_from_z function, which assumes a standard ocean profile, gives these sea pressures:

Depth	Constant ρ = 1,025 kg/m³ (sea pressure)	TEOS-10 p_from_z (sea pressure)	Difference
1,000 m (lat 30°)	1,005 dbar	≈ 1,009 dbar	≈ 0.4 %
4,000 m (lat 30°)	4,021 dbar	≈ 4,066 dbar	≈ 1.1 %
6,000 m (lat 30°)	6,031 dbar	≈ 6,127 dbar	≈ 1.6 %
11,000 m (lat 11°)	11,057 dbar	≈ 11,342 dbar	≈ 2.6 %

For quick checks and alarms, the constant-density formula is fine. For derived data products such as depth computed from a pressure sensor, use TEOS-10 and record in metadata that you did. The last row also reveals a real problem in the Phase 1 range table. It caps pressure at 1,100 bar, but the absolute pressure near 11,000 m is roughly 1,135 bar by TEOS-10. A correctly working pressure sensor at the bottom of the deepest trenches would be flagged OUT_OF_RANGE. Chapter 8 lists this as a proposed erratum. Until then, implementers should treat readings slightly above 1,100 bar from full-ocean-depth vehicles as plausible and route them to review, not discard them.

Pitfall: the specification formula and the SDK helper

Two places in the WIA-ENE-040 material state pressure incorrectly, and neither should be copied.

ENE-040 §9.1 gives P(atm) = 1 + depth/10 and P(bar) = 1 + depth/10 as if atm and bar were the same unit (they differ by 1.3 %). It also gives P(MPa) = depth × 0.1 × ρ × g, which is dimensionally wrong: with ρ = 1,025 and g = 9.81, 1,000 m yields 1,005,525, a number with no meaningful unit. The worked values listed under it (1,000 m ≈ 10.1 MPa, for example) happen to be about right, which is how such errors survive review.

The SDK's calculatePressure() in @wia/ene-040 computes its MPa field as depth × 0.1 × 1025 × 9.81 / 1e6. For 1,000 m that returns about 1.0 MPa, ten times too small; the correct value is about 10.1 MPa. Its atm and bar fields are within one or two percent, so the returned object is internally inconsistent: bar / 10 should equal mpa and does not. Treat this as a known bug. Any code that consumes the mpa field is wrong by an order of magnitude, and a regression test for it belongs in every SDK test suite (Chapter 8).

A corrected helper takes a few lines. It returns absolute pressure in three units plus sea pressure in decibars, so callers cannot confuse gauge and absolute values:

// Hydrostatic pressure with a constant-density approximation.
// Good to roughly 1-3 % at depth; use TEOS-10 (GSW) for data products.
export const P_ATM_PA = 101_325;     // standard atmosphere, Pa
export const RHO_SEAWATER = 1025;    // kg/m^3, typical near-surface value
export const G0 = 9.80665;           // standard gravity, m/s^2

export interface Pressure {
  pa: number;       // absolute, pascals
  bar: number;      // absolute, bar  (1 bar = 1e5 Pa)
  mpa: number;      // absolute, megapascals (always bar / 10)
  seaDbar: number;  // sea (gauge) pressure, decibars, excludes atmosphere
}

export function pressureAt(depthM: number, rho = RHO_SEAWATER, g = G0): Pressure {
  if (!Number.isFinite(depthM) || depthM < 0) {
    throw new RangeError(`depth must be a non-negative number of metres, got ${depthM}`);
  }
  const gaugePa = rho * g * depthM;
  const pa = P_ATM_PA + gaugePa;
  return { pa, bar: pa / 1e5, mpa: pa / 1e6, seaDbar: gaugePa / 1e4 };
}

// pressureAt(1000).mpa  -> about 10.15   (SDK calculatePressure(1000).mpa -> about 1.01)
// pressureAt(3547).bar  -> about 357.6

Zone summary

The table below brings the zoning, pressure and temperature together. Pressures are absolute and computed at each zone's deeper boundary with the constant-density formula; temperatures are typical open-ocean values and vary by region.

Pelagic zone (benthic)	Depth	Pressure at deeper boundary	Typical temperature	Typical platforms
Mesopelagic (upper bathyal)	200–1,000 m	≈ 101 bar / 10.1 MPa	falls steeply through the thermocline; region-dependent	ROV, AUV, CTD casts, gliders
Bathypelagic (bathyal)	1,000–4,000 m	≈ 403 bar / 40.3 MPa	a few °C	ROV, HOV, AUV, landers
Abyssopelagic (abyssal)	4,000–6,000 m	≈ 604 bar / 60.4 MPa	about 2–4 °C	6,000–6,500 m-class HOV, ROV and AUV; landers
Hadopelagic (hadal)	6,000–11,000 m	≈ 1,107 bar / 110.7 MPa (≈ 1,135 bar by TEOS-10)	about 1–4 °C, rising slightly with depth	full-ocean-depth HOV, landers, a few ROVs

1.3 Temperature, Light and Chemistry as a Validation Envelope

A validator needs to know what values are physically possible, not just typical. The deep sea is remarkably uniform in most places and remarkably extreme in a few, and the Phase 1 range table has to cover both.

Temperature

Below the thermocline, open-ocean water is cold almost everywhere: deep and abyssal water sits at roughly 2–4 °C. In trenches the in-situ temperature rises slightly with depth, because the water is compressed adiabatically, not because of any heat source. Polar deep water can be below 0 °C, and seawater of normal salinity freezes at about −1.9 °C. The lower bound of the Phase 1 range, −2 °C, therefore sits just below the coldest liquid seawater.

The upper bound comes from hydrothermal vents. Fluids from high-temperature "black smoker" chimneys are commonly measured at 300–400 °C; they stay liquid only because the pressure at depth raises the boiling point far above 100 °C. That is why Phase 1 allows up to 400 °C. The hottest vent fluids reported in the literature are at or slightly above that limit, so a probe reading marginally above 400 °C should be flagged OUT_OF_RANGE and reviewed rather than thrown away. The design lesson is that the range table is an envelope for all measurement sources, so it is much wider than any single sensor ever sees. Per-sensor sanity limits, such as a CTD that should never read 350 °C, belong in instrument metadata, not in the global range table.

Light

Useful sunlight for photosynthesis fades out around 200 m. By about 1,000 m no sunlight is detectable at all. Below that, the only light is bioluminescence and whatever the vehicle brings. For data design this has two consequences. Every image in the archive was taken under artificial lighting, so lighting configuration and camera settings are part of an image's provenance. And colour in deep-sea imagery depends on the lights and the water path, so colour-based identification needs the metadata to be interpretable.

Chemistry

Open-ocean salinity is close to 35 on the Practical Salinity Scale (reported as "PSU" in Phase 1) and varies only slightly in deep water. The Phase 1 range of 0–50 PSU is generous so that it can also accept brine pools and diluted vent or coastal water. Dissolved oxygen varies much more: mesopelagic oxygen minimum zones can approach zero, which is why the Phase 1 range for dissolved oxygen starts at 0 mg/L. pH in open deep water sits slightly below 8, but vent fluids are very different. Black-smoker fluids are strongly acidic, while serpentinite-hosted systems of the Lost City type produce strongly alkaline fluids. The full 0–14 pH range in Phase 1 is justified by those end-members.

Taken together, the ranges in the Phase 1 validation table (depth 0–11,000 m, temperature −2 to 400 °C, pressure 0–1,100 bar, salinity 0–50 PSU, pH 0–14, dissolved oxygen 0–20 mg/L) are best read as "physically possible anywhere this standard applies". A reading inside them can still be wrong for its context, and a reading just outside, such as the hadal pressure case above, can still be right. That is why the specification asks for a quality flag rather than rejection.

1.4 Platform Taxonomy

The SDK's SubmersibleType enum defines five platform classes: hov, rov, auv, lander and crawler. They differ in two ways that matter for data. The first is how they are powered and connected, which decides whether data arrives in real time or only after recovery. The second is what they can do on the bottom, which decides what kinds of record they produce.

SubmersibleType	Link to surface	Power and endurance	Main data produced	Representative vehicles (rated depth)
hov — human-occupied vehicle	acoustic only (voice, text, low-rate telemetry)	on-board batteries; a single working day per dive	video and stills, observer notes, samples, CTD	Alvin (6,500 m); Shinkai 6500 (6,500 m); Jiaolong (7,000 m); Fendouzhe and Limiting Factor (full ocean depth)
rov — remotely operated vehicle	tether, usually with optical fibre	power from the ship; limited by ship time and crew, not batteries	continuous HD video, real-time sensor streams, samples, telemetry	Jason (6,500 m); work-class ROVs commonly rated to several thousand metres
auv — autonomous underwater vehicle	acoustic while submerged; satellite at the surface	batteries; mission length set by the energy budget	multibeam bathymetry, side-scan, sub-bottom, magnetics, CTD, photo transects	Sentry (6,000 m)
lander	acoustic release and transponder only	batteries; the spec cites hours-to-days short deployments and multi-month long ones	time-lapse imagery, baited-camera counts, trap samples, CTD/DO/current time series	built to the target depth, including hadal
crawler — benthic crawler	cable to a seafloor observatory, or none	observatory power or batteries; long-term	long seafloor time series at one site	usually purpose-built for one observatory

All depths in the table are rated depths, meaning the depth the vehicle is designed and certified for, not a claim about any particular dive. Records of the deepest dives vary between sources by tens of metres and are a poor basis for validation limits.

Human-occupied vehicles

An HOV carries a pilot and one or two observers inside a pressure sphere, typically titanium, with thick acrylic viewports. Its data is shaped by the fact that humans are aboard. Dives are short (a day at most), the vehicle must surface before the crew's life support runs down, and nothing reaches the ship except over an acoustic link. Most of an HOV's science data therefore arrives in bulk at recovery. What the ship receives in real time is a thin stream of position and status.

Remotely operated vehicles

A work-class ROV is connected to the ship by a tether (often through a depressor or tether management system), and the tether carries power down and data up over optical fibre. That makes the ROV the only deep platform with a high-bandwidth, real-time link, and the Phase 1 VEHICLE_TELEMETRY example accordingly shows "fiber": "CONNECTED" with a separate acoustic backup on standby. The fibre's propagation delay is negligible (light covers ten kilometres of fibre in about 50 µs), so any latency an operator experiences comes from video encoding, processing and networking on the ship, not from depth. The ENE-040 §5.2.1 figure of a depth-dependent tether latency should not be used as a design input.

Autonomous underwater vehicles

An AUV follows a pre-planned mission, often a "lawn-mower" pattern of parallel survey lines, flying at a fixed altitude above the seabed. Because it can fly close to the bottom, it can map in far more detail than a ship-mounted sonar. Because it is untethered, it reports only occasional status acoustically, and its full data set exists only after recovery. The data-design consequence is that AUV records arrive late and in large batches, and their timestamps depend on a clock that has been isolated from GPS for the whole mission. That is the case Phase 1 §3.3 covers when it requires time drift to be documented.

Landers and crawlers

A lander is dropped from the surface and free-falls to the seabed, where it records for hours to months, then releases ballast on an acoustic command and floats back up. Landers are the workhorses of hadal science because they are simple and can be built for any depth. A benthic crawler is a tracked or wheeled vehicle that moves slowly around a seafloor site, usually connected to a cabled observatory. Both produce long time series from one place, which is a different data shape from a dive's track through space. The Chapter 4 record model has to accommodate both.

1.5 The Sensor Suite as a Set of Data Sources

The SDK's ROVSensorSuite interface groups a vehicle's sensors into navigation, imaging, environmental and sonar blocks. For an implementer the useful question is not what each sensor is but which field of which Phase 1 message it fills. The table maps them.

Sensor	What it measures	Phase 1 destination	Implementation note
CTD — conductivity cell	electrical conductivity	environment.salinity (PSU)	salinity is computed from conductivity, temperature and pressure; record the algorithm
CTD — thermistor	temperature	environment.temperature	the time constant matters on fast descents
CTD / vehicle pressure sensor	pressure	environment.pressure (bar); location.depth	depth is derived from pressure, not measured
Oxygen sensor (DO)	dissolved oxygen	environment.dissolvedOxygen (mg/L)	optodes need temperature and salinity compensation
pH sensor	pH	environment.pH	state the pH scale used in metadata
ORP sensor	oxidation-reduction potential	no Phase 1 key	carry it as an extension using the same value/unit/sensorId/calibrationDate shape
Turbidity (optical backscatter)	particle load	environment.turbidity (NTU)	useful for detecting vent plumes
Sound velocity probe	speed of sound	environment.soundVelocity (m/s)	also feeds the sound velocity profile referenced by bathymetry
DVL	velocity over ground; altitude	location.altitude; telemetry position.altitude	bounds INS drift when within bottom-lock range
USBL	range and bearing from the ship	location.latitude/longitude, accuracy.horizontal	error grows with slant range; report accuracy per fix
INS	attitude and dead-reckoned position	telemetry heading, pitch, roll; blended position	the navigation solution fuses INS, DVL, USBL and depth
Cameras with laser scaler	images; scale reference	archive imagery/; specimen.photographs	parallel lasers at a known spacing give organism size
Multibeam echosounder	seafloor depth and backscatter	BATHYMETRIC_DATA soundings[]	see section 1.7
Side-scan sonar, sub-bottom profiler	seafloor imagery; sediment layers	sonarConfiguration; files in the mission archive	no per-ping message type in Phase 1

Three observations from this mapping shape later chapters. First, depth is a derived value. A pressure sensor measures pressure; depth comes from pressure through a density model and latitude, as section 1.2 showed. A depth field without its method is ambiguous at the level of tens of metres in the hadal zone. The accuracy of the sensor itself also scales with its range: a sensor with 0.01 % full-scale accuracy (the specification's example), rated for full ocean depth, has an error band on the order of a metre.

Second, position is a fused estimate, not a measurement. No single sensor tells a vehicle where it is at 4,000 m. The USBL gives a noisy fix whose error grows with distance from the ship, the INS gives a smooth track that drifts, and the DVL restrains that drift while the vehicle is close enough to the bottom to track it. That is why Phase 1 carries accuracy.horizontal and accuracy.vertical with every location, and why those values must be computed per fix rather than copied from a datasheet.

Third, every value has a lineage. Phase 1 wraps each environmental value in an object with value, unit, sensorId and calibrationDate. Deep-sea sensors drift under pressure and temperature cycling, and a data manager checking a suspicious reading months later needs to know which instrument produced it and when it was last calibrated. Chapter 3 treats this structure in detail.

1.6 Underwater Acoustics: The Physics Behind Every Link

Radio does not work, so sound does

Seawater conducts electricity, and radio waves in a conductor die away within a characteristic distance called the skin depth. For seawater with a conductivity of about 4 S/m the skin depth is only about 2.5 m at 10 kHz and about 0.25 m at 1 MHz. Higher frequencies are worse. Wi-Fi, cellular and satellite links are therefore useless below the surface. Light travels further but is scattered and absorbed within tens of metres, and it needs a clear line of sight. Sound is the only signal that crosses kilometres of seawater, which is why every untethered deep-sea link is an acoustic modem.

Latency: seconds, not milliseconds

Sound travels at roughly 1,500 m/s in seawater (the exact value depends on temperature, salinity and pressure, typically within about 1,450–1,550 m/s; the Phase 1 example reports 1,489.3 m/s). That is five orders of magnitude slower than radio, and it turns physical distance directly into latency:

Vertical distance	One-way travel time	Round trip (command + acknowledgement)
1,000 m	≈ 0.7 s	≈ 1.3 s
4,000 m	≈ 2.7 s	≈ 5.3 s
6,000 m	≈ 4.0 s	≈ 8.0 s
11,000 m	≈ 7.3 s	≈ 14.7 s

These are lower bounds for a straight vertical path. Horizontal offsets, ray bending and modem processing all add to them. Any protocol that waits for an acknowledgement before sending the next packet spends most of its time waiting. That is why the Phase 3 stack (Chapter 6) uses selective-repeat and hybrid ARQ, and why its timers are measured in seconds.

Absorption: the range–bandwidth trade-off

Sound loses energy in two ways. Spreading loss is geometric and independent of frequency: under spherical spreading, intensity falls as 20 log₁₀ r decibels with range r in metres. Absorption converts sound to heat through viscosity and chemical relaxation in seawater, and it rises steeply with frequency. A widely used empirical approximation is Thorp's formula, which gives the absorption coefficient in dB/km for frequency f in kHz:

α(f) ≈ 0.11 f²/(1+f²) + 44 f²/(4100+f²) + 2.75×10⁻⁴ f² + 0.003

Frequency	Absorption (Thorp, approx.)	Absorption over 10 km
1 kHz	≈ 0.07 dB/km	≈ 0.7 dB
3 kHz	≈ 0.2 dB/km	≈ 2 dB
8 kHz	≈ 0.8 dB/km	≈ 8 dB
16 kHz	≈ 2.8 dB/km	≈ 28 dB
30 kHz	≈ 8.3 dB/km	≈ 83 dB

A first-order link budget shows what that means. The received level is the source level minus transmission loss: RL = SL − (20 log₁₀ r + α · r/1000). Take the Phase 3 maximum source level of 190 dB re 1 µPa at 1 m and a range of 5 km, so spherical spreading costs 20 log₁₀ 5,000 ≈ 74 dB. At 3 kHz, absorption adds about 1 dB and the received level is about 115 dB. At 30 kHz it adds about 41 dB and the received level falls to about 75 dB, a 40 dB (ten-thousand-fold) difference for the same transmitter. The receiver needs the signal to exceed the ambient noise in its band by a working margin. Noise depends on sea state, shipping and the vehicle itself, so it is not given here. But the direction is clear: long range needs low frequency, and low frequency means little bandwidth, because the usable bandwidth of a modem is roughly a fraction of its centre frequency.

This is the reason the Phase 3 band plan (Chapter 6) pairs its lowest band, 1–3 kHz, with ranges of 10–20 km and rates of hundreds of bits per second, and its highest band, 16–30 kHz, with ranges under a kilometre and tens of kilobits per second. The model here is deliberately simple. Real channels add multipath from the surface and seabed, Doppler shift from moving vehicles and refraction from the sound-speed profile, and all of these reduce the achievable rate below what the loss budget alone suggests.

The fibre-optic exception

The only way to get video-grade bandwidth from the deep sea is to run a cable. ROV tethers and seafloor observatory cables carry optical fibre, and with it bandwidth that is many orders of magnitude above any acoustic link. The price is the tether itself: its drag, the handling system and the ship that must stay above the vehicle. For data design the rule is to assume the acoustic case. A message format and a protocol that work over a few hundred bits per second with seconds of latency will also work over fibre, but the reverse is not true. Phase 1's optional binary encoding and Phase 3's entire stack exist because of this asymmetry.

1.7 Multibeam Echosounding

From a ping to a depth

A multibeam echosounder transmits a short pulse and listens for its echo on many narrow receive beams at once, arranged as a fan across the vehicle's track (ENE-040 §6.1 cites fans of 100–500 beams). For each beam the system measures the two-way travel time t of the echo. In a uniform sound-speed ocean the slant range would be c·t/2, and for a beam at angle θ from vertical the depth would be (c·t/2)·cos θ. The nadir beam in 3,547 m of water returns after about 2 × 3,547 / 1,500 ≈ 4.7 s. Outer beams take longer.

That travel time sets the ping rate. A ship-mounted system in 4,000 m of water cannot send the next ping until the outer-beam echoes of the previous one have returned, which takes more than 5 s. At a survey speed of 4 m/s the ship moves more than 20 m between pings (an illustrative figure), so along-track sounding density is limited by physics, not by the sonar's electronics.

Ray tracing and the sound velocity profile

The ocean is not uniform. Sound speed changes with depth, and a sound ray bends as it crosses layers, following Snell's law: along a ray, sin θ / c stays constant. To turn travel time and launch angle into a seabed position, the processing software traces each ray through a sound velocity profile (SVP), usually measured by a CTD or sound-velocity cast. If the SVP is wrong, the outer beams land at the wrong depth and the swath curves upward or downward at its edges, a familiar artefact in uncorrected surveys. That is why the Phase 1 BATHYMETRIC_DATA message names the SVP it used (processingParameters.soundVelocityProfile) and the ray-tracing method ("rayTracing": "SNELL"). Without them a sounding cannot be reprocessed or audited. Vehicle attitude from the INS (heave, pitch, roll) and a tide correction to a vertical datum complete the chain.

Backscatter

Besides timing, each echo has a strength. Hard, rough surfaces such as fresh lava or rock reflect more sound back towards the sonar than soft mud. A mosaic of this backscatter is a map of seabed character and is the basis for sediment classification. Phase 1 soundings carry an intensity value, but the specification example ("intensity": 142) gives no unit. Implementers should record whether it is a calibrated level in dB or a raw instrument count, because two surveys cannot be compared otherwise.

Frequency, depth and resolution

The same absorption physics from section 1.6 governs sonar choice. ENE-040 §6.1.2 gives the following typical values:

Frequency	Maximum depth (spec)	Resolution (spec)	Typical use (spec)	Why
12 kHz	11,000 m	low (50–100 m)	full-ocean-depth mapping	low absorption lets echoes return from trench floors
30 kHz	5,000 m	medium (20–50 m)	abyssal plains	a compromise between range and detail
100 kHz	1,000 m	high (1–5 m)	continental shelf, detailed survey	absorption limits range to about a kilometre
400 kHz	200 m	very high (<1 m)	shallow water, structures	very high absorption; very short range

Resolution here depends as much on distance as on frequency. A beam 1° wide illuminates a patch of seabed roughly D · tan 1° ≈ 0.017 D across at nadir, where D is the range to the seabed. From a ship over 4,000 m of water that is about 70 m, which matches the "low" resolution of deep-water systems. An AUV flying 50–100 m above the seabed, as in the ENE-040 §5.3.2 mission profile, sees the same 1° beam cover about 1–2 m, whatever the water depth. That is why the specification equips AUVs with 100–400 kHz sonars even for deep work: the vehicle brings the sonar close enough for high frequencies to reach. For data design this means a survey's resolution is a property of the platform-and-altitude combination, not of the sonar alone. The gridResolution declared in a BATHYMETRIC_DATA message should be justified by the footprint, not by the datasheet.

Side-scan sonar and sub-bottom profilers complete the acoustic toolkit. Side-scan builds high-resolution images of the seabed to either side of the track but does not measure depth accurately. Sub-bottom profilers use low frequencies (ENE-040 §6.3 cites 2–15 kHz) so that sound penetrates the sediment and returns echoes from buried layers. Both produce image-like products that Phase 1 carries as archive files rather than as individual soundings.