The Leyden Jar, a tentative PCB replacement for the Brand New Model F Keyboards

Hello keeb lovers,

Long time no see in this ‘Making keyboards’ section!

This time it is not for a new home made keyboard case and PCB combo, only a PCB for an existing keyboard.

But what a keyboard!
I am talking about the Model F keyboards and specially the F62 and F77 variants that @Ellipse made.
IBM Model F was the predecessor of the IBM Model M, another iconic board that I learned programming on a long time ago.
In term of feeling/tactility the Model F does not disappoint: this is a pure joy to type on, really something that everyone should try at least once in a lifetime.

Long before having my own I wanted to undergo the task of making my own PCB for it.
So started to look at various documentation about the electro-capacitive technology behind those boards.
The IBM patents are an interesting read, but the place were I found the most information is on the website of the creator of the original Model-F-USB controllers, Tom Wong-Cornall:

Why making another PCB ? After all there is already a PCB on the new Model Fs that has QMK/VIA support.
The reasons are:

  1. Not much has improved in the technology behind those PCBs since 2014: most if not all PCBs are based on Tom Wong-Cornall design, up to the components used.
  2. The small ATMEGA32u2 MCU used in those designs struggle to make everything fit in it’s memory.
  3. There is a silicon shortage and those Atmel MCUs are now very hard to find and expensive for what they are.
  4. I want to know if I can do it :smiley:

So here we are with the Leyden Jar PCB, name taken from the first ever (crude) capacitor ever invented: Leyden jar - Wikipedia

Some quick specs:

  • A modern RP2040 MCU
  • Columns directly driven by IO pins (original design uses a IO pin multiplexer that can also work as level shifter).
  • Lots of flash storage (16Mbits).
  • Lots of EEPROM external storage (512Kbits).
  • Uses I2C protocol for EEPROM and DAC chips, saves a few pins doing that.

After having seen Gondolindrim constantly use the LTSpice software for simulation, I learned the tool and could make a simulation of a full Model F matrix work.
Without this tool it would have been impossible to find the right technique and components values.
We’ll see how it work in practice but Gondo told me that LTSpice was already giving a good approximation of how things should work(if used well) so I have hope :wink:

There is a lot of things that could go wrong in this design as a lot of things are new to me.
As a result I have a list of stepping stones or goals in mind, so that if the boards is unusable on my Model F I have at least learned something in the process.

  1. Have the RP2040 succesfully starting and flashable.
  2. Can use SWD debugging on it, do the reset circuitry work ?
  3. Can configure and use the EEPROM and DAC chip through I2C.
  4. Can validate that the capacitive sensing works outside of a Model F keyboard.
  5. Can use one of the QMK fork to have a real firmware.
  6. Can make the solenoid work (do not have a solenoid at the moment).

I should be able to order my first fully assembled PCBs at JLCPCB very soon.
Here is a graphic view of the PCB.



See ya people!


This is great Rico! Please keep us updated on this project!

I am definitely looking to switch the Brand New Model F and Brand New Beam Spring projects to an open source RP2040 based controller due to the chip shortage.

Please see the below 33 pin controller design that is the latest version of the project controller, for reference. It allows the 3 LEDs of the beam spring keyboards to be a part of the PCB instead of through wires, and it is also backwards compatible for all of the new Model F keyboards.

It seems like QMK support is in progress but not yet completed for the RP2040, and there are other projects like KMK which seem to work with the RP2040. The question is, is it better to go with KMK? How stable is it? It may take a while for QMK RP2040 support to be ready. Some recent related links:

What would it take to get the Model F firmware working on the RP2040 chip?


Hello @Ellipse,

Thank you very much for your interest in my little project!
I am not sure yet I will succeed but will definitely try.

A big thank you for the link to the last PCB design you have, this will probably help me understand how the 3 leds are working, and will try to add this feature in my PCB (but I only have 2 free IO pins left).
Looks like Diptrace program have been used for the design, never used it but will see what I can do.
I could at least have a look at the PCB design and there are several dimensions displayed that I had to measure by hand on the real PCB, this will help me tune my holes positioning if needed.

As for KMK vs QMK.

KMK is a very nice technology and the RP2040 chip is powerfull enough to run it without any problem.
But asking people to dive into Python programming to adapt their layout will probably be too much for most.
Also I am not sure how easy it is to implement a custom matrix scanning on it.

IMO QMK/VIA/VIAL should be the way to go, while dealing with the problems you mentioned earlier.
My take on that is that RP2040 port to QMK is seriously taken by QMK and ChibiOS team and it is only a matter of time.
In the mean time if KalrK90 fork is working as intended an early support could already been done.
With VIA/VIAL support people don’t really need to dive in to firmware compiling themselves.
Also this early situation would not be that much different from the current status of firmware for the current hardware … until full RP2040 support is officially supported on QMK of course.


A little bit of news.

I took @Ellipse suggestion into account of adding support to the 3 leds for the future beam spring keyboards.
It has not been easy as I had only 2 free pins left and I initially needed 3.
So added an IO expander that will be in charge of driving both the solenoid and the 3 leds.
It is controlled by the second available I2C controller of the RP2040, the first one been used by both the external EEPROM and the DAC.

