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

[dodddummy]

I have a B122 on order and am considering ordering an F122 but would like to know how long is it taking for model F122s to ship. I did some searching but didn't see anything.

[Ordinary Witch]

F122 cases are ready for production but the inner assemblies aren't IIRC, so shipping is a bit further away still

[Ellipse]

The Round 2 Model F and Beam Spring boards should be wrapping up production and assembly over the next few months, a delay from the original expectation of around this current time. All these Round 2 boards should be going out at the same time once they arrive on the container ship, so if someone decides to order an additional board and they have two boards on order then they usually get to skip the additional line and have both boards go out in the same shipment and at the same point in line as their first board.

sensy do you have any more details on your mod? Does the caps lock provide a second layer for both halves? I am not sure.

[sensy]

sensy do you have any more details on your mod? Does the caps lock provide a second layer for both halves? I am not sure.

Yes, both num lock and caps lock (and scroll lock but I’m generally scared of that function for reasons) activate separate layers for both halves. There’s also no reason why you can’t do combinations of lock leds to add layers - or my current idea I haven’t actually done anything with yet - sending codes to have dozens/hundreds of layers by activating and deactivating lock functions in certain timings/combinations. It’ll be an awful hack job by me that no one else will ever use, but it feels like a fun project for hangover me tomorrow.

HAPPY NEW YEAR

[Ellipse]

Very interesting sensy; please keep us posted with your project!

[sensy]

OK, I spent some time making a very primitive and probably silly locklight layer number selector. It... "works" but it's not perfect by any stretch. It's in my "senseored" keymap in this zip.

It functions by setting scroll lock to on, then caps lock move bits and numlock sets the bits on/off. So sending 2 would be:
SL: On
CL: On, CL: Off (first bit off)
CL: On, NL: On, NL: Off, CL: Off (second bit on)
CL: On, CL: Off (third bit off)
SL: Off

Currenly I'm only sending three bits to make it more responsive, but I'm not a good programmer so maybe this could be made better. But it works for what I need. I'm still using the numlock and capslock layers for faster layer-switches for my more common stuff, but it's nice to have the extra options.

[LLRnR]

Given that I have not been made aware of any glaring issues with the prerelease copy posted by Ellipse earlier, I'm ready to announce a Release 4 of my Vial firmwares for the Model F Labs series of F-model keyboards.

Hi! I've been a long time away from this forum, and I'm not sure if this is the right place to post my question.

I just received my new Model F62 with a HHKB split (right shift split + backspace split) and I'm trying to get Vial framework onto it. I have the version specified by @NathanA in the post I quoted (r4) but I can't seem to find the proper hex file for my keyboard. If I just flash the F62 hex file, it assumes I have the standard ANSI version. If I understand correctly, this layout (among other) has not been added yet to the latest version, right? Is there a way I can make it myself?

I'm asking this because I think there's a problem with the QMK firmware that comes by default with my keyboard. Everything works except for the solenoid which is lagging behind my keystrokes, and Joe from Model F Keyboards advised me to load the latest Vial firmware instead of the QMK one.

If I posted in the wrong place, please kindly direct me to where I should have asked the question

[sensy]

Given that I have not been made aware of any glaring issues with the prerelease copy posted by Ellipse earlier, I'm ready to announce a Release 4 of my Vial firmwares for the Model F Labs series of F-model keyboards.

Hi! I've been a long time away from this forum, and I'm not sure if this is the right place to post my question.

I just received my new Model F62 with a HHKB split (right shift split + backspace split) and I'm trying to get Vial framework onto it. I have the version specified by @NathanA in the post I quoted (r4) but I can't seem to find the proper hex file for my keyboard. If I just flash the F62 hex file, it assumes I have the standard ANSI version. If I understand correctly, this layout (among other) has not been added yet to the latest version, right? Is there a way I can make it myself?

I'm asking this because I think there's a problem with the QMK firmware that comes by default with my keyboard. Everything works except for the solenoid which is lagging behind my keystrokes, and Joe from Model F Keyboards advised me to load the latest Vial firmware instead of the QMK one.

If I posted in the wrong place, please kindly direct me to where I should have asked the question

In the Vial program there's a tab for layout, where you can select split backspace and right shift.

