What Happens When a Solar System Fails Its ASTM E2848 Capacity Test?

A failing ASTM E2848 capacity test is not the end of the road — but it is a signal that something needs attention. Whether you are an EPC contractor facing a contractual deadline, an asset owner trying to close a transaction, or an independent engineer validating a new installation, a Capacity Test Ratio (CTR) below the agreed threshold triggers a chain of investigation, remediation, and retesting that can take days or weeks if not handled efficiently.

This article walks through what typically happens after a failed test, the most common root causes, and how to get back to a passing result as quickly as possible.

Why a Failed Test Matters Commercially

ASTM E2848 capacity tests are almost always tied to contractual milestones. In most EPC agreements, passing the test is a condition for achieving substantial completion or provisional acceptance. A failed test can trigger several consequences depending on the contract structure: the EPC contractor may owe performance liquidated damages for each percentage point the system falls short of the guaranteed capacity, delay liquidated damages may start accruing if the retest pushes past the guaranteed completion date, and in the worst case the owner may have the right to reject the plant entirely if performance falls below a minimum threshold.

Even outside of strict EPC contracts, a failing capacity test creates uncertainty for asset buyers, lenders, and insurance providers who rely on test results to underwrite their financial models. The faster you can diagnose and resolve the issue, the less commercial damage accumulates.

Step 1: Verify the Test Setup Before Blaming the System

Before assuming the PV system itself is underperforming, it is worth ruling out problems with the test procedure. A surprising number of failed tests turn out to be caused by analytical or instrumentation issues rather than genuine system deficiencies.

Check the Regression Model Configuration

The ASTM E2848 regression equation relates system power to plane-of-array irradiance, ambient temperature, and wind speed. For this to work correctly, the right data columns need to be mapped to the right terms in the equation. In practice, this is where human errors creep in most easily: assigning the wrong SCADA channel to the irradiance term, mixing up front-side and rear-side POA sensors on a bifacial system, using a temperature sensor from the wrong location, or accidentally mapping gross power instead of net power to the output variable. For sites with multiple subarrays, the weighted-average POA irradiance calculation is another common source of mistakes — using the wrong area weights or forgetting to include an orientation entirely will skew the regression. Even small configuration errors like these can produce a CTR that is several percentage points off, which is often enough to turn a passing test into a failing one.

Check the Simulation Model

Separately from the regression setup, it is worth reviewing the reference simulation — typically a PVsyst model — that defines the expected capacity. If the simulation was built with outdated module parameters, an inaccurate shade model, or a weather file that does not represent actual site conditions, the benchmark itself may be unrealistic. Common issues include shading simulations that do not match as-built conditions, albedo assumptions that differ from the actual ground cover, and module datasheet parameters that were updated between the design and construction phases.

Check the Sensors

Sensor accuracy is the foundation of any capacity test. Irradiance sensors that have drifted out of calibration, temperature sensors with poor thermal contact, or anemometers that are partially obstructed will inject systematic errors into the regression. POA irradiance sensors deserve particular scrutiny: even a small angular misalignment between the sensor and the actual module plane can introduce a bias that makes the system appear to underperform.

As a rule of thumb, all sensors should have been calibrated within the 12 months before the test, and the POA sensor mounting should be visually verified to match the module tilt and azimuth at the start of every test campaign.

Check the Data Filtering

ASTM E2848 requires data to be filtered for minimum irradiance levels, inverter clipping, stability, and other criteria. Overly aggressive filtering can remove too many valid data points, leaving a dataset that is too small or biased toward a narrow range of conditions. Conversely, insufficient filtering can leave noisy data that inflates the regression error. Review the filter summary to understand how many data points were removed at each step and whether the remaining dataset is representative.

Step 2: Investigate the System

If the test setup checks out, the next step is to look at the system itself. This is where time-series analysis of inverter and weather data becomes essential. Rather than looking only at aggregate numbers, plot the measured power alongside irradiance, temperature, and wind speed over the entire test period and look for patterns.

Inverter-Level Analysis

Compare the output of individual inverters against each other and against what the model predicts for their respective subarrays. A single underperforming inverter can drag the whole-site CTR below the passing threshold. Common inverter issues include firmware that limits output below the rated capacity, MPPT tracking errors caused by misconfigured string voltages, communication faults that cause intermittent shutdowns, and thermal derating due to poor ventilation or excessive ambient temperatures.

If one or more inverters are consistently producing less than their peers under the same conditions, that is a strong signal to inspect those units specifically.

Module and String Performance

