A rechargeable AIO can reach the end of a battery indicator and still leave saleable oil behind. It can also show charge remaining while vapor output has already become unacceptable. In both cases, the commercial problem is not simply “the battery is too small.” The failed boundary may sit in the cell, protection circuit, output logic, heater, liquid delivery path, charging interface, or the test method itself.
That is why nominal milliamp-hours should start an AIO battery discussion, not finish it.
For brands evaluating disposable AIO hardware, the useful release question is more specific:
Under a defined use profile, can the exact filled-device configuration reach its declared end-of-use state without an unresolved battery, delivery, output, activation, or recharge failure?
Answering that question requires a controlled endurance study. It does not require a universal mAh-per-milliliter rule—and no responsible study should pretend that one ratio applies to every oil, coil, voltage, PCB, sensor, preheat routine, and user pattern.
Nominal mAh is an input, not a release result
A cell’s rated capacity is measured under defined conditions. The energy a finished device can use depends on more than the number printed in a specification.
Battery voltage changes under load. Available capacity and voltage behavior can vary with discharge rate, temperature, and the cutoff conditions used by the system. Texas Instruments’ battery-gauge guidance shows why characterization must reflect the expected load range rather than treating nominal capacity as an unconditional runtime value. Analog Devices likewise explains that capacity is specified for particular conditions and that load and temperature influence available charge and voltage behavior.
An AIO adds another layer: the battery is not the only system consuming or controlling energy. The PCB decides when to activate, how output is regulated, when a preheat cycle runs, what the indicator displays, and when low-voltage protection ends operation. The heater’s resistance, working-voltage mode, draw duration, rest interval, and liquid-delivery condition shape the actual demand.
Two devices with the same nominal mAh can therefore reach different practical end states. Conversely, a larger battery does not prove that a device will deliver the intended fill acceptably.
The collection page helps a buyer select an AIO capacity and voltage configuration. This article begins after that selection: it asks what evidence proves the chosen configuration can complete its intended duty cycle. The right comparison is configuration against configuration under one declared protocol.
Freeze the configuration before testing it
An endurance result belongs to the exact build that produced it. Before the first activation, record enough identity to reconstruct that build.
At minimum, freeze:
- AIO model, capacity, and hardware revision;
- cell, PCB, and firmware revision where controlled;
- heater construction and measured or specified resistance range;
- working-voltage mode and activation method;
- preheat availability and intended preheat use;
- oil identity and fill target;
- filling and closure condition;
- charge method and defined starting state;
- conditioning history;
- package state if packaged conditioning is part of the study.
Do not combine results from visually identical units if their PCB logic, resistance, cell source, or firmware differs. “Same shell” is not a technical configuration.
Activation must also remain explicit. A button-operated profile can include manual preheat events that a draw-activated profile does not. Our guide to button versus draw-activated AIO hardware addresses that selection question. In an endurance study, the important point is narrower: whichever behavior is intended for release must be represented consistently in the test profile.
Define end of use before the first run
“Until it stops” is not an adequate endpoint.
A device may stop because low-voltage protection activates, the sensor fails to trigger, the heater no longer receives the intended output, the liquid path stops feeding, or the fill is functionally exhausted. Those are different outcomes.
Define the study’s end state in advance. A program-specific definition might combine:
- the device’s expected electrical cutoff behavior;
- remaining fill or mass-change assessment;
- observable output consistency;
- activation response;
- permitted recharge events;
- leakage, clogging, dry behavior, or other disqualifying anomalies;
- a rule for tests that end ambiguously.
The acceptance criteria must come from the project specification and risk plan. There is no defensible universal number of activations, percentage of residual oil, voltage threshold, or output tolerance for every AIO.
A useful endpoint answers both sides of the question: what happened to the energy system, and what happened to the liquid-delivery system?
Build a representative use profile
An uncontrolled person taking occasional puffs may reveal usability issues, but it does not create a reproducible engineering comparison. A qualification profile should specify the events that materially affect demand.
Record:
- activation duration;
- rest interval;
- voltage setting;
- preheat frequency and duration;
- recharge rule;
- environmental condition;
- orientation or handling cycle where relevant;
- inspection checkpoints;
- stop and hold rules.
The profile does not need to imitate every possible consumer. It needs to represent the intended use case well enough to challenge the release question, while remaining repeatable across samples and configurations.
Avoid false realism. A test that uses random draws, undocumented charging, and changing room conditions may look “real world,” yet it cannot explain why two samples ended differently. Variation can be introduced deliberately later. The baseline comparison should first be controlled.
Texas Instruments guidance on discharge-rate characterization recommends evaluating capacity across relevant rates and expected operating loads. An AIO protocol should apply the same underlying discipline at the finished-device level: define the pulse and rest pattern the device actually experiences, then test that pattern rather than extrapolating from a cell label.
Record the run as a sequence, not a final number
A final activation count hides the story of the device.
Build a run log that can show when behavior changed and which subsystem changed first. Useful fields include:
| Record field | What it helps explain |
|---|---|
| Unit and configuration ID | Which exact build produced the result |
| Starting charge condition | Whether units began from a comparable state |
| Activation/preheat sequence | The demand actually applied |
| Voltage mode and changes | Whether output settings remained controlled |
| Battery indication or state | What the device reported during the run |
| Output observations | When vapor or heater behavior began to drift |
| Remaining fill or mass checkpoint | Whether liquid remained when operation degraded |
| Cutoff and recharge events | Whether the device reached or recovered from an electrical endpoint |
| Leakage, clogging, sensor, or charge-path events | Whether another subsystem ended the test |
| Final disposition | Release, conditional release, hold, or investigation |
Where measurement tools and validated methods are available, teams may add electrical or mass data. The record should still preserve the operating context. A precise measurement attached to an unidentified unit or changing profile is not strong evidence.
Diagnose what ended the test
When oil remains, do not automatically enlarge the battery. First classify the observed end state.
Battery or low-voltage limitation
The device reaches a defined electrical cutoff or cannot sustain the intended output under the test profile, while the liquid path and activation system remain otherwise functional. Confirm that the starting charge, cell/PCB identity, cutoff logic, and recharge rule were controlled before attributing the result to nominal capacity.
Liquid-delivery limitation
The battery can still activate the heater, but the coil is not receiving liquid consistently. Output may fall while charge remains. Changing mAh will not correct an aperture, wicking, oil-compatibility, conditioning, or closure problem.
Heater or output drift
The device continues to activate, yet output changes beyond the program’s limits. Resistance variation, regulation behavior, connection quality, thermal conditions, or accumulated deposits may need investigation. The test record should distinguish this from simple depletion.
Activation-system failure
A sensor or button event fails to produce the intended response even though the battery may retain energy. Intermittent activation should not be counted as ordinary battery exhaustion.
Charge-path or recharge failure
A rechargeable device may fail to accept charge, indicate charge incorrectly, or recover inconsistently. “Rechargeable” is a design feature, not evidence that the intended recharge sequence works across the released configuration.
Ambiguous end state
If the evidence cannot identify the first failed boundary, retain the unit and mark the result unresolved. Forcing it into the “battery life” category creates a confident answer from weak evidence.
Compare samples and conditions without false precision
One successful unit is a demonstration, not a release basis.
The study should cover enough samples, lots, configurations, and relevant conditions to support the actual business decision. The correct plan depends on novelty, risk, intended volume, known failure modes, measurement capability, and the consequence of a missed failure. Those factors should set the sample and acceptance plan; the Blog should not invent a universal quantity.
Consider separating the work into controlled comparisons:
- Repeat the baseline profile across multiple identified units.
- Compare intended voltage or activation modes without changing other variables.
- Add relevant conditioning as a separate factor.
- Evaluate the allowed recharge sequence.
- Re-run only after documenting any hardware, firmware, oil, or process change.
If several variables change together, the test may show that the new combination behaves differently, but it cannot show which change caused the difference.
Keep transport evidence and endurance evidence separate
Lithium-battery documentation matters, but it answers a different question.
UNECE’s Manual of Tests and Criteria, Part III, subsection 38.3 defines a transport-related lithium cell and battery test regime. A test summary identifies the battery type, laboratory, report, tests conducted, and results required by that framework. It does not demonstrate that a filled AIO will deliver its intended oil volume through a representative activation profile.
Our guide to reviewing a disposable AIO UN 38.3 test summary explains that document boundary. Keep the two evidence packages linked to the same controlled configuration, but do not substitute one for the other.
The same applies in reverse: a clean endurance run is not a transport-compliance conclusion.
Convert the evidence into a release decision
An endurance report is valuable only if it changes a decision.
Use three bounded outcomes:
Release. The identified configuration met the project’s predetermined endurance and end-state criteria under the defined profiles and conditions. Record exactly what was tested and what later changes require review.
Conditional release. A limited condition remains, but its scope, owner, closure evidence, and permitted next step are explicit. “Monitor in production” is not a useful condition unless the monitoring method and decision boundary are defined.
Hold and investigate. A criterion was missed, the end state is ambiguous, the tested build did not match the intended configuration, or a change could materially affect the result.
The endurance result should then enter the broader disposable AIO pilot-run evidence package. The pilot controls whether the complete intended configuration and production path are ready to scale. Battery endurance is one focused evidence stream within that larger release decision.
A practical buyer checklist
Before accepting an AIO battery-endurance claim, ask:
- Is the exact hardware, cell, PCB, firmware, heater, oil, fill, and closure configuration identified?
- Was the starting charge condition controlled?
- Does the test profile define activation duration, rest interval, voltage mode, preheat use, and recharge?
- Is end of use defined across both electrical and liquid-delivery behavior?
- Were multiple identified units and relevant conditions tested?
- Does the record show remaining fill when output changed or operation stopped?
- Are battery, delivery, heater, activation, and charge-path failures classified separately?
- Are acceptance criteria project-specific and declared before interpretation?
- Is the UN 38.3 evidence kept distinct from runtime evidence?
- Does every approved result state which changes require requalification?
If the answer is only “the battery has enough mAh,” the release case is incomplete.
Qualify the system that will reach the customer
A large oil chamber and a rechargeable cell do not automatically form a balanced AIO. The balance is created by the complete configuration: stored energy, output control, heater demand, activation behavior, recharge path, oil delivery, environmental condition, and the endpoint the buyer is willing to accept.
A professional endurance study freezes that configuration, applies a declared use profile, records how the device approaches its end state, separates competing failure modes, and converts the evidence into a bounded release decision.
That process produces something more useful than a battery-size promise. It produces a result another team can reproduce, question, and carry into production without guessing what “battery life passed” was supposed to mean.
Editorial note: This article presents a proposed hardware-qualification framework, not a universal industry standard, legal opinion, safety certification, or product-performance guarantee. Test conditions and acceptance criteria must be defined for the specific device, formulation, process, market, and intended use.
