Glasses, Standby, And Device Confidence Update

The last update focused on power, diagnostics, and the evidence needed to trust the devices between active moments.

Since then, Apex Infinity has moved in two directions at once.

The first direction is visibility. Core is no longer only feeding the wrist display family. It can now drive a glasses-based display directly, using the same live and replay telemetry path that already supports the rest of the Apex display system.

The second direction is patience. The wrist devices continued moving toward lower-power standby behavior that can be measured over long quiet windows, woken by touch, and checked with diagnostics instead of guesswork.

Together, those are important steps toward a more flexible product. Apex Infinity is becoming less dependent on a single screen, and more disciplined about what the devices do when the user is waiting for the next active window.

Core can now speak to glasses directly

The biggest visible change is that Core can now stream telemetry to a glasses-based display without using a phone app as the middle layer.

That matters because it changes the role of Core.

Core already acts as the source of truth for the live device state. Until now, the main display targets were the Apex wrist devices. The new path lets Core also behave as a direct client for compatible glasses, discover the display, connect over BLE, and send compact display updates while preserving the same underlying telemetry source.

The important engineering decision was to treat glasses as another sink, not as a separate telemetry world.

Live behavior and replay behavior still come from the same Core telemetry stream. That keeps the architecture honest. A replay that drives the wrist display can also drive the glasses display. A live session can follow the same path. New display surfaces should not require new copies of the product logic unless they genuinely need different data.

That is a foundation we will want later. Today it supports one glasses path. Over time, the same shape can support other wearable display modules, including options that may require a phone in the middle or a different device-specific bridge.

The first glasses layout became usable through real viewing

Getting packets to a display is only the first step.

The harder product question is whether the information lands where the user can actually read it.

The first glasses layout went through a practical fit pass: remove unnecessary framing, reduce the visual weight, simplify the status row, keep the battery indicator visible, and place the main value where it can be read comfortably. A saved display configuration now carries the small status elements and battery icon, while Core updates the changing telemetry values during replay or live use.

That split is useful. Static layout assets do not need to be redrawn over and over, and dynamic values can stay focused on what is changing. It also gives us a clearer future path for user-adjustable placement. The current tuning proved that comfort and eye position are personal. The next product version should let Companion send placement preferences so the user can fit the display to their own view rather than relying on one firmware default.

The most important result is that the layout crossed from "connected" to "readable enough to validate." Replay telemetry flowed to the glasses as expected, and the display reconnected quickly after repeated power cycles.

Reconnect behavior became part of the definition of done

Direct glasses support would not be useful if it only worked immediately after Core rebooted.

Core is an always-on device. A user may turn the glasses on later, turn them off after a session, charge them, or switch between display surfaces. The connection path has to keep searching and reconnecting without requiring a Core restart.

That exact behavior was tested.

After the glasses disconnected, Core returned to a scan-and-retry path, found them again, connected, rediscovered the display path, and resumed the ready state. After replay completed, the glasses were powered off and back on twice, and they reconnected immediately both times.

That is the kind of behavior that turns a feature from a bench demo into something closer to product behavior. It means Core can keep being Core while displays come and go around it.

Camera coordination stayed in the design

The glasses work also had to respect another near-term product path: camera control.

Core has been moving toward short, timed camera activation windows. That means the glasses path cannot monopolize the wireless stack or recover slowly after giving another device priority.

The current implementation keeps that constraint in mind. If camera work needs the connection window, glasses work can back off and then retry quickly. That is not only a technical courtesy. It is a product priority statement: visibility, camera coordination, replay, and wrist display behavior all need to coexist around the same Core timeline.

This is where the platform architecture matters. Core should not become a pile of one-off device modes. It needs a disciplined way for display surfaces and external actions to share the same source of truth without stepping on each other.

Standby work continued to get more honest

While the glasses work moved forward, the wrist standby story continued to mature.

The recent power work made one thing clear: a good standby mode is not just a dark screen. It is a whole-device behavior. The display, touch path, wireless state, polling, diagnostics, and wake rules all have to agree about what "resting" means.

The latest tests continued separating promising ideas from reliable ones.

One touch-controller sleep experiment showed strong overnight battery behavior, but later exposed a wake reliability problem. That was the right kind of failure to catch early. The safer path disabled that experimental sleep layer again, retained diagnostics for future work, and returned to a more reliable wake path. A later long idle run woke immediately and showed materially better drain than the early display-only baseline.

Deep sleep also became more concrete. The device can now enter a longer storage-oriented rest state after the normal standby window and wake by touch. Diagnostics can show whether that state was entered, how it woke, and whether preparation steps succeeded. The first results are not the final power answer, but they are a much better engineering answer: the behavior is observable, repeatable, and no longer hidden behind a vague battery estimate.

That distinction matters. Apex Infinity does not need power features that look good once. It needs standby behavior that can be trusted repeatedly.

Local validation kept tightening the loop

Another quieter improvement was operational.

The project continued shifting expensive validation work toward local test machines and trimming old build targets that no longer represent the active hardware path. That matters because validation cost affects engineering discipline. If every check is too expensive or too slow, teams start avoiding the checks. If the checks are focused and affordable, they become part of the normal rhythm.

This round also reinforced the value of keeping diagnostics and validation evidence close to the work. Firmware flashes, monitor captures, replay runs, and app-side checks were logged as named artifacts. That makes it easier to understand why a change was trusted, not just that it happened.

What this means for Apex Infinity

This update is about flexibility and confidence.

Core can now drive a glasses-based display directly. The wrist devices are getting better at resting and waking. Replay remains the shared validation tool that proves display behavior without needing to wait for a live scenario. Diagnostics keep turning uncertain behavior into evidence. And the platform is getting more intentional about how displays, camera windows, and device connections coexist.

There is still work ahead.

Glasses placement should become user-configurable from Companion. Additional glasses paths may need a module strategy so firmware does not grow without limit. Camera coordination needs more product shaping. Deep sleep still needs more measurement and tuning. And the standby story should continue moving from gauge-derived confidence toward current-measured confidence.

But the direction is strong.

Apex Infinity is becoming a system where Core owns the truth, multiple displays can subscribe to that truth, and the devices can rest, wake, reconnect, and explain themselves with increasing discipline.