Let there be light! (and usb high speed and rotary encoders)

Added in the rotary encoder. Not much to say, was just 5 wires after figuring out what was what and what goes where.

When getting ready for the LEDs (figuring out what pins on the STM32 I wanted to use), I realized that PA11 and PA12 are for USB Full Speed, not USB High Speed. It was a simple switch, moving the D- and D+ lanes to PB14 and PB15 instead, allowing me to actually reach the 8000Hz polling rate target goal.

Now, the fun part. LEDs! I decided to go with the SK6812s as they are cheap, good, and widely used in custom keyboard projects so there will be a lot of documentation widely available for the firmware. The first challenge was they expect a 5V data input, while the STM32F405 does 3.3V. That we fix with the 74AHCT125 which will boost our 3.3V data input to 5V. We can then send that into the DIN of our first LED, and daisy-chain the rest. Yay!

Connect that to a SPI capable pin on the STM32 and we are officially in business 🥳

Now, its just reviewing the schematic for any mistakes, then its on to the footprint!

Keys, multiplexers, and Hierarchical Sheets!

Created the circuit for the keys and wired all 64x keys, and 8x multiplexers.

They key circuit works because when idle (0 magnetic flux), the TMR sensor produces +1.65V (when supplied with +3.3VA). Treating this as our "baseline" unactuated state, when a magnetic switch is installed in the socket, pressing it will cause a magnetic flux that the firmware can take the absolute value of the difference (as we don't know if the magnetic in the switch is north facing, or south facing) from +1.65V, and compare that to a minimum actuation requirement. When the mechanical switch is installed, the TMR sensor will continue to output that "baseline" +1.65V. By treating the mechanical switch as a simple short, by wiring it directly to GND, the firmware would see a voltage drop from +1.65V to 0V, and detect a key press. The TMR sensor would be protected by a resistor between it's VOUT and the signal lane.

Tada! A socket that is capable of supporting both magnetic and mechanical switches (theoretically, of course).

Also, in the process of this, I discovered Hierarchical Sheets in KiCad. Saved me a lot of space in wiring everything to the STM32. I also moved the multiplexer circuit into a hierarchical sheet as it was rather large as well.

Next step is either going to be the rotary encoder, or the LEDs, but we're almost there!

Power!

Got the two LDOs for digital and analog power into the schematic. Also, one schematic page was getting a bit crowded so I moved the STM32 into its own page, and put the power circuitry into another. Thats all :)

Next, I have to first create a circuit for one key, connect it to the multiplexer, then copy that 64 times. Onward!

Power, clock, USB Headers, SWD, and more components

The STM32 finally has power! I spent a lot of time digging through the datasheet and figuring out what needs to go where and I think I have it right:

• all 4x VDD + 1x VBAT pins are connected to +3.3VD with a 100nF capacitor to ground for each pin
• VSS is straight to GND
• 1x VDDA is connected to +3.3VA with a 100nF capacitor, AND connected to VSSA with a 1uF capacitor
• VSSA is straight to GND
• VCAP1 and VCAP2 are connected to GND with a 2.2uF capacitor each

Then I had to get the 8MHz crystal connected to the PH0 and PH1 pins to serve as the clock for the STM32. Both pins also need to be connected to GND with a 22pF capacitor each. There is also a 1MΩ resistor in the circuit between the two pins.

I decided to add pins for SWD as i'd rather have them and not need them, then need them and not have them :). Those went straight into PA13 and PA14, and will lead to a pogo pin of sorts on the PCB when I start on that.

For the USB headers, I needed those to go to PA11 and PA12 for D- and D+ respectively. The D+ trace also needs a pull up to +3.3VD with a 1.5kΩ resistor.

I opted to not add a button for NRST or BOOT0 as I can just short the BOOT0 pin to flash QMK/VIAL for the first time, and then just use them to flash the firmware over USB DFU if needed in the future. I also have SWD available. So those ended up just leading to GND for BOOT0 (low for booting firmware) with a 10kΩ resistor, and to +3.3VD for NRST with a 10kΩ resistor and to GND with a 100nF capacitor.

Next steps are adding in the LDOs for converting the +5V USB power to two +3.3V power lanes, one for digital components, and one for analog components. I decided to use the TPS7A47000RGWT as my LDO as it had good specs and an agreeable price in the right form factor. Big thanks to SnapEDA for having the symbol, footprint, and 3d model!

After that its LED time!

Removed a key, started wiring the schematic, and researched

Updated the keyboard to only have a total of 64 keys as I am using a 8:1 multiplexer and adding the 65th key was having me use a entire 9th multiplexer for only one key.

Big thanks to SnapEDA for having the footprint and 3d model for the TMUX1308!

Now that I have most of the symbols that I need, I've started wiring the schematic, but first had to spend a lot of time reading through the STM32F405RGT6 datasheet and TMUX1308 datasheet to figure out what the correct pins to use were. Currently, this is how its wired:

• The multiplexer select pins (A0-A2) are wired to pins PC13-PC15 (2-4) on the STM32.
• The data lanes from the multiplexers are wired to pins PA0-PA7 (14-23) on the STM32 as they support ADC.

Adding the 9th multiplexer meant i'd have to use pin PB0 (25) which is a little bit further away on the footprint, and I'd rather have all of the data lanes in one area.

Also added the JST connector and wired it to GND and +5V power.

