AI water monitoring in aquaculture: where fish are lost
Nighttime oxygen depletion develops quickly and almost unnoticed.
With the onset of darkness, phytoplankton switches from releasing oxygen to consuming it, and during the darkest hours the oxygen regime of the pond drops to a minimum — with high stocking density and warm water, a drop from 7-8 mg/L to 2-3 mg/L takes less than an hour.
Manual rounds cannot keep up with this rate. A measurement every 2-3 hours yields an isolated point, and between two readings the environment manages to change so much that fish mortality begins before the hydro technician approaches the cage again.
Rain, night fog, and water blooms shorten this interval even further, so scheduled water quality control only works against a calm background.
Measurement error is added to timing error. A portable oxygen meter requires rinsing and calibration, the sensor has inertia, and readings are affected by sampling depth.
Stationary probes such as OxyGuard remove some of these problems, but without polling logic and notifications they remain indicators: the value is visible on screen, and decisions are still made by a human.
Late detection costs more than everything else. Aerators are turned on when fish are already rising to the surface, and some mortality is inevitable.
To catch the onset of a drop rather than its consequences, a continuous loop is needed for oxygen, temperature, and redox potential — below we break down how it is built and what it gives the farm.
Early warning of oxygen crashes and stagnation
At night the oxygen regime is on the edge: phytoplankton photosynthesis stops, while oxygen consumption by biomass and bottom sediments continues.
Scheduled aeration during these hours either runs idle or is late — the crash is recorded in the morning during rounds, when some fish have already risen to the surface.
OxyGuard and similar sensors provide a continuous series for dissolved oxygen, but the series itself does not replace an alarm — what matters is what is done with it next.
The model builds a forecast of the oxygen minimum based on the rate of decline: current value, water temperature, biomass, time of last feeding, wind, and pressure.
Recalculation occurs every few minutes, and the alarm relies not on the current deviation but on threshold crossing in 2-4 hours. The signal goes out before the minimum occurs, so reaction time is measured in minutes: confirm, turn on aeration, if necessary shift feeding.
Aeration on demand instead of on schedule: equipment turns on based on the forecast and rate of decline. Operating hours decrease with the same oxygen background, and at night the water body does not go into stagnation.
The effect is measurable: the share of prevented nighttime kills grows, rounds decrease — the operator reviews deviations instead of measuring blindly. An even oxygen regime keeps feeding without forced pauses, and in total this reduces fish mortality.
Manual measurement, stationary sensors, predictive model
The three approaches solve different tasks, and choosing between them is a choice between data frequency, maintenance labor, and the horizon over which you want to see the situation in the cage or tank.
Manual measurement gives a point in time, stationary posts give a continuous series, and the predictive model gives time to react.
Confusing their roles is the costliest mistake: automation without reference calibration drifts, and a model without observation history has nothing to learn from.
| Option | When it fits | Limitations |
|---|---|---|
| Manual water measurement | Small farms, nursery ponds, project start, periodic monitoring of automation operation | Discreteness: one or two points per day, the nighttime oxygen peak remains unnoticed; the result depends on operator care |
| Stationary monitoring posts | Cages, tanks with constant water exchange, areas where the cost of failure is high | Drift and fouling of sensitive elements — rinsing and verification according to regulations are needed; coverage is limited to installation points |
| Predictive model | When a decision is needed several hours before an event, rather than a statement after the fact | Requires accumulated history and regular recalibration; without a series of posts and laboratory cross-checks it does not learn |
In practice this is not "either/or" but "and": posts provide a continuous series, manual measurement serves as a reference for cross-checking them, and the model works on top of both sources.
Therefore comparison of control methods should be based not on a single parameter, but on which control loop you are closing — operational, reporting, or warning.
Implementation stages: survey, setup, on-site verification
We start not with sensors, but with a farm survey: we look at water supply points, flow rate, how parameters behave over 24 hours, and who currently takes readings manually.
Based on this picture, we select areas worth equipping — those where the indicator changes quickly and directly affects survival.
- Farm survey — map of sampling points, water supply regimes, frequency and method of manual measurements.
- Selection of controlled parameters — temperature, dissolved oxygen, acidity, turbidity; calculation of the number of sensors for the actual dynamics of the area.
- Installation and calibration of sensors — verification solutions, corrections for temperature and salinity, so that measurement series are comparable with each other.
- Setup of logic and thresholds — baselines for each area, averaging windows, notification rules: when a signal is enough, and when we call out the team.
- Trial operation — the system operates in observation mode, thresholds are refined based on actual data, not datasheet values.
- Commissioning and on-site verification — control measurements alongside laboratory analysis, discrepancy reconciliation, and calibration adjustment.
- Transfer of the system to farm personnel — response regulations, shift training, sensor maintenance procedure.
After transfer, the farm has a working system, a log of readings, and a clear regulation: at what deviation who does what. We continue to support it — we review thresholds by season and analyze false alarms.
What remains with the farm: diagrams, regulations, access rights
The monitoring system should not remain the contractor's "black box": shifts change, fish farmers go on vacation, and sensors have to be cleaned and moved.
Therefore, along with the working loop, the farm receives a set of documents and settings that allow the system to be operated, maintained, and transferred to new people without us.
- Passports of posts and sensors: what it measures, where it is located, how it is calibrated, how the sensitive element is cleaned, and at what intervals.
- Layouts of sensor placement across cages, ponds, and tanks tied to depth and intake points — so that when posts are moved, measurement representativeness is not lost.
- Notification regulations: thresholds for oxygen, temperature, acidity, and nitrogen compounds, "attention" and "alarm" zones, who receives the signal and in what order.
- Access differentiation: roles of observer, operator, engineer, and administrator — who only views telemetry, who changes thresholds, who confirms an alarm.
- Incident response scenarios: loss of communication with a post, reading drift, false alarm — indicating who intervenes and within what time.
- Event and alarm logs with export: reading history, who confirmed a signal and when — the basis for incident review and reporting.
- Maintenance and update instructions: cleaning frequency, communication checks, procedure for backing up settings and migrating the loop to a new server.
Case: eliminating nighttime kills at a pond farm
A pond farm with six ponds raises carp and silver carp. Oxygen here was measured manually: an attendant walked the ponds four times per night with a portable oxygen meter, and some samples went to the laboratory. He saw a critical drop after the fact and manually turned on aerators himself.
What it was
During the season there were two or three nighttime kills — in total up to 10% of marketable fish.
It was not due to negligence: between rounds 40-60 minutes passed, the trip to the far pond took the same amount of time, and oxygen on a hot, windless night falls faster than a round proceeds. At the same time, aerators ran on schedule — where there was no deficit, electricity was wasted.
What was changed
At the deepest points of each pond, Hach dissolved oxygen and temperature sensors were installed, and readings go to the server every few minutes.
The model forecasts a drop 2-3 hours ahead based on temperature, wind, biomass, and feed volume: the attendant receives a signal with the number of the specific pond, not "something dropped somewhere." The aerator starts automatically when a deficit occurs; if a sensor fails, a backup control loop turns on.
What became
| Indicator | Before | After |
|---|---|---|
| Night rounds | 4 per night | 1 check |
| Reaction to a drop | 40-60 minutes | automatic start |
| Kills per season | 2-3 | 0 |
| Aeration consumption | on schedule | by deficit, −20% |
| Fish survival | baseline | +8-10% |
Night duty turned into monitoring a summary: one engineer sees the state of all ponds and confirms the system's decisions, instead of driving between them.
The farm changes threshold settings and aerator start logic itself — we transferred them along with documentation and trained the shift.
How does threshold notification differ from a predictive model?
Threshold notification is the rule "value went beyond the boundary — alarm." It can be set up in one evening: boundaries for temperature, dissolved oxygen, acidity, turbidity. It is predictable and transparent, but it reacts to a fact that has already happened.
False alarms appear where a value briefly crosses the boundary and returns: feeding, nighttime cooling, a turbidity spike after rain or water discharge.
Without a confirmation window and hysteresis, the dispatcher receives dozens of identical messages and stops reading them — alarm setup becomes a source of noise.
The predictive model works differently. It takes the same measurement series, adds feeding history, stocking density, weather background, and builds a trajectory several hours ahead.
Instead of "oxygen dropped," proactive scenarios arrive: by the morning minimum the indicator will move to the lower boundary — so aeration is turned on in advance, when it is safer for fish.
Both loops do not compete. The threshold remains a safeguard and catches sensor failures and shock discharges that the model does not have time to predict. The forecast covers slow processes — blooms, organic matter accumulation, seasonal shift. Together they form a two-level scheme: anticipation plus a hard boundary.
The practical selection criterion is simple: where processes are fast — a threshold is needed; where an event develops over hours — a forecast pays off. We analyze on your data what horizon provides stable anticipation and how many false alarms are eliminated.
Technical questions: sensors, false alarms, installation
Any doubt about such a system comes down to four things: whether it will start "crying wolf," who maintains the sensors and how, what happens when communication is lost, and what happens when the farm decides to expand.
Below is how this is addressed engineering-wise, without promises that it will "work by itself."
Will monitoring turn into a stream of false alarms?
An alarm is raised not based on a single reading.
The system compares several sensors at one node, checks the rate of parameter change, and requires the deviation to persist within a specified window — a single outlier from interference or a fish swimming by simply does not pass the threshold.
Triggers are marked by level: warning for the operator and emergency notification for the attendant. Thresholds are configured for a specific tank or cage, not taken as "industry averages."
What happens when communication is lost?
Data is not lost: the controller writes it locally and uploads it to the system when the channel returns. More importantly, loss of communication itself becomes an event, not silence in the interface.
The operator sees "no communication with node," not "all normal," and understands that there is currently no data for this area.
How to maintain sensors and expand the system?
Sensors are consumables with a regulation: rinsing, verification, replacement of membranes and electrodes on schedule.
The system keeps a calibration log, reminds about deadlines, and based on reading drift itself suggests that a node is due for maintenance — data quality is visible, not taken on faith.
Expansion proceeds node by node: a new cage or line connects as a separate node with its own thresholds, and the working part does not need to be reassembled.
Let's discuss the task: monitoring posts and notification scenarios
Project evaluation relies on the specifics of the farm, not industry averages: seemingly similar cages and tanks require different sets of monitoring posts and different notification logic. Below are the inputs sufficient to come back with an estimate and a staged implementation plan.
- Farm type and water bodies: cages, ponds, recirculating tanks — this determines the number of monitoring posts and sensor polling frequency.
- What is already installed on site: oxygen, temperature, pH, ammonium, turbidity sensors — what transmits data automatically and what is recorded manually in a log.
- Communication and power: where there is a stable data transmission channel, where only mobile communication, and how backup power for posts is arranged.
- Threshold values and scenarios: which deviations are critical, who receives the signal and within what time, and how night duty is organized.
- Automatic actions: what the system starts itself during an alarm and where operator confirmation is mandatory.
- Connections with existing systems: feeding, aeration, batch accounting, laboratory log.
- Observation archive: measurement history with known outbreaks and losses — it is used to configure thresholds based on fact, not datasheet values.
- Who will operate it: shift composition and training of the people who will see an alarm first.
Describe the task within this scope — we will come back with a project estimate and implementation plan: composition of monitoring posts, notification scenario logic, and timelines by stage.
