Project Logs

Collapse

• Slight speedbump

  Patrick Tait • 10/02/2015 at 17:21 • 0 comments

  I've been both practicing and doing dev work on an Asus tablet using the ArduinoDroid app. That let me work on code during my lunch break and practice my typing on the treadmill and elliptical. For no apparent reason the tablet stopped accepting OTG connections, so I can neither type nor upload. I tried different OTG cables and different devices with no use, and I could successfully attach the keyer to other tablets. So now I either have to hump my laptop or find a new tablet.

  As far as progress before the tablet started acting weird, I can touch type pretty much the entire alphabet. For some reason F and J always give me trouble. Haven't done much work on the symbols yet. Most of my current practice involve typing pangrams or working on a short story I'm writing for my fiance.

  Code wise I'm working on tuning the keyeing algorithem. Type on release is good for training but I think it slows down typing. There will be a "pro" mode where if the chord is held down for N milliseconds it types. Figuring out the exact tuning to maximize speed and minimize mis-keys is proving to be trickey.

• Typing works

  Patrick Tait • 09/09/2015 at 05:01 • 0 comments

  Got typing for the basic alphanumeric chords working. None of the shifting yet so zero punctuation or numbers. Been doing a bit of practice with gnu typist on Dvorak mode to keep the symbols to a minimum. Getting about 10 wpm when I really try. I'm thinking that the current design of type on release will slow me down, but I'll need to be good and reliable before I can start hitting the chords on the downstroke.

  It's also quite good for typing on the move. I was able to type on the elliptical machine with the chorder, a feat I've never been able to mach with a conventional or on screen keyboard..

  Full hat tip to Mr. Ganssle's debouncing guide. I've done switch deboucing before but his page cut down on a few lines of code and may have added a bit to the reliability.
  

• 2nd video - now with blinkenlights

  Patrick Tait • 09/06/2015 at 19:07 • 0 comments

  Next step, actual typing.

• Still working

  Patrick Tait • 08/25/2015 at 18:53 • 0 comments

  Sadly, didn't make it to the semifinals. I knew I wouldn't be making it to the top 10 or even the top 50, but gave myself a 50-50 chance of making it to the next level.

  On the plus side, I am getting a free T-Shirt, which was basically the reason I signed up in the first place. I'll chalk this one up to a win.

  Right now I'm still getting used to development on the Arduino platform, it's kinda like having training wheels, in some ways limiting but in some ways simplifying. I've got the basics of key clicks and LED outputs and will hopefully be moving on to the analog thumb sticks and keyboard output for the basic chords by the weekend.

• Moving on from the LabJack

  Patrick Tait • 08/19/2015 at 01:14 • 0 comments

  So now I have the proof of concept, I debated changing the keymap based on the Gieger Code Chorder project but decided to keep it how it is. Next step is to make it into something more useful. The Labjack is a great quick and dirty prototyping device but it's useless if I want to use the keyboard at work, hooked up to my android slab or at anyone else's house but mine. Even if they have Linux installing the Labjack drivers and support programs makes it a somewhat nontrivial matter. I need something that will work with USB HID natively.

  I generally work with straight AVR's, 2313's a personal favorite of mine. I decided to be lazy this time though and go with the Arduino Leonardo. I chose this platform for three reasons:

  A) Native USB HID support

  B) I could pick it up at microcenter without waiting for the parts to arrive

  C) I received an Intel Galileo for Christmas so if I ever want to rebuild the keyer into a stand alone editor A La the MicroWriter I already have the board for it.

  Since I'm doing dev work on a new system, even if it's a system built atop one I'm familiar with, it's best to start small with blinking LED's and basic input. Since real time feedback is obviously helpful I'll start by having a simple set of indicator LED's for all of the keys. Press a key and the corresponding LED lights up. Once I have input and output down on the platform the sky's the limit

• qick video

  Patrick Tait • 08/17/2015 at 13:01 • 0 comments

  no action shots as it's being taken at a place I'm house sitting with no linux computer and my software only works on linux:

  
  

