Modeling an F key mechanism

[DMA]

..looks like nobody makes decent-capacity pouch li-ion batteries smaller than ~35mm in width. Which means an airfield above F-keys - about 5 centimeters. 1000mAh battery should occupy space to the right of F12, which should allow for additional 12 (may be even 13, although I'm not a fan of double-barreled Esc) programmable keys.
OR, it can be used as a place to keep your pen, good old-fashioned style.
Any opinions?

Of course, the battery can be put under the keyboard block - but that opens whole new can of worms like cabling into the lower chamber and figuring out how to attach that lower chamber to the bottom plate in a way that won't be shorn off if somebody drops the keyboard from the table - let alone losing that 0 degrees slant capability (which can be quickly switched to more ergonomic negative slant when desired). Plus, that additional pedestal is additional manufacturing - and more complex manufacturing than two metal plates and a flat acrylic insert..

[DMA]

Figured out how to place double F-row _and_ antenna cutout (left) _and_ a battery (red).

double-f-row.png (42.19 KiB) Viewed 21605 times

Turns out, there are no standard sizes for li-poly pouch batteries - but 10x34x50mm is pretty close to standard for 2000mAh, and 2000 mAh should be enough for probably 3 hours of full-bore LEDs (2x IS31FL3743 (18x20mA each) = 720mA) or probably 100 hours with LEDs off.

[Muirium]

That’s a Big Boy! What’s the weight looking like?

With that much space on top, you might as well throw in some twiddlers, as are all the fashion now. Maybe a pair of proper vintage analog VU meters, too. Well, that’s just me; wishcasting.

[thefarside]

Looks great! I’m curious if there’s a possibility for a ridge to use as a pen holder at the top.

[DMA]

That’s a Big Boy! What’s the weight looking like?

weight should be around 1.5-2 kg. It's also not that big - something like 380x180mm.

With that much space on top, you might as well throw in some twiddlers, as are all the fashion now.

What are "twiddlers"? Rotary encoders? I'm not convinced of their utility. Sure, one can be volume (although.. why?), but more than one..

Maybe a pair of proper vintage analog VU meters, too. Well, that’s just me; wishcasting.

analog VU meters showing what, exactly? The main problem with all these steampunky shit is that it's utterly useless (plus it will require drivers - custom drivers for every OS, plus an application sending that data to those meters).

[DMA]

Looks great! I’m curious if there’s a possibility for a ridge to use as a pen holder at the top.

yeah, that's pretty easy actually - something like 5x5mm bar with 2-3 threaded blind holes in it, plus matching holes in the top plate. (pen holder without a ridge is pretty useless, actually - will interfere with top row)

[Muirium]

analog VU meters showing what, exactly? The main problem with all these steampunky shit is that it's utterly useless (plus it will require drivers - custom drivers for every OS, plus an application sending that data to those meters).

Mere wishcasting, but the way I’d do it is with an analog audio input on the keyboard, right beside the USB / charging socket, and make them bone fide stereo VU meters. No need to worry about OS and drivers that way, analog is eternal.

As for twiddlers: more than one can be quite useful for those of us into music composition. They can be bound to all manner of things in a DAW. Might as well give the extra land a purpose.

I’ll admit it’s the flurry of box-grouped keys you’ve just put on top that’s reminded me of a controller keyboard and kicked my mind into synth mode.

Spoiler:

[DMA]

As for twiddlers: more than one can be quite useful for those of us into music composition. They can be bound to all manner of things in a DAW. Might as well give the extra land a purpose.

Ceci n'est pas une keyboard - I think Ableton fully covers that particular area (and also requires a hefty driver pack)

[Muirium]

I believe it’s all done over the basic USB MIDI interface, as USBHID was made back in the enlightened and optimistic age when open seemed to be the future! Oh, those were the days.

A friend’s M-audio controller keyboard works well on my M1 Mac with no drivers and even iOS where drivers are completely forbidden. So this USB support for very many literal knobs and metaphorical whistles is still the case, thankfully.

Apple hates drivers just as much as you do, albeit for different reasons. They killed absolutely every single last remaining one of them on Mac with the end of 32-bit support a few years ago. No backwards compatibility, no migration path, just a big “Fuck you, designed by Apple in California”. I never liked Rando third-party drivers either, especially back on the windows 32-bit era when I came over. Abandoned drivers are the cause of so many Blue Screens and resulting e-waste. Adopt the open industry standard or go home. Logitech: I’m looking at you!

[thefarside]

You know what would be cool (probably only to me) would be programmable LEDs. It would be neat to program them to convey signal level as a heat graph or show persistence after a key press like an o-scope after a trigger. No clue if and how this is done. Does QMK or other open firmware have hooks or APIs for LED control? I’ve never owned a LED board but it would be cool to customize it.

I was also curious what your plans were for the flipper springs. It seems like the Model F springs were different than Model M and a mystery on the specs. I thought ellipse said he had to do materials analysis to resolve the spring type and I’m not sure if he’d be willing to share the specs.

[Muirium]

A glowing heat map is more interesting in theory than in practice. I once had a Ducky Shine 3 which had individually addressable LEDs in its MX switches back when that was novel. Among its modes was one which would light on key press and fade after a few seconds, which you yourself could alter with keys. Its longest setting was maybe 5 seconds. I’d have preferred much longer. But then again, the strobing of the LED matrix was all too visible with different brightnesses on view (all driven by flickering PWM) that I couldn’t stand it for long anyways.

It was, however, fun though.

Improvements I wanted when I tried it:

• Longer fade time
• Fading to a low level of illumination, rather than all the way to black
• Rarely used keys are the ones which need visible legends the most! So don’t let them all lie dark
• A persistent heat map which logs the frequency you press all keys, using that—sampled over the whole time you use the keyboard—as the rest state for all the individual keys, letting them fade from high down to that per-key rest state: an actual heat map rather than an echo of immediately pressed keys
• Far, far less flicker
• Storing the user’s preferences, and ideally heatmap, when disconnected

Implementing a game of Whack a Mole would be fun, too. The board could use its alpha block as a low resolution display to spell out your reaction time and score.

[thefarside]

That sounds awesome! I could see it being a novelty but I like that kind of stuff. I’m starting to see why people like RGB keyboards.

[DMA]

I believe it’s all done over the basic USB MIDI interface, as USBHID was made back in the enlightened and optimistic age when open seemed to be the future! Oh, those were the days.

But it's not like you can do much with that USB MIDI interface outside of specific programs that understand MIDI. OS itself won't even treat those MIDI controls as a system volume knob, let alone something more substantial.
And that's what I mean by "drivers". Plus, I have some experience talking to those musicians - they are a stubborn bunch, if you're not M-Audio or Ableton - they won't buy anything from you, because they value Reliability and Reputation
And we're only talking about _input_ here - try _outputting_ something to the keyboard, and you'll quickly find yourself writing a companion tray app

Abandoned drivers are the cause of so many Blue Screens and resulting e-waste.

Well, the thing about "no third-party drivers" is mostly a result of industry using standard comms nowadays. Everything has an USB plug nowadays - I've heard that firewire is kinda still alive, but haven't seen a physical device with a firewire socket for a long time.

In other news - it looks like barrels can be formed from metal: https://www.youtube.com/watch?v=pI48FEdkQv8
I guess flippers can also be made this way - but I'm worried about PCB longevity and SCRATCHING SOUNDS.

[DMA]

You know what would be cool (probably only to me) would be programmable LEDs. It would be neat to program them to convey signal level as a heat graph or show persistence after a key press like an o-scope after a trigger. No clue if and how this is done. Does QMK or other open firmware have hooks or APIs for LED control? I’ve never owned a LED board but it would be cool to customize it.

I was also curious what your plans were for the flipper springs. It seems like the Model F springs were different than Model M and a mystery on the specs. I thought ellipse said he had to do materials analysis to resolve the spring type and I’m not sure if he’d be willing to share the specs.

Well, HaaTa's kiibohd controller actually supports a lot of programmability for LED animations.
Also, I've heard that Windows 11 supports HID LampArray out of the box nowadays - but no way in hell I'm installing that adware crap to check. I'll rather wait for Windows 12 - where they'll surely roll back all the madness and make something sensible instead. I'm pretty sure it will be that way - just look at huge fuckups that Vista and Windows 8 were - followed by Windows 7 and 10 which were pretty much usable. (but whoever made the start button not in the corner of a screen.. we should make public hangings a thing again just for that guy - and watching the video of that particular execution should be part of mandatory yearly training for every UI/UX designer.)

Re: heatmaps - it's A LOT of programming labor, A LOT of flash endurance burned to persist the state, A WHOLE LOT of whining from Privacy Advocates (basically, you're implementing a keylogger right there - while also, if you're unlucky and work in a company which doesn't provide you with a yubikey, revealing your password in literally GLOWING LETTERS), and also, if anything, the backlight should be _darker_ for more frequently-used keys - because those are exactly the keys you have the best muscle memory for.

