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

[daedalus]

I suspect it's the Silver Grey option - it doesn't look like either the beige or the Industrial Grey to me

See this post here: viewtopic.php?p=460773#p460773

[robo]

I suspect it's the Silver Grey option - it doesn't look like either the beige or the Industrial Grey to me

See this post here: viewtopic.php?p=460773#p460773

Ah, maybe. I think this reinforces my comment about the photography on the main site, it's pretty hard to judge what the colors look like. Silver grey there looks very different.

[daedalus]

I have one of the Industral Grey cases, and it's more of a green colour (I'm using the blue keycaps as a reference as I have a set of those)

[Muirium]

Shame it's not the right colour. But China, whatyagonna do? Is the paint staying on better now?

[Ellipse]

Yep it's silver gray. The Industrial Gray is more of a green-tan-gray type color, while the Silver Gray option is more of a Silver-Blue-Gray type color. The Industrial Gray on the new Model F Keyboards is a pretty good match with the original IBM Industrial SSK: https://www.modelfkeyboards.com/wp-cont ... 7-Copy.jpg

As a note the IBM Industrial SSK case color is noticeably different from the IBM 101-key Industrial Gray Model M. I've seen both in person and the 101-key has much less tan/brown in the color mix. https://www.modelfkeyboards.com/wp-cont ... 0722-2.jpg

For Silver Gray the target was the Benjamin Moore Silver/Blue Gray color shown here: https://www.benjaminmoore.com/en-us/col ... or=2131-60

As an update I posted another one of the monthly updates on the project web site. Not too much new with this update, as orders continue to go out. The factory expects to finish up the remaining international sets and other key sets this month, after significant delays.
https://www.modelfkeyboards.com/blog/

[Bschuster]

Hey, have an issue with my solenoid. In short, the solonoid stops being clicky if I type too fast. Example: https://youtu.be/5kZXMFVnwCA

I did have to re flash my firmware as I did not have the keys to impact the solonoid throw range. However I could t figure out how to fix this issue. Any advice?

[Ellipse]

Hi Bschuster, did you check out the manual's new solenoid section as well as the firmware flashing instructional video? Here's part of the written documentation:

If you are using any of my hex files for either QMK or Via, this is done for you automatically. However if you use the QMK Configurator web site to make your firmware, import my JSON template file for your configuration and flash the firmware (see the firmware section of this manual), and while the keyboard is connected to your computer, hold down the keys Fn+Spacebar++= (the + = key next to backspace) which has been preprogrammed to increase the Solenoid dwell time by 1 ms. Press it 20 to 25 more times to get it to the minimum required amount for full power. You can also press the following options
Fn+Spacebar+T–>Toggle the Solenoid On/Off
Fn+Spacebar+ -_ Decrease Solenoid dwell time HPT_DWLD. Refer to the two solenoid videos at the top of this page for a visual guide. To program this into your own keyboard, for QMK drag the Any key to the key and layer you want, and then type in HPT_TOG to toggle, HPT_DWLI to increase the dwell time 1ms, or HPT_DWLD to decrease it. Each key has to be in its own box of course.


As a test you could also flash the original firmware linked to in the manual, which is preprogrammed for full solenoid operation even with super fast typing.

[NathanA]

As a note the IBM Industrial SSK case color is noticeably different from the IBM 101-key Industrial Gray Model M. I've seen both in person and the 101-key has much less tan/brown in the color mix.

Interesting. Do you (or anyone else active on this thread) have access to both an Industrial SSK M and an Industrial 101-key M? If so, would you mind at some point taking a picture with both of them together in the same shot for comparison? In your copious amounts of spare time, of course...

[Bschuster]

Hi Bschuster, did you check out the manual's new solenoid section as well as the firmware flashing instructional video? Here's part of the written documentation:

