deskthority

Looks great! Now what are you going to do with all those extra PCB's? I'd take one off your hands!

Also, was seeedstudio able to cut the board shape out as well? Or did you have to do that in post?

Good question. I'm still interested in your excess, too. Looks just as neat in reality as it did at the design stage. Great stuff!

Send me your details by PM and I'll mail them out. I only have six spare. I'll probably be doing another batch once initial testing is complete.

Hopefully you all live in the US so postage isn't too much, otherwise it'll be shipped Pigeon post

Let me know what resistor size you need for the LEDs and I'll see if I can get the SMD resistors (hand) soldered on which is the tricky part. I'm trying low current 2mA LEDs in the first test unit, but I don't know if they are going to be bright enough...

PJE

Awesome! I'm not in the US, but my brother is so you're in luck. SMD sounds the daunting part so if you're up for that you have my double gratitude. Let's see how your test run goes. Dark LEDs are preferable to me anyway.

If you're really willing to shlep an extra PCB my direction, way cool! Happy to build it & maybe help with the software if you've got a repo somewhere. But no worries on soldering the resistors, I can manage fine & should have a bunch coming for my board.

By the way, did SeeedStudio cut out the board outline as well, or did you do that in post? If so, I may go with them instead of OshPark for my board.

Current allocated PCBs:
Mu
bearcat

Four are currently up for grabs - I'll send them free to anyone who asks. It may be a little slow outside US.

I've just finished assembling my initial prototype - I had one bad solder joint which I've temporarily fixed with a wire on the back rather than removing a switch to access the joint. I found some old 100m PCB tray as an enclosure, and it seems to work pretty well. I'll upload pictures tonight.

I've loaded my software onto it and it works apart from the debounce which seems to be much longer on the MX Blues when compared to the Quinkey's switches. I need to work on my debounce logic, but otherwise the code is working... )

I can currently type with it, but get around 20% double characters. I'll be optimizing my debounce logic this evening.

PJE

Where did you get your Cherry stabs, PJE? Those are the one component I don't already have, ready to kit out a prototype myself. But I can always use <2 unit caps on those two switches instead.

I bought 20 stabilizers G99-0742 (2x) from Arrow Electronics for $13.80, although shipping was another $8.

I bought the MX Blues from Mouser, as a stop gap until 7Bit sends the Reds and Browns - although I'm quite liking the click (nice and annoying ;0)

PJE

So did Seeedstudios route the pcbs as well?

bearcat wrote:So did Seeedstudios route the pcbs as well?

Yes! They traced the board outline very well. I'm very pleased with the PCBs. The only issue was my silly mistake with D6/D7 putting a switch on the Teensy LED, which I fixed by removing the tiny resistor in series with the LED. I've just not to press the key while in bootloader mode. My next revision of the board will swap D6/D7 to remove this hack.

I've used 2mA LEDs on my initial unit, with slightly large resistors to I'm using more like 1.5mA. They glow fine in the dark, even through the solid keycaps, but need some form of window (or a semi-transparent cap) to work better in daylight.

I'm now concentrating on the switch debounce logic, which is non trivial with my version of a chording design!

PJE

I can only imagine!

How are you implementing the controller? And does layout editing require rebuilding the firmware from source? I've had little luck with the Teensy developer library, but perhaps with a fully chording keyboard like yours I should concentrate on just learning the layout instead of fiddling with it!

This response was typed on the OneHand keyboard... I've fixed the debounce issues.

I'm a little slow at the moment, but I'm getting faster all the time. The software is written using the Arduino development package. I think I have the basic functions pretty much sorted.

You would need to follow the Arduino help on the Teensy website. It's quite easy using my code to implement different mappings.

Phew! made it to the end of the post...

PJE

At present the keyboard mapping is hard coded into the application. I'm looking at implementing an EEPROM based table in a future release.

I'm working on the mode functions at the moment.

PJE

Edit: I've slightly modified the way the system handles the 1x buttons. I used to make two 8-bit values, but have split it into two five bit and two three bit numbers. This allows for easier visualization of the keys needed for a certain combination:

F11000, F00000, T000, T000, KeyCode, Modified KeyCode, Mode1 KeyCode, Mode1 Modified KeyCode....

This would allocate a keycode to the two key chord using the two keys on the top row at the far left. I created new definitions for F00000..F11111 (0..31) and T000 to T111 (0..7) to make the code more readable.
The two larger keys are handled as modifier keys with their own 2-bit code.

