We are close to the one year mark of use of the Leyden Jar controller in the F122 keyboards, and I can confirm the good news that I have received no new Leyden Jar bug reports in the past few months! Here are the ideas for future updates of the Leyden Jar controller. Credit for the ideas goes to Rico, Arkku, and other forum members.
If you would like to see anything else or have any feedback on these ideas, please reply here or email me.
Request for F122 testers:
For the first update, the idea is to remove the 1K resistors directly above each through hole (and of course bridge with solder), which were there initially to protect the other components on the controller; they are not needed.
For someone who ordered an F122 that hasn't shipped yet, please email me if you'd like to help the project by receiving your board with removed resistors, so that this can be tested for reliability with daily usage. In the unlikely event that it tests fine in the testing on my side but does not work reliably I'd be fine exchanging the controller for a regular production one with the resistors.
Additionally, anyone can feel free to remove their own 1K through hole resistors on their F122, but this would be done at your own risk. If you end up testing this, please do let me know the results.
As an update on the new keyboard project designs (split keyboards, etc.), Rico and I are hoping to start prototyping the new controller designs for my upcoming big order of controllers, expected over the coming months as the new keyboard designs are made.
(1) Firmware update that was discussed last year: Binning not with an equal number of keys for each bin, but instead binning the same resting values in one bin (and if there are more unique resting values than available bins, putting nearby resting values in the same bin only if needed). The firmware only uses the number of bins based on the number of unique resting values, with one or two adjacent numerical values going into a given bin. Currently there are instances where a key position is put into a bin of keys with higher or lower resting values because each bin has the same number of keys, which in the future may affect keyboards as debris enters the board and goes between flipper and capacitive PCB. This update would optimize the number of needed bins and maximize scan rate.
(2) PS/2 add-on. Folks emailing me about this are quite excited and looking forward to it. Some possibly helpful PS/2 RP2040 QMK projects:
https://github.com/tmk/tinyusb_ps2https://github.com/No0ne/ps2x2picohttps://github.com/BuzzL123/QMK-PS2-USB-Dual-Mode-Keyboard(3) Rev4 controller update discussion ideas:
Topic 1: add a few through holes to be populated only if split keyboard functionality is needed. Two controllers communicate through a USB-C cable, sharing momentary function layer status, sharing shift key status by default for Mac, etc. while allowing use of the solenoid driver and LED lock lights at the same time. A small PCB with a USB-C receptacle would be used for split keyboards.
Topic 2: IO pins - add support to use both the column IO pins and also custom code and through holes to support the unused pins on the IO Expander, which are not natively supported in QMK/Vial. If the Rev4 supports both options, it will maximize flexibility for future proofing rotary encoders, solenoid drivers/solenoids, LEDs, etc. Extra pins might go towards the "split keyboard case, 3 IO pins for a rotary encoder, more for any other feature that you'd want in the future but have not yet thought about" (to quote Rico).
