Author Topic: Re-Create the DataHand - Thumb cluster under development. Project 75% done.  (Read 417696 times)

0 Members and 1 Guest are viewing this topic.

Offline OldDataHands

  • Thread Starter
  • Posts: 280
  • Location: Michigan
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #300 on: Wed, 22 October 2014, 18:24:48 »
When you say Dodohand, what are you referring to?  Just need some clarification.

This project is the DodoHand project - This Re-Creation of the DataHand.

I named it DodoHand a while after I started into this project:
http://geekhack.org/index.php?topic=41422.msg871630#msg871630

Offline wolfv

  • Posts: 269
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #301 on: Thu, 23 October 2014, 00:03:39 »
the Teensy-3.1
I have written the code for right-hand and have the ball working, mouse buttons (mapped to thumb switches), key matrix (Dvorak layout) and it is all working really well.  I am now working on IO expander firmware for the left-hand unit with an I2C connection to the right-hand unit.

hweller,
That looks like a nice trackball setup.  Thank you for posting :thumb:
I was thinking of replacing a thumb cluster with a track ball, but your setup might be better.

I am working on a DodoHand firmware for Teensy 2.0.
What firmware or library are you using or modifying?

Offline hweller

  • Posts: 25
  • Location: UK
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #302 on: Thu, 23 October 2014, 03:09:23 »
I also considered fitting a thumb trackball but having used a Kinesis Advantage keyboard for some years I am reluctant to give up one of the thumb-clusters for a trackball and having both look impractical.

I initially looked at smaller balls for the fingers which would be less of a squeeze but do not feel so comfortable under the hand.  Overall I think that the 2 1/4" ball is optimal but meant a lot of fettling of the PCBs to fit.  Incidentally I contacted John Kicklighter concerning the smaller ADNS9800 breakout boards and he kindly offered to provide them -- one problem solved.

I haved developed code for the Teensy 2 in the past in C using Makefiles but the support for this approach on the Teensy 3 is not so good.   The PJRC site recommends the Teensyduino interface for Teensy 3 development but I quickly became irritated by the IDE and longed for a good old-fashioned Makefile.  I played with my own for a while and then found:
https://github.com/apmorton/teensy-template
which is a good starting point for Teensy 3 development.  Additionally I use a Teensy 3 version of the CLI loader:
https://github.com/texane/teensy3.git

For I2C I use the standard Wire library supplied by PJRC.

For SPI (interface to the ADNS9800) I use:
https://github.com/xxxajk/spi4teensy3

The ADNS-9800 interface I use in this project is based on that provided by John Kicklighter
https://github.com/mrjohnk/ADNS-9800.git
https://github.com/mrjohnk/Trackball2.git
with updates for the Teensy-3.1 from
https://github.com/pepijndevos/Dwergmuis

The interface to the MCP23018 was a bit more tricky as I could not find a suitable class using Wire rather than twi so I had to write my own with reference to the ergodox-firmware:
https://github.com/benblazak/ergodox-firmware.git
and
https://github.com/sumotoy/gpio_expander.git

I wrote the key cluster processing classes myself with reference to the dhteensy and dodohand code:
https://github.com/imarko/dhteensy.git
https://github.com/dodohand/dodohand.git

I hope to get my code in a releasable state over the next few days.

Offline vivalarevolución

  • Posts: 2146
  • Location: Naptown, Indiana, USA
  • Keep it real b/c any other way is too stressful
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #303 on: Thu, 23 October 2014, 08:51:36 »
When you say Dodohand, what are you referring to?  Just need some clarification.

This project is the DodoHand project - This Re-Creation of the DataHand.

I named it DodoHand a while after I started into this project:
http://geekhack.org/index.php?topic=41422.msg871630#msg871630

Ok, thank you.  Fun title!
Wish I had some gif or quote for this space, but I got nothing

Offline wolfv

  • Posts: 269
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #304 on: Thu, 23 October 2014, 12:55:47 »
Wow hweller, that is an impressive array of firmware you put together.

I am using the Arduino Keyboard and Wire libraries on teensy2 and MCP23018.
I use Make to develop most of the classes on g++, then use the Arduino IDE for the final build with the Arduino Keyboard and Wire libraries.  That way others only need to install Arduino IDE to modify and compile the code.
I will release the firmware in November.
« Last Edit: Thu, 23 October 2014, 13:02:34 by wolfv »

