Agricultural Sensor Series · Part 2
This installment examines four technology developments. Start with Part 1: From Data to Better Decisions for the adoption challenges behind them.
Smart agriculture sensor technology is advancing in four connected directions: local processing, dependable power, more robust sensing hardware and clearer data interfaces. Together, they address a practical question: how can a sensor remain useful after installation, through changing weather, interrupted connectivity and routine farm work?
In our previous article on agricultural sensor adoption, we examined the gap between collecting measurements and using them. Reliability problems, difficult field power arrangements, isolated data and unclear links to decisions can all undermine a deployment. These problems have technical solutions, but the maturity of those solutions varies.
For distributors, agricultural equipment installers and commercial growers, the useful distinction is between a feature that can be demonstrated on the proposed equipment and a promising research direction. This article follows the four developments and explains what to verify before specifying them for a project.
1. Edge Computing: From Sending Data to Processing It Locally
In a cloud-centered installation, field devices transmit measurements or images to a remote service for processing. That arrangement can work well where connectivity is dependable and the application tolerates transmission delays. In a remote field, however, an interrupted connection can postpone access to information and cloud-dependent instructions.
Edge computing moves some processing closer to the measurement point. It can take place in a gateway, a field computer or a suitably equipped sensor. NIST’s fog computing model describes distributed processing that complements centralized cloud services. Local processing does not necessarily require artificial intelligence: filtering, threshold checks, buffering and control rules can also be valuable edge functions.
Intelligent gateways and field computers
An edge gateway may combine several sensor inputs, check whether values are plausible, store records and send summaries upstream. A more capable computer may run an image-recognition model. Its actual functions depend on the hardware, software and model supplied; an ordinary data-transfer gateway should not be described as an AI computer.
Consider an illustrative insect-monitoring application. Rather than uploading every image immediately, a compatible edge system could identify candidate insects, count detections and transmit a timestamped result with selected images for review. The result might trigger an alert for inspection, rather than an automatic pesticide recommendation.
Bandwidth use and response time depend on image resolution, capture frequency, processor capability, model size and network conditions. Verify them under the proposed configuration instead of assuming a universal improvement. Ask which local insect species and operating conditions the model has been validated against, including false detections and missed detections.
Intelligence inside the sensing device
Some instruments integrate imaging and analysis within the device. A compatible spore-monitoring instrument, for example, may capture images and classify or count supported spore categories locally. That is a more specialized capability than ordinary environmental measurement.
Image classification alone does not always establish pathogen species, viability or disease risk. Similar-looking particles, sampling conditions and the training dataset can affect the result. A concentration estimate also requires a defined sampling volume or flow and a suitable counting method. Buyers should request the supported targets, validation method and limitations before using an output in a disease-warning workflow.
Offline operation requires a complete control design
An edge controller can continue configured local rules when the internet connection fails, provided power, sensor inputs and actuator connections remain available. This can support functions such as scheduled irrigation or ventilation within agreed limits. A local knowledge base is optional; offline operation can also use conventional control logic.
Specify what happens when readings are missing, implausible or stale. Define maximum operating duration, manual override, alarm behavior and record storage. During commissioning, disconnect the internet and test the actual response. “Offline monitoring,” “offline data storage” and “offline automatic control” describe different capabilities.
Cloud services can still support remote access, long-term analysis and software management. The objective is an appropriate division of work between field equipment and the cloud. See our guide to sensor data and irrigation control for the wider system architecture.
2. Power Technology: From Frequent Visits to Better Energy Management
Remote monitoring depends on an energy source that remains adequate when conditions are unfavorable. A low-power sensor can still be part of a demanding system once the radio, gateway, imaging, heating or actuator requirements are included.
Environmental energy harvesting
Solar charging with energy storage is an established option for many outdoor monitoring configurations. Other approaches, including thermoelectric generation, vibration harvesting and triboelectric devices, are being investigated for particular conditions. They should not be treated as interchangeable replacements for a conventional field power supply.
A temperature difference between soil and air may provide a potential energy source, but it changes with weather and time of day. Rainfall and wind are intermittent. Indoor photovoltaic options depend on the available light, while emerging materials also need suitable encapsulation and environmental durability.
The practical question is whether harvested energy meets the complete operating demand over the required period, including losses and a reserve for weak input. Texas Instruments’ energy-harvesting technical discussion illustrates the importance of combining an energy source with power management and low-power electronics. It is design background, not a battery-life promise for a finished agricultural system.
Low-power electronics and communication
Sleep modes, duty cycling and sensible reporting intervals can reduce demand. However, a microcontroller’s sleep-current figure does not represent the average consumption of an assembled sensor node. Measurement warm-up, sensor excitation, transmission peaks and repeated connection attempts must also be considered.
LoRa-based systems and cellular IoT can suit some remote applications, but the choice depends on coverage, regional compatibility, payload size and gateway availability. Longer intervals between reports may help with energy management, yet an application needing rapid alarms may require a different design.
Request a power budget for the actual configuration: normal and peak consumption, reporting interval, battery usable capacity, temperature limits, charging assumptions and the required operating period without charging. Validate performance at the site. Aim for manageable maintenance rather than assuming that an unattended device can be forgotten indefinitely.
3. Hardware Innovation: Smaller Devices, Better Diagnostics and More Durable Surfaces
Hardware development includes miniaturization, improved sensing materials, integrated electronics and more suitable packaging. The benefits depend on the measurement principle. A development that improves one type of sensor may not apply to another.
Solid-state sensing and MEMS
MEMS fabrication can integrate small mechanical structures and electronics in devices such as pressure sensors. Solid-contact ion-selective electrodes can replace the internal filling solution used in some conventional electrode designs. These are distinct approaches, not a single technology that removes every reliability problem.
Miniaturization can simplify integration, but a compact sensing element still needs appropriate protection, a stable reference where required and a suitable interface with the measured environment. Solid-state construction does not automatically mean calibration-free operation or a guaranteed longer field life.
Research on solid-contact ion-selective electrodes discusses remaining challenges including potential stability and reproducibility. For buyers, the evidence to request is specific: measurement accuracy under stated conditions, repeatability, drift behavior, interference, calibration procedures and service requirements for the complete instrument.
Self-checks are different from self-calibration
Multiple sensing elements may help identify disagreement or compensate for some effects. They do not necessarily provide an independent reference: two elements exposed to the same contamination can drift together.
Ask the supplier to distinguish automatic temperature compensation, internal electrical checks, drift detection and actual calibration. Establish what the device can detect, how an invalid reading is flagged and which reference procedures remain necessary. Avoid selecting equipment solely on a “self-calibrating” label.
Anti-fouling materials and serviceable construction
Surface engineering inspired by water-repellent or slippery biological surfaces is an active research direction. In some applications, suitable coatings or cleaning mechanisms may reduce unwanted deposition. A coating must also preserve contact between the sensing surface and the substance being measured.
For soil and submerged probes, request evidence under representative conditions, not just a clean-water demonstration. Consider abrasion, chemical exposure, biological growth and cleaning compatibility. Accessible mounts, replaceable consumables and straightforward cleaning procedures remain useful even when advanced materials are present.
These improvements support reliability, but they do not remove the need for installation checks and maintenance records. Our sensor troubleshooting guide covers practical checks when readings drift or communication becomes unreliable.
4. Interoperability: From Separate Devices to Understandable Data
Connecting equipment involves several layers. Devices need compatible electrical interfaces or radios, a shared communication method and an agreed meaning for the data. A connection that carries bytes successfully may still leave the platform unable to interpret them.
Agree on more than the protocol name
For a sensor described as RS485 Modbus, request the pinout, electrical requirements, communication settings and register map. For a networked system, confirm the supported interface, authentication and access permissions. An MQTT connection, for example, also needs agreed topics, payload fields, units and timestamps.
Keep measurement identity explicit. Record the sensor location, installation depth where relevant, unit, calibration information and quality flags. Soil moisture measured as volumetric water content should not be merged indiscriminately with another device’s relative moisture percentage.
Common information models can help
Standardized descriptions can make device capabilities and data formats easier for software to understand. The W3C Web of Things Thing Description provides a model for describing interactions and associated metadata. Such frameworks offer an interoperability approach, but do not establish that any particular agricultural product implements it.
Automatic discovery and configuration require compatible implementations, supported profiles and appropriate provisioning. Older equipment may still need an adapter or manual mapping. Ask the supplier to demonstrate connection to your proposed gateway or platform with a sample device, rather than accepting a general “open protocol” claim.
Consistent data also matters when records are used for agricultural AI. Training data needs provenance, representative conditions and appropriate labels as well as a consistent format. Merely combining more measurements does not make a model accurate or suitable for a new region.
What Should Buyers Verify Before Choosing Smart Agriculture Sensor Technology?
| Development | Useful capability to verify | Evidence to request |
|---|---|---|
| Edge computing | Local processing, buffering or control | Offline demonstration, model scope where applicable, failure behavior and update procedure |
| Power management | Suitable power and storage for the site | Whole-system power budget and a trial under representative reporting and environmental conditions |
| Hardware improvements | Stable measurement and practical servicing | Application-specific test conditions, drift checks, calibration and cleaning instructions |
| Interoperability | Usable data in the intended system | Interface documentation, sample data, export access and an integration test |
Start with one defined application and an acceptance plan. Specify the required measurement, installation environment, power availability, communication arrangement and the decision or action the reading will support. Test those functions together before extending the deployment.
For a sample review, send Wewin Smart Agri your application, required parameters and ranges, site conditions, power supply, existing gateway or controller, preferred interface, reporting interval, offline requirements and expected quantity. We can help review product matching and the points to confirm for sample evaluation. Discuss your sensor and integration requirements with Wewin. Availability of advanced functions must be checked for the proposed model.
Four Developments, One Practical Goal
The four directions reinforce one another. Local processing needs adequate power. Robust hardware needs a maintenance plan. Shared data needs a clear definition of what the measurements mean. A complete system succeeds when these parts support the same operating task.
The next step in agricultural sensing is therefore more than a smarter chip or another dashboard. It is equipment that can be demonstrated to work in the intended environment, with information that people can understand and act on.
That brings the series to its next question: when reliable technology is available, which applications make the most practical starting point for a commercial deployment? That is the question for the next article.