How to Test and State Battery Life for a Voice AI Device Honestly

Illustration

Define each usage profile first, then measure whole-device current on the battery rail for each one, and print the profile beside the hours. A chip datasheet gives chip-level current only. The FTC says an ad needs substantiation for what it actually communicates, so a best-case figure needs proof for that exact case.

A voice AI device does very different things in one day: it sleeps, it listens, it uploads audio over Wi-Fi and it plays an answer. One "battery life" number cannot describe all of that. This guide helps a product manager choose usage profiles, build a current budget from published chip data, plan the measurements on a real board, and avoid a headline figure that the product cannot reproduce. It contains no measured result and no Duobay price. The only numbers come from the FTC and Espressif pages linked below. For measuring sleep current and radio bursts, see How to Measure Sleep Current on Microamp Devices. For testing a small device with a battery emulator, see Battery emulator for device testing: what it does and when to use it.

What does the law say about a battery claim?

This is an engineering team's summary of three published texts. It is not legal advice, and we draw no legal conclusion from it. Please have a lawyer confirm how these texts apply to your claim. We found no FTC rule written specifically for battery life, so the first two rows are the general policy for objective claims.

The 16 CFR 255.2 text was read through a Cornell Legal Information Institute reproduction of the regulation. Compare it with the eCFR original before you rely on it. The FTC quotes above should also be checked against the live page.

Which usage profiles should the claim name?

Pick the profiles before you measure anything. Each profile gets its own number, and the number is always printed with the profile. A figure without a profile has no conditions, so nobody can check it.

The profile in the claim should be one that a buyer would plausibly reproduce. If the most flattering profile is the only one in the test file, the file supports only that profile.

How do you budget current from a chip datasheet?

A budget shows where the charge goes, so you know what to measure. Treat it as a planning aid and keep it out of the claim. The table lists published currents for one voice-capable chip, the Espressif ESP32-S3, as of October 31, 2026. It describes that chip alone. Other voice chips differ, and none of these rows includes the microphone, codec, speaker amplifier, power management or the battery. If your device has a screen, add the display as well. OLED vs LCD for small device displays explains how its power depends on what it shows.

The model

I_avg  = Σ ( I_i × d_i )            Σ d_i = 1
h      = C × k / I_avg

I_i    current in state i, mA
d_i    fraction of time in state i, unitless
C      battery rated capacity, mAh
k      usable fraction of rated capacity, unitless
h      runtime, hours

Only the I_i for the chip comes from a source. C, k and every d_i are your assumptions to replace. The usable fraction k depends on your cell, your cutoff voltage, your temperature and the age of the cell, and the datasheet says nothing about it. Measure it. A capacity test standard such as the IEC 61960 series exists, but we have not read its full text and quote no threshold from it.

A worked example from the datasheet numbers alone

Question: how much radio time per day does it take for the radio to dominate the chip's average current? Take the Deep-sleep floor at its lower published value, 7 µA, which is 0.007 mA. Take Wi-Fi receive at 88 mA. With a receive duty cycle d and sleep for the rest of the time:

I_avg = d × 88 + (1 − d) × 0.007            mA

Set the radio term equal to the sleep term:
d × (88 − 0.007) = 0.007
d = 0.007 / 87.993 = 0.0000795   (about 0.008%)

Per day: 0.0000795 × 86,400 s = about 6.9 s

Receiving for about 6.9 seconds a day already doubles the chip's average current over its own Deep-sleep floor. Repeating the calculation with the 283 mA transmit peak gives about 2.1 seconds a day, and that peak is rated at a 100% duty cycle, so treat it as an upper bound. The point of the example is the order of magnitude. The same chip draws 88 mA over 7 µA in two states, a ratio of about 12,600. A battery figure built on standby alone tells you almost nothing about a device that connects to Wi-Fi to answer a question. These are chip-level inputs. Your whole device adds other loads, and the real answer comes from the measurements below.

