Leyden Jar, tentative controller replacement for the Brand New Model F Keyboard

[Rico]

Hello keeb lovers,

Long time no see in this ‘Making Stuff Together’ 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:
https://static.wongcornall.com/ibm-capsense-usb-web/ibm-capsense-usb.html

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

• 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.
• The small ATMEGA32u2 MCU used in those designs struggle to make everything fit in it’s memory.
• There is a silicon shortage and those Atmel MCUs are now very hard to find and expensive for what they are.
• I want to know if I can do it 

So here we are with the Leyden Jar PCB, name taken from the first ever (crude) capacitor ever invented:
https://en.wikipedia.org/wiki/Leyden_jar

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.

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

Here is a graphic view of the PCB.

Top

Bottom


See ya!

[Ellipse]

Great work Rico!  I am looking forward to this project as a potential controller for the Model F and beam spring projects.

[Rico]

Ty Ellipse!

As you suggested I added 3 pins to the connector to be able to drive the leds in the future.

The PCB is designed to be able to easily manufactured assembled at JLCPCB as all components are listed on their site.

And I ordered a few assembled PCBs yesterday, we'll see shortly the amount of mistakes I made on this revision.

[Rico]

I received the PCBs for JLCPCB.
Everything is assembled but the push button and the QSPI flash (were out of stock at JLCPCB at that time).



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 ****ty 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!

[Rico]

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

Code: [Select]

Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.
code.py output:
Scanning I2C bus 0
0x50
0x60
2 device(s) found on I2C bus 0
Scanning I2C bus 1
0x18
1 device(s) found on I2C bus 1
Code done running.
This is looking good, all my 3 I2C devices are correctly detected
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.

[suicidal_orange]

Good work, I love the rounded and irregularly spaced traces - reminds me of old school hand drawn PCBs

[Rico]

Thank you for your nice feedback!

Yes, some old PCBs had those organic traces: as they were hand drawn PCB designers could sometimes have a little bit of fun.

For the Leyden Jar some traces are rounded in order to limit signal reflection, not needed for the whole design but I found it would be nice looking to do that for all the traces.

[Ellipse]

I had a question on the 16x8 matrix.  The beam 122 will likely have close to 128 keys (104/105 keys for standard ANSI/ISO + 12 F13-F24 keys + 10 keys for the left side block); close to the 128 maximum allowed on a 16x8 matrix. With this limitation, compromises will possibly be needed for those wanting to order custom layout 122-style beam spring keyboards, especially if they want additional keys like splitting the backspace, etc.

Would your updated controller design allow for an additional optional column or two?  It might be tricky with maintaining backwards compatibility (maybe a solder pad to switch it from being an extra column to being a ground column?  Or add it as a 34th pin if that is not possible).

[Rico]

I have 2 IO pins still unused so I may be possible in the future to add one or two additional columns.
There are indeed a few ground pins that could be repurposed for that (thinking about the two in the middle of the connector).
This will need some PCB redesign though and lose compatibility as a result, but as I will probably find a few things to tune in the future, it could be for the Rev2 of the board.

