From Virtual Board To Manufacturing: A Revision F Confidence Update

The July update focused on making Apex Infinity's devices coordinate more reliably. Companion could express more of the user's intent, Core could preserve and act on it, and Wrist could make more of the resulting state visible.

Since then, the central engineering question has changed:

How much uncertainty can we remove before ordering the next physical boards?

That question led to one of the most important development steps in the project so far. We built a repeatable validation loop that connects the actual firmware, an interactive representation of the PCB, behavioral models of the board's major components, analog power analysis, and the files intended for manufacturing.

We call that environment Board Lab.

Board Lab does not replace a physical prototype. It gives us a much better reason to build one.

A bench failure made Core more defensive

The path to Board Lab began with an unsettling result on the hand-wired development hardware. While sitting still, Core briefly interpreted impossible motion as real activity and produced alerts that should never have occurred.

Instead of treating that as a one-off glitch, we preserved the available storage evidence before changing anything and followed the data through the full decision path.

That investigation led to several layers of protection. Core now uses a coherent pressure sample for its related calculations, rejects stale or physically implausible changes, requires sustained evidence before changing its operating phase, and suppresses safety callouts when the supporting data is not healthy. Ground-reference behavior was also corrected so it can stabilize, remain locked during an active session, and return cleanly after completion.

The resulting firmware passed an extended stationary soak without repeating the false activity, then completed a full replay and returned to a stable idle state. Storage behavior was tightened at the same time: after a verified Companion sync, Core can automatically reclaim only the space that its own accounting proves is safe to release. If that accounting is ambiguous, it fails closed and leaves the data alone.

This work did not prove that every possible environmental condition has been solved. It did give the next hardware revision a more defensive firmware baseline and gave us a real failure scenario to reproduce in simulation.

The PCB became interactive

Board Lab started by turning the PCB from a static design file into something we could inspect in a browser.

The board can be viewed from the front, the back, or with all copper layers visible. Components, pads, routes, vias, and filled copper areas can be selected and inspected. Individual nets can be isolated so their physical paths are easier to follow. Front and back views can also be shown side by side in their correct orientations.

The same page accepts a complete board package through drag and drop. That package carries the matching PCB, firmware images, emulator files, board model, preferences, audio assets, and replay data needed for a repeatable session.

This matters because a board image alone cannot tell us whether the firmware expects the same component addresses, storage behavior, status-light behavior, or audio path that the schematic describes. The package binds those assumptions together and verifies that the required files belong to the same revision before a run begins.

Production-derived firmware now runs against the modeled board

The next step was to boot production-derived Core firmware against behavioral models of the important devices on the PCB.

Board Lab now models the two pressure sensors, motion sensor, magnetic sensor, positioning receiver, external storage, status light, and digital audio path closely enough for the firmware to discover and exercise them. The models support normal behavior as well as selected failure conditions, including an absent device, a wrong identity, a busy device that does not recover, and invalid data.

A deterministic replay can then drive the firmware through a complete operational timeline. Board Lab records component transactions, storage activity, status-light changes, audio output, and processor logs while the run is in progress. The captured audio can be played through a Mac, and the PCB view shows communication activity in real time.

This has already found a genuine firmware-hardening item involving extreme invalid motion-sensor data. That item remains open rather than being hidden behind a simulator workaround. Finding an unresolved edge case is a successful test result when the alternative is discovering it after manufacturing.

Digital behavior and power behavior now meet in one place

Firmware emulation can show that Core boots, discovers its modeled devices, stores data, changes state, and produces light and audio output. It cannot, by itself, show whether the board's power rails remain healthy when several loads peak together.

Board Lab now connects those two kinds of evidence.

The firmware replay produces a time-based workload. That workload drives an analog power model covering USB input, battery operation, charging, system power, and the regulated rail used by the processor and most peripherals. The completed waveforms appear next to the digital result, with separate current traces for audio, the status light, wireless activity, sensors, storage, and background loads.

Each case is evaluated three ways:

• Best case represents favorable component tolerances and source conditions.
• Nominal case represents the expected design behavior.
• Worst case deliberately stacks unfavorable source resistance, component tolerance, and peak-load assumptions at the same time.

Failures are not reduced to a red label. The user can open the details, see the measured result, see the required limit, identify the rail and source involved, and inspect the corresponding waveform.

We also completed a passive-component coverage audit. Every resistor and capacitor in the design is classified as explicitly simulated, included in an aggregate rail value, reviewed for connectivity or function, intentionally not populated, or intentionally outside the power model. The Revision F package has no passive components missing from that accounting.

