Re-Create the DataHand - Thumb cluster under development. Project 75% done.

[wolfv]

Hi Interface,

When I got started, I looked into modeling as well.  Modeling the hand can get very complicated.
I don't think there is enough data on "stresses of individual joints" and "hands natural mechanics" to make a model that is more accurate than intuition.
jacobolus said it best on:
https://deskthority.net/keyboards-f2/debunking-a-legend-about-languages-and-keyboard-layouts-t10507-30.html > 28 Apr 2015, 00:12

To get a feel for previous optimization efforts, enter these three words into your favorite search engine: keyboard "layout analyzer"

What DodoHand needs is much simpler: 3D printed parts for the thumb switches.

[test321]

are you using laser based photogrammetry? i don't think photo based methods can produce such accurate reproduction. I love the idea of buttons and positioning to be optimized for every finger, imo that's the next big step in dodohand ergonomics.

[Interface]

Hi Interface,

When I got started, I looked into modeling as well.  Modeling the hand can get very complicated.
I don't think there is enough data on "stresses of individual joints" and "hands natural mechanics" to make a model that is more accurate than intuition.
jacobolus said it best on:
https://deskthority.net/keyboards-f2/debunking-a-legend-about-languages-and-keyboard-layouts-t10507-30.html > 28 Apr 2015, 00:12

To get a feel for previous optimization efforts, enter these three words into your favorite search engine: keyboard "layout analyzer"

What DodoHand needs is much simpler: 3D printed parts for the thumb switches.

That's why I'm saving the hand sim for last. Thanks for your input anyway

are you using laser based photogrammetry? i don't think photo based methods can produce such accurate reproduction. I love the idea of buttons and positioning to be optimized for every finger, imo that's the next big step in dodohand ergonomics.

Photo based methods should work. I need to try

[invultri]

So I have been lurking in this thread for some years now and I have decided to try and create a version of the dodohand for myself.

I have just send a pull request to the thumb_work branch where I have changed the pads on the finger unit to have the same solder bridges as on the thumb. I would like to know 2 things:
1) Did I brake anything with this change?
2) Is the thumb PCB "functional" can I actually order them and components and get the electronics side done ?

Sneakpeak of current work:


Invultri

[OldDataHands]

I have just send a pull request to the thumb_work branch where I have changed the pads on the finger unit to have the same solder bridges as on the thumb. [snip]
1) Did I brake anything with this change?
[snip]

I'll try to look at the PCB over the weekend, but: That is AWESOME! Needed to be done. Thanks!

2) Is the thumb PCB "functional" can I actually order them and components and get the electronics side done ?

Yes, the thumb PCB is functional. The only circuit issue I'm aware of is Q1 on the finger PCB which is there as
an apparently poorly thought-out attempt at being able to read the state of a possible additional switch (meant for a
now-discontinued sparkfun breakout called an easypoint). Just leave Q1 off and the rest of the electronics work.

The current state of the thumb_switch branch hasn't been printed by me, or that I'm aware of.
I believe that it is worth printing, but have not yet done so.

[wolfv]

So I have been lurking in this thread for some years now and I have decided to try and create a version of the dodohand for myself.

Very exciting to see a DodoHand thumb cluster; the last piece of the DodoHand puzzle!

I soldered and tested an older version of the DodoHand PCB.
It works as intended, except for some LED indicator lights.
Right-PCB LED D11 (Normal mode) is the only indicator LED that works.
I am not a hardware expert, so it is possible that I did something wrong on my end.
Maybe OldDodoHands can tell you if the LED traces need fixing.

Here some observations from when I was trouble shooting the indicator LEDs.
LED-continuity is the same on left and right PCB:
    LED anodes (long legs) to pins
    LED cathodes (short legs) to resistors R10, R11, R12, R13
    Resistor R11 to ground
    Resistors R10, R12, R13 to power (this seems wrong)
Right-PCB LED D11 works.
Left-PCB LED D11 does not work because it uses Teensy pin D6, which is Teensy's on-board LED.
LEDs D10, D12, D13 do not work because their resistors are connected to power.
Otherwise the PCB works as intended.

My DodoHand PCB and breadboard keyboard are pictured below.
Both run the same keybrd_DH firmware https://github.com/wolfv6/keybrd_DH.
All the LEDs except for Scroll Lock work on the breadboard keyboard.

[invultri]

So I have been lurking in this thread for some years now and I have decided to try and create a version of the dodohand for myself.

Very exciting to see a DodoHand thumb cluster; the last piece of the DodoHand puzzle!
[snip]

It is my first design fully based on the work done by OldDataHands. I changed the design from snapfit to two interlocking parts that should be printable with an extrusion based printer. The printer is ordered and should arrive somewhere in the next 2 weeks, after which I will have to assemble it I fully expect that many things need to be improved once I print the first prototype, but with a printer at home that should be relatively easy.

[sinusoid]

Great job you guys!
It's awesome to see this thread alive.   

I'm still too busy with work to do anything meaningful, so no news from me unfortunately 
In the mean time I'm using a spring-modded cherry MY board with a negative angle, it's good enough for now. Light and fast.

@ Interface,
photogrammetry should do fine, I think there is an open-source toolchain that will let you do that. I was postprocessing one such scan in Blender for a friend, it was pretty smooth and detailed with a dense mesh. You can always try David Laser Scanner, they have some impressive results on their forum, and the software was partially free last time I checked. Avoid the handheld scanners, they're crap unless you're willing to pay north of 10K eur.
Not much experience with Rhino - does it have the capability to make something parametric out of a vertex-based mesh?

@invultri,
You can get the parts to snap together using the texture of the 3d print. Two sufficiently precise FFF 3d prints fit together like zip ties due to the stripey structure of their sides. They're basically push-fit. It works very well, you can even make them almost inseparable without breaking.
Out of curiosity, what printer are you getting?
If you get issues with assembly, you can post here, in the 3d printing thread, or PM me, I'll try to help out.

