As much as I love my Happy Hacking Keyboard, and other smaller keyboards - especially the 40% keyboard by ne0phyte at http://deskthority.net/workshop-f7/thkb-tiny-hacking-keyboard-40-t6455.html - I've always had a soft spot for one handed keyboards. As no one hand keyboards fully meet my requirements I decided to have a go at building my own. I started this thread to prevent me from hijacking other threads with my design.

The OneHand is a 20% keyboard designed to be used with either the left or right hands, while the other hand is operating a mouse. To minimize the number of keys each finger would need to use to perform all the functions of a standard keyboard the OneHand would use a system if chords and modes. It is also intended for two units to work together as a split keyboard.

Background

Typical chording keyboards use as few keys as possible to perform the function of the typical 104 key keyboard. This involves multiple finger chords which can be difficult to perform. To reduce the number of keys needing to be passed at one time, additional keys could be added to the OneHand keyboard. This reduces the number of keys needing to be pressed for the more obscure functions. The basis of the keyboard is the five keys microwriter used, one under each of the fingers and thumb.

It was initially thought that adding two keys for each of the three main fingers would make the keyboard more flexible. Another driving factor with the design was to make the keyboard usable by either hand. This led to a symmetrical arrangement.

I purchased a number of Cherry MX key caps to test out the arrangement. After resting my hand on the keyboard, I realized that adding another row above the primary keys would not impact the usability of the keyboard while allowing more single key characters.

When looking at entering numbers it would be advantageous to have an arrangement similar to a numeric keypad. I then added another row of key at the bottom to provide a number pad arrangement.

The main issue is going to be remembering how to select and enter the various types of punctuation. I therefore decided to implement modes via a combination of the thumb key and the five top keys. To provide mode feedback I decided to add LEDs to the top keys as a mode indicator.

Using eighteen keys for the keyboard reduces the number of combinations needed to enter the most important characters. It is possible to use a single button, in conjunction with a single modifier key (thumb) to enter all characters of the alphabet.

The modified qwerty arrangement is obviously not the best arrangement of keys, as some of the primary keys are used for the less common characters. I am therefore going to implement an optimized character arrangement once the hardware is finalized. This arrangement would also use the simpler multi-key chords to position the more common character pairs in close proximity.

Hardware

For the initial design I decided to create a PCB to hold the Cherry MX key switches in the required arrangement, and also mount a Teensy controller underneath. The board is less than 10cm by 10cm, as this was the limit for me to get cheap prototype PCBs.

The Teensy has sufficient inputs and outputs to allow each key to have its own dedicated input, and each LED to have an output. This significantly simplifies the track layout, and I decided to place the keys based on the Teensy pin layout to remove the need for vias or long traces.

While designing the PCB I added the option to have up to two additional double height keys inside the thumb keys

I have just finished the PCB design for the first prototype, and I have placed an order for 10 samples, and I'm going to experiment with different MX colors while I wait for the PCBs.

Once I've tested the arrangement, and finished the initial software, I'm going to replace the Teensy with an embedded microcontroller to allow the keyboard to be mounted lower to the desk.

The keycaps I'm using were bought from WASDkeyboards.com, and uses Row 1, 2, 3 and 4 for each row of keys, and two number pad Enter keys for the thumb keys. This provides a nice shape to the keyboard, and a useful ridge between the primary chording keys and the upper keys.

Edit: One interesting aspect is that the keyboard will work very well with my Nexus 7 in a portrait mode, as shown in the image above. This uses a simple USB OTG adapter cable to communicate with the Teensy.

Hopefully, I'll have the PCB in a couple of weeks (depeinding on shipping time), at which point I'll post an update.

Findecanor wrote:Whoa. That location of the Teensy is mind-blowing. I had to bring out a Teensy and a switch just to see for myself that it would work.Very interesting project.

Thanks. It took a bit of checking to see if the Teensy would fit, and assembly will have to be in the correct order!

The main concern I have is that with the Teensy mounted below, how high will the keyboard be off the desk.

Here's a picture of a dual TwoHand keyboard, which would probably get away without needing too many modes to generate all the key codes.

I'm going to see if I can use the couple of spare pins to link the two Teensy's together. It should be possible to use serial TX, RX, Vcc & Gnd to link the two halves together and allow a single USB connection to the PC.

ne0phyte wrote:Nice! Especially the Teensy mounting - I planned to do the same but I didn't check yet whether it would fit Great to see it does.

I just made a slight change to the design before pulling the trigger on the PCB. I lowered the Teensy a teensy bit to make the two middle pins split the two keys correcly, and I also added a serial connector to allow a second unit to be powered and communicate via a wired connection to the first without needing another USB link.

I see you don't use a matrix but one pin for each key and the ground : Why this choice ?