Offline wolfv

  • Posts: 269
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #305 on: Thu, 23 October 2014, 18:06:57 »
I am writing a DodoHand firmware but don't have access to a DataHand.
If you use a DataHand, please answer these two questions for me:

1) When finger Mouse is on, does pressing "Arrow Keys On" (right middle finger well) activate arrow keys?
Page 37 of DataHand Pro II User Guide says "To use the arrow keys in Mouse Function mode, you must first turn on the arrow keys and turn off the mouse." How do you do that?

2) If NAS+shift+5 is pressed, does DataHand print "5" or "%"?

Thank you.

Offline OldDataHands

  • Thread Starter
  • Posts: 280
  • Location: Michigan
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #306 on: Thu, 23 October 2014, 21:19:21 »
Hi wolfv,

Re: 2): When NAS+shift+5 is pressed, you get %

Re: 1) I have Dvorak DataHands, which have a different mapping to the mouse mode and arrow keys.
In the Dvorak layout the right-hand pinkey finger N/E/S/W keys are arrows in NAS mode.

Regarding the MCP23018: The DodoHand uses a PCA9655E because it relies upon the I/O Expander
to source current, not sink it like the MCP2308... I assume that you're just using that as a surrogate,
but want to make certain.

hweller: It would take a bit of tweaking, but I could swap pin assignments and free up the SPI port on
the Teensy2.0 for that laser sensor. (I'm currently setup for an I2C pointing device, not SPI). Do you
think that the atmega32u4 has enough guts to reasonably deal with the laser tracker too?  I have no
idea what idle time is available after dealing with the PCA9655E and USB HID stuff...  Still, first things
first: I need to finish the first revision before worrying too much about possible improvements.

Calling InputNirvana: You've said multiple times that improvements were needed. I think hweller is really
on to a good thing here. Do you have any particular reaction?


Offline wolfv

  • Posts: 269
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #307 on: Thu, 23 October 2014, 22:12:42 »
Re: 2): When NAS+shift+5 is pressed, you get %
Thank you for the information OldDataHands.

If NAS+shift+% is pressed, what does DataHand print?

Offline OldDataHands

  • Thread Starter
  • Posts: 280
  • Location: Michigan
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #308 on: Thu, 23 October 2014, 22:17:10 »
If NAS+shift+% is pressed, what does DataHand print?

Also %

Offline ConscienceDrop

  • Posts: 139
  • a-are these pbt?
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #309 on: Thu, 23 October 2014, 22:42:01 »
this project blows my mind and goes way over my head.  :eek:
but i feel like im learning alot from reading all your posts and watching this re-birthing process.

very inspirational guys.

Offline OldDataHands

  • Thread Starter
  • Posts: 280
  • Location: Michigan
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #310 on: Thu, 23 October 2014, 23:02:06 »
One last note for the night: Looks like it'll run around $120 to
print the components for all the thumb switches, and ~$30 for the PCBs.

Unfortunately, Shapeways recently altered their pricing calculation and
multiple pieces now cost extra for each part, whereas before you could
group them into one model and save. This looks to add around $180
to the cost of printing a full set of switch parts. What a bummer. I guess
I'll have to do research again to see what other 3D printing options are
around.

Offline jacobolus

  • Posts: 3661
  • Location: San Francisco, CA
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #311 on: Thu, 23 October 2014, 23:33:00 »
I think you can add some little tabs connecting your parts to dramatically cut your shapeways cost. Kind of a pain in the ass though.