[OldDataHands]

I soldered and tested an older version of the DodoHand PCB.
It works as intended, except for some LED indicator lights.
Right-PCB LED D11 (Normal mode) is the only indicator LED that works.
I am not a hardware expert, so it is possible that I did something wrong on my end.
Maybe OldDodoHands can tell you if the LED traces need fixing.

Here some observations from when I was trouble shooting the indicator LEDs.
LED-continuity is the same on left and right PCB:
    LED anodes (long legs) to pins
    LED cathodes (short legs) to resistors R10, R11, R12, R13
    Resistor R11 to ground
    Resistors R10, R12, R13 to power (this seems wrong)
Right-PCB LED D11 works.
Left-PCB LED D11 does not work because it uses Teensy pin D6, which is Teensy's on-board LED.
LEDs D10, D12, D13 do not work because their resistors are connected to power.

Hi wolfv,

The LEDs all work, just not as you're expecting (and I just had to re-write this post because I think I know why!)

If you look at the LED schematic in the lower-left here:
https://geekhack.org/index.php?action=dlattach;topic=41422.0;attach=42475;image

excerpt here:


You'll see that LEDs 0, 1, and 2 go power->LED->micro pin, allowing the micro to ground the LED and pull current through it.
Works on both the left and right halves of the keyboard.  For LED 3 (connected to teensy pin D6) it is reversed, as you noted,
because of the presence of the diode on the teensy. This also works though. You have to configure the pin to an output that
drives current (i.e. +5v) and should get both the on-board diode and the external diode to light on the teensy side.

All works just fine.

Now, where I suddenly suspect that you got off course: I just opened the schematic with a new version of KiCAD, and all
of the diodes were reversed!!! WTF? I have no idea how/why, but it would sure make a mess of your idea of how to install them.

[wolfv]

The LEDs all work

That's good to know.  I will test the LEDs on the PCBs in September.

[invultri]

@sinusoid
I am getting a prusa i3 v2 with a 0.25 nozzle. As for push fit, it is what I am trying to achieve (or glue/acetone ). See example of the thumb side key below


@OldDataHands/wolfv
Instead of the trackpoint I have dug up: https://www.tindie.com/products/jkicklighter/adns-9800-laser-motion-sensor/ so I was thinking to include a trackbal into the hand unit. Do you think there is room in the teensy to enable a pointing device?

@OldDataHands
Since I am now to make the finger carrier fit the PCB I noticed that the via's for the carrier are not all the same distance from the origin. The north and east are further away. Is there any specific reason for this ?
As for changes in kicad, it seems that the component libraries you created are now "legacy". Thus I put the new footprint into the footprints.pretty library.

[wolfv]

@OldDataHands/wolfv
Instead of the trackpoint I have dug up: https://www.tindie.com/products/jkicklighter/adns-9800-laser-motion-sensor/ so I was thinking to include a trackbal into the hand unit. Do you think there is room in the teensy to enable a pointing device?

Not on the Teensy 2.0.
The keybrd_DH firmware and boot loader consume 2.3 kb of SRAM.
Teensy 2.0 has 2.5 kb SRAM.
Teensy LC has 8 kb SRAM (that should be enough SRAM, and I have two Teensy LCs on hand). https://www.pjrc.com/teensy/teensyLC.html
Teensy 3.2 has 64 kb SRAM.
I can easily change the keybrd_DH firmware and my bread board to Teesny LC or Teensy 3.2 and have it tested for you.
Changing the PCB would be more work, and I don' know how to design PCBs.

[invultri]

@OldDataHands/wolfv
Instead of the trackpoint I have dug up: https://www.tindie.com/products/jkicklighter/adns-9800-laser-motion-sensor/ so I was thinking to include a trackbal into the hand unit. Do you think there is room in the teensy to enable a pointing device?

Not on the Teensy 2.0.
The keybrd_DH firmware and boot loader consume 2.3 kb of SRAM.
Teensy 2.0 has 2.5 kb SRAM.
Teensy LC has 8 kb SRAM (that should be enough SRAM, and I have two Teensy LCs on hand). https://www.pjrc.com/teensy/teensyLC.html
Teensy 3.2 has 64 kb SRAM.
I can easily change the keybrd_DH firmware and my bread board to Teesny LC or Teensy 3.2 and have it tested for you.
Changing the PCB would be more work, and I don' know how to design PCBs.

I can update the PCB layout and schematic if needed. The "bad news" seems to be that the teensy 2.0 and teensy LC / teensy 3.x do not have the same footprint. This means that a new version of the PCB would be needed.

Time has passed since the PCBs were originally created, is it worth it to upgrade to a teensy LC /  teensy 3.x? If so which one should we use? It does not seem to cost that much more than a 2.0 where the LC seems even cheaper.

[wolfv]

I can update the PCB layout and schematic if needed. The "bad news" seems to be that the teensy 2.0 and teensy LC / teensy 3.x do not have the same footprint. This means that a new version of the PCB would be needed.

Time has passed since the PCBs were originally created, is it worth it to upgrade to a teensy LC /  teensy 3.x? If so which one should we use? It does not seem to cost that much more than a 2.0 where the LC seems even cheaper.

Get the Teensy LC, unless the trackball needs more SRAM.
You can compile the firmware to see how much SRAM is needed before deciding.

Consider at total redesign of the PCB.
The current PCB is reversible - one design for both left and right hands.
It would be much simpler to have two separate PCB designs, one for the left hand and one for right hand.
Easier for you to design, and easier for novice users to trouble shoot.
I had a hard time trouble shooting the reversible PCB because it has traces crossing all over the place.

[OldDataHands]

This is not a simple thing:

---snip---
Get the Teensy LC
---snip---

Both the teensy LC and the teensy 3 are 3.3v devices, which isn't helpful here.
That isn't to say that they would be impossible to use, but certainly more complicated.