If you are using any of my hex files for either QMK or Via, this is done for you automatically. However if you use the QMK Configurator web site to make your firmware, import my JSON template file for your configuration and flash the firmware (see the firmware section of this manual), and while the keyboard is connected to your computer, hold down the keys Fn+Spacebar++= (the + = key next to backspace) which has been preprogrammed to increase the Solenoid dwell time by 1 ms. Press it 20 to 25 more times to get it to the minimum required amount for full power. You can also press the following options
Fn+Spacebar+T–>Toggle the Solenoid On/Off
Fn+Spacebar+ -_ Decrease Solenoid dwell time HPT_DWLD. Refer to the two solenoid videos at the top of this page for a visual guide. To program this into your own keyboard, for QMK drag the Any key to the key and layer you want, and then type in HPT_TOG to toggle, HPT_DWLI to increase the dwell time 1ms, or HPT_DWLD to decrease it. Each key has to be in its own box of course.


As a test you could also flash the original firmware linked to in the manual, which is preprogrammed for full solenoid operation even with super fast typing.

Yes! Finally, got it working. After flashing your original F77 code and then playing around with the settings, I was able to get it right. Thank you!

[daphnis]

Hm, after two years with no mechanical issues, my I key has problems. At first it wouldn't register until I released it and then not at all. Pulling it out and replacing it fixes it for a week or so until the same problem returns.

[QuantumDOS]

Hey Ellipse,

I'm going to be relocating soon and was curious if an address change is still possible at this juncture. Sorry for hitting you up on the Deskthority boards, but I wasn't 100% sure I was interpreting the customer service email provided on the model F webpage.

Thanks a million for bringing this awesome project to life!

[Ellipse]

That is good to hear Bschuster!

QuantumDOS yes please email me for all address changes and include your order number.

daphnis did you see the QC secrets video linked to in the manual on the project web site? If you are pulling springs that has probably damaged the spring. More details are in the spring QC section of the video and in the manual.

[daijoubu]

I noticed that the QMK and Via zipped hex files that Ellipse posted, the via firmwares does not have the split space mapped.

[I0IParzival]

Hi all! I was wondering (while waiting my f77), why not an ortho option?? I guess not many people is interested, but only the plate and the membrane and probably the membrane can be shared across models. A man can dream....

[Ellipse]

daijoubu this is correct - to customize your keyboard further I recommend starting from the pre-made JSON files in the posted zip file in the manual on the project web site and making adjustments from there for split space bars or other custom split keys.

For what do most folks use their extra key near the space bar if they use the shorter space bar? Right click/menu?

[daijoubu]

daijoubu this is correct - to customize your keyboard further I recommend starting from the pre-made JSON files in the posted zip file in the manual on the project web site and making adjustments from there for split space bars or other custom split keys.

For what do most folks use their extra key near the space bar if they use the shorter space bar? Right click/menu?

I tried with the pre-made hex files files for Via and it doesn't detect the extra key for the short space, but it does for the short right shift.
This is even after I have enabled short space in the Via GUI.

However when I flashed the Via firmware on darkcruix's website here https://www.bucklingspring.com/via-firmware-and-layout/, it short space extra key is activated. So i suspect there is something wrong with the Via firmware in the posted zip. Unfortunately darkcruix's firmware does not have the solenoid toggle shortcuts, so right now I am using the zipped QMK files to have both solenoid + short space extra key function.

I use the extra key as an Fn. It's intuitive to use that with the thumb and then use the immediate keys on the right as an arrow cluster.

[NathanA]

I tried with the pre-made hex files files for Via and it doesn't detect the extra key for the short space, but it does for the short right shift.
This is even after I have enabled short space in the Via GUI.

However when I flashed the Via firmware on darkcruix's website here https://www.bucklingspring.com/via-firmware-and-layout/, it short space extra key is activated. So i suspect there is something wrong with the Via firmware in the posted zip.

I don't use the split space / extra key, but I tested your claim, and can confirm that I see the same thing...