Offline hweller

  • Posts: 25
  • Location: UK
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #312 on: Fri, 24 October 2014, 05:58:52 »
hweller: It would take a bit of tweaking, but I could swap pin assignments and free up the SPI port on
the Teensy2.0 for that laser sensor. (I'm currently setup for an I2C pointing device, not SPI). Do you
think that the atmega32u4 has enough guts to reasonably deal with the laser tracker too?

Yes I think that with care the Teensy 2.0 is sufficient in terms of performance but if you would like the trackball to operate an interupt which the ADNS9800 breakout board provides you will need an extra pin, i.e. 5 pins in total for the SPI + interupt.  The problem I have with the DH200 is that the matrix is 14x2 so I need 16 pins just for the keys.  My total pin utilization is
    Pin requirements:
    | Purpose                                              | #pins |
    |------------------------------------------------+--------|
    | I2C (comms between teensys)           |        2 |
    | SPI (comms with trackball) + interupt |        5 |
    | Key matrix column inputs                    |        2 |
    | Thumb row outputs                             |        4 |
    | Finger row outputs                              |      10 |
    | Mode and modifier indicator LEDs       |        6 |
    | Wake-up GPIO pin                               |        1 |
    |------------------------------------------------+---------|
    | Total                                                    |      30 |

So the Teensy 2.0 with only 25 IO pins is not sufficient.  I could use the Teensy++ 2.0 but the Teensy 3.1 has enough pins and more power and memory than I know what to do with so I thought I will go with the latest.  The only disadvantage of the 3.1 over the Teensy++ 2.0 is that I need to use some of the pins on the underside of the PCB so I had to solder on a surface-mount header and as I wanted to fit it to the veroboard on a socket I had some "fun" with track-cutting and fitting strips of header socket.  But it is do-able.  Fitting the Teensy 3.1 with the surface-mounted header to a PCB would not pose any problem.

I have used the Teensy 2.0 for chorded keyboard projects in the past and found that I ran out of memory quite quickly and had to move data back and forth between RAM and FLASH which was a pain.  In the end I moved over to the Teensy++ 2.0 because of the extra memory but now the Teensy 3.1 is available and is also cheaper than the Teensy++ 2.0 I will stick with the 3.1.  I am hopeful that in the longer term there will be a suitable microcontroller based on the open-source RISC V processor.

Offline OldDataHands

  • Thread Starter
  • Posts: 280
  • Location: Michigan
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #313 on: Sat, 25 October 2014, 22:17:16 »
I ordered a print of the thumb switches for the right-hand
from Shapewas tonight, and the PCBs from OSHPark.
Hopefull by mid-November I'll be able to assemble the
thumb switches and see if/how they work.

Yes I think that with care the Teensy 2.0 is sufficient in terms of performance but if you would like the trackball to operate an interupt which the ADNS9800 breakout board provides you will need an extra pin, i.e. 5 pins in total for the SPI + interupt. 

Understood, and that's not a problem.
There are sufficient pins for the IRQ.

I think you can add some little tabs connecting your parts to dramatically cut your shapeways cost. Kind of a pain in the ass though.

Good point jacobulus. Given that in total, for both hands
there are some 96 pieces, there is an opportunity to drop
well over $100 from the print cost by connecting with a
tree. Definitely a pain.

Here's the 3D model submitted for printing:
80796-0

Offline hweller

  • Posts: 25
  • Location: UK
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #314 on: Sun, 26 October 2014, 11:45:32 »
The initial version of the DH200 with trackball is now complete. 

The left-hand unit now has a MCP23018 IO-expander replacing all of the original electronics but otherwise remains unchanged.  I am tempted to fit a trackball also in the left-hand unit in which case it might be easiest to fit a microcontroller rather than an IO-expander but this is for the future.  I found the Wire library supplied for the Teensy-3.1 worked fine during testing with a very short I2C wire but now I have a 1/2m TRRS cable it has proved unreliable and I am now using the i2c_t3 library which works better.  For those wanting to separate the left- and right-hand units a long way, or maybe connect them via a cable behind a chair for example I think a low capacitance cable e.g. Cat5/5e would be much more reliable than TRRS and for the next version I will replace the TRRS connectors with Cat5 8P8C connectors (to be able to use readily available Cat5 cables) or maybe the 4P4C connector.

I am still evolving the key-maps and playing with a shift-mode in addition to the shift modifier which allows complete freedom in mapping of keys as well as their shifted variants, in particular I REALLY want to swap () with [] for Lisp/Scheme programming.  At the moment I use xmodmap to remap shifted keys which is not convenient.  So far the shift-mode looks like a good solution.

The initial version of my notes and code for this project is now available from GitHub:
https://github.com/Henry/TrackHand

Offline OldDataHands

  • Thread Starter
  • Posts: 280
  • Location: Michigan
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #315 on: Sun, 26 October 2014, 13:09:55 »
Sounds great!

Any idea what makes the one I2C library work better? slower clock rate?

Offline hweller

  • Posts: 25
  • Location: UK
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #316 on: Sun, 26 October 2014, 13:56:54 »
Same clock rate was used, just 100kHz.  I played with the settings a bit but couldn't get Wire to work reliably so I thought I would try i2c_t3 as a sanity check and found it worked fine verifying my wiring.  I didn't investigate the problems with Wire any further.  I think this is only an issue with the Wire library for the Teensy 3.? and as the i2c_t3 is specialised for the ARM microcontoller and better performance is probably preferable anyway.  I think the standard Wire library is fine for the Teensy 2.

Offline Tiramisuu

  • Posts: 329
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #317 on: Sun, 26 October 2014, 15:41:46 »
like many I am watching this thread regularly.   An exciting project.
Keyboard error F1 to continue.

Poker 2, Gherkin, Lets Split, Planck, Filco

Offline dpanse

  • Posts: 14
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #318 on: Sun, 26 October 2014, 18:26:05 »
To digress a bit, my Datahand Pro II stopped working. Any help would be greatly appreciated: http://geekhack.org/index.php?topic=64792.0

Offline OldDataHands

  • Thread Starter
  • Posts: 280
  • Location: Michigan
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #319 on: Tue, 28 October 2014, 22:18:42 »
Thank you for the information OldDataHands.

If NAS+shift+% is pressed, what does DataHand print?

Hi wolfv,

Not certain if this will be of immediate value to you, but here is the switch matrix:

81073-0

Note that the switch matrix is the repeated for each hand, and that the easypoint
switch is purely optional.

Offline dorkvader

  • Posts: 6288
  • Location: Boston area
  • all about the "hack" in "geekhack"
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #320 on: Tue, 28 October 2014, 22:51:24 »
looks like you can achieve NKRO using a very similar method as the modern hall effect keyboard matricies will.

Offline OldDataHands

  • Thread Starter
  • Posts: 280
  • Location: Michigan
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #321 on: Wed, 29 October 2014, 09:42:47 »
looks like you can achieve NKRO using a very similar method as the modern hall effect keyboard matricies will.

I'm unfamiliar with those, but the DodoHand switch matrix is certainly NKRO... USB: not so much.

Offline dorkvader

  • Posts: 6288
  • Location: Boston area
  • all about the "hack" in "geekhack"
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #322 on: Wed, 29 October 2014, 12:18:00 »
looks like you can achieve NKRO using a very similar method as the modern hall effect keyboard matricies will.

I'm unfamiliar with those, but the DodoHand switch matrix is certainly NKRO... USB: not so much.

since the photoresistors will only output when they have light hitting them, you can "isolate" a row from the rest by only powering the LEDs on that row. Then, with a high scanrate, you can "remember" what was pressed or unpresed from the last scan, and only update switch states that have changed.

Offline jacobolus

  • Posts: 3661
  • Location: San Francisco, CA
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #323 on: Wed, 29 October 2014, 13:08:27 »
USB: not so much.
USB is entirely capable of NKRO. You just need to use the proper bit of the protocol, which most keyboards don’t. Check out soarer’s and hasu’s firmware to see examples.

Offline OldDataHands

  • Thread Starter
  • Posts: 280
  • Location: Michigan
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #324 on: Wed, 29 October 2014, 14:36:43 »
USB is entirely capable of NKRO. You just need to use the proper bit of the protocol, which most keyboards don’t. Check out soarer’s and hasu’s firmware to see examples.
Interesting! Thanks for the gentle cluesticking!

Offline HaaTa

  • Master Kiibohd Hunter
  • Posts: 794
  • Location: San Jose, CA, USA
  • Kiibohds!
    • http://kiibohd.com
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #325 on: Wed, 29 October 2014, 15:24:01 »
Here's a couple USB NKRO descriptors:

Freescale ARM
AVR PJRC

hasu has various descriptors as well for USB NKRO (though they are slightly different as he's trying to do different things): https://github.com/tmk/tmk_keyboard/tree/master/protocol

Unfortunately Soarer never opened up his code (and then proceeded to disappear..). Made it tricky when I wanted to ask him questions about it. However, you can still get a USB HID Descriptor out of it -> http://pastebin.com/phRrCPty

I'll try to give the super brief overview, I should write an article sometime...but feel free to join #geekhack @ irc.freenode.net and you can ask me more specific questions.

  • 2 USB Endpoints are required, 1 must adhere to the Boot Protocol (see Appendix B in the USB HID spec), the other can be whatever you want
  • By default, use NKRO, unless SET_PROTOCOL is requested by the computer side USB stack, according to the spec this is a requirement...
  • To do USB NKRO you can either send N bytes (which is dumb) or you can send a bitmap of all of the keystates (e.g. 1 bit per key), you can define which bits do what using the USB HID descriptors (which is why I linked examples above)
  • You can go even further by grouping packets so you don't have to send everything all the time
  • On Linux you cannot send keycode 0x50 due to a bug in their HID stack, regardless of whether it gets fixed you still have to deal with it because old versions of Linux will still have the issue
  • System Control and Consumer control need their own USB HID Descriptor

You'll also want to be familiar with the USB HID Spec -> http://www.usb.org/developers/hidpage/HID1_11.pdf http://www.usb.org/developers/hidpage/Hut1_12v2.pdf
The USB HID spec doesn't explain how to implement NKRO, but it hints at how to achieve it (which is how dfj, Soarer and hasu figured it out).

All of this has been tested Windows/Linux/Mac and adheres to the USB HID spec so in theory should work everywhere.
When in doubt, Wireshark helps with debugging. Though you'll want some microcontroller side USB debugging as well to deal with odd Microsoft/Mac issues that tend to come up with USB.
« Last Edit: Wed, 29 October 2014, 21:51:54 by HaaTa »
Kiibohd

ALWAYS looking for cool and interesting switches
I take requests for making keyboard converters (i.e. *old keyboard* to USB).

Offline wolfv

  • Posts: 269
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #326 on: Wed, 29 October 2014, 17:06:14 »
I received a PCA9655E I/O expander today.  How to mount it on a solderless breadboard?

Thank you DodoHand for the thumb cluster switch matrix.

The NKRO information will be useful.  NKRO can be added to the firmware on a  later release.

Offline OldDataHands

  • Thread Starter
  • Posts: 280
  • Location: Michigan
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #327 on: Wed, 29 October 2014, 17:59:21 »
I received a PCA9655E I/O expander today.  How to mount it on a solderless breadboard?

 https://www.sparkfun.com/products/495

is probably the right answer.

Offline OldDataHands

  • Thread Starter
  • Posts: 280
  • Location: Michigan

Offline chrisandreae

  • Posts: 43
  • Location: Tokyo, Japan
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #329 on: Wed, 29 October 2014, 20:36:50 »
  • 2 USB Endpoints are required, 1 must adhere to the Boot Protocol (see Appendix B in the USB HID spec), the other can be whatever you want

Following boot protocol doesn't actually require a separate interface/endpoint - after a Boot Interface subclass interface receives Set_Protocol, it's expected to ignore whatever report format its report descriptor specifies and send boot format reports. Your descriptors don't need to include the boot protocol report descriptor, since A BIOS using the boot protocol doesn't read the report descriptors at all. (See Appendix B and F)

  • To do USB NKRO you can either send N bytes (which is dumb) or you can send a bitmap of all of the keystates (e.g. 1 bit per key), you can define which bits do what using the USB HID descriptors (which is why I linked examples above)
  • You can go even further by grouping packets so you don't have to send everything all the time

An awkward HID spec compliance issue for NKRO is that Appendix C (Keyboard Implementation) states that "Non-modifier keys must be reported in Input (Array, Absolute) items" - so using an Input (Variable, Absolute) bitset is not actually adhering to the spec. That said, I think it's still the most compatible with real-world systems (though I haven't actually played with NKRO for a while - is this still true?). Splitting up the keyboard into multiple independent interfaces with a few (Array, Absolute) input items each runs into the awkward problem on OS X that modifier state is not shared between "different keyboards", so each modifier key change might require sending several reports.
« Last Edit: Thu, 30 October 2014, 08:17:53 by chrisandreae »

Offline HaaTa

  • Master Kiibohd Hunter
  • Posts: 794
  • Location: San Jose, CA, USA
  • Kiibohds!
    • http://kiibohd.com
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #330 on: Wed, 29 October 2014, 22:05:00 »
  • 2 USB Endpoints are required, 1 must adhere to the Boot Protocol (see Appendix B in the USB HID spec), the other can be whatever you want

Following boot protocol doesn't actually require a separate interface/endpoint - after a Boot Interface subclass interface receives Set_Protocol, it's expected to ignore whatever report format its report descriptor specifies and send boot format reports. Your descriptors don't need to include the boot protocol report descriptor, since A BIOS using the boot protocol doesn't read the report descriptors at all. (See Appendix B and F)
Yeah that makes sense. I'll have to test it, but there may be a compatibility reason why Soarer and hasu settled on using two separate endpoints.

  • To do USB NKRO you can either send N bytes (which is dumb) or you can send a bitmap of all of the keystates (e.g. 1 bit per key), you can define which bits do what using the USB HID descriptors (which is why I linked examples above)
  • You can go even further by grouping packets so you don't have to send everything all the time

An awkward HID spec compliance issue for NKRO is that Appendix C (Keyboard Implementation) states that "Non-modifier keys must be reported in Input (Array, Absolute) items" - so using an Input (Variable, Absolute) bitset is not actually adhering to the spec. That said, I think it's still the most compatible with real-world systems (though I haven't actually played with NKRO for a while - is this still true?). Splitting up the keyboard into multiple independent interfaces with a few (Array, Absolute) input items each runs into the awkward problem on OS X that modifier state is not shared between "different keyboards", so each modifier key change might require sending several reports.