Relevant info:

The 5.0v ATMega32u4 allows you to make more of the 4mA going through the
IR LEDs (you can drive two at a time) and use the same output for powering
the matching phototransistors. The 20mA @5v drive capability of the pins allows
for driving 6 IR LEDs _and_ 6 phototransistors off of one output pin. Yay Atmel.

Most of the outputs on the TeensyLC are capable only of sourcing 5mA @3.3v.
Seems to me like you _might_ get away with driving 2 IR LEDs and 2 phototransistors.
However, now the switch matrix gets to be rather rectangular i.e. 2x13 (needing 15 pins). Not good.
There are a couple high-drive pins which can provide 20mA (like the Atmel) so you might
be able to get away with a 4x6 plus 1 partial row (only 11 pins)  (similar to my first design)
Those high-drive pins are even available. Yay Freescale (if you're careful).

Disappointingly, the chip in the Teensy 3.2 has a max drive capability of 9mA on some pins, 2mA on most at 3.3v. Boo Freescale.

The PCA9655E I2C I/O expander is perfectly capable of driving the switch matrix at 5.0v,
but is unable to supply enough current at 3.3v, and the PCA9655E has relatively high
drive capabilities compared to many of the other options. So now you're talking about using
an I2C level shifter to talk to a 5.0v IOE with your 3.3v micro, different voltages on one side
of the keyboard than the other, different resistor populations from one half to the other...

Again, not impossible, but not clean or simple to get right.

[invultri]

This is not a simple thing:

---snip---
Get the Teensy LC
---snip---

Both the teensy LC and the teensy 3 are 3.3v devices, which isn't helpful here.
That isn't to say that they would be impossible to use, but certainly more complicated.
[snip]

Clear. That basically means a redesign of most of the board. Since I am already busy with the 3d modelling that will have to wait, maybe even till after I made the first proto.
(My first thought would be to use the PCA9655E for both sides)

Edit: @wolfv here is some example code on using that optical sensor (https://github.com/mrjohnk/ADNS-9800/blob/master/PJRC-Teensy-Example/). To my untrained eye "it does not seem like a lot of bytes", can they be crammed into the teensy2 on top of the other firmware?

[wolfv]

"it does not seem like a lot of bytes", can they be crammed into the teensy2 on top of the other firmware?

Maybe if the mouse-move keys are removed.
The track ball also brings up another issue.

Teensy needs to continuously read the track ball's output, except when a key is pressed.
Currently Teensy 2.0 uses I2C to poll PCA9655E one row at a time.
I2C is slow.  Most of the Time Teensy is simply waiting for poll results.
The firmware would need to be rewritten to use interrupts.
Interrupts are complicated and implementing interrupts consumes RAM.

I have not used interrupts before, so I it might take me until October to get that working.
As far as I know, I/O expander interrupts have not been done on Arduino, so it might be beyond my technical abilities.
I will have time to look into it in September.

Another way would be to poll the I/O expander using SPI.
Advantages of SPI compared to I2C:
 * much faster (the ADNS-9800 Laser Motion Sensor uses SPI)
 * simpler
 * uses less SRAM
Advantages of I2C:
 * only needs 4 wires (SPI needs 6 wires)
But SPI would require a different I/O expander, requiring a PCB redesign.

Teensy in on the left hand.
If the trackball is on the right hand, you will need additional SPI wires connecting left and right PCBs.
Ideally a trackball and Teensy would be on the same PCB, so fewer connecting wires are needed.
Would be nice for lefties, if the PCBs where left-right reversible, so that trackball and Teensy are always on the same hand.

Interrupts and/or SPI I/O expander should be tested on a breadboard before making changes to the PCB.

Adding a track ball would be cool, but it would take a lot of time and effort.

Also, radar chips may make the trackball obsolete - https://geekhack.org/index.php?topic=83044.msg2205718

[invultri]

Another way would be to poll the I/O expander using SPI.
Advantages of SPI compared to I2C:
[snip]

How about distance requirements? The left to right side connection is quite long, I also assume a different cable between left and right needs to upgraded with a 4 wire variant (cat 6 or something)? I think going that road would be difficult indeed or at the very least I would need to re-learn a lot about electronics. Using an io expander on both hands would free up some pins on the controller however. The MCP23S17 is able to source and sink 25mA on all io pins and can be driven on both 3.3v and 5v, according to my quick reading of its datasheet. Warning! I am not an electronics designer

[OldDataHands]

---snip---
The MCP23S17 is able to source and sink 25mA on all io pins and can be driven on both 3.3v and 5v, according to my quick reading of its datasheet. Warning! I am not an electronics designer

The MCP23S17 is spec'd ( Voh )as being able to drop 0.7v on output high while sourcing only 3mA at VDD=4.5v. This isn't very suitable, and suggests that it will drop quite a bit more voltage while sourcing the 25mA which is possible without causing immediate damage. The situation is typically
worse at lower VDD and is almost certainly unfit to do the job at 3.3v. I would not use this part as the datasheet doesn't cover the voltage behavior at the ~20mA we need and I don't want one part to work and have the next not work. We don't need extra headaches.

Regarding SPI v. I2C: Speed isn't really too much of an issue here, at least regarding scanning the switch matrix. I2C at ATMega32u4 speeds is more than capable... however wolfv is right to note that we would have a problem if we also wanted to continuously monitor a trackball on the same bus.
Neither SPI nor I2C are really designed for running through a long cable, but running at low speeds
helps to achieve robust/reliable communications and reduced emitted EM radiation.

It might turn out to be reasonable to run the PCA9655E at 5v from the teensy 3.2 because I remember hearing that the micro in the teensy 3.2 had 5v tolerant I/O.

[wolfv]

How about distance requirements? The left to right side connection is quite long

The keybrd library debouncer has error correction. https://github.com/wolfv6/keybrd/blob/master/src/Debouncer_Samples.cpp
I tested this with 10 feet of flat telephone wire between Teensy 2.0 and MCP23018 (I2C).  It was flawless.

I also assume a different cable between left and right needs to upgraded with a 4 wire variant (cat 6 or something)?

Or eSATA cable.

Using an io expander on both hands would free up some pins on the controller however.

Shift registers is another way to free up pins.

[OldDataHands]

----snip----
I have just send a pull request to the thumb_work branch where I have changed the pads on the finger unit to have the same solder bridges as on the thumb. I would like to know 2 things:
1) Did I brake anything with this change?
----snip----

Hi Invultri,

I've had a first glance at your changes:

1) The silkscreen which indicates where to place a bridge is now off-center in your version and partially over the pads. This needs to be cleaned up.

