F104+SSK+122+62+77+50+Ergo orders now open! New Kishsaver+Industrial Model F Keyboards

[lucwilride]

Hello all, new to the forum. I just ordered an F77 original case the other day and I'm very excited for the board. Just curious, are these still shipping with the classic styrofoam packaging or the updated smaller packaging used by the modern/compact versions?

[Ellipse]

Still Styrofoam for now

[lucwilride]

Thanks for confirming

[Ellipse]

Fourth container shipment update (final round keyboards for F62/F77):

The forwarder picked up the shipping container. This shipment should arrive to me in about 2-3 months (significant congestion in the port of NY and a major shortage of truckers from what I was told). Below are some photos of the beginning of the loading stage (Only some of the boxes are visible in these photos but it will be a full 40' container). Hopefully the factory will send additional photos later.

1.jpg (291.32 KiB) Viewed 20071 times

2.jpg (336.02 KiB) Viewed 20071 times

3.jpg (283.26 KiB) Viewed 20071 times

4.jpg (178.69 KiB) Viewed 20071 times

5.jpg (98.67 KiB) Viewed 20071 times

[Ellipse]

Assemble your own new Model F Keyboard - any interest?

I have enough spare parts to offer about 40-50 keyboards unassembled (just the flippers and springs would be assembled). Please PM or email me if interested and I can send details. The savings would be very small compared to an assembled kit but it would be a fun project. You would be issued a serial label and box label with a keyboard kit.

[zrrion]

considering I received mine only partially assembled I'd expect that getting them completely unassembled wouldn't be too far off the usual experience

[Scarpia]

Assemble your own new Model F Keyboard - any interest?

I have enough spare parts to offer about 40-50 keyboards unassembled (just the flippers and springs would be assembled). Please PM or email me if interested and I can send details. The savings would be very small compared to an assembled kit but it would be a fun project. You would be issued a serial label and box label with a keyboard kit.

Here’s a thought: if the self-assembly variant came with a different part number or “KIT EDITION” marking on the case sticker, it would both make it easier to track these special boards later, it’s definitely prestigious to have a kit board that you built yourself (and you might like to show off this fact to other collectors), and I would think it’d make it even more attractive to those who are already drawn to the rarity factor of these boards. I know personally I would find that simple addition to be a real cherry on top.

[Muirium]

<Contains provisional keyboard.>

Some assembly and bug fixing is required.

[doureios]

Assemble your own new Model F Keyboard - any interest?

considering I received mine only partially assembled I'd expect that getting them completely unassembled wouldn't be too far off the usual experience

I'll gladly take my outstanding F77 order unassembled if it makes it come any sooner. I plan to disassemble it anyway to add a barrel to split the spacebar (among other things). It wouldn't be too much more work to affix the circuit boards and drop in the flippers.

Since I already paid, would it be possible to do something like toss in a solenoid kit or some more spare parts? I have no clue how much of a discount you're talking about.

[Arkku]

In case anyone other than myself is using my firmware, I further optimised it: calibration is now about 2–3 times faster (but, to be fair, the sub-second calibration time was never really an issue). More importantly, the assignment of keys to bins is now more dynamic and should further ensure fast scan times: Previously the bins were just evenly spaced before any keys were assigned, which sometimes meant that keys end up unnecessarily split into different bins even though they might all be close enough that one bin would suffice. (After other optimisations I've made earlier, the matrix scanning is faster when some of the calibration bins are empty.) Now the bin thresholds are only set when the first keys are assigned to them.

Personally I'm still always seeing only one calibration bin with keys assigned to it, only the threshold varies a bit over time (the greatest differences are seen with the keyboard case open). So far this seems to be fine: I have not seen a single instance of a key being unreliable in practice, and I've been using these keyboards daily for work ever since I got them. I have three of the keyboards so I hope that's a decent sample size, but it annoys me a bit that some of the constants related to calibration are cargo cult stuff from the other firmwares and I don't know the basis for picking those exact values (maybe trial and error based on someone else's keyboards?).

https://github.com/arkku/aakbd/releases/tag/0.9.5

[Ellipse]

Thanks for the update Arkku. I wonder if any of the improvements over QMK should be incorporated in the Model F QMK?

I recall some folks having issues when they set up their keyboard with a key being stuck and it affects operation. Seems like a good idea to not send a key press signal to the computer for a key that is pressed when the keyboard initializes, if that key is programmed for something and is not a key marked as normally pressed, and to disregard this key for the threshold calibration.

[Arkku]

Thanks for the update Arkku. I wonder if any of the improvements over QMK should be incorporated in the Model F QMK?

At least some of the speed optimisations are such that I consider them strictly better with no downsides (e.g., skipping empty bins, not writing the same DAC threshold again if it was already at that). The calibration changes could have theoretical downsides since I have not been able to test it with any keyboard having big variation in key thresholds, but for my keyboards it has been an improvement.

So, yes, I would suggest backporting the changes to QMK. Technically it should be rather easy, just copy the matrix.c file and then rename a few things in other files referring to it, but the bigger issue is that QMK supports all the different controller variants and IBM keyboards that I (sadly) don't have available to test. (Also, I don't really have much motivation to do QMK development since I specifically made my own firmware to replace QMK, but of course it is all GPL open source so anyone can try it and see what happens.)

[Muirium]

IBM keyboards that I (sadly) don't have available to test

I could help you with that. Bear in mind I’m not a proficient coder, and I’m strictly Mac based. But I know my way around flashing hex files and have a good bit of experience of different firmwares on these two Xwhatsit powered IBMs: a beamspring and a Kishsaver.

[Arkku]

IBM keyboards that I (sadly) don't have available to test

I could help you with that. Bear in mind I’m not a proficient coder, and I’m strictly Mac based. But I know my way around flashing hex files and have a good bit of experience of different firmwares on these two Xwhatsit powered IBMs: a beamspring and a Kishsaver.

Sure, if you want to test on those, we can give it a try! I'm also mostly a Mac user, and I do the development on Mac, so that's actually a good thing as we can use the same tools… Can you give/link me the QMK configurations that work for those keyboards, and I can then check what it would take to a) build my firmware for those keyboards, and b) build those QMK configurations with my changes backported?