I would be highly interested in testing out a PCB. I have the required components too.

mohitgarg wrote:I would be highly interested in testing out a PCB. I have the required components too.

Please PM me your address, and I'll drop one in the post.

PJE.

I've been working on a few things with the software, but I just remembered I hadn't posted any pictures of the working unit...





Forgive the small jumper wire - I haven't fixed the bad solder joint yet...

I've modified the code to allow direct access to normally shifted characters - !@#$%^ etc.. This was performed by duplicating them in an unused region of the scan code map (by adding 0x90 to the base key) and then stripping off the added value and substituting the shift key modifier before it was sent.

A current code mapping element now looks like :
The Shifted keys have SK_KEY names to make their use easier. This mapping is the current codes for the orange key in the picture (hence the single 1 in the top row values).

I'm getting quite fast typing with it, although one handed operation was more important than speed, but I'll need a quieter key switch (MX Red? if they ever turn up) if I'm to be allowed to use the keyboard at home

As I come across key combinations which I find difficult to press or access while typing normally I find other alternatives, and as such the keyboard arrangement is evolving. One benefit of how the keyboard is coded, is that I can use multiple different key combinations to perform the same function.

At present I've coded the system for right hand use. I now need to see how well the coding works with the other hand, or whether different arrangements are needed depending on the hand being used.

I'm also looking at making a gamepad mode where multiple keypresses can be sent at the same time for WASD type games.

PJE

The symmetry of your design ought to make lefty use pretty easy. I'd just flip the logical layout and watch human symmetry at work! A key combo to mirror the layout would be advantageous when swapping hands.

Muirium wrote:The symmetry of your design ought to make lefty use pretty easy. I'd just flip the logical layout and watch human symmetry at work! A key combo to mirror the layout would be advantageous when swapping hands.

That's what I was thinking. It's harder typing on the keyboard using the same codes for left/right than with a mirrored arrangement. I've found that I don't need as many modes for the keyboard as I was expecting, and therefore Mode 4 can be used to select the mirrored keys...

PJE

EDIT: Well that was too easy!!! I simply made Mode 4 invert the pin mapping and mapped the presses onto the Mode 0 key combinations - Job done (for now)! It also makes the key definition array 20% smaller!

Just a quick update on progress with the initial prototype.

The keyboard is working very well - although my wife dislikes the noise the MX Blue's make (hopefully the Reds & Browns will arrive soon).

I've been working in enhancements to the software as time allows and I've now implemented Auto-Repeat which is a little novel on a Chording keyboard. It will repeat if the main (non-thumb) keys are held for a period - I'm optimizing the speed at the moment.