AFAIK, this has been tested working on Windows/Linux/Mac. Mac runs into issues if there are separate endpoints composing a keyboard. When I talk about groups, this is still within the same HID collection so it is still referencing the same keyboard device.

I've yet to see a system that does not work with bitmaps (vs. arrays) myself.

Hmm, something interesting in the spec. Look at 6.2.2.4, it's possible to have an Array that is also a bit field (bitmap) (bits 1 and 8 for Input). This might be why using the bitmaps works in the tested implementations.
Kiibohd

ALWAYS looking for cool and interesting switches
I take requests for making keyboard converters (i.e. *old keyboard* to USB).

Offline wolfv

  • Posts: 269
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #331 on: Wed, 29 October 2014, 23:28:21 »
What soldering method do you recommend for the DodoHand PCB: soldering iron, hot air station, or toaster oven?
I have no surface-mount soldering experience or tools.

Thank you.

Offline dorkvader

  • Posts: 6288
  • Location: Boston area
  • all about the "hack" in "geekhack"
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #332 on: Thu, 30 October 2014, 00:05:03 »
What soldering method do you recommend for the DodoHand PCB: soldering iron, hot air station, or toaster oven?
I have no surface-mount soldering experience or tools.

Thank you.


Looking at the PCBs, you could do it with a hand soldering iron and a lot of care, but if you have access to a reflow toaster or hot air it would probably make it easier.

