A field node that lives on a research site or a back paddock has to survive three things: the power running out, the weather getting in, and nobody being around to press the reset button. Most early failures come down to one of those. This article walks through how we think about each one, in the order they usually go wrong.
Start with the power budget, in watt-hours
Solar sizing is not complicated, but it is unforgiving if you skip steps. Work in watt-hours per day, because that is the unit the sun and the battery both understand.
Begin with average power draw, not peak. A small ARM board might sit at a couple of watts idle and several watts under load; a camera, a modem and a Starlink terminal each add their own figure. Measure each with a meter rather than trusting datasheets, because real cables, converters and regulators all lose something. Multiply the average watts by 24 to get watt-hours per day.
Then decide how many days the node has to run with no useful sun. On the east coast a run of overcast days in winter is normal, and a fortnight of it is not rare. Multiply daily consumption by that number of days, then divide by the usable fraction of the battery. Lithium iron phosphate batteries tolerate deep discharge much better than lead-acid, which is why we default to them, but any chemistry ages faster if it is cycled to empty.
Panel sizing comes last. Take the daily watt-hours, divide by the peak sun hours for the site in the worst month, then add a healthy margin for panel soiling, tilt, temperature derating and charge-controller losses. If the answer looks too large, the fix is nearly always to reduce consumption rather than to buy more glass.
Sleep cycles change everything
The single biggest lever in that arithmetic is how often the node is actually awake. A board that samples sensors for a minute every fifteen minutes and sleeps in between uses a small fraction of the energy of one that runs a full operating system continuously. Not every workload can duty-cycle. A camera doing on-device inference on every frame cannot sleep during the event it is trying to catch. But most environmental sensing can, and a modem that only wakes to upload a batch is far cheaper to run than one holding a link open all day.
Where the design allows, we separate the always-on part, a low-power controller that keeps time and manages power rails, from the part that does the work and can be switched off. That controller is also the thing that can bring the rest back to life, which matters later.
Enclosure, heat and ingress
In Australia the enemy is usually heat, not cold. A sealed enclosure in full sun can sit far above ambient inside, and consumer boards, batteries and SD cards all age quickly at those temperatures. Shade the enclosure, mount it off the ground, paint it a light colour, and give the electronics a path to shed heat to the case wall. Fans are a last resort in an unattended installation because they fail and they need holes.
Ingress is the other half. Rain is obvious. Less obvious are ants, which will find any gland that is not properly sealed, and condensation, which forms inside sealed boxes as they cool overnight. A vent with a membrane that passes air but not water helps equalise pressure and reduce condensation. Conformal coating on boards is cheap insurance. Run cables through proper glands, with drip loops, and never rely on the lid seal alone.
Choosing ARM compute
Low-power ARM single-board computers are the natural fit for this work. They idle at a fraction of the power of an x86 box, they run mainstream Linux, and the ecosystem of carrier boards and industrial variants is mature. A few things guide our choices:
- Prefer boards with an industrial temperature rating and a long-term availability commitment. A hobbyist board that is revised every year is hard to support across a fleet.
- Boot from eMMC or an industrial SD card, not a consumer card, and keep the root filesystem read-only where possible so a power cut mid-write does not corrupt it.
- Match the compute to the job. A board with a neural accelerator makes sense for camera inference; a much smaller one is fine for logging a handful of sensors.
- Check the supply chain for the specific SKU. Two boards with the same name can differ in memory, wireless and power behaviour.
A cluster of a few of these boards, rather than one larger machine, also gives you graceful degradation. Losing one node costs some capacity, not the whole site.
Recovering when nobody is on site
Sooner or later something will hang. The design goal is that no hang needs a site visit. That means layers: a hardware watchdog that reboots the board if the operating system stops responding; a power controller that can cut and restore power to the compute and the modem independently, on a schedule or on command; a boot arrangement with a known-good fallback image; and configuration held in version control so a replaced board can be rebuilt without anyone remembering what was on the old one.
Out-of-band access is the last layer. If the primary link is the thing that failed, a low-bandwidth secondary path that only needs to carry a shell session and a few commands is worth its weight in fuel.
Where Bizix Agritech fits
We engineer low-power ARM edge clusters for field deployment on solar, with the power management, enclosure design and remote recovery described here built in from the start. The intent is a node that is installed once and visited rarely, which is as much about reducing site entries as it is about uptime. Designed and supported in Australia.