Rainy Season Autonomy Sizing (Worst-Month PSH) — EPC Review-Safe Method

Table of Contents

Autonomy sizing rainy season solar street lighting why projects fail after 2-4 cloudy days worst month PSH recovery margin

If your solar street lighting project starts failing after 2–4 cloudy days, it’s usually not “bad luck”.

It’s almost always an autonomy sizing error — caused by sizing against annual average sun hours, ignoring derating losses, or hiding energy gaps behind “battery Ah” labels.

Engineer’s rule: You don’t buy “autonomy days”. You buy an auditable energy balance designed for the worst month.
✅ Need a tender-ready pack in 24H (autonomy sizing sheet + DIALux/Relux + IES/LDT + BOQ mapping)?
Request here →

EEAT / Scope note: This article is a screening method used in EPC/government reviews. Final sizing should be confirmed with site conditions, project targets, and declared assumptions.

Quick Answer (60 seconds)

Rainy-season failures happen when the system can’t meet two conditions in the worst month:

1) Survive the cloudy spell (battery usable Wh covers the nights)
2) Recover SOC between cloudy spells (PV harvest surplus restores charge)

A “3 nights autonomy” label is meaningless unless the bid shows this evidence chain:

Worst-month PSH → Nightly Load (Wh) → Derating chain → Usable Battery (Wh) → PV Harvest (Wh/day) → Recovery Margin → Pass/Fail

If any link is missing, the bid is not comparable and often not reviewable.
✅ Want a fast sanity check? Upload any ONE item (BOQ / map pin / wattage & hours) → Request now

Module 1 — The “Worst-Month Autonomy Evidence Chain” (What Reviewers Trust)

This is the only chain that survives an EPC or donor audit.
If a supplier skips one step, you are not buying a system — you are buying risk.

Worst month autonomy sizing evidence chain for solar street lighting PSH load derating usable battery PV harvest recovery margin pass fail

Worst-month sizing evidence chain: PSH → load → derating → usable Wh → PV harvest → recovery margin → pass/fail.

Audit language you can copy into tender clarifications:

  • “Provide worst-month PSH basis and dataset reference (or a clearly declared proxy assumption).”
  • “Provide usable battery energy (Wh) with DoD + temperature + aging factors.”
  • “Provide PV harvest vs nightly load in worst month with recovery margin.”

Data basis (avoid overclaiming): Worst-month PSH should be based on a traceable dataset (e.g., NASA/POWER, PVGIS) or a clearly stated proxy assumption used consistently across bids.

Why Mauritania + Togo Fail for Different Reasons (Same Root Cause)

These two climates break weak designs in different ways:

Mauritania (Sahel / desert-to-coastal)

  • Dust/soiling reduces PV harvest (especially before and after storms)
  • Coastal salt corrosion accelerates connector and sealing failures (Nouakchott / Nouadhibou)
  • High temperatures push batteries and drivers outside “lab conditions”

Togo (West Africa monsoon pattern)

  • Multiple consecutive cloudy days reduce PSH sharply
  • Humidity + rain exposure punishes weak IP sealing and cable routing
  • Recovery windows between storms can be short — PV must “catch up” fast

Different symptoms, same engineering truth: worst-month energy balance decides survival.

The Evidence: “Annual Average PSH” Is the Trap

Most failed bids size using annual average PSH because it makes the PV look smaller and the price look cheaper.

But solar radiation is not stable across months.

The “Average vs Worst Month” deficit (what kills projects)

If a site has:

  • Annual average PSH: 5.0–5.5h
  • Worst-month PSH (rainy season): 3.0–3.8h

Then sizing on annual average creates a ~25%–40% energy deficit in the worst month — before losses.

And that deficit shows up on site as:

  • early dimming (SOC protection)
  • random shut-offs after day 2–4
  • battery damage from deep cycling
  • complaints, disputes, and rework

Module 2 — “Good Quote vs Bad Quote” (De-AI + High-Conversion Filter)

If you want to look like a real engineer wrote this: this section does it.
It’s blunt, and it saves EPC teams months.

Item Bad Quote (Red Flag) Good Quote (Review-Safe)
Solar data “PSH 5.5h (avg)” (no month) “Worst-month PSH = 3.4h, dataset stated”
Battery “100Ah LiFePO4” “Usable Wh stated + DoD limit + aging factor”
Autonomy claim “3 nights autonomy” (no math) “Nightly load vs usable Wh shown (pass/fail)”
PV sizing “Panel 200W” (no harvest calc) “PV harvest Wh/day in worst month shown”
Recovery Not mentioned Recovery margin ≥ 1.15–1.30× declared
Dimming “12 hours @ 100%” Energy-aware profile (segments + % + Wh calc)
Evidence Marketing sheet only Evidence pack: BOQ → IES/LDT → DIALux → qty
Good vs bad autonomy sizing quote table rainy season solar street lighting worst month PSH usable Wh recovery margin dimming profile

