deskthority

Please fill out the Google form linked below to reserve or request one of the possible new Model F designs (Split Ortho, Planck, Preonic, 6x12, F20, Kinesis Advantage, Unsaver, etc.). All of these designs may not be made, so in the Google form, please do feel free to request second choices and third choices should your first choice not be made, but clearly indicate whether you want all of the designs or if you will order only one of the designs you indicated interest in.


https://forms.gle/bBBcQGW6g7HvACpc8


Hello everyone - I am the project coordinator for the Brand New Model F and Beam Spring Keyboards projects, which offers Model F and beam spring keyboards in various layouts (122 104 SSK 77 62 50 and split ergonomic) and styles (Compact and Classic styles). Currently everything is in stock except the balance of F122 keyboards and the Round 2 Beam Spring boards, and and more than 6,000 new capacitive keyboards have shipped since 2019.

I have been requesting feedback that folks may have regarding additional Model F keyboard designs that will have enough orders to cover the production costs. One-off designs that only you and a few others would buy are unfortunately cost-prohibitive due to the setup/tooling costs to make each unique design, so unless you want to spend tens of thousands of dollars please suggest boards that will likely have at least 25-50 keyboards' worth of interest at the expected $399 pricing.

Besides those listed below and the ones that have already been made for the new Model F project, which board styles and layouts are most popular?

For each design below, please let me know the quantity you are interested in at the expected pricing of $399, and provide any feedback regarding design / style / layout and any other aspects. So far I have made no designs so we are only limited by the physical specifications of the Model F and beam spring design parameters. Do folks want LED lock lights (Num/Caps/Scroll) on these smaller boards?

The biggest new advances for these boards will be:

(1) Rico's RP2040-based Leyden Jar controller, which has much more memory than the ATMEGA chips powering the previous projects (more room for the increased number of layers that may be more important on smaller and ergonomic style boards) and its plans for communication between controllers, so as to allow one USB cable to the computer and direct communication between halves of a split keyboard. These controllers are currently being used in the B104, B122, and F122 keyboards. The previous Split Ergo Model F used two usb cables and the QTY 50 units produced sold out quite quickly.

(2) The possibility to use a 4 layer board to make as compact a Model F design as possible, thus avoiding the need for extra area on the sides. The credit for this idea goes to wcass, who is also the designer of all the new Model F and beam spring project boards and compact xwhatsit controllers.

So far we have requests for the following which can be made with compact cases, probably 25 to 50 minimum order quantity at a $399 price:


Ergodox Style Split Ortho with Leyden Jar controller (one USB cable and second keyboard half connected to the first half).

4x12 ortho Model F (Planck style)

5x12 ortho Model F (Preonic style)

6x12 ortho Model F

F20 num pad

Kinesis Advantage2 and/or Advantage 360 Pro style

Beam Spring models - we can make compact beam spring ortholinear and other models as well, but the demand is quite low so far.

palm rests?


There was also some discussion about making a new Model F Unsaver. The thing is that you'd need a new top case mold for each additional design that cannot be easily CNC milled, which is quite costly. The bottom can be stamped like with the F104/FSSK/F122, which would not require a mold. The alternative is a flat case like for the compact models, which may not work for such a tall model as the unsaver.

Requests for die cast only cases (needs around 150-200 minimum order quantity for a $399 keyboard cost, unless some folks chip in for the tooling):

Unsaver



To save some time in your survey responses, here are some previous requests and mods that are not likely to be factory options:

Transparent keys (would require a different mold since the type of plastic would be different)

LED lighting for each key (does not make much sense when the keys have no transparent or translucent areas and the steel plate blocks visibility of the large capacitive PCB underneath each key)

Flip out Model M style feet (would require several very expensive injection molds)

Bluetooth wireless - this is possible, see discussion here, but someone would need to help: https://www.modelfkeyboards.com/questio ... nectivity/

Mods to reduce or eliminate pinging / ringing and Trackpoint mod – adding a trackpoint to your New Model F keyboard, flush mount USB-C connector - already done, see the manual on the project web site for details

