Frame from supplied battery-test video showing an operator and connected cells beside a computer. It provides process context only; it does not establish runtime, current, capacity, cutoff, sample identity or a pass result.
A runtime number is useful only when the buyer can reproduce the battery state, operating mode, load and cutoff behind it. Before approving a rechargeable portable light, define the test record that turns “lasts eight hours” into evidence another team can inspect.
This guide is for US private-label flashlight and portable-light brands at sample approval or pre-shipment planning. It does not prescribe a universal runtime, battery capacity or discharge current. Those values belong in the approved product specification for the selected model and market.
Browse NIGHTFIELD buyer insights for related function, photometric and environmental evidence guides.
Start with the job and the mode
Runtime depends on what the user asks the light to do. A high mode, low mode, flashing mode, sensor mode and standby state can draw different loads and can trigger different thermal or control behavior. Start by naming the job, the mode and the minimum useful output rather than asking for one headline number.
Write the mode sequence in the test request: steady output or cycling, brightness setting, control lock, sensor state and whether the product is allowed to step down. The supplied frame shows a connected battery setup, not a confirmed portable-light mode or a measured result.
Freeze the sample and battery state
Record the model, sample ID, revision, firmware or driver revision, cell type, cell count, protection board and charger. For a rechargeable product, state the charging method, charge termination indication and rest time before the runtime check. For a replaceable cell, record the brand or approved equivalent and the starting voltage rule.
Do not treat a fresh cell, a fully charged pack and a partially charged pack as interchangeable. A runtime result without its starting state cannot tell a buyer whether two samples were tested under comparable conditions.
| Record before start | Why it matters | Do not infer |
|---|---|---|
| Product model, revision and sample ID | Connects the result to the approved configuration | That another revision has the same runtime |
| Cell type, count, source and protection | Defines the energy source and safety context | That a different cell is an equivalent substitute |
| Charge method, end state and rest time | Makes the starting condition repeatable | That a charger indicator proves full capacity |
| Mode, control setting and step-down rule | Defines the load the user will actually see | That one mode result covers every mode |
Define the load and cutoff
A runtime test needs a clear end point. The cutoff may be a defined light-output threshold, automatic shutoff, protected-cell cutoff, loss of the approved mode or another buyer-approved rule. State which event ends the clock and how it is observed.
Keep the electrical load and the user-visible result together. If a driver steps down before shutoff, record the time and the condition instead of reporting only the final off time. If the product is tested through a fixture rather than its normal optics, label that as a different electrical check.
Use the portable-light function inspection checklist for button, charging and indicator observations. Use a separate photometric method when the acceptance rule is expressed as lumens, lux or beam distance.
Control the environment and placement
Record ambient temperature, humidity when relevant, airflow, mounting position and any enclosure or heat sink used during the test. A light on a bench, in a closed housing or attached to a vehicle can shed heat differently. The same battery and mode can therefore produce a different user-visible result.
Environmental values should be recorded as test conditions, not claimed as product capability. When a temperature or humidity exposure is part of the program, connect the runtime check to the approved sequence and use the temperature and humidity evidence guide for the chamber record.
Log the curve, not just the final hour
Keep a time-stamped record of start state, output step-downs, warnings, charging or protection events, temperature observations and the final cutoff. A short video can help locate an event, but it does not replace the test sheet or the instrument record.
| Event | Minimum record |
|---|---|
| Start | Sample ID, mode, cell state, charge method, rest time and clock start |
| During run | Time stamps for step-downs, warnings, control changes and temperature observations |
| Cutoff | Time, observed trigger, remaining indicator state and safety condition |
| After run | Reactivation, recharge behavior, housing condition and evidence file names |
Separate runtime from related claims
A runtime result does not by itself prove lumen output, beam distance, battery capacity, ingress protection or long-term ageing. Those are separate questions with their own methods and acceptance limits. Keep the evidence linked by sample ID, but do not let one test stand in for another.
The existing rechargeable-light buyer brief helps frame battery, charging and service questions early in selection. This page is narrower: it defines the repeatable record needed when a sample is being approved or released for inspection.
Use defect codes that describe the mismatch
Short codes make it easier to compare samples without pretending to know the root cause. Keep the first failure, any correction and the recheck as separate records.
| Code | Observable mismatch | Evidence to keep |
|---|---|---|
| RUN-01 | Starting battery state or sample identity is missing | Label photo, charge record and unit ID |
| RUN-02 | Mode, control setting or placement differs from the approved request | Setup sheet and action/result video |
| RUN-03 | Step-down, warning or cutoff occurs outside the defined rule | Time-stamped log and instrument trace |
| RUN-04 | Unsafe heat, swelling, leakage or protection behavior is observed | Safety stop record and before/after photos |
| TRC-01 | Result cannot be linked to a lot, revision or test file | Lot record, sample ID and evidence index |
Connect the result to the lot decision
One passing sample supports only that sample and condition. Before production release, agree how units are selected across the lot, how many modes or repetitions are required and what counts as a critical, major or minor mismatch for the order. Record the purchase order, lot reference, unit number, sample revision, date and disposition.
Do not replace a failed first result with a later pass after a battery, driver or firmware change. Record the original failure, the correction, the recheck condition and the final decision so the history remains useful.
NIGHTFIELD’s manufacturing and quality coordination can help connect the approved sample, evidence request, supplier response and outgoing inspection across manufacturing partners.
Repeat the check after meaningful changes
Repeat the relevant runtime check after a change that can alter energy use or heat behavior. Typical triggers include a cell supplier, capacity, protection board, driver, LED, optic, firmware, control logic, charger, housing, heat path, mounting position or approved operating mode.
A cosmetic change may need only a document review, while an electrical or thermal change may require a full runtime recheck. Write that decision and its reason so an old result cannot be mistaken for evidence of the new configuration.
Send this runtime-test request before approval
- Identify the model, sample ID, revision and intended user job.
- State the mode, control setting and any allowed step-down behavior.
- Record cell type, count, source, protection and charging method.
- Define the starting charge state, rest period and placement.
- State ambient conditions, airflow and any enclosure or fixture.
- Define the cutoff event and how it will be observed.
- Log start, step-down, warning, cutoff and post-run events with time stamps.
- List safety, charging, control and reactivation checks after the run.
- Connect each unit to the lot, sample plan and acceptance rule.
- List changes that trigger a partial or full repeat check.
Frequently asked questions
Does a battery-test video prove a runtime claim?
No. It shows process context only. Buyers still need the product identity, battery state, operating mode, load, cutoff rule, timestamps and written acceptance criteria.
What battery state should a runtime test record?
Record the cell type and source, charge method, end-of-charge indication, rest time and starting voltage or state rule agreed for the product. A generic “full battery” label is not enough to reproduce the condition.
Should every mode receive its own runtime result?
Yes when the modes have different loads or are sold as separate user promises. State the mode and any step-down sequence instead of using one result as a proxy for every setting.
Can one passing sample represent a whole production lot?
It supports only the identified sample and condition. Lot-level decisions require an agreed sampling plan, traceability and acceptance limits for the specific order.
When should runtime testing be repeated?
Repeat the relevant check after a change that can alter energy use or heat behavior, such as a cell, driver, LED, optic, firmware, charger, housing or approved mode change.
Source note: the article image uses a frame from user-supplied video in the designated Nightfield material library. It shows an operator, connected cells and a monitoring setup as process context only and does not claim runtime, current, capacity, certification, customer order or NIGHTFIELD-owned facility.