1/12/2026 - Defined Problem and Performance Targets

• I first researched sources of latency in mechanical keyboards, including:
  • Switch actuation time (~1–2 ms for MX-style linear switches)
  • Matrix scanning (QMK default ~1 ms per row)
  • Firmware debounce (typically 5 ms, tuneable)
  • USB reporting (1–2 ms)
  • OS processing (<1 ms)
• I also created a latency budget table to estimate total input delay.
• I made sure to define the target performance for the project:
  • Total end-to-end latency ≤ 5 ms for key presses
  • Rotary encoder response ≤ 10 ms
• Also established project constraints:
  • 75% keyboard layout
  • Black/grey linear switches
  • Rotary encoder integration
• I documented design rationale and trade-offs:
• Semi-quiet linear switches chosen to balance typing comfort with actuation speed
• Wired USB chosen for consistent low-latency performance
• Budget and component availability considered for feasibility

---

Latency Budget Table

Latency Source	Estimated Time	Notes
Switch actuation	1.5 ms	Pre-lubed linear switches
Matrix scan	1 ms	QMK default 1ms per row
Firmware debounce	1–2 ms	Configurable in QMK
USB reporting	1–2 ms	Polling at 1000 Hz
OS processing	<1 ms	Standard USB stack

---

Reflections / Next Steps

• Actual latency will be measured later with a logic analyzer for validation.
• I will next focus on system architecture and signal path decomposition.
• I will also identify firmware parameters that affect latency the most for tuning during build.
  

1/13/2026 2 AM - System Architecture & Signal Path Design

Summary

I designed the full system architecture of the ultra-low-latency keyboard to understand how a physical keypress propagates through the electrical and firmware layers until it registers as a key event on the host computer. I also identified latency-critical paths and define controllable parameters.

---

Activities Completed

• I designed the end-to-end signal path from switch actuation to host key event.
• Worked on identifying all hardware and firmware components involved in the signal chain.
• Analyzed which parts of the system have the largest impact on latency.
• Evaluated design trade-offs related to MCU choice, scanning method, and USB interface.

---

System Architecture Overview

Mechanical Input Layer

• MX-style linear switches actuated by user input.
  
• Switches arranged in a row/column matrix to reduce I/O pin usage.

Electrical / PCB Layer

• Switch matrix routed to MCU via PCB.
  
• Diodes included to prevent ghosting.
  
• Rotary encoder connected to dedicated GPIO pins.

Firmware Layer

• RP2040 microcontroller running QMK firmware.
  
• Periodic matrix scanning detects switch state changes.
  
• Debounce logic filters noise from mechanical contacts.
  
• Encoder interrupts handled separately to avoid blocking scan loop.

Host Interface Layer

• USB HID reports sent to the host computer.
  
• Host OS interprets reports and registers key events.

Signal Path Diagram:

• Switch Actuation
• PCB Matrix
• MCU GPIO
• QMK Scan + Debounce
• USB HID Report
• Host OS Key Event

---

Latency-Critical Analysis

Component	Reason
Matrix scan rate	Determines how quickly a key press is detected
Firmware debounce	Can add artificial delay if misconfigured
USB polling rate	Limits how fast reports reach the host
Encoder handling	Needs fast response without blocking scan loop

MCU Selection: RP2040 chosen for:

• High clock speed for fast scan loops
  
• Native USB support
  
• Strong QMK support
  
• Deterministic performance for latency-sensitive tasks

---

Design Trade-Offs

• Matrix vs per-key GPIO: Matrix reduces pins with minimal latency impact.
  
• Polling vs interrupts: Matrix scanning predictable; interrupts reserved for encoder.
  
• Wired vs wireless: Wired USB avoids transmission latency and simplifies power management.

1/13/2026 7 PM - Electrical Architecture & MCU Selection

Today I focused on designing and validating the electrical architecture of the keyboard at the PCB level. Rather than treating the electronics as an abstract block, I mapped out the full key matrix and began translating it into a physical layout to understand real-world routing constraints.

