1/2/2026 - Creating a guide for features and layout

Today I created the first plan of features an the final layout of the low profile keyboard inspired by the lofree flow and the framer x work louder Collab

Features

• Rounded Corners
• Metal Frame
• 84 Keys
• Full Number row and Top Row
• Backlight
• Transparent Bottom with lightening
• Low Profile Switches and keycaps

Layout:

• Made for Windows and Mac Layout
• Full command row
• 75% Layout (84 keys)

Parts I want to use

• Choc v2 brown low profile switches with low profile caps
• Mini LEDs
• Aluminum frame

1/3/2026 - Research and planning

What I Did Today

1. Design Research and Moodboard

• Collected visual references for keyboards and industrial design, focusing on products like the Lofree Flow, NuPhy Air75, IQUNIX 75 Pro and similar devices that match a 1960s Dieter Rams aesthetic.
• Defined the visual direction: very clean, functional forms, minimal ornamentation, black low‑profile keycaps with white legends in a silver case, inspired by Braun-era product design.

2. Right-Side Extension Concept

• Finalized the idea that the keyboard will have a main Lofree-Flow‑style 75% section on the left and a right-side extension block.
• Planned that the right block will contain the main electronics below a “service area”, plus a small display and one or more rotary encoders arranged on the top area, all kept visually consistent with the Rams-inspired design language.
• 

3. KiCAD Schematic Work

• Continued working on the schematic: placed switches and started wiring rows for the key matrix .
• Thought through how to handle uneven key counts per row (16 / 15 / 15 / 14 / 14 / 10) and concluded that rows can still be wired straight across, with columns later handling the vertical grouping and simply leaving empty matrix positions where a row has no key in a given column! .

---

Next Steps

1. Finish wiring all rows in the schematic, ensuring each switch in a row is correctly chained and associated with a row label .
2. Design the column matrix so that every physical key position maps cleanly to a row/column pair, allowing for empty positions where needed .
3. Assign footprints for all switches, diodes and other components and prepare for importing the layout outline into the PCB editor .

1/4/2026 - Kicad Schematic start & BOM

What I Did Today

1. KiCad Library Installation

• Installed ScottoKeebs keyboard library

- Installed Hack Club hardware libraries

2. Started Schematic Design

• Began planning keyboard matrix layout (84 keys)

3. Figured Out Matrix Layout (on paper)

• Problem: 75% layout has different numbers of keys per row
  • Row 1: 16 keys
  • Row 2: 15 keys
    
  • Row 3: 15 keys
  • Row 4: 14 keys
  • Row 5: 14 keys
  • Row 6: 10 keys

4. Calculated GPIO Requirements

• Matrix: 16 cols + 5 rows = 21 pins
• Rotary encoders (2×): 4 pins
• OLED I²C: 2 pins (SDA/SCL)
• LEDs (if addressable): 1 pin (data)
• Total needed: ~28 pins
• SuperMini has: only 21 usable GPIO
• Solution: Use 2× MCP23017 I/O expanders (16 GPIO each via I²C)

5. Component Research on AliExpress

• Searched for compatible parts that work together
• Checked reviews, pricing, compatibility
• Focused on budget-friendly options

6. Current Bill of Materials (BOM)

Component	Qty	Price (€)
SuperMini nRF52840 controller	1	5.99
Kailh Choc hotswap sockets	90	16.99
Rotary Encoder EC11	2	10.89
1N4148 SMD Diodes	90	0.37
Kailh Choc V2 Brown switches	90	24.79
MCP23017 I/O Expander modules	2	3.05
0.96" OLED Display I²C	1	0.99
Low-profile PBT keycaps ANSI	1 set	15.59
Subtotal		~78.66 €

---

Notes

• Still need: LiPo battery, PCB fabrication, plate, USB-C port, stabilizers, case materials
• Deciding whether I should solder switches directly instead of hotswap to save money

1/5/2026 - Figuring out the "New Stuff" in the Schematic

What I Did Today

1) LED Wiring

• Worked on the LED wiring in the schematic and tried to make it “actually makes sense” instead of random nets everywhere.
• Set up the core LED nets:
  • LED_5V for power
  • LED_DATA for the data line
  • GND for ground

