geekhack Projects > Making Stuff Together!

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

(1/3) > >>

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  ;D
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: ---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.
--- End code ---

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.

Navigation

[0] Message Index

[#] Next page