Power, Diagnostics, And Standby Confidence Update

The last update focused on device coordination and replay confidence.

Since then, the work has moved into another product-critical layer: power, diagnostics, and the evidence needed to trust both.

That may sound less exciting than a new feature, but for a wrist device it is one of the most important product questions. A display can look good on the bench. A replay can prove a profile. A wireless link can connect. None of that is enough if the device cannot sit quietly between uses, wake when it is needed, and explain what happened when something goes wrong.

This phase was about making Apex Infinity quieter, more measurable, and easier to debug.

Standby became a measured product behavior

The first Wrist power work started with the obvious problem: the display should not stay fully active when the device is sitting in ground mode.

That first step mattered. The screen could dim, then turn off, and touch could bring it back. But the early battery tests made the next point clear: turning off the visible display was not the same as putting the device into a good standby state.

On the Classic display test device, the first display-idle-only run was still much too expensive. A 1000 mAh battery dropped roughly 40% over four hours. That was useful evidence because it showed that the biggest power problem was not only the pixels. The firmware, wireless stack, UI loop, telemetry handling, touch path, and polling behavior all mattered.

The work then moved through narrower, measurable slices:

• dimming before display sleep
• stopping unnecessary UI work while the display is asleep
• quieting high-rate telemetry during sleep
• stopping advertising and scanning while asleep
• disconnecting from Core during sleep, then reconnecting on touch wake
• stopping the BLE host during sleep
• slowing or stopping background polling
• using light sleep with touch wake
• reducing periodic fallback wakes
• experimenting with CST9217 touch-controller sleep on Classic

The important part is not that one switch solved it.

The important part is that the product behavior became measurable enough to improve.

The standby numbers are now moving in the right direction

The battery numbers are still gauge-derived, so they should be treated as practical field-test indicators rather than lab current measurements. But they are already useful.

The early Classic test was roughly 40% over four hours. Later normal-sleep work brought the device into the range of about 4% over roughly two hours. The latest CST9217 sleep experiment produced an overnight result of about 5% over roughly eight to nine hours, with touch wake and BLE reconnection still working.

That is a different class of behavior.

It does not mean the power story is finished. It does not replace a real current measurement setup. It does not remove the need for deep sleep. But it changes the baseline. The device is no longer only proving that it can turn the screen off. It is starting to prove that it can sit quietly and return to use.

That matters for the real use case.

A user may have several active sessions in a day, with long idle windows between them. The device needs to survive the whole day without feeling fragile. It also needs a deeper preservation mode for longer non-use, winter, injury, travel, or storage. Normal sleep and deep sleep are different product states, and this work is clarifying that boundary.

Diagnostics became part of the product loop

Power work is hard to trust without diagnostics.

One of the biggest changes in this phase was the creation of a native Mac diagnostics app for Apex devices. It started as a way to read Wrist battery and BLE state without relying on the screen, then grew into a broader tool for Core, Classic, and Edge tabs.

That tool can now show and copy useful device state in one place: Bluetooth state, PMU battery estimate, PMU status, last battery read, peripheral links, light-sleep wake counters, last wake cause, touch-controller power counters, touch-controller status, and touch-read counters.

That sounds like an engineering convenience, but it is more than that.

It makes hardware testing conversational. When a device wakes, fails to wake, reconnects, drains faster than expected, or reports a questionable battery estimate, the next step is no longer only "watch the serial monitor" or "try to remember what happened." The tester can connect over BLE, copy the diagnostic snapshot, and preserve the evidence.

The app also helped uncover real issues:

• stale or invalid diagnostic payload parsing
• battery UI disagreement while connected to USB
• BLE icon behavior that did not always match the actual Core link
• touch-controller restore problems after experimental sleep
• unexpected light-sleep wake counters
• Core log and event tail access needs

That is exactly what a diagnostics surface should do. It should make the next bug easier to describe.

Core postmortems became easier to capture