Did some debugging and managed to figure out what's going on. pandrew's calibration code, which wasn't written with VIA in mind (& specifically the idea that you might flash a firmware to your 'board that doesn't have certain keys mapped to anything on layer 0 out-of-the-box, but that you might decide to change that later with VIA), will apparently skip auto-threshold-calibration of a particular key and act like it doesn't exist if that key is mapped to KC_NO (QMK's "no-op" keycode) on layer 0 within the default keymap burned into the firmware image. Therefore it doesn't matter if you change it with VIA after flashing that image, because the pandrew capsense matrix initialization routine doesn't look at the keymap saved to EEPROM, since it doesn't even know that such a thing exists (EEPROM-resident keymaps aren't a thing in stock QMK, only in VIA/Vial-enabled firmwares).

The workaround for this turns out to be simple: make sure you assign some default keycode -- any keycode -- to the unused key. Don't just set it to KC_NO.

The reason that the extra split space key works with darkcruix's build of VIA firmware is because he built his with a default keymap that maps the extra key to space, so pandrew's calibration code doesn't skip over the key during startup. The copy that Ellipse built (as well as the Vial version that I built) used a keymap that set the extra key to KC_NO, so that key has been inadvertently disabled permanently in these particular builds of the firmware.

I've gone ahead and built a new version of my Vial firmware for the F62 that should fix this, and which also uses Ellipse's solenoid timings by default. If you're willing to give it a try, I'd love to hear if it fixed it for you.

Note that the attached firmware is both VIA and Vial compatible, but that if you try to load a saved keymap with VIA, it will not properly restore the solenoid toggle shortcuts to Fn layer 2 (this seems to be a problem with VIA on the whole, not with this particular version of the firmware). So for that (and many other) reason(s), I recommend using Vial instead. However, if you specifically want to use VIA, then you will need to use the particular JSON definition file bundled with this firmware in order for VIA to see the keyboard; the one that comes with the darkcruix and Ellipse archives won't work.

As far as long-term fix for the issue, maybe the calibration routine should be rewritten to take the layout stored in EEPROM into account, though that may not be worth it & we should perhaps just avoid using KC_NO for any keys on layer 0 in any publicly-distributed keymaps. I haven't tested this yet, but I suspect that if you absolutely don't want a particular key on layer 0 to register a scancode to the host at all, I'd bet you can just use KC_TRNS on layer 0 for that key instead of KC_NO.

[daijoubu]

I tried with the pre-made hex files files for Via and it doesn't detect the extra key for the short space, but it does for the short right shift.
This is even after I have enabled short space in the Via GUI.

However when I flashed the Via firmware on darkcruix's website here https://www.bucklingspring.com/via-firmware-and-layout/, it short space extra key is activated. So i suspect there is something wrong with the Via firmware in the posted zip.

I don't use the split space / extra key, but I tested your claim, and can confirm that I see the same thing...

Did some debugging and managed to figure out what's going on. pandrew's calibration code, which wasn't written with VIA in mind (& specifically the idea that you might flash a firmware to your 'board that doesn't have certain keys mapped to anything on layer 0 out-of-the-box, but that you might decide to change that later with VIA), will apparently skip auto-threshold-calibration of a particular key and act like it doesn't exist if that key is mapped to KC_NO (QMK's "no-op" keycode) on layer 0 within the default keymap burned into the firmware image. Therefore it doesn't matter if you change it with VIA after flashing that image, because the pandrew capsense matrix initialization routine doesn't look at the keymap saved to EEPROM, since it doesn't even know that such a thing exists (EEPROM-resident keymaps aren't a thing in stock QMK, only in VIA/Vial-enabled firmwares).

The workaround for this turns out to be simple: make sure you assign some default keycode -- any keycode -- to the unused key. Don't just set it to KC_NO.

The reason that the extra split space key works with darkcruix's build of VIA firmware is because he built his with a default keymap that maps the extra key to space, so pandrew's calibration code doesn't skip over the key during startup. The copy that Ellipse built (as well as the Vial version that I built) used a keymap that set the extra key to KC_NO, so that key has been inadvertently disabled permanently in these particular builds of the firmware.

I've gone ahead and built a new version of my Vial firmware for the F62 that should fix this, and which also uses Ellipse's solenoid timings by default. If you're willing to give it a try, I'd love to hear if it fixed it for you.

Note that the attached firmware is both VIA and Vial compatible, but that if you try to load a saved keymap with VIA, it will not properly restore the solenoid toggle shortcuts to Fn layer 2 (this seems to be a problem with VIA on the whole, not with this particular version of the firmware). So for that (and many other) reason(s), I recommend using Vial instead. However, if you specifically want to use VIA, then you will need to use the particular JSON definition file bundled with this firmware in order for VIA to see the keyboard; the one that comes with the darkcruix and Ellipse archives won't work.

As far as long-term fix for the issue, maybe the calibration routine should be rewritten to take the layout stored in EEPROM into account, though that may not be worth it & we should perhaps just avoid using KC_NO for any keys on layer 0 in any publicly-distributed keymaps. I haven't tested this yet, but I suspect that if you absolutely don't want a particular key on layer 0 to register a scancode to the host at all, I'd bet you can just use KC_TRNS on layer 0 for that key instead of KC_NO.

Whoa Nathan many thanks for helping with this! I'll give the firmware a try Friday or this weekend the latest and let you know how it goes. Appreciate your efforts!

[daijoubu]

NathanA, I've tested the Vial firmware you made and it is now working perfectly! There are two observations I made:

a) Sometimes the Q key and the whole number row may stop working midway. Replugging in the keyboard fixes this. It has happened twice, will see whether it reoccures
b) The snappiness and how the solenoid keeps up seems slower than the QMK firmware. I realise even with changing the dwell times I cannot get to a point where the solenoid keeps up with my typing, as opposed to the QMK firmware's. Because of this I went back to the QMK firmware since the solenoid's performance is better.

If there anyway that I can manually adjust the solenoid's performance in the Vial's firmware? I am not well verse in editting and compiling the firmware so I apologize for coming across as a noob .

Other than that, thanks for making a working Vial firmware for the extra space key!

[NathanA]

a) Sometimes the Q key and the whole number row may stop working midway. Replugging in the keyboard fixes this. It has happened twice, will see whether it reoccures

Bizarre. I've never seen this and I use Vial firmware with my F77 daily...

Next time it happens, you might fire up the pandrew utility and run the Keypress Monitor and Signal Level Monitor to see if they are showing anything unusual for those particular keys. You will need to grab a copy of my updated version of the utility since the original pandrew one doesn't work with the Vial firmware.

b) The snappiness and how the solenoid keeps up seems slower than the QMK firmware. I realise even with changing the dwell times I cannot get to a point where the solenoid keeps up with my typing, as opposed to the QMK firmware's. Because of this I went back to the QMK firmware since the solenoid's performance is better.