Since I have no soldering toaster, and lots of SMD experience I'd just do it by hand.

Offline OldDataHands

  • Thread Starter
  • Posts: 280
  • Location: Michigan
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #333 on: Thu, 30 October 2014, 05:56:18 »
What soldering method do you recommend for the DodoHand PCB: soldering iron, hot air station, or toaster oven?
I have no surface-mount soldering experience or tools.

Thank you.

I used a hot air rework wand and an iron during assembly. Having limited SMD experience myself, I feel that it would have taken an extra hour or two with just an iron for me.  If you can spare the $$$, a hot air station is a cool tool! Get one! (but it isn't needed). (but they're cool! i've something like: http://www.circuitspecialists.com/blackjack-solderwerks-hot-air-&-soldering-iron-combo-system.html )

Offline wolfv

  • Posts: 269
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #334 on: Thu, 30 October 2014, 09:08:06 »
OldDataHands,

Ya, I saw a hot-air tool video, it's like a magic wand - "I command you to solder yourself" - and it's done.

How did you secure the PCB during soldering?
Can I just weight the corners down on a mat, or do I need a hobby vise?

update: after looking at another rework video, I would say that the DodoHand PCB is massive enough to not need any restraints.
« Last Edit: Thu, 30 October 2014, 19:50:30 by wolfv »

Offline arisian

  • Posts: 13
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #335 on: Sat, 01 November 2014, 14:41:03 »
In response to the trackball and mapping questions raised by hweller, I'll also throw my enthusiastic support behind having a trackball in the hand unit.  I too had been thinking of a thumb-ball replacing all/part of a thumb cluster, but your solution seems like it would be much better, assuming that not too much movement of the palm is required to switch between comfortable use of keys and trackball.

As a long time datahand user, I have also found that the mappings of certain keys like () and [] were inconvenient, and wound up re-mapping several things, though I've had to do it in software (I have the Personal, not the Pro).  Doing it with xmodmap, while less than ideal, is fine for most keys; the exception is the keys that auto-send multiple "keystrokes".  For example, the key that produces a <double-quote> (") in the default mapping is useless, since it actually sends <Shift>+<single-quote> ('), which is an inconvenience due to the fact that I type dvorak (on a datahand that was intended to be used qwerty, because that was what I could afford at the time).  The keys that send more than one keystroke by default are effectively dead-keys for me, since there's no way to re-map them.  I've also wound up switching the locations of Alt and Tab, so I could hit Ctrl+Alt with just my left thumb, which lets me access many keyboard shortcuts left-handed (e.g. if my right hand is on a (external) trackball, for example).  Having the ability to re-map everything at will in firmware will be awesome, but that should be the easy part in all of this.
« Last Edit: Sat, 01 November 2014, 14:42:39 by arisian »

