IoT Irrigation Connectivity: Compare LoRaWAN, Cellular, and Farm Wi-Fi

Choose irrigation connectivity by matching each field location, message deadline and power supply to a tested communication path. LoRaWAN, cellular and farm Wi-Fi can all have a place, but none provides a farm-wide performance guarantee from its name alone. Compare the field radio separately from the gateway’s internet connection, then check data traffic, energy demand and recurring costs against the same service requirement.

Wireless infrared thermometers being adjusted on a center-pivot irrigation system. The photograph does not identify a LoRaWAN, cellular or Wi-Fi protocol. Photo: Peggy Greb, USDA Agricultural Research Service.

Draw the field link and internet backhaul as separate paths

A soil sensor may transmit by LoRaWAN to a gateway whose internet backhaul uses cellular service. Calling that installation either “LoRaWAN” or “cellular” without identifying the two segments hides important dependencies. A Wi-Fi access point also needs a route to the intended server; coverage around a pump house does not establish coverage at a distant valve.

Record each sensor or controller, its radio, any gateway or access point, the backhaul and the application destination. Mark who owns and powers each element. For direct cellular endpoints, the mobile operator’s access network replaces the farm-owned radio gateway, but the endpoint still needs compatible service and adequate power. Shared infrastructure can reduce repeated connections while concentrating dependencies at a common location.

The LoRa Alliance’s topology and device-class explanation describes gateways relaying between end devices and a network server over IP connections. That architecture does not imply that every LoRa radio product implements LoRaWAN or that a gateway performs local irrigation control. Obtain the proposed network and application arrangement in writing.

This comparison concerns connectivity selection and measurement. The irrigation guide for unreliable internet addresses local execution, storage and recovery separately. A radio survey cannot establish those controller functions.

Compare access choices using the actual farm locations

Start with a map of the sites that must exchange information, including representative low points, structures and crop conditions. Record installation height, enclosure and antenna position, available power, service access and future endpoints. Do not relocate an agronomically important measurement just to improve a convenient radio test; the soil-moisture sensor placement guide explains why representative sampling locations matter.

These are screening conditions, not a distance ranking. Terrain, vegetation, metalwork, antenna installation, interference and device design can change the outcome. Test with enclosures closed and equipment in its intended position. Include representative irrigation machinery movement and operating electrical equipment where relevant; a result from a temporary antenna above the crop does not validate a final low-mounted node.

A mixture may be appropriate: a powered pump-house network and a low-data field network can use different access methods. Keep their responsibilities explicit. A successful sensor-to-gateway test leaves the gateway-to-application route unproven, while an online gateway says little about the weakest field endpoint.

Match receive availability to the command deadline

Telemetry that supports later trend review and a supervisory command needed promptly have different timing needs. Specify the start and end of each measured interval. For example, application acceptance of a command to its decoded receipt at the field controller is a communication interval; completion of a valve movement is a separate physical outcome.

LoRaWAN Class A devices open downlink receive windows after an uplink. In an illustrative configuration with an uplink only every 15 minutes and no additional trigger, a command arriving after those windows can wait almost another reporting interval before the next opportunity. That configuration cannot guarantee a 60 s command deadline. More frequent uplinks change traffic and energy demand, and still do not by themselves guarantee delivery.

Class C keeps reception open when the device is not transmitting and reduces waiting for a receive opportunity. It does not remove application queues, backhaul delay, radio scheduling, losses or controller processing, and it requires a suitable power budget. Class B uses scheduled receive opportunities; check the supported configuration if considering it. Do not turn a device-class label into a promise of zero end-to-end latency.

The GSMA Mobile IoT Deployment Guide explains that PSM makes a device unreachable from the network while asleep, although its application can initiate an outgoing transmission. eDRX also creates intervals when the receiver is not listening. Requested settings and actual network-negotiated settings can differ, so verify the deployed operator, device and service combination.

Confirm supported bands, the intended cellular technology, roaming arrangements and service availability at the site. A phone showing LTE reception does not prove NB-IoT or LTE-M availability for the selected endpoint. Retain the negotiated timer values and observed receive behavior in the test record. The alarm design worksheet covers how communication delay fits a wider response budget; this article does not set protective trip timings.

Calculate application traffic before estimating network load

Use an invented monitoring example with 24 endpoints. Each produces one 32-byte application record every 15 minutes. Assume all endpoints operate continuously for a 30-day accounting month, without additional event messages. The record size includes this example’s application fields, not radio or transport overhead. These are teaching inputs, not measured equipment specifications.

There are 24 × 60 ÷ 15 = 96 records per endpoint per day. Across the installation, 24 × 96 = 2304 records carry 2304 × 32 = 73728 application bytes per day. Over the assumed month, 73728 × 30 = 2211840 bytes, or 2.21184 decimal MB, where a decimal MB contains 1000000 bytes.

