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

[Muirium]

Received my new keyboards several days ago, but just getting some time to use them. Never flashed anything before but read through the documentation and installed VIA to make my life a little easier. Today I decided to open the keyboard up and split both the spacebar and the LShift keys. Much easier to take apart and reassemble than any of the original model F's. Was able to reassign the new Lshift keys and they work as defined. However, I noticed the new key to the right of the shorter spacebar (installed to make room for the new key), does not register at all. I tried changing the assignment but it still did not register. I checked the following:

1- The key has the same feel and sound as all the other working keys, both on the downstroke and the release.

2 - Removed the key and the spring is well attached to the foot and the foot moves freely as it should. When keyboard is tipped up, the spring toggles to the proper position to correctly install the key. Also tried another key in this position with the same results.

3 - I made sure when I installed the new components and reassembled the two plates, that there were no gaps, the plates completely connected within the tab slots on both plates.

4 - All the remaining keys on that bottom row are working fine without issue.

Any suggestions are appreciated, even it is referencing back to the manual pages for something I may have
missed. If I need to take the plates apart again, just want to make sure I check everything I should while they are apart. Thanks for any suggestions and the keyboard itself. Will be ordering a few more spare parts since it is so easy to work with. My F122 requires many clamps and a few mandatory cuss works to put it back together with new foam.

Loving this so far!!

I'd flash Pandrew's QMK back on it for testing purposes and run the levels diagnostic pictured above in this post:

viewtopic.php?p=504179#p504179

Also, maybe take it easy on the single malt while you're doing this. The Mac na bracha is for celebrating a job well done, not mere Dutch courage!

[marcuso]

Interest Check: ISO Black, Dark Gray, and Industrial SSK Blue key sets, Code Keys, Big PC AT style Enter Keys?

If you are interested please fill out the Google form below to note which sets you’d like. To help pay for the mold each set will cost $20 extra, a total of $99 instead of $79 for each set. The key could also be ordered for $20 individually.

https://docs.google.com/forms/d/1vsamkl ... kDG39r08Q/

On the form you've got the price as $49 - I'd go for one at $20 but if I spent $49 for a keyboard key, my wife will rip out my guts and feed them to the dog!

[NathanA]

However, I noticed the new key to the right of the shorter spacebar (installed to make room for the new key), does not register at all. I tried changing the assignment but it still did not register.

*sigh*

This is a software problem. It's a "known" bug...well, at least known to me, but no matter how many times I shout it from the rooftops, it doesn't seem to be known to many others...

The issue is that pandrew's QMK capsense driver will "pass over" setting a threshold for any keys where the default layer 0 key value is set to "KC_NO" (nothing), and just set that pad to threshold of 0. Which in turn causes that key to not be sensed, period. And it just so happens that literally every key layout in the default firmware distribution other than the JIS and scumyc ones have that extra key to the right of Spacebar set to KC_NO.

The net effect of this is that you will not be able to get that pad to register anything with most of the QMK or VIA hex files from the Ellipse ZIP archive. Your available options as far as I can tell are to either set up your own QMK build environment, edit the JSON file that's closest to the layout that you want to fix this problem, and then build your own copy of VIA firmware...or use my Vial hex files posted to this thread on May 4, which already contain the fix.

I'd flash Pandrew's QMK back on it for testing purposes and run the levels diagnostic pictured above in this post:

If he runs that signal level monitor, it will likely show capacitance value rise whenever he presses the key in question. But if he runs keypress monitor, it will show a 0 as the threshold value for that pad, and pressing the key will still not show anything as being registered.

[Muirium]

Well that's a stoater of a bug if so!

You really can't just assign something useful to the key in layer 0 using Pandrew's web interface?

[NathanA]

Also posting here as well as on the beam spring project thread - what do folks think about the new beam spring LED overlays? They will be Model M spec so that they can be used on the original Model M keyboards too (maybe if you use the new Model F project keys on a Model M or are custom adding overlays to the F77/F62?). A big thanks to Zed for creating these overlays.

I assume no designs compatible with Gen 4 Model Ms / Unicomp 'boards are being considered for production? (Could understand if not. I'm not even sure how you would design it to look good on said boards. Both IBM/Lexmark and Unicomp seem to have failed at this.)

[NathanA]

You really can't just assign something useful to the key in layer 0 using Pandrew's web interface?

None of the preconfigured layouts on the web interface un-hide that pad. Except for if you pick LAYOUT_all. So that might be a possible workaround. LAYOUT_all will force you to pick key bindings for all pads, even ones you aren't planning to use. Though given this particular bug/oversight/intended-behavior/etc. that might not be a bad thing.

Only thing is, pandrew's web interface won't generate a VIA firmware for you, only QMK. And Lagavulin (respect...) sounded like they wanted a VIA or at least VIA-like experience...otherwise I assume they wouldn't have flashed a VIA hex to their keyboard.

[Muirium]

Aye, Lagavulin (hints of peat and hardy islander…) said they want VIA so they're best off flashing your fixed version.

I'm a neat QMK man myself. No rocks, no water.

[NathanA]

I'm a neat QMK man myself. No rocks, no water.

Well played, sir.

As a refresher, here is where I first discussed this issue. In it, I mention that though the Ellipse VIA builds (excepting JIS and scumyc) all have this issue with that particular pad, darkcruix's VIA builds do not. Only trouble is that, darkcruix has not posted updated VIA builds of his own since the newer revision of the wcass controllers were manufactured for the most recent batch of keyboards. Thus, if anybody who received a keyboard within the last few months tries to use the hex files that darkcruix compiled, their 'board won't be able to sense ANY keystrokes...

[BuGless]