Seriously though - flicker shouldn't be a problem anymore (I hope I'll have a chance to see current state of the art next week), longer fade time and fading-to-default-level-not-black are pretty valid points and I'll try not to forget about those.
tbh, the part of programming the animations raises some serious disgust in me currently - but I kinda want to have hardware anyway, even if it won't be supported from the start (well, not completely unsupported - whole-field backlight color and brightness, plus fading light echo will be supported, but no animation editor and no persistent heatmaps). Like, if I was able to live off it, I would've definitely ended doing it, but it's quite unlikely this will provide enough income to support my current, quite expensive lifestyle (main part of that lifestyle is, sadly, mortgage payments).

[Muirium]

Indeed!

Are you considering RGB LEDs, by the way? I could see user 'programmable' groups of different colours / brightness for static backlights in different keyboard regions as a legitimate use-case for those; and a nice complement to various colorways in caps.

The only OMG LOOKIT THIS! feature I can think of besides heatmaps is using the whole keyboard as a goofy, low-res display for scrolling text—like SPELLING OUT YOUR PASSWORD SO BIG THE WHOLE ROOM CAN SEE IT—or, perhaps more usefully, battery state on request and firmware version number etc. It's nice to have a way to give feedback to the user, in a pinch.

[DMA]

Indeed!