This payload total is neither radio airtime nor a cellular bill estimate. Headers, acknowledgments, retries, joins, status messages, gateway traffic, encryption-related framing and software transfers can add load. The data rate, coding and regional configuration affect airtime. Check exact implementation limits and measure actual backhaul use; do not apply one undocumented overhead multiplier to all three technologies.

Also test short-term demand. Endpoints transmitting together, a group of commands or a maintenance transfer can create a more difficult case than the monthly average suggests. State the permitted reporting pattern and maintenance window, then assess the proposed endpoint count and later expansion against them.

Build the power budget from time spent in each state

For a separate illustrative endpoint, assume the entire device draws 40 mA during a 2 s measurement-and-communication event, and 0.020 mA during the remaining time. Use 96 events per day plus a separate 0.50 mAh/day allowance for other consumption. The event is not a claim about transmit airtime or any particular radio standard; sensors, receive periods and processing belong in the measured whole-device budget.

If a 2400 mAh battery has an assumed usable fraction of 0.70 under the relevant conditions, usable charge is 1680 mAh. The ideal estimate is 1680 ÷ 3.11227, approximately 540 days using the unrounded daily total. This is not a service-life guarantee. Temperature, aging, self-discharge, pulse capability and actual retries require verification; the assumed usable fraction and allowance are not universal corrections.

Changing this same model to a 5-minute interval gives 288 events, 576 active seconds and 7.3768 mAh/day including the same allowance. The ideal estimate falls to about 228 days. Constant reception would require a different state model. Check the peak-current supply and voltage throughout operation as well as average charge. Gateways and access points need their own energy and backup calculations; this endpoint example does not size a solar panel or include valve actuation.

Measure arrival by a deadline with a defined denominator

The NIST guide to industrial wireless deployments recommends explicit requirements, site assessment and testing actual installed devices. Its industrial framework is useful here; it does not provide a farm coverage guarantee. Test both directions and record source and destination timestamps with known clock alignment, so clock error is not mistaken for network delay.

For an invented 7-day trial of the 24 endpoints at the 15-minute schedule, define expected unique records as 24 × 96 × 7 = 16128. Define “on time” as application receipt no more than 120 s after the scheduled measurement time. Close collection 24 h after the last scheduled sample. Retain missing source records in this end-to-end denominator, and diagnose them separately; they do not automatically represent radio packet loss.

Suppose the receiver also logged 120 duplicate copies. They do not add unique successes. Use endpoint and record identifiers to distinguish copies from new observations. Report results per endpoint as well as in aggregate: a weak location with 620 on-time records out of its 672 expected records achieves only 92.26%, even while the farm-wide figure looks better.

The 120 s deadline is an invented test requirement, not a safe control limit. Report latency distributions, late records and missing records separately; a percentile computed only from arrivals omits losses. To report radio packet loss, define the specific radio boundary and attempted-transmission denominator, with suitable logs. Repeat representative loaded and seasonal conditions; this short fictional trial cannot certify future reliability or establish a universal acceptance percentage.

Compare the same three-year communication cost boundary

Only compare costs after mandatory coverage, timing and power requirements pass. The following invented quotations cover communication hardware and installation, monthly communication/network service, and annual planned maintenance plus energy for the same endpoint requirement. Amounts are assumed USD, undiscounted and before tax. They exclude identical sensors, irrigation controllers, valves and application costs common to every option; actual differing charges must be added.

Use TCO = installed cost + 36 × monthly service + 3 × annual maintenance and energy. The Wi-Fi line assumes its required access infrastructure is included upfront and only the stated incremental onward-service charge applies. It is not the cost of building new broadband to an unserved farm. The annual allowance must cover the quoted maintenance and energy scope, including planned battery work where applicable.

The lowest number is not a selection result if that architecture fails the field test. Request ownership and renewal terms, supported service lifetime, data access, maintenance responsibilities and the cost of adding endpoints. Identify charges triggered by outages, service visits, excess traffic or subscription changes instead of burying them in an attractive base price.

Select the configuration that passes the farm’s written requirements

Keep one decision record linking the map, exact radios and regional settings, service terms, measured traffic, power budget, deadline results and cost boundary. Record failures and retests after changing antenna placement, gateway location or reporting interval. A weighted score may compare qualifying choices, but it must not offset failure of a mandatory requirement.

Keep local operating permission and protection in their engineered scope. The pump and valve interlock worksheet addresses those dependencies; an internet path does not establish protective behavior. Reassess connectivity after crop development, added devices or service changes. Select the complete tested configuration that meets the stated farm task, with an identified person responsible for maintaining each communication segment.