What goes wrong with battery claims?

These items follow from the published figures above and from the FTC texts. They are engineering reasoning, not accounts of any company's incident.

• Treating a chip sleep row as a device figure. The Deep-sleep rows are 7 to 8 µA for the chip. The microphone, codec, amplifier and power management add their own current, and the datasheet does not include them. A claim built on the chip row has no basis for the whole device.
• Averaging a peak. The transmit peak of 283 to 340 mA is rated at a 100% duty cycle. Using it as the average overstates drain, and ignoring it understates the pulses your battery and regulator must supply. Keep both the peak and the average in the file.
• Assuming one chip current for all work. The Modem-sleep rows run from 13.2 mA to 107.9 mA depending on clock speed, load and peripherals. Your firmware decides where in that range you sit, and a firmware update can move you.
• Forgetting Wi-Fi reconnects. Every reconnect after a dropped access point spends time at receive and transmit current, which the table shows is thousands of times the sleep current. A test run next to a perfect access point may never exercise this path. Whether your device does is an open question until you test with a weak or interrupted signal.
• Leaving out PSRAM. Models with PSRAM add 40 to 200 µA to the sleep rows. A budget copied from the headline sleep number misses it.
• Measuring only at room conditions, with one fresh cell. The datasheet rows describe stated conditions, and your customer's device sees other temperatures and an aged battery. A single prototype with a single new cell tells you little about the spread.
• Printing the best profile and its best hours. Under the FTC statement quoted above, the ad needs support for what it actually communicates. A headline that suggests everyday use needs an everyday-use test.
• Reusing a customer quote. Under 16 CFR 255.2(b) as we read it, a quote you cannot show to be representative needs a clear disclosure of generally expected performance. Check the quote against your own profile tests before you publish it, and ask a lawyer.

What should you measure on your own board?

The sources give chip-level currents only. We have not measured any complete device, and this page reports no battery result. Fix every pass line before you start. A line chosen after you see the data tends to land just under the data.

Put the test conditions in the file: firmware version, cell lot, temperature, access point and signal strength, audio set, sessions per day. If a figure on the box cannot be traced to a file like this, it has no support.

What should you ask before you publish a number?

Take this list to your team and to any supplier who gives you a battery figure.

• Which usage profile does the headline hour figure describe, and is that profile printed next to the figure?
• Is the profile one that a typical buyer would actually reproduce, or the lowest-current mode the product has?
• Where is the test file that supports the number, and who signed off on the conditions?
• Was the figure measured on the whole device, or computed from chip datasheet currents?
• Does the measurement include microphone, codec, speaker amplifier and power management?
• Does the profile include Wi-Fi reconnects after the access point drops, and the retry behavior of the firmware?
• How many units, how many cells and how many cycles stand behind the number, and which one do we publish: the average or the worst?
• At what ambient temperature was the test run, and does it match the temperature range we print in the spec?
• Does the number still hold after the battery has aged, and what do we say about that?
• If we quote a customer who says the device lasts a week, can we show how that matches our own test and the generally expected performance?
• Who owns re-testing when firmware changes wake-up timing or network retry behavior?

If you want a power budget and a battery test plan for your voice device, tell us about your device. For the category background, see audio and voice hardware development.

Sources

All pages accessed October 31, 2026. Re-read them before you rely on any figure.

• Federal Trade Commission, Policy Statement Regarding Advertising Substantiation: https://www.ftc.gov/legal-library/browse/ftc-policy-statement-regarding-advertising-substantiation (accessed 2026-10-31)
• 16 CFR 255.2, Cornell Legal Information Institute reproduction: https://www.law.cornell.edu/cfr/text/16/255.2 (accessed 2026-10-31)
• Espressif, ESP32-S3 datasheet: https://documentation.espressif.com/esp32-s3_datasheet_en.pdf (accessed 2026-10-31)