[LLRnR]

Ohh I see. Thanks! I'll try again tonight. I've never used Vial before so it wasn't immediately apparent to me that you just needed the firmware for the right keyboard model, which will allow to pick the correct layout variation later, in the software.

[LuX]

Another Vial question: I got the split ortho which uses numlock for layer switching. Does anyone know how to setup a momentary layer switch (numlock on when pressing down, off on release)? Maybe the answer is already in the thread but couldn't find it on a quick skim through the last few pages.

Edit: I figured out that TD(1) by default was configured this way. It has numlock assigned to "on hold" and "on double tap" others are blank.

Edit 2: The button I was looking for is actually called "Locking Num" and can be found on "App, Media..." tab second to last.

[sensy]

I did a quick video/sound test of the split ortho Model F since I couldn't find one:

https://www.youtube.com/watch?v=T-3pG3WXO_I

[RedESC]

Had a thought for a mini DIY project relating to this project and as something to accompany this keyboard once it's finished. I notice that you sell keys, barrels, flippers and springs for your model F boards. Any idea how difficult it'd be to make myself a 4x6 macropad using these parts? I suspect the difficult part would be the curved metal plates. (assuming I was going with either no case or a 3d printed case)

Sorry if this is wrong place to ask this.

[LuX]

Had a thought for a mini DIY project relating to this project and as something to accompany this keyboard once it's finished. I notice that you sell keys, barrels, flippers and springs for your model F boards. Any idea how difficult it'd be to make myself a 4x6 macropad using these parts? I suspect the difficult part would be the curved metal plates. (assuming I was going with either no case or a 3d printed case)

Sorry if this is wrong place to ask this.

Besides the swich assemblies you'll need a controller (which Ellipse also sells), it should be configurable to work with a numpad matrix too, probably even has enough pins for each key separately. The configuration process was discussed somewhere in this thread. AFAIK the steel plate is not needed for operation, but you do need a curved surface for proper actuation (?). That could be incorporated to the 3d printed case. It won't sound or feel quite as nice but should be ok. Or consider a sintered metal case?

The biggest hurdle will be making the flexible pcb. The design of the pcb's doesn't look so difficult but you'll need to be mindful of design parameters like layer/copper thickness and pad size so the capacitance detection works properly (?).

As you can see, I'm just guessing here so don't ask me for details. If your project comes to fruition other users are probably more keen on helping you with the process. Overall seems like a doable project to me depending on your skills and the expected quality you are after. But you should make a separate thread to document the process.

Alternatively if enough people are interested, maybe Ellipse would do a small run of numpads. I reckon there's plenty of people who don't want a full model f keyboard but would be interested in the novelty of a "model f numpad". If the price isn't too bad I might be interested too.

[Ellipse]

There is an F50 macro pad that is available here; I still have a few of these left: https://www.modelfkeyboards.com/product ... n-winners/

[RedESC]

Had a thought for a mini DIY project relating to this project and as something to accompany this keyboard once it's finished. I notice that you sell keys, barrels, flippers and springs for your model F boards. Any idea how difficult it'd be to make myself a 4x6 macropad using these parts? I suspect the difficult part would be the curved metal plates. (assuming I was going with either no case or a 3d printed case)

Sorry if this is wrong place to ask this.

Besides the swich assemblies you'll need a controller (which Ellipse also sells), it should be configurable to work with a numpad matrix too, probably even has enough pins for each key separately. The configuration process was discussed somewhere in this thread. AFAIK the steel plate is not needed for operation, but you do need a curved surface for proper actuation (?). That could be incorporated to the 3d printed case. It won't sound or feel quite as nice but should be ok. Or consider a sintered metal case?

The biggest hurdle will be making the flexible pcb. The design of the pcb's doesn't look so difficult but you'll need to be mindful of design parameters like layer/copper thickness and pad size so the capacitance detection works properly (?).

As you can see, I'm just guessing here so don't ask me for details. If your project comes to fruition other users are probably more keen on helping you with the process. Overall seems like a doable project to me depending on your skills and the expected quality you are after. But you should make a separate thread to document the process.

Alternatively if enough people are interested, maybe Ellipse would do a small run of numpads. I reckon there's plenty of people who don't want a full model f keyboard but would be interested in the novelty of a "model f numpad". If the price isn't too bad I might be interested too.