Cleaned up a few things, and voilà!

Now on to double/triple check and send all that for fabrication !


I had the pleasure to test the Kicad 6 plugin “JLCBCB Tools” by Bouni:

I highly recommend it, this dramatically helps filling the BOM information when you want to go through JLCPB or at least order components at LCSC.
The one button that generates all the fabrication files for JLCPCB (gerbers, BOM, POS files) is a god-like feature :slight_smile:

The PCB references only components that are listed at JLCPCB so one could easily make it’s own without having to solder anything.

Just ordered 5 assembled PCBs at JLCPCB, most chips were in stock except the buttons and the QSPI flash.
There were lots of stock available at Mouser so ordered them here and will solder them by hand.

Will keep you posted of my progress!


Just a bit of news on the PCB fabrication and assembly, and some generation information on PCB fabrication at JLCPCB in general.

You may know that often the component placement preview can be messed up at JLCPCB, and they say there will be manual review to correctly place the components.

Here is an example on the Leyden Jar PCB, before the correction:

Pretty messed up uh ?
This was even worse on the preview before doing the order, some resistors were completely outside the PCB area.

And after manual correction:

This is just perfect!

So if you plan to order an assembled PCB at JLCPCB, don’t be put off by weird components placements on the preview, this will be fixed later.
They may even ask you confirmation by email if they have a doubt.

And also you can check daily the production process, they give very precise information.
For example I know that as of now I have 15% of PCB fabrication complete, with the top and first hidden layer manufactured.
And also that they corrected the placement of the components for the future assembly process :wink:


The PCB just came into my doorstep, and they are beautifully made :slight_smile:
Sorry for the, as usual, crappy picture.

Now need to solder the missing parts that JLCPCB didn’t have (the Winbond QSPI flash and the switches) and then begin the testing to see how far I succeeded (or how fast I failed).


Had a little bit of time this WE to work on the PCB.

First, to solder all the missing components on the PCB, that is the push buttons and the QSPI flash. I was not too concerned about beeing able to solder the buttons, the QSPI flash on the other side …
This flash comes in a very tiny USON8 package, with 8 connections on a 3x2mm package. I decided to not stress the already soldered components too much by using hot air soldering, and used my trusted soldering station with a small tip instead.
Here is the result once soldered:

And now the moment of truth, that is plugging the thing in with an USB cable.
For this kind of first connection attempt on all my newly designed PCB I always use an USB hub and never the USB ports on my PC.
The reason ? If something bad happens it fries my shitty 15$ USB hub and not the USB ports on my costly 300$ motherboard (in happened to me before, not with my own designs though).

Let’s go!

Yay, it works!
Having this already validates a lot of things:

  • USB connection and ESD protection correctly wired.
  • 3.3V voltage regulator is correctly working.
  • RP2040 MCU, crystal, and bypass capacitors wiring are good.

This does not yet validate that the QSPI flash is working, for that we have to flash an executable file in UF2 format to see if it works.
But my design is using the same 2MB Winbond flash as the Raspberry Pi Pico board, so why not trying to install CircuitPython on it ?

It works!
Now the QSPI flash is known to work correctly.
I also tested that the two push button ‘Run’ and ‘Bootsel’ were doing their job correctly, that is reset the device and also be able to boot from the ROM.

Things not validated yet are if the SWD interface is working correctly and all the surrounding design that is Model-F/Beamspring specific.
This is my next step and now that CircuitPython is installed why not do that in Python ?

See you!


A quick python script to scan for i2c devices on i2c0 and i2c1 and here is the result:

Auto-reload is on. Simply save files over USB to run them or enter REPL to disable. output:
Scanning I2C bus 0
2 device(s) found on I2C bus 0
Scanning I2C bus 1
1 device(s) found on I2C bus 1
Code done running.

This is looking good, all my 3 I2C devices are correctly detected :slight_smile:
This means that I have good chance to have working:

  • The external EEPROM.
  • The DAC chip to set the voltage reference value for the comparators.
  • The IO expander to drive solenoid and LEDs.

Another little news about testing the PCB.

While writing small python code to check the I2C devices was very time effective, it is not how I want to proceed to fully proof test all hardware components.
And before starting firmware development with QMK I need to write the basic libraries to pilot the various devices and put in place the matrix scanning stategy.

  1. I want full control of the hardware and adequate speed so Python will not fit my development purposes, will use the great C++ Pico SDK instead.
  2. I want to iterate fast so drag and dropping compiled executable file each time I make a code modification is out of question, need hardware SWD debugging.

But fortunately there is a way to use a standard Pico PCB as a SWD debugger, this way I can upload and debug code under VS Code editor and go fast.

Already did that some time ago to debug programs with two Pico PCBs, there is a great article that explains it:

And I recently found a new one that explains how to wire everything while using USB port to power the target board:

Here is my debugging setup:

Yellow wire is SWCLK, Orange is SWDIO and Green is ground.
Green wire is very important as both boards (Pico PCB that contain picoprobe software and Leyden Jar PC) need to share their ground, it will not work without it!

And the debugging session of a very basic progran that runs on the Leyden Jar PCB:

So the two SWD pins are working correctly, nice :slight_smile:
I feel at home with a real debugger :stuck_out_tongue: