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

[Ellipse]

Check out the manual on the project web site for all technical matters. There is a section on firmware which provides the simplest way to flash your firmware (it includes a step by step video guide as well).

[Ellipse]

Question for all the coders:

Is anyone up for helping move the Model F QMK/Via/Vial project to the new Raspberry Pi RP2040 chip over the coming weeks? Recently the ATMEGA chips have become nearly impossible to find in quantity due to the chip shortage, which means it's probably time to switch over to the RP2040 for the capacitive keyboard controllers. After it is up and running I would like to secure the RP2040 chips soon before they may run out too, so that the final round and beam spring second round will not be delayed.

It seems like QMK support is in progress but not yet completed for the RP2040, and there are other projects like KMK which seem to work with the RP2040. The question is, is it better to go with KMK? How stable is it? It may take a while for QMK RP2040 support to be ready. Some recent related links:
https://golem.hu/guide/kmk-firmware/
https://www.reddit.com/r/MechanicalKeyb ... igning_if/
https://github.com/qmk/qmk_firmware/pull/14877
https://github.com/KarlK90/qmk_firmware ... 40-support
https://github.com/KarlK90/qmk_firmware ... rollers.md
https://github.com/qmk/qmk_firmware/issues/11649
https://github.com/pimoroni/pmk-circuitpython
https://www.reddit.com/r/olkb/comments/ ... _the_pico/
https://github.com/vladantrhlik/VT-40
https://www.reddit.com/r/MechanicalKeyb ... _firmware/
https://github.com/KMKfw/kmk_firmware

What would it take to get the Model F firmware working on the RP2040 chip? Would the xwhatsit wcass controller require an updated design for the RP2040 to work?

[zrrion]

It sounds like you would want to actually hire an employee instead of asking the community to do work for free that you will make money off of.

[Muirium]

Open source means you don’t get paid though, right?

[zrrion]

nah, just means you don't keep it closed

[NathanA]

I'm not a low-level embedded systems guy, but just from what I'm seeing of the QMK implementation, you're likely looking at what amounts to a full rewrite either way (porting the QMK capsense matrix code that pandrew wrote over to RP2040, or implementing a similar design on KMK). And I'd also have to believe that swapping out the AVR for the ARM is also basically going to involve a near-complete board redesign. So all in all, ...non-trivial.

Is it just the 32U2 that is in short supply, or all AVRs with built-in USB support? It would likely be simpler to keep the AVR microcontroller but just switch to a different part that is at least as capable as the 32U2. Likely would still require tweaks to the PCB design since I'm not sure that other AVR parts have exact same pinout and/or package design and can be drop-in replacement for the current one, but still easier I'd wager.

[NathanA]

Only AVRs I'm finding that would be "drop-in replacements" for 32U2 would be the ATmega16U2 or AT90USB162. But with half the memory of the existing chip, neither option would be desirable nor likely even sufficient.

32U4 would likely be the easiest and next-cheapest option even though it would require some PCB rework. This is also assuming that there are no features that the 32U2 has but the 32U4 doesn't & that are also being depended on by the current design.

One other option occurs to me: is it all 32U2 parts that have dried up, or is it just the QFP-packaged variant (32U2-AU) that the current board design has been using up to this point which is scarce? If QFN-packaged version (32U2-MU) is still available for purchase in the quantities that you need, perhaps it would be relatively simple to update the PCB design to use that instead?

EDIT: Is JLCPCB doing the assembly for you? It looks like they are clean-out of all 32U2s. They do seem to have plenty of 32U4s, though admittedly the pricing delta is much wider than I expected...

[bmk]

I haven't been following this part of the project that much, but why not use an ESP32 or something instead? Just go full 32-bit for the connectivity and GPIO, and they're only like $1 each. Easy to code too.

[NathanA]

I haven't been following this part of the project that much, but why not use an ESP32 or something instead? Just go full 32-bit for the connectivity and GPIO, and they're only like $1 each. Easy to code too.

Are you volunteering?

The electronics and software side of this project has all been built on preexisting work that was fleshed out long before this project even existed, and whose original goal was to adapt the IBM-built keyboards to a USB interface. The core of the controller that is in this keyboard was designed back in 2014 (link). That design was done around the ATmega32U2 microcontroller. The same person who designed the controller also wrote his own firmware for it. The original plan was just to use this same controller board design straight-up, but as Ellipse was still in the middle of working on getting factories to faithfully reproduce the keyboard hardware itself, a volunteer here on DT (wcass) re-did the board layout to make it smaller and switch out the mini-USB connector for a USB-C one. But at the end of the day, the schematic & design of this updated board is still essentially the same as the original.