I have had a PCB manufactured before a couple of times (Was a couple of simple boards with a MCU that wirelessly controlled Somfy shades for my smart home setup) but never a flexable one so that will be a new adventure. Not sure what I'd use as a controller, got a few options there. Reason I was considering a Steel plate rather than plastic or other materials was from seeing what happened with the orthoBS project Chryosran22 showed off on youtube. (Plate wasn't ridgid enough) Did see the f50 from ellipse, it's maybe a bit overkill for what I'm aiming for, my end goal would be something more compact also doing it mostly as a bit of fun to see if I can rather than because I need it. (I got a F122 on order from this project so not worried about actually running out of buttons for macros)

[LuX]

I have had a PCB manufactured before a couple of times (Was a couple of simple boards with a MCU that wirelessly controlled Somfy shades for my smart home setup) but never a flexable one so that will be a new adventure. Not sure what I'd use as a controller, got a few options there. Reason I was considering a Steel plate rather than plastic or other materials was from seeing what happened with the orthoBS project Chryosran22 showed off on youtube. (Plate wasn't ridgid enough) Did see the f50 from ellipse, it's maybe a bit overkill for what I'm aiming for, my end goal would be something more compact also doing it mostly as a bit of fun to see if I can rather than because I need it. (I got a F122 on order from this project so not worried about actually running out of buttons for macros)

I wasn't familiar with that video of the orthoBS, but after watching it I could tell in 2 seconds the case design is shit. Thin acrylic sheets fixed together with tiny scews at six places? No, what I'm talking about is making a solid two part 3D printed rectangle with just the appropriate cavity inside to fit the pcb, controller and switches, and if need be, print all at full infill and have screw mounts at every intersection of keys to give even pressure... I guarantee it will survive being driven over by a car.

[shampoo]

Hello

I am getting some ghosting.. That is, while typing, extra characters or the volume button gets activated etc.. Usually, this is because the solder joints on the PCB are contacting the back of the case.. I have taped it up with that clear brown tape used to prevent electrical shorts.. But no luck. I have changed cables and am now plugged directly into the keyboard and no luck.

Anything else I should be looking at to fix this ?

Thanks

[Ellipse]

You might want to open up the keyboard and physically push up the controller so it does not make contact with the bottom of the case, but it can still have enough clearance to easily plug and unplug the USB connector, and try several layers of the polyimide kapton tape

[shampoo]

I’ll give that a try. Am i correct in saying the only place interference can happen is around the case and controller.

[shampoo]

It looks like it's just a single row on the keyboard.. Example:

I just kept hitting the period key:

.....................n.........................................n....................................

An eventually the 'n' pops up.. An I have notice that when there is a ghost char, it's from the same row. Maybe a coincidence, but maybe not..

I removed all the polymide tape, then added more all over and also added to the back of the case where the controller might touch the case..

I had to replace a flipper a while back.. Wondering if maybe that's the issue.

[Ellipse]

If it is one key it is most likely the spring needing replacement, or possibly debris in the area.

[NathanA]

All,

I present for your enjoyment Release 5 of my Vial firmware builds for Model F Labs keyboard models that employ the wcass variant of the xwhatsit controller.

For various reasons that I won't go into right now, I have not had a lot of available time within the last couple of months to really dedicate much to the firmware project, so the publishing of this release is happening a lot later than I'd hoped. I actually had this 99% ready to go back in November, and was hoping to get it out before the holidays and end-of-year work projects descended on me and sucked away all of my remaining available time, but then it became clear in my communication with Ellipse that some of the choices I'd made were not going to work well for him insofar as providing something easy for the people on the factory floor to use. Before I could really try to address this, my free time dried up.

This release really hasn't actually changed all that much since November as my free time is still at a bit of a premium at the moment, but rather than continue to hold it up, I'm just releasing what I've got at this point.

One of the issues I wanted to tackle with this version was the return of discrete layout & keymap configs being bundled with the release. With the previous one, there was again a rush to get something usable out-the-door for the factory to use as they started to churn out the latest keyboard models, and so I was concentrated mostly on supporting those models, and the separate keymaps got (temporarily) dropped, replaced with a singular "allpads" config for each model that just had every conductive pad / key location revealed on the Vial layout tab.