Good vs Bad quote: the fastest way to reject non-auditable bids before they waste your schedule.

Hard rule: If they can’t show the math in a table, it’s not “cheaper” — it’s not comparable.

Technical Qualification Gate (Non-Negotiable Rules)

Use this as your tender clause / technical gate.
If any of these are missing, the offer is not technically qualified:

1) Worst-month sizing: autonomy must be sized against worst-month PSH, not annual average
2) Wh, not Ah: battery must be stated in usable Wh with DoD + temperature + aging assumptions
3) Recovery margin: PV harvest must exceed nightly load by ≥ 1.15×–1.30× in the worst month
4) Energy-aware dimming: “100% power all night” without an energy profile = automatic flag
5) Assumptions must be auditable: every key input must be traceable to a stated assumption, a dataset, or a test record

No worst month. No usable Wh. No recovery. No valid comparison.

✅ Want us to audit a supplier bid fast? Upload the BOQ / map / targets✅ Want us to audit a supplier bid fast? Upload the BOQ / map / targets: → Request now

Standards & References (How to Use Them Without Overclaiming)

You don’t need to “follow every standard” in every country.
But you must cite what your acceptance and reporting is aligned to.

What you’re proving Why it matters in rainy season Common reference
Road lighting targets & uniformity Rainy season exposes darkest points and uniformity issues EN 13201 / IES RP-8 / CIE 115
PV module safety/performance (if required) Low irradiance + humidity punishes weak modules IEC 61215 / IEC 61730
Ingress protection (water/dust) Humidity + storms = sealing becomes failure trigger IEC 60529 (IP)
Impact protection Transport + installation damage is common on projects IEC 62262 (IK)
Commissioning documentation discipline EPC acceptance needs traceable records, not “looks fine” IEC 62446 (documentation framework)

Practical rule: Standards don’t help if the bid doesn’t show traceable evidence.

The Audit-Ready Sizing Protocol (What Reviewers Trust)

Step 1 — Lock worst-month PSH (not annual)

State:

  • location basis (city / coordinates or climate proxy)
  • worst-month PSH assumption used for sizing
  • whether dust/soiling factor is applied (Sahel projects often need it)

Step 2 — Calculate nightly load in Wh (not just “W”)

Nightly energy must match the operating profile:

  • operating hours per night
  • dimming schedule (segments + % power)
  • controller overhead + driver losses

Step 3 — Apply a derating chain (make the design honest)

At minimum, declare:

  • controller/driver efficiency assumption
  • battery usable fraction (DoD limit)
  • temperature factor (hot coastal / hot Sahel)
  • aging factor (2–3 year capacity fade baseline)

Step 4 — Add recovery margin (this is what most quotes miss)

Even if you survive 3 cloudy nights, you still fail on day 4–6 if you can’t recharge fast enough.

Practical rule: In the worst month, PV harvest should be 1.15×–1.30× nightly consumption
to recover SOC between rain spells (declare your assumptions).

Case Logic (Mauritania + Togo): What Failure Looks Like in Real EPC Audits

Case A — Togo rainy spell: “3-night autonomy” but shutdowns on day 3–4

Symptoms

  • Units dim earlier than schedule
  • Random OFF events after consecutive cloudy days

Audit findings
1) PV sized with annual average PSH, not worst-month
2) Battery quoted in Ah only (usable Wh not stated)
3) No recovery margin; SOC never catches up between storms
4) Dimming profile assumed too aggressive (near-constant high power)

Fix

  • Re-size with worst-month PSH + derating chain
  • Add PV harvest surplus (recovery margin)
  • Adjust profile: peak hours full power, late-night reduced

Case B — Mauritania: not only rain — dust + coastal corrosion turns into “autonomy failure”

Symptoms

  • Output drops faster than expected after dust events
  • Increased failure rates at connectors, sealing points, fasteners
  • Battery performance deteriorates in high heat

Audit findings
1) PV soiling loss ignored → real PSH effectively lower than “data PSH”
2) IP sealing quality and cable routing not verified → moisture ingress accelerates faults
3) Coastal corrosion not addressed in materials and fasteners
4) Energy balance had no buffer; any loss triggers shutdown behavior

