Why battery labs run out of channels
Most test benches are busy for hours or days per job. Battery cyclers are different: a cycle-life test holds a channel for months, and calendar-ageing studies come back for check-ups at fixed intervals for a year or more. Capacity decisions made today determine which projects can start next quarter.
- Long, overlapping tests — a new request can wait weeks for a free channel even if the lab looks half empty on average.
- Coupled resources — a channel is useless without chamber space at the required temperature, and high-current tests may need several channels in parallel.
- Unplanned occupancy — cells that fail, tests that are repeated, and channels down for calibration or repair.
- Invisible backlog — requests sit in e-mails and spreadsheets, so the real demand only becomes visible when channels are already full.
Step 1: estimate test durations
Channel demand is only as good as the duration estimates behind it. Derive them from the test profile, not from gut feeling, and correct them with the actual durations of past tests.
| Test type | How to estimate duration |
|---|---|
| Cycle life | Time per cycle × number of cycles. A 1C/1C cycle with CC-CV charge and rest periods takes roughly 2.5–3 hours, so 1,000 cycles means around 100–125 days on one channel. Add periodic reference performance tests. |
| Calendar ageing | Cells mostly sit in storage, not on a channel. Plan channel time only for the check-ups (capacity, internal resistance) at each interval. |
| Characterisation (capacity, DCIR, HPPC, OCV curves) | Sum of the profile steps including thermal soak — typically hours to a few days per cell. |
| Drive-cycle and application profiles | Profile length × repetitions; watch for current limits that require paralleled channels. |
Step 2: from channel-hours to channel count
- 1
Sum the demand
Channel-hours = Σ (cells × test duration in hours) over all tests that will run in the period. Only count the part of a long test that falls into the period.
- 2
Add a retest margin
Add 10–15 % for failed cells, repeated tests and extensions. Use your own historical rate once you have it.
- 3
Set a target utilisation
Plan for 75–85 %, not 100 %. Changeovers, calibration, maintenance, waiting for cells and weekends without staff all consume channel time.
- 4
Divide
Average channels needed = channel-hours with margin ÷ (hours in period × target utilisation).
Worked example: one quarter
A quarter of 13 weeks has 2,184 calendar hours. The backlog for the quarter contains three kinds of work:
| Work package | Channel-hours |
|---|---|
| Cycle life: 24 cells × 1,200 h | 28,800 |
| Characterisation: 40 cells × 30 h | 1,200 |
| Calendar-ageing check-ups: 36 cells × 4 check-ups × 15 h | 2,160 |
| Subtotal | 32,160 |
| + 10 % retest margin | 35,376 |
At 80 % target utilisation, one channel delivers 2,184 h × 0.8 ≈ 1,747 channel-hours per quarter. On average the lab therefore needs 35,376 ÷ 1,747 ≈ 20.3, i.e. 21 channels.
Now look at the timeline. If all 24 cycle-life cells must start in week 1, they occupy 24 channels for 50 days. If the 40 characterisation cells arrive in the same two weeks, they add about 1,200 h ÷ 336 h ≈ 4 channels, and the check-ups about one more. Peak demand is about 29 channels — roughly 40 % above the average of 21. Staggering only helps once the batches stop overlapping: a second batch of 12 cycle-life cells starting in week 6 still overlaps the first for about two weeks (peak around 25); starting it in week 9 brings the peak down to about 17, but roughly 5,200 channel-hours then move into the next quarter. Buying channels for the peak or moving work between quarters is a planning decision, not a hardware decision.
Calculator: try it with your own backlog
Enter your own work packages below. The calculator applies the same steps as this guide — channel-hours with retest margin, target utilisation, and the peak on a weekly timeline — so you can see immediately whether staggering starts or more channels solve the problem.
Calculate channel demand from your backlog
Enter your planned tests. The worked example from this guide is pre-filled — everything is calculated in your browser, nothing is stored.
Work packages
Channel-hours incl. margin
35,376
Channels on average
21
1,747.2 h per channel at target utilisation
Channels at once (peak)
29
in week 1
The average says 21 channels, the peak needs 29. Either plan for the peak or stagger starts (increase "spread over") until the peak is close to the average.
Channels in use at once per week (peak); line = average demand
The calculator does not check temperature groups or climate chambers — calculate each temperature separately.
In TestLabIQ this forecast is calculated from your real schedule — per station type, with what-if scenarios.
Request a demoStep 3: check chambers, parallel channels and downtime
- Temperature groups: tests at 25 °C, 45 °C and −10 °C cannot share a chamber. Plan channel demand per temperature, then check each chamber's space and cable feed-throughs.
- Paralleled channels: high-current cell or module tests may use two or more channels each; count them as such.
- Calibration and maintenance: take cyclers and chambers out of the plan for their calibration dates and service windows.
- Safety constraints: abuse-adjacent tests or large-format cells may need dedicated chambers with gas detection or venting — a separate capacity pool.
In many labs the chamber, not the cycler, is the binding constraint. A channel count that looks sufficient on paper still produces a queue if all the requested tests need the same temperature.
Keeping the forecast current
A one-off spreadsheet forecast is outdated as soon as the first cell fails. The forecast stays useful when it is fed by the same data the lab runs on:
- Every request enters one backlog with cell count, test type and requested start date.
- Planned tests are scheduled on concrete channels and chambers, so conflicts show up before the cells arrive.
- Actual start and end times are recorded for every test, so duration estimates improve with every test.
- Channel and chamber occupancy per week is visible to project managers, not only to the lab lead.