I get quite frustrated with the unimaginative and clumsy design of keyboards. The standard layouts, lack of several features that should be there, the ridiculously huge size, slow scan rates many have (that limit typing speed), using wired or wireless but never the option of both, not universally being usable as bluetooth peripherals for multiple computers including tablets, not being open-hardware designs that allow customer extension, short operating lifetimes, liquid spill susceptibility, key legends wearing off, key backlighting done wrong, and many other shortcomings.
One of my most unfinished project stacks, has a custom keyboard development as a sub-component. If any of it ever gets finished, it will be all open source and freeware. I'm not mentioning the names I use for the component parts, in case it ever actually progresses to being worthy of release. The stack is like this:
A fairly radical extension of ASCII, to include multiple modern information processing concepts that ASCII lacks. An absence that necessitates all kinds of kludges, work-arounds and flat-out fuck-ups, that most people either don't perceive at all or just accept as 'the way things are.'
An experimental OS and hardware architecture, incorporating several new concepts including integration of that extended ASCII.
(Born of my hatred of Bill Gates/MS and what they did to PC-OS evolution, dismay at what Apple became after a fine early start, and despair at the Unix-Linux experiment in million-monkey development model.)
An experimental GUI, for that OS. (The GUI is an application, NOT a deeply entangled OS component.)
A physical keyboard. The design both integrates all the features required for the above, and also is my 'dream keyboard'. It's intended to be suitable for both commercial manufacture, and home construction using 3D printer and small scale PCB manufacture.
Part of the development of that keyboard is a virtual keyboard, to let me play around with the layout and codes stream generation. Necessary since the underlying target coding is an ASCII extension that existing keyboards cannot support.
Some kind of functioning keyboard and the coding it allows typing, are required for further stages of the OS & GUI development. Then the key layout etc would need to be flexible as the whole project group evolves. Hence doing a virtual one initially.
Pic attached is an early stage of the virtual keyboard. It's not 'alive' yet. Just constructing a html/js framework to support a flexible layout. Last work I did on it was getting html custom font loading working, for custom key legends. There's a lot still to do on the basic visual presentation. Properly stretched keys, fascia outlining around keys, and so on. And the layout you see is just based on existing keyboards, and does not incorporate any of the variations I'd be doing later to support the rest of the project.
As for a physical version, I've been putting a lot of thought into it. The aim is a design that allows for 'forever' functionality. Lifetime of user, can be passed down to descendents, etc. This means long life components, and also ability to replace any parts that break or wear out. Complete replaceability of electronics, external interfaces, etc. Open source code & hardware.
Keytops have to be two-part plastic so the legend can never wear off. For back-illuminated keys, that's necessary anyway. I'm hoping such keytops are achievable with 3D printers as well as commercial injection molding.
The key mechanisms have to be robust and give that nice tactile 'click', but the audible click has to be an option that can be turned on/off, and adjusted in level and sound. So, silent keys plus a software generated sound via a transducer. keys have to be dust and liquid proof, and completely immune to intermittent faults. That means no mechanical electrical contacts.
The key mechanism must support key-hold-release sensing and would be nice if it allowed for analog encoding of key depression depth and stroke velocity, as a dynamic option. Useful for some types of user interfaces, eg music, machine control, gaming, etc. It must also be FAST, so there's no chance of slow keyboard scan rates producing user-perceptible keystroke order errors.
The key structure has to allow for back illumination, preferably by RGB LEDs for full color control. The entire back of the keytop must be illuminated, to avoid the problem of parts of the key legend not being illuminated. This means the illuminator must be in the centerline of the key structure.
Sensing types I'm considering include:
* Dielectric sensing, like in the early IBM clicky. But this probably requires some form of flapper plate, in addition to the key plunger. Has excess moving parts and can't be silent. Not a favorite. Also, EM emissions?
* Hall effect sensor, small magnet on plunger. Also not a favorite due to the need to buy the hall sensors, and their potential to become unavailable.
* Inductance variation in coil. Fixed coil, plunger has a shorted turn or slug, control circuit monitors inductance or resonant frequency of the coil. I like this because it's dust-immune and worst case the coils could be home made/replaced. Potentially allows for stroke depth & velocity capture. I'm a bit worried about potential EM emission problems with this method. There's also the issue of remote EM eavesdropping.
* Optical sensing. Key plunger has a vane that interrupts a light path. Could possibly be integrated with the keytop back-illumination though variable brightness control may cause problems. It also relies on commercial availability of LEDs and photodetectors. But that doesn't seem a big ask. This is my current favorite.
The overall physical structure would be:
* Flat thick steel backplate, with no folds, just a few screw holes. Gives weight and strength. Easily home made. It's tilted slightly, giving space for the control PCB and external connector(s) underneath and along rear edge. Ditto small battery compartment. Battery to be replaceable lithium, preferably an 18650 for long operating time on battery, and quick change when needed.
* Profiling supports, 3D printed plastic. These provide the front keytop curvature for the key layout. Mount to the steel backplate with a few self-tap screws. The top surface supports the identical key mechanisms and flex PCB key interconnects (or even hand wired point-to-point, if at all possible.) They are modular for each key row/group, allowing flexible key arrangements.
* Key plunger and body. I'm not sure 3D printing and materials can achieve the durability, precision and surface smoothness necessary for nice-feeling and long-wearing key plungers. Maybe the sliding mechanism would have to be injection molded? We'll see.
Anyway, all identical. The key click would be built into this part. Not sure of a method yet. It would be nice if it could use the exact same flat springs as in those old HP buckling spring switches, since that would also provide a permanent source of those springs to repair old HP gear, ha ha.
The central axis must be open, for backlighting the keytops. Clip-on of the keytops therefore must be a ring structure with central opening. Which is good since it's easy to make that very robust, as opposed to stupid little posts that can break off. It also helps with the 'wide' keys like Enter.
There has to be facility for a leveling torsion bar, for very wide keys like space-bar. Though that can be mounted by clips on the rear of the keytop, without involving the key plunger.
The key mech bodies clip or screw onto the 3D-printed profiling support frames. Individual key mechs must be replaceable from the front, without disassembly of the entire keyboard. Removal of the key mechanical structure exposes the sensors attached to the PCB, where they can be replaced from the front. Ie surface mount.
* Spill/dust protection membrane (optional.) Fits over the key base structure. Molded silicone sheet with upward necks sealing around the fixed key-mech bodies, under key tops. Provides a liquid drain path. Can be easily peeled off, replaced.
* Outer shell. Pretty standard. For early development I wouldn't even bother. But if I did one, it would have NO LOGOS.
Sadly, at the rate I'm going and how this keeps getting shoved down the queue by other urgent chores, I can't see it happening any time soon. So this post is just a 'wouldn't it be nice, if...' sort of thing.
Home
Help
Search
Login
Register