After the first round of keyboards began shipping out, a different fellow here (pandrew) implemented a new firmware for the exact same hardware controller based on top of QMK, and after that was released, Ellipse started preloading that firmware instead of the original on newer units.

Straight-up designing a new controller from scratch was never part of the scope of this project; leveraging existing and already-known-to-be-working solutions was the name of the game. Designing a new controller at this point strikes me as not a small task, though perhaps for the right person(s) it's simpler than I am imagining? Outside of the factories that he's hired and the volunteers here and there who have stepped in to help when needed, the New Model F project itself is largely a one-man-band operation. And as far as I have been able to tell, Ellipse has neither a software nor EE background, so he would have to depend on somebody else (or multiple somebody elses) to do this.

Though there are plenty of existing keyboard controller designs one could crib from if this were just any old bog-standard mech keyboard full of contact-based switches, my impression is that the capacitive-sense switch design is a bit more complicated to implement and get the fine details right on, and is not one where there are just tons of reference designs sitting around to take inspiration from. So it's all well and good to say such-and-such microcontroller is easy to program, but the devil is in the details. pandrew's QMK implementation has some small routines in it that are written in AVR assembly which would need to be wrecked out even if one were to try to model a brand-new implementation after his...it's not like somebody could just target a new platform and hit Compile.

[jsheradin]

Curious if an off the shelf capacitve matrix driver chip could be made to work with the KB matrix. They're meant for touch buttons in cars and whatnot but the underlying tech is the same and the scan rates are about 2x what an HHKB runs at.

The row/col count is a bit limited on them though. You'd need to effectively have multiple separate matrices each being run off their own driver chip. All the driver chips would then talk to the host controller via semi-standard SPI, the host chip would handle USB, mapping, etc.

[sedevidi]

Curious if an off the shelf capacitve matrix driver chip could be made to work with the KB matrix. They're meant for touch buttons in cars and whatnot but the underlying tech is the same and the scan rates are about 2x what an HHKB runs at.

« Manufacturer Standard Lead Time: 52 Weeks »
Ooops...
In theory, this kind of chip would be very convenient and would potentially make things easy. In the context of QMK and basic-standard-reuse chips it's meant to work on, as NathanA said, I guess that would not make things simpler quickly.

[Zcool31]

I have a silly question. Why is the chip in the keyboard as powerful as an entire minicomputer from the 70s? How were keyboards made in ancient times without do much computing power?

[Muirium]

The modern controllers only use fancier chips because they are what’s available these days, especially for USB output.

Arguably, software stacks like TMK, QMK and whatever other letter MK that’s based on Python or something similarly absurd, do hog more resources because they are doing so much more behind the scenes. Programmability means flexibility means a CPU and RAM, no matter how small.

Back in the day, manufacturers (not hobbyists like us) would burn fixed functionality into very simple hardware indeed. That’s the way to be efficient. But we are neither them nor their intended end user market.

[Sheepless]

A modern microcontroller costs very little to manufacture, and not much more to buy (you can get an RP2040 for pennies). There'd be very little to gain by making an MCU with 1970s-era processing power, even if it could keep up with the modern demands placed on it.

[Zcool31]

USB is silly complicated. Why not generate XT or AT scan codes using discrete components and leave all the translation/fancification to a separate middlebox?

[Muirium]

Also why do that?

[Ellipse]

Here is a helpful post over on the GH project thread that I wanted to share here:

Question for all the coders:

Is anyone up for helping move the Model F QMK/Via/Vial project to the new Raspberry Pi RP2040 chip over the coming weeks? Recently the ATMEGA chips have become nearly impossible to find in quantity due to the chip shortage, which means it's probably time to switch over to the RP2040 for the capacitive keyboard controllers. After it is up and running I would like to secure the RP2040 chips soon before they may run out too, so that the final round and beam spring second round will not be delayed.