Core also had an important reliability thread running in parallel.

The device had shown spontaneous reboots, and the persistent evidence pointed to reset reason 5, an interrupt watchdog reset. The hard part was that the actual monitor was not always running when the reboot happened. Without the live panic output, the team needed better postmortem capture.

Core now has a stronger path for that.

The work added a dedicated crash-capture area by reclaiming legacy USB import space, retained and rotated syslog output, preserved event logs, and added retained breadcrumbs around startup and runtime paths. The Mac diagnostics app can also read Core summary, event-log tail, and syslog-tail information over BLE.

That does not magically solve the reboot.

It makes the next reboot more useful.

Instead of only knowing that Core restarted, the team can now inspect the reset reason, retained breadcrumbs, event tail, and syslog context. That is the difference between guessing and narrowing the next investigation.

This is especially important because Core is becoming a coordination point. It handles telemetry, logging, audio, replay, Companion transfer, display devices, and future external-device behavior. Random resets are not just a firmware annoyance. They are product trust issues, and they need an evidence trail.

Replay kept the battery story honest

The same period also included a full-profile replay test on battery.

That was useful because standby is only half the power story. A wrist device also needs to handle active use: bright display, live telemetry, phase changes, and realistic session behavior.

The observed replay run used about 5% battery from takeoff through post-landing dimming at default brightness. That is a good early practical signal for day-use planning. Most users will not be continuously active for the entire day. They will move between active windows and standby windows.

That makes the product question more specific:

How much does one realistic activity cost, and how much does the device spend while waiting for the next one?

The active-use result gives the team a starting point for the first half. The standby work is driving the second half down.

The replay path also exposed transfer reliability and throughput issues. Large replay uploads initially failed or moved too slowly. Core and Companion were updated to capture transfer breadcrumbs, quiet telemetry during the transfer stream, use better chunk sizing on macOS, reduce fixed write delay, and log rate and completion details.

The result was not perfect throughput, but it became explainable. A full transfer succeeded, Core stored the replay, rebooted into the replay path, and the diagnostics showed the transfer stage and byte counts. That is the pattern Apex Infinity needs: keep improving the speed, but first make the path observable enough to trust.

The touch-controller experiment is promising but still experimental

The latest Classic display power experiment goes one level deeper by putting the touch controller into its own sleep path and resetting or normalizing it on wake.

That work is intentionally marked as experimental.

It showed a strong overnight battery result, and wake behavior has worked repeatedly in manual testing. It also exposed a subtle restore problem where touch handling could appear stuck in a dimmed state until the firmware restored the controller more carefully. The diagnostics counters were expanded specifically to catch that class of issue: enter, exit, reset, normalize, retry, error, status, and touch-read behavior.

That is the right way to move this kind of power feature forward.

Do not hide the uncertainty. Instrument it, test it, and only promote it when the wake path is boring.

What this means for Apex Infinity

This phase was about turning power saving from an assumption into a measured product behavior.

Apex Infinity now has a much better normal-sleep path for the Wrist devices. Classic and Edge are the active hardware focus. The device can dim, sleep, stop much of its background work, wake by touch, and reconnect over BLE. The Classic experiment is also starting to show what touch-controller sleep may be able to add.

At the same time, the supporting tools are catching up. The diagnostics app can read the device without serial. Core can preserve more postmortem evidence. Replay transfer has better breadcrumbs. Battery tests now have enough repeatability to guide decisions instead of relying on guesses.

There is still work ahead.

Deep sleep is not done. True current measurement still matters. Core's interrupt-watchdog reboot still needs a captured root cause. Replay transfer speed can improve. User-selectable brightness belongs in Companion. And the touch-controller sleep path needs more time before it can stop being called experimental.

But the direction is stronger.

The product is learning how to conserve itself, wake reliably, and explain its own behavior. For a connected flight device, that is not a side quest. That is the path from a working prototype toward something a user can wear all day and trust.