2) Trying to understand the basics (painfully)

• Watched hours of YouTube because I’m still trying to fully understand stuff like:
  • What GND really is and how it is shared across multiple parts.
  • Differences between types of pins and how different meanings mean the same thing (like the 10 different names for GND 😭).
  • How to wire an extra USB‑C port in a project that also has an MCU + battery (basically I want the USB‑C port to power the LEDs, and the battery should power the MCU).

3) USB‑C + Battery + MCU = brain melt

• Tried to combine the idea of:
  • Basically I want the USB‑C port to power the LEDs so they don’t work when running on battery (Travel Mode).
    (LED = the 5V rail; I also want it to power the battery and maybe the LCD.)
  • Battery powering the MCU.

---

What I Dropped

• I pretty much gave up (for now) on using a nice!nano v2 clone + two MCP23017 expanders.
• Reason: it turned into a nightmare:
  • Not as common as other MCUs in builds like this → fewer tutorials and schematics as references.
  • Too much trouble connecting to expanders, also not very price effective.
  • Worst part: wrong / misleading pin assignments in the ScottoKeebs symbol (at least compared to how the board is labeled and what I expected). 😭

---

Current Decision / Next Step

• Now I’m deciding between:
  • RP2040 (Arduino/RP2040 direction)
  • STM32 Blackpill (more common “real dev board”)
• I need something that’s more common, with enough pins to power my feature-heavy (also learning-heavy) project (with 84 keys, each key solo lit, two rotary encoders, 2.2" display, etc.).

1/6/2026 - Troubleshooting & Schematic

What I Did Today

1) Switched to Arduino RP2040

After abandoning the nice!nano + MCP23017 nightmare, I committed to the Raspberry Pi Pico (RP2040 (W?)).

• More common, way more tutorials, better community support.
• More GPIO pins for my 84-key + 2 encoders + display setup, but i still need one mcp.
• Actually affordable.

Sadly Bluetooth isn't available in QMK. So I'm considering ZMK instead. Fun times.

2) Library & Symbol Chaos

The SK6812MINI LED finally showed the "D" symbol, so in the footprint assigment stage they hat the same name as the Diodes

• Tried changing it in the Symbol libary, but Kicad gave me a pop up with "Failed to load"
• Needed to reinstall (again) all the libarys)

3) Net Labels

• Assigned net labels for everything and finally connected all the part
• Kicad hat problems with net labels for GND etc, so I learned that you need to use those things from the symbol library

Troubleshooting

• Symbol libraries → reinstalled, deleted old ones, now they work.
• ERC violations → some are legit, some are just KiCad being paranoid about multiple power outputs on the same net (ignored those).

Next steps

• Fixing all erc problems
• Aligning the Key switches etc. in the PCB, hopefully i understand the KLE importer Plugin

1/7/2026 - LED Matrix and Footprint Assigment

1) LED Matrix Updates

After looking at other keyboard projects and videos, I adopted the pattern of adding 0.1µF capacitors between VDD and GND on each LED to handle current spikes and reduce noise issues.

• Rewired the LED data chain so every LED is in the correct sequence.
• Added per‑LED 0.1µF decoupling caps plus one big bulk cap on the LED 5V rail.
• Double‑checked that LED5V, LEDDATA, and GND are cleanly labeled and shared across sheets.

2) Library & Symbol Chaos (Again)
Ran into repeated issues with the ScottoKeebs libraries randomly “disappearing” from KiCad, even though the paths were correctly configured.
Sometimes the symbols showed up but the footprints were missing in Assign Footprints, sometimes the entire library was reported as “not found”, which meant reinstalling and re‑adding things several times.

• Re‑added the ScottoKeebs symbol and footprint libraries multiple times.
• Fixed environment variables like SCOTT_KICAD and refreshed the footprint library tables.
• Cleared filters and cache in Assign Footprints so the SK6812MINI and Choc footprints finally showed up.

3) Footprints & PCB View Weirdness
After the libraries behaved and all components finally got proper footprints the PCB view just showed cables.