I have yet to find time to check that the matrix scanning can work with this design, will take me a bit of time.
If it works well then:
- will need to check if the solenoid can work (unfortunately I don't have one on hand).
- will brainstorm the possibility of one or two additional column.
- make a rev 2 of the board.

[Rico]

After a few weeks of holidays I am back on track to work on this project.
The goal is to now see if capacitive detection is working as well as on the LTSpice simulations.

Below is a test setup with one switch:



And the results I got were at first unexpected: not only it proved to work, but was working too well based on my initial expectations.
I could detect exactly the voltage value when no colum/row was connected, with the same value as the simulations.
But when a capacitor was wired the detected voltage level was out of the roof, so high that anything bigger than 0.5pF capacitance was out of my detectable voltage range (a maximun of 1V).
As I had only conducted serious LTSpice simulation on a full 16x8 switch matrix I told myself that I missed something for my understanding, so began to make simulations of a single switch.
… And I could obtain very close results compared to my initial test, great!

Also when adding columns in the mix the detected voltage level is getting lower and lower.
Let’s see what happens with a 5 colums and 5 rows matrix:



And I obtain very close results to my simulations of the same matrix with ~20pF of parasitic capacitance!

I am starting to think that having a working controller is now more a question of ‘when’ than a question of ‘if’ 
To be 100% sure I have to write a full QMK firmware, let’s go!

[Rico]

I am happy to say that things progressed quite a bit!

The first step was to design a good matrix scanning program.
This is more difficult than it looks, as during my simulations I saw that I had only 1us window to read all the row values.
So it works no problem using CPU polling if you want to read only one row (and this is what I did to check that the PCB was working as intended).
But reading 8 rows by reading IO pins using the CPU and expecting to have consistent results is another matter…
Several factors can make this process using the CPU unreliable:

• We could simply not have time to scan all 8 row IO pins, and we’d miss key presses.
• This could ‘work’ most of the time, but be interrupted by an external code or kernel process and miss some keypresses as a result.
• The timing at witch to read the IO pins is important, a bit sooner or a bit later and we can have slightly different results; we need to have this timing very consistant (I measured an optimum time of 0.8us between activating a column and reading row IO pins).

While current Model-F PCB is reading row IO pins using CPU “as fast as possible” (said Tom Wong-Cornall in it’s blog), this not gonna do it at least for my design.

But I knew that from the start thanks to the LTSpice simulations and selected the right MCU for this task 
Hello RP2040 and it’s PIO feature!
I should be able to make a PIO program to do the matrix scanning without CPU usage and very tight and consistent timings.
I took me a while to do that (my first time doing PIO stuff and this is another specialized hardware to learn) but finally had my PIO matrix scanning program working like a charm :slight_smile:

Second step, test this matrix scanning program on the real beast, my own Model-F F77 board.
For that I needed to desolder the current PCB and solder the Leyden Jar PCB.
This was a big step for me as it would not only determine that my PCB work on the real hardware, but also would validate that everything fits nicely mechanically.
Not entering too much into details, I have to say that the official PCB has been a ***** to desolder :frowning:
But here is the result:



This is ugly but had to put back the kapton tape as the lower part of the PCB is touching the bottom case (as with the official PCB).



Happy that everything screws and fits as intended, there is even place for my SWD connector for developping/debugging!
Debugging session that started shortly after:



So how does it works?
First the detected voltages are lower than in my simulations:

• This is normal as we now have to deal with parasitic capacitance and inductance.
• I have very early timings in my PIO program, this could improve in the future (already tweaked a few things to make it better).
• We are using 3.3V for the column IO pins instead of 5V for the official PCB, having a lower voltage peak was more or less planned.

But the most important thing to have is consistency and we have excellent consistency here:

• We have only ~1mV deviation for the same keys tested during several tests sessions.
• Variance between all unpressed keys is 8mV at most (looks to be the same with pressed keys).
• We have a peak voltage variance of ~30mV between pressed and unpressed key, this is more than enough to perform a very stable key press detection :slight_smile:
• Pressing several keys at once or only one does not look to change the detected peak voltage much.

I think that the key of this consistency is to have a reliable 3.3V voltage source as it is generated by the onboard voltage regulator.
On the other end, I had some undetected keys problems with the official PCB when plugged on my ****ty USB hub; this may be explained by some fluctuations on the 5V line, that even the calibration program can’t handle. No problem when plugged on my PC USB ports though 

To conclude this will definitely work like a charm and I am excited to start writing a VIAL firmware to confirm this.

On top of that there is another good news, the scanning process is quite fast: as of now scanning all 16 columns and 8 rows takes only 640uS (40uS per column).
This could change in the future:

• If changing the timings helps to have better peak voltage detection it could end to be slower.
• But it could also be possible to have something even faster 

[geewiz]

Well done! That's some impressive work, and I'm excited to see your progress. Thanks for sharing it with us!

[Rico]

Those last days I worked mostly on having an early QMK/VIAL firmware working on my F77 board equiped with the Leyden Jar PCB.

Although I previously had a 'bare metal' program using the Pico SDK that demonstrated that the hardware was working nicely I was afraid to find many QMK integration problems.

Problem 1:

When talking about QMK firmware there is a significant software fragmentation issue.
This started by the VIAL fork in order to have an opensource alternative to VIA software.
Then due to the need to add support to  the RP2040 MCU, things got even worse and you can find on the net many git repositories that gives early support for it.
Fortunately QMK has recently added official support of RP2040 into their main branch, but VIAL did not yet merged this support to their own repo.
So had to select one of the numerous git VIAL repositories for my integration task.
Fortunately Zykrah, very active in VIAL Discord, did all the tedious task of merging official QMK RP2040 support to it's own VIAL repository:
https://github.com/zykrah/vial-qmk/tree/vial-develop
All my work will use this repository as a base.

Problem 2:

As my matrix scanning is using PIO, I was not sure yet what kind of support would be available for that, if any.
Looking at the QMK source code, there are official support of WS2812 led drivers using PIO.
IO pin configuration is using ChibiOS HAL api directly and for PIO stuff the Pico SDK API is used.
Let's see if I can do the same thing for my PIO matrix scanning program.

I had to perform different tasks in order to hope to have everything working:

• Review QMK source code to understand how/what RP2040 support was added.
• Configure a work enviromnent to be able to use a SWD debugger.
• Review previous QMK firmware source codes that implement F77/F62 firmware using the official controller, mostly to understand or reuse how physical rows/columns are arranged.

And this last task proved to be more complicated  that planned: to my surprise I could not easily reuse the work already done.
So time to start a debugging session and see what happen when you press the buttons, came with this ugly postit writeup of the matrix reverse engineering:




Fortunately using PIO proved not to be the headache I was fearing.

I was soon greated by the VIAL keymap display



And finally could validate that all the keys were working with the matrix tester 



It is very early, need a lot code polish and add missing features, but it works !

Things that work:

• All keys work.
• Storage settings on external EEPROM works.
• Storage settings on RP2040 flash storage also works! I was surprised by seeing this feature added in QMK repo. Now need to choose between EEPROM and flash, if flash is selected I could remove the EEPROM chip for future PCB revisions.
• Key commands to reset the MCU and erase the storage settings (EEPROM or flash) are also working.

Things not done:

• Implement a proper voltage threshold calibration program, as of now it is harcoded and may not work on other boards.
• Implement solenoid support, unfortunately I don't have such hardware at the moment so this task alone could take time.
• Tidy up code, fix bugs, add F62 support.

Happy man I am 

[Rico]

The Model-F solenoid and it’s driver just arrived, ty very much Ellipse for having sent this so quickly!

So now on to try to make it work!

I already checked that the solenoid connector on the Leyden Jar PCB was correctly wired, good

I could work a bit on the software part also.
Having the connector pins connected to the I2C IO expander makes things a bit more complicated as QMK firmware does not handle this case at the moment.
With a bit of cheating and after studying QMK haptic/solenoid management code I could come with something not too terrible.

Was the time to work on the solenoid support and to discover if a 3.3V logic would be enough to drive it correctly.

I had read long time before the datasheets of both the current limit and the darlington array chips that are used inside the solenoid driver PCB.
At that time I concluded that a 3.3V signal would be enough to make everything working.
It is time to confirm that I guessed well !

Here is my current test setup in picture with everything attached:



After a long time of frustrations, numerous failures, and fear that in the end it may not work, I finally managed to make it work perfectly
And oh boy this thing is noisy as f**k

I have been very lucky up until now, having everything working as hoped.
Of course this design is still not perfect and may need further investigations and probably a revision 2.

Things that are still to do:

• Cap sensing voltage variations are smaller than I intended, need to investigate how to improve that. This does not prevent to make Model F keyboards work very nicely, just that with more columns used things could get more complicated and would prevent BeamSpring keyboards to work reliably enough. I could try to improve this my modifying the current revision of the board.
• Solenoid is driven by IO pins from the I2C IO expander chip. QMK has native support to only direct MCU IO pins usage; had to do little code tricks to make everything work. Would be best to use MCU IO pins next time.
  
• Current design uses 2 I2C devices; again the QMK API does manage only one I2C device, I had to rely on ChibiOS API to drive the second one, complicating the code a bit. I’d wire all used I2C chips to only one I2C device for the next design.
• External I2C EEPROM chip is now not needed as QMK has official support for EEPROM emulation using RP2040 flash storage; I tested that both were indeed working but would remove the external chip to reduce BOM (and then cost).
• Ellipse would like to have 2 additional columns to drive for possible future BeamSpring projet, like for example a 122 keys battleship. I saw a possibility of doing that and may add it in a future revision.

See ya !

[Rico]

After a long yatus, please let me give some update on the Leyden Jar project.

This project is not dead, far from it.
In fact I collaborated with Ellipse on making the Leyden Jar controller work on one of it's Beam Spring Full Size Rev 2 keyboards.
After quite a few exchanges and tries (had to make a firmware without owning the board) Ellipse now have a fully working Beam Spring keyboard, with VIAL support, Solenoid and LEDs!

I then quickly worked on the Revision 2 of the board, adding Ellipse suggestions.
One was to support two additional columns, for a total of 18.
Another was to support in the future a daughterboard connected in place of the solenoid controller and that would allow native PS/2 AT support.

Here are renders of the new PCB:




And I am also happy to announce that the project is now officially open source under the GPLv3 licence!
Here is the link to the repository below:
https://github.com/mymakercorner/Leyden_Jar

Plan for Ellipse is to use this PCB for the Model F122 keyboards, the two additional columns will be put to good use