As I started working through converting the various QMK keymap files over to Vial layout format, and given how the number of keyboard models that are being supported now has absolutely exploded, I also saw a need to try to come up with a different naming scheme...I personally found the original one confusing, and judging from e.g. Chyros' review I wasn't the only one. In addition to desiring one that (ideally) made it clearer to the user which file contained which layout, I also desired something that made it easier on me to generate layout files & scripts while putting releases together. I hastily threw together a scheme that Ellipse wasn't thrilled with, and to be fair to him, on second consideration, it admittedly also had flaws, and as a result & more keyboard layout combos were needed, I had to twist the naming through more and more contortions to accommodate new layout options where the names just made less and less sense as time went on.

I still haven't really had the time necessary to be able to sit down and fully re-think through this issue, so I reserve the right to change it again in the future ( ), but I went ahead and made some tweaks to the keymap+layout naming that -- at least to me -- seem logical, and which I hope will make sense to everyone.

I had these goals in mind:

• It had to have some kind of internal logical consistency
• It had to be relatively flexible, both in order to accommodate the crazy number of current models + layout combos, as well as any future such combos that I can't possibly anticipate
• It had to be less overly-verbose than the original names, but still somehow remain readable while remaining compact and terse
• It had to be "command-line friendly"...while working on these, I'm largely typing them out over and over again, and even with command-line completion, things such as capitals (which slow one down when working on a case-sensitive filesystem) and characters that need to be escaped (a different list on every FS and OS, but e.g. spaces, commas, etc.) are annoying to repeatedly deal with in a CLI setting

Initially, I treated "HHKB" as a separate layout altogether, but treating it instead as a layout modifier has turned out to be a better choice, especially since there are some layouts that only borrow certain elements from the HHKB layout in a piecemeal fashion. (Plus apparently there is some sort of demand for an ISO spin on HHKB, which...I did my best to approximate what I thought that could look like, but since the lower-row 1.5U Backspace is fundamentally incompatible with having an ISO Enter, is not fully possible to do...)

So, here is the rough "legend" I'm using for the naming at this point:

base_modifier1_modifier2_[...]_modifierN

...where...

• base is either 'ansi' or 'iso':
  • ansi uses an ANSI Enter, and non-split left shift
  • iso uses an ISO Enter, and a split left shift
• modifiers are strung together to explain the deviation from the base; each of the below modifier groups are mutually-exclusive:
  • fn / hhshift / hhkb:
    • fn means: split right shift (HHKB-style), with rightmost 1U key being mapped to Fn
    • hhshift means: as above, but also Caps Lock and Left Ctrl are swapped relative to ANSI
    • hhkb means: as above, but "full HHKB" (backspace is moved down a row to replace 1.5U backslash, original backspace is split)
  • optN: for F77, refers to the right-side block layout option, where N is from 1 to 5, as described in Model F Labs documentation
  • nlock / simulock:
    • nlock means: enables the Num Lock based layer 1 selection feature, and in the case of F77 implements the right-side block using this feature
    • simulock means: "simulated" Num Lock; primarily used on F77 for variants of certain right-side block options where the number pad is implemented with a "Num Lock" key that does a layer trigger but *without* actually changing host Num Lock status (see: previous posts on the subject here; this was an earlier solution to implementing options 3 through 5 before the advent of host Num Lock based layer switching, but is preserved because some users may find this version preferable)

So for example, "f77-ansi_fn_opt3_nlock" would be an F77 layout based on ANSI, with HHKB-style split right shift, right block option #3, implemented with the Num Lock based layer switching feature.

There will surely still be some oddball options from time to time that won't perfectly fit into this model, but I hope this will prove flexible enough to accommodate them (there are even a small handful included in this release that this is true of). At this stage, not all possible layout options for every supported keyboard model are yet comprehensively covered. If there is a particular layout that is missing but was an obvious oversight / should have been included, feel free to let me know.

Flashing scripts for both Windows and Mac (+ Linux, if you supply your own dfu-programmer) are found in 'flash-scripts/', grouped by keyboard model.

Change log:

• Changes in r4 (from r4b3):
  • rename & distribute > r4 release candidate
