Weighing Data Logging at Sea: What to Record and Why

Why log every weighing

Logging every weighing, automatically and at the moment it happens, turns a scale from a display into a source of evidence: it proves what was packed, supports traceability and reporting, and shows where product is being lost. Manual notes and spot checks cannot do this, because they miss most of the weighings and cannot be audited.

On a fishing vessel a complete weighing log serves several purposes at once:

• Traceability. EU rules require net weight in kilograms per lot as part of the minimum information passed on digitally (Article 58(5) of Regulation (EC) No 1224/2009, as amended by Regulation (EU) 2023/2842).
• Landing records. Operators weighing fishery products at landing must complete a weighing record for each landing and keep it for three years (Article 60(5)).
• Logbook accuracy. Weighed quantities per species help keep logbook estimates within the permitted margin of tolerance.
• Giveaway control. Pack weights per product show average overweight and spread; see Reducing Giveaway.
• Disputes. When a buyer claims short weight, a time-stamped record of each box is the vessel's evidence.

Fields to record per weighing

A useful weighing record contains what was weighed, how much, when, where, by which instrument and under which settings, in a structure that stays identical for every record.

Not every installation needs every field, but record ID, timestamp, instrument, preset, net weight, unit and stability are the minimum for data that can be trusted and reused. Species codes should follow the FAO ASFIS list so that records match logbook and traceability data.

Audit trail: recording what changed

An audit trail is a time-stamped record of events that could influence the measurement, such as parameter changes, calibration and software updates, kept separately from the weighing records themselves.

OIML Document D 31 defines an audit trail as a continuous data file containing a time-stamped information record of events, for example changes in the values of the parameters of a measuring instrument or software updates, that are legally relevant and may influence the metrological characteristics (OIML D 31:2019). Even where a scale is not used under legal metrology, the same principle makes weighing data defensible.

Events worth logging on a vessel:

• calibration and adjustment, with the reference weights used;
• changes to capacity, resolution, filtering or stability settings;
• creation, editing and deletion of presets, including target and tolerance values;
• manual zero and tare operations, and changes of tare values;
• software and firmware updates;
• corrections to records: a correction should create a new entry that references the original, not overwrite it;
• clock changes and time synchronisation events.

The legal background for instruments used in trade is on the legal metrology hub.

Timestamps, units and number formats

Most data problems in weighing logs come from ambiguous time, units and decimal separators rather than from the scale, and they are avoided by fixing conventions before the first record is written.

• Time. Store timestamps in UTC in the internet date-time format of RFC 3339 (for example 2026-09-14T06:42:17Z). Vessels cross time zones; local time can be derived for display. Synchronise clocks with GPS or network time and log any adjustment.
• Units. Store the unit with the value, or fix it per field (net_kg). Never mix kg and g in one column.
• Resolution. Store values at the scale's resolution with a fixed number of decimals; do not round again during export.
• Decimal separator. Use a point in machine-readable files. CSV opened in a spreadsheet with a comma-decimal locale may misread 5.120 as 5120; document the convention and test the import.

Statistics per preset

Statistics per preset summarise all records of one product over a chosen period and show at a glance whether packing is on target.

Example with hypothetical numbers: 1,200 boxes on preset COD-GUT-5KG with a total of 6,138 kg give a mean of 5.115 kg and an average giveaway of 115 g per box, or 138 kg over the period. Comparing that figure per shift or per grader recipe is how improvements are measured.

Export formats: CSV, JSON and PDF

CSV, JSON and PDF each serve a different audience: CSV for spreadsheets, JSON for software, PDF for people and documents that must not change.

A robust setup keeps the log in its original form on the scale or vessel system, exports CSV or JSON for further processing and generates PDF reports for people. How software reads records directly is described in Integrating Scales with Your Software via an API.

Storage, backup and retention

Weighing logs should be stored locally first, backed up regularly and retained at least as long as the longest applicable obligation, which for landing weighing records in the EU is three years.

Storage needs are modest. A record of about 250 bytes, at 20,000 weighings per day, produces about 5 MB per day, or roughly 150 MB for a 30-day trip, before compression. Local storage on or next to the scale ensures nothing is lost when a network link or shore connection is down; backups at every port call protect against hardware failure. Sending data ashore during the trip is covered in Ship-to-Shore Data.

How WPL approaches this

WeightControl runs directly on the R10 scale or as an external application for several scales, with a web interface and no client software. Every weight registered on the scale is automatically recorded in its database. A statistics dashboard shows recorded weights per preset and selected period; registration logs can be viewed in a PDF viewer and downloaded, exported as CSV for software such as Excel, and retrieved as JSON through the integrated API. The R10 Configuration Panel can save registered weights to its own logs for export and provides backup and restore of scale data. More on the overall data chain is on the data integration hub.