Solar panel size calculator
Calculates the required array power from daily demand and the sun hours at your location — in the plane of your modules and for the weakest month of the chosen operating period, not from a rule of thumb. The difference is drastic: 2,400 Wh/d need 8 modules in Berlin at 35 degrees south, 17 mounted flat, 4 for summer-only use. Plus the itemised efficiency chain and a design temperature from the month’s sunlit hours instead of a blanket 20 degrees.
The formulas behind the calculator
Every number above can be recomputed: the full calculation path, all assumptions and the data source with retrieval date — plus cross-validation against independent references. Disclosed, not claimed.
An estimate based on the stated assumptions. The final design must be checked by a qualified professional against the rules that apply where you are.
Data as of: 2026-07-30
| Step | Formula | Value | Provenance |
|---|---|---|---|
| Module temperature | T_a + G / (u0 + u1 * W) | 30.609 °C | measured |
| Temperature factor | eta_rel(G_norm, T_m - 25) | 0.98382 | measured |
| System efficiency | Π eta_i | 0.7366 | assumed |
| Array power | E_day / (PSH * eta_sys) | 3,151.9 Wp | exact |
- Formula
P_array = E_daily / (PSH · η_sys)- Valid for
- Sized for the weakest month of the chosen period. Sun hours in the module plane and the design temperature come from the site hourly year (PVGIS-SARAH3 TMY, calibrated) — the same chain as calculators 23 to 28; the temperature is the mean over SUNLIT hours of the design month, not the whole month. Efficiency chain itemised, module temperature after Faiman, relative efficiency after Huld. Reference case: 2,400 Wh/d in Berlin, 35 degrees south → December, 1.03 h/d, 6.4 °C, 3,152 Wp (eight 400 Wp modules).
- Not covered
- Shading from nearby objects (the terrain horizon is included, a tree in front of the window is not), tracking, bifacial rear-side gain, snow on the modules, partial-shading mismatch beyond the blanket mismatch factor.
- Data sources
- JRC Photovoltaic Geographical Information System (PVGIS), European Commission — endpoints tmy, MRcalc, printhorizon · PVGIS API v5_3, solar radiation database PVGIS-SARAH3 · retrieved 2026-07-30
Frequently asked questions
How many solar panels do I need for my daily consumption?
Required power = daily energy ÷ (design PSH × system efficiency). At 2400 Wh/day, 1.07 PSH (Berlin, 35°, December) and about 75% system efficiency that is roughly 3000 Wp — close to eight 400 Wp modules. The design month is decisive: using the annual average of 3.7 PSH would suggest only 870 Wp, and the system would be empty from November to February.
Why does the calculator derive module temperature instead of assuming a flat 0.75?
Because the temperature factor genuinely moves between summer and winter. The calculator determines module temperature with the Faiman model from ambient temperature, irradiance, wind and mounting, and derives the efficiency factor per Huld — roof mounting costs about 13 K and 6.5% power versus free-standing. Every factor of the chain is reported individually, multiplied together as PVGIS prescribes.
Is battery efficiency included here?
Yes — but only on the charge side, and that is the difference to many competing calculators: round-trip efficiency belongs in the generation chain (the energy must get into the battery), not additionally on the discharge side. Counting it twice makes results 8–15% too pessimistic. The battery-runtime calculator mirrors this by leaving it out.
Why design for the worst month — and what does it cost?
Designing for the annual mean leaves you in the dark in December: at the example site December delivers 1.07 PSH, the annual mean three times that. The monthly chart shows both options honestly: December design means year-round autonomy but large summer surpluses; April design means a third of the module power but many winter days in deficit. From about a factor of 3 between winter and mean design, the calculator notes that a small generator for the winter gap is usually more economical.
What is wrong with the blanket 0.75 factor?
It is wrong in both directions. The efficiency chain has seven named links — soiling, mismatch, cable, charge controller, battery round trip, temperature, ageing — and this calculator computes the temperature link with Faiman/Huld for month and mounting: in a German December, cold modules are more efficient than at standard conditions (factor ≈ 1 or above); on a Spanish summer roof it is ≈ 0.86. A fixed factor hits neither case, and every link is individually editable.
What does a PWM controller really cost me versus MPPT?
The calculator prices it as extra module demand: in the reference case (2,400 Wh/day, 3.1 PSH) MPPT needs about 1,191 Wp, PWM about 1,445 Wp due to the poorer controller efficiency (0.80 instead of 0.97) — 21% more module power. At today’s module prices that usually eats the PWM price advantage; the “PWM penalty” tile shows your specific number.
Where do the design sun hours come from?
From your location and the plane of your modules. Previously a fixed value of 1.07 hours per day sat here — Berlin, 35 degrees tilt, December. Anyone calculating for Freiburg, mounting flat or facing east still got 1.07. Now the same calibrated hourly calculation runs as in the peak-sun-hours calculator: 35 degrees facing south in Berlin gives 1.03 hours in December, 5.72 in the best month.
How much does the mounting change the result?
Drastically. The same 2,400 Wh per day need 3,152 Wp in Berlin at 35 degrees facing south — eight 400 Wp modules. Flat on the roof of a van it is 6,683 Wp and thus 17 modules. The reason is the December sun: at 52 degrees north it stands so low that a horizontal surface catches only a fraction. This is exactly the calculation a fixed default cannot do.
What does designing for summer only save?
Half the modules. If you use your vehicle from April to October, you size for the weakest month of that season instead of December: 2.75 instead of 1.03 sun hours, 1,215 instead of 3,152 Wp, four instead of eight modules. Notably the weakest month of the summer season is October, not April — again a result from the data, not a convention.
Why use the temperature of sunlit hours?
Because a module only heats up while it is producing. The monthly mean includes the nights and is therefore too low; the blanket 20 degrees previously in the form is far too high for December. For Berlin it is 6.4 degrees during December sunlit hours. That gives a module temperature of 30.6 instead of 44.2 degrees — and about three percentage points more system efficiency.
Why was the old default still close to the right answer?
Because two errors partly cancelled, and only for the exact case it was tuned to. The assumed 1.07 sun hours were slightly too high (smaller array), the assumed 20 degrees far too warm (larger array). For Berlin at 35 degrees this produced 3,177 Wp against the correct 3,152 Wp. As soon as location or orientation change, that coincidence disappears.