2) Why did you go up to 6mil for the gaps?  regack's work (https://geekhack.org/index.php?topic=41422.msg1191731#msg1191731) indicated that 5mil was the right answer and that's what is on the thumb PCBs...

[invultri]

----snip----
I have just send a pull request to the thumb_work branch where I have changed the pads on the finger unit to have the same solder bridges as on the thumb. I would like to know 2 things:
1) Did I brake anything with this change?
----snip----

Hi Invultri,

I've had a first glance at your changes:

1) The silkscreen which indicates where to place a bridge is now off-center in your version and partially over the pads. This needs to be cleaned up.

2) Why did you go up to 6mil for the gaps?  regack's work (https://geekhack.org/index.php?topic=41422.msg1191731#msg1191731) indicated that 5mil was the right answer and that's what is on the thumb PCBs...

1) I can fix that
2) that was after I went browsing for PCB manufacturing places, 6mil seems more common. I can revert the changes no problem (yay for git )

I was also wondering why the finger carriers are off-center by 0.14,0.14 mm, was there a specific reason ?

[OldDataHands]

I was also wondering why the finger carriers are off-center by 0.14,0.14 mm, was there a specific reason ?

Can you explain in a bit more detail which measurement you're referring to?
Is this the PCB, or the OpenSCAD model?
Either way, sounds more like an error than intentional...
Off-center relative to what?

[invultri]

I was also wondering why the finger carriers are off-center by 0.14,0.14 mm, was there a specific reason ?

Can you explain in a bit more detail which measurement you're referring to?
Is this the PCB, or the OpenSCAD model?
Either way, sounds more like an error than intentional...
Off-center relative to what?

If you open the footprint of the finger unit and examine the pads (hover + e) you will see that they are not centered around 0,0. The silk mask cross is at the center of the footprint. For now I take that offset into account when making the finger unit design, as that is where I noticed it (yes I did measure up all 80 via's and made the pcb in openscad to do a check if everything fitted, that is how I noticed.)

Anyway, I will fix the silkscreen and revert back to 5mil today.

Edit: pull request updated. I hope this time its ok, PCB New really hates these pads, unconnected pad warnings which make no sense on several (no pattern to be found) and all of them are to close. Please check it and tell if anything else needs changing.

[invultri]

Status update:
- The 3d printer has been assembled (it arrived 2 weeks earlier than expected)
- System of writing code in openscad is in place
- Porting finger unit to new system is in underway (meaning I dare to release it to the public)
-- Code will probably end up in a new place as its a full reimplementation with no link to @OldDataHands work (available under gpl of course)
-- Doing my best to keep the footprints compatible
- Looking if I can use XRA1405 as io-expanders with SPI

@OldDataHands, did you design the leds to use only 5mA of power on each parallel path?

[OldDataHands]

Hi invultri,

Looking forward to seeing your work!

The diodes go two in series then a 470-ohm.
The phototransistors go over a 2.5kohm.

each diode pair over the 470ohm will pull roughly 5mA and there are 3 = ~ 15mA
each phototransistor could take ~ 1.8mA @5v and there are 6 per row = ~=11mA

These are all rough, as they aren't accounting for the exact voltage drop from the I/O expander's output.

Short version: XRA1405 doesn't provide enough juice to run the circuit that I've designed.

Details:

The XRA1405 that you're referring to could be run at 3.3v, and is spec'd to be damaged at 25mA on an output.
The VOH for its gpio pins at 3.3v is spec'd at 2.6v@8mA. A _very_ crude approixmation of the effective resistance
on that output is around 87Ohms ((3.3v-2.6v)/8mA=87.5Ohm) which might lead you to believe that you could
have an output voltage as low as 1.1v if you actually managed to pull 25mA out of it.  In practice, you should
expect that once you get to around 12mA load you would start to drop some LEDs out of the ctircuit as they would
no longer have enough voltage to turn on (still assuming that 87.5Ohm output resistance).

Maybe you can do some testing and see if you really need to push 5mA through the IRLEDs. Maybe they would
do a perfectly great job at 1mA? That'd help. Maybe you can run the phototransistors at a much lower current too.
These would all help make it possible to use that chip. I have done no research/testing in that direction.

[OldDataHands]

One more (**important**) thing: The IR LED spec allows for a worst-case forward voltage of 1.6v @ 20mA
and gives no guidance regarding the shape of the I/V curve in those parts. It might be that the worst-case
actually happens and you'll get some parts with around >= 1.4v forward voltage in order to turn on. You're
then really pushing the limits of operation in trying to drive two IR LEDs at one time no matter how little current.

[invultri]

One more (**important**) thing: The IR LED spec allows for a worst-case forward voltage of 1.6v @ 20mA
and gives no guidance regarding the shape of the I/V curve in those parts. It might be that the worst-case
actually happens and you'll get some parts with around >= 1.4v forward voltage in order to turn on. You're
then really pushing the limits of operation in trying to drive two IR LEDs at one time no matter how little current.

It seems that I did manage to complete the "code" for the finger unit. But.. I seem to get into a bind with the license things. Is it ok for me to just put my own name as the copyright notice? there is 0 code shared so I guess that is fine? (https://www.gnu.org/licenses/gpl-howto.html). The bigger issue is that I would like to use the name "dodohand project" meaning that it would loop back to your version. Complicated! What would be the best way to get this code out there?

As for the xra1405 I would actually let them sink 5v. This would mean they pull ~15mA out of 24 which seems safe. If not for that worst case of 1.6v forward it would have been possible to put 3 leds in series. This will of course require a separate VCC line to the leds. Since the xra1405 is 5v resistant on the SPI interface as well we could use any of the 3 teensy types. I will create a schematic first and then provide it here for discussion. I think I need a small break from union, difference, intersection, translate, rotate etc

[wolfv]

Have you considered a photointerrupter with Slot Type transmission?
The IR emitter potentially needs less power because optic alignment allows narrower focus.
Digi-Key has filters for "Current - DC Forward (If) (Max)" and "Current - Collector (Ic) (Max)":
 http://www.digikey.com/product-search/en/sensors-transducers/optical-sensors-photointerrupters-slot-type-transistor-output/1967054

[OldDataHands]

there is 0 code shared so I guess that is fine?
(...snip...)
The bigger issue is that I would like to use the name "dodohand project" meaning that it would loop back to your version. Complicated! What would be the best way to get this code out there?

As for the xra1405 I would actually let them sink 5v. This would mean they pull ~15mA out of 24 which seems safe.
(...snip...)

If your source code is merely inspired my mine, and not copied from mine, then your name is only only one in the copyright.

I am perfectly happy to have The DodoHand Project be an umbrella under which both could live. Please proceed with that.
I'd prefer that we concentrate eyeballs and thoughts in one spot anyhow.

One of the reasons that I chose to have the power switched rather than the ground is that it was a simple way to ensure that stray light hitting the phototrasistors of switches not currently under evaluation in a column (of the switch matrix) didn't have a power source with which to raise the voltage on the sense line. (i.e. if only one phototransistor on a column/sense line has power at a time, then the others that share the sense line can't contaminate the evaluation).

[invultri]

Have you considered a photointerrupter with Slot Type transmission?
The IR emitter potentially needs less power because optic alignment allows narrower focus.
Digi-Key has filters for "Current - DC Forward (If) (Max)" and "Current - Collector (Ic) (Max)":
 http://www.digikey.com/product-search/en/sensors-transducers/optical-sensors-photointerrupters-slot-type-transistor-output/1967054

I did in the past and had to conclude that I could not get them to fit.

If your source code is merely inspired my mine, and not copied from mine, then your name is only only one in the copyright.

I am perfectly happy to have The DodoHand Project be an umbrella under which both could live. Please proceed with that.
I'd prefer that we concentrate eyeballs and thoughts in one spot anyhow.

One of the reasons that I chose to have the power switched rather than the ground is that it was a simple way to ensure that stray light hitting the phototrasistors of switches not currently under evaluation in a column (of the switch matrix) didn't have a power source with which to raise the voltage on the sense line. (i.e. if only one phototransistor on a column/sense line has power at a time, then the others that share the sense line can't contaminate the evaluation).

