A bold project! Keep us posted. :)
No idea what this is but looks fancy.
No idea what this is but looks fancy.
Stay tuned!
Stay tuned!
I wonder if the 3D printer I just got has the resolution to print the parts to the tolerances you need.
Stay tuned!Show Image(http://ergodox.org/datadox/datadox.jpg)
I think it is IR / optical what is the purpose of the magnets ?
How does the prototype feel compared to the OG Datahand?For a first, relatively blind effort, I am happy that it is reminicent of the original. Howevet, I need to improve several aspects of it. First, The N/E/S/W buttons are a bit mushy. This is a result of the magnet being able to pivot a little bit on the end of the steel insert rather than strictly pivoting upon the bottom end of the key lever. Second, the center button is just a bit too firm. It has a wonderful release, but I need to find a way to reduce the force required. The N/E/S/W issue can easily be addressed by a more careful mechanical design. I think the central button issue can be addressed by using less steel, perhaps thinner shim stock. In any case, the prospects for achieving a good feel are encouraging.
Looking forward to another update! =)¨
noob question... how does one type using 8 keys?
:O that would take a long time to get used to! But I can imagine the speed one can achieve once he/she masters it!
Let me just say this as a former Datahand owner...there is room for improvement over the real deal. The finger side-to-side movements required were not comfortable, the individual keyboard boxes could have been a bit smaller which could improve placement, etc.
Do you have any plans for the thumb button?
...
Let me just say this as a former Datahand owner...there is room for improvement over the real deal. The finger side-to-side movements required were not comfortable, the individual keyboard boxes could have been a bit smaller which could improve placement, etc. The mouse action was not very good at all. 2 people did some great things...one put an IBM KPD8923 pointer in his unit, and another added some custom scripts to the firmware. Both of these should be on GH.
...
Do you find that you have to rework the parts after you get them?I've chosen the laser sintered nylon process because it is a relatively tough, and cheap, opaque option. It took a bit of effort to open up the long, minimum-separation tubes I created for the opto component leads. I've now made these a bit bigger in the hopes that they will need less attention. Everything else turned out pretty well. Dox used a process capable of finer details in his prototype, but in a translucent material. I'll be interested to hear how it worked out for him.
(Attachment Link)
This video / animation should be available shortly: Not a valid vimeo URL(just don't expect much, and you won't be disappointed.)
I got my first PCBs back from OSHPark, and they need some cleanup. The edge cuts are not neat, and need to be trimmed down in places where they were snapped apart.
I liked that you could just order 1 of something from BatchPCB, and while the ones from OSHPark are a bit nicer looking, I don't always need or want 3 of something.
I noticed that OSHPark quote $5/sqin for double layer abd $10/sqin for quadruple layer and they also have a minimum order or 3, so is this price per board (so have to multiply by 3) or the total already including 3 copies?
I noticed that OSHPark quote $5/sqin for double layer abd $10/sqin for quadruple layer and they also have a minimum order or 3, so is this price per board (so have to multiply by 3) or the total already including 3 copies?
The $5/sqin covers the 3 copies you'll get. so a 10sqin design will cost you $50, and you'll get 3 copies of it.
hey look! i'm trying to make your guys' designs monetarily feasible to produce!
http://geekhack.org/index.php?topic=43362.0 :D
The added pointer was a PS/2 Trackpoint from an IBM KPD8923. It has a ribbon cable to it's own separate pcb that is separate from the keyboard pcb. It's what I used for the Split Kinesis
Anyway, I wish I had skills with circuit boards, because then I could help out.I've got the PCB aspect reasonably well covered. Now, if you could create a parametric
(Attachment Link)
Do you think that this unit may be the only prototype, or you may need a second/third to dial in the quality/engineering issues?
Do you think that this unit may be the only prototype, or you may need a second/third to dial in the quality/engineering issues?
I can work out the center-stem slop on this prototype, and will do so.
I'll then do another rev of the finger assembly before moving on to
the thumb switches. Fortunately, the PCB didn't need any rework this
time, and I have two spare, and the electronics needed to populate
them.
There are numerous small
details that need to be improved in the three-D model (Can't type
the digit three as I only mapped the letters!) before I get another
set printed. These would address things that made the assembly
a bit slow.
Main point though: It Works!
When do you think it'll be done? and what price will it be at?
When do you think it'll be done? and what price will it be at?
I hope to have the finger assembly done this summer.
I hope to have the thumb switches figured out before
winter is over. Perhaps by this time next year all the
pieces will be ready?
Pricing is pretty far out at this point. I could imagine a
simple, cheap case option allowing a cost of less than
$400, particularly if a group buy allows good pricing on
PCBs and electronics.
Please, could you provide the 3d files?
Would it then be possible for me to get the finger assemblies printed when they're done?
I saw a teensy at your schematic and other IC - what is that for? (the second IC)
When do you think it'll be done? and what price will it be at?
I hope to have the finger assembly done this summer.
I hope to have the thumb switches figured out before
winter is over. Perhaps by this time next year all the
pieces will be ready?
Pricing is pretty far out at this point. I could imagine a
simple, cheap case option allowing a cost of less than
$400, particularly if a group buy allows good pricing on
PCBs and electronics.
Very nice, and you're doing alot of great work.
You said you would release the source code etc, because I only need the (left and right) finger assemblies. I've got another idea for the thumb buttons. Would it then be possible for me to get the finger assemblies printed when they're done?
Sign Me UP!
[ ed ... ] and what I can do on the 3 modelling front.
hey IN, want to write up a geekhack open source license? :DWhy not use one already written?
hey IN, want to write up a geekhack open source license? :DWhy not use one already written?
Sounds like something that may actually really, truly need to happen.the existing open source hardware licenses are a hodgepodge and don't cover hardware/software combinations... i think this we have something genuine to contribute on a more general scale here.
Fortunately.
Sounds like something that may actually really, truly need to happen.the existing open source hardware licenses are a hodgepodge and don't cover hardware/software combinations... i think this we have something genuine to contribute on a more general scale here.
Fortunately.
also that general thing could be named the geekhack general purpose license ad infinitum :D (ggpl lol qq!)
I do prefer GPL or LGPL.hey IN, want to write up a geekhack open source license? :DWhy not use one already written?
The WTFPL is my favorite.
I do prefer GPL or LGPL.hey IN, want to write up a geekhack open source license? :DWhy not use one already written?
The WTFPL is my favorite.
http://opensource.org/licenses
How's the Project going?Progress has slowed (as expected) for the summer, but I have
could anyone provide me with the measurements of a DH? As-in height, width, depth etc?
what good/suitable microswitch to make datahand custom?
For ideas on how to integrate adjustment into the design I would look at the R.A.T. 7 gaming mouse. It is both compact and simple in design and goes along with what you described.
For the thumb cluster the key you press going up always seemed quite small and I have seen that it breaks quite often, so something different there would be good.
If help is needed designing a case, I would be willing. I work with Blender 3D pretty much exclusively, can do Solid Works and ProE as well.
--- Ed: additional awesome links and such removed - please refer to original post ---
...Also the idea being that you could have a fine and coarse mouse were you to choose to have two trackpoints...I feel the need to quote the film "dude, where's my car" and respond to that kick-arse plan with "Dude! Sweet!" :) i never liked trackpoints much due to them never having the right level of responsiveness, that plan just reeks of awesomeness.
The entire assembled datahand would fit on the print bed of the Replicator2x. It measures about 21cm by 12.5cm. It has been designed with machinability fully in mind. Currently it is structured such that it could be made through injection moulding, 3d printing or subtractive processes (milling). I do know a thing or two about machining, 3d modeling/CAD and have had a few things 3d printed through Shapeways SLS. There is no reasonable expectation for this to be comparable in cost to a flat acrylic case, this is markedly more complex. People are spending $150+ for alloy cases, so my current estimates of ~$200 for prototyping cases by SLS are not unreasonable. You seem to assume I have missed some very basic things like putting holes in a plate, I assure you I know how to do that...
I will be using the EasyPoint breakout board from SparkFun to develop the trackpoint. It is pretty much the only reliable source for a high quality pointing device in any volume.
The entire assembled datahand would fit on the print bed of the Replicator2x. It measures about 21cm by 12.5cm. It has been designed with machinability fully in mind. Currently it is structured such that it could be made through injection moulding, 3d printing or subtractive processes (milling). I do know a thing or two about machining, 3d modeling/CAD and have had a few things 3d printed through Shapeways SLS. There is no reasonable expectation for this to be comparable in cost to a flat acrylic case, this is markedly more complex. People are spending $150+ for alloy cases, so my current estimates of ~$200 for prototyping cases by SLS are not unreasonable. You seem to assume I have missed some very basic things like putting holes in a plate, I assure you I know how to do that...
I will be using the EasyPoint breakout board from SparkFun to develop the trackpoint. It is pretty much the only reliable source for a high quality pointing device in any volume.
for scale, what's the diameter of that big button top? that is very complex, and i wonder.. it may be that the makerbot can only make the outer shell to reasonable precision anyway.
(Attachment Link)
This is a cutaway view of one of the finger assemblies.
But the single biggest flaw has always been the mouse functionality; the built in system is simply useless.
[...]
Everyone here seems to be working on the assumption that a trackpoint is the only option for improving the mouse [...]
Maybe other people really like trackpoints a lot, or aren't fans of trackballs, so I don't know how popular this idea is, but it's the one thing I've always, always longed to do to my own datahand (and probably would have attempted years ago if I could afford to buy a spare unit to experiment on).
Regarding cleaning: my clone carries forward the same foibles as the original. It'll be possible to remove the north and south keys, but the interior east and west keys will prevent each other from being removed. once soldered in. The good news is that for $15 you should be able to print a new finger assembly and replace it if it ever dies. That will require soldering though.
Is there any way of improving this issue? E.g. using a shroud around the photo diodes or a different wavelength of light?
Many things could be improved including weight and a slimmer profile.So do you think it weighs too much, or too little?
Is there any way of improving this issue? E.g. using a shroud around the photo diodes or a different wavelength of light?
3D printing allows some things which are
not achievable with injection molding.
Where on the original the eye of the
phototransistor slides down a slot,
exposing its top side to the room, my
design has a small round window which
the eye snaps into and which serves to
shield the eye from the room. The whole
transistor also snaps into a shroud at the same time to limit ingress of light through the top of the transistor case. I expect this
to be a marked improvement, but have no
data to back that up.
psp joystick? are they easy/cheap to come by from spares dealers then? personally i think that one of them would soundly kick the arse of any of the laptop nub thingies that i've used (not that i've used one for years now mind) so it sounds good to me :)2-3 bucks on ebay, usually with free shipping and a **** quality screwdriver. For example, here (http://www.ebay.com/itm/3D-Analog-Joystick-Stick-Button-Replacement-Repair-Parts-for-Sony-PSP-1000-1001-/310562225598?pt=US_Video_Gaming_Replacement_Parts_Tools&hash=item484ef37dbe).
psp joystick? are they easy/cheap to come by from spares dealers then? personally i think that one of them would soundly kick the arse of any of the laptop nub thingies that i've usedReadily available, cheap and easy to use - but utterly useless as a trackpoint replacement in my opinion : hysteresis, high forces and lack of accuracy made it a pain to use for exact and fast pointer movement. Could be that some more optimization to the algorithms and filters could have improved it, but real trackpoints are so much simpler to use.
That's hot. Glad to see this project is still chugging along, it's by far the weirdest input device I've seen but that's what makes it interesting to me :D.
Can you explain a little as to what testing you're doing?
Edit: I'm the epitome of a mechanical engineer (I'm horrible at code and anything electrical) so I'm trying to learn more about the electrical side of things and I'm using keyboards as my gateway ^__^.
Can you explain a little as to what testing you're doing?I'm going to go at it with a multimeter and make certain that there are no hidden solder bridges
what you think about a GB of your PCB?
doing so we could help you with ideas ...
I'm really interested into this project and I bet that it could help you a lot to speed up the firmware development.
I would welcome any help. Anyone willing to put one of these together at this point can PM me and I will
provide the design files or coordinate a buy depending upon the level of interest.
Yup, I'm at the same page man - however most of my projects are kinda sleeping awaiting for the GH60 or stabs.
I would welcome any help. Anyone willing to put one of these together at this point can PM me and I will
provide the design files or coordinate a buy depending upon the level of interest.
If I didn't already have 5 projects going I would jump all over this...
found my first circuit/PCB error - IAbout the switches - I saw two 2 lateral small pins, these two pins seems to be kinda fragile ...
misunderstood the I2C level shifter ASIC
which was then bleeding voltage over into
my 3.3v supply. Some careful trace cutting
and rewiring will solve it, so no major slowdown, but glad to have it understood.
Also, I now have enough of the
mechanicals to assemble 7 fingers worth
of switches. Waiting on one more
shapeways order. They seem to be
running a bit behind though, so it may
be a few weeks longer.
The SLS nylon is a very tough material, and atSLS? Okay, I now nothing about this kind of material - I thought it were PLA or ABS.
these dimensions, fairly flexible too. This, along
with the relatively low cost, is the reason I am using it.
Since those pins don't support much load during
normal use I don't think it will be a problem. Their
main reason for being present is to prevent the key
from wandering out of position. I suppose that
you could break them if you tried hard to pull the
keys up and out of the carrier. I think that it'll be fine
as long as you don't do that.
SLS? Okay, I now nothing about this kind of material - I thought it were PLA or ABS.I've no first-hand experience with the
Do you think it's possible to print your parts at home using one homebrew 3d printer? I haven't saw any bridges at all but I'm just guessing it by the pictures ...
This thread needs a new title. It's far from the "first baby step"! :)You're so right. I've been thinking the same. Comin' right up!
SLS? Okay, I now nothing about this kind of material - I thought it were PLA or ABS.
This is my favorite project on geekhack.+1 massdrop
I just wanted to stop in and let you know how cool this is turning out and to say thanks.
I would love if this eventually ended up like the ergodox on massdrop.
This is my favorite project on geekhack.
I just wanted to stop in and let you know how cool this is turning out and to say thanks.
I would love if this eventually ended up like the ergodox on massdrop.
it's kinda hard to figure out where the jumper is ...There are over 30 of them in that pic.
could you draw a arrow?
it's kinda hard to figure out where the jumper is ...There are over 30 of them in that pic.
could you draw a arrow?
each of the 0603 SMD components is a
0-Ohm bridge or jumper. If you zoom
in you can even read 000 on them!
Looks great. Are there any jams in the physical parts when you use it?Some of the keys needed trimming during assembly
Have you used smoothed the surfaces with acetone or used any sort of lubrication?
Really niceBaby DH,interested with thumb cluster like DH or different
Have you used smoothed the surfaces with acetone or used any sort of lubrication?I used acetone vapor for ABS.
Curious what your current plans are for making larger quantities of the metal springs?I've been meaning to attend to this topic. There is a local
Seems like hand bending those is going to be a source of some quality control issues even just on a single unit -- getting the right profile dialed in and mass produced seems like it would be a key part of a group buy, since the tooling costs will be non-trivial but making several thousand would be otherwise quite cheap, yeah?
Ok, so I just got these today.
(Attachment Link)
I was able to bridge all of them - except for the one with the 40 mil gap - but some took more than one application of solder. [size=78%]The three that were the easiest were:[/size]
1) 5mil interlock
2) 4mil interlock3
3) 0.05mm spacing
Those three bridged as soon as I put the iron on them, and didn't wick away. I'll try with a second board just to see what happens and if it changes. I tested the connections with the fluke.
Let me know if you want the .mod file or the whole project or something.
Curious what your current plans are for making larger quantities of the metal springs?I've been meaning to attend to this topic. There is a local
Seems like hand bending those is going to be a source of some quality control issues even just on a single unit -- getting the right profile dialed in and mass produced seems like it would be a key part of a group buy, since the tooling costs will be non-trivial but making several thousand would be otherwise quite cheap, yeah?
shop which seems to specialized in these types of things.
I'm going to have them quote it. My problem is that I'm an
electrical engineer and I don't know dimensioning & tolerancing
for mechanical drawings. You've spurred me into action though.
Here's a screenshot of my first attempt at capturing the design
with the important dimensions:
(Attachment Link)
Anyone care to help an EE out with some mechanical drawing
insight? Here's the matching .dxf file: I would welcome any
corrections. (drawn with LibreCAD)
(Attachment Link)
A few pointers:
-Tighter tolerances = higher cost. Larger number of tolerances = more places they will have to measure and verify = higher cost.
-The thickness of the sheet is specified to +-0.02mm. This is very tight and close to impossible. The material will be thickened or flattened at the bend depending on how they draw or bend it. It is also very difficult to measure if that thickness is correct all the way so best case scenario is that they ignore it.
-The 0.04mm width of the spring is quite tight as well, does it need to be that exact?
-Geometric tolerances. There are signs which is used to specify flatness, circularity etc. I suggest you look through this link and use them rather than text. (http://en.wikipedia.org/wiki/Geometric_dimensioning_and_tolerancing#Symbols)
Edit:
-Stacked tolerances:
http://i.imgur.com/qB0XNle.png
The dimension marked in red will be +-1.3mm if you add up the tolerances of the other dimensions. Be aware of where you put the dimensions and exactly which dimension is actually important. Just something to be aware of.
Let's see if this works...Thanks regack!
I've developed a strange mannerism of pressing the "Normal" key in between typing,Hear, hear! I found myself nodding at this because that's exactly what I'm doing. After several years of using DH exclusively I also have this habit of pressing "N" because wrong mode accounts for over 90% of all the [few] errors I make when typing.
and just generally, because nearly all issues are being in the wrong mode.
That's probably just a "typing tick" though.
Any estimate of a cost when this project is fully finished?
Hopefully as far away from the 1k on ebay
OldDatahands,
Have you thought about sharing all the resources you've created thusfar on github or similar?
It would allow others to contribute more easily, and also be a launching platform to gain popularity and, I guess, orders.
Like you said, you're not thinking about the enclosures yet, but someone else could start to, and contribute the files to you for you to approve, etc.
My only requirement is that the left and right devices must be able to be positioned separately. Ideally, each device would be a separate Bluetooth keyboard.
The optical switch design is definitely a painful one for a battery approach.Yes, I think hall effect / magnetic is probably a good idea, over optical (especially if it's affected by mere sunlight) and capacitive (which are a lot harder to actually read, due to all the interplay between capacitors and analog effects, etc. There is a reason old capacitive keybaords used several hundred volts to strobe the matrix!)
For a battery-powered approach, I would consider a capacitive system -- it would take some tuning, but one could position sensors such that the movements of the leg springs or magnets would create a large enough signal to be sensed reliably and with a much smaller bias/sensing waveform than an optointerruptor. A Cypress button-scanning touch IC should be able to run like that for a very, very long time.
One bonus would be ambient light tolerance -- direct sunlight borks my DH system.
Yes, I think hall effect / magnetic is probably a good idea, over optical (especially if it's affected by mere sunlight) and capacitive (which are a lot harder to actually read, due to all the interplay between capacitors and analog effects, etc. There is a reason old capacitive keybaords used several hundred volts to strobe the matrix!)
My only requirement is that the left and right devices must be able to be positioned separately. Ideally, each device would be a separate Bluetooth keyboard.
How often are you willing to replace batteries in a keyboard?
How big a battery are you willing to tolerate?
I ask because this switch design is power hungry.
Each IR LED will take > 5ma when active, each
IR photo transistor takes the same if key is pressed
When scanned. With 5 cols on each half you've
Got an average draw approaching 50ma when idle.
AA batteries might last a couple days. Because of this
I'm not convinced that this is a great design for wireless.
Mine will be wired.
There are people who've done wireless mods, but they're
relying on large, external battery packs. Not something
I imagine a lot of people being happy with.
if battery life will be low go for a integrated battery charger. ppl will tollerate the fact that they have to hock the keyboard up to a powersupply every 2-3 days much more easy than switching the battery every week.
it would be even better than no wireless option.
logitechs first aproach to wireless optical mouses was like that and it was a big success.
if battery life will be low go for a integrated battery charger. ppl will tollerate the fact that they have to hock the keyboard up to a powersupply every 2-3 days much more easy than switching the battery every week.
it would be even better than no wireless option.
logitechs first aproach to wireless optical mouses was like that and it was a big success.
Let's see if this works...
Let's see if this works...
Hi regack,
So I've spent many hours now in trying to incorporate the best of your solder-bridge
layouts into my existing footprint. I keep running into the basic problem with kicad
that it doesn't consider adjacent or overlapping, but separate pads to be connected.
It then turns my otherwise clean design into a mess of a ratsnest of unconnected pads
I've filed a bug report with kicad: https://bugs.launchpad.net/kicad/+bug/1280645 (https://bugs.launchpad.net/kicad/+bug/1280645)
in the hopes that they'll address this.
In the meantime I have moved on to working on the thumb switch mechanical design.
I don't have anything to show there yet, but work has begun.
If nothing changes in kicad, I'll eventually adjust to one of your less-optimised, but
still working layouts... but thumb switches first.
Thanks again for your work there.
I would really love to be able to mouse without leaving the DH. [...] For me the best two options to put a trackpoint-style 'nubbin' would probably be ...
I was wondering if this design still uses optical switches (which have the disadvantage of potentially not working in direct sunlight)
If it is so, why? Is there a viable alternative?
However, more to your point: 3D printing allows some easy improvements to
the original in terms of shielding. I have no data to prove it, but I expect that
I have improved on the resistance to ambient and IR light through being able
to have the IR phototransistor snap partially into a box which shields its front
completely and does not expose the eye from above at all. Should be better.
...I am primarily a coder. I work best in the dark, far from windows...:)
I quite like what gator456 did here: http://geekhack.org/index.php?topic=12212.0I like that approach too, though I'm right handed! Unfortunately it wouldn't work as well for me as I like to have the finger wells dialled quite far forward and I'm not sure if there's enough space left over. It's a very tidy mod, though.
I do not believe that packaging will allow your #1 position, though I think it wouldThat's a fair point and a good idea. I used to have a Toshiba Libretto 70ct which had a very wide/flat top to the trackpoint-style mouse - if such a device could be mounted in the front of the palm support (top facing the keywells) for use by the middle finger, perhaps it could be flanked by two small rectangular tactile switches for left/right click?
be comfortable. I'm not personally a fan of your #2 position, as it seems awkward to
me. I'm also not sure that the parts will be able to fit in that spot.
If you used your middle finger in the same way as you're using your index finger in #1,
I think that could be supportable, and comfortable. ( my understanding is that you're
imagining the "nubbin" to be sticking out of the front edge of the palm support ).
Please note that I have not been concerned with being mechanically compatible with
the existing DataHand PCBs. You might be able to achieve that by tweaking my OpenSCAD
dimensions, but I have not been targetting that. I am targetting a complete replacement,
and therefore new PCBs too. Along with that will come complete control over your layout
and key assignments - the joy of a custom keyboard.[/ quote]
Yeah, I understand that - the best thing about opening it up like you have is that I could go as far as building a new unit from scratch or mod your case designs to fit my existing DH parts. It's great to have the flexibility!The feel of the center switch (and the others for that matter) is greatly affected by the shapeThat's interesting, I might experiment with mine at some point to see if I can firm it up a little. They're still my favourite input method but there's always room for personal taste :)
and mass of steel in the clips to which the magnet is drawn. If you wanted to increase the
force required to release the center key, you could choose to make clips out of 0.020" material
instead of 0.015" material and make them 0.050" wide rather than 0.045" or anywhere
inbetween. This is a wide range of release force. I bet you could be happy somewhere in there.
I have not considered using a cherry switch in the center because 1) MX are too large, 2) I want
to maintain the feel of the magnetic release on the switches.
As for the sunlight thing, I work in a fairly bright open-plan office and never had a problem. They're not as badly affected as everyone assumes!
Stone
Thanks to damorgue for the input. With
that, some serious redrawing, then redlining
by an M.E. friend, then more redrawing
I now have a drawing to get quoted.
I'll pass along the info once they get
back to me.
...
I think the keys were designed erroneously with too large a “dish” in the center and with the outer ridge too close to the side keys. I would have made the “dish” about one-quarter or at most 5/16th of an inch in diameter.from http://deskthority.net/photos-f62/datahand-t2384-90.html
...
These firmwares do not contain the word "expander" in the source or documentation:
- TMK https://github.com/tmk/tmk_keyboard
These firmwares use io expanders:
- ErgoDox uses an expander. https://github.com/benblazak/ergodox-firmware
Thanks OldDataHands. I will study the dhteensy working example of the datahand modifiers.trig is short for trigger.
I did a quick survey of some keyboard firmwares and if they use an io expander.
These firmwares do not contain the word "expander" in the source or documentation:
- Soarer's http://geekhack.org/index.php?topic=50437.0
- imarko's dhteensy https://github.com/imarko/dhteensy
- TMK https://github.com/tmk/tmk_keyboard
These firmwares use io expanders:
- gator456's DataHand Upgrade Project probably uses an expander, but the thread doesn't say what firmware he is using or how usable it is. http://geekhack.org/index.php?topic=50437.0
- ErgoDox uses an expander. https://github.com/benblazak/ergodox-firmware
- The keyboard firmware I wrote uses an expander (I will open source the code).
And two questions, if you don't mind:
In the DodoHand firmware, what does "trig" mean? e.g.
pca9655e_trig_scanrh()
pca9655e_trig_cyc()
pca9655e_trig_init()
In the DodoHand Bill of Materials, what are the 22 "test point" parts for?:
http://www.digikey.com/product-detail/en/1040/1040K-ND/315157
When complete, what will it cost?
Just wanted to note that I am starting to work on this again, a bit.When complete, what will it cost?
I recall thinking that, depending on case design, I could make it for ~$600, not counting time or tools of course.
I think if you make it available to receive donations for your efforts, some of us will be more than willing to send you compensation.
Maybe it's worth setting up a Kickstarter campaign, I'm more than willing to donate.
I have been following this excellent thread and work closely and had printed a finger cluster using and ABS filament with partial success. It looks like a filament-based printer could be used but it would need PVA support and probably using nylon rather than ABS. When the local printing company has a dual-head machine with nylon/PVA we will have another go.
In the meantime I purchased an old DH200-6 in order to test my plan to build a 2 1/4" finger trackball into the DodoHand. I am using the ADNS9800 laser sensor for the ball and build the prototype cup out of polymorph. The first problem I hit was how old the electronics in the DH200-6 is and decided to replace it entirely with a Teensy microcontroller. I chose the Teensy-3.1 because I had one in stock and wanted a project to play with it. The prototype electronics is on veroboard for now, if all goes well I will look into creating a PCB.
One big headache was the extent of the thumb-cluster PCB which pushed the trackball too far from a comfortable position. In order to trim this board I had to move the up-switch inwards, re-mold the leaver and re-wire underneath. With a lot of trimming and messing about I managed to get the ball into a good position and trimmed the case appropriately to expose the ball. If others are interested in putting a 2 1/4" trackball into the DodoHand we may need to look carefully at the extend of the thumb-cluster PCB and possible relocation of the up-switch closer-in and appropriate changes to the leaver.
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. In the longer-term I might put a trackball in the left-hand unit also.
I have attached to photos of the right-hand unit. I would be happy to provide more detail and discuss this project if there is general interest in a track-ball option for the DodoHand.
P.S. This is my first post here and I am not sure how the images will be processed, sorry if it doesn't come out right.
When you say Dodohand, what are you referring to? Just need some clarification.
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.
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
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?
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.
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.
Thank you for the information OldDataHands.
If NAS+shift+% is pressed, what does DataHand print?
looks like you can achieve NKRO using a very similar method as the modern hall effect keyboard matricies will.
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.
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.
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!
I received a PCA9655E I/O expander today. How to mount it on a solderless breadboard?
https://www.sparkfun.com/products/495errr, actually this one:
is probably the right answer.
- 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
- 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
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.
- 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.
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.
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.
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.
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 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 (https://github.com/Henry/TrackHand)
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.
Is that case the original?
For the magnets, can you get a more magnetic (higher N number) or will you have to get a physically larger magnet?
Found they make a black cue ball http://www.amazon.com/Action-Black-Cue-Ball/dp/B009H6ZN1O (http://www.amazon.com/Action-Black-Cue-Ball/dp/B009H6ZN1O) which looks pretty cool, assuming it works with the laser pointer.
Isn't the black number 8 problem when it gets aligned with the sensor?
There is probably room in the back of the case for a few AAA batteries. If you are able to send HID over BT4.0 it'll be pretty awesome for the KB community as a whole, and would also maybe work out for the DH project as well.
However I really don't view wireless + battery as that unattainable.
And if *is* attainable, then it would have an impact on the casing design, right?
Bluetooth 4 obviously lowers the target for how much battery power you'd need,
and arduino's popularity means there's already chips kicking around we can use.
Isn't the black number 8 problem when it gets aligned with the sensor?I haven't had any issues with the pool balls I've used in my CST trackball (black or otherwise) I imagine the adns9800 that everyone got from mr kicklighter won't either.
Found they make a black cue ball http://www.amazon.com/Action-Black-Cue-Ball/dp/B009H6ZN1O (http://www.amazon.com/Action-Black-Cue-Ball/dp/B009H6ZN1O) which looks pretty cool, assuming it works with the laser pointer.
Excellent case design! I look forward to putting together a complete DodoHand.
On the issue of ball choice I tried several and found that the more features there are on the surface the better the laser is able to track it. So old scratched balls work better than brand new clean and shiny ones. After playing for a while and trying to get a response from Aramith about getting balls with a metalic finish as used in the slimblade I settled for a "golden 8" http://www.aramithpoolballs.com/bbgold8.html (http://www.aramithpoolballs.com/bbgold8.html) which works REALLY well. It is possible that the problems I experienced with new shiny balls relates to the inaccuracy of the positioning of the laser relative to the ball (I used a belt-sander on the cup) and if the cup and laser sensor mount were manufactured more accurately e.g. by 3D printing it would work better. However, using a "golden 8" ball is the safe and reliable readily available option.
I'm not sure if its been mentioned yet but I strongly recommend using mini bearings similar to what's used in mouse-trak.
I'm not sure if its been mentioned yet but I strongly recommend using mini bearings similar to what's used in mouse-trak.
Any recommendations as to sourcing those components? The smallest ball transfer unit I could find was 8mm, in a 16mm diameter package on Ebay. Going to be a tight fit in there.
Also curious about the smaller package for the ADNS-9800, any idea as to those dimensions?
Does John Kicklighter have the IGES drawing for the ADNS-6190-002 lens? It looks like a deprecated product, so didn't see it on Avago's website.
@nandop, the case is really as compact as it can be. In the previous image and the following it can be seen that the pcb fills the whole of that upper portion. The overall dimensions are 15cm by 20cm by 3cm.Show Image(https://dl.dropboxusercontent.com/u/4966230/GeekHackHand021.png)
This shows one concept I have been working on to be milled out of billet aluminum. The bottom plate would be 3mm acrylic or 1/8in aluminum plate. Looking at the cost of current keyboard cases the block may be about $100-150 per hand. I don't think the adjustably of tenting and tilting are really feasible for the first round. Like the ergodox I think people will find ways to get the tenting and tilting that they need.Show Image(https://dl.dropboxusercontent.com/u/4966230/GeekHackHand016.png)Show Image(https://dl.dropboxusercontent.com/u/4966230/GeekHackHand018.png)
In tandem I am also designing an acrylic case to target a lower cost. It may not be quite as low as you might expect with things like the ball cup and switch guards needing to be 3d printed that would be milled in the CNC aluminum design. Currently designed for 3mm acrylic. Bit tricky to go back and fourth between both designs to make sure that all screw holes and standoffs work together.Show Image(https://dl.dropboxusercontent.com/u/4966230/GeekHackHand019.png)Show Image(https://dl.dropboxusercontent.com/u/4966230/GeekHackHand020.png)
Certain aspects such as the thumb keys and such are still in flux so the design is subject to change.
I have been using a DataHand DH200 with the trackball for a few weeks now and I am not entirely satisfied with the behavior of the opto/magnetic switches; some are a bit sticky, they require different force to actuate (the RH pinky switch is particularly difficult to press) and the tactile feedback is poor. Even before I obtained a DataHand I have been considering the possibility of creating an equivalent device using Cherry MX down switches and Panasonic micro-switches for NSEW.Yeah, I've experienced the same, on my DataHand the LH pinky is particularly difficult to press. I also noticed that between different DataHand models the activation force seems to be slightly different (I assume DataHand Inc. has been tweaking the switches over time). I tried to build a finger board with micro-switches myself a couple of months ago and got good initial results, I was using the smallest 20g micro-switches I could find (I'm happy to dig out the exact part number). The switches also have a really nice tactile click sound.
I have just completed the first prototype which proves the principle but it difficult to get all the switches in suitable positions so that the centres are located in the same positions an in the original DataHand. All the switches feel good and I am now building the micro-controller board so that I can practice typing on it before constructing the left-hand unit. Here is a picture showing the general layout, I can post more details if there is interest.Please post more details :)
I have some questions about dodohand-master2014.1.16\documentation\switch_matrix.svg,
What rows map to what keys? For example:
Row0 = north
Row1 = east
Row2 = south
Row3 = west
Row4 = well
Are the row-switch mappings different for left and right hands?
What pin number do they go to?
What is the symbol to the right of the diodes?
nnoremap l g
map g k
noremap h d
noremap , m
noremap d h
noremap m j
noremap [ l
I understand (and respect) that the reason that more talk of group buying/sourcing hasn't come up more often/hasn't been organised yet is probably because it would be premature at this stage, is this correct?Certainly not ready for a group buy, and a group buy will barely make sense as the bulk of the
OldDataHands, are there any plans to create another revision of the fingers or thumb modules, or would you say they are good to go?The finger modules are functional, though care is required during assembly, and the extremely
My only concern would be the exotic parts (magnets and the custom made clips).
Another concern would be if the case is required for the keys to work properly (or would the black plastic be enough by itself to block out light pollution)?
Have you considered using a second magnet as a target instead of the clips?
... What's vi like on <non-standard qwerty boards> ...i'm currently using a kinesis at work and an ergodox at home, both with colemak layouts instead of qwerty. i decided to stick with the standard vim mappings rather than trying to go with something more customised to my layout since all those resources out on the internet presume a normal setup. i decided to try to embrace the advice of using hjkl as little as possible, more for off-by-one errors rather than main navigation, so their shuffling wasn't a big problem. in colemak's case h stays the same but j, k & l change to n, e & o respectively, all of which are common, important vim keys with good mnemonics, so i didn't want to swap their meanings. i get on with it just fine, so i'd recommend that you try to just work with it as is before resorting to remappings.
The magnets are commercially available, so maybe they aren't that exotic. The clips are an
irritant, though I was able to make the first prototypes into a useful shape with only pliers and
the bench shear for cutting the starting strips. You probably won't have perfectly identical feel
from switch to switch, but would function fine.
Silly question, would it be feasible to 3d print the clips? If we do not consider price, would the clips be more consistent?
http://www.shapeways.com/materials/steel
Not sure as to the alloy, if there is too much nickel it will not be ferromagnetic.
As an alternative the magnets can always be glued in for magnet on magnet. Not ideal, but not really that bad to loose some pocket change for a key replacement magnet.
I don’t think any of the 3d-printable metal materials have suitable strength to be used as substitutes for bent sheet metal clips.You know 3D-printed metal parts go into aerospace applications like turbines or medical implants? They surely are tough enough!
You know 3D-printed metal parts go into aerospace applications like turbines or medical implants? They surely are tough enough!People use shapeways.com to print metal aerospace parts and medical implants? (Specifically, parts of the same shape as bent pieces of thin sheet metal?)
They use the same machines, yes ;-)You know 3D-printed metal parts go into aerospace applications like turbines or medical implants? They surely are tough enough!People use shapeways.com to print metal aerospace parts and medical implants? (Specifically, parts of the same shape as bent pieces of thin sheet metal?)
They use the same machines, yes ;-)Do you have a link to an example of a part like a clip normally made out of thin bent sheet metal being replaced by a 3d-printed metal part?
OldDataHands,I have some questions about dodohand-master2014.1.16\documentation\switch_matrix.svg,
What rows map to what keys? For example:
Row0 = north
Row1 = east
Row2 = south
Row3 = west
Row4 = well
Are the row-switch mappings different for left and right hands?
What pin number do they go to?
What is the symbol to the right of the diodes?
Have a look at the same document in the thumb_work branch.
I already partially addressed the north/east/south question but haven't
pulled it back into the main yet. Note that it reflects the left hand.
There is only one PCB layout, reversible, so the switch-to-finger
position mapping is mirrored on one hand vs. the other. (west on
one hand is east on the other).
Switch: Left : Right
Matrix : Teensy : PCA9655E
---------------------------------------
ROW0 : F0 : IO1_0
ROW1 : F1 : IO1_1
ROW2 : F4 : IO1_2
ROW3 : F5 : IO1_3
ROW4 : F6 : IO1_4
COL0 : B0 : IO0_5
COL1 : B1 : IO0_4
COL2 : B2 : IO0_3
COL3 : B3 : IO0_2
COL4 : D2 : IO0_1
COL5 : D3 : IO0_0
The symbol to the right of the LEDs is my version of the normally
closed mechanical/optical switch between the LED and the
phototransistor (i.e. the symbol (diode included) is my attempt to
represent the dodohand switch, LED, phototransistor and all).
Excited to be able to try out your firmware!
*snip*I know when building my reprap we used set screws to drill there own thread into plastic holes to keep pullies / rods in place, those might be an option as well if enough metal is there to pull in the magnet.
Or instead of a clip, maybe use a miniature screw?
I know when building my reprap we used set screws to drill there own thread into plastic holes to keep pullies / rods in place, those might be an option as well if enough metal is there to pull in the magnet.
I am currently tuning my reprap again to do some printing for the dodohand. I do not think I can print all of the parts but the big pieces for the main housing, palm rests and I hope the trackball housing should be doable. Another thing I want to do is get pricing details on the finger / thumb unit parts from regional 3d printing shops, can I use the branch for the thumb unit to get a good estimate on the costs ?
I can change the code to work with DodoHand hardware, but I am unsure of how to handle the optic switches.
Would firmware tested on normally open tactile switches with cathode end of diodes pointing towards the row work on the DodoHand hardware?
OldDataHands, could you possibly elaborate a bit on the IR sensors? Are they in any way special, or would any kind work (DigiKey has high postage costs here, rs-components might work better, but they don't have the exact components you use). Do you just pulse the emitter and check the transistor for a signal multiple times per second?
Would something pre-packaged like a slotted optical switch work too?
Another question, do you activate the LEDs all the time, or do you strobe them just whenever you are reading them?
I can change the code to work with DodoHand hardware, but I am unsure of how to handle the optic switches.
Would something pre-packaged like a slotted optical switch work too?
One more question; what are the Teensy and pca9655e pin assignments on the DodoHand?
The dodohand-thumb_work\src\ shows pca9655e pins assigned to LEDs, and pins assigned to lh_matrix[][].
Please provide all the pin assignments.
One more question; what are the Teensy and pca9655e pin assignments on the DodoHand?
The dodohand-thumb_work\src\ shows pca9655e pins assigned to LEDs, and pins assigned to lh_matrix[][].
Please provide all the pin assignments.
Teensy _or_ this are populated. never both."
Thanks for the schematics OldDataHands :thumb:.
On the PCA9655E schematic, what does "populated" mean?QuoteTeensy _or_ this are populated. never both."
I believe that the two hands are the same PCB but reversible (like the ErgoDox), so you either put a Teensy on, or a PCA9644E, but never both on the same PCB.
Some one with access to a DataHand please run the following test.All of them print "%".
With CapsLck off, verify that:
NAS+shift+5 prints "%"
NAS+shift+% prints "%"
Repeat the test with CapsLck on, what does it print?
NAS+shift+5 prints:
NAS+shift+% prints:
What do these pin assignments mean?:
EPINT
EPRST (also on PCA9655E)
EPSPARE
AREF
TRST
What do the LED numbers map to, on Teensy2 and pca9655e? e.g. NumLck, CapLck, Mouse, NAS, Normal, 10-key:
LED_0
LED_1
LED_2
LED_D6_3
A 10-key DodoHand is running and tested on a breadboard with Teensy 2.0 and PCA9655E I/O expander.
The 52-key DodoHand firmware without the above pins compiles, but I don't have the hardware to test it.
I am writing documentation to make debugging easier.
It will be pushed to GitHub in a few days.
Module cache size: 6 modules
Compiling design (CSG Tree generation)...
ECHO: "x,y,z, d,w,h:", 0.9, 14.1333, 6.528, 11.5, 2.19267, 2.7045
ECHO: "x,y,z, d,w,h:", 0.9, 14.1333, 6.528, 11.5, 2.19267, 2.7045
ECHO: "x,y,z, d,w,h:", 0.9, 14.1333, 6.528, 11.5, 2.19267, 2.7045
ECHO: "x,y,z, d,w,h:", 0.9, 14.1333, 6.528, 11.5, 2.19267, 2.7045
ECHO: "index finger opto lead position array"
WARNING: Ignoring unknown variable 'h1ia'.
WARNING: Ignoring unknown variable 'h1r'.
WARNING: Ignoring unknown variable 'h1ia'.
WARNING: Ignoring unknown variable 'h1r'.
ECHO: "[", undef, undef
WARNING: Ignoring unknown variable 'h2ia'.
WARNING: Ignoring unknown variable 'h2r'.
WARNING: Ignoring unknown variable 'h2ia'.
WARNING: Ignoring unknown variable 'h2r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h3ia'.
WARNING: Ignoring unknown variable 'h3r'.
WARNING: Ignoring unknown variable 'h3ia'.
WARNING: Ignoring unknown variable 'h3r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h4ia'.
WARNING: Ignoring unknown variable 'h4r'.
WARNING: Ignoring unknown variable 'h4ia'.
WARNING: Ignoring unknown variable 'h4r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h5ia'.
WARNING: Ignoring unknown variable 'h5r'.
WARNING: Ignoring unknown variable 'h5ia'.
WARNING: Ignoring unknown variable 'h5r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h6ia'.
WARNING: Ignoring unknown variable 'h6r'.
WARNING: Ignoring unknown variable 'h6ia'.
WARNING: Ignoring unknown variable 'h6r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h7ia'.
WARNING: Ignoring unknown variable 'h7r'.
WARNING: Ignoring unknown variable 'h7ia'.
WARNING: Ignoring unknown variable 'h7r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h8ia'.
WARNING: Ignoring unknown variable 'h8r'.
WARNING: Ignoring unknown variable 'h8ia'.
WARNING: Ignoring unknown variable 'h8r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h9ia'.
WARNING: Ignoring unknown variable 'h9r'.
WARNING: Ignoring unknown variable 'h9ia'.
WARNING: Ignoring unknown variable 'h9r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hAia'.
WARNING: Ignoring unknown variable 'hAr'.
WARNING: Ignoring unknown variable 'hAia'.
WARNING: Ignoring unknown variable 'hAr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hBia'.
WARNING: Ignoring unknown variable 'hBr'.
WARNING: Ignoring unknown variable 'hBia'.
WARNING: Ignoring unknown variable 'hBr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hCia'.
WARNING: Ignoring unknown variable 'hCr'.
WARNING: Ignoring unknown variable 'hCia'.
WARNING: Ignoring unknown variable 'hCr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hDia'.
WARNING: Ignoring unknown variable 'hDr'.
WARNING: Ignoring unknown variable 'hDia'.
WARNING: Ignoring unknown variable 'hDr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hEia'.
WARNING: Ignoring unknown variable 'hEr'.
WARNING: Ignoring unknown variable 'hEia'.
WARNING: Ignoring unknown variable 'hEr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hFia'.
WARNING: Ignoring unknown variable 'hFr'.
WARNING: Ignoring unknown variable 'hFia'.
WARNING: Ignoring unknown variable 'hFr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hGia'.
WARNING: Ignoring unknown variable 'hGr'.
WARNING: Ignoring unknown variable 'hGia'.
WARNING: Ignoring unknown variable 'hGr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hHia'.
WARNING: Ignoring unknown variable 'hHr'.
WARNING: Ignoring unknown variable 'hHia'.
WARNING: Ignoring unknown variable 'hHr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hIia'.
WARNING: Ignoring unknown variable 'hIr'.
WARNING: Ignoring unknown variable 'hIia'.
WARNING: Ignoring unknown variable 'hIr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hJia'.
WARNING: Ignoring unknown variable 'hJr'.
WARNING: Ignoring unknown variable 'hJia'.
WARNING: Ignoring unknown variable 'hJr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hKia'.
WARNING: Ignoring unknown variable 'hKr'.
WARNING: Ignoring unknown variable 'hKia'.
WARNING: Ignoring unknown variable 'hKr'.
ECHO: "", undef, undef, "]"
ECHO: "middle finger opto lead position array"
WARNING: Ignoring unknown variable 'h1ia'.
WARNING: Ignoring unknown variable 'h1r'.
WARNING: Ignoring unknown variable 'h1ia'.
WARNING: Ignoring unknown variable 'h1r'.
ECHO: "[", undef, undef
WARNING: Ignoring unknown variable 'h2ia'.
WARNING: Ignoring unknown variable 'h2r'.
WARNING: Ignoring unknown variable 'h2ia'.
WARNING: Ignoring unknown variable 'h2r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h3ia'.
WARNING: Ignoring unknown variable 'h3r'.
WARNING: Ignoring unknown variable 'h3ia'.
WARNING: Ignoring unknown variable 'h3r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h4ia'.
WARNING: Ignoring unknown variable 'h4r'.
WARNING: Ignoring unknown variable 'h4ia'.
WARNING: Ignoring unknown variable 'h4r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h5ia'.
WARNING: Ignoring unknown variable 'h5r'.
WARNING: Ignoring unknown variable 'h5ia'.
WARNING: Ignoring unknown variable 'h5r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h6ia'.
WARNING: Ignoring unknown variable 'h6r'.
WARNING: Ignoring unknown variable 'h6ia'.
WARNING: Ignoring unknown variable 'h6r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h7ia'.
WARNING: Ignoring unknown variable 'h7r'.
WARNING: Ignoring unknown variable 'h7ia'.
WARNING: Ignoring unknown variable 'h7r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h8ia'.
WARNING: Ignoring unknown variable 'h8r'.
WARNING: Ignoring unknown variable 'h8ia'.
WARNING: Ignoring unknown variable 'h8r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h9ia'.
WARNING: Ignoring unknown variable 'h9r'.
WARNING: Ignoring unknown variable 'h9ia'.
WARNING: Ignoring unknown variable 'h9r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hAia'.
WARNING: Ignoring unknown variable 'hAr'.
WARNING: Ignoring unknown variable 'hAia'.
WARNING: Ignoring unknown variable 'hAr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hBia'.
WARNING: Ignoring unknown variable 'hBr'.
WARNING: Ignoring unknown variable 'hBia'.
WARNING: Ignoring unknown variable 'hBr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hCia'.
WARNING: Ignoring unknown variable 'hCr'.
WARNING: Ignoring unknown variable 'hCia'.
WARNING: Ignoring unknown variable 'hCr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hDia'.
WARNING: Ignoring unknown variable 'hDr'.
WARNING: Ignoring unknown variable 'hDia'.
WARNING: Ignoring unknown variable 'hDr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hEia'.
WARNING: Ignoring unknown variable 'hEr'.
WARNING: Ignoring unknown variable 'hEia'.
WARNING: Ignoring unknown variable 'hEr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hFia'.
WARNING: Ignoring unknown variable 'hFr'.
WARNING: Ignoring unknown variable 'hFia'.
WARNING: Ignoring unknown variable 'hFr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hGia'.
WARNING: Ignoring unknown variable 'hGr'.
WARNING: Ignoring unknown variable 'hGia'.
WARNING: Ignoring unknown variable 'hGr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hHia'.
WARNING: Ignoring unknown variable 'hHr'.
WARNING: Ignoring unknown variable 'hHia'.
WARNING: Ignoring unknown variable 'hHr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hIia'.
WARNING: Ignoring unknown variable 'hIr'.
WARNING: Ignoring unknown variable 'hIia'.
WARNING: Ignoring unknown variable 'hIr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hJia'.
WARNING: Ignoring unknown variable 'hJr'.
WARNING: Ignoring unknown variable 'hJia'.
WARNING: Ignoring unknown variable 'hJr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hKia'.
WARNING: Ignoring unknown variable 'hKr'.
WARNING: Ignoring unknown variable 'hKia'.
WARNING: Ignoring unknown variable 'hKr'.
ECHO: "", undef, undef, "]"
ECHO: "ring finger opto lead position array"
WARNING: Ignoring unknown variable 'h1ia'.
WARNING: Ignoring unknown variable 'h1r'.
WARNING: Ignoring unknown variable 'h1ia'.
WARNING: Ignoring unknown variable 'h1r'.
ECHO: "[", undef, undef
WARNING: Ignoring unknown variable 'h2ia'.
WARNING: Ignoring unknown variable 'h2r'.
WARNING: Ignoring unknown variable 'h2ia'.
WARNING: Ignoring unknown variable 'h2r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h3ia'.
WARNING: Ignoring unknown variable 'h3r'.
WARNING: Ignoring unknown variable 'h3ia'.
WARNING: Ignoring unknown variable 'h3r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h4ia'.
WARNING: Ignoring unknown variable 'h4r'.
WARNING: Ignoring unknown variable 'h4ia'.
WARNING: Ignoring unknown variable 'h4r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h5ia'.
WARNING: Ignoring unknown variable 'h5r'.
WARNING: Ignoring unknown variable 'h5ia'.
WARNING: Ignoring unknown variable 'h5r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h6ia'.
WARNING: Ignoring unknown variable 'h6r'.
WARNING: Ignoring unknown variable 'h6ia'.
WARNING: Ignoring unknown variable 'h6r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h7ia'.
WARNING: Ignoring unknown variable 'h7r'.
WARNING: Ignoring unknown variable 'h7ia'.
WARNING: Ignoring unknown variable 'h7r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h8ia'.
WARNING: Ignoring unknown variable 'h8r'.
WARNING: Ignoring unknown variable 'h8ia'.
WARNING: Ignoring unknown variable 'h8r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h9ia'.
WARNING: Ignoring unknown variable 'h9r'.
WARNING: Ignoring unknown variable 'h9ia'.
WARNING: Ignoring unknown variable 'h9r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hAia'.
WARNING: Ignoring unknown variable 'hAr'.
WARNING: Ignoring unknown variable 'hAia'.
WARNING: Ignoring unknown variable 'hAr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hBia'.
WARNING: Ignoring unknown variable 'hBr'.
WARNING: Ignoring unknown variable 'hBia'.
WARNING: Ignoring unknown variable 'hBr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hCia'.
WARNING: Ignoring unknown variable 'hCr'.
WARNING: Ignoring unknown variable 'hCia'.
WARNING: Ignoring unknown variable 'hCr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hDia'.
WARNING: Ignoring unknown variable 'hDr'.
WARNING: Ignoring unknown variable 'hDia'.
WARNING: Ignoring unknown variable 'hDr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hEia'.
WARNING: Ignoring unknown variable 'hEr'.
WARNING: Ignoring unknown variable 'hEia'.
WARNING: Ignoring unknown variable 'hEr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hFia'.
WARNING: Ignoring unknown variable 'hFr'.
WARNING: Ignoring unknown variable 'hFia'.
WARNING: Ignoring unknown variable 'hFr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hGia'.
WARNING: Ignoring unknown variable 'hGr'.
WARNING: Ignoring unknown variable 'hGia'.
WARNING: Ignoring unknown variable 'hGr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hHia'.
WARNING: Ignoring unknown variable 'hHr'.
WARNING: Ignoring unknown variable 'hHia'.
WARNING: Ignoring unknown variable 'hHr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hIia'.
WARNING: Ignoring unknown variable 'hIr'.
WARNING: Ignoring unknown variable 'hIia'.
WARNING: Ignoring unknown variable 'hIr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hJia'.
WARNING: Ignoring unknown variable 'hJr'.
WARNING: Ignoring unknown variable 'hJia'.
WARNING: Ignoring unknown variable 'hJr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hKia'.
WARNING: Ignoring unknown variable 'hKr'.
WARNING: Ignoring unknown variable 'hKia'.
WARNING: Ignoring unknown variable 'hKr'.
ECHO: "", undef, undef, "]"
ECHO: "pinkie finger opto lead position array"
WARNING: Ignoring unknown variable 'h1ia'.
WARNING: Ignoring unknown variable 'h1r'.
WARNING: Ignoring unknown variable 'h1ia'.
WARNING: Ignoring unknown variable 'h1r'.
ECHO: "[", undef, undef
WARNING: Ignoring unknown variable 'h2ia'.
WARNING: Ignoring unknown variable 'h2r'.
WARNING: Ignoring unknown variable 'h2ia'.
WARNING: Ignoring unknown variable 'h2r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h3ia'.
WARNING: Ignoring unknown variable 'h3r'.
WARNING: Ignoring unknown variable 'h3ia'.
WARNING: Ignoring unknown variable 'h3r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h4ia'.
WARNING: Ignoring unknown variable 'h4r'.
WARNING: Ignoring unknown variable 'h4ia'.
WARNING: Ignoring unknown variable 'h4r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h5ia'.
WARNING: Ignoring unknown variable 'h5r'.
WARNING: Ignoring unknown variable 'h5ia'.
WARNING: Ignoring unknown variable 'h5r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h6ia'.
WARNING: Ignoring unknown variable 'h6r'.
WARNING: Ignoring unknown variable 'h6ia'.
WARNING: Ignoring unknown variable 'h6r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h7ia'.
WARNING: Ignoring unknown variable 'h7r'.
WARNING: Ignoring unknown variable 'h7ia'.
WARNING: Ignoring unknown variable 'h7r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h8ia'.
WARNING: Ignoring unknown variable 'h8r'.
WARNING: Ignoring unknown variable 'h8ia'.
WARNING: Ignoring unknown variable 'h8r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'h9ia'.
WARNING: Ignoring unknown variable 'h9r'.
WARNING: Ignoring unknown variable 'h9ia'.
WARNING: Ignoring unknown variable 'h9r'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hAia'.
WARNING: Ignoring unknown variable 'hAr'.
WARNING: Ignoring unknown variable 'hAia'.
WARNING: Ignoring unknown variable 'hAr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hBia'.
WARNING: Ignoring unknown variable 'hBr'.
WARNING: Ignoring unknown variable 'hBia'.
WARNING: Ignoring unknown variable 'hBr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hCia'.
WARNING: Ignoring unknown variable 'hCr'.
WARNING: Ignoring unknown variable 'hCia'.
WARNING: Ignoring unknown variable 'hCr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hDia'.
WARNING: Ignoring unknown variable 'hDr'.
WARNING: Ignoring unknown variable 'hDia'.
WARNING: Ignoring unknown variable 'hDr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hEia'.
WARNING: Ignoring unknown variable 'hEr'.
WARNING: Ignoring unknown variable 'hEia'.
WARNING: Ignoring unknown variable 'hEr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hFia'.
WARNING: Ignoring unknown variable 'hFr'.
WARNING: Ignoring unknown variable 'hFia'.
WARNING: Ignoring unknown variable 'hFr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hGia'.
WARNING: Ignoring unknown variable 'hGr'.
WARNING: Ignoring unknown variable 'hGia'.
WARNING: Ignoring unknown variable 'hGr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hHia'.
WARNING: Ignoring unknown variable 'hHr'.
WARNING: Ignoring unknown variable 'hHia'.
WARNING: Ignoring unknown variable 'hHr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hIia'.
WARNING: Ignoring unknown variable 'hIr'.
WARNING: Ignoring unknown variable 'hIia'.
WARNING: Ignoring unknown variable 'hIr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hJia'.
WARNING: Ignoring unknown variable 'hJr'.
WARNING: Ignoring unknown variable 'hJia'.
WARNING: Ignoring unknown variable 'hJr'.
ECHO: "", undef, undef
WARNING: Ignoring unknown variable 'hKia'.
WARNING: Ignoring unknown variable 'hKr'.
WARNING: Ignoring unknown variable 'hKia'.
WARNING: Ignoring unknown variable 'hKr'.
ECHO: "", undef, undef, "]"
ECHO: "oaw: ", 23.9
ECHO: "clip_len (mm, in): ", 11.5157, 0.453373
ECHO: "clip_w: ", 1.31667, 0.0518373
ECHO: "clip2_len: ", 15.7916, 0.621718
ECHO: "clip2_B: ", 1.63782, 0.064481
ECHO: "flange radius: ", 20.6757
ECHO: "lh_i_sty: ", 18.7966
ECHO: "lh_i_sby: ", -18.7966
ECHO: "lh_m_sty: ", 24.5116
ECHO: "lh_m_sby: ", -13.0816
ECHO: "lh_r_sty: ", 16.6122
ECHO: "lh_r_sby: ", -20.981
ECHO: "lh_p_sty: ", -0.507392
ECHO: "lh_p_sby: ", -38.1006
ECHO: "ks_screw_id: ", 1.6383
Compiling design (CSG Products generation)...
Geometries in cache: 93
Geometry cache size in bytes: 2539896
CGAL Polyhedrons in cache: 0
CGAL cache size in bytes: 0
Compiling design (CSG Products normalization)...
Normalized CSG tree has 1923 elements
Compile and preview finished.
Total rendering time: 0 hours, 0 minutes, 0 seconds
1) What are the ten "8 position SMT header" used for? (the BOM says quantity 5 and the pictures show them absent from your PCBs).
2) On thumb PCB, what are the meanings of the three labels R101, R102, R103?R101, R102, and R103 are the labels for the 3 resistors in the thumb switch matrix.
3) On thumb PCB, which solder bridges get bridged?Just like on the finger PCB, the bridges that are on the side opposite your hand will
Hah! Excellent! That guard looks great!
So, How does the guard seem to line up with your hand?
I arranged it for mine, and it was quite close to the original...
Greebled is a new term for me, but I can see what you mean.
[...]
Regarding all of the warnings on compile: I'd been off working
on the thumb model and hadn't tried to clean those up. It is
just the cruft left over from getting final position data out for
locating pins in the PCB.
How's the work on the thumb cluster going?
How big is your SRAM deficit?I haven't measured the SRAM deficit yet.
Might there be an opportunity to squeeze some otherI squeezed all the memory I could.
places so as to make some space available for what you're
trying to accomplish?
There may also be another way to arrange things so as toThe array of polymorphic objects is fundamental to the sketch's architecture.
achieve what you're trying to get using this "polymorphic object"
without actually having to use that approach.
Are you willing to share what you've got at the moment that doesn't fit into the 32U4?I will push a working DodoHand firmware to GitHub in a few weeks, but the mouse buttons will not be sticky.
Haven't checked and measured all the mechanical pieces in detail but are there any that's too small to be printed on an FDM-machine like the Makerbot? If it is I would like to fork it and make one that'll be accessible to more people.
Wow!
What is the travel distance of the tips of the keys?
The leads from those switches all come nearly to the same point.
What do you have in mind regarding a center switch? How're you
going to fit it in there?
Ahah! That looks promising. Looking forward to a report
about the feel!
Even my Pro-II datahands have separate "keycap" parts...
though I'm uncertain of the benefit if you're doing your
own FDM 3D-printing. In my models I did a crude connection
between the thumb switches and the "keycaps" because it
allows the print to fit into a smaller bounding volume.
Do you have an idea which would work ?
It seemed to me that for the finger switches the tolerances
were too coarse to allow for a nice, reliable fit within the
rather thin parts that I was imagining.
So the ABS had a lot of acetone trapped within, even though I dried it for a very long time. When I stuffed it into the oven at 120°C it foamed and got runny! Got me some burns trying to save it and knead it back to shape while still hot, but it paid off... ergonomy-wise, at least. Now it's functional and comfortable, but dead fugly.
@Phenix
Re:price/making it a product/selling it - No idea. Didn't really think about it yet. I don't even know if there's gonna be demand for this, or will people like the new switches. I have it in the back of my head, and would love to do it, but it's still too early. Needs to be tested, needs not to break, needs to be easily fixable, needs to fit most hand types... and I need to research best practices regarding selling stuff on GH.
I'll get down to it after I have a working, programmable prototype running. At this stage this would be a distraction. I did some research after your post, and ErgoDox price range seems like something acceptable to a lot of people. I would also like to release the files for this at some point, so anyone can print those out and assemble/modify on their own.
It looks like some kind of alien organic control system in a sci-fi movie... it's fantastic!
Thanks for the update.
The wrist Rest looks .. functional. But if its ergonomic why not
to set up the angle is a good idea!
I'm super glad you're going to be releasing the files, it's always a good thing to have it open source :)) Hope this doesn't end up facing any major problems, since I've been wanting a DataHand since I first saw one.
Good luck with finishing up the prototype :thumb:
Great post man! Don't cheap out on switches :P they should have different actuation force for different fingers. Considering this is pretty much best keyboard to top all the keyboards, price doesn't matter at all, it should be all about quality. Does 3d printed plastic feel good or are there other more comfortable materials? Looks kinda tall, but that's probably because of your unique switch/part positioning.
pick function over form every time.
I want some vids of excessively ergonomic WPMs
The only thing left to work out is the electronics, and that's a well documented process that doesn't need exotic parts.
Wiring breadboard is a pain. Just design a PCB (you will need it at the end anyway) and etch it at home. Its only something like 2 hours of work to etch it. It is cheap and the result is much easier to work with. And if it turns out well then you can put your prototype PCB into your first prototype keyboard.
Also, the PCB is not yet designed, which isn't 2 hours :)Yes, but you will need a PCB at the end anyway so designing it is not a loss of time. It would be lost time only when you think it is highly probable that your schematic is so bad or the case/PCB contours so unstable that you would need to modify it in a substantial way (which would completely break the original PCB layout).
A very high DPI would be best so that not much movement would be required, to go with the rest of the minimal movement idea of the Datahand.
A very high DPI would be best so that not much movement would be required, to go with the rest of the minimal movement idea of the Datahand.
The trouble with "high DPI" is that it also means twitchy and hard to control precisely; this would exacerbate the issues people were already concerned about of having to actively counter the "mouse" movement when trying to type. One of the big "advantages" of the original datahand design was that it required only finger movement; no wrist/arm movement is needed for use. That's why the trackball/trackpoint ideas seemed like a more natural extension of the original design. Of course, there's no reason why we can't ultimately have several different models/variants ;D
Thought: Ever heard of those double-nipple IBM laptop prototypes? They used one for fast nav, and the other for precise nav, and you could combine them to be used at the same time... See where this is heading?
re:additional buttons
I can't visualize this... could you please draw that, or illustrate in some way?
Looking at this excites and worries me. The eventual product could become a procrustean bed that fits the hand of the designer, and excludes a significant number of other people.Most of these keyboards are experimental prototypes.
@Zekromtor, re: two mice at once, nipples
Lol.
AFAIR, Linux allows multiple cursors. That would be strange.
Gonna leave that for much later though.
I added a pin to serial-in, so I can pull it up or down for debug.You can drop the pin and leave at GND or Vcc all the time. (That is if you do not want for debugging to be able to define what values should be in those low bits.) It better even from the power consumption point of view. It is negligibly lower when input pit is not floating.
@LuxHmm, I did some calculating and measured that the cap would displace by only >1.5mm. The stem is unnecessarily long, so that could be made even shorter and reduce the travel. Either way, not too bad.
The Problem when using leverage is, that it increases the length of the keystroke. Nice Idea if you find a way to design around the shortcommings. The precision is no problem in my oppinion but the activation force which could be quite uncompfortable for keyboard use. They are probably designed to be activated by the thumb.
NAS | orange (I will use blue) |
Normal | green |
MF | yellow |
10-Key | red |
The DataHand guide does not have a complete description of the indicator lights.
What are the indicator lights on the left-hand unit? Caps Lock? Num Lock?
MODIFIERKEY_LEFT_ALT MODIFIERKEY_RIGHT_ALT
MODIFIERKEY_LEFT_CTRL MODIFIERKEY_RIGHT_CTRL
MODIFIERKEY_LEFT_SHIFT MODIFIERKEY_RIGHT_SHIFT
KEY_DELETE KEYPAD_PERIOD (KEY_NUM_LOCK off)
KEY_INSERT KEYPAD_0 (KEY_NUM_LOCK off)
KEY_PAGE_UP KEYPAD_9 (KEY_NUM_LOCK off)
KEY_PAGE_DOWN KEYPAD_3 (KEY_NUM_LOCK off)
KEY_END KEYPAD_1 (KEY_NUM_LOCK off)
KEY_EQUAL + SHIFT KEYPAD_PLUS
KEY_8 + SHIFT KEYPAD_ASTERIX
KEY_MINUS KEYPAD_MINUS
KEY_SLASH KEYPAD_SLASH
So far so good.See "Switching Left and Right Function for Duplicate Keys: The L/R Modf Key" for information on temporarily switching individual key functions.which on page 40 says,
Alternatively the ALT and CNTR keys can toggle to RT by double clicking either key.Page 46 says,
L/R Modf will switch the scan code output of the ALT and CTL keys.What does "RT" mean?
Alternatively a double strike of the either key will temporarily change to the alternate scan code output.
If you strike CTRL-L a second time, without striking any other keys in between, you will get CTRL-R sent instead.
When the CTRL-R is released, the CTRL key automatically reverts back CTRL-L.
If you strike CTRL-R a second time, without striking any other keys in between, you will get CTRL-L sent instead.
When the CTRL-L is released, the CTRL key automatically reverts back CTRL-R?
Global "L/R Modf" changes all 12 left-right keys, including the CTRL and ALT?
Thanks for the detailed description arisian. That clears up a lot.
There are still some points I am unsure of. Are these statements correct?:QuoteIf you strike CTRL-L a second time, without striking any other keys in between, you will get CTRL-R sent instead.
When the CTRL-R is released, the CTRL key automatically reverts back CTRL-L.
If you strike CTRL-R a second time, without striking any other keys in between, you will get CTRL-L sent instead.
When the CTRL-L is released, the CTRL key automatically reverts back CTRL-R?
QuoteGlobal "L/R Modf" changes all 12 left-right keys, including the CTRL and ALT?
I expect the DodoHand firmware to be heavily customized.
The firmware is object oriented and very modular; so customizations are easy.
DataHand functionality is faithfully replicated to give the DodoHand community a common baseline to work from.
To change the L/R Modf, hold up the FUNC Mode key and at same time press the L/R Modf (left little finger, well key...light on the right hand will flash to verify entry into right side).Which light flashes and what color is it?
+ - * / . Enter 00 0 1 2 3 4 5 6 7 8 9, arrow keys (on 10-Key-On left-index finger)
@test321
Yep. I need to finish a project at work that swallows up most of my time.
There aren't many updates photo-wise, but I still managed to make a few things in the mean time.
I etched and soldered a PCB with a shift reg on it, schematic is in the PCB thread. Will post pics later.
Also, it turned out that I can't (rly?) make Arduino Mega act as a HID using its integrated USB port, I need a shield for that. Ended up buying an 32u4 based arduino that can act as a HID.
Later I realized I could just communicate keypresses from the Mega to a Python script via pyserial and generate stuff from there, but that would have been a whole new level of fugly.
Right now I have the ardu running as a serial keyboard without issues, this was kind of a dumb job, as the Arduino software has libraries and sketches for that, so it essentially ran OOTB. I'll have to write something to handle the shift registers, wire up the keyboard, map keys to symbols, and it should be ready. But that will happen after I'm done with current work, which may take some 3 weeks more.
im glad to hear you're still working on this project, but how long will it take to move it from prototype phase (once its completed) + crowdfunding + searching for manufacturer + final shipping time? like at least a year?
@LuX
Awesome job man! You're totally doing it right. I tested similar switches, they behave nicely and have a very low travel. I actually made little test rigs with tensioning screws for these, to see how they behave.
Kinda wondering now if I shouldn't have chosen that path, hehe :)
Try getting these printed, assemble a prototype!
Btw, is that Blender? :thumb: ;D
Thanks again arisian. The double-strike L/R Ctrl and Alt keys are working nicely.
Now to implement the L/R Modf LED indicator lights. Page 40 of the DataHand User Guide says:QuoteTo change the L/R Modf, hold up the FUNC Mode key and at same time press the L/R Modf (left little finger, well key...light on the right hand will flash to verify entry into right side).Which light flashes and what color is it?
Is there an indicator light for left the side?
Also some questions about NumLock.
Page 29 of DataHand User Guide says that NAS (both 10-Key-On and 10-Key-Off) send Alpha-number scancodes (KEY_).
When NUM_LOCK is on, these number keys will send the 10-Key pad scancodes (KEYPAD_).
Does DataHand's NUM_LOCK only effect number keys 0-9, or all these keys?:Code: [Select]+ - * / . Enter 00 0 1 2 3 4 5 6 7 8 9, arrow keys (on 10-Key-On left-index finger)
For those of you wondering how to tell the difference between identical looking characters, keycodes can be read using command 'xev' in the Linux terminal.
Command 'xev' will open a window and print contents of keyboard events.
LEFT INDICATOR LIGHTS
---------------------
MouseOn yellow
NumLock yellow
ScrollLock yellow
CapsLock green
RIGHT INDICATOR LIGHTS
----------------------
NAS blue
Normal green
MF yellow
10-Key red
Scroll Lock, ??? (For some reason, mine isn't illuminating)
Are we currently modeling the behavior on the original DH-200's? or the later ProII's?I reversed engineered the firmware from the DataHand Professional II Users Guide version 1.7.8 October 2003, and what ever other information people provided (I don't have access to a DataHand).
I always thought that a separate L/R mode indicator light would have been helpful on the DatahandsAdding another LED to the firmware would be a trivial task.
the Scroll, Mouse, NumLock, Cursor (L,R,U,D), and Function mode lights are all "red" whichWhat is this "Cursor" light you speak of? And were do the letters "L,R,U,D" come from? - Left, Right, Up, Down
Hi Interface,That's why I'm saving the hand sim for last. Thanks for your input anyway :)
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.
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 :)
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]
2) Is the thumb PCB "functional" can I actually order them and components and get the electronics side done ?
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.
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]
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.
The LEDs all work
@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?
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.@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.
---snip---
Get the Teensy LC
---snip---
This is not a simple thing: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.---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]
"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.
Another way would be to poll the I/O expander using SPI.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 :)
Advantages of SPI compared to I2C:
[snip]
---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 :)
How about distance requirements? The left to right side connection is quite longThe keybrd library debouncer has error correction. https://github.com/wolfv6/keybrd/blob/master/src/Debouncer_Samples.cpp (https://github.com/wolfv6/keybrd/blob/master/src/Debouncer_Samples.cpp)
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.
----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----
----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...
I was also wondering why the finger carriers are off-center by 0.14,0.14 mm, was there a specific reason ?
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?
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.
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...)
Have you considered a photointerrupter with Slot Type transmission?I did in the past and had to conclude that I could not get them to fit.
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
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).
How about using Hall effect sensors instead of optics?
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*
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. :thumb:
Thanks for the update. :thumb: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.
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.
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.
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.
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
Thanks for the detailed answer.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.
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).I guess it's not a simple as I had imagined.
invultri,I will check up on this in some time, there is no schematic provided so I must first reconstruct the workings.
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.
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
Hi invultri,
I did review the datasheets for those chips, and briefly reviewed your
schematic: They all look reasonable to me. I think you'll be able to
make a reliably functioning circuit with that combo.
I look forward to seeing pics of the first prototype!
Edit:Hi, invultri
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
Hi, invultriHello Hanya,
NCV7608 is works like Nch-MOSFET. In your circuit, anode of IRLED is connected to drain of NCV7608 (D1 in the case of row0 line) and VCC is connected to source (S1 for row0).
In figure 21 of the NCV7608 datasheet tells it has body diode. The diode current is quite high even in low source-to-drain voltage. It looks these IRLEDs are always on.
VCC pin of NCV7608 is connected to VCC(+5V from teensy 3.2), it makes logic level of NCV7608 VCC level.
Recommended voltage of VS pin of NCV7608 is range 5.5V to 28V. If you can connect 5V to VS pin, on resistance could be smaller.
If each ICs can have decoupling capacitor near each power pins.
Here is the schematic I plan to test on a breadboard.
It's a proof of concept with only 4 keys.
It has everything I need to develop the DodoHand scanner firmware.
The KiCad schematics are at https://github.com/wolfv6/keybrd_DH/tree/master/schematics
The files to look at are dodohand_BB.sch and row_shiftReg_photoInterrupt_BB.sch.
A review or the schematic would be appreciated.
There are some KiCaD issues I am struggling with.
When I get those straightened out on the above schematic, I can draw a schematic of the full DodoHand circuit.
Which will add LMC7101 buffer amplifiers for the IR LEDs, and SN74HC595 shift registers for indicator LEDs.
Since you are strobing the leds it is just a matter of a big capacitor to handle the power spikes.By "strobe" I mean power to the IR LEDs is on for a short time while the shift registers read the photo transistors.
What are the datalines?I don't understand the question.
5V
MISO
MOSI
CLK
CS1
CS2
Strobe
GND
There is at least one problem I see, the PL is not on triggered on a clock flank but transparent. This means that as long as the CS line is low you can not shift the data. Qoute from datasheet: "When the parallel load input (PL) is LOW the data from D0 to D7 is loaded into the shift register asynchronously. When PL is HIGH data enters the register serially at DS." You can not just connect the CS to the PL, this is the part where I got "stuck" with using the piso chips as you need some additional control for PL.The CS pin is not connected to the 8 parallel load input pins.
As for the strobing, be careful with the power. You are going to need 13 (26 leds in series of 2) * 5mA = 80mA to turn on all leds for one hand.Ha ha. Clever use of a 74LS121 pulse-width modulation chip.
...
My suggestion not needing the strobe and automatically triggering the parallel load but introducing yet another chip: http://i.imgur.com/Jntical.png
the clock enable (CE) inputs are not used, might as well connect them to the CS line as well.Good idea, I will test this on the breadboard.
As for the strobing, be careful with the power. You are going to need 13 (26 leds in series of 2) * 5mA = 80mA to turn on all leds for one hand.Ha ha. Clever use of a 74LS121 pulse-width modulation chip.
...
My suggestion not needing the strobe and automatically triggering the parallel load but introducing yet another chip: http://i.imgur.com/Jntical.png
But firmware would be complicated because 74LS121 pulses would be asynchronous with Teensy.
The simplest option would be to leave 52 IR LEDs always on.
My schematic of the full DodoHand circuit will show LMC7101 buffer amplifiers stobing the 26 IR LEDs.the clock enable (CE) inputs are not used, might as well connect them to the CS line as well.Good idea, I will test this on the breadboard.
The horror that I see coming is soldering 52 resistors (or 64 if the extra inputs are used). There would be more resistors on the IR leds as well (1 for each led pair, 13 total) to deal with the difference in resistance in the leds themselves.The 52 pull-down resistors can be SMT resistor arrays (4 resistors per array).
Next week I will post the results of the breadboard and firmware test.
Thank you.
I did notice that the clock enable (CE) inputs are not used, might as well connect them to the CS line as well.I tested this, but it did not work because SPI.transfer() is called when slaveSelect is HIGH (inverse of SPI convention is explained in keybrd/src/Scanner_ShiftRegsReadStrobed.cpp)
For fun after reading the comment that the 74165 was not following the SPI rules (and my brain needing to do something else after being in openscad all day). Here is an autonomous schematic that is following the SPI rules (if all the components work like I think they do).
(http://i.imgur.com/j21IXITt.png) (http://imgur.com/j21IXIT)
@wolfv
I did take a look at your schematics. How did the experiments go thus far? Did you try it with the IR Leds already...
Good to see progress on the thumb cluster. Looks nice. :thumb:Its a replacement for the matrix driver but now SPI style as a single SPI device (and SPI can read and write in parallel, that is what is done in this schematic). It works as annotated, row0-4 and col0-5 are the same ones as on the original schematics (thus the leds / photo transistors are not drawn). Fets are there to deal with the current, the matrix is still sourced and I do not think the 595 can handle it. The only gotcha while using the circuit is that you write the row you want to read for N+1 whilst reading the sample N.
What is he schematic circuit supposed to do? Is it a shift register array? Where are the IR LEDs? What are the five JFETs for?
*snip*
It works as annotated, row0-4 and col0-5 are the same ones as on the original schematics (thus the leds / photo transistors are not drawn).That sounds a lot like "Shift register matrix" section in https://github.com/wolfv6/keybrd_DH/blob/master/examples/shiftRegs/README.md
Also I do suggest that you calculate the current based on the typical voltage drop of the IR Leds and the resistors in the original circuit of OldDataHands. The leds are powered by less current than you think, which is a good thing :).
but I ran into a little snag, it will not fit the PCB as designed...
@OldDataHands
How did you decide on the positions of the thumb keys? I modeled the thumb down key based on the right image and then the PCB seems to be simply to small to fit the side buttons. Am I missing something ?
Fets are there to deal with the current, the matrix is still sourced and I do not think the 595 can handle it.TPIC6B595 shift register has same pin out as 595, but is able to sink 150mA per pin, thus eliminating the need for FETs.
I didn't refer to the mechanical shape/size of the original thumb switches in my design.Ok, I will continue the work in this direction and redefine the PCB surface area.
There's relatively little work in the thumb PCB design. If you have a mechanical design that works, I can help get a new PCB designed.
That sounds a lot like "Shift register matrix" section in https://github.com/wolfv6/keybrd_DH/blob/master/examples/shiftRegs/README.mdCorrect, but it will deal with the timing problem and allows the full duplex writing / reading (just remember that you write for the next read cycle). It will also do the strobe internally.
TPIC6B595 shift register has same pin out as 595, but is able to sink 150mA per pin, thus eliminating the need for FETs.Unfortunately I want to drive the leds and photo transistors not sink them to prevent crossplay. This makes all the open-drain types unsuitable, if you can find a high drive 8bit SIPO that can source about 35mA for its maximum ratings the fets can be replaced. Do note that the entire circuit runs on 3.3v as well now.
http://www.ti.com/lit/ds/symlink/tpic6b595.pdf Continuous drain current, each output: 150 mA Max
https://www.adafruit.com/products/457
Edit:Yes, a single MCP23S18 could handle it with the external fets. This design does everything by itself and uses the shift registers where with the MCP23S18 you need to do the strobing from software.
Another option is to drive the matrix with a MCP23S18 (SPI I/O expander), with FETs on the MCP23S18 strobe pins.
So that's what the 74LS121 monostable multivibrator is for. :)That sounds a lot like "Shift register matrix" section in https://github.com/wolfv6/keybrd_DH/blob/master/examples/shiftRegs/README.mdCorrect, but it will deal with the timing problem and allows the full duplex writing / reading (just remember that you write for the next read cycle). It will also do the strobe internally.
Photo transistors can be powered all the time at 3.3v. Only the IR LEDs are turned on and off. This was tested on https://github.com/wolfv6/keybrd_DH/tree/master/examples/shiftRegs/sr4_keysTPIC6B595 shift register has same pin out as 595, but is able to sink 150mA per pin, thus eliminating the need for FETs.Unfortunately I want to drive the leds and photo transistors not sink them to prevent crossplay. This makes all the open-drain types unsuitable, if you can find a high drive 8bit SIPO that can source about 35mA for its maximum ratings the fets can be replaced. Do note that the entire circuit runs on 3.3v as well now.
http://www.ti.com/lit/ds/symlink/tpic6b595.pdf Continuous drain current, each output: 150 mA Max
https://www.adafruit.com/products/457
I didn't refer to the mechanical shape/size of the original thumb switches in my design.Ok, I will continue the work in this direction and redefine the PCB surface area.
There's relatively little work in the thumb PCB design. If you have a mechanical design that works, I can help get a new PCB designed.
powering all of the leds and/or all of the phototransistors is a mistake as it would tend to add noise into the system. Extra leds means unwanted light possibly hitting the sensor.
Hi invultri,Changed the setup to make it 200us
Based on my early testing: https://geekhack.org/index.php?topic=41422.msg838207#msg838207
You may need to consider 200us for reading a stabil result of the switch evaluation (seems to take that long to fully stabilize).
Hi wolfv,Here is a version with the matrix where the leds are sunk via the fets and the photo transistors are sourced via the 595.
Invultri and I agree that powering all of the leds and/or all of the phototransistors is a mistake as it would tend to add noise into the system. Extra leds means unwanted light possibly hitting the sensor. Extra phototransistors means extra, unwanted current on the column from each phototransistor that isn't under evaluation.
Cool. If you can provide me with the locations of the required holes, both for electronics and switch mounting, then I'll create a new PCB.Will do, I think I can sneak in some more design time this friday. I need to create and place the "up" button, reinforce the backside of the anvils and make the frontside of the anvils a bit sturdier. Some assembly drawings would be nice as well. It will be bear time once I get the thumb design V1 done.
You'll (of course) also have to enlighten me regarding the layout of the matrix that you'd like to have.
this should make a roll-your-own SPI compatible matrix driver based on shift register and supporting full duplex.
what happened with sinusoid?
The usual stuff. Food, money, deadlines.I am still at it yes, it takes a bit of effort :)
Worry not, I see Invultri's at it! :D
Do you have an open drain IC in your electronics box? If so could you test this:
(http://i.imgur.com/K0nvfsdt.png) (http://imgur.com/K0nvfsd)
This would allow the use of the MCP23S18, but I do not believe it will work. Do note that the schematic uses a germanium diode.
I don't understand how this could could be useful with more than one switch on a column.
What I see is that the output on the column would be high if any switch is not pressed (i.e. can only be low if all switches on the coulmn are pressed).
Am I missing something?
Well I am often wrong about these things that is why I asked for a test. My mind sees this:
(http://i.imgur.com/EPhjbpVt.png) (http://imgur.com/EPhjbpV)
I still do not believe it is going to work however. I need either a) a good simulator for circuits or b) a breadboard and some components and definitely some sleep as the alarm will ring in less than 6 hours.
I need either a) a good simulator for circuits or b) a breadboard and some components.Yes. There will be many more trial and error before it's all done.
Great you're making progress guys! I created a channel #dodohand on Freenode if you're interested.I will lurk around in there :)
I thought that those pulldowns would be needed. Its a shame that there will be a continues leakage current though. The only reason I wanted to explore it was to investigate if I could use open drain chips (like the MCP23S18 but that still can only sink 25mA -_-) to simplify the design.Well I am often wrong about these things that is why I asked for a test. My mind sees this:
(http://i.imgur.com/EPhjbpVt.png) (http://imgur.com/EPhjbpV)
I still do not believe it is going to work however. I need either a) a good simulator for circuits or b) a breadboard and some components and definitely some sleep as the alarm will ring in less than 6 hours.
Ahh. I think this will work with one small tweak: A high-ohm pull-down after the diode to ensure
that the voltage after the diode discharges when the switch is closed. (Level of need will depend
on the characteristics of the input, but shouldn't hurt in any case. something like 500kOhm would be a
good place to start.
Thanks for the extended diagram - I needed the extra help understanding your column concept.
full duplex 8bit SPI matrix driver with internal strobe function and 5 external outputs, 2 external inputsFast, with room for 5 indicator LEDs, and only 6 connecting wires between hands. :thumb: I am impressed!
The first revision of the thumb unit is now live on my github. Next step would be to actually try and print it, hopefully this week.Show Image(http://i.imgur.com/RUU88H7t.png)
I finally checked out your scad and had a very brief look at the thumb: Looks to me like 2 out of 3 of the
thumb switch mounting holes don't leave room for the head of the screw. Other than that it looks really
promising. I'll have a look at some of the inner geometries later this week. Exciting Stuff!
Let me know when you've got some confidence in the layout and I'll start at the PCB.
But ... deary me that is a lot of chips :-\.Tristate ICs come in packages with 1, 2, or 4 tristates in one IC.
How far along is this? I may be able to provide a bit of funding to take this into production at a larger scale if anyone's interested.Pretty far I'd say, invultri has designed a thumb cluster to go along with OldDataHands OpenSCAD-files of the finger keys, those have been printed through Shapeways. invultri's thumb cluster hasn't been printed yet afaik. Also they seem to have gotten far on the electronics and software.
I hate registering on forums but rediscovering the DataHand again, while reading about the split keyboards made me do it. The split keyboards I see people getting so excited about just seem like a rehash of an old idea. Those DataHand people thought outside the box, but were too far ahead of their time unfortunately. :((https://i.imgur.com/D8LJCfo.png)
If 3D printing doesn't work yet, how about using traditional molds for the keys? Ask a factory in China to make them out of aluminium. Or get a local old school metal worker to make them. :)
To setup biomechanical simulations with parametric model generation takes a lot of time. Does anyone know if Datahand development used biomechanical simulation for development?I'm guessing they did not. If they had done it then how did they justify switches on sides (left/right) of fingers. Try to move e.g. your ring finger left/right without moving other fingers.
Hm, I might be an odd duck, or perhaps well trained from 10+ years on datahand, but I can move ring fingers that way without any problem. Otherwise it'd be major pain to "type" Esc,B,N,Win keys. :-)To setup biomechanical simulations with parametric model generation takes a lot of time. Does anyone know if Datahand development used biomechanical simulation for development?I'm guessing they did not. If they had done it then how did they justify switches on sides (left/right) of fingers. Try to move e.g. your ring finger left/right without moving other fingers.
Does anyone know if Datahand development used biomechanical simulation for development?
You could ask the inventor himself maybe, but he is getting up there in years. I saw a webpage with Dale Retter's address on LinkedIn but I can't find it.
I was thinking about how technology is getting smaller and was wondering if a wearable could replace the DataHand. So I went looking and found this yesterday, but as usual with anything really interesting they have given up. They reached their goal on Kickstarter then gave all the money back, because they needed additional funding that fell through.Then there's also https://www.tapwithus.com/product-2/ (or maybe better link would be https://www.tapwithus.com/overview/ ). Which looks promising, but still somewhat off the mark.
https://gest.co/technology
A system where sensors on your wrist report the vectors to your fingers. That way you could build a DataHand without any moving parts. Everything else would be code.
Edit:
Well it looks like it is already here.
https://www.bebopsensors.com/
Edit 2:
Actually I was just thinking about the risks associated with wearables, in that they put electric fields next to your flesh. It could be a cancer risk. They say the same of mobile phones.
Then there's also https://www.tapwithus.com/product-2/ (or maybe better link would be https://www.tapwithus.com/overview/ ). Which looks promising, but still somewhat off the mark.
I accidentally also saw someone (on Kickstarter?) create a Kinesis-like keyboard that is split to two units (DH style) where one of the units as a whole also functions as [an oversized] mouse, but can't really remember the link. It would be a neat idea to integrate that into dodohand. :-)
Edited to add: https://www.kickstarter.com/projects/1666150716/keymousetm-the-keyboard-and-mouse-re-invented
I've been working on a similar project...
.. here's a bit of a teaser of my first functional prototype :).
I second that nomination. This is unexpected. And all kinds of awesome. :eek:I've been working on a similar project...
This is simply amazing. I'd like to nominate this for keyboard of the year, 2019.
Although, If you like diving straight into the deep end, I won't stop you.
Out of curiosity, how did your datahand break? Electrical or mechanical?
and the idea of ssh'ing into my left and right keyboard units is actually pretty amusing.
I've been working on a similar project...
Well, that turned out better than expected. I had never tried photogrammetry, so I didn't really know what to expect. I ended up using meshroom, which was quite simple to use. And the result turned out as close to the original as I could have hoped.
If people are paying #3000 for these on eBay (with serial cables, and other ancient technology,) I'm sure you could raise tens of thousands, or hundreds of thousands overnight i order to get them developed and manufactured. You get the funding... hire a few competent engineers, subcontract a few manufacturing plants... and not only will you produce the best programming keyboard of all time, you'll likely have earned millions.
Get funding. Don't do this on your own. I'm sure the people on this forum are excited enough to fund the kickstarter.
Speaking of which, here's my second unit, now installed on my desk at work :D
Speaking of which, here's my second unit, now installed on my desk at work :DThat is a nice piece of work. And also Evoluent mouse hiding off to the right side :D
As soon as this gets on the radar of whoever holds the patents of the original DataHand, **** will hit the fan.The patents of the original DataHand have run out by now.
I've been considering creating a new thread for mine, just to make it easier to find, and have less confusion between the 2 different projects. Does anyone have a preference either way? (new thread, or just keep using this one).Well, it can work either way, I think. But it will get crowdy here, the more people will go through the motions to rebuild your fine creation.
Once you start doing the electronics, I did discover one tip you may find useful. Since the LEDs are IR, you can't see whether they're turning on or not... but your phone camera likely can! The IR light shows up as a pale purple glow. That's useful for testing, although in actual use the LEDs have such a low duty cycle that it's hard to see anything even on a phone.Awesome. That worked. At least in proving my point. And checking the soldered board LED connections.
It looks like you found and sourced some actual metal ball-head screws? And you machined the supports they screw into out of aluminum?
Man, I gotta get me one of those. If they ever sell again. Who'd have thought people'd buy that in droves. FunkyShow Image(http://azeron.eu/wp-content/uploads/2018/07/Azeron-Gaming-Keypad-Hot-Red-001-1.jpg)
Just stumbled upon the Azeron gaming keypad (http://azeron.eu/) which seems to be inspired by the DataHand. It doesn't have the east and west clicks for each finger but it has an extra row of keys above the north ones. And since it's a gaming keypad it's not designed for typing and only has 26 keys per hand.
Has anyone here tried it? Even if it's not a perfect substitute for the DataHand I'm glad that that kind of design is starting to gain some traction.
Yeah, 6-DOF was an explicit goal for me. I was never quite happy with the adjustability of the datahand - I could never get things quite where I wanted them. I do agree the adjustment is a bit of pain though. It took me a while to get them adjusted just right. But once I did, I haven't had to mess with it.
It definitely doesn't feel unstable to me though. The magnets I use on the posts have plenty of pull force to keep them down, and after applying rosin on the steel, they don't slide at all - except maybe the thumb cluster sometimes. It's easy to press too hard on the outward keys, especially the lower one that you hit with your knuckle.
The central down keys are probably the thing I'm least happy with, in terms of assembly, and to a lesser extent in terms of performance. In terms of assembly, both the hole in the cluster and the post on the key usually require a bit of cleanup, which can be a bit.. fiddly. Although I was able to get them feeling right, at least to my fingers (which have had many many years of experience on a datahand :)).
And in terms of performance, I do get the occasional stuck key, although it's rare enough that it's not too much of an issue.
I think the design for central keys was probably the aspect of the design that I iterated on the most. Although I don't particularly want to use normal keyboard switches, so I didn't explore that avenue at all. Many many iterations with magnets though. Still room for improvement, but I'm... eh, 95% happy with them :)
The legs are my biggest issue. When I move the clusters, the legs always go into some other direction and then the clusters move as a whole and I have a whole lot of legs to place upwards again. I am somewhat hesitant to screw them tighter as I fear the plastic will not like that.
It seems like if the clusters were already pre-aligned and flat on the surface with a single foot, it'd go way easier.
But I'm gonna postpone replacing those until I'm happy with how the rest behaves.
Speaking of which, it seems the thing now works:
(https://i.ibb.co/vq1BY6j/IMG-20190805-164549.jpg) (https://ibb.co/6wYZB7W)
Just ignore the cables for now ;)
Seems I flipped the finger slots on the PCB, so if you're about to use those, just flip the order of the non-thumb keys.
I'm training like crazy right now. For some reason, even using the original QWERTY-like layout, my finger memory does not kick in. Ah well, is only like the third time I'm (re)training some layout.
I get a very different haptic feeling comparing the central down key with the other keys.
However, I compared it to regular flat keyboard and it has much less force, still, so replacing it with a regular switch probably worsens the issue.
I'm not entirely sure how to proceed.
Btw, how come the down-key has this weird, hard to file layout?
Why the thinner part in the middle, and using an extra part to block the light rather than having the IR tube go through the block above or below the magnet?
There has to be some reason behind it?
Oh, I just realized what you meant by "thinner part in middle". The thinner part on the key post? Yeah, I did that to help make sure that part of the key post doesn't touch the sides of the hole. If I remember right, I was getting some surface irregularities there in the middle area, even on the sides and back, due to the way the slicer handled the hole for the magnet. So I made that area a bit more narrow to ensure that it doesn't touch, so that any surface irregularities don't affect the how the key moves/feels.
That's partly why I didn't want to add another though-hole through the central post for the LED optical path - more opportunity for surface irregularities in the printed surface of the post and the sides of the hole.
PLA on PLA and pretty much any 3d printable non exotic plastic will always stick, fatigue or wear out fast, and depending on what temperature you print at, the part will always be little big/small, printing hot will make the part shrink more when cools off. Also printing thin or thick walls will influence how much is gonna expand/shrink
Carbon fiber infused got very good stiffness and wear resistance, I believe you can find samples (5~10 ft) on eBay/Amazon for fairly cheap, that should be enough to give you an idea of material you want to use without spending $50+ right away. Next down would be PETGAh, I see. Yes, there are some materials out there that might also do the trick. Like steelfill and such.
For you to get some decent results, no matter what material you gonna print with, re-design as needed to have at least 3mm of wall everywhere, Polycarbonate filament beats both carbon pla and PETG but is kind of bendy, same with nylon, you cant use these with thin walls, so, up to you how you want to approach this.
There are other approaches.Yeah, okay, that works for your arms, but I'm not seeing how you can do that for the center down key.
1. Pre-tension the switch, while inserting it, the lever is already exerting some down-force (20% ?) and will take very little force to press it/close circuit.
2. Add 1mm magnets to push/pull/compensate for the pushing power required.I have a suspicion this won't work. At least not for the down key. For pushing, the magnets would have to be above something to push down for which you probably have no space.
5. Optical/IR sensor to sense when the transmitter is being blocked/exposed to light and only use magnets to control the force required to close circuitYeah, that's where we are right now.
6. Re-do your model using SLA/Resin, not filament, you might get better results, smoother non-sticky/movementUh, but I just got this printer...
#4 and#5 Will require extra electronics/board redesign and will not provide much click/clack feedbackWell, to be fair, the click feedback is there thanks to JesusFreke's modeling Genius. The idea to use the magnets for pulling and starting off from where they are in contact creates a sensation not unlike tactile switches.
It appears to me that Datahand is not for people with medium/small hands, I`m saying that because the thickness of the switches and distance between the clusters/switch assembly will force the user to uncomfortably spread fingers to touch the center/down switch or pinky/left and index/right.
For example my hand is 7 inch long, measuring from wrist joint to tip of the middle finger, according to the pictures and measurements I found about DataHand, I would not be able to use the device comfortably.
Part of the challenge is to make the 5 way switch no bigger than 1 inch width/height and keep it serviceable. People with extra small hands... sorry, having Michael Jordan`s hand size would solve lots of design problems
@RSanders or anyone that own a DataHand, do you happen to have large hands/long fingers ? And thank you all for posting pictures of the original device.
The keymouse... the trackball version is $500+..., the mouse version is not even worth talking about, you cant destroy your shoulder constantly moving half pound piece of plastic on the desk...
For that money you can get a cheap 3d printer for $150, micro switches max $20, one roll of filament whatever color you want $15, soldering iron, wires/solder/flux $40, teensy $20
And you can customize it, modify the 3d file and print parts as you please, make modifications to fit your need, hang in there, we`ll get this :)
I couldn't really tell from the images already posted, does your design account for over-travel prevention similarly to the DataHand, i.e. the plastic "fence" around all four key wells?
Each key well has a back that provides a positive stop. It also has a little groove that mates with one in the key to prevent the keys from sliding out when you press them, since they're not held in mechanically, only magnetically. (makes for much easier cleaning/maintenance/replacement!)
Once complete, is the intent to have an open source DIY model for this project
... yes, it already is :)
lalboard.com (http://lalboard.com)
The way I designed the cluster switches will allow about 10 degrees of movement
Thank you both for the images/measurements....easy to clean it with little bit of compressed air.
what ever happened to OldDataHands original project? it seemed to be complete and just stalled. were there problems with it?I think the DodoHand thumb cluster isn't complete.
I believe this was the repository: https://github.com/christianvdstap/dodohand/blob/master/images/dodohand_logo_w_name.svg
very cool! Did you use silicone wires or PVC?The BOM tells me it's PVC. So, yeah, I had to wrangle them a bit. Now they stay the way I need them :)
IronFox, which TOP (1-8) did you use? and approximately how heavy is it?
There's a slight offset in the magnet sketch. What's the usage?
Is there a gerber package for the left thumb PCB of lalboard?
I downloaded https://github.com/IronFox/lalboard/blob/master/eagle/thumb%20left/CAMOutputs.zip but it doesn't contain gerber files.
Ironfox, what is your educational background, particularly the parts that helped you design the modification you made?
I'm pretty envious of yours and JesusFreke's skillz.
Hmm, having some problems with printing some of the parts, I might have to tweak the designs to reduce part complexity, since i don't need as much modularityYeah there’s a fair amount of tuning required to get it working with different printers. I’ve had luck simply scaling everything up a couple percent in the slicer.
1- Why does each N/S/E/W switch have two magnets for the latching? It seems like you could use a steel washer around the center post to achieve the same effect with the benefit that you don't have to worry about polarity of the magnets as much.
2- Why did you choose to create an optical switch instead of using an off the shelf switch like: https://www.jameco.com/z/IRLA075-Siemens-Corporation-Photointerupter-IR-3mm-Gap-Tab-PC-Mount_2078282.html (https://www.jameco.com/z/IRLA075-Siemens-Corporation-Photointerupter-IR-3mm-Gap-Tab-PC-Mount_2078282.html), it seems like these might be easier/faster to assemble, although about the same price.
This is a really neat project and I love the aesthetic of it!
fwiw, It's been many years since I learned on the datahand, but the muscle memory from typing on a normal keyboard mostly transferred. Except for things like the diagonal keys, which obviously have to be remapped, and all of the extra stuff - function keys, cursor control, numbers and symbols, etc. But the muscle memory of typing basic letters was there.
There really shouldn't be any problems with accidental key presses - other than "mapping" errors. e.g. forgetting which key is which, and intentionally pressing the wrong button, vs. trying to press one button and accidentally pressing another.
Do you have a picture with your hand in-place? I'd be curious to see your hand placement/form. It's hard to tell just from the pics, but it seems like it would be a somewhat different hand/finger placement.
They definitely look awesome though :)
Having my hand in a slightly different position may make this more or less likely.
Despite the keys and hand rests being somewhat stationary, I noticed my fingers are not always in the same position.
particularly my right hand fingers may either relax and stretch out or curl together more, but it can be as simple as the wrist angle not being as it was before cause I moved the thing.
Those key wells look super deep. The side keys should really only come up enough that you can just "grab onto" them with the tip of your finger. When typing, my fingers tend to hover just a little bit above the central keys. And when pressing a side key, the other fingers do tend to move a bit as well, but they're raised up a bit and pass over the side key.
I assume, though, you also learned to keep your other fingers still when pressing one key.
For instance when I press the right center middle key, I sometimes also press the right center ring key.
Or pressing any left/right key, I often also press one of the thumb keys or neighboring keys of the same direction.
Having my hand in a slightly different position may make this more or less likely.
Despite the keys and hand rests being somewhat stationary, I noticed my fingers are not always in the same position.
particularly my right hand fingers may either relax and stretch out or curl together more, but it can be as simple as the wrist angle not being as it was before cause I moved the thing. As a consequence some or the other key may end up being closer at one time or the other.
I finally got around to taking a video of me typing on the lalboard, to give an idea of the typing motions. It's definitely a bit weird seeing myself type like that :)
Has anyone explored using the conductivity of the magnets as the switch?
I agree that it seems like your specific-fit version might not be viable for mass consumption. I did have a related thought though: It's hard for most people (ie me) to translate manipulated real-world elements into 3d space. Have you put any thought into designing your individual key clusters with that step in mind? Or laying out a recommended method for making the prototype->final files? Do you think the end goal for most users would be a more permanent setup?
...
ps I spent some time looking at your py scripts. That is wild. It looks like a python version of openSCAD. Is there any way to import those models into the gui version of fusion other than stls? I was so surprised by `import adsk.core, adsk.fusion`!
...
But if you just want to run one of the scripts manually, I think you should be able to install the fscad addin in fusion (https://github.com/JesusFreke/fscad/wiki/Installation) and then add the part folder in the lalboard project (e.g. <lalboard_root>/parts/cluster for the main finger cluster) as a script in fusion (Tools->Add-Ins->My Scripts->'+' button) and run it from there.
I should really add some documentation about that. Documentation has never been my strong suit. haha :)