Starlink has changed what is possible on remote properties and research sites. A dish, a power supply and a clear patch of sky now give you a link that would have needed a fixed wireless tower or a geostationary satellite service a few years ago. It is a good service, with specific behaviours that catch people out when it is treated as a drop-in replacement for a fibre connection in town.
This article sets out what to expect from Starlink on a working site, and how we design around its limits rather than pretending they are not there.
Latency and throughput: good, but variable
Low-earth-orbit satellites sit much closer than geostationary ones, so round-trip latency is a fraction of what the older satellite services delivered. In practice it lands in the tens of milliseconds most of the time, which is fine for SSH, video calls, remote desktop and sensor uploads. What it is not is constant. Latency and throughput move as the dish hands over between satellites, as constellation load changes through the day, and as the cell you are in gets busier in the evening.
For most farm and research traffic that variability is invisible. It matters when you run latency-sensitive control loops across the link, or when you assume a fixed upload rate for camera streams. Design for the poor end of the range, not the speed-test number from day one.
Obstructions are the number one field problem
The dish needs a wide view of the sky, and in Australia it tends to favour the northern sky. A single tree branch or shed roofline in the wrong place shows up as short, regular dropouts rather than a dead link, which makes it easy to misdiagnose as a software fault. The obstruction check in the Starlink app is worth running before anything is bolted down, and worth re-running after a season of tree growth.
Mounting height helps, but so does mounting location. A pole a few metres away from the shed is often better than a bracket on the shed itself. Keep the cable run within the length the kit supports; the dish cable is a proprietary assembly you cannot simply extend with a joiner.
Power draw and weather
A Starlink terminal draws meaningfully more power than a 4G modem or a small router, and it draws it continuously. On a solar-only research node it is often the single largest load in the power budget, and the dish heater, if enabled, can make it worse on cold mornings. Measure the current draw of the specific dish model you have, use that number in your sizing, and turn off features you do not need. If the site is solar-only, treat the dish as a load that may need to be scheduled rather than left on around the clock.
Weather is the other variable. Heavy rain and dense cloud attenuate the signal, which on the east coast means the link is most likely to degrade during the storm you most want to observe. Light rain is generally fine. Very heavy rain or hail can cause brief outages. None of this is a reason to avoid Starlink; it is a reason not to make it the only path.
Combining Starlink with 4G or NBN using VyOS
This is where SD-WAN earns its keep. We run VyOS on a small router at the site and build encrypted tunnels from it back to a hub, one tunnel per WAN. Starlink is usually the primary because it has the most bandwidth. The secondary is whatever is available: a 4G modem with an external antenna, NBN fixed wireless, or a second Starlink on a different plan.
A few things matter in this design:
- Starlink residential connections sit behind carrier-grade NAT, so you cannot reach the site inbound. Tunnels are initiated outbound from the site to the hub, and everything you need to reach lives inside the tunnel.
- Health checks decide when to fail over. We probe through each tunnel to the hub, not to a public address, so a check tells you whether the path you actually use is healthy.
- Failover and failback need hysteresis. A link that flaps every thirty seconds causes more disruption than one that is simply down. Require several consecutive failures before switching, and a longer run of good results before switching back.
- Sessions do not survive a WAN change unless the tunnel does. Terminating the tunnels on the hub with a stable inner address means a remote desktop session or a sensor upload sees a pause, not a disconnect.
- Bulk traffic such as camera archives can be pinned to Starlink only, so a 4G fallback with a data cap is not consumed by an overnight sync.
What to monitor
The link is only as dependable as your visibility into it. At a minimum, collect and alert on tunnel handshake age or keepalive state for each WAN, round-trip time and packet loss through each tunnel, the dish’s own obstruction and outage statistics from its local status interface, and the power state of the terminal if it sits on a controlled circuit. Watch the trend, not just the current value. A slow rise in obstruction percentage over months is a tree, and it is far cheaper to prune than to fault-find at midnight.
Keep the monitoring itself out of band where you can. A small amount of telemetry over the 4G path will still tell you what happened to Starlink when Starlink is the thing that failed.
Where Bizix Agritech fits
We design and support SD-WAN edges built on VyOS for remote agricultural and research sites, with Starlink, 4G and NBN combined behind a single stable tunnel to a hub. The monitoring described here is part of the standard deployment, so the people responsible for a site know about a degraded link before the people relying on it do. Everything is designed and supported in Australia.