Why '5 peak sun hours' is wrong for half the year

What a peak sun hour actually is

A peak sun hour (PSH) isn't a count of daylight hours — it's a unit of total solar energy. One PSH equals one kilowatt-hour of sunlight falling on each square meter, the intensity a panel is rated against in laboratory testing (1000 W/m² at standard test conditions). A place that gets 5 PSH in a day received the same total solar energy as if the sun had shone at that lab-test intensity for exactly 5 hours, however the light was actually spread across a longer, weaker real day. It's a convenient number precisely because a panel's rated wattage times its PSH count gives a reasonable estimate of daily energy output — but that convenience only works if the PSH number used is the real one for the real month, not an average pulled from somewhere else.

Where "5 hours" comes from, and why it stops being true

The 5-hour figure is a rough midpoint of annual average PSH across the sunnier parts of the continental United States — the kind of number that's approximately true if you average every month, in a moderately sunny location, and then round. Each piece of that sentence is a place the number can quietly stop applying: a specific month instead of the annual average, a specific location instead of a sunny generality, and the version of the year the system actually has to survive rather than the version it does best in.

Real monthly data for Minneapolis, Minnesota (a mid-latitude, not-particularly-cloudy US city with no unusual weather to make it a bad example) shows the range this collapses:

July's 5.894 PSH is close enough to the "5 hours" rule of thumb to look like confirmation. December's 2.752 is 47% of July's figure — less than half — and even the annual average across all twelve months, 4.6 PSH, undershoots the rule of thumb before winter is singled out at all. "5 hours" isn't wrong because it's an invented number; every value in that table is real, station-derived data. It's wrong because it silently picks one favorable month out of twelve and applies it to all of them.

Why this specific error matters more than a generic "estimates vary" caveat

An off-grid system doesn't get to choose which month its battery has to survive. It has to make it through the actual worst month it will experience, every year, or the owner runs out of power in the exact season — winter, short days, more indoor load — when running out matters most. A system sized against 5 PSH looks correctly sized on paper for ten months of the year and is quietly undersized for the two months when failing is least convenient. That's the opposite of a random estimation error: it's systematically wrong in the same direction, in the same season, every single year.

This project's own array-sizing calculation, arrayBalance(), takes a required daily energy figure and a specific month's real generation rate and returns how much array wattage is actually needed that month — not an annual average, and not whichever month the person doing the math happened to be thinking about.

The same fixed daily load, four different required array sizes

Hold a 3000 Wh/day load constant — a modest off-grid load, roughly what a compressor fridge, lighting, and device charging draws in a day — and run it against Minneapolis's real monthly generation rate for an MPPT-derated array (arrayBalance() applies the standard 90% MPPT derate to every result below). genPerKwDay() converts a month's total generation-per-installed-kW figure into a daily wattage rate for that specific month, which is what actually determines how many watts of panel are needed to meet the load in that month.

An array sized at 566 W — the number July's generation rate would justify, and not far from what a "5 PSH" assumption would suggest — meets the 3000 Wh/day load in mid-summer and falls more than 50% short of it in December, the exact month the same array actually needs to work. Sizing against December's 1211 W instead means the array overproduces for most of the year, which is a real cost in extra panels, but it's a cost paid in cash up front rather than in a dead battery in January. The gap between 566 W and 1211 W on the identical load is the entire argument against "size for 5 hours" in one comparison: more than double the array, for the same house, the same fridge, the same load, depending only on which month's number gets used.

Tilt and location both move this number too

Latitude tilt — angling panels close to the site's latitude — captures more winter sun than a flat mount, because it points the panel more directly at the sun's lower winter arc; a flat-mounted array in the same location sees an even worse winter-to-summer ratio than the table above, not a better one. And Minneapolis is a moderate example, not a worst case: locations farther north or with more winter cloud cover (the Pacific Northwest, for instance) see winter PSH fall to a smaller fraction of their summer peak than Minneapolis's roughly 47%, while dry, low-latitude desert locations see a much flatter year-round curve where "5 hours" is a far more reasonable, if still imprecise, approximation. There is no single replacement constant that works everywhere — which is exactly why a location's own monthly data, not a rule of thumb from a forum post, is the only input that produces a correct answer.

What "sizing for the average month" costs in practice

It's tempting to split the difference and size for the annual average instead of either extreme — Minneapolis averages 4.6 PSH across all twelve months, which sits close to the "5 hours" shortcut and might look like a reasonable compromise. Running that average through arrayBalance() for the same 3000 Wh/day load gives a required array of about 725 W. That array would meet the load from roughly April through September, run short every month from October through March, and specifically fall about 40% short of the load in December — the same month a resistive heater, extra lighting, and a furnace blower motor are likely adding to the load rather than easing it. An "average month" sizing doesn't fail randomly throughout the year; it fails in a predictable six-month block that happens to be winter everywhere the PSH curve is this uneven, because a shortfall in July (when the array overproduces) can't be carried forward to cover a shortfall in December — daily generation has to meet or exceed the daily load close to every day, not just on average over the year, unless the battery bank is oversized specifically to bridge that seasonal gap.

Why a bigger battery isn't a substitute for a correctly sized array

A natural response to a seasonal shortfall is to add battery capacity rather than array wattage — if a few winter days run a deficit, a bigger bank can absorb it. That works for day-to-day weather variation (a string of cloudy days in an otherwise adequate month), but it doesn't work for a structural monthly deficit, because the deficit doesn't stop: if December's array underproduces the daily load by 40% every single day of the month, a battery bank can only bridge that gap for as many days as its capacity allows before it's drawn flat, and then every day after that runs on whatever the array manages to produce, not the load the system was built for. Sizing the array against the real worst month, rather than trying to store enough energy to cover an array that was never big enough in the first place, is both the cheaper and the more reliable fix — battery capacity is for smoothing day-to-day and week-to-week variation around a correctly sized array, not for compensating for a systematically undersized one.

Try it with real monthly data

Enter the daily load and pick a month to see the array wattage Minneapolis's own real PSH data for that month requires, using this project's genPerKwDay() and arrayBalance() functions on the exact figures in the table above.

What to size against instead

Three practical rules follow directly from the data, not from a better rule of thumb:

1. Use the location's own worst realistic month, not an annual or national average. "5 hours" is nobody's real worst month at a real off-grid location in the continental US outside the desert Southwest — it's closer to a good-to-average month almost everywhere else.
2. Check the actual monthly spread before assuming a flat number applies. A location with a wide summer-to-winter ratio (most of the northern half of the country) needs its winter month sized deliberately; a location with a flatter curve (much of the Southwest) can get away with something closer to a single number, but that's a property of the specific location, not a universal shortcut.
3. Bigger isn't automatically better once the worst month is covered. An array sized for December's 1211 W will overproduce for most of the year — that's the tradeoff of solving for the worst case, and it's a knowable, deliberate cost rather than a surprise.

The location pages on this site carry this exact monthly PSH table for every supported location and tilt angle, so the real worst-month number is always one lookup away instead of a borrowed average.