Here's my take on an F77/F62 keymap featuring (using 6 layers):
- A numpad like ATM/phone layout (by default off, it's on a separate layer, activated by Fn-Keypad -).
- Hexkeys support (shifted into through Delete).
- All layers are independent of the state of the Numlock key.
- A fallback (hidden) caps-lock key to reset an accidental caps-lock state (Fn-right shift).
- Mouse-keys support.
- Cursor and mouse-keys support even without the numpad on the right (so for F62).
- Media keys.
- Numpad with the center numpad 5 key for tactile orientation.
- The Caps Lock at the bottom left should actually be labeled "OS/Linux/Command/Windows key".

BuGless_F77.jpeg (280.92 KiB) Viewed 50895 times

[darkcruix]

I have been absent for a while, but tried to catch up with all the great things.
I have read somewhere back about Num-Lock and wanted to share how I configured it.

If there is interest of the QMK keymap.c code, I am happy to post it (including the LED part). My Num-Lock is keyboard based and also works with Macs.

[Lagavulin]

Aye, Lagavulin (hints of peat and hardy islander…) said they want VIA so they're best off flashing your fixed version.

I'm a neat QMK man myself. No rocks, no water.

Information, humor and Single Malt....the perfect responses. Thank you for taking the time to respond. Neat is complete!

[skitsykitsy]

Just managed to reattach the spring for my "4" key -- I managed to nail it by using some floss to keep it from falling into the inner assembly housing and actually managed to reattach it by lying the keyboard down flat, attach the spring, then held the 'board vertical to put the keycap in place.
My Model F repro is now in perfect working order. <3

[Lagavulin]

You really can't just assign something useful to the key in layer 0 using Pandrew's web interface?

None of the preconfigured layouts on the web interface un-hide that pad. Except for if you pick LAYOUT_all. So that might be a possible workaround. LAYOUT_all will force you to pick key bindings for all pads, even ones you aren't planning to use. Though given this particular bug/oversight/intended-behavior/etc. that might not be a bad thing.

Only thing is, pandrew's web interface won't generate a VIA firmware for you, only QMK. And Lagavulin (respect...) sounded like they wanted a VIA or at least VIA-like experience...otherwise I assume they wouldn't have flashed a VIA hex to their keyboard.

Nathan, Thanks for your responses and patience for apparently having to rehash the topic. Armed with lack of experience, understanding of the two pads of rebirth (jumpering the pads), curiosity, and single malt, I will read through your suggestions, attempt them and report back if the result is either a success or an interesting story. Seriously, thanks for the quick responses from yourself and Muirium

[Muirium]

Raise a glass to DT. Slàinte mhath!

[Ellipse]

Pad printing update: I received the air shipment from the factory and here are the latest pad print samples. I requested the printing to be thicker like on the original IBM M13. Of course the samples do not have the correct alignment of the finished products. Please disregard the cell phone quality of the photos.

As a reminder please sign the White text on Black Keys Pad Printing Interest form to reserve your spot in line for these sets: https://docs.google.com/forms/d/1873Q9w ... 4XtN1DfNk/

So far there are 65 requested sets which is enough quantity to proceed with production after good samples are produced.

20220531_135121.jpg (668.61 KiB) Viewed 50779 times

20220531_135142.jpg (1.13 MiB) Viewed 50779 times

20220531_135144.jpg (1.16 MiB) Viewed 50779 times

NathanA I don't think I'll be making the smaller LED overlays for Unicomp boards as the tooling would be different/extra.

[NathanA]

My Num-Lock is keyboard based and also works with Macs.

Looked at your keymap.c, and this is exactly identical to how I did it, just using Vial instead of in code (QMK keymap.c): "Num Lock" doesn't trigger system Num Lock but just selects a layer where the keys on that block are set to number keys, and number key codes transmitted with Num Lock on are the top-row number keys & not the number pad number keys. And also of course on top of that you have wired up LEDs to your controller and have the Num Lock LED reflecting a layer selection rather than actual system Num Lock, which is very cool.

What some people here seem to want, however, is for Num Lock key to be actual system Num Lock toggle, but to have system Num Lock status determine which layer is selected in QMK. That way, numbers or nav commands can be triggered system-wide (or at least also triggered from the system) & the status of keyboard Num Lock can also be known by the system, but a different arrangement of nav commands can still be configured on the number pad keys other than what the default Enhanced 101/102/104/105 key layout has already predetermined. (EDIT: should be pointed out that of course this wouldn't work on Mac, which lacks the whole concept of a system-wide Num Lock.)

[NathanA]

The pad-printed keys look awesome...

NathanA I don't think I'll be making the smaller LED overlays for Unicomp boards as the tooling would be different/extra.

Again, totally makes sense. But just so that we are absolutely crystal-clear: the Unicomp (& also IBM and Lexmark Gen 4 boards like 42H1292) LED overlays are not "smaller". The stickered area is 100% identical in size, as are the LED hole cutouts themselves (or at least they are roughly enough the same that it wouldn't matter if a sticker contained windows ever-so-slightly bigger). The difference is that the LED holes are in a different position within the designated area. I believe they are all offset by a constant amount (X & Y coordinates-wise) relative to the original Model M LED locations. (EDIT: taking a closer look, they might actually be slightly closer together than they are in the original arrangement.)

It's just that the IBM & Lexmark made ones are super uuu-u-uuuuuu-gly! It's literally just Num Lock / Caps Lock / Scroll Lock black text free-floating in a sea of pearl, uncentered!, with no visual separators or borders between them like on the "classic" design from before. I suspect IBM just didn't know (nor likely care much by that point...) what to do with it (which begs the question why they changed it to begin with, since I bet they could have retained the LEDs in the original position on the newer-style "over-numpad" controller board if they'd really tried).

Good pictures of it are hard to find, but here's one.

I actually think that the (unbranded version of) the Unicomp pearl sticker is a step up from this, because even if you don't like the pictograms they chose, it at least doesn't look anywhere near as lazy as IBM's "slap some left-justified text below the LED windows" effort.

That said, if somebody were to come up with a better-looking design and have it produced, I suspect a lot of people would rise up and call them blessed. I guess pandrew at one point tried to take a stab at it, but IMO not sure I'd call any of the ideas here super successful, which just goes to show the kind of hole IBM dug for themselves when they made this change...it's not a problem whose solution is just blindingly-obvious, design-wise.

BTW if anyone is actually looking for design A1 (in pebble) from your chart of options, Unicomp still makes that one & it can be ordered from the page on their site that I linked to earlier. It is of course the grayscale options (or the all-caps options) that don't exist at this time.

[flowchartsman]

When I installed the solenoid and driver for my F77, I took the liberty of swapping the usbc->usbA cable out for a right-angle cable usbc->usbc I found online so that it would take the stress off the controller board and so I could plug it directly into my macbook. When plugged into my dock, the keyboard works great, but when I plug it directly into my macbook it doesn't work at all. Anyone have any idea why this is? I swapped it back out again for the standard cable and it works fine, but I'm just a bit worried at the stress the default cable puts on the board.

[Ellipse]

PCB issue:

I received the sample controllers from the most recent batch and it appears that the 6th and 10th pins from the left hand side result in the xwhatsit utility's entire matrix turning from grey to white, instead of just the selected row turning white. Interestingly these are both the rightmost connections to RP3 and RP4. The other rows work normally. This is for the standard controller last year without alterations and following xwhatsit's Model F testing guide (reattached here). It happens on all of the controllers I've tested from this batch but not on the older controllers.

The updated 33 pin controller has the same behavior, but at the same threshold 80, the 3rd pin from the left changes rows 2,3,4,7,8. Same with the 4th pin. Other pins cause flickering of the remaining rows and other rows turning white correctly. Pin 5 correctly changes row 1 in the xwhatsit capsense utility. Pin 8 correctly changes row 5. Not sure if updated xwhatsit original style firmware is needed for this controller.

Any ideas?

[flowchartsman]

That said, if somebody were to come up with a better-looking design and have it produced, I suspect a lot of people would rise up and call them blessed.

What, like this?



I was able to find a schematic reference for the cutouts on the original Model M, but these unicomp ones are derived from tracing, so I could use some better measurements if anyone has them.

[Lagavulin]

I'm a neat QMK man myself. No rocks, no water.

Well played, sir.

As a refresher, here is where I first discussed this issue. In it, I mention that though the Ellipse VIA builds (excepting JIS and scumyc) all have this issue with that particular pad, darkcruix's VIA builds do not. Only trouble is that, darkcruix has not posted updated VIA builds of his own since the newer revision of the wcass controllers were manufactured for the most recent batch of keyboards. Thus, if anybody who received a keyboard within the last few months tries to use the hex files that darkcruix compiled, their 'board won't be able to sense ANY keystrokes...

Thanks I went with your updated vial firmware mentioned in your referenced discussion. Works like a champ.

Thanks for the assistance. I need to read more to understand the differences between VIA and VIAL but the key works!

[darkcruix]

I'm a neat QMK man myself. No rocks, no water.

Well played, sir.

As a refresher, here is where I first discussed this issue. In it, I mention that though the Ellipse VIA builds (excepting JIS and scumyc) all have this issue with that particular pad, darkcruix's VIA builds do not. Only trouble is that, darkcruix has not posted updated VIA builds of his own since the newer revision of the wcass controllers were manufactured for the most recent batch of keyboards. Thus, if anybody who received a keyboard within the last few months tries to use the hex files that darkcruix compiled, their 'board won't be able to sense ANY keystrokes...

Thanks I went with your updated vial firmware mentioned in your referenced discussion. Works like a champ.

Thanks for the assistance. I need to read more to understand the differences between VIA and VIAL but the key works!

Just to close the loop: I have also removed the older firmware files from the web page, so there are is no confusion anymore.

[ghostbuster]

Hi,

Trying to compile a custom layout for F77 since I purchased the Mac keycaps so I need GUI next to space instead of alt. I'm doing this from Linux and I've already managed to use dfu-programmer to flash the provided .hex file and that was successful.

I've used the qmk package from the arch pacman repo to clone a copy of the QMK source but as far as I can tell there, nothing has been upstreamed from this project. I'm guessing I need to use someone's fork of QMK.

I tried the configurator site at http://35.164.28.200:5000 but when I try to load the ANSI-HHKB-split_shift_split_backspace layout, none of the keys are mapped. I hand-edited the json and uploaded it until it looks correct but when I try to use the website to compile, I get an error.

I'd prefer to just compile this locally if possible and I'm generally capable of building and flashing firmware for other atmega devices but the warnings in the "manual" on modelfkeyboards.com about not using any other guides have got me worried.

Can anyone tell me where to get the source for the QMK firmware for an F77 and whether it's okay to build it using standard QMK procedures?

[DMA]

PCB issue:

I received the sample controllers from the most recent batch and it appears that the 6th and 10th pins from the left hand side result in the xwhatsit utility's entire matrix turning from grey to white, instead of just the selected row turning white. Interestingly these are both the rightmost connections to RP3 and RP4. The other rows work normally. This is for the standard controller last year without alterations and following xwhatsit's Model F testing guide (reattached here). It happens on all of the controllers I've tested from this batch but not on the older controllers.

The updated 33 pin controller has the same behavior, but at the same threshold 80, the 3rd pin from the left changes rows 2,3,4,7,8. Same with the 4th pin. Other pins cause flickering of the remaining rows and other rows turning white correctly. Pin 5 correctly changes row 1 in the xwhatsit capsense utility. Pin 8 correctly changes row 5. Not sure if updated xwhatsit original style firmware is needed for this controller.

Any ideas?

seriously looks like your RP3 and RP4 are 10-pin while PCB is made for 8-pin ones.

[flowchartsman]

seriously looks like your RP3 and RP4 are 10-pin while PCB is made for 8-pin ones.

Yep, sure does, doesn't it? It actually looks like at least one of them is okay, while the others are definitely not. Pin spacing means some of the contacts are almost certainly bridged.

For instance. This one looks like it might be okay:


This one definitely not.


My money's on a stock mixup and the wrong roll got put on the pick-and-place, or they thought they could get away with using the 5 array and they might have been able to if they'd have gotten the spacing right. But they didn't

[Ellipse]

Thanks DMA and flowchartsman! I have let the PCB factory know about the error. The photos showed 2 controllers from the new sample batch and one older working controller (the one with the ribbon cable and that has the 8 pin RP3 and RP4 parts).

For the LED overlay suggestions, I like the new ones but please let's stay to the original IBM LED hole locations for the designs. I'm open to moving the overlay but there would be a tooling charge of $100 to $200. Attached is an LED template as prepared by Zed.

ghostbuster feel free to check out the QMK part of the manual to git clone pandrew's repo (pandrew's github does not have the most recent versions).

darkcruix is there a way to use pandrew's QMK configurator site to set up the tap keys and such for the additional right side block options?

[ghostbuster]

ghostbuster feel free to check out the QMK part of the manual to git clone pandrew's repo (pandrew's github does not have the most recent versions).