Offline hweller

  • Posts: 25
  • Location: UK
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #336 on: Sat, 01 November 2014, 15:57:42 »
In response to the trackball and mapping questions raised by hweller, I'll also throw my enthusiastic support behind having a trackball in the hand unit.  I too had been thinking of a thumb-ball replacing all/part of a thumb cluster, but your solution seems like it would be much better, assuming that not too much movement of the palm is required to switch between comfortable use of keys and trackball.

So far I have found that using the trackball fitted as close as possible to the finger cluster surprisingly convenient and requires practically no palm movement to move the ball comfortably.

I've also wound up switching the locations of Alt and Tab, so I could hit Ctrl+Alt with just my left thumb, which lets me access many keyboard shortcuts left-handed (e.g. if my right hand is on a (external) trackball, for example).

I did the same yesturday, partly to allow Ctrl and Alt modifiers to be applied to the mouse buttons but also to make it more convenient to press them both at the same time, i.e. using the left thumb.  So far I have found this arrangement pretty good.  I have put images of the current key layout I am using on my github repository for this project, you will find them at the bottom of the project front page, let me know what you think:
https://github.com/Henry/TrackHand


Offline OldDataHands

  • Thread Starter
  • Posts: 280
  • Location: Michigan
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #337 on: Sat, 01 November 2014, 20:03:46 »
I have put images of the current key layout I am using on my github repository for this project, you will find them at the bottom of the project front page, let me know what you think:
https://github.com/Henry/TrackHand