• Changes in r4b4 / r5b1 (from r4b3):
  • Num Lock based layer select feature (intended for split boards and F77 right-side block)
  • Added Bourne shell flashing scripts for our *NIX-using friends, and included MacOS-compatible dfu-programmer binary (if you want to use with e.g. Linux you will need to replace 'flash-util/dfu-programmer' with an appropriate binary, or symlink it to one)
• Changes in r4b5 / r5b2 (from r4b4 / r5b1):
  • For split keyboards that use the Num Lock shared layer select feature, turn host Num Lock off automatically at keyboard initialization
• Changes in r5 (from r5b2):
  • Add support for select Beamspring models: B104r1, BSSKr1, BSSKr2, B62 (B104r2 and B122 matrices are too large for / incompatible with xwhatsit and are not supported)
  • Re-introduced separate keyboard layout and keymap options that are installable at flash-time...you can once again select from many common layout options during flash instead of flashing & manually reconfiguring

[Muirium]

Cool. What architecture is your Mac build of the Pandrew Util? Is it still just Intel? (I checked: it's Intel only.)

I tried building an ARM (Apple Silicon) version of the Util myself, but couldn't get it to work. I’m no coder, so the filthy hacking I was doing to clear all the build errors I getting was both gross and still going nowhere. It was all about qt.

I'd like an ARM or Universal build that works with regular Pandrew's QMK on original Xwhatsit + IBM hardware ideally, as that's what I run.

[shampoo]

If it is one key it is most likely the spring needing replacement, or possibly debris in the area.

I ended up taking the keyboard apart.. Cleaned everything and put it back together.

If there is ever a V2 of this keyboard, making it easier to replace a switch which be SO much better. Having to remove all the keycaps and then splitting open that sandwich is such a PITA.. I just bend back the long tabs to get it open.. but I figure doing that enough times will eventually cause those tabs to break..

Anyhow, long story short, it appears to be working now with no ghosting.

[NathanA]

Cool. What architecture is your Mac build of the Pandrew Util? Is it still just Intel? (I checked: it's Intel only.)

I tried building an ARM (Apple Silicon) version of the Util myself, but couldn't get it to work. I’m no coder, so the filthy hacking I was doing to clear all the build errors I getting was both gross and still going nowhere. It was all about qt.

I built this copy of the util back at the beginning of November. I used the same toolchain to do so as I did for prior releases. All I intended to do was to add support for additional models of keyboards. I haven't had time to screw around with putting together a universal binary release & though I'm sure I'll try my hand at doing so at some point, this is frankly not a priority for me at the moment.

pandrew-util is written against Qt5. Apple Silicon wasn't supported as a first-party build target in Qt until 6.2, and did not get backported to version 5 until 5.15.9. I use a precompiled version of older Qt5 that Qt Group released quite a while ago, which is Intel-only. Back in 2020, Qt Group announced that as of 5.15.x, offline installers would only be downloadable by developers paying for & holding a commercial license.

To me, this leaves free availability of precompiled binaries of latest Qt5 (ones that would actually support Apple Silicon) from Qt themselves in an ambiguous place. I mean, I'm certainly not going to pay for a commercial license. It may be that you can still obtain binaries at no cost through the "online installer", if you create a Qt Account first. Haven't investigated this too deeply yet.

If not then you'll be forced to build Qt from source, which can be a daunting and lengthy task given the sheer massive size of the codebase and its various build dependencies. Googling around, this article seems like a good starting point for doing so on Mac for anybody who feels like giving it a shot.

[NathanA]

If there is ever a V2 of this keyboard, making it easier to replace a switch which be SO much better. Having to remove all the keycaps and then splitting open that sandwich is such a PITA..

These keyboard are recreations of a tried-and-true design that IBM came up with decades ago.

Discrete buckling spring switch mechanisms -- especially ones that 100% reproduce everything that fans of the Model F switch love & expect -- would surely be non-trivial to design, test, and manufacture. It took long enough to merely faithfully recreate an existing design... You're talking about a whole 'nuther project entirely here, not a "v2".

[NathanA]

Another Vial question: I got the split ortho which uses numlock for layer switching. Does anyone know how to setup a momentary layer switch (numlock on when pressing down, off on release)?

[...]

Edit 2: The button I was looking for is actually called "Locking Num" and can be found on "App, Media..." tab second to last.

Correct; I went over this here and then again here

Edit: I figured out that TD(1) by default was configured this way. It has numlock assigned to "on hold" and "on double tap" others are blank.

Correct: Tap Dance 1 is set to the Locking Num when held (press for layer switch, release when done), and to regular Num Lock when double-tapped (leaves Num Lock on, so layer remains locked/switched to, until you tap it again to turn it back off & go back to Layer 0) but not when single-tapped (empty action).

This is to precisely reproduce the same behavor that the regular Ergodox layout prescribes for that same key. Regular Ergodox layout *without* Num Lock based layer switching & sharing has TT(1) set for that same key position. The QMK layers documentation describes TT(x) functionality as follows:

TT(layer) - Layer Tap-Toggle. If you hold the key down, layer is activated, and then is de-activated when you let go (like MO). If you repeatedly tap it, the layer will be toggled on or off (like TG). It needs 5 taps by default, but you can change this by defining TAPPING_TOGGLE -- for example, #define TAPPING_TOGGLE 2 to toggle on just two taps.

TAPPING_TOGGLE is indeed set to 2, so you get identical behavior to TT(1) when using the preconfigured TD(1) on a firmware that has Num Lock layer selection enabled.

[NathanA]

Ohh I see. Thanks! I'll try again tonight. I've never used Vial before so it wasn't immediately apparent to me that you just needed the firmware for the right keyboard model, which will allow to pick the correct layout variation later, in the software.

You can now also try my latest version (r5) that I posted earlier this morning, which includes a bunch of preconfigured layouts that can be programmed in at time-of-flash. But even if you use one of those for the initial programming, Vial still allows you to completely change the layout later, without requiring a complete re-flash. Just make the changes you want in the Vial interface, or alternatively load the preconfigured layout that you want to switch to using the Vial app (you would pick the .vil file for the layout you want, not the .hex with the same name; the .hex is what is used to do the initial layout programming during a flash, so it's the same layout as contained in the .vil file, just in a different format that's compatible with the flash utility).

You didn't address whether switching to the Vial firmware fixed your solenoid responsiveness...did it?

[NathanA]

From what I understand, the command file (flash-allpads-f77.bat) flashes the most up-to-date firmware, which means the keyboard should now work with the solenoid (old firmware had some bug) - is that correct?

Did you try the solenoid after flashing? Should answer the question.

If solenoid is broken with these Vial firmwares, then people need to pipe up and let me know. I've mentioned before that I don't personally own a solenoid, so I can't test it myself first-hand. I can only go off of what other people tell me. I have heard other positive reports, so until I hear otherwise, I will assume solenoid is working properly.

[NathanA]

Thanks wolfman for the QMK update. It is interesting to see a behind the scenes look at the approval process. After something is approved, what if it loses compatibility with the latest QMK version? It seems like QMK is updated so much that some boards may lose compatibility.

The way that this is supposed to work *in theory* is that once a keyboard model has had its contributions accepted into the main QMK source tree, there is no threat of future QMK versions ever "losing compatibility" with the keyboard, since the QMK developers at that point actually take on the responsibility of updating all officially-supported keyboards whenever they themselves make any kind of "breaking change" to the underlying QMK base. This is very similar to how drivers in the Linux kernel are handled for officially-supported hardware: once the driver is "in", if Linux core makes a big underlying API change, the Linux maintainers will themselves update the included drivers so that they are compatible with the new version of Linux.

Think of prepping a new keyboard model for inclusion with QMK (or a driver for a new piece of hardware in Linux) like merging onto an interstate from an on-ramp: you're responsible for getting up to & matching speed so that you can then safely merge into traffic. Once you are on the highway and going with the flow of traffic, then you can put on the cruise control.

The reason that this has proven to be so much more difficult with the capsense keyboards compared to virtually every other keyboard model that has been accepted into core QMK to-date is that most keyboards in QMK just elect to use the default matrix decode engine that's included in QMK. So most "new keyboards" are just the same old mecha switches wired up slightly different than the next one. But QMK had zero capsense support before this, and adding support for a capsense matrix is vastly more complicated and requires re-invention of many wheels.