Sizing Solar for a LoRaWAN Gateway You'll Never Visit Again

The real failure mode

You've run the RF path analysis. The link margin is comfortable, the spreading factor is negotiated, the gateway is on the ridge. Then four months later you discover the hardware has been offline since December — not because the link failed, but because the battery went flat.

Off-grid IoT deployments in mountainous terrain fail on power more often than on radio. The reason is usually the same: someone applied a flat-irradiance estimate to a location that is not flat. They used regional average daily irradiance, ignored the effect of surrounding ridges on early-morning and late-afternoon production, and sized the battery for a summer-calibrated worst case rather than a real winter one.

At the Atlas Mountains in Morocco — our worked example for this post — a gateway site near the Tizi n'Tichka pass at approximately 2,260 m elevation sits in a valley where the south-facing horizon is partially blocked by the ridgeline that forms the southern wall. PVGIS v5.2, using the Copernicus GLO-30 digital elevation model, will account for that horizon obstruction. A lookup of the regional average for 31°N will not.

The difference in computed battery autonomy between the two estimates can easily be 20–40% in winter months — more than enough to explain a December outage.

Why LoRaWAN gateways are power-constrained in a way sensors are not

LoRaWAN end-nodes are almost always battery-powered and almost always duty-cycled. A typical Class A sensor wakes every 15 minutes, transmits for a few hundred milliseconds, and sleeps the rest. Its average current draw is in the tens of microamps.

A gateway is different. It is always-on: it must listen on all eight channels simultaneously, maintain a backhaul connection (cellular, satellite, or unlicensed mesh), and run the LoRaWAN Network Server interface. A compact single-board gateway with a cellular modem typically draws 300–800 mA continuously at 5 V, depending on cellular signal quality, CPU utilization, and thermal throttling behavior.

That continuous draw changes the sizing problem. You cannot rely on the gateway averaging down to microamps. The daily energy budget is roughly V_sys × I_avg × 24, and it does not compress with clever firmware. You need to produce enough solar energy every day — including the worst production day of the year — to keep the battery above its minimum state of charge.

Gateway monitoring data, where it exists, almost always shows the failure pattern: battery voltage declines gradually through autumn, then drops sharply in late November or December when irradiance falls and a sequence of cloudy days depletes the reserve. The hardware does not fail — it simply runs out of energy.

What PVGIS v5.2 actually computes

The European Commission's PVGIS tool (Photovoltaic Geographical Information System, version 5.2) is the reference dataset FresnelPath uses for solar irradiance estimation. It combines satellite-derived irradiance data from the SARAH-3 (Europe/Africa/Middle East) and ERA-5 (global fallback) datasets with a PV performance model and, critically, terrain horizon data from the EU-DEM or global equivalent.

The computation has two distinct stages.

The first stage is the optimal-tilt calculation. Given a geographic location, PVGIS returns the annual irradiance at the optimal fixed-tilt angle for that location's latitude. This is the number most people use when sizing a solar installation.

The second stage is the battery autonomy simulation. Given a panel size (Wp), a battery capacity (Wh), a daily load (Wh), and a horizon profile derived from the local DEM, PVGIS simulates day-by-day production and consumption across a representative multi-year period and identifies the fraction of days the load cannot be met.

The second call is the one that matters for off-grid IoT. And it is the one that flat-irradiance estimates entirely skip.

Why the horizon matters more than the panel tilt

Panel tilt is a second-order optimization. For a fixed horizontal panel, you lose perhaps 10–20% of annual production relative to the optimal tilt at mid-latitudes. You can recover most of that by tilting toward the equator at the appropriate angle — roughly equal to latitude for year-round average.

Horizon obstruction is a first-order loss, and in mountain terrain it can dominate everything else. A ridge that blocks the sun until 09:30 at winter solstice effectively eliminates two to three hours of production on the worst days of the year. At high latitudes or in deep mountain valleys, the sun may never clear the horizon at all for weeks around the December solstice.

FresnelPath computes the horizon profile by ray-marching outward from the site across the GLO-30 DEM at 36 azimuths (10° spacing). For each azimuth, it finds the maximum elevation angle to any DEM cell within the relevant radius. The resulting 36-point horizon profile is passed to PVGIS as the usehorizon / horidata parameter pair, which PVGIS uses in the internal solar geometry calculation to mask production hours when the sun is below the local horizon.

At the Tizi n'Tichka site, the southern ridgeline produces a horizon elevation of approximately 6–8° in the south-southwest quadrant. That sounds modest. But at 31°N in December, the sun's maximum elevation at local noon is only about 36°. An 8° horizon obstruction in that azimuth range delays first light by roughly 30–40 minutes and reduces the available production window meaningfully on short winter days. Over the battery sizing simulation, that difference consistently shifts the verdict from acceptable to marginal.

The four reference days

PVGIS's battery autonomy simulation uses a multi-year historical record, not a single representative day. But for diagnostic purposes, FresnelPath surfaces four reference days to show users how production varies across the year: the two equinoxes (approximately equal day/night) and the two solstices (maximum and minimum sun elevation).

