Device Coordination And Replay Confidence Update

The last update was about logbook sync, validation reporting, and release readiness.

Since then, Core validation has moved into another important area: coordinating an external device while the firmware continues doing its normal work.

That matters because Apex Infinity is not only a recorder, an audible alert system, or a replay tool.

It is becoming a small device platform.

External-device control moved from research to bench behavior

The camera-control work started as a feasibility question.

Could Core coordinate with an external camera directly enough to be useful later?

The answer is now yes, with important limits. In bench testing, Core connected over Bluetooth and issued recording commands from the development monitor command surface. That moved the work beyond research notes and into behavior that can be replayed, measured, and improved.

The current proven path is intentionally narrow. It does not depend on camera Wi-Fi. It does not claim that every power state, camera model, or production setting is solved. It proves that Core can establish the link, send the command, and observe the expected result under controlled conditions.

That is enough to start shaping the integration work without overstating the product surface.

Replay became the safe proving ground

The next question was whether external-device coordination could fit into a realistic Core activity profile.

A recorded replay gave the right test path. It let Core move through a known profile, run alerts, stream telemetry, command the external device, and finish the profile without needing a live field test for the first integration pass.

That replay matters because it tests timing and coordination together.

Core triggered the external-device flow before the configured alert point by estimating lead time from the current climb behavior. The important result was not the exact timing number. The important result was that Core could prepare the device early enough for the intended window while preserving the existing alert behavior.

That is the kind of integration Apex needs: coordinated device behavior that does not ask the user to manage another manual checklist.

Telemetry stayed alive during the work

The most important constraint was not only whether the camera command worked.

Core also had to keep doing Core work.

During the scan, connection, and command sequence, telemetry continued to flow. The replay log showed that the normal reporting path kept advancing before, during, and after the external-device action.

That is a critical result because live behavior cannot let device coordination steal time from logging, alerts, display devices, or telemetry.

The product principle is straightforward: external-device control can become part of the workflow only if it behaves like a coordinated background action, not a blocking mode switch.

This replay showed the right direction.

The full lifecycle now has evidence

The replay also carried the control path through completion.

Core started the recording behavior during the configured preparation window, kept the recording state active through the relevant portion of the profile, and sent a stop command when the profile reached its completion state.

That closes the first complete loop for this class of integration:

• prepare the external device before the configured alert window
• keep the recording state active through the expected profile
• stop recording at completion
• preserve telemetry and alert behavior along the way

There was also a useful cleanup item. The first implementation successfully sent the stop command, but the development state machine kept printing repeated completion messages after the link was already gone. That is not a feature failure, but it is exactly the kind of rough edge replay validation is supposed to expose. The cleanup is already identified and patched locally.

Replay also exposed a BLE lifecycle bug

This round found a separate Bluetooth stability issue.

During one replay transfer attempt, Companion disconnected partway through the upload. A later reconnect exposed a NimBLE advertising restart problem in the BLE lifecycle.

That is useful evidence.

The camera work did not only prove a new control path. It also stressed the shared Bluetooth system enough to expose a real reconnect problem. The fix direction is to move sensitive restart work out of the callback path and into a safer execution context.

That kind of bug matters because Apex Infinity depends on ordinary wireless behavior being reliable. Companion, display devices, telemetry, replay transfer, and external-device control all share the same Bluetooth reality.

What this means for Apex Infinity

This milestone changes the camera conversation.

The open question is no longer only whether Core can send a useful command to an external camera. The answer is now proven enough to continue integration work. The remaining questions are better questions:

• how much lead time should Core use under different climb profiles?
• how should the setting distinguish an audible alert from automatic device control?
• which camera states and supported devices are reliable enough for production?
• how should this graduate from development commands into normal configuration?

That is progress.

The platform is moving from "can we talk to this device?" to "how do we make this reliable, understandable, and safe as part of the normal Core workflow?"

The replay evidence is the bridge. Core can now use realistic recorded profiles to validate not only its own alerting and telemetry, but also external-device coordination. That points toward a broader Apex Infinity model: Core records the activity, reports state, preserves history for Companion, and coordinates supporting devices without asking the user to manually manage every surface at once.

That is the shape of a product workflow, not just a protocol experiment.