[Muirium]

Cool. I’ll grab you a json for my Kishsaver and 3278 when I’m home. I always save those from (Pandrew’s capsense modified) QMK configurator along with my hex files, as I know I’ll always be back to fiddle with some detail or another soon enough.

If QMK saved config specific urls like TMK Unimap does, I’d just grab you a link. But those editors are swings and roundabouts…

[Muirium]

Attached: zipped json and hex files for my three Xwhatsit boards, all OG IBM: Kishsaver, AT and beamspring.Layers but no macros in these. I’m doing all of that in Karabiner.

Three Amigos.zip

(75.93 KiB) Downloaded 133 times

I'd say to bear in mind the beamspring's capsense is the opposite polarisation to the two Model F's—the fly plates sit on the sense pads and only lift on actuation—but I bet you're way ahead of me.

Edit: Seeing as some folk are downloading this, let me explain those downright weird F16-18 keys:

As promised, my latest update: 🖱 Numpad Mouse Keys

This mode is entered by pressing Fn + M (mouse) on my HHKB. (Behind the scenes, I remapped Fn + M to F16 for this purpose.) You exit the mode by pressing Fn + N (navigation) right beside it. (Mapped to F18 internally, for Karabiner to catch it.) I didn't use a toggle this time because leaving the HHKB in Mouse mode is too disruptive. I want to be able to jam it directly in and out this mode without needing to think about it. So dedicated Mouse and Navigation Fn keys it is.

No, I’m not pining for the majestic, terminal fjords. Just hijacking phantom keys.

[Arkku]

Attached: zipped json and hex files for my three Xwhatsit boards, all OG IBM: Kishsaver, AT and beamspring.Layers but no macros in these.