It seems like QMK support is in progress but not yet completed for the RP2040, and there are other projects like KMK which seem to work with the RP2040. The question is, is it better to go with KMK? How stable is it? It may take a while for QMK RP2040 support to be ready. Some recent related links:
https://golem.hu/guide/kmk-firmware/
https://www.reddit.com/r/MechanicalKeyb ... igning_if/
https://github.com/qmk/qmk_firmware/pull/14877
https://github.com/KarlK90/qmk_firmware ... 40-support
https://github.com/KarlK90/qmk_firmware ... rollers.md
https://github.com/qmk/qmk_firmware/issues/11649
https://github.com/pimoroni/pmk-circuitpython
https://www.reddit.com/r/olkb/comments/ ... _the_pico/
https://github.com/vladantrhlik/VT-40
https://www.reddit.com/r/MechanicalKeyb ... _firmware/
https://github.com/KMKfw/kmk_firmware

What would it take to get the Model F firmware working on the RP2040 chip? Would the xwhatsit wcass controller require an updated design for the RP2040 to work?

Hello Ellipse,

Please let me try to answer your questions the best I can as a non-expert/hobbyist guy.

About KMK.
Never wrote a KMK firmware but had a quick look at the repository source code and a few keyboard firmwares.
It looks to be very easy to write a custom firmware with KMK and the code is very compact and readable.
KMK needs quite a lot of memory but the RP2040 has plenty of it so it is not a big deal.

KMK caveats:
1) Firmware is written in Python, so any modification to the key layout means modifying python code.
Not a big deal for a seasoned developper as KMK developpers made their best to be an easy process, but can be a blocker for non-programmers.
2) No VIA/VIAL support currently.
And again non-programmers may be reluctant to dive in python source code for any key layout modifications.

KarlK90 version of QMK:
He looks to have done a pretty good job to add most of the needed features.
A thing that could be a miss is the lack of EEPROM emulation (using flash storage), but easily compensated by using an external EEPROM chip.
Now I did not tested that is was indeed working.


About the amount of work to port to RP2040 MCU:
An xwhasit like PCB need to be designed, tested and a firmware written for it.
As for the hardware differences the most obvious is the operating voltage (3.3V for the RP2040, 5V for an ATMEGA).
Tom Wong-Cornall (the designer of xwhasit PCB and firmware) was unsure in this blog if his technique would work sufficiently well with 3.3V output instead of 5V.
If the answer is yes his design could be simplified a bit by getting rid of the two 74AHC595 shift register controllers and drive the thing directly with the RP2040 IO pins.
Otherwise those shift registers will need to stay and the PCB design will have to be modified to use mixed (3.3V and 5V) voltages as RP2040 IO pins are not 5V tolerant.
That looks a significant amount of work but at the same same time looks very exiting to do
IMO RP2040 most compelling features is not its current availability, but its PIO feature that could be used for efficiently reading the outputs of the comparators.
And of course there is its incredible price and the fact that it is a dual core beast

The alternative:

Gondolindrim has done quite a lot of research on capacitive sensing for keyboards and came recently with a very interesting design that he discussed about on Twitch.
He focused on Topre-like capasitive sensing and the solution looks quite advanced.
See this GH thread here:
https://geekhack.org/index.php?topic=105035.150

He also did a lot of work to mitigate MCUs frequent shortages and came with a multi-MCU (STM32 based) compatible template called Joker.
I see more and more PCB designers using Gondo's Joker template recently and it has been proven to work well for it's TKL PCB designs, some used by Geon.
More info here:
http://acheronproject.com/joker_mcus/joker/

Hope I've been of any help.

PS:
You've made be want to dive into this problem :p

Thanks Rico, very helpful!

I guess one question would be, could the new RP2040-based controller hardware design be futureproofed to allow QMK to run on it in the future since adding support for the RP2040 is currently in progress. Or would we have to wait for QMK's update to be finished before doing mass production?

A quick look shows a similar scarcity with the STM chips, including the one mentioned in the Joker template link.

[gipetto]

USB is silly complicated. Why not generate XT or AT scan codes using discrete components and leave all the translation/fancification to a separate middlebox?

No joke, i have a love for through hole keyboards and i would absolutely love to do this, but it's way beyond my skill level. i think for a diode rom memory you would need over 3k diodes so it would be huge, unless you used rope core memory like the autodialer at this link. incidentally, i found this comment in the page about such a keyboard. wonder if anyone can guess which it is.

>https://hackaday.com/2021/12/30/threade ... nt-6410903

>IanS says:
>December 31, 2021 at 12:27 am

>That video reminded me of a surplus keyboard that worked on a similar principle. Each key operated a microswitch >that connected to a wire threaded through a selection of cores to generate the character. Unfortunately I broke it >down for the components before thinking to work out which character set it used. The chassis was heavy diecast.
>Report comment

