Sizing Solar and Battery for Pond and Shed IoT Nodes in India: Surviving a Week of Monsoon Cloud
125 milliwatts. Run for a day, that is 3.0 watt-hours, the energy budget of a pond node that wipes its probe, reads three sensors every five minutes and reports over a cellular link. Give it a solar panel sized on India's annual average sunshine and a small battery for the nights, and it will work beautifully from October to May. On the fourth day of a monsoon spell it goes dark, and the farm discovers that the one week the pond most needs watching is the week its node was sized to ignore.
This post is a framework for sizing solar power and battery storage for pond and shed IoT nodes in India. The central rule is simple to state and routinely broken: size the panel for the worst cloudy spell you must survive, not for the annual average, and let the battery cover the nights and the short gaps. The rest of the framework turns the rule into steps (budget the load, choose the design sun, size the panel, size the battery, derate for dirt and heat, add firmware that degrades gracefully, simulate the worst spell), and each step has numbers you can rerun.
The sizing code and the simulations in this post were executed, and the outputs are quoted. The wet-spell sunshine values are an illustrative stress test, not a measurement of any site. Before sizing a real node, look up your site's daily or monthly irradiation from a satellite-based source and use a worst spell from it.
A battery buys nights. A panel buys weeks. When the sun stays below the load for ten days, no battery you can afford will carry the node, and the only thing that does is panel margin.
The Framework in Seven Steps
Budget the load in watt-hours per day, from the duty cycle of every part.
Choose the design sun, the sunshine in the worst spell the node must ride through, in peak sun hours on the plane of the panel.
Size the panel from the load, the design sun and the losses.
Size the battery from the autonomy you want, the usable depth of discharge and the efficiency.
Derate for dust, heat, cold, shade and ageing.
Add energy-aware firmware that slows down before the battery empties.
Simulate the worst spell and read the minimum state of charge.
The order matters. Teams usually do step 3 with an annual figure and step 4 with a rule of thumb, and never reach step 7.
Step 1: Budget the Load
Average power is a poor guide, because a pond node is mostly asleep and spends its energy in short bursts. Compute the energy of each burst and sum over a day. The table is an illustrative budget for a pond node with a self-cleaning optical probe, three sensors and a cellular uplink; replace each row with your own measured figures.
Load | How it is used | Energy per day |
Base electronics (microcontroller, regulators, clock, watchdog) | 10 mW average, all day | 0.24 Wh |
Sensor set (optical DO, pH, temperature) | 0.45 W for 30 s, every 5 minutes (288 readings) | 1.08 Wh |
Probe wiper | 3 W for 15 s, 48 times a day | 0.60 Wh |
Cellular uplink | 1.5 W for 24 s, 24 times a day | 0.24 Wh |
Relay and aerator-current interface | 35 mW average, all day | 0.84 Wh |
**Total** | About 125 mW average | **3.00 Wh** |
Two lessons come out of a table like this. First, the radio is rarely the villain on a low-power link. A LoRa uplink of a 33-byte frame at spreading factor 9 takes about 247 ms of airtime; at a transmit current near 44 mA on 3.3 V that is roughly 36 millijoules, or about 0.003 Wh over 288 uplinks a day, a rounding error beside the probe. A cellular modem is a different animal and belongs in the budget at its true cost. Second, the loads that cost the most are the ones that move or heat something: wipers, pumps, heaters, relays. Reducing the wiper from 48 cleanings a day to 24 saves 0.30 Wh, which is more than the entire LoRa radio uses.
Measure, do not guess. Put a current meter with a logging mode in series with the node for a day, or use a power analyser, and reconcile the measurement with the budget. A 20 percent gap between the two is normal on a first pass, and it is better to find it on a bench.
Step 2: Choose the Design Sun
India receives a lot of sunshine, and the annual figures are comfortable. A solar-data summary built on the Global Solar Atlas gives daily global horizontal irradiation of about 4.0 to 5.5 kWh/m²/day across Indian reference sites, and lists Hyderabad at 5.28 kWh/m²/day, which is 5.57 peak sun hours on a panel tilted at the local optimum of 21 degrees. Peak sun hours are numerically equal to daily irradiation in kWh/m²/day, because the reference irradiance is 1,000 W/m².
An annual average is the wrong design input for a node that must work every day. The weather the node must survive is a spell: several days in a row of heavy cloud, storms and rain, with daily sunshine a fraction of the average. The design sun for a battery-backed node is the average sunshine over the worst spell the farm cannot tolerate being blind for, and the minimum in that spell sets the battery's burden.
For the examples below we use a deliberately harsh, illustrative ten-day wet spell, with daily plane-of-array sunshine in peak sun hours of 2.5, 1.5, 1.0, 0.8, 1.2, 0.7, 0.9, 1.4, 2.2 and 3.0. The spell averages 1.52 peak sun hours with a minimum of 0.7. These are not measured values for any place. They are chosen to be bad enough to expose a sizing mistake. To build your own, take daily irradiation for your site from a satellite dataset for the monsoon months of several years, find the worst ten-day window, and use that sequence.
Finding the Worst Spell in Your Own Data
The design sun is the one input in this post that you cannot get from a rule of thumb. It comes from data for your site, and the data has to be read for the right quantity and the right window.
Use daily values on the plane of the panel. Satellite-based solar datasets give irradiation on a horizontal surface, and many also give it on a tilted plane. Peak sun hours are the daily irradiation in kWh/m²/day, so the numbers carry over directly, but a fixed tilt changes them. A solar-data summary that reports both horizontal and optimum-tilt figures shows the difference at Hyderabad: 5.28 kWh/m²/day horizontal against 5.57 peak sun hours at the 21-degree optimum tilt. For a small node, convert to the plane you will actually mount, or use the horizontal value as a conservative proxy.
Use several monsoons. One monsoon is one sample. Pull at least five years of daily values for the months June to October, and ideally more, from a satellite-based dataset such as the Global Solar Atlas or NASA's POWER service, or from a local weather station if one exists. Check the data source's resolution: a grid cell of tens of kilometres smooths local cloud, so treat the results as a guide and add margin.
Find the worst window, not the worst day. A single dark day is survivable. A battery fails in a run of days. The code below finds the lowest-average window of a chosen length in a series of daily peak sun hours:
# worst_window.py -- the cloudiest run of N days in a daily series
def worst_window(daily_psh, n=10):
best_i, best_mean = 0, float("inf")
for i in range(len(daily_psh) - n + 1):
m = sum(daily_psh[i:i + n]) / n
if m < best_mean:
best_i, best_mean = i, m
return best_i, round(best_mean, 2), daily_psh[best_i:best_i + n]
# On a synthetic series with the illustrative spell inserted at day 40:
# worst_window(series, 10) -> (40, 1.52, [2.5, 1.5, 1.0, 0.8, 1.2, 0.7, 0.9, 1.4, 2.2, 3.0])
Run it for several window lengths, such as 5, 10 and 15 days, and for each year. The 10-day window is a reasonable default for a monsoon node, because it spans the spells that farmers describe as "a week of rain". Record the window mean and the window minimum, and use the sequence itself in the simulation, not just the mean, because the order of dark and bright days changes the minimum state of charge.
Choose the risk you will accept. The cloudiest window in ten years is a harsher design than the cloudiest in three. The right choice depends on the cost of being blind.
Risk tolerance | Design window | Typical use |
Nothing may go dark | Worst 10-day window across all years, plus margin | Oxygen alarms on high-density ponds |
A short blind spell is acceptable | Worst 5-day window, adaptive duty to stretch it | Environmental logging where a gap is inconvenient |
Data gaps are acceptable | Median monsoon window | Research and trend nodes |
The sunshine that sizes the panel is the cloudiest run of days you cannot afford to miss, not the average of the year.
Step 3: Size the Panel
The panel must produce, on the design sun, at least the day's load, after the losses between the sky and the load:
# solar_size.py -- panel and battery sizing with explicit losses
def size_solar(load_wh_day, psh_design, pr=0.70, autonomy_days=5, dod=0.8,
batt_eff=0.9, soiling=0.05, vnom=3.2):
pv_wp = load_wh_day / (psh_design * pr * (1 - soiling) * batt_eff)
batt_wh = load_wh_day * autonomy_days / (dod * batt_eff)
return pv_wp, batt_wh, batt_wh / vnom # Wp, Wh, Ah at the nominal cell voltage
for psh in (4.5, 3.0, 2.0):
pv, wh, ah = size_solar(3.0, psh)
print(f"design sun {psh}: panel {pv:.1f} Wp, battery {wh:.1f} Wh ({ah:.1f} Ah at 3.2 V)")
The factors are: a performance ratio of 0.70 for cable, controller, temperature and mismatch losses at this small scale; a soiling loss of 5 percent; and a battery round-trip efficiency of 0.9. A solar-data guide cites an IEA-PVPS report putting soiling at 3 to 5 percent of annual production worldwide, and a dusty Indian site with infrequent cleaning can do worse, which is why the schedule below includes cleaning.
Design sun (peak sun hours) | Panel needed for 3.0 Wh/day | Battery for 5 days of autonomy |
4.5 | 1.1 Wp | 20.8 Wh (6.5 Ah at 3.2 V) |
3.0 | 1.7 Wp | 20.8 Wh (6.5 Ah at 3.2 V) |
2.0 | 2.5 Wp | 20.8 Wh (6.5 Ah at 3.2 V) |
The panel scales inversely with the design sun, and the battery does not depend on it at all. That is the arithmetic behind the opening rule: the sun sets the panel, and the autonomy sets the battery, and the two answer different questions.
Step 4: Size the Battery
Battery energy is the daily load times the days of autonomy, divided by the usable fraction of the pack and the efficiency. Five days of autonomy at 3 Wh/day, with 80 percent usable depth of discharge and 90 percent efficiency, needs 20.8 Wh, which is a 6.5 Ah pack at the nominal 3.2 V of a lithium iron phosphate (LiFePO4) cell. Autonomy is what you buy for nights and short gaps. It is the wrong tool for a long spell, and the simulation shows why.
Chemistry | Strengths | Cautions for pond and shed nodes |
LiFePO4 | Long cycle life, stable chemistry, tolerates heat better than other lithium types | Do not charge below freezing (a concern only at altitude); check the cell's charge temperature range |
Lithium-ion (NMC and similar) | High energy density | Ageing accelerates in heat; protect from enclosure temperatures above the datasheet limit |
Sealed lead-acid | Cheap, tolerant of abuse | Heavy; shortens quickly when left partly charged for long periods, which is exactly what a monsoon spell does |
Supercapacitor | Excellent power, long life | Poor energy density and high self-discharge; a bridge for bursts, not a store for days |
A battery that spends ten days at a low state of charge is a battery that ages. For chemistries sensitive to that, such as lead-acid, a long spell is not just a risk of an outage; it is a cost.
Step 7 First: What the Worst Spell Does to Each Design
The simulation steps through the illustrative spell one day at a time. Each day the panel adds energy (peak sun hours times panel watts times losses), the load removes 3.0 Wh, and the battery is capped at its usable capacity.
# monsoon_sim.py -- state of charge through a cloudy spell
def simulate(load_wh, pv_wp, batt_wh, daily_psh, pr=0.70, soiling=0.05, dod=0.8, eff=0.9):
usable = batt_wh * dod
e = usable # start full
trace = []
for psh in daily_psh:
gen = pv_wp * psh * pr * (1 - soiling)
e = min(usable, e + gen * eff - load_wh)
e = max(e, 0.0)
trace.append(round(e / usable * 100, 1))
return trace
spell = [2.5, 1.5, 1.0, 0.8, 1.2, 0.7, 0.9, 1.4, 2.2, 3.0]
Running it for a 20.8 Wh battery and several panel sizes gives the results below.
Panel | State of charge over the 10-day spell | Minimum state of charge |
1.1 Wp (sized on the 4.5 hour sun) | 92, 80, 66, 51, 38, 22, 8, 0, 0, 0 percent | 0 % (dead from day 8) |
2.0 Wp | 100, 93, 82, 70, 60, 47, 36, 28, 26, 29 | 25.5 % |
3.0 Wp | 100, 98, 91, 82, 76, 66, 58, 55, 60, 75 | 54.7 % |
4.0 Wp | 100, 100, 96, 90, 89, 81, 76, 78, 92, 100 | 76.0 % |
5.0 Wp | 100, 100, 100, 96, 100, 94, 93, 100, 100, 100 | 92.6 % |
6.0 Wp | 100, 100, 100, 99, 100, 97, 99, 100, 100, 100 | 97.1 % |
Three things stand out. A panel sized on average sun fails in the spell, whatever the battery. A panel at the break-even for the spell's average (3.3 Wp here) keeps the node alive but runs the battery down by half, which is acceptable for a lithium iron phosphate pack and unkind to a lead-acid one. And the improvement from 3 to 5 Wp is cheap compared with the cost of a site visit in the rain.
Now compare the case that causes most field failures: a node sized on the annual average sun (5.3 peak sun hours) with two days of autonomy needs only a 0.9 Wp panel and an 8.3 Wh battery. Run through the same spell, its state of charge reads 82, 59, 30 and then zero for the remaining six days. The design is correct for the average day, and the average day is not the one that matters.
Size the panel on the cloudiest ten days you can name, and then check the battery against the same ten days. The average sun is for the sales brochure.
Step 5: Derate for the Real World
The formula above includes a performance ratio and a soiling factor. A few practical factors deserve their own attention:
Dust and droppings. Soiling is the loss that a maintenance schedule controls. A 5 percent allowance assumes the panel is cleaned; in dusty weather, near a poultry shed or under a bird roost, the loss can be several times that. Mount the panel steep enough to shed water and droppings, and add it to the weekly cleaning round.
Tilt. For a fixed panel the best tilt is near the latitude. The solar-data summary lists 21 degrees for Hyderabad. Rain washes a tilted panel, a flat one holds dust.
Heat. Panel output drops as the panel heats, and batteries age faster in a hot enclosure. Put the battery in the shade, ventilate the enclosure, and keep it off a metal roof.
Cold. Lithium cells should not be charged below freezing. This matters at altitude and almost never on a pond in the plains, but check the datasheet for the cell's charge range.
Shade. A shed's edge or a tree can cut a small panel's output sharply for hours. Even a partial shadow on a small panel can disable a whole string; check the shadow path at the worst sun angles.
Ageing. Panels and cells lose capacity with years. Size with 10 to 20 percent margin or plan a replacement date.
Theft and damage. Mount panels out of casual reach, and use bolts that are hard to remove. A stolen panel is a failed node whatever the sizing.
Step 6: Firmware That Slows Down Before It Dies
A node with a fixed duty cycle spends energy at the same rate when the battery is full and when it is nearly empty. A node that adapts will stretch a bad spell. The rule is short: reduce the work as the state of charge falls, protect the alarm path to the end, and restore normal operation with hysteresis so that it does not flap at a threshold.
# duty_by_soc.py -- degrade gracefully as the battery falls
def duty_for_soc(soc: float, recovering: bool = False):
"""Return (report_interval_min, wiper_enabled, watt_hours_per_day)."""
hi, mid, lo = (0.65, 0.35, 0.12) if recovering else (0.60, 0.30, 0.10) # hysteresis on the way up
if soc > hi: return 5, True, 3.0 # normal
if soc > mid: return 15, True, 1.6 # slower cycle, wiper every 12 hours
if soc > lo: return 60, False, 0.7 # hourly, no wiper
return 360, False, 0.15 # heartbeat and alarms only
With the same wet spell, the adaptive rule changes the picture sharply. The marginal 1.1 Wp panel, which was dead for three days under a fixed duty cycle, bottoms out at 29 percent state of charge with the adaptive rule and never loses the node. The 2.0 Wp panel's minimum rises from 25.5 to 44.1 percent, and the 3.0 Wp panel's from 54.7 to 57.6 percent, with little change because it was barely stressed. The cost is data: during the worst days the farm gets hourly readings instead of five-minute ones. That is a good trade when the alternative is no data, and the farm should decide in advance which readings and alarms survive to the end.
Panel | Fixed duty: minimum state of charge | Adaptive duty: minimum state of charge | Days dead (fixed / adaptive) |
1.1 Wp | 0 % | 29.0 % | 3 / 0 |
2.0 Wp | 25.5 % | 44.1 % | 0 / 0 |
3.0 Wp | 54.7 % | 57.6 % | 0 / 0 |
Adaptive duty is insurance, not a substitute for the panel. It earns its place when a panel is marginal, when a spell is longer than the data suggested, or when a panel is partly shaded or dirty.
Charge Control, Protection and Telemetry
A few design points connect the sizing to the electronics:
Charge controller. At a few watts, a simple controller matched to the panel and the cell chemistry is adequate. Choose a panel whose maximum-power voltage suits the battery, avoid wasting a large part of the panel's output in a poorly matched controller, and make sure the controller has the low-temperature cut-off and over-voltage protection that the cell needs.
Low-voltage disconnect. A node must shut down cleanly before the cell is over-discharged, and restart only when the battery has recovered, not at the first ray of sun.
Brown-out behaviour. A microcontroller that restarts repeatedly at low voltage burns energy and corrupts storage. Hold it in reset below a safe threshold and use a supervisor.
State-of-charge estimate. A voltage-based estimate is crude for lithium iron phosphate because the voltage curve is flat. Combine voltage with a coulomb count or a periodic rest-voltage reading, and calibrate against a measured discharge.
Report the battery. Send state of charge and panel current with every message. A falling trend over three days tells the farm to clean the panel or move a shadow before the node dies.
Enclosure, Wiring and Surge Protection
A correctly sized panel and cell still fail if the enclosure leaks, a connector corrodes or a lightning strike arrives down a cable. Monsoon is also thunderstorm season, which means the weeks of low sun and the weeks of surge risk coincide.
Item | Why it matters on a pond or shed | A sound practice |
Enclosure rating | Rain, spray, condensation and washdown | A sealed enclosure with a rating suited to the site, gaskets checked, and a breather or desiccant for condensation |
Cable glands and drip loops | Water follows cables into enclosures | Glands sized to the cable, a drip loop below each entry |
UV-resistant cable | Sunlight cracks ordinary insulation within a few seasons | Cable rated for outdoor use, with the panel lead protected from abrasion and chewing |
Connectors | Salt air and damp corrode contacts | Sealed connectors, no exposed screw terminals, and grease on the contacts |
Fuse near the battery | A short on a lithium cell is dangerous | A fuse or protected cell holder as close to the cell as possible |
Reverse-polarity protection | Maintenance mistakes happen | Protection in the charge path, and polarised connectors |
Surge protection | Storms induce voltages in long cables | A surge device on the panel lead and on long sensor cables, with a short, low-resistance earth |
Mounting | Wind, theft and shading | A rigid mount, tamper-resistant fasteners, and a position clear of shadows at the worst sun angles |
Battery location | Heat shortens life | In the shade, ventilated, off a metal roof |
Earthing deserves a sentence of its own. Surge devices only work with a good, short path to earth, and a node on a pond bund may sit on dry, high-resistance soil in the dry season and wet soil in the monsoon. Test the earth connection when you install, and again after the first monsoon.
A One-Week Bench Test Before You Ship
A node sized on paper is a hypothesis. A week on the bench turns it into a measurement, and every item below catches a mistake that is cheap to fix in the lab and expensive in a pond.
Test | How | Pass criterion |
Energy per day | Log current for 24 hours in the real duty cycle | Within 20 percent of the budget; reconcile any gap |
Battery capacity | Discharge a charged pack at the node's typical current, at room temperature and in a warm box | At least the sized capacity, with margin |
Panel output | Measure panel current at noon and in cloud on a test rig | Matches the data sheet within the expected losses |
Charge path | Run a simulated bright day and a dark day through the controller | Battery tops up when sun returns; low-voltage disconnect and restart behave |
Wet-spell replay | Feed the node a synthetic sun profile from a bench source or by scaling the load | Minimum state of charge matches the simulation |
Adaptive duty | Force low state-of-charge thresholds | Report interval and wiper behaviour change as designed; alarms survive |
Brown-out | Lower the supply slowly | The node resets cleanly and does not corrupt storage |
Enclosure | Spray test and a hot soak | No ingress; battery temperature within its limit |
The wet-spell replay is the one most teams skip, and it is the most revealing. Instead of waiting for a monsoon, scale the daily generation in your own simulation, run the node's firmware with a bench supply that follows the profile, and read the logged state of charge. A node that hits zero on the bench will hit zero in the pond, with fewer people watching.
Replay the worst week on the bench. It is the cheapest monsoon you will ever have.
A Second Example: The Shed Node at 0.4 Wh a Day
The same framework works for a much smaller load, and the comparison is instructive. Take a shed node with a LoRa uplink, a temperature and humidity sensor and no moving parts, drawing 0.4 Wh a day on average. Running the sizing function with that load and a design sun of 1.5 peak sun hours, the spell's average, gives a panel of 0.45 Wp and a battery of 2.78 Wh, which is 0.87 Ah at 3.2 V for five days of autonomy. The break-even panel for the illustrative spell is 0.44 Wp, close to the sizing result, as it should be.
Rounding to practical parts and replaying the ten-day spell through the simulation gives the table below.
Panel | Battery | Minimum state of charge in the spell | Reading |
0.3 Wp | 3.0 Wh | 39.2 % | Survives, but the battery sits low for days |
0.5 Wp | 2.0 Wh | 61.0 % | Comfortable with a small cell |
0.5 Wp | 3.0 Wh | 74.0 % | Good margin for ageing and dirt |
0.6 Wp | 3.0 Wh | 85.5 % | Generous; consider if shading is likely |
1.0 Wp | 3.0 Wh | 100 % | Over-sized for this load |
A half-watt panel and a three-watt-hour cell are small, cheap parts, and the node rides through a spell that would flatten a pond node ten times larger on a panel sized the same way. The sizing rule scales with the load, and the margin that matters is the same: panel above break-even for the worst spell.
The alternative for a load this small is a primary lithium cell and no panel. A large lithium thionyl chloride cell of 19 Ah at 3.6 V holds about 68 Wh. At 0.4 Wh a day it lasts about 171 days, or roughly 120 days with a sensible margin, so a farm would replace it two or three times a year. At a tenth of the load the same cell lasts years and the panel is not worth its maintenance. The break-even between the two sits at a daily load of a few tens of milliwatt-hours: below that, a primary cell wins on simplicity; above it, a panel wins on running cost, provided someone cleans it.
Match the energy source to the load. A cell wins below a few tens of milliwatt-hours a day, a small panel wins from a few hundred milliwatt-hours, and above that you are sizing a power system and not a sensor.
A Pond Node and a Shed Node Through One Monsoon
A representative composite, genericised, shows how the framework plays out. A farm ran two types of solar node: a pond node with a wiper and cellular uplink at the 3.0 Wh/day budget above, and a shed node with a LoRa uplink and no moving parts at 0.4 Wh/day. Both were sized in the dry season on a design sun of 5 peak sun hours with two days of autonomy.
In the first monsoon, the pond node went dark on the fourth day of a stormy week, and the farm lost its oxygen alarms for the three nights that mattered. The shed node, with a load an order of magnitude smaller, rode through on the same relative margin. The farm re-sized the pond node on the worst ten days of the previous three monsoons, which gave a design sun near 1.5 and a panel of about 3.3 Wp at the break-even, and chose 5 Wp for margin. It cut the wiper from 48 to 24 cleanings a day and added the adaptive duty rule. The next monsoon, the node's state of charge bottomed out above 50 percent in the worst week, and the farm's weekly panel-cleaning round became the maintenance task it checked first when the battery trend sagged. The numbers in this account are illustrative of the pattern. What generalises is the order of events: the average-sun design failed in the first bad spell, the worst-spell design fixed it, and the adaptive rule and the cleaning round kept it fixed.
When Solar Is the Wrong Answer
Loads in the tens of watts. An aerator controller or a pump will need mains or a much larger system, and the framework above will mislead. Size those from first principles with an electrician.
Places with mains and a stable supply. A small mains adapter with a backup cell may be cheaper and more reliable than a panel that needs cleaning.
Very small loads. A node that draws a few hundred microwatts on average may do better with a primary lithium cell and no panel, as our earlier post on battery chemistry argues.
Shaded or theft-prone sites. If the panel will be in shade or will not survive unattended, a larger battery on a controlled replacement schedule is the honest design.
No one to clean or check it. A solar node is maintained. If nobody will wipe the panel, size the soiling loss at 20 percent and plan for it.
Starting on Monday
Measure the node's energy over a full day with a logging current meter, and rebuild the load table from it.
Pull daily irradiation for your site for the last three monsoons, find the worst ten-day window, and use that sequence in the simulation.
Run the sizing code with your measured load and the spell's average sun, and choose a panel at or above the break-even.
Choose the battery for nights and short gaps, with autonomy of three to five days, and the chemistry for your temperatures.
Simulate the chosen panel and battery through the worst spell and read the minimum state of charge; aim to stay above 40 to 50 percent.
Add the adaptive duty rule and decide which readings and alarms must survive to the end.
Report battery state and panel current in every message, and alarm on a three-day downward trend.
Add the panel to the cleaning round, and log each visit.
What the Sun Owes You and What It Does Not
India's sunshine is generous on average, and a well-sized node uses it for most of the year. The days that matter are the ones the average hides. Size for the cloudiest week you can name, protect the alarm path with firmware that retreats gracefully, and keep the panel clean. A node that survives the monsoon with half a battery to spare is a node the farm stops thinking about, which is the best thing an instrument can be.
EurthTech is an engineering-first product design and embedded systems company with a development center in Hyderabad. To discuss a project, write to connect@eurthtech.com or see https://www.eurthtech.com/case-studies.
Comments