XtergoXTERGO_

Sensor interface and mechanical integration

The first step is a standalone sensor interface. That means tracing the original board, establishing the supply rails and logic levels, confirming the pinout, and documenting the initialization sequence before attempting motion reads. The exact sensor identification and interface still need verification; a presumed part number is not enough to define the circuit.

The breakout needs local decoupling, access to the sensor signals and a mounting arrangement that preserves the relationship between the sensor, lens and tracking surface. The eventual replacement board also has to fit the existing mounting points, scroll-wheel assembly, side switches and button mechanisms. Retaining the original optical click switches requires their associated sensing electronics, not just a pair of ordinary switch inputs.

Controller and wireless architecture

The intended architecture has a mouse-side controller reading motion and button state, a proprietary 2.4 GHz link, and a receiver presenting a USB HID mouse to the host. Bluetooth is a separate operating mode. Support for up to five Bluetooth hosts is a requirement under investigation; stored pairings, fast host switching and simultaneous active connections impose different firmware requirements.

The nRF52840 and STM32 wireless families are being evaluated. The decision depends on sensor interfacing, USB support, radio access, Bluetooth integration, power consumption and the ability to develop without Zephyr. The nRF52840 remains a candidate for its combination of SPI, USB and proprietary radio support. An STM32 alternative needs its radio and host-interface capabilities checked at the specific part level.

Firmware, power and validation

The firmware work is divided into sensor communication, button and encoder handling, report generation, radio transport and receiver-side HID. A 1,000 Hz report rate is an initial target, not a measured result. Validation needs to separate sensor sampling intervals, packet timing, retransmissions and host report delivery rather than treating polling frequency as an end-to-end latency measurement.

Battery integration needs charging, protection, regulation, idle behaviour and physical clearance considered together. The planned sequence is wired sensor bring-up, a measured wireless link, then a custom board. A functioning sensor driver, sustained wireless reporting, battery life and a fabricated replacement PCB remain validation milestones.

Socket data and engineering tools

The proposed tooling separates document extraction from engineering validation. Python handles extraction and normalization into a canonical land dataset. Rust is intended to validate coordinates, signal classifications, record counts and references, then generate socket maps, reports and KiCad artifacts. This is the agreed toolchain architecture, not a claim that the complete generator is implemented.

The data model separates physical contact geometry, the manufacturer's published signal definition and the project's interpretation of how that signal will be used. Missing information stays explicitly unknown. Validation checks internal consistency, while verification compares entries against independent source material. Generated symbols and footprints are derived outputs, not a replacement for the source data.

PCH qualification before motherboard design

The current first-stage investigation focuses on the Intel 100-series Sunrise Point PCH-H family, with H110 as the initial candidate and Z170 as a comparison target. A proposed characterization fixture would make harvested chips testable before committing them to a motherboard. Its scope includes power domains, clocks, resets, straps, SPI flash access and observable platform behaviour.

The fixture concept includes controlled power sequencing, current measurement and accessible debug signals, with a suitable BGA carrier or socket arrangement still to be established. Package similarity alone does not establish interchangeability. Ball assignments, reserved contacts, electrical requirements, enabled HSIO functions and firmware configuration must be compared for each SKU. A fixture that observes power and SPI activity also does not establish full PCH functionality without the necessary CPU companion and platform checks.

Power-on sequence and pre-memory firmware

The first board-level objective is a controlled path from standby power to early firmware execution and usable memory. The investigation follows rail validity, reference clocks, reset release, configuration straps and the SPI firmware image. The flash descriptor, platform configuration and Management Engine dependencies are part of that work, rather than assumptions hidden behind a generic BIOS block.

Each transition is intended to have an explicit driver, receiver, signal polarity, electrical domain, timing requirement and evidence source. This should make a failed bring-up distinguishable from a bad harvested component, an incorrect power sequence or firmware that never reached memory initialization.

DDR4 and PCB constraints

DDR4 is treated as a complete subsystem: data byte lanes and strobes, address and command groups, clocks, termination, reference voltages, supply rails, DIMM SPD access and memory initialization firmware. Placement and routing must follow socket escape constraints, topology, return paths and timing budgets. The CPU memory interface is considered separately from the CPU-to-PCH DMI link and the PCH's peripheral interfaces.

The intended first functional milestone is repeatable DRAM initialization and a memory read/write test with diagnostic output. A complete peripheral set and operating-system boot come later. Broader processor compatibility, a universal PCH fixture and replacement of closed platform components are research directions, not demonstrated capabilities.