Ask why one remote SCADA site runs flawlessly on the same panel that leaves another dead every winter, and the answer usually comes down to a single number that was misunderstood at the design stage: peak sun hours. It is the figure that converts the sunlight a location receives into a usable input for sizing a panel and battery, and it is routinely confused with the far larger and far more flattering number of daylight hours. This page defines what peak sun hours actually measures, explains why it is so much smaller than the hours of daylight, and shows how installers pull the right worst-month value from irradiance data to drive real sizing.
Peak Sun Hours in one line: Peak sun hours is the number of equivalent hours of full-strength sunlight a location receives per day, where full strength means the standard reference intensity that solar panels are rated against. It is not the number of hours the sun is up; it compresses a whole day's varying sunlight into an equivalent count of hours at peak intensity, so a site with many hours of daylight may have only a few peak sun hours. It is the single most important input in field solar sizing, because the daily energy a panel produces is essentially its wattage multiplied by the site's peak sun hours, and using the worst-month value is what keeps a SCADA site alive through winter.
Peak sun hours is a way of boiling a whole day of changing sunlight down to a single, useful number. Over a day the sun's intensity rises from nothing at dawn, climbs to its strongest around midday, and falls back to nothing at dusk, and a panel's output follows that curve. Peak sun hours takes the total energy that curve delivers and expresses it as the number of hours you would need at the one standard reference intensity, the full-strength value panels are rated at, to deliver that same total energy. So a location with, say, a certain number of peak sun hours receives, across its whole day of weak-to-strong-to-weak sun, the same total energy as it would from that many hours of steady full-strength sun.
This is why peak sun hours is always smaller, usually much smaller, than the number of hours the sun is above the horizon. A day might offer ten or twelve hours of daylight, but for much of that time the sun is low and weak, delivering only a fraction of full intensity, so the equivalent full-strength hours might be only three, four, or five. The gap between daylight hours and peak sun hours is the whole point of the concept: it strips out the weak early and late sun and the effect of the sun's angle, leaving only the amount of usable energy, which is what a panel actually converts to power.
The reason this matters so much for sizing is that panel output tracks peak sun hours almost directly. To a good approximation the daily energy a panel produces is its wattage multiplied by the site's peak sun hours, before losses, so the peak sun hours figure is the multiplier that turns a panel's rating into a daily energy yield. That makes it the natural bridge between the sunlight resource and the sizing arithmetic, and it is why every solar sizing calculation runs through peak sun hours rather than through daylight hours or any other measure of how sunny a place feels.
Installers do not estimate peak sun hours by eye; they pull it from solar resource data for the specific location. That data comes from irradiance maps and databases built from years of measurement and modelling, which report how much solar energy a location receives, typically as an average per day for each month of the year. From those figures you can read the peak sun hours for the site broken down month by month, which is essential because peak sun hours is not a single fixed number for a place; it swings substantially with the seasons, high in summer when the sun is strong and the days are long, low in winter when the sun is weak and the days are short.
That seasonal swing is exactly why the worst month, not the annual average, is the figure that drives SCADA sizing. A remote SCADA site has to run every day of the year, including the darkest weeks, so it must be sized against the month with the least sun, which for a site far from the equator is usually a deep-winter month. Sizing against the annual average would leave the site well supplied in summer and badly short in winter, and a site that fails for the darkest weeks has failed, so the relevant peak sun hours is the lowest monthly value the location will see. This is the number installers extract from the resource data and carry into the panel and battery calculations.
There are refinements that shift the figure a little, chiefly the tilt and orientation of the panel, because peak sun hours as commonly quoted assumes a particular panel angle, and aiming the panel to favour the low winter sun can raise the worst-month value at the cost of some summer yield. On an off-grid SCADA site, where the design constraint is entirely the worst month and there is usually surplus in summer anyway, tilting the panel steeply to capture more winter sun is a common and sensible move that improves the number that actually matters. The key discipline throughout is to use location-specific, worst-month, correctly-tilted peak sun hours rather than a generic or annual figure, because the whole reliability of the site rests on that one input being honest.
Peak sun hours sits at the heart of the chain that sizes a remote SCADA power system, feeding directly into both the panel and, through it, the battery. The panel wattage needed is the site's daily energy load divided by the worst-month peak sun hours and then inflated for system losses, so peak sun hours is the divisor that sets how big the array must be. Because a lower peak sun hours means a bigger, more expensive array for the same load, getting this number right, and not accidentally using an optimistic annual or daylight figure, has a direct and large effect on the cost and reliability of the site, which is why it deserves the care it is given.
It also underpins the battery sizing indirectly, because the days of autonomy the battery must cover are the days when the site gets little or no sun at all, and the worst-month peak sun hours frames how thin the margin is between the array keeping up and falling behind. In the darkest month the array is barely meeting the load on a good day and cannot keep up at all on a cloudy one, so the battery has to carry the difference, and understanding just how low the worst-month peak sun hours goes is what tells you how hard the battery will be worked. The two sizings are linked through this single number describing how little sun the worst part of the year offers.
For an operator running many remote sites into a cloud SCADA platform such as Merobix, peak sun hours is also the yardstick that turns raw field data into a judgment about site health. By comparing the actual daily charge a site is receiving against the peak sun hours its location should be delivering for the season, staff can tell whether a site that is running low on power is simply experiencing a normal low-sun stretch, which peak sun hours predicts, or whether the panel is genuinely underperforming from soiling, shading, or a fault, which shows up as charge well below what the season's peak sun hours would predict. That comparison, expected sun versus delivered charge, is what separates a weather problem from an equipment problem across a fleet of sites without visiting any of them.
Daylight hours simply counts how long the sun is above the horizon, while peak sun hours counts the equivalent hours of full-strength sunlight, compressing a whole day of weak-to-strong-to-weak sun into an equivalent number of hours at the standard reference intensity. Because the sun is weak near sunrise and sunset and at low angles, peak sun hours is always smaller, often much smaller, than daylight hours, so a site with ten hours of daylight might have only three or four peak sun hours. Panel output tracks peak sun hours, not daylight hours, which is why sizing must use the smaller figure.
They pull them from solar resource data, meaning irradiance maps and databases built from years of measurement and modelling, which report how much solar energy a location receives, usually broken down by month. From that data an installer reads the peak sun hours for the specific site month by month, which is necessary because the value swings with the seasons rather than being a single fixed number for a place. For SCADA sizing the figure that matters is the worst month's value, typically a deep-winter month for sites far from the equator.
Because a remote SCADA site must run every day of the year, including the darkest weeks, so it has to be sized against the month with the least sun rather than the average across the year. Peak sun hours varies strongly with the seasons, high in summer and low in winter, and sizing to the annual average would leave the site well supplied in summer but badly short in winter. Since a site that fails for the darkest weeks has failed regardless of its summer performance, the worst-month value is the correct and conservative input for sizing.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.