• Still don't understand what happened ...

4) Starting on Key Placement with KLE Placer
Began researching how to position all the Choc V2 switches with correct unit sizes (1u, 1.25u, 1.5u, 2u, etc.) without manually eyeballing everything.
Found KLE Placer as a bridge between Keyboard Layout Editor (KLE) and KiCad, and started experimenting with how to use it in this project.

• Looked into using KLE Placer to import that layout and auto‑place switch footprints on the PCB.
• Still in the learning phase, but now I understand which variables like x and y Difference i need to understand
• Need to research clearances between the chocs, the LEDs, Diodes and Condensatores

1/8/2026 - Starting PCB

PCB Kickoff + Plugin Chaos (again)

What I Did Today

1) Finished the schematic
I finally got the schematic to a “complete” state (matrix + controller side + extra parts) so I could properly move on to PCB layout.

2) Started the PCB + imported parts
Imported all the footprints into the PCB editor and began actually placing things instead of just staring at the schematic.

3) Installed kbplacer / KLE importer
I installed the keyboard layout plugin and followed the tutorial basically 1:1, but ran into issues with how it expects the diode-per-switch setup.

4) Diode placement problems → manual fix
kbplacer complained about the diode configuration (it thought there were multiple diodes per switch / the matrix association wasn’t unambiguous), so I stopped fighting it and just placed/adjusted the diodes manually to keep moving forward.

5) LEDs: placed them, then reality hit
I initially placed all the per-key LEDs too, but realized the specific LEDs I chose are flat SMD parts without “real pins”, meaning I’d need a stencil + reflow/hotplate workflow to solder them reliably (which I don’t have right now). The 0.1 uF Condensators were also to large to fit on / under the PCB (for those I assigned handwired ones)
So I decided: V1 will ship without per-key LEDs (maybe only a few accent LEDs later).

6) Electronics “right-side block” layout
I started laying out the right-side extension block. The goal is to fit the “motherboard area” (Pico/RP2040), MCP23017 expander, rotary encoders, and the big display into a tight space (~45×110mm).
To save space, I’m putting the controller board on the back side under the display area.

7) Saved LEDs as a separate project
Instead of deleting everything permanently, I saved the LED version as a separate project so I can revisit it later without losing work.

Next Steps

• Finish wiring/routing the remaining columns/rows (I started, but it’s far from done).
• Clean up placement and start serious routing for the right-side block (I2C, power, display lines, encoders).
• Decide if I want a tiny “accent LED” option for V1 or keep it fully LED-free for maximum simplicity.

1/10/2026 - PCB reorganizing

PCB Layout Progress + Component Research

What I Did Today

1) Rebuilt the LED Matrix (Again)

After deleting the previous LED setup, I realized SMD components CAN be hand-soldered with a regular soldering iron (especially larger packages like 1206 capacitors and SK6812MINI-E LEDs with pins).

Rebuilt the entire LED matrix in the schematic:

• 84× SK6812MINI-E LEDs
• 84× 0.1µF decoupling capacitors (one per LED)

2) Component Placement with KBplacer (Partial Success)

Used the KBplacer plugin to speed up placing repetitive components, but ran into several frustrating limitations:

Problems:

• No way to adjust spacing between components (fixed at plugin defaults)
• Can't automatically place components on the back side of the PCB
• Had to manually flip 252 components (84 LEDs + 84 caps + 84 diodes) to the back side one by one
• When selecting multiple components and pressing F to flip, everything just mirrors itself instead of just moving to the other layer

Ended up doing most placement semi-manually to get things on the correct side.

3) Right-Side Block Layout (First Pass)

Started laying out the "electronics section" on the right side of the keyboard:

Top side:

• 2× rotary encoders (top edge for easy access)
• 2.2" display (possibly touch-enabled, depending on budget)

Bottom side (under display):

• USB-C receptacle (positioned for easy cable access)
• Raspberry Pi Pico / RP2040 (mounted on back to save space)

Still uncertain about the final alignment and exact placement—need to iterate once I start routing traces.

4) Component Research + Footprint Changes

Spent time researching hand-solderable alternatives and updated several footprints to make assembly easier:

