Logging test data on the water means capturing every sensor reading and manual observation during a boat-based sea trial with a reliable time, position, method, and instrument record attached to it. This guide is about marine field testing: ocean robots, moored buoys, drifters, and handheld sensors run from a working boat. It is not about pool water chemistry or drinking-water quality testing.
The whole method comes down to one idea: a number without a timestamp, a position, and a note about conditions is not data yet. It is a reading that happened somewhere at some point, which is nearly useless once the boat is back at the dock and someone asks where the minimum occurred.
Plan for about an hour of setup and checks per platform, and expect the post-run verification to take as long as the run itself did. Most teams that skip it are the ones discovering a three-hour gap in their series a week later.
Table of Contents
- What You Need
- Step-by-Step: How to Log Test Data on the Water
- Common Mistakes
- Frequently Asked Questions
- Can I use a smartphone to log marine test data?
- What sample rate should I use for water-based sensor testing?
- Do I need paper notes if the onboard logger records everything?
- How should I handle GPS loss during a boat or ocean robot test?
- What should I do if a sensor fails while the mission is running?
- How can I tell whether a complete data file was recovered?
- Conclusion
What You Need
A logging setup that survives a wet deck needs redundancy built in, not one clever box doing five jobs. Gather these before the boat leaves the slip.
- A primary data logger with a sample interval you have set deliberately, not left at a factory default.
- An independent backup recorder. A second logger writing the same channels to its own storage, or a phone app on a separate device. If your only record lives on the computer that also runs the mission controller, you have no backup.
- An accurate clock source. Ideally GNSS time from the GPS receiver, falling back to a disciplined onboard computer clock. Set everything to UTC.
- A GPS source that logs a fix alongside each reading, not just position in a separate file you have to join later.
- A power supply sized for the full planned duration, with headroom for the worst case rather than the average case.
- A waterproof field log sheet, printed or in a downloadable form, for weather, sea state, and events.
- A tested file-naming convention, written down and agreed before anyone is standing in spray holding a laptop.
On documentation, one page is enough. Deployment ID, date, platform, operator names, sensor list with serial numbers, and calibration offsets currently in use. That page travels with the data, not in someone’s inbox.
Step-by-Step: How to Log Test Data on the Water
Prepare the Logging System
Set up the logging software on shore, not in the boat. Create a folder structure for the deployment before you insert any card: a raw folder for untouched logger output, a processed folder for derived data, and a metadata folder holding the log sheet and deployment page.
Set the sample interval from the phenomenon you are measuring, not from what the sensor can do. A surface temperature probe might be fine at one sample per minute; a short-period wave or vehicle motion measurement needs seconds. Reserve timestamp space so that a row with a fix and a row without one still align when you load the file.
Assign a deployment ID now. A short code like saildrift-run03 is enough, as long as it is unique and it appears in every filename, every log sheet, and every photograph you take that day.
Finally, confirm the system starts recording on its own when powered. Relying on someone remembering to hit start is how runs get lost.
Synchronize Time and Position
Align every clock on the system to UTC before the sensors go in the water. The logger, the mission computer, the GPS receiver, and any camera with a timestamp all need to agree.
Run a short synchronization check: note the time on each device within the same minute, then compare. GPS-disciplined receivers usually hold UTC to a fraction of a second. A cheap standalone board with no time discipline can drift noticeably in an afternoon, and drift of a few seconds is enough to misalign a fast-moving platform with a manual note.
Write down the offset you measured. If a device is 400 milliseconds fast, that is a fact about the run worth having in the metadata, not something to quietly correct later. Also check the time zone and daylight-saving setting on any device that displays local time, since a phone left on local time will quietly disagree with a UTC logger for half the year.
Connect and Verify Every Sensor
Wire the sensors with power off. Check polarity twice, confirm grounding follows the manufacturer’s arrangement, and fit strain relief so a chafed cable cannot become a flooded one.
Weatherproof connectors properly: seated fully, with the sealing O-ring clean and lightly greased if the manual says to grease it. Salt spray finds every unseated face, and a connector that sprays through a few hours into a run takes the whole channel with it.
Label each channel with what it actually measures, its units, and its range. The label should be written where you can read it on a moving deck. Then walk the channel list with the operator so everyone knows which wire is which before the first deployment rather than after a puzzling plot.
Run a Dry Test Before Deployment
Do a controlled rehearsal on the dock with the platform out of the water. Move it in known ways: tilt, rotate, and lower it a known distance, so later you can check that the recorded values match something you did on purpose.
Confirm four things. Files are being created, timestamps advance at the expected spacing, GPS fixes appear on the rows that should have them, and alarms or low-storage warnings actually fire. Test the alarm by filling the card or pulling the antenna rather than by trusting the default configuration.
If a channel is stuck, the reason is usually wiring, grounding, or a unit mismatch caught right now in five minutes rather than after a full run.
Create a Deployment Log Sheet
Print one page per deployment and keep it in a waterproof sleeve. It is the record that survives a dead battery, a flooded housing, or a laptop that never made it back to the dock.
The sheet should carry the deployment ID and date, start and end positions, operator names, sea state and wind, and air and water temperature. Add running notes for battery voltage, power state, and any change of operator or instrument mid-run. Reserve space for unusual events and for photographs, with a column to record the file name of each photo.
Also put on it the thresholds that mean stop: minimum battery voltage, maximum allowable sea state, and the point at which a leak triggers recovery. Deciding those on a calm deck is far better than deciding them in a swell.
How to Log Test Data on the Water Without Disturbing the Sensors
Check the system at fixed intervals rather than constantly. Ten minutes for a short run, thirty for a long one, and write the check time on the log sheet. At each check, look at battery state, remaining storage, GPS fix quality, and whether data is still flowing.
Read from the display, do not open the housing. Every time you break a seal you add a failure point, and on a moving deck the odds of a dry reassembly drop fast.
Know when to intervene and when to leave it alone. If a reading looks wrong but the platform is where it should be and the data is still flowing, note the observation and keep running; a restart destroys the record around the fault and often fixes nothing. Intervene when there is a real hazard, water inside the housing, or a platform that has to be recovered.
Mark Events and Record Context
Use one event note format for the whole trip: UTC time, what happened, and the position. A note that reads 1421Z course change to 090, wake from survey boat is far more useful later than a scribbled arrow on a chart.
Log the events that change the meaning of the data: course changes, wave encounters, a suspected leak, a sensor that stops responding, a battery change, animals seen near the platform, and any manual sample you collect. The BGC-Argo practice of taking validation water samples during deployment is a good model, since the sample is what later tells you whether the sensor was telling the truth.
For manual spot readings, write down the value, its units, the GPS position, the time in the same format the logger uses, and the method. A reading with those five fields attached is defensible. A number on a scrap of paper is not.
Back Up and Verify the Data After Recovery
Stop logging in a controlled way once the platform is aboard, then leave the original files untouched. Copy them to two separate locations before you open anything: a working drive and a different physical place. Salt, sun, and a wet deck do not care about your backup plan.
Verify the copies rather than assuming them. Compare file counts and total sizes between the source and both copies, and open one file from each to confirm the rows are readable. Then spot-check the series: look for gaps, values frozen at the last reading, timestamps that jump or repeat, and a final sample interval that differs from the configured one.
Write up what you found before the detail fades. Note any gaps with their start and end times, any suspicious values, and the state of the housing, desiccant, and connectors on recovery. Do not edit the raw files. Corrections belong in a separate processed set with a written record of what changed and why, which is the whole point of keeping the raw data intact.
Common Mistakes
Almost every lost sea trial comes from one of a short list of causes, and all of them are cheap to prevent.
Unsynchronized clocks. Two devices whose clocks disagree by a few seconds make it impossible to line up an automated series with a manual note. Sync to UTC at the dock and record the offsets you measured.
No deployment ID. Files named final2.csv are useless a year later. Use the naming scheme before the first run, not after the fourth.
Unverified sample rate. A default of one sample per second on a slow-changing channel wastes storage; one per minute on a fast event throws the event away. Set it from the phenomenon.
A full storage card. Check free space at every pre-cruise checklist, and treat a low-storage alarm as a reason to return, not a warning to acknowledge.
Loose or unseated connectors. Water and salt in connectors is a routine cause of lost channels. Seat, seal, and strain-relieve every one, and look at them again after recovery.
Undocumented manual events. If something happened on deck and it is not on the log sheet, it did not happen as far as the dataset is concerned.
Restarting after a fault. A restart clears the evidence around the failure. Log it, note it, and only restart when the run is genuinely unrecoverable.
Keeping one copy. One copy is a plan, not a backup. Two copies in two places, verified by file count and size.
Two habits improve reliability more than any other. Run a reference instrument alongside a new sensor for at least one deployment, so you have a known-good series to compare against. And treat fouling and sensor drift as expected rather than exceptional: check a clean-water reference reading at the start and end of each run, and record the difference.
Frequently Asked Questions
Can I use a smartphone to log marine test data?
Yes, as a backup rather than the primary record. A phone gives you an independent clock, a camera with a timestamp, and a GPS position for every photo of the instrument display, which is genuinely strong evidence. It also dies, gets wet, and runs out of battery at the worst moment. Run the phone in parallel with the primary logger so that when one fails you still have a defensible record.
What sample rate should I use for water-based sensor testing?
Set the interval from the fastest thing you need to see, not from what the sensor can do. Temperature and salinity usually need one sample per minute or slower. Wave, motion, or vibration signals need seconds. Doubling the rate doubles storage and power, which matters on a multi-day deployment, so choose the rate the phenomenon requires and log what you chose in the metadata.
Do I need paper notes if the onboard logger records everything?
Keep them anyway. A waterproof log sheet is the record that survives a flooded housing, a dead battery, or a laptop left on the dock, and it captures the context no sensor measures: sea state, who was operating, what went wrong, why a run was stopped. Write notes during the run, not from memory after it. The logger gives you numbers; the sheet tells you whether the numbers mean anything.
How should I handle GPS loss during a boat or ocean robot test?
Log the loss as an event rather than filling in the blanks afterwards. Record the time it started and stopped, and note whether the platform was in sight, in a wave shadow, or under structure. Dead-reckon from the last good fix and the platform’s own heading log, and mark the interpolated positions as interpolated in the dataset. Never quietly carry the last fix forward, because that invents data you did not measure.
What should I do if a sensor fails while the mission is running?
Note the time, the channel, and what the reading was doing, then decide based on the risk. If the platform is safe and the remaining data is useful, log the failure and keep running, because the rest of the series still has value. Recover the platform if there is a leak, a power problem, or a hazard to the boat. Either way, photograph the instrument display at the moment of failure and write it on the log sheet before you pack up.
How can I tell whether a complete data file was recovered?
Compare file counts and total sizes between the source card and both backup copies, then open one file from each. Check that timestamps advance at the configured interval, that GPS fixes appear on rows that should have them, and that the last sample time is close to the recorded recovery time. A file that is short, ends hours early, or freezes on one value is a partial recovery, and you should say so in the write-up.
Conclusion
Start with a one-page logging checklist for your next deployment: deployment ID, sample rate, channel list, clock offsets, and the stop thresholds. Build it, test it on the dock, and run the dry test until every one of those lines has a value against it.
Then keep both records, the machine file and the written field context, in two verified backups. That is the whole practice. Everything else is detail, and this update for 2026 reflects what the standard ocean-observing guidance, from NOAA quality-control work to observatory data management plans, has said for years about data you cannot defend.