When the issue is not at the inverter level, it may be distributed across the array. Soiling — dust, pollen, bird droppings, or other debris on the module surface — is one of the most common and most easily overlooked causes of underperformance. Even a thin, uniform layer of grime can reduce output by several percent, and heavy soiling can reduce it much more.

Other array-level issues to investigate include partial shading from vegetation that has grown since commissioning, damaged modules with micro-cracks or hot spots that may not be visible to the naked eye but show up clearly on thermographic inspections, and wiring problems such as loose connectors, blown fuses, or ground faults in individual strings.

Sensor and Measurement Errors Revisited

Sometimes the system investigation reveals that a sensor problem is the root cause after all — not a calibration drift, but a physical issue like a cracked pyranometer dome, a temperature sensor that has detached from the module back sheet, or a data logger with clock synchronization errors that misalign the weather and power time series.

Step 3: Fix What You Find

The specific remediation depends on what the investigation turns up. In practice, the most common corrective actions fall into a few categories.

Equipment repairs: Replacing blown fuses, reseating loose connectors, updating inverter firmware, or swapping out a failed inverter entirely. For string-level issues, I-V curve tracing can help pinpoint exactly which modules or connections are at fault.

Module cleaning: If soiling is the culprit, a professional cleaning of the array before retesting is straightforward and often produces an immediate, measurable improvement in output.

Sensor realignment or replacement: If the POA irradiance sensor is misaligned or a temperature sensor has failed, correcting or replacing it before collecting new test data is essential. There is no point running a retest with the same measurement error that caused the original failure.

Model correction: In some cases, the right fix is not on the physical system but in the reference model. If the PVsyst simulation used incorrect module parameters, an unrealistic albedo value, or a shade model that does not match as-built conditions, updating the model may be more appropriate than modifying the plant. This requires agreement between the parties — owner, EPC, and independent engineer — since changing the reference model changes the benchmark against which the system is measured.

Step 4: Collect New Data and Retest

After remediation, you need fresh measured data for the retest. ASTM E2848 requires a minimum of 50 valid data points that pass all filtering criteria, which typically means several days to a few weeks of clear-sky data collection depending on the season and location.

A few practical considerations for the retest: avoid mixing pre-remediation and post-remediation data in the same test dataset, because the regression needs to reflect the current state of the system. Make sure the reporting conditions are recalculated from the new dataset per ASTM E2939 unless the contract specifies fixed reporting conditions. And document everything — what was found, what was changed, and why — so the retest results are defensible in an audit.

The time pressure here can be significant. Every day spent collecting new data is a day closer to the contractual deadline for substantial completion. Having a streamlined, repeatable test workflow makes a real difference when you are on your second or third test attempt.

Step 5: Review the Results and Close Out

Once the retest produces a passing CTR, the result needs to be documented in a clear, audit-ready report that includes the regression model, the data filtering summary, the capacity comparison at reporting conditions, and the measurement uncertainty analysis. The report should also reference any remediation actions that were taken between the original test and the retest so that reviewers understand the full history.

If the retest still does not pass, the cycle repeats: investigate further, remediate, collect new data, retest. In the worst case, if the system genuinely cannot meet its guaranteed capacity — for example because of a fundamental design shortfall or widespread module underperformance — the contract provisions for performance liquidated damages or plant buy-down payments come into play.

How Heliotest Helps You Iterate Faster

The investigate-fix-retest cycle is where manual processes and spreadsheet-based tools create the most friction. Each iteration requires uploading new data, reconfiguring filters, rerunning the regression, and regenerating the report — all steps that take hours when done by hand and minutes when automated.

Heliotest is built for exactly this workflow. Because site configuration is saved between test runs, retesting after a remediation is as simple as uploading the new measured data and clicking run. The platform generates an audit-ready PDF report with all the required plots, filter summaries, and metadata automatically, so you do not have to maintain a separate reporting template. And its built-in test result analysis features help you pinpoint underperforming inverters or anomalous data patterns before you even go back to the site.

For sites with additional complexity — bifacial modules, multiple array orientations, or GHI-only sensor setups — Heliotest handles the additional calculations natively, so the retest does not require custom scripting or manual workarounds.

Key Takeaways

A failed ASTM E2848 capacity test is a starting point, not a dead end. The path back to a passing result follows a clear sequence: verify that the test itself was set up correctly, investigate the system using time-series data analysis, fix what you find, collect new data, and retest. The faster and more systematically you can move through this cycle, the less commercial impact the failure has.

If you are currently managing this process with spreadsheets or one-off scripts and want to see how a purpose-built tool handles the iterate-and-retest workflow, Heliotest offers a free tier so you can try it on your own data.