Ok, let's start with the simplest experiment: I forked the latest QMK firmware, then copied my slightly modified pandrew firmware xwhatsit directory into it, and finally copied my updated matrix file over that. I didn't do anything to the bindings, so you won't have manual control over the calibration saving to EEPROM or any diagnostics about calibration, but if these work, then at least we have confirmed that the changes themselves are backportable to QMK.

Three Amigos AAQMKK.zip

(74.36 KiB) Downloaded 125 times

P. S. To stay on topic for this thread, I tried already with the F77, and it appears to work, so looks like it really is as simple as copying matrix.c and matrix_manipulate.h from AAKBD and changing two lines in util_comm.c.

It is available here: https://github.com/arkku/qmk_firmware

I can't host a web configurator for this version, though.

[Ellipse]

Speaking of QMK configurators, can anyone provide a working setup/instructions/files for a QMK Model F configurator site like pandrew's site? I'd like to put one on the project web site. In my own testing, following pandrew's files and help from some forum members I was unable to set up a working solution.

[Muirium]

Code: Select all

USB device disconnected: Tom Wong-Cornall/Purdea Andrei IBM Model F AT (0481:0002:0001)
Atmel DFU device connected: ATMEL ATmega32U2 DFU (03EB:2FF0:0000)
Attempting to flash, please don't remove device
> dfu-programmer atmega32u2 erase --force
> Erasing flash...  Success
> Checking memory from 0x0 to 0x6FFF...  Empty
> dfu-programmer atmega32u2 flash --force /Users/muirium/Downloads/Three Amigos AAQMKK/xwhatsit_ibm_fat_xwhatsit_locklights_muat.hex
> 0%                            100%  Programming 0x5500 bytes...
> [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
> 0%                            100%  Reading 0x7000 bytes...
> [>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>]  Success
> Validating...  Success
> 0x5500 bytes written into 0x7000 bytes memory (75.89%)
> dfu-programmer atmega32u2 reset
Atmel DFU device disconnected: ATMEL ATmega32U2 DFU (03EB:2FF0:0000)
Flash complete
USB device connected: Tom Wong-Cornall/Purdea Andrei IBM Model F AT (0481:0002:0001)

So ee I am on Arkku's fimware on my AT. As you can see it's mostly working just as it should! Statup is definitely quicke tan on Pandew's QMK. The AT boots up real quick now, nice! Trrouble is that missing H key—hey you're working now? I power cycled te boarrd a few times—damn it, h is definitely still flaky—just to see if it sakes out. No, there's definitely some dodginess wit te old IBM ardwaer and tese levels.

Still, a promising start! Love aving all my features in place!

[Arkku]

The flakiness is almost certainly due to the calibration having been only tested with the new keyboards. I will try to get you a version that can output the calibration info so we can see which direction to adjust, but promising overall!

[Muirium]

FWIW: In my 10 minutes of testing earlier, I had one key double firing (oversensitive) but several more hardly firing at all (undersensitive); quite simultaneously. So finding the sweet spot may be a little complex!

Indeed, that was always Xwhatsit’s Achilles heel. Pandrew’s system is much better, albeit at the cost of taking longer to start up as it measures all of those calibration levels. There may indeed be a smarter way to do this, but it will take some work. It’s not just automatic out of the box.

[Arkku]

Indeed, that was always Xwhatsit’s Achilles heel. Pandrew’s system is much better, albeit at the cost of taking longer to start up as it measures all of those calibration levels. There may indeed be a smarter way to do this, but it will take some work. It’s not just automatic out of the box.

My method measures all of those calibration levels as well. The speed-up is due to doing 8 keys in parallel instead of one at a time, not due to somehow measuring less precisely. (In fact, I would argue that my algorithm is more precise, because it is less prone to randomness.)

However, the key difference is that pandrew's algorithm is more eager to split the keys into multiple bins (but that slows down scanning, and with the new model F keyboards has been completely unnecessary for me). I may have gone too far in the other direction. Another possibility is that the threshold between pressed and not pressed needs adjustment since the calibration changes result in a slightly different threshold. The DAC is 4 times more precise on your keyboard than the new ones, so if the value is right on the edge (as it seems to be), the imprecision of the new controllers might cause the values to round to correctly and hide the issue. Yet another possibility is that my attempt at correcting invalid calibration from keys held on launch is causing the issue if your keyboard genuinely has just a couple of keys that are significantly different from the others.

Anyway, we will hopefully find out once I have time to compile AAKBD for your keyboard, then we can use the debug output to see the exact results of the calibration.

[Muirium]

The quick brown fox jumps over the vintage IBM on her way to the lazy brown dog.

Looks like the second version you sent me is a whole lot better tuned for original Model Fs. Fantastic! I'll give this one an extended test drive, it sure feels like a keeper.

[Muirium]

Kishsaver's working perfectly well now too. And my Beamspring! Remarkably fuss-free, I must say. Especially with my layouts exactly as I left them.

Arkku's firmware has the µ seal of approval for use on vintage IBM.

Edit: Actually, there is one thing wrong, but it may not be new to Arkku's firmware. When I dare to put the solenoid on, I can out-type it quite easily—as I am right now—which may be a dwell time issue. Oddly, it still sounds as snappy-tap-tap as usual, but it's getting saturated by my not at all remarkable WPM. I very seldom leave it toggled on like this, as it's such a racket, but I don't recall Pandrew's QMK doing this. Might need a tweak, too. The actual typing is solid, though.

[Ellipse]

With permission I am quoting someone's interesting experimentation to adjust the spring length and add o rings to the keys, and some questions for everyone:

"I am working on an ergonomics-motivated modification to reduce key travel on the Model F. As part of the process, I have to stretch the springs by just the right amount to move the actuation point closer to the top of the keystroke. This is a pretty tedious and error-prone process, and once over-stretched, I find it difficult to compress the springs again without introducing buzz, so I am going through a lot of springs this way. For my purposes, the ideal spring length is 18.75mm, as measured by my Vernier calipers."

My reply: During my R&D, I actually ordered 2 batches of springs slightly longer than my current batch, 18.475mm and 18.5 mm. [note 9/7/22 I still have more than 160 springs available of each type if anyone's interested - please PM or email me]

Replying to me: "I just installed the new springs in a couple of keys that were giving me some issues, and I am happy to report that the longer springs work really well. They require just a very gentle stretch to work with 0.4mm EPDM O-rings around the stem (a trick carried over from the Cherry MX world -- see attached). This reduces vertical key travel a bit and makes the keyboard a little easier on the tendons. I am somewhat curious to see how much more I can reduce it, but that is a task for another day when I have more free time. For now this already makes a huge difference in comfort.

What other ergonomics tricks are you aware of with the F62/F77? One of the things I really struggle with is the height of the thing. I built up a temporary palm/wrist rest out of an existing one and some cut pieces of a mouse pad stacked on top of one another to form a gentle slope toward the middle. This helps with using the space bar without making my thumb tendons too angry and the slight "hill" in the middle takes some load off of the pisiform bone when resting the hands. I made a thread with some ideas here. I am curious to see how others solved similar problems."

modelf_key_with_0_4mm_epdm_oring.jpeg (389.61 KiB) Viewed 18797 times

modelf_temporary_palm_rest.jpeg (379.99 KiB) Viewed 18797 times

[Takashi]

Running my keyboard with a new computer now, and so far, no problems with that the keyboard does not work without plugging it in/out! After using it for about a month now, I don't see myself ever using something else!

I've also made a tiny video about the keyboard

[ivor_h]

What other ergonomics tricks are you aware of with the F62/F77? One of the things I really struggle with is the height of the thing. I built up a temporary palm/wrist rest out of an existing one and some cut pieces of a mouse pad stacked on top of one another to form a gentle slope toward the middle. This helps with using the space bar without making my thumb tendons too angry and the slight "hill" in the middle takes some load off of the pisiform bone when resting the hands. I made a thread with some ideas here. I am curious to see how others solved similar problems.

Interesting re. the rubber rings, I'd not considered that. I used to use red o-rings on my cherry blues so I've just tried one and it gives a nice soft finish to the keypress, also the key still works fine with the original springs. Right.... this may take some time. (just checked - 1.5mm thick)

20220908_080303.jpg (100.71 KiB) Viewed 18684 times

For wrist wrest I have an old thick double gel thing (although I can't find it online anymore "CaseLogic GL-1") which is the perfect height for the ModelF for me (~35mm), being a really soft gel I find it moulds around my wrist and I tend to have it slid slightly back:

20220908_080206 (1).jpg (370.49 KiB) Viewed 18684 times

20220908_081844.jpg (259.02 KiB) Viewed 18684 times

(having trouble getting a picture of the height! but about this:)

20220908_082529.jpg (165.36 KiB) Viewed 18684 times

[ivor_h]

Is there anybody here with an F62/F77 + Solenoid who would be willing to flash the most recent build of Vial that I've made and give it a try, specifically with an eye toward evaluating how well the solenoid works with this firmware vs. the stock ones, and then report back here?

I wasn't able to reply earlier! I was having problems signing up to the forum. I was using your vial build to be able to use the vial configurator which I prefer, but I wasn't happy with the solenoid and spent some time fiddling with the settings.
I used your build script to get the right buildable versions of everything, thanks!
In the end I found that if I dropped the SOLENOID_MIN_DWELL (and default) down to 4 then I got to just the right level of "thunk" for me (the patch had increased it to 20).
I also tweaked my version to use the scroll-lock light to show the "layer" status (now I have LEDs ).
Finally I too noticed the difference in the keycodes from 0x5C94 but if I corrected that then there was a static_assert in "via_ensure_keycode.h" with hardcoded values, so I left that as-is.

[Rico]

Hello fellow keyboard enthusiasts.

I am happy to be a new member of Deskthority forum!

I would like to talk about my current project here as it may interest some members of this community.
A few months ago I received my Brand New F77 Model F keyboard.
This board is absolutely stunning in every way, I love it's refined tactility and it reminds me a Model M keyboard that I learned programming on, but better

Soon after buying the board I was more or less brainstorming on the development of a PCB controller for it, just to know if I can do it and for the pleasure to mess with electronics.
But this was when Ellipse posted a message on GeekHack asking for a new PCB with possibly an RP2040 on it that I got really pumped to try harder on having something working: the Leyden Jar PCB project was born.
The name taken from the first ever (crude) capacitor ever invented: https://en.wikipedia.org/wiki/Leyden_jar

For more details on this project I posted my work in progress on Keebtalk and GeekHack:
https://www.keebtalk.com/t/the-leyden-j ... ards/17489
https://geekhack.org/index.php?topic=11 ... 139419#top

I will try to post future updates in this forum too

A of now preliminary testings have been conducted with success and I feel that I can now develop a QMK/VIA/VIAL firmware for it.
I could start this work without any previous information of what has been done so far, but feel that asking in this forum for a few things would help me accelerate the development process.

What would be great for me to have:

• Source code of the current QMK firmware, for informative purposes mostly

• Information on matrix/switches topology with always on and off switches(could still find that reading qmk source code)

• Have access to Pandrew utility software: I feel that I could connect the firmware with this tool and why always reinvent the wheel ?

See you!

[ivor_h]

A of now preliminary testings have been conducted with success and I feel that I can now develop a QMK/VIA/VIAL firmware for it.
I could start this work without any previous information of what has been done so far, but feel that asking in this forum for a few things would help me accelerate the development process.

What would be great for me to have:

FYI to get the build for a vial firmware the steps from NathanA listed in: viewtopic.php?p=495074#p495074 will provide the right/compatible/patched versions (best option download the script then follow the steps manually tweaking as needed)