From Sensor Stream to Shore: Engineering a Store-and-Forward Coastal Buoy

The hard part was not putting a hydrophone in a buoy.

It was preserving a high-bandwidth raw record while power, connectivity, stability, waterproofing and field handling all competed for the same limited platform.

Our UCL MEng final-design team began with an inherited passive instrument carrier and a £2,500 hardware budget. By the end of the project, it had become a working coastal-monitoring prototype with underwater acoustics, motion, water temperature, GNSS, local solid-state storage and a live 4G/LTE dashboard.

The prototype worked in the sense that matters for a first engineering iteration: it acquired data, stored the full record, reported its state remotely and survived a supervised saltwater deployment. It also failed in specific, measurable ways. It did not meet the original fourteen-day endurance target. Its analogue acoustic gain was too low for quiet deep-sea ambient noise. Its IMU recovered dominant wave frequency but not calibrated wave height. Its flat upper geometry could remain stable when fully inverted.

Those limitations are not footnotes to the project. They are the clearest description of what the next design must solve.

This article explains the system as an engineering argument: how the requirements forced the architecture, how the architecture coupled the disciplines, and what the verification sequence actually established.

1. The system requirement was a recoverable measurement

A coastal sensor is useful only when the measurement survives the deployment.

That statement sounds obvious, but it changes the design priority. A live dashboard is attractive because it makes a prototype visible. It is not the primary data path when connectivity is intermittent and one channel produces tens of gigabytes per day.

The hydrophone was configured through a HiFiBerry DAC+ADC Pro at 96 kHz and 32-bit stereo. The source was mono, so this was not an efficient final format, but it made the architectural constraint clear: acoustic data dominated the storage and transmission problem.

The design therefore separated two products:

scientific record meant the complete raw files retained on board; operational awareness meant the selected health, position and summary messages sent to shore.

This is a store-and-forward architecture.

The Samsung T9 SSD held the raw acoustic and IMU records. The LTE link carried GNSS, battery state, file acknowledgements, sensor status and selected summaries. A network outage could delay visibility without deleting the measurement.

That choice also made post-recovery audit possible. A file manifest could answer whether a recording existed, when it began, when it ended and whether the shore service had acknowledged it. The architecture was therefore not merely about throughput. It was about evidence.

The US IOOS passive-acoustics quality-control guidance treats deployment configuration, metadata, continuity and instrument state as part of the observation rather than as administration around it. The same principle applies here: a waveform without timing, configuration and health context is a weaker scientific record.

2. Four requirements forced a split compute architecture

Four requirements governed the electronics:

1. continuous acquisition of the configured acoustic stream;
2. retention of the complete raw archive;
3. live remote monitoring during a coastal deployment;
4. deterministic low-rate acquisition for motion and environmental channels.

No single device was ideal for all four.

A microcontroller offered deterministic timing and low power, but not the managed filesystem, USB storage, Linux networking and dashboard services required for the archive and telemetry path. A Raspberry Pi offered those services, but at a continuous base load of several watts and with less deterministic handling of low-rate sensor acquisition.

The final architecture retained both classes of device.

This division was not theoretically optimal. It was defensible for a first-generation platform because each device performed the work for which its software and interfaces were suited.

The bench results supported that choice. The Raspberry Pi reached a working SSH state in 40 seconds. The IMU logged at about 10 Hz, enough to oversample the intended 0.1–1 Hz wave band. The SSD sustained 226 MB/s against less than 1 MB/s required by the configured stream. Storage bandwidth was not close to the bottleneck.

The more important bottleneck was power.

3. Recording was cheap; staying awake was expensive

The measured 5 V rail averaged 4.38 W at idle and 4.27 W during active recording.

That result initially looks wrong. It is not.

The audio capture and SSD writes used efficient system interfaces and added little processor load relative to the cost of keeping the Raspberry Pi, storage, modem and supporting electronics powered. The energy cost of the mission was therefore dominated by base state, not by whether the hydrophone was writing at that moment.

This changed the endurance problem.

Reducing sample count alone would not deliver an order-of-magnitude improvement. The design needed one or more of:

• genuine low-power states;
• scheduled duty cycling;
• a lower-power compute architecture;
• a larger battery;
• energy harvesting;
• or a different mission profile.

At the measured load, the 120 Wh LiFePO₄ pack supported approximately 23 hours of projected continuous operation once conversion and navigation-light demand were included. The original fourteen-day requirement was therefore not met.

The report explored larger batteries and duty-cycled operation, but the important lesson is systemic. A larger battery adds mass and volume. Mass changes draft, freeboard and handling. Its vertical position changes stability. A solar array adds windage, penetrations and charging electronics. Endurance cannot be repaired without revisiting the mechanical design.

The next iteration should therefore treat energy, hull geometry and deployment handling as one optimisation problem.

4. A free-flooded hull changed what waterproofing meant

The inherited hull was not converted into one sealed pressure vessel.

It was used as a free-flooded protective structure around closed-cell foam and two IP68 enclosures. Water could enter the main shell, while the useful buoyant volumes and electronics remained protected.

This decision avoided relying on a large old hull with multiple penetrations as the only ingress barrier. It also changed the hydrostatic model: trapped air inside the shell could not be counted as reliable buoyancy.

The report’s final mass budget placed the prototype at 23.13 kg without ballast and 35.13 kg with the maximum 12 kg removable ballast. The calculated freeboard remained 19.1 cm and 16.1 cm respectively.

Small-angle stability was strong because of the wide circular waterplane. Calculated metacentric height was 0.386 m unballasted and 0.348 m with maximum ballast, both well above the project’s 0.15 m criterion.