Fantastic. Can't emphasize that enough. Just Brilliant.

Once I get the DodoHand switches worked out,
the pinheaders for connecting the thumb PCB
to the finger PCB will be moved to allow this
arrangement, and an alternate PCB will be
created for the thumb cluster to provide more
room.

Offline arisian

  • Posts: 13
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #338 on: Mon, 03 November 2014, 18:24:27 »
Another mapping thought for the trackball layout is to add a key that, when pressed, causes the trackball to behave like a mouse scroll wheel.  See, for example, the option "EmulateWheel" in xorg.conf under Linux (though I think that only lets you use mouse buttons, and not keyboard inputs, to activate the mode).  I've got my old Logitech TracMan Optical set up this way; it actually has a scroll wheel, but I find it more comfortable to press a button and then use the ball for scrolling if I'm trying to scroll more than a few lines.

This would be particularly useful in the dodohand given that there are no plans to incorporate a scroll wheel (and, in fact, I think this is preferable to a scroll wheel for most purposes; the only case where it's an issue is where you're looking for precise control like using the wheel to cycle through items in a list, or switch weapons in a FPS, in which case a "clicky" scroll wheel would have an edge).  I'm pretty sure this would just be a matter of a bit of extra logic in the firmware; no special hardware should be required.

Offline hweller

  • Posts: 25
  • Location: UK
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #339 on: Tue, 04 November 2014, 03:20:11 »
Another mapping thought for the trackball layout is to add a key that, when pressed, causes the trackball to behave like a mouse scroll wheel. 

We are thinking along the same line.  Yesterday I developed and pushed an update to support scrolling by holding the shift key while moving the ball.  This could be changed to be activated by any other modifier key in any mode or any free key in the function/mouse mode.  When in scroll mode the resolution of the ADNS-9800 sensor is reduced but the lowest it can be set to is 50cpi which is still quite quick for scrolling.  However, I have always found the scrolling on the Kensington SlimBlade rather slow so I will use this faster scrolling for a bit to see if I get used to it.  If not it would be possible to keep track of the motion returned by the sensor and reduce the resolution in the software  for scrolling and this could be made "jumpy" to give the behavior closer to a "clicky" scroll-wheel but without the clicks or the feedback.  I never liked the clicking noise anyway.


Offline eviltobz

  • Posts: 95
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #340 on: Tue, 04 November 2014, 03:31:53 »
I just wanted to say that I'm loving seeing progress in this thread again :) Good work guys.