PS/2 communication - unnecessary given the presence of reverse adapters, but Rico is looking into adding a PS/2 port for those who want a built-in solution. PS/2 offers no benefits in terms of responsiveness or speed for the Model F keyboard, and it has several disadvantages including power limitations (can't run a solenoid). Also full NKRO is available for all current new Model F and new beam spring keyboards - PS/2 is not necessary to have NKRO with a Model F or beam spring keyboard.

Any updates on the beamspring boards? Last I heard prototypes were approved.

Yes, quite a number of updates since then! Check out the dedicated beam spring project thread: viewtopic.php?p=524241#p524241

Everyone please do check out the manual on the project web site as I am currently in progress of a major update, which has reorganized the setup process under more manageable steps which encourage folks to take one step at a time and review just the contents of that step before going through that step, instead of the previous suggestion to go over everything before starting. As always, if you can suggest (privately by email or message) some specific feedback on what to update or if something is out of place, it would be much appreciated.

Hey Ellipse -- was hoping for an update on F122s. The last check in was about six weeks ago and there has been a lot going on in the world since then. I guess I have a short list of questions I was hoping to answer:

- You said it would take a couple months to test / ship the KBs from the first batch. How's that going?

- As someone who splurged for a low SN / early ship (over a year ago), should I hold out any hope that my KB is in the batch that already arrived or am I holding out for the next shipment? I don't need my personal status per se, just a general outlook. I'm not trying to be rude or angry, I've just gotten antsy checking for updates and finally couldn't resist asking anymore.

- How is the second shipment coming along? The first shipment went out before CNY (so 3 moths ago) -- is the second shipment at sea yet or still waiting at the factory?

- The biggest question -- how is this whole chaotic US Tarriff situation affecting you / the project?

F122 update:

I am working on the first batch of F122 orders, with priority towards the low/custom serials (it is still OK to add a custom/low serial upgrade to your F122). I want to make sure everything is good so as to avoid the need for folks to do a firmware update. There are about 150 boards to go out. This process only started recently; it did not start as soon as the keyboards arrived last month. The goal was to get out that shipment out of China as quickly as possible (even if I was not ready to ship them soon after they were expected to arrive), and the shipment ended up leaving the port only days before the first tariffs went into effect.

As always for each board I do the final QC, including making sure each key pad registers in the signal level monitor. In addition to creating the entire Leyden Jar controller hardware, firmware, and diagnostic utility (!), Rico has been very helpful in fine-tuning the firmware for the production units. Extra attention needs to be paid to the calibration bins and the threshold offset values, so I've been trying various firmwares that vary these settings so I can put the best one on the boards.

As mentioned in the prior F122 update, some boards are in the first batch that arrived several weeks ago, while others are in the future batch that the factory is working to complete this month (they had to remake a small number of individual parts that were damaged or defective - I've asked them to make extras for future orders so that we won't have to wait to remake parts to complete a current order). I won't be confirming everyone's order to see which batch they are in as my focus is to get these orders out as quickly as possible. The low serial upgrades are definitely appreciated to help cover project cost overruns, but it doesn't mean your board is prioritized during factory production; it means that your board is prioritized for shipping once it is in stock. The factory makes these keyboards by variation number, doing all boards of a particular variation at one time; they did not do 50% of each variation or prioritize making just the keyboards that were already ordered as that is not a feasible production process. Currently there are several hundred variations of the Model F keyboards that the factory has made.

It's always slower for a new product as I physically set up and test a sample of the first keyboards going out, with different variations (this does not mean that all the single digit serials get set up, for example). This is a slow process. I do a good amount of testing to measure the signal output of each key, as well as doing typing tests. I am definitely taking my time with extra caution for the F122's since this is the very first Leyden Jar RP2040 powered keyboards.

I mentioned an update about the tariffs earlier this month (see that post a bit earlier in this thread for details). Currently they have no effect on the project, as nothing has shipped in the past few weeks since they went into effect. As mentioned earlier, the current tariff rate for the HTS number 8471 containing keyboards was temporarily lowered to 20% on the production cost, which is not something that would cause an insurmountable issue if it were to remain in place.

Currently this is not an available option but something I might consider, in addition to the other strategies noted before, is to allow folks in the second batch to switch their keyboard to an in stock variation, after all the keyboards from the current batch have shipped. Please do not email me asking to switch now as I don't know which keyboards will be available until I've tested and mailed out the first batch.

If you are not picky with the case colors, please order a color other than Off-White/Beige or Industrial Gray. Those colors were more popular than expected and I want to make sure some are still available in the future for those who are not flexible.

Below are my current updates to the manual for the Leyden Jar firmware, which includes a discussion of optimizing the firmware. The firmware will have various options for folks who want some choices. I note below the current plans for which firmware I will be flashing to each F122 during QC - a firmware designed with maximum compatibility and ease of use. Despite being a max compatibility firmware, this firmware setting will have a scan rate that is three times faster than the xwhatsit.

Also below is a photo of one of the aforementioned keyboards that I have been testing and optimizing firmware with; it will be going to a user of the German layout (pardon the cell phone quality): Flashing Leyden Jar - can use Windows, Mac, and Linux (same instructions):

For keyboards with the Raspberry Pi RP2040-based Leyden Jar controller (F122, B104, B122, and others in the future)

Open the Leyden Jar diagnostic tool, which is in a folder inside the comprehensive QMK-layout-files.zip file linked above, click Refresh Device List, and click Enter Bootloader.  After clicking Enter Bootloader, an empty hard drive named "RPI-RP2" will appear in your computer's Explorer.  All you have to do is copy to this drive the .uf2 file inside one of the leyden_jar_firmware_package folders which can be found in the QMK-layout-files.zip file linked above.  There are several firmware variants with different numbers of calibration bins and activation offsets. 

I recommend the one with 5 calibration bins and an activation offset of 7.  A higher number of calibration bins allows for a margin of safety around keys with different unpressed capacitance levels (for example, if there were only 1 bin then all keys would activate at the same value, but some keys may have an unpressed value close to or higher than the activation level, meaning a key would send a signal to the computer without being pressed.  I like to see the pressed value at least 3 higher than the DAC Threshold for that key's bin, and an unpressed value at least 3 less than the DAC Threshold for that key's bin (with capacitive PCBs, a pressed key may change the capacitance of other keys). 

Calibration bins allow for different activation levels based on the initial unpressed level of each key when the keyboard is first plugged in.  More bins is safer but there is a performance penalty that is infinitesimally small, several thousandths of a second.  Rico notes that matrix scans are 3 times faster on the Leyden Jar compared to the xwhatsit controller (720us to scan 18 columns compared to xwhatsit's around 2ms since it is a 500hz polling rate). In other words, 5 bins would be 5 x 720us = about 3.5ms total scan time for 5 bins on the Leyden Jar compared to 5 x 2ms = 10ms for 5 bins on the xwhatsit. The xwhatsit Vial firmware uses 5 bins, so the RP2040 could even use 15 bins and still have approximately the same scan rate performance as the xwhatsit controller. 

The default Leyden Jar firmware is expected to have 5 bins and an activation offset of 7 to be more foolproof, but premade firmware files with fewer bins and varying offsets are also available in the above zip file (for folks who want theoretically the best performance that they can never actually notice in real-world usage!).  Firmwares with 2 bins may be more likely to have issues with one or two keys sending a signal without being pressed, so I do not recommend them.  Be sure to close the Leyden Jar diagnostic tool before using Vial.rocks or the Vial software.

Thanks for the detailed update Ellipse -- it is greatly appreciated. I know there's lots going on, and writing it all up can feel like a distraction, but it's really good to hear how things are progressing.

Stolen keyboard alert:

Everyone please keep an eye out for a True Red Model M style case F104, serial number 680 which was stolen earlier this month. Please let me know right away if you come across such a listing, or if you see a listing for a keyboard without a serial label shown.

can i get f77 update.

Irving wrote: 10 Feb 2025, 18:27 This is what I would like to achieve:
o I would like to have the Globe/fn key (as a key code) available for MacOS windows management as well as for bringing up the character viewer.
o In addition, I would want the function keys acting as the media keys etc. as available on an original Apple keyboard.

Hi, I know it's been a while since you asked this, and you have already received some good workarounds (e.g., Caps Lock mapping in recent macOS versions, and Karabiner elements).

If those solutions work for you, then it will save a lot of effort to just do either or both of those. I'm also using Karabiner elements anyway to remap keys on my MacBook Pro's internal keyboard where firmware solutions are not possible.

If, for some reason, you can't or don't want to use these solutions, then the only options seems to be to compile a custom firmware with these changes:

• the USB vendor and product ids must match an Apple keyboard with the features you want (and this means it is unlikely that any firmware project will support this out of the box)
• the USB HID report (i.e., the packet of data that the keyboard sends to the computer to indicate which keys are pressed) must be configured to have a custom field dedicated to the Apple vendor-specific extensions, i.e., the Fn/Globe key is not possible to precisely replicate with any "normal" keycode, which means you need USB protocol level code changes in the firmware to support this key
• a key must be mapped to some kind of custom "meta keycode" that causes the keyboard to use the Apple vendor-specific part of the HID report for that key, rather than the normal USB HID standard keycodes part

For QMK-based firmwares, there is a popular patch available here: https://gist.github.com/fauxpark/010dcf ... e37414c6c4

It may or may not work with QMK versions that support these keyboards. In the comments there is a link to another patch that works with newer firmware versions. There is also an expanded version by me, that I'm using with a different keyboard, but that is based on the older version of the original path and I haven't kept it up to date (since everything that I want works fine with the older version): https://gist.github.com/arkku/95e661db1 ... a8d5bc9850 – in the comments there is a link from someone else to a modified version that may or may not work with latest QMK firmwares.

To use these patches you would first need to download the source code and the necessary development tools to build a custom firmware for your keyboard. Then, once you have that working, you would apply the patch with "git apply", test that it still builds, and then edit the configuration to add the bindings you want (see the first comment under my patch for slightly more details), and change the USB vendor and product ids. (Apple's vendor id is 0x05AC and one ISO layout keyboard with an Fn key has the product id 0x021E – this works for me. These aren't secrets: you can see them by plugging in such a keyboard and looking at the list of connected USB devices.)

Hopefully this helps – use AI assistants if you need further guidance! Unfortunately I'm not able to offer support for this approach since I've switched to my own firmware for the keyboards that I have (but I don't have the FSSK so I haven't implemented support for it, and in any case my firmware is aimed more at the developer-tinkerers – if you identify as one, it isn't particularly hard to add support for the keyboard, e.g., see the F50 that I added most recently and do the same changes for the FSSK using the files from the QMK firmware as source).

Oh, and if you fake being an Apple keyboard (at least the model mentioned above), the F-keys will start to work as the Apple special keys automatically.

Still, if at all feasible, the Caps Lock and/or Karabiner elements solutions are far easier.

Ellipse wrote: 24 Apr 2025, 06:25 Rico notes that matrix scans are 3 times faster on the Leyden Jar compared to the xwhatsit controller (720us to scan 18 columns compared to xwhatsit's around 2ms since it is a 500hz polling rate). In other words, 5 bins would be 5 x 720us = about 3.5ms total scan time for 5 bins on the Leyden Jar compared to 5 x 2ms = 10ms for 5 bins on the xwhatsit. The xwhatsit Vial firmware uses 5 bins, so the RP2040 could even use 15 bins and still have approximately the same scan rate performance as the xwhatsit controller. 

Technical nitpicking, but poll rate and scan time are independent. Basically the scan takes as long as it takes and then updates the key matrix state, while independently the poll rate determines how often the USB report is generated. In theory you could have a 100 ms scan time and then poll it at 1 ms intervals - you'd just not see any changes until a new scan is completed, but then after the scan it would take a maximum of 1 ms before the state is polled. In comparison, if you set the poll rate to 10 Hz (every 100 ms) because of the long scan time, it would mean you might have to wait another 100 ms after the scan completion until the change would be polled. So having a faster poll rate does still decrease latency, and similarly you can't look at the poll rate and assume the scan time.

I did measure the actual scan time of the xwhatsit controller's default firmware at some point, but sadly I don't remember what it was, but I'm pretty sure it is actually quite a bit more than 2 ms (in total for the keyboard). By optimizing the code for my firmware I got it down to under 1 ms (for the whole keyboard, but in fairness one of the "key" optimizations was to only scan bins and columns that have mapped keys in them, and this means the effective number of bins scanned was either 1 or 2 because the calibration ended up not needing more – another optimization was to not artificially force extra bins to be used if the keys were close enough in their levels to not need more).

sl70309 are you looking for an update on an order? Generally the backlog is 1-2 months, as noted on the Updates page on the project web site.

Update: the F122 orders have started shipping out this week. A lot of folks like the transparent relegendables with these keyboards. Please do share photos of how you have customized your transparent relegendable Model F / M keys, whether new or original, as I have not seen too many such photos. Any advice for how to use these keys?

Thanks Arkku for this discussion! That is great information. I like your idea to set the number of bins based on the number of keys with different bins, and turn off / not use more bins than necessary. Would this be implementable in the new Leyden Jar Vial firmware (linked below)? For example, it could set each bin for all keys with a resting value of a certain value plus/minus 1, 2, or 3 values either higher or lower (not both higher and lower; easily user-adjustable by a variable. Should each bin's reference level be the highest level of keys in that bin, or the lowest?).

This would allow a lower offset to be used, which could be helpful to keep keyboards running even if they have some dust or debris that enter under the flipper at some point in time (these flippers would produce a weaker signal so the offset / value change when the key is pressed would be smaller). So for example it could put 378 and 379 resting values for one bin, 380 and 381 for another, one key with a 386 value on its own bin, and one key with 393 on another bin.

Sometimes with the F122 keyboards (they use the Leyden Jar controller), there are some keys that have a much higher resting value, and these values differ among these few keys. The current firmware hard-codes some of these keys to have their own custom bin, but sometimes the resting levels vary even between those keys so they shouldn't both be in one bin.

Do you (or does anyone else) have additional recommendations for the Leyden Jar project and firmware?

https://github.com/mymakercorner/vial-q ... leyden_jar

Ellipse wrote: 01 May 2025, 20:39I like your idea to set the number of bins based on the number of keys with different bins, and turn off / not use more bins than necessary. Would this be implementable in the new Leyden Jar Vial firmware (linked below)? For example, it could set each bin for all keys with a resting value of a certain value plus/minus 1, 2, or 3 values either higher or lower (not both higher and lower; easily user-adjustable by a variable. Should each bin's reference level be the highest level of keys in that bin, or the lowest?).

I haven't looked at the details of how the Leyden Jar firmware is implemented, but assuming the hardware works similarly to the xwhatit's-based controller: sure, the same optimizations can be done, but the actual values for the thresholds would differ and would probably need to be determined by trial and error.

As for what value to use for each bin, IIRC the approach used in my firmware's auto-calibration is to take the average value of that bin and then offset it by a magic number to make it less sensitive. This magic number is what needs to be determined by trial and error based on the hardware – it's basically an offset that is sufficiently large that there are no phantom keypresses, but not so high that it would stop real keypresses from being detected. It also indirectly determines how many bins are needed: there must be enough bins that the keys in the same bin are close enough that they all work after the offset is applied (i.e., the average value is ok to use because no key in the same bin differs greatly from it).

The maximum number of bins is hardcoded at compile time and can't be changed, but as long as the difference between keys is small compared to the magic number, there is no reason to use all of those bins. All four of my model F keyboards work with either 1 or 2 bins – not sure whether the keys will start to deviate more with age.

Then it's just a matter of optimizing the code to be able to skip any unnecessary scans. And there are some additional micro-optimizations possible, like do every other scan in the opposite direction (this saves changing the DAC settings once per scan because the last setting of the previous scan is the first setting of the next – although it makes the latency of some keys variable since the scan order is not always the same). When talking about fractions of milliseconds, these do add up.

I've got an update regarding my warn paint.

Three months ago I received a replacement case for my f62 because the paint did not last at all. I'm pleased to say that the new case is holding up perfectly. There is no wear to speak off. The paint hasn't softened and rubbed off like my last case. My experience is that there is a difference between the paint in my two cases, despite there being no expected change to the formula.

I started using the first case on the 2024-02-22, and this photo was coincidentally taken exactly three months later on 2024-05-22. I replaced the case on the 2025-01-29 and today on 2025-05-02, a bit over three months later, it's still perfect. The new case is an industrial grey. Both cases experienced their first three months in the summer to autumn months. They were both used full time. They were both used in the same room and neither of them were transported at all.

I'm pleased that my new case is holding up. I'm now of the opinion that the paint on the previous case was defective and there isn't something about me that was causing it to dissolve.

Re. scan time and bins, on my F77 the calibration seems to first put keys into two bins, but it notices they are so close that it moves all of the keys into one bin. The scan time with one bin ends up at 0.63 ms. (I haven't made external tools for the firmware so it has a debug mode where it uses the keyboard itself to "type" this kind of debug info into a text editor. The row data are bit masks of columns in that row/bin – all keys end up in bin 1 at the end but bin 2 shows non-zero rows so some columns were originally placed there.)

That is great to hear Arkku!

Having manually analyzed many production F122 keyboards, including their unpressed and pressed values for each key, I believe that an offset of 6-7 (difference between pressed and unpressed values for a particular key) is acceptable for virtually all F122 keys if bins only allow 2 or 3 adjacent numbers for each bin, in terms of unpressed values. So I think your updated Leyden Jar firmware could start with those figures as an initial version.

To keep things simple I would like each bin's reference level to stay the same as what Rico has set. I like that your firmware plans for future deviance requiring more bins, without needing to recompile firmware in the future.

resonator thanks for your update. Glad your keyboard case is holding up so far but I do still expect it to wear over time. Please do keep us updated every once in a while.

Ellipse wrote: Yesterday, 19:55So I think your updated Leyden Jar firmware could start with those figures as an initial version.

To avoid false hopes: I'm not working on any version of the Leyden Jar firmware, since all of my keyboards have a xwhatit's controller. (Still on the fence whether I "need" more keyboards, though I'm slightly tempted by the FSSK and the round 2 beam springs, but, let's see.)