@copyright Ok, I have set everything up for an upload to github. I will create a branch in my fork with my edition so we keep things together. This will likely happen today (gmt +1).
@switching power thanks for clearing that up, I was wondering why you wanted to source the led's and transistors. That is actually pretty clever

Update: Finger unit uploaded. Its in the alternative branch on my fork: https://github.com/christianvdstap/dodohand/tree/alternative . Now.. do not turn on your printers just yet, I need to print it myself and see what the result is like.

[wolfv]

DodoHand Finger clusters, PCB, and  firmware are done.
3-D printed thumb cluster is the only missing part.
Currently invultri is working on the 3-D printed thumb cluster, and might change the electronics to accommodate a trackball.

Do you have access to a DataHand?

[invultri]

The dodohand is a slow moving project, no full working prototype (that I know off) exists. OldDataHands started it by doing a lot of the mechanical legwork, Wolfv is working on the software and a prototype case was provided by Turbinia. On and off others have shown interest in creating some variant of this project and create a working unit. I am one of those others

So for what is needed... I guess just about everything. I like to leave the publicity (like website) to OldDataHands, I do like the current logo. It also seems that there is no concentrated effort but everyone is either making his / her own variant or is specializing on specific part. This makes it hard for me to indicate what exactly you could help with. Once I upload the schematic, a review would be appreciated.

My status is currently:
- Created drafts of finger unit and thumb unit 3d designs, printable via extrusion
- Assembled the 3d printer
- Started ordering some mechanical components (will order sheet metal 0.38mm thick next week)
- Created an initial version of the 3d finger unit (available in my clone on the alternative branch)
- Created an initial schematic of the finger PCB utilizing SPI (finalizing it, screenshots / upload probably in the coming week)
- Started working through electronic devices, fifth edition by Floyd
Next up (no specific order, non exhaustive):
- Creation an initial version of the 3d thumb unit based on the draft
- Create PCB layout for SPI variant of the finger PCB
- Design casing based on the blender prototype
- Design palm rests
- Print parts
- Order and assemble PCB
- Iterate until done

@wolfw and others
Poor picture: http://i.imgur.com/atAJUf3.png
Todo:
- Wondering if I will replace the 74165 with a XRA1402 to get rid of the buffers
- Need to add power connector for expansion boards, unless the expansions do not pull more than 100mA due to ribbon cables
- Considering to add a breakout pin for unused MCU IO

[wolfv]

invultri,
Could you please post a schematic at higher resolution?  I can't read half the text.

I got another idea  .  I don't know enough about electronics to judge if this idea is practical or just nonsense.
How about using Hall effect sensors instead of optics?
Some IC hall effect sensors have very low power requirements, so they can work with the XRA1405 or MCP23S17 I/O expanders.
Some IC hall effect sensors are tiny, so they can fit inside the 3-D printed parts.
For example, the Allegro A1171 is tiny and low power: http://www.allegromicro.com/en/Products/Part_Numbers/1171/1171.pdf