These four days are not arbitrary. They are the inflection points of the annual irradiance curve. If a site is viable on the December solstice, it is viable year-round. If it is borderline in September (post-summer with increasing cloud probability at some latitudes), that signals a risk that a summer-calibrated estimate would miss entirely.

The intent is not to replace the full multi-year simulation — it is to give the engineer an intuition for which time of year the site is at risk, and whether to increase panel or battery capacity to address it.

Verdict bands

The solar analysis in FresnelPath returns a verdict rather than a raw number. The verdict classifies the site based on how many low-production days occur in the PVGIS simulation relative to the battery reserve's capacity to absorb them:

• Viable. The site has sufficient production to keep the load met across virtually all simulated days, including the worst production sequences. Deploy with confidence.

• Marginal. The battery goes into deficit on a meaningful number of days per year, typically concentrated around the winter solstice. The site may work, but a larger panel or battery is warranted before deployment.

• Undersized. The production shortfall is severe enough that the system will routinely fail in winter months regardless of good component selection. The site or the load assumption needs to change.

The bands reflect real engineering judgment about what constitutes tolerable risk for a gateway you cannot easily visit. A sensor node going offline for a few days is a data gap. A gateway going offline for a few days silences an entire cluster of end-nodes. The acceptable failure rate is correspondingly lower.

System losses: IEC 61724

Solar panels do not deliver their nameplate wattage under field conditions. The gap between rated power and actual delivered energy is called the system loss, and it comes from multiple sources: temperature derating (panels are rated at 25°C; warmer panels produce less), cable resistance, charge controller efficiency, battery round-trip efficiency, and soiling.

FresnelPath applies a system loss factor consistent with IEC 61724, the international standard for PV system performance monitoring and analysis. The standard provides guidance on how to account for these losses in energy yield calculations. The exact percentage used in the calculation depends on the installation class (a well-maintained commercial installation vs. a dusty remote enclosure), but the methodology follows the IEC framework rather than a rule-of-thumb.

For remote IoT deployments, soiling is often the underappreciated loss. A panel in a high-dust environment or under seasonal snowfall accumulation can lose 10–20% of production before it is cleaned. If the site is accessed infrequently, that degradation compounds. The conservative approach is to size the panel as if it will be dirty for several months of the year.

Worked example: Tizi n'Tichka, Morocco

The Tizi n'Tichka pass sits at approximately 2,260 m elevation on the main road crossing the High Atlas from Marrakesh to Ouarzazate. It is a well-documented geographic feature with publicly available DEM coverage in GLO-30. It represents a realistic off-grid IoT scenario: high elevation, road-adjacent but not serviced, EU868 frequency band (Morocco), and surrounded by ridgelines that produce measurable horizon obstruction in multiple directions.

The site coordinates are approximately 31.26°N, 7.38°W. PVGIS v5.2 returns a horizontal irradiance of approximately 5.8 kWh/m²/day annually at optimal tilt for this latitude — a high-irradiance location by global standards, which might lead a naive sizing calculation to be optimistic.

The horizon profile from GLO-30, however, shows elevation angles of 4–9° in several directions due to the surrounding ridgelines. In December, when the sun's path stays low, these obstructions eliminate a meaningful fraction of what PVGIS would otherwise compute for a flat-horizon site at this latitude.

The practical outcome depends on exact panel and battery sizing, but the pattern is consistent: horizon-aware simulation produces a more conservative winter-month estimate than flat-horizon PVGIS for this site class, and that difference is typically what determines whether a nominal sizing is genuinely viable or borderline marginal in December.

This is exactly the failure mode that flat-irradiance calculations miss — not because Morocco is a low-irradiance environment (it isn't), but because the specific site is valley-constrained in ways that the regional average cannot capture.

Practical checklist for off-grid LoRaWAN gateway sizing

The link–power co-analysis workflow

The standard approach is to plan RF and power separately: run the path analysis in one tool, size the solar in a spreadsheet, and hope they both work at the same location. The problem is that the best RF site and the best solar site are often different places — a ridge crest may have excellent line-of-sight to the node cluster but poor south-facing exposure due to its own topology.

FresnelPath integrates both analyses under the same DEM. The RF path profile and the solar horizon analysis both read from the same GLO-30 elevation data for the candidate site. That means you can compare a ridge-crest site (excellent RF, possibly compromised winter solar due to the steep topography around it) against a south-facing false summit slightly below (good solar, marginally reduced RF coverage) using consistent data for both decisions.

The solar verdict appears alongside the link analysis in the results panel. If the site scores marginal on power and comfortable on RF, you have a concrete basis for trying an alternative candidate 200 m in a different direction, rather than guessing.

Summary

Flat-irradiance estimates are adequate for rooftop installations on buildings with unobstructed southern exposure. They are not adequate for off-grid IoT gateways in mountain terrain, where the surrounding ridgelines can shadow the sun for hours each day in winter and the consequences of a dead gateway are a silent network, not a missed export record.

The analysis that actually protects you has three parts: a horizon profile derived from the local DEM, a battery autonomy simulation using a multi-year irradiance record, and a verdict grounded in the failure tolerance appropriate for always-on infrastructure rather than interruptible sensors.

The December solstice is the design case. Size for that, and the rest of the year takes care of itself.