The keyboard is organized as a row-column matrix to minimize pin usage while maintaining fast scan cycles. I allocated microcontroller GPIO pins to rows and columns based on proximity, symmetry, and expected routing density. This required balancing electrical simplicity with physical feasibility, especially around avoiding trace congestion near the MCU fan-out region.

To test whether the matrix design was physically realizable, I created an initial PCB layout view showing all row and column connections as a ratsnest. This visualization allowed me to identify high-density routing zones, evaluate whether traces could be kept short and consistent, and anticipate where multi-layer routing might be necessary. Seeing the full matrix represented spatially made timing and signal integrity considerations much more concrete than a schematic alone.

This step also surfaced several design tradeoffs. Increasing matrix width reduces scan depth but increases routing complexity, while tighter clustering around the MCU simplifies firmware mapping but risks congestion. I documented these tradeoffs and adjusted pin assignments to reduce crossover and simplify later routing passes.

Although this layout is not finalized or routed, it serves as a critical validation step. It confirms that the proposed matrix architecture can be implemented on a compact custom PCB using off-the-shelf components, and it provides a clear foundation for schematic capture, firmware development, and future optimization for low-latency scanning.

1/14/2026 3 AM - Matrix Routing Optimization and Signal Considerations

I focused on refining the keyboard’s electrical matrix with the goal of improving routing efficiency and preparing the design for low-latency scanning. Building on the validated matrix structure, I shifted attention from feasibility to optimization, analyzing how routing choices at the PCB level could influence scan consistency and future firmware behavior.

I reviewed the row-column organization to reduce unnecessary trace crossings and long routing paths. Rows and columns were reorganized to better align with physical key groupings rather than purely logical symmetry, which reduced congestion in high-density areas and made the electrical structure easier to reason about during firmware development. This step emphasized predictability and repeatability over aesthetic alignment.

Diode placement and orientation were standardized across the board. Diodes were positioned close to their corresponding switch footprints to minimize trace length and ensure clean electrical isolation during simultaneous key presses. Orientation consistency was prioritized to reduce assembly errors and simplify visual inspection during debugging.

I also evaluated routing decisions through the lens of signal integrity and scan performance. While PCB-level latency is small compared to firmware and USB timing, minimizing unnecessary vias, sharp trace bends, and excessive trace length helps maintain reliable high-frequency scanning. Special care was taken to keep matrix routing away from the microcontroller and USB interface region to avoid introducing noise or routing conflicts.

Although the PCB is still unrouted, this refinement phase establishes a clear and intentional electrical structure. The matrix is now organized in a way that supports aggressive scan rates, clean firmware pin mapping, and straightforward manufacturability.

1/14/2026 7 PM - System Integration and Enclosure Finalization

This session focused on consolidating all prior design work into a coherent, fundable system proposal. At this point, the electrical architecture, firmware strategy, and component selection are sufficiently defined to justify physical fabrication, so the emphasis shifted to integration, manufacturability, and presentation completeness.

I began by reviewing the full signal path—from switch actuation through matrix scanning, firmware processing, and USB transmission—to confirm that the electrical and firmware assumptions remain consistent across the entire system. This included verifying that the MCU pin allocations, scan rates, and latency budgets align with the chosen hardware and do not introduce hidden constraints once assembled.

To complement the PCB design, I created an initial CAD model for the keyboard enclosure. The case is designed around a tray-mounted PCB with a fixed plate, prioritizing rigidity and consistent switch alignment. Mounting standoffs were positioned to avoid high-density routing regions on the PCB, and internal clearances were checked for the MCU, USB connector, and cable strain relief. The enclosure geometry intentionally remains simple at this stage, favoring ease of manufacturing (3D printing or CNC) over cosmetic refinement.

I also used the enclosure model to sanity-check overall dimensions, typing angle, and component accessibility. These checks ensure that the funded build will not stall due to mechanical incompatibilities.

With the electrical design validated, firmware architecture defined, and a feasible enclosure designed, the project is now ready to be actually executed. The remaining work after funding will primarily involve fabrication, assembly, firmware implementation, and latency measurement to create the final product.