Case study
Compute at the edge, transmit via space: 99% less data over a satellite link
Mountain grazing has no broadband. We ran the model on a Jetson in the barn and sent 200-byte events over a satellite link, a 99% cut against raw video.
Farms in data deserts
Precision livestock farming has a coverage problem that nobody in the literature likes to state plainly. Almost every deployed system assumes terrestrial connectivity: Wi-Fi, LoRaWAN, or 4G and 5G cellular. That assumption quietly restricts the entire field to flatland and peri-urban farms.
Greek sheep farming is neither. It is fragmented smallholdings on rugged terrain, and regions like Crete run their local economy on livestock while having no broadband worth the name at the pen. The farms that would benefit most from automated health monitoring, because they are furthest from a vet and shortest of labour, are exactly the ones the standard architecture excludes.
ELDER was built to work there. The architecture is easy to state and awkward to implement: do all the computation on the farm, and send almost nothing.
From video to 200 bytes
The camera produces RGB-D video. The pipeline on the device runs object detection and pose estimation to extract keypoints for each animal, then a recurrent classifier scores the gait across a sequence of frames. Only the conclusion leaves the farm.
That conclusion is a JSON object with five fields: animal ID, timestamp, lameness score, severity, and location. Against the raw video input, that is a 99% reduction in transmitted data, and it was the enabling constraint rather than an optimisation. Narrowband IoT over non-terrestrial networks caps a message at 200 bytes. Either the event fits in 200 bytes or the architecture does not exist.
Two numbers made this workable. Inference latency averaged 492.25ms for a seven-frame segment on a Jetson Orin, which is fast enough to tag an animal before it leaves the camera's field of view. Getting there needed ONNX conversion and TensorRT engines, worth a 2.5x speed-up, plus a real-time kernel patch to stop the scheduler introducing jitter.
What has to be decided to fit an event into 200 bytes
- What is the event, exactly? Not a frame, not a detection. One animal, one pass, one conclusion. Getting this wrong multiplies message count by an order of magnitude.
- What identifies the subject? An animal ID that is stable across passes and days, or the trend analysis that justifies the system is impossible.
- How much of the score survives? We send a lameness score and a severity band. The full probability distribution does not fit and nobody downstream would use it.
- What is the evidence, and where does it live? The snapshot a farmer needs to verify an alert cannot go over the satellite link. It stays on the device and syncs when there is bandwidth.
- What happens to unsent events? They queue on the device. Storage is bounded, so there is a discard policy, and somebody has to choose it deliberately.
- What timestamp do you trust? Events arrive out of order, sometimes hours late. The device clock is the only ordering you have.
Store-and-forward changes what latency means
We validated against a testbed emulating low Earth orbit conditions, with the delays and the store-and-forward behaviour those constellations actually have. Messages batch on the device and go out during connectivity windows. In the field test the windows were two five-minute passes during the validation pilot, and the alerts flowed end to end without loss.
The simulated delivery latency ranged from minutes to hours. For this application that is fine, and the reason is worth stating carefully, because it is the part that does not generalise: lameness is a chronic condition. An alert that arrives ninety minutes late is as useful as one that arrives instantly. Nobody is going to act on it within the hour.
The delay tolerance of the application is the design input that decides whether this architecture is available to you at all. It is also the one most projects never write down, because on a terrestrial network nobody has to.
Under those conditions the system held 100% data integrity through field testing, in an environment with well under 10% connectivity uptime.
Terrestrial or non-terrestrial
Satellite IoT suits you if
- The site has no reliable terrestrial link and will not get one
- The decision is made locally and only the result travels
- Alerts tolerate minutes to hours of delivery delay
- Events are small, discrete and countable
- Power is constrained, so narrowband beats cellular
It does not suit you if
- Anything upstream needs to act within seconds
- The payload includes images, video or raw sensor traces
- Central systems must issue commands back promptly
- Event volume is high, since every message has a cost
- A terrestrial link already exists and is adequate
My take
The interesting engineering in this project was not the model. It was deciding what a single event is, and then being ruthless about everything that did not fit in 200 bytes.
That constraint turned out to be clarifying rather than limiting. When you can send five fields, you have to answer what the system is actually for, and the answer is never "all the data". Most of what a monitoring system transmits over a fat link is transmitted because the link was there, not because anyone downstream reads it. We have all built those systems. The bandwidth is cheap enough that nobody asks.
My contrarian position is that the 200-byte discipline produces a better system even where connectivity is not a problem. It forces the conversation about what the farmer does on Tuesday morning, and that conversation is the one that determines whether the thing gets used. If I were starting a monitoring project on a well-connected site tomorrow, I would still design the event payload as though it had to fit through a satellite, and only then relax it.
The corollary is uncomfortable for the industry: "we stream everything to the cloud and decide later" is not an architecture, it is a deferral. Sooner or later somebody has to decide what matters, and doing it at design time is cheaper than doing it after two years of storage bills.
The general version of this argument is in designing for the link that drops. The same deployment produced a false-positive rate we missed our target on and a ground-truth problem that nearly sank the model. For the hardware question, see sizing an edge device without guessing, or read about the monitoring work itself.