If there anyway that I can manually adjust the solenoid's performance in the Vial's firmware?

Also strange, since both the solenoid code as well as the default dwell time (20ms) in mine should be identical to the QMK firmwares from Ellipse. But I don't have a solenoid to test with myself.

Did you try manually adjusting the dwell time with Fn + Spacebar + [+/-] ? Does that make any difference?

Before you flashed the Vial firmware, did you make sure to wipe the contents of EEPROM (not 100% sure both of these steps are needed, but since I have not been able to find A SINGLE PERSON who can tell me exactly what eeprom_erase.hex actually does, for completeness' sake, I would try: first flash eeprom_eraser.hex, then wait several seconds before QMK Toolbox sees it reconnect, then click "Clear EEPROM" button at bottom)?

If you use the Ellipse QMK firmwares, do you have to adjust the solenoid dwell time at all, or does it just work for you as expected out-of-the-box?

[daijoubu]

The default solenoid dwell time did not do it for me, so I had to manually adjust it so that it reaches a level where I can press q.w.e consecutively many times without the solenoid lagging. With the Vial firmware I cannot find a setting that I can do that, but with the QMK firmware I can eventually find one where it *almost* keeps up.

Perhaps I need to cycle through more on the Vial firmware, it could be there somewhere.
Is there there a way to know how many dwell time options are there with the QMK vs the Vial?

[NathanA]

The default solenoid dwell time did not do it for me, so I had to manually adjust it so that it reaches a level where I can press q.w.e consecutively many times without the solenoid lagging. With the Vial firmware I cannot find a setting that I can do that, but with the QMK firmware I can eventually find one where it *almost* keeps up.

Hmm. Are you reducing the dwell time (-) or increasing it (+)?

Perhaps I need to cycle through more on the Vial firmware, it could be there somewhere.
Is there there a way to know how many dwell time options are there with the QMK vs the Vial?

Again, it should be no different. First, to be clear, VIA-enabled and Vial-enabled firmwares are just QMK with extra sprinkles on top. It's still QMK at the core. Second, I took the default parameters for the solenoid dwell time straight from Ellipse's build instructions that he follows when he makes his QMK firmware images. They should be a match.

Dwell time is measured in milliseconds. By default:

• QMK straight from the source (which does NOT support the New Model F keyboards) allows for a range of dwell times as low as 4ms and as high as 100ms, and defaults to 12ms (unless a specific keyboard driver overrides that).
• pandrew's xwhatsit additions to QMK lowered the default dwell time to 4ms from 12.
• After testing with his new solenoids, Ellipse not only raised the default dwell time from 4ms to 20, but he also raised the minimum to 20 as well (can't make it go any lower than that).
• Since that's what Ellipse does for his QMK firmwares, and since that's what seems to work for most people, that's what I also did for my builds of Vial-enabled firmwares.
• The Fn & Space & + or - key sequences add or subtract 1ms from whatever dwell time you are currently using.

So for example, if you were using the darkcruix VIA firmware (which I believe still retains the pandrew default dwell of 4ms), if you wanted to get the dwell time to match what Ellipse recommends & defaults to in his firmwares, you'd have to press Fn&Space&+ 16 times (4 + 16 == 20).

I guess the other question I should be asking rather than assuming the answer to is...are you using a solenoid you bought from Ellipse? Or one that you sourced from somewhere else?

[daijoubu]

The default solenoid dwell time did not do it for me, so I had to manually adjust it so that it reaches a level where I can press q.w.e consecutively many times without the solenoid lagging. With the Vial firmware I cannot find a setting that I can do that, but with the QMK firmware I can eventually find one where it *almost* keeps up.

Hmm. Are you reducing the dwell time (-) or increasing it (+)?

Perhaps I need to cycle through more on the Vial firmware, it could be there somewhere.
Is there there a way to know how many dwell time options are there with the QMK vs the Vial?

Again, it should be no different. First, to be clear, VIA-enabled and Vial-enabled firmwares are just QMK with extra sprinkles on top. It's still QMK at the core. Second, I took the default parameters for the solenoid dwell time straight from Ellipse's build instructions that he follows when he makes his QMK firmware images. They should be a match.

Dwell time is measured in milliseconds. By default:

• QMK straight from the source (which does NOT support the New Model F keyboards) allows for a range of dwell times as low as 4ms and as high as 100ms, and defaults to 12ms (unless a specific keyboard driver overrides that).
• pandrew's xwhatsit additions to QMK lowered the default dwell time to 4ms from 12.
• After testing with his new solenoids, Ellipse not only raised the default dwell time from 4ms to 20, but he also raised the minimum to 20 as well (can't make it go any lower than that).
• Since that's what Ellipse does for his QMK firmwares, and since that's what seems to work for most people, that's what I also did for my builds of Vial-enabled firmwares.
• The Fn & Space & + or - key sequences add or subtract 1ms from whatever dwell time you are currently using.

So for example, if you were using the darkcruix VIA firmware (which I believe still retains the pandrew default dwell of 4ms), if you wanted to get the dwell time to match what Ellipse recommends & defaults to in his firmwares, you'd have to press Fn&Space&+ 16 times (4 + 16 == 20).

I guess the other question I should be asking rather than assuming the answer to is...are you using a solenoid you bought from Ellipse? Or one that you sourced from somewhere else?

I think the dwell time cycles. I start off my increasing the dwell time until it becomes strong enough, but it wont be able to keep up with my usual typing speed (about 80-100 wpm). Then I realise as I keep increasing it, it'll jump from "strong" to suddenly weak again, and then slowly back to strong. At a certain point for the QMK it'll be both strong and can keep up with my typing, but I can't seem to find that point in the Vial firmware.

I am using the solenoid bought from Ellipse.

Just a quick question, what is dwell time anyway? I at first assume that as I go higher "Fn + Space + "+" it adds more power and faster response speed.

[axql]

When did people who have recently received their boards place their orders? (Assuming you didn't ask for a low serial). I'm interested in seeing how far along they've gotten.

Ordered mine in May 2021...still waiting. I guess I am in for a long wait but I have other keyboards to tide me through

I ordered mine in May of 2018 and am still waiting. RIP me

[robo]

When did people who have recently received their boards place their orders? (Assuming you didn't ask for a low serial). I'm interested in seeing how far along they've gotten.

Ordered mine in May 2021...still waiting. I guess I am in for a long wait but I have other keyboards to tide me through

I ordered mine in May of 2018 and am still waiting. RIP me

I'm really hoping that things are shipping out at a much faster rate than orders were coming in over the last 3 years...

[Ellipse]

Yes, I expect to get out the remaining orders over the next 6-7 months as noted earlier. Orders with sublimated keys only started going out less than one year ago - will be going full speed once everything from the factory arrives (keys, etc.). The remaining sublimated keys should be completed in the coming weeks. Once again I thank everyone for their patience with the factory and with me as I go through the backlog.

[PRIPARA_PLAYER]

I just went to add some extra bumpers to my order, when I got to checkout it didn't list any options for shipping and said my total was $10, then when I checked out the full international shipping cost was suddenly tacked on and charged to me.
Has the checkout process changed to no longer allow adding small items?

[Ellipse]

Everyone feel free to contact me for a discounted shipping quote if you are only ordering smaller items that ship separately. Otherwise they can ship with your keyboard if it hasn't shipped already (can pick "other shipping" if that's the case).

[PRIPARA_PLAYER]

Everyone feel free to contact me for a discounted shipping quote if you are only ordering smaller items that ship separately. Otherwise they can ship with your keyboard if it hasn't shipped already (can pick "other shipping" if that's the case).

That's the issue I'm running into, the "other shipping" option is no longer showing up for me. I just went through again and I can select "other payment", but there's no "other shipping"

EDIT: After placing an order with "other payment", I now can go through checkout a third time and this time around select "other shipping" Maybe something is just messing up on my end with loading shipping based on the address.

EDIT 2: I've gotten to the bottom of this, I need to intentionally click place order without agreeing to terms of conditions to get an error and the shipping options to load based on my address. If I agree then it goes straight through without giving me shipping options.

[Ellipse]

Hmm, I just did a test of ordering one keycap and entering in your information in sequence of the text boxes on the checkout page (starting at the top and moving downwards) and was able to see and select both the other shipping and other payment options. I know the system likes to see the address before it calculates the shipping options (maybe a limitation of Woocommerce or my own very limited coding knowledge). You have to click to each next box and enter in the information before the the options show up.