Nice work : it's the kind of thing useful for a graphist or a CAD designerI think it lacks 4 mounting holes to screw it on a case or just for putting feet (a default shared with the Teensy but fixable in your PCB)

Vierax wrote:I see you don't use a matrix but one pin for each key and the ground : Why this choice ?

Why not! A matrix is an unnecessary complication with this few switches. No need for diodes to achieve NKRO with direct connections, as there's no masking or ghosting possible when every switch has its very own pin. It should be simpler to program too.

Great project by the way, PJE. I'd think about a pointing device between both hands for the dual version, but perhaps you have already. Plus I like the idea of a Teensy on each hand. They could be used separately that way, and a serial connection is smarter than sharing a unified matrix over a bunch of wires.

Vierax wrote:I see you don't use a matrix but one pin for each key and the ground : Why this choice ?

Nice work : it's the kind of thing useful for a graphist or a CAD designerI think it lacks 4 mounting holes to screw it on a case or just for putting feet (a default shared with the Teensy but fixable in your PCB)

As Mu stated, a single key per pin makes the software much easier, and prevents ghosting/NKRO issues which are critical with a potentially chording keyboard. The only concern I have with my current arrangement is the slightly scatter shot pin to key arrangement to allow PWM on all the LEDs, and allowing access to the hardware UART.

I was just planning on sticking rubber feet on the bottom, but I took your advice and dropped on four holes as well. I'll use threaded PEM nuts in the holes to allow adjustment from one side, with a locknut, as getting to the key side will be a little awkward.

This reminds me of the Datahand modify/shift keys (thumb down). They have a unique feature of which I don't think there's an equivalent. If you press down but don't bottom out, it acts as a shift. For instance, shift to numbers mode. If you bottom out, it clicks and acts as lock, for example, it locks to number mode, until you go back to "normal" mode. Such a concept could be of great use to a one hand keyboard, not only for lock mode purposes. By distinguishing between half-way and all-the-way, you greatly increase the number of combinations with a limited number of keys.

Another alternative (or complementary) feature of chords is the dead key (as Compose or diacritic signs present in some layouts) allowing you a release in a tricky combination of keys. But it doesn't allow you to send following keycodes on this layer without a new deadkey press…

Interested to one board, I'm just running out of Teensy right now Is there any Teensy GB still open ?

Dead keys are pretty crafty. On the Mac, Option is just a regular modifier (equivalent to Alt) but it's also the way into a selection of dead keys for various diacritics:So press Option+U then hit a to get ä, Option+E + a to get á, and so on. I guess they're transient dead keys.

Webwit's description of the DataHand's union of shift and shift lock makes me wish Cherry did a variant of the MXLOCK with two levels of depression, to achieve exactly that. But there's nothing we can do with actual MX switches.

I'm interested in your leftovers, too! I've switches aplenty and even a few Teensies fresh in the mail.

I've been experimenting with the modes and alternate key switching, and I feel that I should be able to get to most characters in a reasonably understandable way without needing complex chords.

When I've finished my diagram I'll post it, but my current thought is thumb + top row to select modes as needed, and then single, dual and triple adjacent keys plus the thumb 'alternative' key to enter the characters. I'm restricting most keys to those combinations easily entered while keeping the fingers on the 'home row'.

Currently I'm thinking the thumb key does not need to be released as it merely switches between alternative character sets on the other keys, which will reduce finger movement.

Indeed, I like the balance you're striking between compactness and chording overload. Although extreme chording keyboards like the BAT have their charm, something like this has more slack built in which should make it easier to actually use. I use keyboard shortcuts all the time, I hate to think of the gymnastics I'd need to hit them on a highly chording keyboard.

Plus the multiple thumb keys look very promising along with the symmetry and independent operation you're bringing to the table. I'd have a thumb key for simulating the opposite hand, in mirror image like Matias uses the space bar on his one handed keyboard.

I've been working on the keyboard character layout, and I would like to be able to type alpha-numeric characters and basic cursor movement without needing special modes. Here's what I've come up with so far...

The thumb key is a temporary mode shift into numbers and cursor, while pressing the Mode button with I, T, L, or BS would switch modes. Pressing mode on its own would revert to standard. I've tried to keep the chording to the simpler chords, with few chords using the little finger.

I was thinking of having long presses on some keys to invoke shifted or alternative characters, but that may get a little difficult to manage.

Finally, Does anyone know of a good place to order MX keys and stabilizers? I'm looking for MX Red (MX1A-L1NW) or MX Blue (MX1A-E1NW) together with the G99-0742 PCB mount stabilizer. I can track down items at different vendors, but would prefer to place a single order.

