Why Process Satellite Data Before Sending It Home?

Part 7 of 30 · Series date: September 8, 2026

A mountain of data tomorrow can be worth less than one trustworthy warning today.

Imagine a lookout who sees smoke on a distant ridge. Instead of sending a warning, he begins describing every tree, rock, and cloud in view. His observations may be accurate, but his priorities are terrible.

A satellite can face a similar problem. Its instruments may collect far more information than an available connection can carry immediately. Deciding what deserves attention can be as important as collecting another image.

The narrow doorway

A downlink is the communications path from spacecraft to Earth. Its usable capacity depends on more than the radio or laser's peak speed. The satellite needs an appropriate receiver, a suitable path, and time to transmit. Other traffic may compete for that time.

When incoming data exceeds outgoing capacity, a queue forms. More storage lets the spacecraft wait longer, but it does not widen the doorway. More powerful communications may help, but add their own demands.

Onboard processing offers a third approach: reduce or prioritize what must leave.

ESA's PhiSat-2 mission describes AI applications for processing Earth-observation data, including detecting cloud-obscured images. Such work illustrates why useful computation can belong beside an instrument. ESA Earth Online: PhiSat-2.

Four different ways to send less

Compression represents information more efficiently. Filtering rejects material judged unnecessary. Summarization produces a smaller account. Prioritization changes the order of delivery.

These are not interchangeable. A compressed image may preserve information that a summary omits. A rejected image may be impossible to recover after deletion. A prioritized image can still be delivered in full.

Consider a hypothetical wildfire application. The satellite might first send a short alert containing time, location, and uncertainty. It could next send a small image around the suspected event. A larger original image might follow when bandwidth permits.

That workflow is a proposed design, not a report of a specific deployed service. Its purpose is to show that reducing delay does not require pretending a model's conclusion is the whole truth.

The cost of a wrong decision

Filtering creates a difficult trade. If the system discards a useful image, no one on Earth may know what was lost. If it sends too many false alarms, users may stop paying attention.

The right threshold depends on the application. A crop survey can tolerate some delay. An urgent hazard alert may require stronger safeguards and independent confirmation. Clouds that obstruct one scientific question may themselves be the subject of another.

A responsible design therefore defines what “unusable” means for each customer. It might retain a sample of rejected data, preserve uncertain cases, or keep originals temporarily for audit. These are editorial design recommendations, not universal mission rules.

Faster does not automatically mean better

A quick result is valuable only when it supports a useful decision. An emergency operator needs enough context to distinguish a likely event from sensor noise. A scientist needs calibration information and a reproducible processing history.

Each result should therefore carry provenance: the instrument, time, software version, relevant quality checks, and known limitations. Provenance is the information equivalent of a chain of custody.

The objective is not to replace all human interpretation with a confident label. It is to use limited communications more intelligently while preserving enough evidence for accountable decisions.

Why a highly accurate detector can still overwhelm people

Rare events create a statistical trap. To see it, use an invented test set of 10,000 observations, only ten of which contain the event we want to find. Suppose a detector finds nine of those ten events and falsely flags one percent of the other 9,990 observations.

It produces about 100 false alerts alongside nine correct alerts. The system detected 90 percent of the real events, yet only about eight percent of its alerts are correct. Both statements can be true.

These are teaching numbers, not measured performance for a satellite or wildfire detector. They show why one impressive accuracy percentage cannot tell a responder what to expect.

The service needs measures that answer different questions. How many real events are missed? How many alerts are wrong? How quickly does the useful warning arrive? Can a second sensor or human review resolve uncertain cases without losing the time advantage?

An orbital system should not spend its communications savings by flooding people with bad decisions. Its success depends on the entire alert workflow, including the people who receive it.

Keep a path back to the evidence

Return to the imagined smoke alert. A short message can arrive first: location, observation time, suspected event, and a clear indication that confirmation is needed. A small image can follow. The original data can remain available for later review within a defined storage policy.

That sequence gives different users what they need at different times. A responder needs a prompt, intelligible warning. An analyst needs context. A scientist improving the detector needs the raw observations, including some cases the system rejected.

Storage is finite, so preserving every original forever may not be possible. The retention policy becomes part of the mission design. One approach might retain uncertain cases longer, sample rejected observations, and allow a ground request to protect particular files from deletion.

Those are proposed safeguards, not universal requirements. Their value lies in making the cost of irreversible filtering explicit. Once a unique observation has been discarded, a faster processor cannot recreate the event that produced it.

Better alerts need feedback from the ground

A model can change behavior when the scenery changes. New seasons, unfamiliar terrain, different lighting, or a revised instrument can expose weaknesses absent from its original tests.

An imagined service should therefore learn whether its alerts proved useful. Did responders find an event? Was the location wrong? Did the message arrive after another system had already supplied better information? Feedback can reveal whether orbital processing actually improves decisions rather than merely generating more notifications.

Updating the model then creates a second responsibility. The provider should test a new version on representative data, compare its errors with the old version, and preserve a safe rollback path. A new model should earn broader use through evidence.

This is where onboard intelligence becomes a continuing service rather than a one-time installation. The algorithm is only part of the loop. Instruments, communications, analysts, and local responders all contribute to whether the person beneath the ridge receives something worth acting on.

Put a price on the bottleneck

The business case should compare the cost of onboard processing with its benefits. Does it reduce ground-station demand? Deliver valuable information sooner? Allow a smaller transmitter? Save storage? What additional power and cooling does the processor require?

If an inexpensive ground connection already delivers everything in time, another orbital processor may add little value. If delays routinely make data less useful, nearby computation could earn a premium.

Location is not the benefit by itself. Removing a costly delay is the benefit.

What would prove this?

Run a representative dataset through both workflows. Measure delivery time, bytes transmitted, energy used, missed events, false alarms, and the ability to reconstruct decisions. Include difficult cases rather than selecting only clear successes.

The first great orbital computing business may be built on a modest promise: send the right information while it still matters. For the person watching a ridge line, that could be worth more than receiving a mountain of perfect data tomorrow.

Previous article · Next article