Are you considering RGB LEDs, by the way? I could see user 'programmable' groups of different colours / brightness for static backlights in different keyboard regions as a legitimate use-case for those; and a nice complement to various colorways in caps.

Of course those will be RGB LEDs. No "keyboard regions" tho - it will be a mess. The purpose of LEDs is to light the legends (and small area around the keyboard) in the dark.

The only OMG LOOKIT THIS! feature I can think of besides heatmaps is using the whole keyboard as a goofy, low-res display for scrolling text—like SPELLING OUT YOUR PASSWORD SO BIG THE WHOLE ROOM CAN SEE IT—or, perhaps more usefully, battery state on request and firmware version number etc. It's nice to have a way to give feedback to the user, in a pinch.

Firmware version number is useless in practice (why would anybody even care? Firmware version exists in two states - "good enough" and "upgrade to latest version immediately" - both of which don't require knowing exact version), battery state is unobtainable (because there are only two states - normal and "battery low"). Again, a lot of effort for no practical result (which is not even fun). Keyboard is an _input_ device, not output. For output, you have display.

[Muirium]

I have also long been an advocate for custom firmwares to output diagnostic info, including battery level, via text output into the host. Strangely absent feature.

[DMA]

I have also long been an advocate for custom firmwares to output diagnostic info, including battery level, via text output into the host. Strangely absent feature.

this is a feature nobody needs. HaaTa's controller, if you enable debug, provides a serial port console (which is a better alternative for these things). My controller communicates firmware version (among other things) to the configurator program (which then shows those parameters in a nice way).
Diagnostic info is rarely needed - the fact that you insist on it's being needed is a testament to abysmal quality of firmwares you have to use - when things just work, what's the point of knowing firmware version?
Battery level is a bit different - but, at least with Li-ion chemistry, it's not really possible to tell how much energy is left in the battery. The only thing that you _can_ tell is "we're below 10%". The rest is dark arts of estimation (there are specialized chips that measure charge going into and out of the battery, but it's all very approximate (and as battery ages it becomes worse), plus those chips are quite expensive). But due to the only actionable output from battery state is "plug it in, or else" (because keyboard isn't a standalone device, and host can always charge it) - battery level output beyond "LOW BATT" LED is useless in practice.

On why this info is absent - nobody wants people to accidentally trip this diagnostic output in the middle of a game and then being mad at the firmware developer (and OF COURSE it's the firmware developers' fault)

[Muirium]

the fact that you insist on it's being needed is a testament to abysmal quality of firmwares you have to use

Nope. Just looking for a whimsical, glitzy purpose for the LED matrix. As back lights they are entirely pointless to me. They restrict you to inferior caps, and the lighting is crap, as it is in quite the wrong position.

[DMA]

the fact that you insist on it's being needed is a testament to abysmal quality of firmwares you have to use

Nope. Just looking for a whimsical, glitzy purpose for the LED matrix. As back lights they are entirely pointless to me. They restrict you to inferior caps, and the lighting is crap, as it is in quite the wrong position.

How exactly they restrict you to the inferior caps? If you have completely opaque keycaps, you'll only see key outlines highlighted, but nothing prevents you from using those.

And what is "the right position" for the LEDs? LED above the barrel is exactly where notebooks have them, and you seem to like those. Sure, there are "south-mounted" LEDs, and those are horrible because they directly shine towards you between the lower row keys. But it's not the case here.

[Muirium]

Useful enough, for learner typists / obscure media keys.



Lame.

[Findecanor]

Does QMK or other open firmware have hooks or APIs for LED control? I’ve never owned a LED board but it would be cool to customize it.

I haven't followed QMK's source code for a few years, but there used to be several instances for specific LED driver chips. The QMK firmware for the Input.Club K-Type was one with individually addressable RGB LEDs.

I once started to hand-wire a keyboard that I intended to drive with addressable LEDs and custom firmware, not through a driver chip but by bit-banging GPIO pins. (But I instead bought a PCB which didn't have them individually addressable). The keycaps were thin ABS, so each LED would illuminate the entire key.
I wanted only two effects:
• The number row would light up in three groups of four when holding Fn, to indicate groups of F-keys.
• After a period of inactivity, it would have a scrolling text message on the four alphanumeric rows. I think that if it scrolled fast enough and the rows got updated with a slight delay between them then that would compensate for the rows being staggered.

[DMA]

Lame.

Ah, that's what you were talking about. Those keycaps are so twentieth century. We have https://vortexgear.store/products/oem-d ... ranslucent nowadays, those are shine-thru.
Technically, nothing prevented authors of your keycaps to pour transclusent PBT instead of black for the legends - but that required some forward thinking, and there's a global shortage of that since September 1993.

[Muirium]

They’re actually these: Round 5. You may have seen them in DT’s header once or twice.



They’re much nicer caps than the Vortex ones you linked. But they’re so exxtra that they render all attempts at backlighting entirely moot.

[DMA]

They’re much nicer caps than the Vortex ones you linked. But they’re so exxtra that they render all attempts at backlighting entirely moot.

Well, if by "nicer" you mean "thicker" - then sure, backlight isn't an option. Also it's kinda stupid for backlighted keys to have black legends. And if "nice" means "thicc" - then those notebook keys are merde de la merde

[DMA]

..looks like it's mass drop-dead season among the keyboard-producing companies.
Which means I'm probably will not be actually making anything.

OTOH I've got the job - so may be a super-limited run of like 50-100 devices, hand-assembled by me (except PCBs - those will be PCBA'd, I'm not soldering 100+ RGB diodes per device!), at cost (which will likely be _huge_ due to low quantity produced)

[NathanA]

Firmware version number is useless in practice (why would anybody even care? Firmware version exists in two states - "good enough" and "upgrade to latest version immediately" - both of which don't require knowing exact version),

Can't quite tell if you are pooh-pooh-ing the idea of versioning firmware and/or ever exposing the version to the user/owner, or just the idea of having the keyboard directly display or "output" it to the user.

If the latter, completely understandable.

If the former, however, then hard disagree here. The number of times I have been screwed over by bad software & regressions that get introduced after an "upgrade" is not insubstantial. To the point where these days I try to make sure as often as is reasonably possible that I have a copy of an old, known working version -- plus a means to be able to utilize that copy / back-level down to it again -- in the event that the "new and improved" version proves to be anything but.

This naturally requires that I, the user, actually know what the version numbers are. Both so that I can know what is proven to work for me before potentially abandoning it, in order that I might be able to return back to it again later, as well as so that I can know what crap to avoid moving forward. Thus I actually very much DO want to be informed about the version number of the "good enough" one I'm currently running even though it is "good enough". It is not the case that "ignorance is bliss" as long as things are working well. Awareness and vigilance are required in order to KEEP things in that happy state.

It is also very often not acceptable to simply report a bug and then wait for the next "latest" version to come out that fixes it, especially if it is a showstopper and it could take months for an actual fix to be delivered. I really really despise this modern mentality to just immediately accept the latest software updates without giving it any thought, especially with (often) absolutely zero way to undo or roll back (especially especially when older versions get pulled down & made unavailable as soon as the newest is posted!). Sure, the "rolling release" / constant pushing to prod strategy might be great for developers as they get instant feedback and don't have to actively support hoards of older releases, but I contend that it is miserable for actual end-users.

the fact that you insist on it's being needed is a testament to abysmal quality of firmwares you have to use

CORRECT.

You might say that you in particular work hard to make sure that you release quality software/firmware. Or you might even make the grandiose claim that anybody using the software you write will never ever feel a need to downgrade their copy at any point. You might even be objectively correct about your claim...it's absolutely conceivable that you might genuinely be the best, most careful and conscientious software engineer on planet Earth.

Still, you'll pardon me if I don't take your word for it. And it's not personal. It's just experience talking.

Apple hates drivers just as much as you do, albeit for different reasons. They killed absolutely every single last remaining one of them on Mac [...]

I'm sure you understand this, but just in case & for any passers-by out there, this urban myth being perpetuated (not necessarily by you, but I see it out there from time to time) that Apple's platforms no longer use "drivers", drives (heh) me nuts. Of course they still use drivers. You need to have some way of interfacing hardware with software and providing a layer of abstraction between them. What do you think a "kext" (kernel extension) is? They just only bundle & ship first-party ones that they have vetted/certified/approved themselves; it's only third-party ones that they no longer allow (at least without jumping through tons of hoops). They can get away with this because 1) they largely control the whole enchilada these days of their own machines, so the need to install a third-party driver for e.g. a different video adapter or WiFi chipset is virtually gone, and 2) to your point, there are many standard ways of interfacing certain classes of hardware devices over common busses like USB, most of which are already natively supported by the drivers bundled with the host OS/platform.

(I don't know that they are looking to do this, but even if Apple completely eliminated the "kernel extension" as a thing, and started statically linking all of their first-party driver support code to a monolithic kernel binary, old-school style, that still wouldn't mean that they had eliminated "drivers". They just simply would no longer exist as separate files on the filesystem. Now, what would be potentially more interesting is if they managed to come up with some performant model that would allow the implementation of any arbitrary hardware/software interface [...driver...] such that all of them could run in userspace without any downsides. I'm sure that their main concern here isn't with forcing everybody to use already established USB device classes or whatever, but is rather about protecting the kernel's memory space, both from a stability and security perspective. Though I suppose even a user-space driver-like thing could be coded poorly/inefficiently and do nasty things like consume gobs of CPU, which they'd also not be keen on.)

However, the points in their favor that allow them to get away with this don't completely eliminate some of the edge-cases that exist. What if somebody builds a hardware device that does something that some standards-body hasn't anticipated in advance? That is, it doesn't fit into any of the existing and common hardware device "classes"? Most Macs these days might not have an internal PCIe expansion slot, but Thunderbolt is a thing, and it's essentially external PCIe. What is a hardware vendor that comes up with some killer new idea which requires a bus with PCIe-esque throughput for it to be successfully implemented supposed to do? Wait for some international standards bureaucracy to recognize it, and then after that happens, wait until all of the popular (and even not-so-popular) platforms out there support the newly-ratified standard? I also think it's not uncommon for at least certain broad classes of devices -- say, for example, network interfaces like USB ethernet dongles -- to not merely implement the least-common-denominator USB CDC protocol(s) & instead do their own thing (likely for performance reasons), which of course requires that the host either allow you to side-load a driver, or have native, built-in support for the chip(set) being used in said device.

[DMA]

If the former, however, then hard disagree here. The number of times I have been screwed over by bad software & regressions that get introduced after an "upgrade" is not insubstantial.

My point exactly - never upgrade unless you absolutely need to - every new major version is downhill, every upgrade is "upgrade" at best. Things aren't broken for you? DO NOT TRY TO FIX THEM.
Which doesn't require you to know exact firmware version, because you can tell immediately if things are broken or not FOR YOU without knowing or caring for firmware version.

It is not the case that "ignorance is bliss" as long as things are working well. Awareness and vigilance are required in order to KEEP things in that happy state.

Not unless the particular user mindlessly upgrades to the "latest version". If something is working for your particular combination of firmware, software and your personal neural network serttings - don't touch any knobs, you'll only make it worse

It is also very often not acceptable to simply report a bug and then wait for the next "latest" version to come out that fixes it

reporting bugs is pointless, I've never seen a real person reporting a bug in commercial software which was fixed. Yes, defect might not be present in the next version - but nobody has any proof proof of a causal relationships between the two facts. I've seen couple cases of paid enterprise hardware support fixing firmware bugs, but that's about it.

You might say that you in particular work hard to make sure that you release quality software/firmware.

I might, but that would be a lie.

Or you might even make the grandiose claim that anybody using the software you write will never ever feel a need to downgrade their copy at any point.

That claim I do periodically make, but this isn't because I work hard to make sure downgrades won't be needed or software quality. It's because I don't give a fuck about maintaining old versions - if they were good, there won't be a new version, would it? But the fact that old version is, in general, "not good", doesn't mean it's not fit for the purpose. Like when I had to add support for pedals - this led to eeprom layout change and so I had to bump major version. But for all the preexisting keyboards (all 10, or may be whopping 15 of them) previous version is totally fine. Now if there's a bug discovered that breaks something in one of those previous keyboards - I might fix it if I have time, but I'm not going to backport anything - if you badly want the fix, you have the motivation to upgrade, if not - you probably don't have motivation to even reflash. People are SURPRISINGLY lazy about their software updates - except like five in the world (unfortunately including me) who keep things updated proactively.

[Muirium]

But the new features, man. I don’t wanna be left out in the cold! Update.