Simulation changed the board before manufacturing

This combined view exposed a meaningful concern in the previous revision. Under an intentionally aggressive overlap of audio, wireless, status-light, processor, and peripheral loads, the regulated rail could be asked to deliver more current than its original regulator was designed to guarantee.

The hand-wired Core has played audio reliably during extensive replay testing, so the modeled peak is not proof that the product would fail in normal use. But it was enough uncertainty to stop and improve the board before spending money on another run.

Revision F replaces that power stage with a higher-capacity regulator and adds local energy storage near the audio path to better support short demand spikes. Board Lab was then updated to use the Revision F schematic assumptions and manufacturing files rather than pretending the earlier board had changed.

The result is encouraging and appropriately qualified:

• All best-case power tests pass.
• All nominal power tests pass.
• The deliberately stacked worst-tolerance cases remain conditional because some combinations still lack guaranteed margin.
• The digital firmware replay passes against the modeled Revision F board.
• More than 200 automated Board Lab checks pass.
• Manufactured-board evidence is not yet available.

That last line is as important as the others. Revision F is a stronger manufacturing candidate, but simulation is not a first-article acceptance test.

The manufacturing package became controlled evidence

The board files went through repeated DFM and assembly reviews while Board Lab was evolving.

Trace geometry, clearances, annular rings, solder-mask spacing, component placement, and assembly data were reviewed and refined where the board geometry allowed it. The final handoff package includes the fabrication layers, drill data, paste data, BOM, component placement data, and controlled assembly notes needed for quotation and first-article production.

Critical substitutions are explicitly controlled rather than left to a generic parts match. The battery connector, regulator, charger, sensors, storage, antenna, magnetic USB connector, and spring-contact speaker all carry manufacturing guidance. The speaker is included in the BOM with its installation method documented so it is treated as part of the assembly rather than an informal add-on.

This does not eliminate supplier questions. It gives those questions a single, versioned answer instead of allowing the schematic, PCB, spreadsheet, and email instructions to drift apart.

Companion and Wrist continued to improve around the same system

The hardware-validation work was the dominant effort, but the other product surfaces continued moving forward.

Companion's Preferences experience was reorganized into focused sections that are easier to navigate on desktop and mobile. The sync path now distinguishes an authoritative empty Core directory from a missing or incomplete response instead of guessing where records should be. This makes the existing storage-management workflow safer when session identifiers are sparse or non-sequential. These changes were delivered to internal macOS and iOS TestFlight testers.

Wrist now shows its local battery, USB-power, and BLE connection state immediately after startup instead of waiting for the first live update from Core. The change was accepted on Classic hardware while preserving the existing activity and camera display paths. The current firmware baseline was also built, installed, and boot-validated on Edge hardware, with a full visual replay check still reserved for the next validation round.

These are smaller changes than Board Lab, but they support the same goal: the system should report what it actually knows, avoid guessing, and make incomplete evidence visible.

What Board Lab proves, and what it does not

The strongest result of this work is not a single green badge. It is a separation of evidence.

The digital result tells us whether the firmware can boot and interact with the modeled Revision F components through a complete replay.

The analog result tells us how the modeled power and charging paths respond to the measured workload under favorable, expected, and deliberately conservative assumptions.

The physical-hardware result remains not run because Revision F boards do not exist yet.

Only manufactured hardware can validate the real USB data path, charging behavior with the selected battery, wireless range through the enclosure and around a human body, audio loudness and power draw, temperature behavior, assembly quality, and manufacturing defects. Those are not gaps that should be painted green by software.

The first Revision F boards will therefore be treated as measurement instruments as much as prototypes. The incoming test plan will begin with visual and unpowered checks, then use current-limited power, USB enumeration, charging tests, rail and current capture, firmware installation, component discovery, storage, audio, status-light, and BLE validation. The measurements will then be fed back into Board Lab to replace conservative assumptions with calibrated hardware data.

What this means for Apex Infinity

The project now has a much stronger answer to the question, "Why do we believe this board will work?"

Not because the schematic looks correct.

Not because the firmware works on a collection of development boards.

Not because one simulator produced a clean graph.

We believe Revision F is ready for a first-article run because the design has been reviewed from several independent directions. Production-derived firmware can exercise the modeled board. The analog model can replay the resulting load. Every passive component is accounted for. The findings changed the PCB before manufacturing. The manufacturing package is controlled. The remaining uncertainty is stated plainly and attached to a physical test plan.

That is not the end of verification. It is the point where building the next boards becomes the most useful next experiment.