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

NathanA

26 May 2022, 03:43

headphone_jack wrote:
26 May 2022, 03:23
I haven't actually tried. I was so frustrated by the end of the whole endeavor I boxed up the keyboard and haven't opened it since, except to take pictures for listing.
Oh, dang it, I just remembered another thing I was going to ask you: some of your experience with the reflash sounds a little like what Chyros described going through in his video review, and IIRC I think it was eventually discovered in his case that at least part of the problem turned out somehow to be a USB hub that he had the keyboard plugged into, and that once he plugged the keyboard directly into the computer and bypassed the hub, (some of his) issues with getting into bootloader mode were solved by that. (Ugh now I need to go back and re-watch to make sure I'm not mis-remembering or mixing this up with something else...) Was your keeb plugged into a hub at the time you were trying to reflash it?

Sorry for peppering you with questions...

headphone_jack

26 May 2022, 05:25

NathanA wrote:
26 May 2022, 03:43
headphone_jack wrote:
26 May 2022, 03:23
I haven't actually tried. I was so frustrated by the end of the whole endeavor I boxed up the keyboard and haven't opened it since, except to take pictures for listing.
Oh, dang it, I just remembered another thing I was going to ask you: some of your experience with the reflash sounds a little like what Chyros described going through in his video review, and IIRC I think it was eventually discovered in his case that at least part of the problem turned out somehow to be a USB hub that he had the keyboard plugged into, and that once he plugged the keyboard directly into the computer and bypassed the hub, (some of his) issues with getting into bootloader mode were solved by that. (Ugh now I need to go back and re-watch to make sure I'm not mis-remembering or mixing this up with something else...) Was your keeb plugged into a hub at the time you were trying to reflash it?

Sorry for peppering you with questions...
I originally did have it plugged into a USB PCIE card, but even after I plugged it directly into my motherboard (no small feat I might add, my motherboard ports aren't accessible from the outside of the case) the problems persisted with no change.

Neightro

26 May 2022, 06:55

NathanA wrote:
26 May 2022, 03:31

There is no way to get this working with a proper Num Lock as far as I am aware, at least not without some extensive re-working of QMK under-the-hood (like making it possible for the keyboard to change layers in response to the system's current Num Lock status, which I think would actually be a pretty cool feature...).
Unfortunate; this is what I had feared. A pseudo-numlock wouldn't be the worst thing; it's not as if these keyboards come with lock lights to begin with. I would love to see a keyboard firmware implement that; remapping the numpad is surely a common use case.
NathanA wrote:
26 May 2022, 03:31

But I would be happy to put together a F77 Layout 5 config for you, much like I did a Layout 4 config for HatefulLight. The disclaimers & qualifications are that it would be applicable to Vial, so you'd have to flash to that, and it would be a similar kind of "pseudo" Num Lock: I can make the key actions switch between outputting numbers and nav commands by having you press a key that is physically labeled "Num Lock" or that you think of as "Num Lock", but actual Num Lock status on the computer won't be changing when you press it. If that works for your needs, I'll throw it together...
If you aren't too busy, then that would be greatly appreciated. It would also be fantastic if you could link me to the Numpad 4 config; I should be able to piece something together from there. If that's the case, then I'll drop whatever I end up creating here.

Disclaimer noted! I'm thinking about flashing Vial anyways; I like libre software, as well as the idea of not depending on an online service. No hate on QMK, of course; it's just not my preference.

It would be great to have these configs linked/included within the documentation, if they aren't somewhere already. I'm sure there's other people who would find them useful.
NathanA wrote:
26 May 2022, 03:31

(Also, which key should toggle "pseudo-NumLock" on and off? Unlike Layout 4, there is no dedicated Num Lock key on the 3x5 pad. So you'll have to pick some other key on the 'board to use as a toggle. By default I think Ellipse mapped right Ctrl to the actual Num Lock. I can either re-map that to the so-called pseudo-NumLock, or you can pick a different key and use right Ctrl as an actual Ctrl key.)
I have an HHKB layout with a home-row Ctrl, and out of the box Num Lock is mapped between Right Alt and Right Ctrl. I don't know if I'll keep it there in my config, but it works well as a standard default.

NathanA

26 May 2022, 10:21

Neightro wrote:
26 May 2022, 06:55
It would be great to have these configs linked/included within the documentation, if they aren't somewhere already. I'm sure there's other people who would find them useful.
Might not be 100% clear to you yet, but a huge percentage of the goings-on in these parts are community efforts, so they don't necessarily get roped back into the "official" docs, at least not immediately. For example, as far as Vial support on this keyboard goes, I'm pretty much the only one at this point trying to take up that cause (such as it is). I'd love one day to see it treated as a first-party option, but I haven't pushed hard on that yet because I'd still like to see it mature a bit more first (right now the firmware-side of things on the F62/F77 Vial-wise is stuck back at the v0.4.1 / summer 2021 code level due to serious stability issues whenever newer Vial code and the pandrew QMK capsense driver get anywhere near each other; I just haven't yet had the time either to pester pandrew about it and/or to try to dig into it myself).

Thus...
Neightro wrote:
26 May 2022, 06:55
It would also be fantastic if you could link me to the Numpad 4 config; I should be able to piece something together from there. If that's the case, then I'll drop whatever I end up creating here.
...the things you seek are mostly to be found directly within this thread. Just search, and ye shall find.
Neightro wrote:
26 May 2022, 06:55
I have an HHKB layout with a home-row Ctrl, and out of the box Num Lock is mapped between Right Alt and Right Ctrl. I don't know if I'll keep it there in my config, but it works well as a standard default.
Good; HHKB makes this easier because you have that split right shift with the extra key that by default is "Fn". And I misspoke earlier: you're right & the key between RAlt and RCtrl is by default Num Lock; what I was thinking of was RCtrl being "Fn" by default on models without the split right shift.

I've attached my take on a right block layout #5. I would advise you to first read my post that I linked to earlier that contained the layout #4, where I link to the Vial files you'll need as well as offer general flashing advice, and explain how the layout works & the reasons behind some of the choices I made (not all of which will apply to #5).

Here were the assumptions I made while building this one:
  • pseudo-NumLock is off by default; if you want this reversed, you will need to swap the key assignments for the right block between layers 0 and 1.
  • Keys 1, 2, 3, 0, and . don't have dual functions/legends printed on them; thus I left them function-less on the nav command layer...seemed to make sense that if you're busy using the inverted-T arrows for something, you might prefer that nothing happen if you accidentally strike one of the keys adjacent to any of the arrow keys while trying to use them. That said, if they're used frequently enough, you might want 0 and . at the very least to always output 0 and . even when Num Lock is not "on". You can make this change easy enough if desired.
  • In contrast to this, the arrow keys will work on both the nav and number layers. If you don't want this, then set the arrow keys to blanks on the number layer instead of the fallthrough/transparent action they're set to now.
  • Finally, there are no - and + on the numpad in layout #5, so I had to figure out somewhere else to put the NKRO toggle and bootloader mode shortcuts. I elected to put them at Fn+1 (NKRO) and Fn+3 (bootloader) since those seemed out of the way enough as to not be accidentially triggered (esp. since -- again -- 1 and 3 have no secondary legends, so unlikely to hit Fn + either of them by accident).
The devil, it turns out, really is all in the details, and there are often way more things that one needs to consider than one might first assume. ;)

Enjoy!
Attachments
F77_-_HHKB_split_backspace_-_Option5.zip
(1.06 KiB) Downloaded 61 times

sedevidi

26 May 2022, 10:30

Neightro wrote:
26 May 2022, 06:55
If you aren't too busy, then that would be greatly appreciated. It would also be fantastic if you could link me to the Numpad 4 config; I should be able to piece something together from there. If that's the case, then I'll drop whatever I end up creating here.
NathanA's #4 config is a few pages earlier (~245), and my #3 is also somewhere there, with an added bonus that numpad numbers are actually "Shift+numrow" because AZERTY outputs real number only with Shift pressed. I guess my config would not be that generaly useful.
I decided to reproduce my #3 config from NathanA's #4 description of the process, instead of loading and adjusting his config. Much easier to understand; easy anyway.

vpap

26 May 2022, 10:42

NathanA wrote:
26 May 2022, 03:21
vpap wrote:
25 May 2022, 22:17
And then I saw that the alt key when completely pressed would not always be shown as pressed down.
Sounds like between the two of them, it's the Alt key that's the actual problem, then. If you sometimes see that keypress monitor doesn't show the key as being pressed down when it is, do you also similarly see signal levels not always changing as expected for that key on the signal level monitor when you press it?

I still think it's weird that Y, U, F, V, and B all show as low 130s at best on your signal level monitor screenshot after you said that you pressed them...are you also having problems with those keys?
It seems like the Alt key was the problem after all. I took out the keycaps of Alt and Ctrl and I compared the barrels and the springs and there wasn't anything too obvious. But it seemed like at their resting position the spring on Ctrl was always on the center of the barrel, meanwhile the spring on Alt was always slightly looking downwards. So with a pair of tweezers I played around with the spring on the Alt key and I tried to "bend" it the other way. This seemed to have done the job, I can't replicate the previous erratic behavior anymore.

Regarding the other keys you mentioned I redid the test by pressing each key on the keyboard instead of trying many at once. I don't have problems with other keys so far.
pressing_all_the_keys_again.PNG
pressing_all_the_keys_again.PNG (42.4 KiB) Viewed 41723 times

sedevidi

26 May 2022, 10:49

sedevidi wrote:
25 May 2022, 12:54
I openned the anvil, added a layer of isolation between the controller and the bottom of the case, tightenned one controller screw, tested without the case, and everything was seemingly OK. After closing the case with everything in place, all keys were OK too.
So: grounding issue... solved...
Well, not that much. The rest of yesterday proved a bit more difficult, as the LeftCtrl did misbehave more and more as hours passed. I just unplugged the keyboard and replugged it somewhere else this morning, and it seems to work better. Maybe a power supply issue, then.

The keyboard was on an USB2 port on the Thinkpad Dock (with proper power supply and behind an USB hub inside the computer and a second USB hub inside the dock).
It is now on the USB2 charging port in the back of the Thinkpad itself (a single USB hub away from root_hub, as "lsusb -t" shows; same first hub as above).
There is also an USB3 port on the dock, which seems to be directly connected to the root_hub... I'll try this one later.

Daniel_CH

27 May 2022, 07:00

So, back in my first post (after receiving the keyboard), I mentioned my right shift being "grindy" (or "scratchy"), and none of the solutions suggested for the horizontal large keys would work. I thought the stabilizer or barrel might be misaligned or something, but I ended up finding the solution upon closer inspection: It was actually the keycap itself grinding against the ISO enter cap above. The edges of both had a tiny bit of extra plastic, I'm assuming where they were cut, and would touch each other on press. (Somehow enter felt alright.)

Quickly smoothed both edges out with some very find sandpaper, and now everything is fine.

Putting this here just in case someone finds themselves with the same issue.

skitsykitsy

27 May 2022, 14:01

Thanks very much for your assistance, NathanA -- due to my wacky shift-hours, I haven't been able to reply until now, but your help is seriously appreciated. The community here looks pretty damn awesome, should've joined years ago.

So, after a brief moment o' thought, I discovered what was wrong with the stabbed keys: I just had to press them down _firmly_. I thought I had, but clearly not enough. A firm push, a click, and now every key works like a dream. Control keys are also (for some reason) working much better; for this I have no explanation.

The ONLY issues I'm having now are with the spring for the four key, and a query I need answered re: QMK flashing (which will be necessary if I cannot fix the four-key, and I'll be sure to check the previous pages of this thread before asking). This is already such a great typing experience that it has become my daily driver.

Does anyone have any hints/tips for getting the spring back on the flipper? I'm trying to replace it with a pair of tweezers as per the instructional videos Ellipse has made. I'm thinking of trying again after attaching tooth-floss to the spring so I can't drop it into the inner housing. Maybe it's the same as before, I'm just not pushing hard enough...
NathanA wrote:
20 May 2022, 13:02
skitsykitsy wrote:
20 May 2022, 12:36
Aha, yeah, then I have them in the correct orientation. And as I mentioned above, the enter key is wonderfully smooth but backspace (and the non-stabbed ctrl keys) are nightmares. :|
Right, if your Ctrl is acting up that's got nothing to do with stabs. Do any other 1.5U keys (like Alt or Tab or Backslash) work fine? ...

flowchartsman

27 May 2022, 21:15

Quick question on the vial firmware. I installed the latest(?) newfxx-vial_20220405 firmware and it configures great so far, aside from a small issue that was probably my fault using tapdance and TO_ together. But I noticed that there were a couple raw (hex) keycodes on layer 2, and in my overzealousness, I accidentally replaced one of them (highlighted). What should this be and also what is 0x5CDE? I'm not able to find any references to it except a QMK code that looks to do with something involving USB output. Any ides?

Image

flowchartsman

27 May 2022, 21:37

Given that 0x5CDE on the "E" key, maybe that was meant to be QK_CLEAR_EEPROM (0x5CDF) instead? Still not clear what would have gone on 'D'. Maybe QK_DEBUG_TOGGLE (0x5C01)?

vpap

27 May 2022, 22:14

It seems like that the problems didn't stop as I had a problem with the Ctrl + A combination too, which seem to have been resolved, at least for now, after playing around with the A key spring the same way I did for the Alt key. Indeed it's a let down that these reliability issues persist and I really don't know if the springs are to blame here or something else regarding the sensing. The typing feel is the best I have ever experienced out of a keyboard, but you can't do serious work with it if you have to stop your work here and then to adjust springs. Let's hope that this will be the last problem that I will ever encounter with this keyboard.

NathanA

28 May 2022, 03:46

flowchartsman wrote:
27 May 2022, 21:37
Given that 0x5CDE on the "E" key, maybe that was meant to be QK_CLEAR_EEPROM (0x5CDF) instead? Still not clear what would have gone on 'D'. Maybe QK_DEBUG_TOGGLE (0x5C01)?
Hmm, much to discuss surrounding the various issues you've brought up...

First, I should point out for y'all's benefit that the latest version of my Vial hex files that I posted only contain the firmware images and nothing else, as it was just a minor update that I was hoping to expose to wider testing. But the last major update I posted prior to that included a bunch of other stuff in it, like a (primitive) build script, the modified pandrew utility (for Windows...have gotten one built also for MacOS, hoping to post soon), and finally all of Ellipse's QMK keyboard layout JSON files converted over to .vil files for Vial.

So re: your PM to me, the F77 .hex file defaults to standard ANSI format. If you have HHKB or whatever & find some keys aren't working or doing what you expected, you should grab that main Vial archive and load your preferred layout into your keyboard from the corresponding .vil...since the whole point of Vial is to be able to change your layout on-the-fly without subjecting yourself to an entire recompile and reflash loop, I thought this was a more straightforward approach than (IMO) needlessly generating one entire .hex per layout.

Re: the layer 2 D key, it looks like you guessed right: 0x5C01 was what Ellipse had programmed to that key. I haven't messed with QMK debug mode though so not sure what to expect when it's pressed. It might also require CONSOLE_ENABLE to be DEFINEd during QMK build which I don't do for my Vial hexes, because not enough memory and/or available USB endpoints with all of the other features enabled. :cry: (darn you, ATmega32U2...)

By the way, in the future if you ever bork an existing default key assignment, you failed to take note of what it was first, and want to restore it, just save your work-in-progress existing layout to a .vil file & then either wipe the EEPROM (which will restore the default layout built into the firmware) or reload the correct .vil from my large 7zip package. Find the key in question, make a note of what it's mapped to, then reload your saved .vil back into your keyboard and set that key to the "right" value (assuming you care to after you find out what it was).

Finally, you are correct: Fn+Space+E should be EEPROM_ERASE, which is normally 0x5CDF. So I took a look, and it turns out that in my Vial builds, EEPROM_ERASE actually is 0x5CDE. So it still does what it should when you press it, but Vial shows a value for that key that you wouldn't expect (& had it been set to 0x5CDF would *not* have done an EEPROM wipe). This looks to be a VIA bug, and since Vial is built atop the QMK VIA (firmware-side) code, it inherited this bug. Looks like the problem is due to this #ifdef block nested inside the quantum_keycodes enum in quantum_keycodes.h:

Code: Select all

    MI_VEL_0,  // 5C92
#ifdef VIA_ENABLE
    MI_VEL_1 = MI_VEL_0,
#else
    MI_VEL_1,  // 5C93
#endif
    MI_VEL_2,   // 5C94
Since VIA_ENABLE causes MI_VEL_1 to = MI_VEL_0 which is 5C92, the numbering within the enum restarts at that point, causing all value assignments past that point to be off by 1. It's possible it has been fixed in later versions; I'd have to check. If not, best explanation is that probably nobody ever noticed since as long as one references either the enum names or C preprocessor constants rather than the raw values, everything still "works", and most people probably just keep their keymap exports to themselves rather than share them, or if they do share them they're likely sharing them with others who are running the same firmware on the same keyboard model that they are, so there would rarely be a problem.

Easy fix is just to make the value of MI_VEL_2 within the enum explicit:

Code: Select all

    MI_VEL_2 = 0x5C94,
...though of course if I fix this in future builds then I'll have to re-issue new .vils, and anybody loading .vils from either before or after the fix onto the opposite firmware won't have working EEPROM_RESET key (& possibly others!) until they go in and manually redefine them, heh.

Come to think of it...I wonder if this explains past issues with people running Vial & having trouble adjusting their solenoid settings with the Fn shortcuts. The haptic (HPT_xxx) keys would have been affected by this, so if they had loaded on Vial without clearing their EEPROM, and the key map from the previous firmware actually had the "correct" values for the haptic dwell time toggles in place...hmmmmm...

sedevidi

28 May 2022, 10:07

vpap wrote:
27 May 2022, 22:14
It seems like that the problems didn't stop as I had a problem with the Ctrl + A combination too, which seem to have been resolved, at least for now, after playing around with the A key spring the same way I did for the Alt key. Indeed it's a let down that these reliability issues persist and I really don't know if the springs are to blame here or something else regarding the sensing. The typing feel is the best I have ever experienced out of a keyboard, but you can't do serious work with it if you have to stop your work here and then to adjust springs. Let's hope that this will be the last problem that I will ever encounter with this keyboard.
I finally tested the USB3 port behind the dock, which was better than the nearby USB2 port, but not 100% OK, then yet another port on the computer, which is OK.
There is a USB audio dongle connected to the dock, which may introduce power supply noise...

So: carefully select the USB port you connect the keyboard to, or unplug everything else. I was aware of the potential problem, but didn't think it would be a real problem here, until I tried another port...

I'll also try to add a ferrite around the cable, within the keyboard or near the USB-A connector, if I manage to find a removable one collecting dust. I remember photos of Ellipse's cables with ferrite...

User avatar
Muirium
µ

28 May 2022, 11:51

I’ve used Xwhatsit hardware (which is the electronics in Ellipse’s Fs, too) for many years rock solid without any such instability, plugged into all manner of USB ports. The *only* time it’s fussy is when flashing new firmware: always go straight to host with that or it plain won’t let me flash it. And no I just use random USB cables, too.

The flakiness is coming from inside the house. I mean the keyboard! It’s not the USB side of the controller, it’s the capsense.

User avatar
thefarside

28 May 2022, 15:47

I’ve been holding off on asking because I haven’t fully read the manual but I am curious if it’s possible to use Xwhatsit instead of the default firmware.

NathanA

29 May 2022, 03:12

thefarside wrote:
28 May 2022, 15:47
I’ve been holding off on asking because I haven’t fully read the manual but I am curious if it’s possible to use Xwhatsit instead of the default firmware.
It's got an Xwhatsit controller on the inside...why wouldn't it be able to run Xwhatsit firmware? The QMK port to the Xwhatsit capsense controller did not even get underway until keyboards had already started to ship out to people. All keyboards that shipped out prior to August 2020 or thereabouts came with Xwhatsit firmware flashed to them "from the factory". So yes.

That said, there are a couple of minor differences between original Xwhatsit hardware design and the wcass redesign...namely, the row and column mapping is slightly different, and a resistor pack was removed in favor of utilizing internal pull-ups for the GPIO lines provided within the Atmel MCU itself. So you need to use the 0.9.3 version of the firmware, as the last 0.9.0 release from Xwhatsit himself is not 100% compatible.

sedevidi

29 May 2022, 17:42

Muirium wrote:
28 May 2022, 11:51
The flakiness is coming from inside the house. I mean the keyboard! It’s not the USB side of the controller, it’s the capsense.
Do you mean I should check for something related to sensing (say solder joints between the controller and the capsense PCB?), or is there some design issue on the F77/F62 which is not purely related to the xwhatsit controller?

The fact remains that the keyboard works fine on some USB ports, and less fine on others. The USB connection may not be the ultimate source of the problem, but is clearly related...

User avatar
Muirium
µ

29 May 2022, 17:58

I don’t have one of these boards so I don’t know.

I wrote what I can stand by: I’ve used 3 Xwhatsit controllers in IBMs for many years and they just do not behave like that. All three are rock solid on Pandrew’s QMK.

Ellipse

29 May 2022, 18:08

sedevidi have you tried another USB cable?

NathanA

29 May 2022, 18:53

Muirium wrote:
29 May 2022, 17:58
I don’t have one of these boards so I don’t know.

I wrote what I can stand by: I’ve used 3 Xwhatsit controllers in IBMs for many years and they just do not behave like that. All three are rock solid on Pandrew’s QMK.
I agree that something seems weird here, but then again I also happen to think it's weird that even you have problems communicating to the controller when its in DFU mode if it is going through a hub.

The other factor that is (to me) clearly different & which could be playing a part here is the difference in host itself. I know from past discussions that you use a Mac, and also that sedevidi does not. And Apple has generally been pretty good about giving every USB port within a machine feature and performance parity with each other...when they adopted USB3, for example, they didn't bother with this "some ports are USB2 and some other ports are USB3" stuff that a lot of PC vendors at the time did: every single USB port could negotiate USB3 rates. sedevidi clearly talked about how some of his USB ports are USB2 and others are USB3, and that the keyboard seems to work okay when plugged into the USB3 ones. Even if the details aren't yet clear, just the fact alone that there are different capabilities of the different ports tells us that they are wired up & implemented differently on the host side. And though the Atmel controller doesn't actually do USB3, it could be that there is something about however the PC vendor in question implemented the USB2 ports (max power output? grounding?) that the controller perhaps doesn't like...something that has absolutely nothing to do with USB speeds or protocols themselves, but something lower-level.

So though this is admittedly speculative on my part, it could very well be that if we took sedevidi's exact same keyboard and dropped it off at your door, that if you used it with all of the same computers you've used your original xwhatsit-populated boards with, that it would behave just as well for you & that you also wouldn't notice a problem.

User avatar
Muirium
µ

29 May 2022, 21:54

Possible.

Seeing as you’re focussing on USB ports, these are the ones which work with my Xwhatsit powered Kishsaver, 3278 beamspring and AT:
  • 2020 MacBook Air M1: both USB 4 ports with Apple’s USB A adapter, also CalDigit TS3+ Thunderbolt hub
  • 2013 MacBook Pro 15 inch: both internal USB 3 ports
  • 2006 Mac Mini: all 4 USB 2 ports
  • 2003 PowerBook G4: both USB 1.1 ports
Quite a spread of USB versions there! All of them run these boards just fine, beamspring solenoid included. Only the Air and Pro could flash the controller, however. I forget if I ever thought to try with the Core 2 Mini (still running Snow Leopard) but my PowerBook is PowerPC so… :lol:

Flashing works best when hooked straight to the Mac (with Apple’s adapter in my no USB A ports M1’s case). I think I may have successfully done it through the CalDigit Thunderbolt dock, too, but sometimes the controller isn’t visible in DFU mode on hubs. I’ve avoided it accordingly.

As I recall, the USB 3 hub in my Dell P2415Q never likes devices in DFU mode, not even Teensies. Feels like a hub chipset thing.

Ellipse

30 May 2022, 06:20

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.

In the coming weeks I expect the factory to start production on these. It may be possible to offer additional designs if there are any suggestions, but not sure yet. There may be a limit of designs so not all of the below designs may be produced.
LED overlays.jpg
LED overlays.jpg (312.8 KiB) Viewed 41004 times

pandrew

30 May 2022, 09:16

Ellipse wrote:
18 May 2022, 21:37
Since I am making a mold would any other keys be worth adding that have not been made before? I don't think the big PC AT enter key or code key would have enough interest to merit $1000 extra for the mold costs but it would be lower than having a completely separate mold.
I meant to respond to this a little sooner, I hope it's not too late, I have a couple ideas for things that are not available on the market, and I would like to see exist, but they're all very limited use, so they might not be worth it:
  • 1.33U keys, 3 variants: left-aligned stem, middle-aligned stem, and right-aligned stem. By left-aligned stem I mean the distance from the left edge of the key to the stem would be the exact same as for the standard LCtrl key. By right-aligned stem I mean the distance between the right-edge of the key and the stem would be the same as for the standard LAlt key. You could use these in place
    of standard Left-alt/Windows/Right-alt keys, in order to make the bottom row look more uniform, as on modern keyboards:
    modern_look_bottom_row.jpg
    modern_look_bottom_row.jpg (22.63 KiB) Viewed 40975 times
    I think this idea is the most likely to have enough buyers to be worth it.
  • 2.5U keys. Their use would be fairly limited, only for custom keyboards.
  • 0.75U keys (i.e. like normal 1U keys, but with a straight vertical slope, so they can be squeezed into very tight spaces. Make it the absolute smallest size that can still accept a normal size barrel. These would only be usable on the edges of custom keyboards, by cutting of the side wall of the bottom of the barrel, and allowing the other side to go out futher than the key goes out. These can't really be packed next to each other because they would then require a custom barrel, and custom flipper. (because standard barrel bottoms touch eachother) Again, extremely limited use.

Liopleus

30 May 2022, 12:59

Is it recommended to flash to newer version of VIA firmware when I don't have a problem with the current one?
I flashed my Model F to VIA last year and I saw the firmware note.

sedevidi

30 May 2022, 13:08

Ellipse wrote:
29 May 2022, 18:08
sedevidi have you tried another USB cable?
I do not own a spare USB-A-to-C cable... I may try with an USB-A-to-microUSB with an USB-C adapter though, if I can somehow manage to use the keyboard while open...

As a recap, I tested on the following ports on my Thinkpad T430 with my Mini Dock Plus Series 3 :
  • dock USB2, 2 hubs from the root, with mouse, phone and USB-audio : bad LeftCtrl, not good feeling overall
  • dock USB3, directly on the root hub : some glitches with LeftCtrl, good feeling
  • laptop USB2 yellow rear charging port : everything OK
  • laptop USB2 side port : everything OK
I didn't test on any other computer. I'm testing now without the USB-audio adapter (I just swaped audio and keyboard to keep them "away" from each other).

User avatar
Muirium
µ

30 May 2022, 14:08

sedevidi wrote:
30 May 2022, 13:08
  • bad LeftCtrl, not good feeling overall
  • some glitches with LeftCtrl, good feeling
Perplexed about what you mean by "feeling" when you say the board's flaky on them both.

I'd definitely try with another computer, too. Anything with USB will do. ;)

sedevidi

30 May 2022, 15:18

Muirium wrote:
30 May 2022, 14:08
Perplexed about what you mean by "feeling" when you say the board's flaky on them both.
The LeftCtrl is definitely the worst key, thus defines the flaky behaviour. Other keys feel like they do not registrer some times, or registrer a bit late: that's the feeling. Nothing definitive or clearly defined. LeftCtrl is the only key which I can really identify as OK/not OK, depending on the USB port... And ports provide various levels of feelings, from really bad, to somewhat OK, to really good.
Muirium wrote:
30 May 2022, 14:08
I'd definitely try with another computer, too. Anything with USB will do. ;)
My latest test is "swap keyboard and audio", and it seems to be OK up to now (keyboard on dock, USB audio on the laptop). So, it seems that this not-so-cheap chinese USB dongle introduce power supply noise, which, on top of the probable dock noise, makes the keyboard mis-behave. I have this USB audio dongle because the analog audio routing from the laptop through the dock, to the microphone jack, introduced a lot of analog noise that is not present when using the laptop's jack or laptop's microphones...

Ellipse

30 May 2022, 19:42

Here's the May project update - I have copied part of the first section from the update below.

https://www.modelfkeyboards.com/blog/

So far I have mailed out more than 1,000 Brand New Model F Keyboards since early April, which is more than half of the remaining backlog. We have about 850 keyboards remaining in the backlog. My expectation remains as before, that I can expect to move through the rest of the backlog in June and July. As noted before, it is not possible to project the timeline 100% based on last month’s progress as each order takes a different amount of time and orders with many individual extra keys will take much longer to process; many of the remaining orders are disproportionately ones that have such keys while the “all in stock” orders have been able to go out already.

This week another batch of the custom dye sublimated keys is arriving by express / air mail from the factory so many more orders will be “all in stock” and eligible to ship. The only remaining custom keys the factory is finishing up in the next couple weeks is the HHKB Front Print, Extras, SSK Num Pad, 4704, Terminal, and Ergodox sets.

Interest Check: Pad Printed New Model F Keys

I am reviewing samples for the pad printing with the plan to offer white text on black keys, which is a common request. If interested in black pad printed Model F / Model M keys please sign the interest form here to reserve your set: https://forms.gle/qnUATUrng8bX9Qxt8

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

I am looking into making a mold for the ISO Enter key (currently we are using Unicomp keys for this key as noted before, and they cannot make the additional colors for black and for gray and blue to match my project’s key colors). This would allow for key sets with ISO Enter to be made in additional project colors black, 60% dark gray, and Industrial SSK Blue. I will probably make the key non-stepped just like the other keys are all non-stepped.

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/

Since I am making a mold would any other keys be worth adding that have not been made before? I don’t think the big PC AT enter key or code key would have enough interest to merit $1000 extra for the mold costs but it would be lower than having a completely separate mold. Please post on the Deskthority project thread if you have any recommendations.

Major Project Milestone – 2 million dollars in orders!

Today we reached a major project milestone of 2 million dollars in Brand New Model F orders! It is very surprising to me that there has been so much interest in this project. This figure includes accessory orders and shipping costs.

Lagavulin

31 May 2022, 04:06

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!!

Post Reply

Return to “Group buys”