geekhack Projects > Making Stuff Together!
Leyden Jar, tentative controller replacement for the Brand New Model F Keyboard
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 :p
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 :p
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 :D
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 ;)
Navigation
[0] Message Index
[*] Previous page
Go to full version