I haven't wired up the 3.3V power yet as I'm still trying to figure out where certain capacitors and crystals need to go... I'll add in the LDO soon, just first have to confirm that it doesn't need anything else and can be connected straight to the +5V power.

I also decided to use 2 LDOs, one for powering the STM32, MUXs, and mechanical switches, and another for powering the TMR sensors and other analog components on the STM32. This protects the TMR sensors from any instability in the power plane from the MUXs switching and keeps them stable.

Updated TMR2652D Footprint

Learnt that I completely messed up on the footprint for the TMR2652D sensor so had to start that from scratch. Found a base DFN6 3x2mm footprint in KiCad but it had a pitch of 0.5mm, while the TMR2652D has a pitch of 0.65mm between pins, so I used the same tool to generate the base footprint to generate a new symbol for the TMR2652D that hopefully should be accurate.

Created project repository and started on PCB schematic

Finally got around to creating a project repository. Spent some time adding in a commit standard following Conventional Commits to keep commits organized and readable.
Decided on the following project structure:

• qmk_firmware: submodule of a fork of the qmk/qmk_firmware repository. Currently unchanged from upstream, but thats soon to change!
• hardware: all of the KiCad project files as well as any custom symbols & footprints needed.

Put the keyboard layout and preview image in the repository as well. I'll add other folders as parts & files (EG, case, BOM, etc.) are added but for now thats sufficient.

I licensed the project under the GNU General Public License v3.0 as QMK is licensed under it, and I believe since i'm including my qmk/qmk_firmware fork in my repository, I have to license the entire project under GPL-3.0 as well.

Started on the KiCad schematic and PCB layout. The majority of the time was spent creating a symbol and footprint for the MDT TMR2652D-P3 sensor as I couldn't find an available premade schematic, and wanted to challenge myself to see if I could make it. Followed this datasheet and I think it turned out pretty well. It took a lot of time (almost 3 hours!) to ensure everything was to spec and I learnt a lot as this was my first time using KiCad ever.

Now its on to finding/creating symbols for the other parts (switches, MUXs, etc.) and then getting a working schematic going.

Designed Keyboard Layout

Used https://www.keyboard-layout-editor.com/#/ to design the layout. Went with a 65% keyboard layout, with a 6.25u space bar and space for a rotary switch in the top right corner (currently blank).

Here's a link to the layout

Researched TMR Sensors

Interesting video that helped me understand and better plan the alignment of the magnetic switch and the TMR sensor. TLDR, the TMR sensor must be offset in order to properly detect the magnetic switch as if the switch was directly above the sensor, then the field of the magnetic would be parallel to the sensitive element inside of the sensor, causing no output. Introducing the offset allows for a component of the magnetic field that aligns perpendicularly to the sensitive element of the sensor to produce an output.

https://www.youtube.com/watch?v=wz2ZO3kSfNE

Established Project Criteria and Developed Initial Plan

Created a list of criteria for the keyboard to meet:

• 65% Keyboard in standard ANSI layout
• Full support for both magnetic and mechanical switches on the same hot-swappable socket
• Wired USB-C connectivity
• Addressable RGB backlight
• Customizable, open source firmware
• High performance, 8000Hz polling rate

Researched and created an initial plan, as well as a BOM and project write up.

The keyboard will consist of a 4 layer PCB, comprised of the following:

• Layer 1: Mechanical sockets, Microcontroller, and JST connector
• Layer 2: Solid Ground plane
• Layer 3: Power plane
• Layer 4: TMR sensors, multiplexers, and RGB LEDs

A daughterboard will be fixed to the case, connected to the mainboard via a flexible JST connector, allowing the mainboard to be friction fit and flex when pressed without snapping the connector.

The TMR sensors will be placed at an offset from the socket on the top layer. This should allow compatibility with both magnetic and mechanical switches.

The TMR sensors and mechanical switches will be wired in line. The mechanical switch will be connected to the ground plane and a signal line to the multiplexer. The TMR sensor will be connected to the ground plane, a power plane, and a resistor which leads to the signal line. When a magnetic switch is used, the TMR sensor will produce an analog output into the signal line, the mechanical switch will not produce any output. When a mechanical switch is used, the switch will connect the ground and signal line creating an output sent to the multiplexer. The TMR sensor will not be affected as the resistor separates it from the mechanical switch.
Magnetic switch pressed -> TMR Sensor output -> Resistor -> Mux -> MCU ->
Mechanical switch pressed -> signal is pulled down to 0V, resistor limits TMR sensor's output -> Mux -> MCU

The RGB LEDs are connected to the power and ground plane, and daisy chained. The first LED will be connected to the MCU and controlled via PWM output.

Each MUX can handle 16 inputs each. With a total of 61 keys, 4 MUXs would be required.

The TMR sensors and the MCU should be on separate power planes.

Tentative BOM:

• STM32F405RGT6 Microcontroller 1x ($10.40)

• Texas Instruments CD74HC4067M96 Multiplexer 4x ($3.12 @ $0.78ea)

• Texas Instruments TPS7A2033PDBVR LDO 2x ($0.64 @ $0.32ea)

• MULTIDIMENSION TMR2652D-P5 TMR Sensor 65x ($96.85 @ $1.49ea)

• Gateron Hot-swap PCB 2.0 Socket 70x ($7.00)

• GEON Raw HE Switch 61x ($29.28 @ $0.48ea)

• NeoPixel Reverse Mount RGB LEDs - 10 Pack 7x ($26.60 @ $2.66ea)

• 1kΩ Resistor 70x ($?)