This cut-away picture of Apam IHS switch shows how magnet and Hall effect sensor are arranged: http://media.digikey.com/PDF/Data%20Sheets/APEM%20Components%20PDFs/IH_%20Series.pdf
For the magnet to provide DataHand-like tactile feel, the magnet would normally be in contact with steel.
Imagine an arrangement similar to the aforementioned Apam IHS, but with steel placed above the magnet, with magnet traveling between steel and sensor.

Hall effect switches have been used in production keyboards: https://en.wikipedia.org/wiki/Hall_effect_sensor#Keyboard_switch

There are many small IC hall effect sensors to choose from: http://www.digikey.com/product-search/en/sensors-transducers/magnetic-sensors-switches-solid-state/1967446

[sinusoid]

How about using Hall effect sensors instead of optics?

Works.
I did a bunch of tests with a Honeywell 95A329 some years ago, though it's a sensor, not a switch. I had to manually set the actuation point in software, and I was using a single analog input line in the mcu per sensor.

If you get a good switch the latency is omittable, and the MTBF is out through the roof. AFAIK Most brushless DC motors use these as sensors for coil switching cycles.

[invultri]

invultri,
Could you please post a schematic at higher resolution?  I can't read half the text.

*snip*
Hall effect switches have been used in production keyboards: https://en.wikipedia.org/wiki/Hall_effect_sensor#Keyboard_switch
*snip*

@schematic I am still refining it. I hope to be able to push it to git this week, then you can just use kicad to oogle it. I will be sure to post here once I do.

@hal yes they work, I have one on the old 3d printer and it can be tuned very pricesly. Tuning it exactly right was a pain in the bum however, now imagine doing that for 52 of them . So I did consider hal sensors but decided it had to many unknowns to work with. I would have to make a lot of test switches to find a proper setup, especially since the rare earths that we are going to use are quite strong and the metal clip is in the way of the "ideal" position to place the hal sensor. So I did consider it but did not pursue it further since I think working with the IR leds is easier. At least for V1, get it close enough to the orginal mechanisms to have a base to work from.

Edit: I have just pushed the schematic (my fork, alternative branch, kicad_fingers_spi.sch etc)
Fully SPI based
- 6 primary SPI addresses for "fast" access, 3 on each hand.
- 1 primary SPI address on each hand are used for the driver (NCV7608)
- 1 primary SPI address for the 5v tolerant GPIO (XRA1404 or XRA1403)
- 1 primary address on each hand for another input device (like that trackball)
- Each hand has a dedicated SPI bus (so you can do things in parallel)

Driver has
- 5 lines to drive the led rows (row0-row4)
- 3 generic drive lines (OUT0-OUT3)

GPIO has
- 6 input read lines (col0-col5)
- 4 secondary SPI addresses SS3-A - SS7-A. Secondary IO is only enabled when SS1-A is high, this allows access to the gpio after using the secondary spi device.
- 2 extra inputs on a 4k7ohm pull down
- 3 general purpose IO

Feel free to shoot with constructive feedback

[famadorian]

I'm so god damn excited for this project;)

I've never had a datahand, but I've dreamt of it all my life.

Having this wirelessly in a pair of gloves inside VR/AR and I'm entering cyberspace;)

[jamescobalt]

Oh, wow! So excited for this project. I'm typing this on my Datahand. I love it, but there's room for improvement (how it sits on the lap, size of the housing, how mouse movement is handled, distance between keys, etc). My understanding is the patent has expired, so if anyone wants to go commercial, I want in! (marketing background here)

[invultri]

Just a quick heads up, I am still making (slow) progress on the modeling effort. The thumb carrier (the big button) is up in github (https://github.com/christianvdstap/dodohand/tree/alternative). The next thing I will work on is to port the thumb side buttons from my doodle to the new style.

Once I get some feedback on the schematics I made for the finger unit I will also start creating the PCB for it.

[wolfv]

Once I get some feedback on the schematics I made for the finger unit I will also start creating the PCB for it.

Thanks for the update.
What editor are you using for the .sch files?  Or please recommend a viewer.
https://github.com/christianvdstap/dodohand/blob/alternative/sch_and_pcb/kicad_fingers_spi.sch

Will you be using the XRA1405?  If so, I can add it to the DodoHand firmware.

[invultri]

Thanks for the update.
What editor are you using for the .sch files?  Or please recommend a viewer.
https://github.com/christianvdstap/dodohand/blob/alternative/sch_and_pcb/kicad_fingers_spi.sch

Will you be using the XRA1405?  If so, I can add it to the DodoHand firmware.

I picked the XRA1404 (same as the 1405 but without the level shifter) for the IO and a NCV7608 for driving the leds. The program used is Kicad (http://kicad-pcb.org/). Btw, I did not keep to the SPI pin numbering of the default teensy libraries but that can be changed.

Edit:
To make it a bit easier here is a PDF version: https://github.com/christianvdstap/dodohand/blob/alternative/sch_and_pcb/finger_sch_spi_v1.pdf

[wolfv]

Btw, I did not keep to the SPI pin numbering of the default teensy libraries but that can be changed.

Please use Teensy default SPI pins (which are Arduino default SPI pins) because the keybrd library is an Arduino library and assumes Arduino compatibility.

Thanks for the PDF schematic.  Separating the controller and matrix driver is an elegant way of powering the LEDs.  Nicely done.
I have a couple of questions though.

The way I understand the schematic, there are two Matrix drivers:
1) NCV7608 on left board
2) XRA1404 on right board
Since the Teensy 3.2 is not driving any LEDs, could you use a Teensy LC instead (costs $8 less)?

The schematic shows three indicator LEDs (optional fancy lights) where as DataHand has four.  Is that intentional?

[invultri]

Btw, I did not keep to the SPI pin numbering of the default teensy libraries but that can be changed.