• Got it working in labjack

  Patrick Tait • 08/16/2015 at 17:38 • 0 comments

  We have the hardware, we have the layout, now we just need to do something useful with it.

  I decided to prototype the keyer with my LabJack U12 and python. Since I run Linux interfacing python to generate keyboard events is as easy as writing commands to xte(1) to run the keyboard and the mouse. Now, I'm not going to lie, this is an ugly hack and I should be ashamed of publishing it, but working 55 hours a week in customer service I found shame to be a liability.

  The wiring is entirely free form, hence the somewhat scattered look on the diagram.

  It seems to work well enough. Going from 60 wpm on qwerty to hunt and peck is painful but there's always a learning curve.

  Still need to think of a good name for the keyer, maybe etaim after cyclilng through the keys?

• The Layout

  Patrick Tait • 08/16/2015 at 01:45 • 0 comments

  So we have the basic design, 5 keys, the basic layout, Pinkey, Ring, Middle, Index Front and Index Rear. We need to figure out what chord goes with what key. There's several standards, Engelbart's design, cykey, twiddler, but other than Engelbart none of them are designed expressly for 5 keys, and Engelbart was not optimized in any meaningful way. Like all good engineers do when faced with multiple competing, non compatible standards, I decided to add another competing non compatible standard.

  I spent a few hours clicking in random combinations to try and figure out what fingers worked better with what combinations. I didn't have much of a problem where bending one finger caused another to bend enough to move a second finger, found zero issues with using the index finger to actuate the front, rear or both keys and found the hardest button to press was the pinky.

  I decided to write a very small, very dirty python script to help provide suggestions. Each key was weighted, a letter frequency pulled off of Wikipedia and the permutations calculated and sorted by the expected difficulty of chording. The output was analyzed, tweaked and tested and the end result put in a handy reference sheet. I threw together a layout for the remaining symbols based off of a bit of practise. Time and testing will tell if this is the optimal layout.

• The Keyer

  Patrick Tait • 08/16/2015 at 00:31 • 0 comments

  We have the basic layout, two buttons under the index fingers, one each for the other fingers and the thumb stick under the thumb.

  Sourcing the parts was easy. I had a lot of left over keyboard cherry switches from my Chair Mounted Keyboard project and several dead ps/3 controllers a soldering iron away from donating their joysticks.

  Figuring out a way to place them under the proper fingers was a bit trickier. The idea for the index finger controlling a combination of two keys was stolen from the Chordite keyer, he generally uses limit switches and coathangers for his keyer and my using cherry swtiches somewhat limits the applicability of his construction methods. Working with what materials I had at hand I decided to roll out a sheet of shapelock and mold it to my hand.

  This was less painful than expected, but still probably not the best way to make ergonomic human interface devices.

  The keys were placed on the molded plastic, attached with strips of shapelock, and solder wires run. For simplicity I chose to have a common ground and all individual strips have their own wire as opposed to any sort of multiplexing. Hopefully this won't come back to bite me down the road

• Initial inspiration and statement of purpouse

  Patrick Tait • 08/15/2015 at 21:22 • 0 comments

  This project has been in the back of my mind since the bush administration. Thanks to some very bad typing habits I have mild carpal tunnel syndrome in my right hand. My left hand has been spared so the idea of having a keyboard that can offload the work to the undamaged hand is a compelling one.

  The main problem with most one-handed chorded keyboards is the lack of a way to move a mouse. Most designs (including the original Engelbart model from the Mother of All Demos) assume one hand for the keyer and one hand for the mouse. Both are less useful for people who only want to use one hand for both or be using the keyer to control a mobile platform.

  The first idea was a simple one; Add a thumbstick like you find on modern game controllers and have that be used to control the mouse. The second idea is the big one. The mouse thumbstick is not in use while typing, and the more keys added to the keyer the greater complexity both in the chords and in the construction. Instead of having a large number of keys and combinations or a small number of keys and the requirement for multiple keystrokes to type lesser used symbols the thumbstick can, in typing mode, be used as an additional set of shift bits to allow other symbols, numbers or control keys to be accessed. This allows some chords to be reused in an easily memorized way, shift-space is tab, shift-delete is backspace, etc.

  People who, like me, have carpal in one hand and not the other or limited mobility in their hands can also benefit. The travel distance for a chorded keyboard is significantly less than for a conventional keyboard and using low force switches you can have minimal force for nerve-damaged hands while still having an audiable "click" for feedback.

View all 10 project logs