I'm assuming pandrew = purdea.ro? Trying to clone that getting less than 1 kbit/sec. Are there any plans to upstream this work to the QMK project?

[BuGless]

pandrew says he's too caught up in other things at the moment to upstream it.
I've looked at it, and it needs some refactoring before it can be upstreamed. It's unclear at this point if I can spend enough time to do it. If anyone else feels the urge, please step up.

[sedevidi]

I'm assuming pandrew = purdea.ro? Trying to clone that getting less than 1 kbit/sec.

As an alternative, I use NathanA's Vial build, and I'm very happy with it. He provided all the details to build it yourself a few pages ago. I didn't even build it myself... The plus of Vial is that the open-source GUI allows to tweak the keys on the fly, which is great when first configuring the keyboard, or try some things and change your mind quickly.

Are there any plans to upstream this work to the QMK project?

As far as I remember, the capsense code have something that doesn't please upstream. It's not trivial enough that the effort is not yet finished, or abandonned, which is sad... I think it's related to the fact that there is a good amount of things to do upon initialisation of the capsense (per-key treshold), which get in the way of other QMK initialisation (hotkeys).

[NathanA]

What, like this?

!!!

Honestly, that's...not bad.

I do think that the caps lock with the LED in the center of the padlock is the most awkward of the 3...looks a bit visually crowded, maybe? As I said, it's a hard problem to solve, and IBM did this to themselves...

Still, this is my favorite effort to-date that I've seen.