Large-angle behaviour revealed a different problem.

The maximum-ballast configuration remained positively stable to about 133°, compared with 78° unballasted. Ballast therefore made capsize much harder. It did not create self-righting from complete inversion. The flat upper surface produced a second stable equilibrium, so the buoy could remain upside down.

This is a useful distinction:

high resistance to overturning ≠ guaranteed recovery after inversion

The next mechanical revision should remove the stable inverted condition with a domed or curved upper geometry rather than attempting to solve it only by adding more ballast.

5. Verification had to move from components to the sea

A field deployment is a poor place to discover that a modem requires a physical power-key press after a hard reset.

The project therefore used a staged verification ladder.

The bench stage found both margin and risk.

Storage margin was enormous. Temperature accuracy was within 0.1 °C of a reference. GNSS acquired a cold-start 3D fix in 90 seconds. The hydrophone recorded a clean fifteen-minute file without dropouts.

The LTE modem also exposed an unattended-recovery weakness. After complete power loss, the PiTalk/Quectel modem required a physical PWRKEY action to re-register. A transistor or relay driven by a host GPIO was identified as the next fix. The field test did not erase that single point of failure simply because the link worked on the day.

The wave tank then tested the integrated physical system rather than isolated electronics.

6. The IMU result was useful because it was narrow

The IMU was logged at about 10 Hz across one still-water reference and eight regular-wave conditions from 0.55 to 1.70 Hz.

The useful result was dominant-frequency recovery.

The mean error was 4.7%, and every regular-wave point remained within 11% of commanded frequency.

The amplitude-derived result was weaker.

Heave displacement was inferred by double-integrating vertical acceleration. That makes the estimate sensitive to gravity leakage, sensor orientation, noise and drift, especially at low frequencies where true acceleration is small. The response peaked near the predicted heave resonance around 1 Hz and fell at higher frequency, which was physically plausible, but there was no independent local wave-height reference.

The correct conclusion is therefore:

• dominant frequency was recovered well under the tested conditions;
• relative response showed plausible dynamics;
• absolute wave height was not calibrated.

A stronger next experiment would use an external wave gauge or calibrated video reference, six-position accelerometer calibration and orientation-aware gravity removal.

7. The hydrophone test separated integrity from sensitivity

The wave-tank acoustic result is easy to overstate in either direction.

Controlled waves produced no detectable acoustic signature above the self-noise of the recording chain. That was good evidence that the platform’s regular motion was not creating a large false acoustic feature in the tested band.

It did not mean the acoustic system was sufficiently sensitive.

The same analysis showed that the analogue gain was too low to raise quiet deep-sea ambient signals above the digitiser noise floor. The hydrophone could record moderate and event-driven sound, but low-level ambient monitoring remained an open requirement.

The system therefore passed one question and failed another:

• Did regular tank motion contaminate the channel? No detectable evidence under the test.
• Could the chain resolve the quietest intended ambient signals? Not yet.

This distinction is more useful than labelling the hydrophone simply successful or unsuccessful.

8. The Brighton deployment tested the complete information path

The buoy was deployed from a supported small craft at Brighton on 1 May 2026.

The field objective was not a fourteen-day endurance demonstration. It was to verify integrated operation in salt water: deployment and recovery, local acquisition, GNSS, LTE, dashboard state and file acknowledgement.

The system recorded throughout the field window and retained the raw acoustic files locally. The live link reported position, battery and operational status. Across the deployment window, 52 files were acknowledged and none remained pending, reported as 99.9% upload delivery.

The dashboard screenshot also displayed 99.8% packet delivery at one point. Those numbers refer to different scopes and should not be collapsed into one metric.

The field test established that the end-to-end path worked under the tested coastal conditions:

It did not establish offshore communications, long-duration reliability or autonomous fault recovery.

9. What I would redesign first

A second-generation platform should not begin by adding more sensors.

It should close the four limits that determine whether the existing measurements are trustworthy and operationally useful.

Acoustic calibration

Add a low-noise gain stage with known frequency response, preserve headroom for transients and calibrate the complete hydrophone-to-file chain against a reference source.

Motion calibration

Use an independent wave-height reference and orientation-aware processing so the IMU can move from dominant-frequency detection to defensible heave estimation.

Geometry and stability

Replace the flat top with a domed or curved surface and repeat the righting-arm analysis and inversion test. Do not compensate for a poor inverted geometry only by increasing ballast.

Mission energy

Choose the mission profile before the battery. A fourteen-day continuous acoustic mission, a duty-cycled event detector and a short live coastal test are different products. Each should have its own power budget and validation plan.

Communications recovery

Automate modem power-key recovery and add a low-bandwidth satellite channel for position and health outside cellular range. Raw acoustic data should remain local.

10. The real deliverable was a known starting point

The prototype was not the final instrument.

Its value is that the next team does not have to rediscover the architecture, the power profile, the stability limit or the acoustic gain gap.

The handover package contains the report, CAD, manufacturing drawings, bill of materials, wiring, software, test data, risk assessments, deployment procedures and future-work register. That makes the evidence reusable.

A good first prototype does more than demonstrate that something can work once. It identifies which assumptions survived contact with the system and which ones must be removed from the next design.

For this buoy, the surviving architecture is clear:

• preserve raw data locally;
• treat telemetry as operational awareness;
• split deterministic sensing from general-purpose orchestration;
• validate components before integration;
• treat power, mass and stability as one system;
• report partial success without turning it into a product claim.

That is the foundation on which a repeatable coastal acoustic platform can be built.

References