Please use Teensy default SPI pins (which are Arduino default SPI pins) because the keybrd library is an Arduino library and assumes Arduino compatibility.
I can, but there are only 2 SS pins and I want 3

Thanks for the PDF schematic.  Separating the controller and matrix driver is an elegant way of powering the LEDs.  Nicely done.
I have a couple of questions though.

The way I understand the schematic, there are two Matrix drivers:
1) NCV7608 on left board
2) XRA1404 on right board
Nope the NCV7608 is effectively 8 mosfets in a chip and is only used to drive VCC down something. So it is used on both hands. The XRA1404 is used to read the matrix AND to enable several other SPI devices. This means for the hand that will have the teensy you use the SPI SSX-A addresses and for the other hand the SSX-B addresses (B becomes A again via the RJ45 connector on the other hand) See also a couple of posts up where I have the full feature list.
Since the Teensy 3.2 is not driving any LEDs, could you use a Teensy LC instead (costs $8 less)?
Certainly, this design is simple IO only. They are the same footprint, the design would not change (other than the label)

The schematic shows three indicator LEDs (optional fancy lights) where as DataHand has four.  Is that intentional?
Other than having 8 fets, needing 5 to drive the matrix and having only 3 left. Nope. There is a spare IO on the XRA1404 however ... might be able to sink a single led on that one. In my case I am considering no leds and use a SPI enabled display for status things.

Answers in bold
If you want any specific questions answered just post in here, or contact me on IRC.

[wolfv]

Thanks invultri.

I am still scratching my head.
How does the schematic indicate which parts are on both hands, and which parts are on just one hand?
Please list the components for each hand? e.g.

Left hand:
    one Teensy 3.2 or LC
    one NCV7608
    one XRA1404
    one 74HC126

Right hand:
    one NCV7608
    one XRA1404
    one 74HC126

[invultri]

Thanks invultri.

I am still scratching my head.
How does the schematic indicate which parts are on both hands, and which parts are on just one hand?
Please list the components for each hand? e.g.

Left hand:
    one Teensy 3.2 or LC
    one NCV7608
    one XRA1404
    one 74HC126

Right hand:
    one NCV7608
    one XRA1404
    one 74HC126

The short answer:
The only difference is Teensy vs Regulator. On the side with the teensy we can get the 3.3v directly from the teensy (at least from the non LC version, I need to check that) on the other hand the regulator is used to make the 3.3v.

Longer answer:
I think the workings of the mad contraption are not clear. Lets first ignore the entire 2 hand situation and pretend we only have 1 matrix to control.
In this case there are 2 major SPI components to interface with (via the SPI signals labeled with A):
1) NCV7608. This is used for outputting VCC to demanding circuitry. 5 of the pins (row0 to row4) are used to drive the matrix. This uses SS0 for addressing. This works the same way as the original schematic "driving" the matrix.
2) XRA1404. This is used to read the matrix (col0 to col5) (we are ignoring the extra SPI addresses for now and thus the 74HC126). This uses SS1 for addressing.

In this situation to get a measurement from the matrix the following things need to be done:
1) The correct row (and only that row) needs to be selected on the NCV7608, using SS0
2) The columns need to be read on the XRA1404, using SS1
3) The row needs to be deselected on the NCV7608, using SS0
4) Goto 1 for the next row

Now including the other hand: You would do the exact same thing, just using the SPI signals labeled with B. Nothing different. The B signals on the side from the teensy are cleverly connected to the A signals on the other hand via overlapping the top and bottom RJ45 as indicated in the text on the schema connecting A to B electrically. This means for the software: Do the exact same thing, just use the other set (B) of SPI signals.

Bonus stage (all of this is optional for extra fancy dodohands)
There is a third address (SS2) which can be used directly, this I would like to reserve for a pointing device, which is not included in the schematic other than it being exposed via the J7/J8 connector pair.

A facility is provided for even more chip addresses using extra io pins on the XRA1404 (SS3 to SS6), this is where the 74HC126 is used. To get to these addresses the following needs to be done:
0) During initialization SS3 to SS6 pins should be set to high (only once)
1) Select the XRA1404 with SS1, this will disable all chips connected to SS3-SS6 because the 74HC126 will put the outputs in a high impedance state and the SS lines will be driven high via the pullup.
2) Set the pin for one (and only one) of the extra SPI addresses to low
3) Deselect the XRA1404, this will remove the high impedance state of the 74HC126 and the low signal on the selected address is propagated
4) Now the selected chip can be interfaced via the SPI lines
5) Select the XRA1404 with SS1 again (the same thing as in 1 happens)
6) Set the address pin to high again
7) Do the next thing

Ps. Bed time now, next answer will lag ~8 hours.

[wolfv]

Thanks for the detailed answer.
Using a shift-register matrix might be simpler.

SNx4HC595 is 8-Bits of SIPO shift registers used for strobing rows.
SNx4HC165 is 8-bits of PISO shift registers used for reading columns.

A SIPO shift register strobes a row with 5 volts, while 3.3 volt PISO shift registers read the columns.
The 5 volts would feed the LEDs and would not cook the 3.3 volt circuit.

Board with trackball would have:
    Teensy LC
    5x6 matrix
    8 SIPO shift registers (5 volts) to strobe 5 rows, and 3 indicator LEDs
    6 Teensy LC pins (3.3 volts) to read 6 cols

Board w/o trackball would have:
    5x6 matrix
    8 SIPO shift registers (5 volts) to strobe 5 rows, and 3 indicator LEDs
    8 PISO shift registers (3.3 volts) to read 6 cols

This setup would use a total of 8 wires to connect left and right boards:
    3.3v power
    5.0v power
    gnd
    clk
    MOSI
    MISO
    SS PISO
    SS SIPO