Offline Turbinia

  • Posts: 64
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #341 on: Tue, 04 November 2014, 09:50:28 »
Wow, the track ball concept is awesome! I had so many issues with trackpoints, sourcing, prototyping etc. I was worried no one would find a good solution to the mousing.

Is that case the original?
| Dolch | KBT ONE | QFR w/PBT | Poker II |

Offline hweller

  • Posts: 25
  • Location: UK
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #342 on: Tue, 04 November 2014, 10:53:55 »
Is that case the original?

Yes the case is the original but I had to remove and replace several mounting lugs, drill holes for the new connectors and reset button and cut a section from the palm rest for the ball.   The shape of the palm rest moulding was well suited to the fitting of the 2 1/4" ball so I doubt it could be much better if created from scratch.  However, the palm rest of the more recent Personal and Professional II models are rather different to that of the DH200 I am working with and I am not sure the ball would be so easily accomodated.  For the DodoHand there will not be a problem.

Offline OldDataHands

  • Thread Starter
  • Posts: 280
  • Location: Michigan
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #343 on: Fri, 07 November 2014, 06:43:14 »
81531-0


81533-1


PCBs have arrived and look good.
switch parts have shipped!

Offline OldDataHands

  • Thread Starter
  • Posts: 280
  • Location: Michigan
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #344 on: Tue, 11 November 2014, 21:50:39 »
81762-0

Thumb switches have arrived and I've played with them a little bit now.
They clearly still need some work, although I expect them to be functional.

The return force isn't sufficient for the thumb side switches - they will only
return if they are close to level. I expect to address this by switching to
a stronger magnet, and hopefully nothing else will be needed.

The initial activation force on the two-stage down switch is just a bit too
high, and the secondary activation force is too low. I had trouble only
activating the first one. I hope to address this with a bit less steel
for the magnet to attract.

It looks like they will mount up to the PCB just fine, so I should be able
to test that out within a week or so.

Offline dorkvader

  • Posts: 6288
  • Location: Boston area
  • all about the "hack" in "geekhack"
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #345 on: Tue, 11 November 2014, 22:18:21 »
That's an awesome update!

For the magnets, can you get a more magnetic (higher N  number) or will you have to get a physically larger magnet?

Offline OldDataHands

  • Thread Starter
  • Posts: 280
  • Location: Michigan
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #346 on: Tue, 11 November 2014, 22:32:24 »
For the magnets, can you get a more magnetic (higher N  number) or will you have to get a physically larger magnet?

I'll try using the thicker, higher surface field strength magnet which is already used in some positions.
It does mean some mechanical re-design, but that comes with the territory.  I'm already using neodymium magnets,
so I don't think it'll be easy to find stronger ones in the current sizes, but I'm all ears!

The magnets I'm using are:

http://www.kjmagnetics.com/proddetail.asp?prod=B4201

and

http://www.kjmagnetics.com/proddetail.asp?prod=B221

Offline jacobolus

  • Posts: 3661
  • Location: San Francisco, CA
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #347 on: Tue, 11 November 2014, 22:41:05 »
It might or might not be relevant/helpful in this use case, but either way, check out:
https://www.youtube.com/user/correlatedmagnetics1
http://cmr.polymagnet.com/blog/

Offline dorkvader

  • Posts: 6288
  • Location: Boston area
  • all about the "hack" in "geekhack"
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #348 on: Tue, 11 November 2014, 22:44:06 »
those are N42 (a good strength for Neodymium magnets) you can get up to N52 online but I don't know if they're available in a size that small.
« Last Edit: Tue, 11 November 2014, 22:56:39 by dorkvader »

Offline OldDataHands

  • Thread Starter
  • Posts: 280
  • Location: Michigan
Re: Re-Create the DataHand - Thumb cluster under development. Project 75% done.
« Reply #349 on: Fri, 14 November 2014, 21:55:22 »
The good news is that the side switches are all functional,
and with some minor removal of steel the down switches are usable,
if not perfect.

The bad news is that I messed up the footprint for the down
switches (the phototransistor pin assignments are wrong) so
I have some re-work to do before I can evaluate whether or
not they're functional. Also, the side switches still feel rather
mushy, with a bit too much travel - but hey, they're working on
the first try!!!

If it wasn't already assembled I could just solder the bridges
on the wrong side and be done. As it stands I'll need to get
creative.