I've also added auto brackets/braces/Curley Brackets/whatever they're called - Typing ( will result in () with the cursor placed between the brackets, and similarly for [] and {}. I'll add a second way to generate ([{ to if the pair is not needed.

As the LEDs I fitted were intentionally dim, and ended up being dimmer than expected, I've drilled a small hole in the five top (colored) keys to allow you to see the active LED more easily. In my next prototype I'm going to fit brighter LEDs.

The next enhancement on the list is to add modifiers other than shift - Ctrl, Alt, etc. to allow a more complete keyboard intaction. I'm also going to add a hidden password entry combination to allow long computer passwords to be typed efficiently.

Overall, I think the keyboard is working better than expected, although my character mapping has changed somewhat to make typing easier.

Note: At present I've sent out three PCBS. If anyone else would like to try the OneHand keyboard, and has spare MX switches (PCB mount) and a Teensy 2 lying around please PM me and I'll send one out FOC.

Auto brackets? Cunning. I forgot to add those to my macros in Soarer's Converter!

The one customisation I can be sure I'll need (thanks for the PCB) is to swap Control for Command. This can be done in software on the Mac, but I'm going to try this portable keyboard on the iPad, where it can't. Command is just the Mac's equivalent of the Windows key, USB HID code-wise. But in practice it's more like Control for text navigation and a menu shortcut modifier key merged into one. Apple mods are very much Command and Option (Alt) first, with Control in a distant third.

Muirium wrote:Auto brackets? Cunning. I forgot to add those to my macros in Soarer's Converter!

The one customisation I can be sure I'll need (thanks for the PCB) is to swap Control for Command. This can be done in software on the Mac, but I'm going to try this portable keyboard on the iPad, where it can't. Command is just the Mac's equivalent of the Windows key, USB HID code-wise. But in practice it's more like Control for text navigation and a menu shortcut modifier key merged into one. Apple mods are very much Command and Option (Alt) first, with Control in a distant third.

Hi Muirium,

As long as the Teensy HID driver can send the correct code it should be easy to make an Apple version of the keyboard.

The Control/Alt/Etc modifiers are a little 'interesting' as they need to stay latched until all modifiers have been set and then released (unless latched on) on a non-modifier character.

Typing <Control>, followed by <Alt> and then Delete would currently generate Modifer <Control + Alt> and then send Delete. It should send Modifier <Control> Send [0], Modifier <Control + Alt> Send [0], Modifier <Control + Alt> Send [Delete], Modifier <0> Send [0]. I should have it working by the end of the day...

I also need to fix my auto-bracket feature as the text editor I was testing my keyboard in (Sublime Text 3) already had the auto brace function, so tricked me into thinking my code was working... I think I need to slow down the sending of the keystrokes a little.

Let me know when you've built the OneHand and I'll send you my code. I'll also document my current chord/key mapping and post it in a little while.

PJE

I've been working on the modifiers and I now have Ctrl and Alt working, allowing me to do a Ctrl, Alt, Delete combo! I decided to move the characters off the bottom row of the keyboard, leaving them for punctuation and Ctrl,Alt,etc. It was a little too much of a stretch when typing 'quickly'.

The auto-bracket function now works correctly - I found a wierd bug? in the compiler as the KEY_9 definition was being handled incorrectly when used in a comparison (or a Serial.print). I had to use a cast (char)KEY_9 for it to work correctly... very strange - maybe I'm missing something.

I'm investigating whether the order chords are pressed - A then A+B or B then A+B - would allow larger number of characters to be typed around the home keys. It should be possible to get five characters off two keys - A, B, A+B, A then A+B, B then A+B.

Finally, I'm also looking at adding an OLED I2C I bought a while back to the unit to allow the current character and mode to be displayed for reference.

PJE

Edit: Tried out the sequenced presses, and it'll work well for certain functions. I added pulsing LED indicators for shift, control, alt and WIN to allow you to see when they're selected.

My PCB arrived! Very nice and much appreciated. It's better than many a commercial product's. And it came in the same mail as a serendipitous set of Cherry stabs, too. (From the Surprise Box.) According to your note, I'm to fit resistors and switches before the Teensy. The resistors are for the LEDs, I presume? Two bits I forgot about.

TallHand: (Yes, I have French Round 4 SPH caps lying around.)

This is just a glimpse of the build to come: my switches are plate mount so I'll have to glue them on. Epoxy? I also need to source some appropriately small LEDs (I just have one) and the necessary resistors. Oh, and my legged Teensy 2 needs two three more of them: D4 and D5 on the short end and the mysterious pin E6 for connecting to three switches.

But I like the look of this little thing already!

Muirium,

I like the look of the caps you've tested - the smoother look seems to make it look more finished.

The build sequence would be:

1. Mount 0805 resistors for the LEDs (if they are to be used).

The ones I used were a little high in value, together with the low 2mA LEDs resulted in a dim LED light, to the point where I had to drill holes in the side of the cap to make them visible. I would think 10mA to an appropriate LED might be better. I have some red, green and blue LEDs to test on the next version. Using 2V drop 10mA LEDs would need a 300Ohm (or higher resistor). I'm going to experiment with the LEDs I have to find the best resisitor value of the ones I have on hand.

I simply added a tiny amount of solder to each pad and then position the resistor on top of the pads and reflow the solder. Another option is to tack both ends of the resistor to the pad using the solder used to plate the PCB, and then add a tiny amount more to each end (let one end cool before hitting the other to prevent tombstoning).

After the resistors are mounted, use a multimeter to check the resistance between the Teensy output hole and the A pin on the LED holes.

There are two additional 4.7KOhm pull-up resistors on the I2C clock and data lines which will also be hidden under the Teensy. Again test the resistance after mounting

2. If a Teensy without pre-mounted pins is being used it would be possible to mount the header pins to the bottom of the PCB (using the Teensy to maintain the correct position. Test for continuity between the pin and the corresponding switch/LED resistor/etc to ensure a good contact. (I missed one, hence the jumper wire)

3. Mount switches in positions 21 & 24, which are not reachable once the Teensy is installed, together with the LED in switch 21, and solder on the back. The LEDs need to be 3mm T1 type, and they drop in long pin (typically) to the hole marked A.

4. Mount the Teensy onto the pre-installed pins (easier), or push solder the pin Teensy on the top of the board - making sure to reach E6 between the two switches. I would recommend cutting the pins down so they don't protrude so far through the PCB as this makes soldering easier.

5. Mount the remainder of the switches, soldering them and the LEDs as you go. The 2x stabilizers on the thumb keys are recommended if available.

6. That should be it.

I'll be fully documenting the assembly of my next units once my MX Reds and Browns appear.

let me know when it's together and I'll send you my code - it's still in a state of flux at the moment as I work to speed up typing. I'm getting surprisingly quick on it, but some optimizations on a couple of the combinations will make a big difference.

Changes for the next version:

1. Add a couple of MCP23017 footprints to allow it to operate as an I2C keyboard for another micro, or as an expander for the first OneHand.

2. Change the I2C socket to a Grove standard 4-pin design and pinout.

3. Invesigate replacing the key mounted LEDs with an OLED or LCD display. I'm about to try a tiny 128x64 OLED display on the I2C bus.

Regards,

PJE

I've just been playing with sequenced chords for example:

Pressing the following gives:

GREEN - t
YELLOW - o
GREEN + YELLOW = f
GREEN then GREEN + YELLOW (without releasing the first GREEN): th
YELLOW then GREEN + YELLOW (without releasing the first YELLOW): of

Doing these finger rolls speeds up common pairs, and allows more characters to be typed on the primary keys at a slight reduction of ease of learning. The aim is to produce the most fluid one handed typing possible without distracting stretches between keys, as the rolled combination can generate any combination of letters. It would also be possible to put common combinations on the direct presses, while rolls could create the individual characters, rather than the other way round.

I'm really enjoying being able to experiment on the unit.

PJE

PJE wrote:Doing these finger rolls speeds up common pairs, and allows more characters to be typed on the primary keys at a slight reduction of ease of learning. The aim is to produce the most fluid one handed typing possible without distracting stretches between keys, as the rolled combination can generate any combination of letters.

Indeed. The sheer amount of state that chords can occupy is proof of quite how inefficient standard keyboards are in converting movement into output.

That balance of learnability versus fluidity, two vital things, will be quite the challenge!

PJE wrote:I'm really enjoying being able to experiment on the unit.

Exactly. I had all manner of layer remaps and macros in mind for my (then still to be built) custom keyboard. But actually using the working hardware led me to immediately alter almost everything! Some things have to be chosen by your fingers, not your head.

As for my build: some of the surface mount resistors are required to make this work, besides those for the LEDs? Perhaps I'll join you on the 7bit waiting game for PCB mount reds while I source them. My tall caps have a good feel, but will need some well glued plate mount switches, and I'm wary of committing to one switch type before I've tested it.

The caps are Signature Plastics SA profile sphericals (which I've a strong fondness for these days) like 7bit's current Round 5. I put row 1 on the top, 2, 3 and 4 in sequence for the single unit caps. Seems to work quite nicely. They're likely all available individually from SP as blanks. My legends are clearly superfluous!

I assume A = anode and K = kathode (in Cherry-speak) for the LEDs, as your legends match up nicely with the diode markings on the switch bodies themselves. (Technically, those markings are for the optional diodes, not LEDs, that Cherry can pop inside for you. But I assume the polarity is the same.)

Using rolling keys to enter popular combinations has led me to move some of the base keys to allow simpler combinations and more fluid typing.

The base keys are currently

[¤][a][o][<]
[^ ][t ][e][n]
[ ][d][r ][l ][ ]
[ ][ ][ ][. ][ ]

I'm currently recoding the key capture algorithm to save intermediate combinations to aid in generation of the rolling chords.

PJE.

Muirium, I am working on an acrylic case along with an acrylic case, which I should be able to send out by end of this month if you would be interested. Currently, I'm making two, one for myself and one for PJE.

PJE, I would suggest replacing the Teensy, with onboard SMD components, the GH60 is a great place to get started on that.

{You've got PM.}

A case is definitely an improvement over my current plan of sticking rubber feet on the underside!

@PJE: is it possible to run the OneHand without surface mount resistors entirely? If I forego LEDs and the expansion port?