ErgoDox - Custom split ergo keyboard.

[sordna]

Can't the PCB have a cutaway so that the socket has more room up and down? Of course the socket should be secured by the case, not by the PCB (you would need some flexible leads between socket and PCB).

[Dox]

Can't the PCB have a cutaway so that the socket has more room up and down? Of course the socket should be secured by the case, not by the PCB (you would need some flexible leads between socket and PCB).

No, those sockets need to be soldered/fixed on the PCB and even if I was doing that, the distance from the interior bottom to the top of the case is 16mm (13mm usable for a connector) it's still not enough.
Let's find something else!

[ic07]

I still like the 3.5mm (or 2.5mm) TRRS best, especially aesthetically - as long as it's possible to make it safe from shorting Vcc and any of the other 3.  It looks like the size limitations are going to keep things small enough for my taste whatever gets decided on though .

If using 2 sockets is an option, have you looked at any of those small coaxial power connectors?

Or something simple like a small 4 pin molex?  (Actually, I used to think this connector would be too big and not very pretty, but now I'm starting to think it might look cool...)

sordna:  If you want a curly phone cable anyway, you could always cut the connectors off one and solder some others in their place.  I've been sort of planning on making my own cable if I can, just to get the size and such just right.

[Dox]

I still like the 3.5mm (or 2.5mm) TRRS best, especially aesthetically - as long as it's possible to make it safe from shorting Vcc and any of the other 3.  It looks like the size limitations are going to keep things small enough for my taste whatever gets decided on though .

If using 2 sockets is an option, have you looked at any of those small coaxial power connectors?

Or something simple like a small 4 pin molex?  (Actually, I used to think this connector would be too big and not very pretty, but now I'm starting to think it might look cool...)

sordna:  If you want a curly phone cable anyway, you could always cut the connectors off one and solder some others in their place.  I've been sort of planning on making my own cable if I can, just to get the size and such just right.

Yeah think that the TRRS option is the best for now. Avoiding to short the Vcc is easy, just put the power on the contact that is the furthest outside of the case. That way, there is no chance to short anything.
I prefer to use cables/connectors that are build for external use. That rules out the molex and ribbon cables.
I can't seem to find a pcb mounted 4 contact TRRS 3.5 or 2.5mm. I have to continue searching.

[Parak]

I can't seem to find a pcb mounted 4 contact TRRS 3.5 or 2.5mm. I have to continue searching.

http://search.digikey.com/scripts/DkSearch/dksus.dll?x=0&y=0&lang=en&site=us&KeyWords=CP-43514-ND ?

[ic07]

I can't seem to find a pcb mounted 4 contact TRRS 3.5 or 2.5mm. I have to continue searching.

Would this 2.5mm audio jack work?  Kps linked to it a while ago (I remembered because it was just just before I joined the forum and they were talking about I2C).

Or maybe this 3.5mm audio jack would be better - or maybe there's a different one on there that'd be preferable, I'm not really sure what some of the specs mean so I couldn't tell.

Avoiding to short the Vcc is easy, just put the power on the contact that is the furthest outside of the case.

What about things like if the connector gets plugged in to the right hand side first, and then shorts on the left hand side case (or some keys, or something)?  Or am I just being paranoid now, lol.

[Dox]

Thanks Parak, order placed!

ic07, I prefer the 3.5mm as there is enough place for it and it will be more sturdy.
No matter what side you plug first, with the power on the outside, I think there is no chance to short anything.

[Dox]

ic07, I'm trying to compile your firmware but I get this error.

Code: [Select]



Compiling C: lib-other/pjrc/usb_keyboard/usb_keyboard.c
avr-gcc -c -mmcu=atmega32u4         -I. -gdwarf-2 -DF_CPU=16000000UL -Os -funsigned-char -funsigned-
bitfields -ffunction-sections -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=./li
b-other/pjrc/usb_keyboard/usb_keyboard.lst -I. -std=gnu99 -MMD -MP -MF .dep/usb_keyboard.o.d lib-oth
er/pjrc/usb_keyboard/usb_keyboard.c -o lib-other/pjrc/usb_keyboard/usb_keyboard.o


Linking: firmware.elf
avr-gcc -mmcu=atmega32u4         -I. -gdwarf-2 -DF_CPU=16000000UL -Os -funsigned-char -funsigned-bit
fields -ffunction-sections -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -Wa,-adhlns=lib-oth
er/pjrc/usb_keyboard/usb_keyboard.o -I. -std=gnu99 -MMD -MP -MF .dep/firmware.elf.d lib-other/pjrc/u
sb_keyboard/usb_keyboard.o --output firmware.elf -Wl,-Map=firmware.map,--cref -Wl,--relax -Wl,--gc-s
ections     -lm
c:/winavr-20100110/bin/../lib/gcc/avr/4.3.3/../../../../avr/lib/avr5/crtm32u4.o:(.init9+0x0): undefi
ned reference to `main'
MAKE[1]: *** [firmware.elf] Error 1
MAKE[1]: Leaving directory `C:/Users/Dox/GIT/benblazak-ergodox-firmware-201e38c/src'
MAKE: *** [all] Error 2

I also tried your compiled .hex and nothing is happening. Any idea what's going on?

[ic07]

I think the compile error was from me using `$(shell find ... '*.c')` in the makefile (which in windows probably meant that no .c files were included in the build at all, lol).  Sorry, I forgot to think about that.  Hopefully it works now (using `$(wildcard ... *.c)`).

As for the .hex, I just downloaded and retested it on my little setup, and it worked...  What should happen is:
- all the LEDs should go high for about 1 second (while USB initializes and we wait for drivers to load)
- then all LEDs should go off unless one of the indicators is currently set (I have numlock on in the picture below)
- it should wait for "keypresses" and generate them if they're detected

Did I do the diagram wrong?  I'll put an actual pic of my setup below just in case.  

breadboard setup:
- note: row and column pins are disconnected; i don't have switches of any type at the moment, so i've been using temporary wires when i needed to test for keypresses
[ Attachment Invalid Or Does Not Exist ] 48226[/ATTACH]

[Dox]

Ok the hex file is working, I had my 2.2k resistors to the ground instead of vcc :doh:.
I can now compile it too with the revised makefile.
Thanks!

[Dox]

I have tested the firmware on a breadboard and everything seem to work fine.
I'm now modifying my 3d model with the 3.5mm TRRS and then the pcb.
After 6 months, this is getting very close to the first prototype. Thanks to everyone who got involved in a way or an other until now!

[lorem3k]

You could probably use threaded 3.5mm connectors for extra connection strength.

[dorkvader]

You could probably use threaded 3.5mm connectors for extra connection strength.

Normally, I'm rather against those, but in this case, I think it's okay, as you can use non threaded connectors with most (All?) threaded jacks. I think the real issue now is finding threaded TRRS connectors.

Bytheway, I would still prefer to have two 3.5mm jacks (one to send, and one to receive). It'd be much more flexible in terms of choice (there are a million TS and TRS jacks) and TS and TRS plugs are very durable, and easy to find. I grabbed 20 or so Neutrik (now REAN) NYS-231 TRS plugs. You can get them ~$.70 shipped in low quantities (.90 for the TRS version)
http://www.daleproaudio.com/p-4058-neutrik-nys226-35mm-ts-mono-connector-nickelsilver.aspx

These are easy to solder to, cheap and in practice have been more durable than the extremely beefy Canare F-16

One issue is that you'd be carrying mixed signals power/data on the same connector.
---
I anticipate the largest issue with the TRRS connector is the fact that when it's plugged or unplugged, you will temporarily short each connector to ground as you unplug it or plug it in. This may not be a big issue for the data lines, but there should be some protection for when the power is temporarily shorted to ground.

I will continue looking for a beefy enough low profile connector suitable for this task.

[rburrows]

I love this design and I'm interested in one for ~$400, possibly w/ soldering service.

I have a note/suggestion (apologies if this is already covered upthread):

Is it a deliberate design choice to have outer-bottom key normal-sized rather than wide like the 4 above it? From my own experience with the equivalent key as a modifier (alt) on the Truly Ergonomic board, having a wider key helps in two ways:

As a single modifier: I tend to move my whole arm slightly out of home row alignment. This coarse motion stays accurate because of the wider key surface (Fitts' Law at work?). Similarly, I find swatting the wide hyphen/minus on the top corner of the TE to be easier than on a traditional board.

As a combo modifier with the key above: In this case, the pinky would actuate the bottom key and the ring finger the key above it. The pinky naturally wants to rest farther out than the ring finger, and in the current layout would tend to locate over the "empty" space that could be captured by a wider key.

You're probably too far along on schematics and prototyping but I thought I'd put in my two cents. Keep up the great work!

-Rob

[ Attachment Invalid Or Does Not Exist ] 48815[/ATTACH]

[tjweir]

I'd like to register my interest at $300 and offer a bit of inspiration:
http://www.otd.kr/bbs/board.php?bo_table=album&wr_id=116384

[OrangeJewce]

I have followed this thread closely for a month now, and have slowly built up enthusiasm for this project. Thus, I will throw my name in the hat as well, for anywhere between $300 and $400 (Edit: This would be fully assembled WITH keycaps). I very much look forward to seeing the first prototype!

Cheers,

Ben

[Jim66]

I'm not sure if any of you guys have seen this over at DT; it's a lovely split ergo 'home brew'.

http://deskthority.net/workshop-f7/my-diy-keyboard-collection-or-how-i-became-a-kb-geek-t2534.html

[Spharx]

Damn this is gonna be expensive ;( and also I don't like the shapeways idea.
Did you considered to make this projects more public so that you can find maybe company's who are willing to buy in larger scales or even sponsors?
I would buy a metal version for up to 200$ ... but this would be a miracle if this could be happen.

Pls update the first post if something changes in the design or the price since this is the first information that a uninformed person will get.

Last edited by Dox; 27 Dec 2011 at 17:15.

[jblack801]

Damn this is gonna be expensive ;( and also I don't like the shapeways idea.
Did you considered to make this projects more public so that you can find maybe company's who are willing to buy in larger scales or even sponsors?
I would buy a metal version for up to 200$ ... but this would be a miracle if this could be happen.

Pls update the first post if something changes in the design or the price since this is the first information that a informed person will get.

Or even something like Kickstarter?

[suka]

Damn this is gonna be expensive ;( and also I don't like the shapeways idea.

As I mentioned on deskthority the case parts of the blue split keyboard would cost around 50€  or even less if optimized for it. which I find rather cheap - but for that flat design a custom PCB would also work, true.  But then there would still be no case around it.

The idea of promoting it is tempting, but after that Desaster with the other great design on this forum (can't remember the name, programmable tenkeyless with tracking that was later copied in China) I am not anxious to put my work and money into something that would be too easy to copy anyways.  So open-sourcing the design documents and firmware as well as giving some help building it will allow anybody interested to recreate or better yet improve the design.



Gesendet von meinem MB525 mit Tapatalk 2

[hoggy]

Do you mean Lowpoly's mini-guru?  Or Lilster's filco/phantom case?

The danger of something more public like kickstarter is that you start to cross the line from a hobby to a job.  Hobbies are far more likely to be fun.

This is truly a boutique product.  Unless some company steals the idea, you may never get the chance again.  Grab it with both hands and get your wallet out.

I'm sorry for the rant.

[alaricljs]

I'm sorry for the rant.

If that was a rant I think your blood sugar must be low, or perhaps you're on some depressant?

Anyhow, while kickstarter is nifty there's a whole lot of work to put into making a project KS ready, and there's a whole lot of money that gets eaten by KS.  Also if you decide to go the KS route, you are deciding that if the KS funding falls through the project doesn't happen.  I don't know what sort of link you get to your funders, but here Dox gets the ability to say that he's going through with it one way or the other and the more people that are interested the lower the price is.  You can't vary pricing in KS based on funding and I'm sure they would crack down on someone trying to use KS as a communications platform to get the under-funded project going with different pricing by way of paypal.

[ic07]

Suka: Your project is awesome.  Jim66, thanks for the original post.  If I ever do a keyboard completely by myself, I'm gunna be digging out your link .  Also (in response to some comments on the deskauthority thread), for using a connector between the two halves, have you considered I2C or SPI I/O expanders?  It looks like we'll stick with I2C for this project, but if you're willing to accept the extra wire (5 total instead of 4) SPI would be much faster (from experiment, a simple usage of I2C seems to limit the scan rate to ~167Hz IIRC).  We have a firmware (that's not quite done, but should be stable enough) that'll handle I2C, if you didn't want to just add the capability to your own.  And if the Teensy has similar hardware support for SPI I doubt it'd be overly hard to add.  Anyway, thanks for the write up .

[/HR]

Rburrows, tjweir, OrangeJewce: I've been considering dorkvader kind of the official greeter all this time, but I wanted to welcome you too.  I'm glad to see people still posting to register interest!

[/HR]

And Dox, I know I'm way late, but I never said how excited I was (am) that we're getting close to first prototype.

[/HR]

About the connector:

Did we loose a few posts?  But anyway, the discussion made me think about it even more, and here's a few things I realized (I'll call the MCP23018 side the LH side, and the Teensy side the RH side, for the sake of brevity):

• The LH side isn't connected to anything till we plug it in; so no matter how the contacts are arranged, only one side has power, and we're safe from direct Vcc/GND shorts.
• This makes me think it'd be better to put GND on the sleeve (and probably Vcc on the tip), like dorkvader was talking about.  He had better reasons - I just think it'd be more standard, and just as good.
• I found one other project that was using TRRS for I2C.  He had it wired (tip to sleeve) SCL, SDA, Vcc, GND, with a resistor on Vcc it looks like (and I don't know if anything else).
     
• The user will have a choice of which side to plug in first; so no matter how the contacts are arranged:
• Either the LH Vcc pin will be brought low or the LH GND pin will be brought high; or both.
• Would regular diodes on Vcc and GND be able to help us with this?  Or is the MCP23018 okay with that?  I wasn't able to find it in the datasheet.
         
• Any RH pin will have a chance of touching any LH pin on each insert; so we need to make sure all the pins will be fine with that.



• We also have to keep in mind that SCL and SDA will be oscillating between logic low and hi-Z with a 2.2kΩ pull-up during insert (unless the RH side isn't plugged in to USB yet).

Also:

• I still think we should at least put a current limiting diode (like this one) on the RH Vcc.  If you want, it might be extra safe to put a 2mA one on the LH Vcc.  Or, since it looks like the MCP23018 can operate at full speed down to at least 2.7V, a current limiting resistor should also work.
  
  
• Would it be good to have TVS diodes on all the pins, to protect from ESD?  I hadn't thought of that before, but it seems like a good idea to me, if there's room.

[/HR]

About the firmware:

I was wondering if anyone would care to design a QWERTY (and maybe Dvorak?) layout?  The current QWERTY layout is rather pathetic, but I just don't feel like putting that much time into it because I'm likely going to neglect both and give Arensito a serious shot.  What I'm thinking, if I can get decent QWERTY and/or Dvorak layouts, is that I'll compile the firmware with all three layouts separately, and post 3 different .hex files for everyone's convenience.  If you'd like to take a look, please see the layout documentation file on github (make sure you're on the 'dev' branch), and let me know if you have any questions.

Partly implied in the above, I'm not currently planning to implement on-keyboard remapping.  I'm almost certain it wouldn't be technically hard (it might be almost trivial) with the current design, but I can't think of a good way to do it.  The thing is, if you're willing to learn the *smallest* bit about Make and C (or if you already know both; and I'll try to write a little howto before I consider the project done) you'll be able to remap to your heart's content *and* store keymaps much more easily than you could with on-keyboard remapping, and with no extra effort in the firmware.  If you're willing to learn a lot (or just a little extra, if you already know C), you'll be able to write new keypress/release functions (all keypresses and releases are function calls) and do most anything you want, which wouldn't be possible at all with other methods.  If anyone has some good ideas about how on-keyboard remapping could work though, I'd be interested to hear them; if only because it's a problem I couldn't think of an elegant solution to.

Also, I'm currently working on NKRO.  I'd really like to make it work, but I'm not completely sure if I'll have the patience.  Is this very important to people?

And if anyone has any other thoughts on the firmware I'd be interested to hear them, since the design is starting to finalize in my head.  Not sure what else I'll have the patience/time to implement, but suggestions are always good.

Thanks :) .  Sorry this post is so long.

[hoggy]

NKRO is a great feature when buying - I think it's less important when actually using.  A good deal of members love Model Ms - and they have 2KRO.


Did you mean 6KRO or full NKRO?

[hoggy]

If that was a rant I think your blood sugar must be low, or perhaps you're on some depressant?

There was a lot of editing...

[ic07]

Did you mean 6KRO or full NKRO?

Full NKRO.  Right now we have 6KRO + 8 modifiers, since that's what the PJRC usb_keyboard example (which implements the usb keyboard boot mode) has.

[hoggy]

Cool! 6 KRO + mods would be fine with me.  I don't type that fast and I use my fingers, not my fists.

I'll take a look at the layouts over the weekend if that's okay.

[hoggy]

Would the controller be able to handle mouse movements?  My initial idea would be to have an embedded cursor key set in the right half (layer key in the left half) and the same on the left, but for the mouse.  The mouse click buttons would be on the thumb keys in the same layer.


ijkl - cursor keys
edsf - mouse keys.  Mouse buttons on the two main thumb keys on the left half.

Any thoughts?

[ic07]

 So it looks like I don't need to be sad if NKRO falls through then.  I *do* still want to try though, just because it'd be a shame for the USB spec to beat me like that...

I'll take a look at the layouts over the weekend if that's okay.

Thanks!

---

About mouse movements, it's not possible in the firmware right now, but I think PJRC has some code that would work, so hopefully it won't be way too hard.  [EDIT: I tried it and it didn't work like I hoped - so it will be pretty hard, or at least pretty time consuming.  Oops.  But I'll see if I can do it anyway.]  Thanks for reminding me, by the way, I meant to support that at one point but then I forgot.  It's in my todo list now.

And, sorry, no thoughts on mouse keys from me - lol, to be honest, between gvim and a real mouse, I don't see their purpose - but I think lots of other people here will be happy to have them around .

[boli]

If anyone has some good ideas about how on-keyboard remapping could work though, I'd be interested to hear them; if only because it's a problem I couldn't think of an elegant solution to.

What do you think about the Kinesis way? The process is very simple:
1. Enter remapping mode by pressing some key combination
2. Press the key with the character you want to remap (source)
3. Press key at the location you want the above characters to be at (target)
4. Optionally repeat steps 2 and 3 for other keys
5. Exit remapping mode by pressing some key combination

While this is simple, there are some constraints: you always move all characters from a key, that is unshifted and shifted. That's mostly OK, but some people may want to move number row shifted symbols independently from the numbers themselves for example. Maybe advanced remappings such as this could require software, but basic remapping would not.

Important to note: In step 2 the current remapping does not matter, the "source" character is always from the default unremapped keyboard

Personally I like this approach a lot, it's very easy and requires no software. No matter which OS I boot into, I always have the layout I want.