[ngnx]

So I just finally got my new F77 and it's mostly great, but I just can't get it to fully work, I am sorry if this is the wrong place to ask but I got frustrated and I hope someone can give me advice.

A few of the keys do not buckle. They consequently do not work. I know this is a normal problem with model Fs, I have had an F AT since forever and use it as my daily driver, but whenever I have this issue putting the key on again more carefully a few times solves it.

Still the TAB, left arrow, question mark keys (I can't type the question mark because of this haha) do not buckle.
There's a few ringing ones, enter being one of them unfortunately, but I don't care that much as long as they work and are tactile.
I watched the quality control video on the manual, tried pulling the keys, holding the keyboard vertical space bar up, etc. It just doesn't seem to change anything. It's only these few keys. Is there any other video anyone can recommend me.

[jandres]

Hello,

I am still trying to get my solenoid to work. I have watched the Model F project's video multiple times.

The issue I am have, when I try to use Atmel Flip, after I select ATMega32U2 chip, and then select USB, I immediately get these two (2) errors:

"AtLibUsbDfu.dll not found"

and

"Could not load dynamic library."

I have watched the video repeatedly, following every step to a T, including the pandrew utility (erasing eprom and entering bootloader). Please, any help would be greatly appreciated. I just want my solenoid to work, as it should have out of the box.

Thanks!

[Muirium]

Software error. Try another computer? And maybe a non windows platform.

[AnnoyedWalrus]

There's a few ringing ones, enter being one of them unfortunately, but I don't care that much as long as they work and are tactile.

You could try to floss-mod the keys you don't want ringing.

[Ellipse]

ngnx it is a matter of removing and flipping around the spring as one of the last steps to try, as noted in the manual. The spring must be in the correct 12 o clock orientation as noted in the manual. The ringing keys can also be fixed with the methods shown in the QC secrets video. Removing the keys alone will sometimes not solve this issue. Also having the right tweezers or other tool to push down the spring enough without damaging it is very important.

jandres those errors are clearly noted in the written manual's screenshots how to fix, for those flashing ATMEGA firmware for the first time on a particular computer - check out the firmware section of the manual.

[jandres]

I managed to flash my keyboard and reinstalled the hex for my keyboard. When I press RtCntrl - Space - T, I can here the solenoid engage (or least click). If I press it again, I can hear it disengage (or at least it clicks, with a slightly different sound).

The issue I have now is that no matter what I do, other than the click it makes when I press RtCntrl - Space - T, the solenoid still doesn't work (no clicks, no sound from the solenoid).

I have toggled the press RtCntrl - Space - +, but that has no effect.

Again, any help will be greatly appreciated! Is there anyway someone can send me a hex file that would resolve all these issues? I have the new F77 ANSI with standard non-split space bar. I have loaded the QMK hex lay from the link in on Model F Keyboard project, as well as the one Nathan posted a link to a few posts back, same result.

Thank you.

Thank you.

[Ellipse]

Please use the latest firmware file from my recent post - that fixes the solenoid issue in my testing.

[Mr Luud]

Ellipse is confirmed god of all keyboards.

[Muirium]

Like all gods, he keeps you waiting till Doomsday?

[jandres]

Please use the latest firmware file from my recent post - that fixes the solenoid issue in my testing.

I did. I said as much in my post: "I have loaded the QMK hex lay from the link in on Model F Keyboard project, as well as the one Nathan posted a link to a few posts back, same result." I suppose I should have said the firmware you linked to from NathanA. I have installed it multiple times to be sure I hadn't made any mistakes. It is what I am running now.

I can hear. the solenoid engage (or least click) when I toggle the solenoid on/off and when I start my computer, but it does not work beyond that.

[NathanA]

Please use the latest firmware file from my recent post - that fixes the solenoid issue in my testing.

I did. I said as much in my post: "I have loaded the QMK hex lay from the link in on Model F Keyboard project, as well as the one Nathan posted a link to a few posts back, same result." I suppose I should have said the firmware you linked to from NathanA.

Hmm. I went back through my recent posts just to make sure I wasn't forgetting something, but I cannot find a post where I linked to a firmware download, at least within the context of my exchange with you. So not quite sure what you are referring to there.

What I did do was point Ellipse towards a possible reason why his firmware builds from last November had no working solenoid support, which (according to him) turns out to have been a good guess on my part. So he fixed the problem and released a new set of firmware hex files, and then he posted a link to download the latest version that (at least when he tested it on his own keyboards) corrects the solenoid issue introduced in November.

Do note that when he posted the updated version, he actually replaced the existing copy (the one without working solenoid support) on his web server with this new one. So the URL to download his firmware didn't change...the file itself got replaced with an updated one, and the old version is no longer available to download anywhere. If you downloaded a copy of his firmware files before he updated his post saying that the fixed version was now available, you don't actually have the fixed version. In which case you should delete the ZIP file you downloaded, and try downloading again.

I can hear. the solenoid engage (or least click) when I toggle the solenoid on/off and when I start my computer, but it does not work beyond that.

I want to help with these kinds of issues, but I am bit hamstrung specifically when it comes to the solenoid itself, since I don't have one. So I can't personally test or verify anything on my end & am forced to make educated guesses.

One possibility that occurs to me is that you did get the updated/fixed copy of the firmware and did properly flash it, but that I made an incorrect assumption and managed to lead you astray. That assumption is that immediately after flashing, the solenoid is off by default and you have to hit the solenoid toggle key combo to enable it. If I was wrong and it is actually ON by default, then by hitting that key combo, you're actually turning it off. If you are always hitting the key combo twice before testing, and never actually testing to see what happens when you try to type on the keyboard while the solenoid is in the (assumed) "off" position, it could just be that every time you've tested, you have been testing while it is actually off.

If you have tried toggling once, then typing, then toggling only once again, and typing again, and it never engages, then perhaps we are running into the ol' EEPROM-needs-cleared problem. Did you try running the pandrew utility and clicking "Erase EEPROM"? (After doing so and getting the success message, then unplug/replug keyboard before testing again. If you get an error or timeout message the first time you click the button, try clicking it a second time immediately after.)

If still no luck, then the only other thing I know to suggest is to try again with a known-for-sure-to-work-with-the-solenoid firmware. Ellipse said he tested his fixed version and I have no reason to doubt him, but I haven't seen any independent verification from anybody else yet...and as I said before, I can't test myself since I don't have a solenoid.

Though I did not post a link to a firmware in our previous correspondence, I have in the past (before you arrived to the party) posted copies of firmwares I've built to this thread. A simple search through this thread or my past posts should bring them up, but for convenience, the most recent copy of my firmware was posted here. You could try downloading that and flashing the hex file contained within. The disclaimer is that though others in the past have verified that the solenoid does work with my Vial-enhanced firmwares, some have complained that it feels "laggy" compared to the basic QMK firmwares that most people use. I don't know why that would be since I implemented all of Ellipse's recommended tweaks, and like I've said before: I have no way of testing it myself. But even if it's not working optimally, in theory if you run this firmware, the solenoid should do something. So it might at least be worth trying as a sanity test at the minimum. (There's also a chance that this latest copy of the Vial firmware that I posted fixes the laggy solenoid problem, as I made some changes to my build environment that may have a positive effect on the firmware's performance.)

(If you do try my firmware, I would advise that you flash the "erase_eeprom.hex" file included in Ellipse's ZIP archive to your keyboard first. After that's done flashing, count to 5, unplug/replug keyboard after which keyboard should automatically come back up in bootloader mode, then flash my hex.)

The other thing you can do is what I0IParzival himself said worked for him, which was to download an autogenerated hex file from this website. What you have to do is this:

• Download and unzip the firmware file that Ellipse linked to earlier.
• Go to that site I linked to above.
• Click the import/upload keymap button (the one to the right of where it says "KEYMAP.JSON"), and then select the JSON file from Ellipse's archive that corresponds with the hex file you've been using (the one that matches the keyboard layout you have).
• Click the "COMPILE" button (upper-right), and wait for the baked-potato animation to disappear.
• Click the "FIRMWARE" button with the download symbol to the left of it to download the hex file.
• Flash the hex file that you got from this to your keyboard as per normal.

All of this is in fact demonstrated in the video that Ellipse made.

Good luck!

[sedevidi]

I managed to flash my keyboard and reinstalled the hex for my keyboard. When I press RtCntrl - Space - T, I can here the solenoid engage (or least click). If I press it again, I can hear it disengage (or at least it clicks, with a slightly different sound).

Sounds like an incorrect wiring. I don't remember anybody talking about "engaging" and "disengaging" the solenoid. Miswiring may be "power supply" vs. "key trigger".
(I don't have a keyboard yet)