Fix

  • Add soiling factor + maintenance interval assumptions
  • Upgrade sealing verification and corrosion protection requirements
  • Keep recovery margin so the system survives real-world losses

Engineer takeaway: In Sahel projects, “autonomy” is not just battery days — it’s energy + durability.

Module 3 — What to Upload for a 24H Autonomy Audit (Start With ONE Item)

Send any ONE item to start (unknown is OK):

  • BOQ template (even incomplete)
  • LED wattage & operating hours per night
  • Google Map pin + city name (climate proxy)
  • Target autonomy nights (e.g., 3 nights / 5 nights)
  • Any existing quote you want us to audit

What to upload for 24H autonomy sizing audit rainy season solar street lighting BOQ LED wattage operating hours map pin quote

Send ONE item and we can start the rainy-season autonomy audit within 24H.

Upload / request here →

What you receive within 24H:

  • A pass/fail autonomy check (worst-month + recovery margin)
  • A gap list (what assumptions are missing / risky)
  • A bid-comparison view (which supplier is hiding energy deficits)

What to Ask Suppliers (Copy-Paste RFQ Lines)

Paste these into your RFQ / tender clarifications:

1) Provide worst-month PSH used for sizing and state the data basis (or proxy assumption).
2) Provide battery usable Wh with DoD + temperature + aging assumptions.
3) Provide PV daily harvest vs nightly load in the worst month and show recovery margin ≥ 1.15×–1.30×.
4) Provide dimming profile (segments + % power) and energy calculation.
5) State low-SOC behavior (dim-to-off thresholds) and recovery behavior after cloudy days.
6) Provide evidence pack mapping: BOQ → model → IES/LDT → DIALux/Relux → qty.

If they refuse any of these, they are not selling a solution — they’re selling a dispute.


FAQ (Rainy Season Autonomy)

1) Is “3 nights autonomy” always enough in rainy season?

Not necessarily. The real risk is recovery. If PV cannot restore SOC between storms, the system fails even with a “3-night” label.

2) What’s the #1 mistake in rainy-season sizing?

Using annual average PSH instead of worst-month PSH.

3) Why do you insist on Wh instead of Ah?

Because performance is governed by usable energy, and Ah labels hide DoD limits, temperature losses, and aging.

4) Do we need to run 100% power all night?

No. That is usually a high-risk assumption. A review-safe design uses an energy-aware dimming profile while protecting safety-critical hours.

5) What’s a practical recovery margin rule?

In the worst month: PV harvest should be ≥ 1.15×–1.30× nightly consumption to recover SOC between cloudy spells (with declared assumptions).

6) What should we upload to get a 24H engineering answer?

Any ONE of: BOQ template, map pin + notes, or an existing quote.
Request here → /engineering-support/#request-now

Next Step

Rainy-season failures are not “weather problems”. They’re math + assumptions + traceability problems.

If you want a bid that survives review and survives the rainy season:

✅ Worst-month sizing + derating chain
✅ Recovery margin (SOC rebound)
✅ Energy-aware dimming profile
✅ Auditable evidence pack (BOQ → IES/LDT → DIALux/Relux → qty)

Request an audit-ready engineering pack (24H) →

About the Author (EEAT)

Reviewed by: Solar Street Lighting Engineering Team, Sunlurio
We support EPC/government tenders with audit-ready deliverables: sizing sheets, BOQ mapping, IES/LDT photometrics, and DIALux/Relux reports.
Start here: engineering-support
Quality & verification: manufacturing-and-quality
Reference projects: projects

Picture of Stephen

Stephen

Hello Customers,

My name is Stephen. I’m with Sunlurio, and I have over 15 years of experience in the street lighting industry. I focus on street lighting system configuration, tender documentation support, and project-based solutions. Feel free to contact us—I’m happy to help with the right deliverables for your project.

Email: info@sunlurio.com | WhatsApp: +86 186 5321 8098

Contact Us

Download Catalog

Inside the Catalog:

  • Detailed product listings with high-resolution images
  • Technical specifications and customization options
  • Case studies and project examples
  • Competitive pricing information

Download our comprehensive catalog to explore our wide range of street lights and solar street lights, designed to meet the highest standards of quality and efficiency.

Request Your Custom Quote – No Middlemen

Request Your Custom Quote – No Middlemen

Request Your Custom Quote – No Middlemen

Request Your Custom Quote – No Middlemen