Changed components:

• 0.1µF capacitors: Switched to C12063216MetricPad1.33x1.80mmHandSolder (larger pads, much easier to solder by hand)
• USB-C receptacle: Selected HRO TYPE-C-31-M-12 (common hobby part, 16-pin USB 2.0, available cheap on AliExpress)
• Diodes: Decided on 1N4148 DO-35 (through-hole) or 1N4148W SOD-123 (larger SMD package) for easier soldering
• TP4056 charging IC: Using SOP-8 package (standard, hand-solderable with fine-tip iron)

5) Soldering Basics Research

Watched tutorials and read guides on:

• SMD soldering techniques with a regular iron
• Difference between through-hole vs. SMD components and which sizes are realistic for hand soldering
• How to solder SK6812MINI-E LEDs (PLCC4 package with legs) using the "tack one pin first" method

Key takeaway: 1206 SMD and SOD-123 diodes are totally doable by hand; smaller packages like 0603 or 0805 would be much harder.

---

Next Steps

• Finish wiring the left side (switch matrix rows/columns from keys → MCP23017 → Pico)
• Route the right-side block (I2C lines, encoder pins, display connections, USB-C power)
• Adjust pin assignments on the Pico/MCP23017 if routing gets messy
• Double-check component placement to ensure everything physically fits (especially under the display area)

---

1/11/2026 - Routing Progress & Layout Tweak

Switch spacing / Layout

Reduced spacing for “flow” aesthetic

• Reduced the spacing between switches (kbplacer Step X / Step Y) to save space and move closer to the low‑profile “flow” look.[1]
• After tightening the layout, I re-checked whether LEDs, diodes, and caps still fit without colliding.

Placement tool friction (kbplacer)

• kbplacer is great for initial placement, but it’s risky to re-run once routing has started, because placement changes can desync with already-routed traces.[2][1]

---

Matrix routing

Started rows + columns

• Began routing the rows and columns for the left side of the keyboard.
• Immediately ran into the classic dense-board problem: every routing decision blocks multiple future routes.

“Boxing myself in”

• With RGB + matrix on a 2-layer board, I kept ending up in situations where the only escape was adding multiple vias per key, which felt messy and hard to keep consistent.

---

LED routing

LED chain routing was the hardest part

• When I started routing the LED data chain, it felt basically impossible to do cleanly without using ~3 vias per switch.
• The LED chain kept colliding with rows/columns and I couldn’t find “clean corridors” through the keyboard.

Changed strategy: route LEDs first

• I duplicated the project and flipped the plan:
  • Route the LED chain first
  • Then route rows + columns around it
• This helped a lot, because the LED chain basically defines the routing channels and removes a ton of decision paralysis.

---

Manual cleanup work

Parts rotation + alignment fixes

• I ended up rotating/repositioning a lot of capacitors and other small parts manually.
• Reason: when using kbplacer again, it shifted the keyboard placement, but the already-routed columns didn’t move along with it, which broke the alignment.

Time sink: “just routing”

• Spent a big chunk of the session doing pure routing iteration:
• Trying different trace paths
• Undo/redo loops
• Minimizing vias where possible
• Cleaning traces so they look consistent and not like random spaghetti

---

Board outline update

Rounded corners for aesthetics

• Updated the Edge.Cuts outline to include ~5 mm rounded corners for a smoother look.[3][4]
• This was mostly an aesthetic change, but also makes the board feel less “sharp rectangle”.

---

Open questions / decisions

RP2040 performance uncertainty

• I only routed the left side today, because I’m still unsure whether the RP2040 will fully cover the final feature set.
• Goal features:
• Per-key RGB with effects
• Display animations
• Music-reactive visuals (LEDs + album art)
• Still deciding whether this requires PC-side software (host sends the “music analysis” data), or if a more powerful MCU approach is needed.

---

Next steps

• Decide on the MCU approach (stick with RP2040 + host-driven music visuals, or rethink the controller plan).
• Start routing the right-side electronics block (USB-C charging/power, encoders, display connections).
• Add/confirm power strategy (5V/GND zones) before finalizing the remaining routing.