Teensy LC and SNx4HC595 are connected by clock, MOSI, and Slave Select wires.
Teensy LC VCC is 3.3 volts.  SNx4HC595 VCC is 5 volts.
Will the clock, MOSI, and Slave Select wires safely remain at or below 3.3 volts?

I will run some tests on my breadboard and post the results in a few days.

[invultri]

Thanks for the detailed answer.
Using shift a register matrix might be simpler.
*snip*
I will run some tests on my breadboard and post the results in a few days.

I found it unwieldy to create the circuitry with just the shift registers (I did try). It lead to more chips, getting sufficient driving current was annoying and wrecking them via bugs in software was also an issue. OldDataHands is right in driving the matrix as opposed to sinking since that eliminates the false positives. I also like that the circuitry is symmetrical and I am considering to give the microcontroller its own PCB.

I am interested in how your experiment goes, I would also like to see a drawn schematic of your plans.

[wolfv]

I found it unwieldy to create the circuitry with just the shift registers (I did try).

I guess it's not a simple as I had imagined.

The following is a summary of considerations for the path forward to adding a trackball to DodoHand.

The DodoHand firmware is large because the DataHand layer scheme is complex.
It's unfortunate that the DodoHand firmware consumes all of Teensy 2.0's available SRAM, leaving no room for the trackball firmware.

The trackball requires continuous monitoring by the controller.
Currently, DodoHand uses the I2C communications protocol to poll the PCA9655E IOE.
The controller is always waiting on I2C, so it has no time to monitor the trackball.
There are two ways to reduce wait time, leaving the controller with enough time to continually monitory the trackball: Interrupts and SPI.

1) Interrupts
Using IOE interrupt is complicated and would consume SRAM that Teesny 2.0 can't spare.

(edited) there is enough power to keep the LEDs on:
    26 keys * 20 mA/(2 LEDs in series) = 260 mA < 400 mA total package limit for PCA9655E

    All the IR emitters at DigiKey are at least 20mA.

    From PCA9655E data sheet
    Table 4. DC ELECTRICAL CHARACTERISTICS
     6. Each bit must be limited to a maximum of 25 mA and the total package limited to 400 mA due to internal bussing limits.

2) Use SPI protocol to poll IOE
SPI communications protocol is much faster than I2C, leaving the controller with enough time to continually monitory the trackball.
But changing to an IOE with SPI is complicated because their pins don't have enough power for the optic switches.

Maybe someone could figure out if DataHand uses polling or interrupts by putting a logic analyser on a DataHand.

3) Two controllers
You could use two controllers (this might be the simplest):
* one controller to emulate the DataHand layout
* one controller dedicated to the trackball

Given today's available parts, there is no easy way to make DodoHand with both optic switches and trackball.

4) Hall effect switches
Hall effect switches have very low power requirements.
Changing DodoHand to Hall effect switches would make using I2C with interrupts or SPI easier, which would then make adding a trackball simple.

But making Hall effect switches is a long project.
Like invultri said about Hall effect switches, "would have to make a lot of test switches to find a proper setup".
(edited) Changing to Hall effect switches may not be worth the effort.
However, if they are implemented, there are advantages to adding Hall effect switches before the trackball.

Its a lot of work to:
1) add a trackball to DodoHand (because optic-switch power requirements)
2) then change DodoHand switches from optic to Hall effect

DodoHand could be usable sooner, and effort saved, by changing the order of innovation:
1) finish DodoHand using Teensy 2.0 and PCA9655E
2) change DodoHand switches from optic to Hall effect
3) then add a trackball to the DodoHand controller (easy because Hall effect switches have very low power requirements)
(Hall effect sensor information is in Reply #584)

That about sums up the considerations for adding a Trackball to DodoHand.  Did I miss something?

[wolfv]

Hi invultri,

I started working on a shift-register matrix when I thought of a simpler way:
One row of shift registers to read 26 keys.
A side effect of using just one row is that the scans are very fast, which leaves the controller more time for monitoring the trackball.

This example uses two SN74HC165N daisy chained together for a total of 16 shift registers:
https://github.com/wolfv6/keybrd/blob/master/tutorials/tutorial_4b_split_keyboard_with_shift_registers.md
DodoHand would use four SN74HC165N daisy chained together for a total of 32 shift registers.

Teensy LC Vin pin has enough power to turn on all 52 IR LEDs on DodoHand simultaneously.
IR LED forward voltage: typ. 1.2 at 20mA
26 LEDs * 20 mA/(3 LEDs in series) = 173 mA per hand, 347mA if both hands are always on.
USB 2.0 can handle 500mA.

If you want to switch IR LEDs off between polings, let a buffer amplifier power 26 LEDs.
This would reduce USB current and extend IR LED life.
LMC7101 might be a good buffer amplifier, but I don't understand the datasheet's specifications:  http://ww1.microchip.com/downloads/en/DeviceDoc/lmc7101.pdf
There might be a suitable buffer amplifier to drive LEDs with a constant current.
That would eliminate IR LED current-limiting resistors.
Use Scanner_ShiftRegsPISOMultiRow object (instead of Scanner_ShiftRegsPISOSingleRow), it strobes what ever pin number Row passes to scanner.

Indicator LEDs can be controlled by a SN74HC595.

6 wires connect the left and right hands.
Add 2 wires if you want indicator LEDs controlled by a SN74HC595.

I tested the tutorial's SN74HC165N daisy chain example with tactile switches at 3.3 volts.
I don't have the optic-switch parts on hand to test with 5 volts.
I also don't have a buffer amplifier to test.

Do you want to give it a try?
The next step would be to replace the tactile switches, on the tutorial's breadboard example, with optic switches.

If you decide to go with the a single-row of shift registers for 26 keys, I can write an example with indicator LEDs controlled by a SN74HC595.

[wolfv]

invultri,

I found some optic-switch parts in my other box.  I will write the firmware and test it on a breadboard.
It will be without buffer amps, but that makes no difference to the firmware.
Will post pictures and results in a few days.