USB, Rechargeable Power and LCD Clock Runtime

• USB input
• Supply and charging management
• Complete battery assembly
• Clock load

What you will learn

• Distinguish input power, charging and power-path management.
• Estimate runtime from energy and average power.
• Plan measurements for lighting and network schedules.

Before you start

Understand power, energy, the clock architecture and LCD selection. This article discusses complete power assemblies and device measurements rather than battery construction.

What supports USB and battery operation together?

Supplying the system and charging its battery are separate design responsibilities. Texas Instruments describes power-path management that supplies the system while charging the battery and monitoring charging current separately.

The proposed design uses a complete assembly with confirmed operating characteristics that supports operation during charging, a suitable output and transition after USB removal. Select the whole module rather than relying on its chip name. Connector shape alone does not establish power behavior or load limits.

If a power bank supplies the prototype, test behavior with small loads and extended idle periods. Successful startup is not proof of operation throughout the usage schedule. These are proposed checks, not results for a particular product.

• External power
• Battery power
• Transitions to test

Which quantities determine runtime?

Use energy in Wh and average power in W at a consistent measurement boundary. EIA explains watt-hours as energy associated with power in watts over time in hours. The runtime estimate follows by dividing usable energy by average power.

The design equation is runtime = usable energy / average power. Labelled battery energy and energy delivered to a load may refer to different boundaries. If measuring at the battery input, include the whole device there; if measuring downstream of conversion, account for the appropriate losses without subtracting them twice.

Average power weights each operating state by its share of time. Measure standby, networking and backlighting, multiply each by its duration share and add the results. A state with networking and lighting together should be measured separately to avoid double counting.

A useful log records mode, measurement point, voltage, current or power, observation duration and display configuration. This article has no hardware measurements establishing days between charges.

With alarms and OTA, extend the proposed measurement log to include ringing, snoozing, firmware download and post-update startup. Also measure sound and lighting operating together. Record each state's duration under the same usage schedule; adding features alone does not establish how much runtime changes.

• Usable energy
• Contributions by operating state

Where should power be reduced first?

Measure lighting and Wi-Fi sessions before deciding to enlarge the battery. The proposed external-power mode can allow regular illumination; battery mode defaults to button-triggered lighting with a configured timeout. Keep an explicit longer-lighting option for users who need it.

Espressif describes Light-sleep as preserving state for resumption, while Deep-sleep powers off CPUs and many peripherals. Wireless connections are not maintained in these sleep modes. Reconnection and display behavior therefore need deliberate handling.

The initial proposal gives weather and time synchronization separate schedules and delays retries after network failures. Exact intervals remain settings to evaluate against service requirements and user needs. Updating the minute does not require downloading weather again.

Before using Deep-sleep, establish whether the LCD controller continues scanning and displaying content while the microcontroller sleeps. After wake-up, check buttons, time, settings and rendering. Measure the full development board as an actual load; a chip sleep specification is not a board-level result.

With alarms enabled, the proposed sleep schedule must wake for the next occurrence and allow dismissal or snooze input. Do not extend sleep solely to improve a power reading. Restarting cancels active snooze under the initial policy; also test sleep paths that rerun startup. The original schedule must still be restored.

Allow OTA only with stable USB power and outside the configured alarm exclusion window. Do not enter sleep while downloading firmware or ringing; defer Deep-sleep while snoozing to preserve its elapsed-time counter. These are prototype policies to validate, not a guarantee of operation through every power interruption.

• Networking
• Backlight
• Board and sleep behavior

Real-world example

A prototype misses its runtime target. The team plans measurements with the same screen unlit, lit and performing network requests. This is an experiment plan rather than reported measurements.

If lighting dominates energy use, try button-triggered illumination before buying a larger battery. If repeated Wi-Fi reconnection dominates, reduce network sessions and assess reliability. After each change, repeat the full usage schedule, including outages, to determine whether the change helped.

Common misunderstandings

Low chip sleep current guarantees long clock runtime. Measure the whole device, including display, backlight, board and power assembly.

A charging circuit establishes operation during charging. Load supply, charge monitoring and source transitions must be confirmed for the actual module.

Frequently asked questions

Can component selection establish months of operation?

It is insufficient on its own. Build an energy budget, measure usable energy and test runtime against a declared usage schedule.

Should all-night lighting be the battery default?

The proposal favors lighting on demand. If continuous light is required, measure that mode separately and recalculate endurance.

Should battery selection come before power measurements?

Set the usage target, measure the prototype and choose a suitable complete assembly. Enclosure space and usable energy also affect the final selection.