I'm experiencing feature creep, and as such I'm looking at adding the option of Teensy 2 with the current functionality, or Teensy++ 2 to allow for an an Optical Finger Navigator Module - http://www.parallax.com/product/27903 - and possibly a small LCD...

The Teensy++ should drop onto the top pins of the Teensy, but provide many additional pins

As for reds vs. blues: 7bit sells every MX under the sun for a price I'm yet to see beat for new switches. Reds are coming back in stock "soon"…

Thanks for the heads up on MX Reds.

I'd decided to save the Teensy++ (or embedded microcontroller) for the Mk2 design before I read your post. There are too many differences in the pinout to simply drop one on top of the other.

One change I am looking to make is to see if I can use the TWI interface rather than the UART as the link between the two units as this would allow the optical finger mouse module to be connected... at least for initial testing. After I've looked into this one item I'm placing an order for the PCBs.

I've been testing out the 'typing' on my keycap simulator, and if the MX Reds work as hoped, typing should be quite easy to learn - especially compared to the CyKey chords. I may move some characters around to make typing simpler - but that's the advantage of a fully programmable keyboard!

The MK1 PCB Is finished. I swapped the two UART pins for the two TWI pins (plus pull up resistors) as the Teensy can be a master or slave on the TWI bus, and it allows multiple devices to share a common bus.

I'll be placing the order today... Now where can I get some MX Red switches quickly...

PJE

EDIT: PCBs and switches ordered... now the wait begins - I'm switching over to working on the software.

Well I've just found the first problem with the PCB - I accidentally used D6 which is mapped to the internal LED to an input! Looking at the PCB, I don't think it'll be too hard to modify to swap the D6 & D7 connections... For some reason all the diagrams I was referencing made no mention of it, and it was only when I looked at the schematic that I noticed it.

While I wait for my PCBs/Switches to arrive, I've written the first pass at the software, which I'm currently testing on my converted CyKey chording keyboard. It only has 7 keys rather than the 18 of the OneHand, so I can only type certain words like still and stall....

The way I wrote the code allows easy modification of the character codes output for each combination.

Each mode has standard and 'shifted' combinations, allowing more characters than I can use. I've implemented special characters - such as shift - via modifier keys triggered by non valid key codes (240..255 at present). The buttons are mapped onto three bytes - SwHi and SwLo for the main keys and SwMod for the two larger buttons. The SwHi & SwLo are matched against the first two binary numbers, and the SwMod is used to select between the two options for each mode, with the mode variable selecting which of the three (at present) sets to use.

The software is currently using only a small amount of the Teensy's memory, so I'm looking at what macro features I can incorporate..

I'd definitely go for macros if you can spare it. Macros and layers are the reason every keyboard needs logic like Soarer's converter. Repetitive strain is best given to the silicon to do!

i agree, macros are extremely useful - I'm not sure how I'll implement them - I have to initial options - first to simply store them in a table within the code, and the other would be to use the 1K EEPROM to store the table, which would allow for on-keyboard setting of the macros. The built-in table is much easier - but would require the programming suite to modify...

I'm currently working on a reliable way to leave the thumb key down for multiple consecutive chords, to make typing less tiring.

Smart thumb locking makes sense. Because you're defining your own chording layout, you can disambiguate them without confusion. A contrasting trick I want to use sometime on a regular keyboard (with custom controller) is to embed ESDF (or some other pattern) as arrow keys, which trigger on a quick tap and hold. It's harder because of the ambiguous input: does the user want a second e, a string of es, or to go up? I'll need to tune some heuristics.

As for programmability without recompilation, Soarer uses the EEPROM to store a table, which is accessible via command line tools. This is a good step better than having to rebuild, but not as advanced as being able to program new remaps and sequences directly on the board itself. There are various implementations out there of just that. A simple one in current production is the Ducky Mini which has a Pn key for recording and playing macros, stored in a separate layer.

After what seemed a unbearable wait, my OneHand PCBs showed up from Seeedstudio... $25 for 10 PCBs!

I only have PCB mount Blues on hand (still waiting for the Reds and Browns), but had to start building one.

I've mounted all the components I can (some of the switches are just pushed in), as I was not expecting the PCBs and did not have all the header pins/sockets needed to mount the Teensy. For the first prototype I'll be socket mounting the Teensy, but future models will be mounting the Teensy directly to the PCB to be lower profile.

The feel of the keyboard, thanks to the MX switches is very good, and I feel that I should be able to type at a reasonable rate with it. I also feel that I can add a few extra key chords without making it too difficult, which will allow [] {} <> etc to be typed without shift modes.

Hopefully I'll get the board working tomorrow - I still have to decide if I'm going to mod the Teensy to remove the LED, or fix the PCB - I'm leaning towards removing the LED, after which I can refine the software I've written.