Katy keyboard (or K80CS (Key80 Contoured Split))

atagunov

16 Dec 2015, 23:50

Hi, I want one in London.

Happy to buy as much stuff ready-made as I can.
Can handle the rest of assembly myself.

[Rant]

guess I'd prefer it with Fn keys (FAR manager fan, Turbo Pascal key bindings)

[Thoughts on modifications]

Not really asking for them - just probing for your interest

[Modification 1]

Would it make sense to tilt thumb pad more?
E.g. for the right half of the keyboard:
- keep the right edge of thumbpad same level as now
- lower the left edge of thumbpad as much as possible
I mean making a step in the direction of Oobly ergonomic keyboard:
https://geekhack.org/index.php?topic=49 ... msg1084760

[Modification 2]

I'd like to try this keyboard in a configuration similar to Yogitype
so the right half may need to stand for me on it's right side and left half on its left side
No modifications needed for that I think - the edges are flat enough?

[Modification 3]

Also - suppose I wanted to bolt the bottom of the keyboard half to smth like this:
https://en.wikipedia.org/wiki/Ball_head
Would the bottom be strong enough as it is?
Or do I need a version with extra thickness?

[Modification 4]

The extra thickness from [Modification 3] might allow for

4.1) bigger tilt in thumbpad (more like Oobly ergonomic)
4.2) bigger tilt sideways and away from user (more like Microsoft Natural with a stand): http://allthingsergo.com/blog/wp-conten ... GP0152.jpg

4.2 is of course achievable with stands

[Credits]

Great work man! As a user of Kinesis Advantage for 8 years I so much wish they'd
- split into 2 halves
- failing that made it be more like Microsoft Natural in shape
- make proper Fn keys (well, this one Katy doesn't solve..)

P.S. Have you seen the webpage on Esrille?
http://www.esrille.com/keyboard/
That guy supplies them in 2 sizes; he suggests people make a paper mock up and figure out which one fits them best
Katy now exists in 2 sizes as well doesn't it?

User avatar
vvp

17 Dec 2015, 15:38

atagunov wrote: Hi, I want one in London.
Happy to buy as much stuff ready-made as I can.
Can handle the rest of assembly myself.
OK, if you have access to an FFF 3dPrinter then you can get models of the case here. Follow the link to share-it later on. There is enough payment options on share-it.

If you want something more then you need to be able to do a money transfer to an IBAN account in Slovakia (i.e. something like 7bit's PAYEUR option) and you must be able to receive a SEPA transfer to the account from which the you will pay. The condition to receive a SEPA transfer is there so that the money can be sent back to you if something would go wrong. UK banks must provide SEPA transfers to their clients sometimes by the September of 2016. Your bank may already provide it or may not yet. UK is special so I do not know but for most other EU countries SEPA is available for free or only a few cents.
The other things I can provide are these:
  • Two PCBs (one for the left side and one for the right side). The PCBs will have parts with reference number smaller than 10 soldered in and the bootloader and the firmware will be preloaded. Price 44 €. I can add two RJ45 jacks, some crimp housings and crimp contacts to connect to the PCBs (if you want pin headers on the PCBs instead of soldering wires directly to the PCBs), and the one IDC receptacle for LCD. This would add 10 € to the price.
  • Raw printouts of the case from an FFF 3dPrinter. These need post-processing as indicated here. The post-processing takes about 14 hours if you already have some experience with it. Price 65 €.
  • Case from an FFF 3dPrinter. The quality is poor compared to an injection molded plastic. The whole case may have a little bit bent in it (about 1-3 mm deviation from bottom plane) when it is finished. I'll compensate for this with glued rubber legs of proper height at the bottom. Price 170 €. We would do it like this: I'll make the case first and then send you detailed pictures and a measurement how big the bent is if any. Then you would decide whether you want it. The case would be sold as it is. I'm willing finish only about 2 cases like this. So this is only a limited offer for people who want to try Katy v0.7 and are too afraid to post-process raw printouts themselves.
  • If you want a pretty and true case then it needs to be pritned using an SLS 3dPrinter. I do not have access to such a printer yet (and maybe I'll never will because prices for new ones are in many tens of thousands). But you can just buy the STL model of the case from shareit and then drop me an email with your shareit order number and I'll send you STL files more suitable for an SLS 3dPrinter for free (the same license) in about 2 days (I did not make them yet). Key-part and palm-part will be merged in the STL model, therefore no need for glueing. A commercial 3dPrinting service will ask about 270 € for printing them. It should look better than the result from an FFF 3dPrinter but I do not know how much better. I did not try this yet.
You need to get yourself all the other things. At least that is the current situation. It may change but not sooner than in about half a year ... and maybe never.

Shipping: I checked few options and it is all about the same. A courier (e.g. UPS) to London would cost about 130 €. A simple post to UK is about 15 €. No tracking number here and it may get lost in post. There is an option to require your signature when delivering it, but I do not know how much this adds to the service cost yet. Requiring a signature at delivery is the only additional service available for UK.

It would be send at the beginning of January after the money transfer arrives. So if you want anything except the STL files of the case then drop me a PM so that we do not bother the general audience here.

The modifications:
Additional F1-F12/F14 keys. I do not ever intend to add these for myself. When Layer/Keypad shifts are so easily available on thumb cluster then I just do not see much point in it. This is also the reason why it has so many thumb keys.

Oobly's thumb cluster. I considered this seriously but the main reason I did not do it is that it would make the keyboard taller. And I would be probably forced to lower number of keys in the thumb cluster too.
atagunov wrote: I'd like to try this keyboard in a configuration similar to Yogitype
so the right half may need to stand for me on it's right side and left half on its left side
No modifications needed for that I think - the edges are flat enough?
Yes the outside edges would be perfectly flat if there would not be small (probably below 1 mm) deviations because of FFF 3dPrinting and glueing. You still need to glue some spacer there so that the pinky column keycaps do not touch table. And also to get stability. Maybe a better option would be to build some stand (maybe from wood) and screw the keyboard bottoms to the stand and then screw keyboard tops to the bottom. This would provide a good stability (provided your stand has it) and you could experiment with angles.
atagunov wrote: Also - suppose I wanted to bolt the bottom of the keyboard half to smth like this:
https://en.wikipedia.org/wiki/Ball_head
Would the bottom be strong enough as it is?
Or do I need a version with extra thickness?
It would wobble. The bottom is only 1.6 mm thick ABS plastics. It is planar. You need to screw a flat (maybe wooden board) to the keyboard bottom first and then mount it all on your ball head. If you screw the keyboard bottom to the wooden board near the 8 screws present on the keyboard case then it should be strong enough. And I think this modification should stay separate so that people who do not want it do not get a taller bottom.
atagunov wrote: 4.1) bigger tilt in thumbpad (more like Oobly ergonomic)
4.2) bigger tilt sideways and away from user (more like Microsoft Natural with a stand): http://allthingsergo.com/blog/wp-conten ... GP0152.jpg

4.2 is of course achievable with stands
Yes, I want to design special stands on which the keyboard would sit. I'm just not sure how quickly I get to it.
And I'll probably try Oogly's thumb clusters but before that I want to give a shot at a track point. That means that Oobly's thumb cluster is at least a year out.
atagunov wrote: P.S. Have you seen the webpage on Esrille?
http://www.esrille.com/keyboard/
That guy supplies them in 2 sizes; he suggests people make a paper mock up and figure out which one fits them best
Katy now exists in 2 sizes as well doesn't it?
Well there is Katy v0.6 and v0.7. The 0.6 version is slightly bigger. But really I do not think v0.6 makes much sense. It does not have any LEDs/photosensor. Well that probably does not matter since LCD is there. Bud especially the pinkie keys are much better reachable on v0.7. My niece has v0.6 now and she decided that she does not want it and rather gest an v0.7 which she likes it much more. So there will be one finished Katy v0.6 available for a sell. Whoever want's it can send me a proposal in PM how much is he/she willing to pay. I'll probably will not sell it for less than than 100 € since that is the cost of parts I put in it. The best proposal wins. The "auction" finishes in January or later if there will not be any proposal at all :-D It cannot finish sooner since my niece did not return it yet.

I have seen Esrille. It is not for me since it is not contoured. I also do not like columns spreading out. I think is a waste of space. Looks cool but wastes space for no good reason. Some people like it and think it is more ergonomic though. The thumb cluster looks OK but has not enough keys for my linking. Of course if it would have more keys then it would not be well reachable any more.

User avatar
vvp

17 Dec 2015, 15:55

Uff and the current status so that people who would be interested know what they get into:

I have a DFU bootloader which does not require the special RJ45 plug (and can be entered by just pressing a reset button) but the software reset from bootloader does not enter the (possibly newly flashed) application code. It is not a big deal. I just means that one needs to un-plug a re-plug the keyboard to exit the bootloader and enter the application. I plan to fix this but I'm not sure whether it will be a success.

The PC client application is still linux only. I still plan to port it to Windows though.

There are two known minor bugs in firmware:
  • If KeypadShift is released before the key it is shifting, then it sometimes can happen that keyboard stays in some funny mode. It can be fixed by pressing and releasing KeypadShift or KeypadSwitch again.
  • Mouse acceleration is not reset when mouse direction is changed quickly.
Of course, I plan to fix this but it is not high on my todo list. The firmware is open, whoever wants to give it a shot is welcomed :-)

User avatar
vvp

21 Dec 2015, 14:51

A note about ootloaders.

Standard Atmel DFU bootloader
  • Use it when you want to be able to reset your firmware without entering the bootloader. This can be useful if you would hack the firmware and it is still crashing and you want to restart it without disconnecting and reconnecting the USB cable.
  • You need a special RJ45 plug which has 5kΩ resistor between pins 7 (oLoad/PC3) and 6 (GND) to flash with this bootloader. All the other pins of the RJ45 plug should be disconnected.
  • Flashing sequence.
    • Disconnect USB cable.
    • Disconnect ethernet cable connecting the two halves.
    • Plug in the special RJ45 plug to the right side.
    • Connect the USB cable.
    • Press reset button.
    • Flash the new keyboard firmware using Atmel FLIP utility.
    • Disconnect the USB cable.
    • Pull out the special plug and connect back the left and the right sides with the non-crossed ethernet cable.
    • Connect back the USB cable ... and you are done.
Modified Atmel DFU bootloader.
  • Use this if you want to be able to flash the keyboard firmware without the special RJ45 plug. The reset button will always enter the bootloader.
  • To flash the firmware just press the reset button and the keyboard enters the bootloader. Flash the firmware using the Atmel FLIP utility and start the application (i.e. the keyboard firmware) from FLIP (with reset checkbox checked) or just disconnect and reconnect the keybaord USB cable ... and you are done.
You can download the bootloader from Atmel website (http://www.atmel.com). Search for "avr1916" application note. The result will contain the application note pdf and a link to the related software (just next to the application note link). Read the pdf file.
The related software is actually a zip file which contains also atxmega128a4u_104.hex. That is the proper bootloader. To get the modified bootloader which does not require the special RJ45 plug apply this patch to it:

Code: Select all

diff -u old/bootloader.hex new/bootloader.hex
--- old/bootloader.hex	2015-12-21 12:00:00 +0000
+++ new/bootloader.hex	2015-12-21 12:01:00 +0000
@@ -1,8 +1,8 @@
 :020000022000DC
-:1000000000C00091780005FD42C0F092400608E172
-:10001000009353060FEF0A950023E9F70091480675
-:1000200003FFECC0E0E0F0E0079116910F3F19F4F8
-:100030001F3F09F4E3C02BC03091CF0137FDFCCF47
+:1000000000C00091780001FF04C002E00093780076
+:10001000F5C0E0E0F0E0079116910F3F19F41F3FA3
+:1000200009F4ECC034C00000000000000000000033
+:100030000000000000002BC03091CF0137FDFCCF45
 :100040003BB72BBFF8012091CA0113E21093CA01FC
 :100050000A01E8952093CA013BBF08953BB72BBF27
 :10006000F8012091CA014093CA013DE93093340060
Edit: Don't forget to set fuses so that boot reset vector points to bootloader instead of application.
Last edited by vvp on 01 Feb 2016, 21:17, edited 2 times in total.

User avatar
vvp

04 Jan 2016, 20:35

Status update for the few users of Katy.
I had free time during the end-of-the-year holiday season and there is some progress!
  • The occasional random bug when a layer shift is released before the shifted key should be fixed. At least, I cannot invoke it any more.
  • You can remap also the program and keypad shift/toggle key positions using the PC application; i.e. their change is possible without any firmware modification.
  • The PC configuration application works on both Linux and MS Windows now (well at least on Windows 7).
  • Macros/programs can be globally disabled/enabled with a key combination.
  • The keyboard program compiler now compiles with the latest GHC and the keyboard programs often compile properly to a byte code which can be loaded into the keyboard. They are loaded using the configuration application and they can run in the keyboard in parallel with the normal keyboard functionality. There are still some significant bugs in the compiler :-(
All this means that is it possible to compile and run a strafe-jump macro which can be triggered by a simple key stroke. Here is an example of the first source code which will actually result in a strafe-jump in COD4. It is still very rough and the jump has long initialization period. But it works. Of course, it depends on the keyboard/mouse setting in the game and the operating system. It looks like this.

Code: Select all

void main(){ while(1){
	short i;
	byte x = -17;
	pressKey(0x2D); // - run
	pressKey(0x0c); // I forward
	pressKey(0x0d); // J left
	for (i=0s; i<150s; ++i ) {
		moveMouse(x, x/2); }
	pressKey(0xE5); // ShR jump
	releaseKey(0xE5); // ShR jump
	releaseKey(0x0d); // J left
	delay(300s);
	releaseKey(0x2D); // - run
	releaseKey(0x0c); // I forward
	break;
}}
The useless while(1) loop and the break command are there to work around a compiler bug.

Programs are probably not much useful but they are for sure a fun to play with :)

atagunov

31 Jan 2016, 00:41

Hi, vvp, received 0.6 prototype fully intanct! Very pleased and thx for great packaging!
Thumb cluster much better positioned than on Kinesis, also having more keys totally makes sense.
Great to have the halves split. It's a success in bettering Kinesis!

Typing on it now. Difficult to re-adjust to key swaps compared to Kinesis - especially the shift keys and enter.
Since I will be switching between Katy and Kinesis I may have to map them back.
(If this is "marketed" to Kinesis fans then it might make sense to have a firmware option which starts with Kinesis mappings and allow people to switch out of it on will.)

Questions and remarks:

How do I use the programming button on botton left?

Windows keys seem pretty useless don't they? (on Kinesis keyboards I move it to F12). And surely nobody needs two of them? I'd consider moving them to the keypad layer or at least swapping Layer shifts with Win keys.

Thanks again for amazing effort! I wonder when I find energy to do a Katy or two myself :)

User avatar
vvp

31 Jan 2016, 01:59

Great the simple post handled it gracefully that it survived the journey without damage. And they even managed to deliver it at the lower bound of the time estimate :-)

As for as the programming keys. Press Prg key (as shift) together with one (or more of the keys below):

Code: Select all

#define SPECIAL_HKEY_CONFIG_LOAD   HID_KEYBOARD_SC_E // together with config number 1,2,..
#define SPECIAL_HKEY_CONFIG_SAVE   HID_KEYBOARD_SC_S // together with config number 1,2,..
#define SPECIAL_HKEY_CONFIG_DELETE HID_KEYBOARD_SC_D // together with config number 1,2,..
#define SPECIAL_HKEY_MACROS_ENABLE HID_KEYBOARD_SC_Q
#define SPECIAL_HKEY_MACRO_RECORD  HID_KEYBOARD_SC_W
#define SPECIAL_HKEY_REMAP         HID_KEYBOARD_SC_R
#define SPECIAL_HKEY_REBOOT        HID_KEYBOARD_SC_B
#define SPECIAL_HKEY_RESET_CONFIG  HID_KEYBOARD_SC_C
#define SPECIAL_HKEY_RESET_FULLY   HID_KEYBOARD_SC_F // together with RESET_CONFIG
#define SPECIAL_HKEY_TOGGLE_BUZZER HID_KEYBOARD_SC_Z
#define SPECIAL_HKEY_READ_EEPROM   HID_KEYBOARD_SC_I // only in debug for SPI EEPROM testing
#define SPECIAL_HKEY_WRITE_EEPROM  HID_KEYBOARD_SC_O // only in debug for SPI EEPROM testing
#define SPECIAL_HKEY_TEST_LEDS     HID_KEYBOARD_SC_L // only in debug for LCD/LED testing
I'm not sure how many configurations are enabled in the firmware now. I guess only 3, for now.

I use windows keys for controlling window manager in linux (i3).

You can remap the keys whatever way you want using the qtclient (KeyboardClient) application. Using the application you can select any USB-HID code for any key both in keypad and normal layers. You can change also positions of KeypadSwitch, KeypadShift and Program keys with it too (these cannot be changed with on-the-fly remap). Just download the firmware ( https://github.com/hercek/keyboard-firmware/tree/katy ). Install libusb library and QT5.5. Change directory to qtclient, and run qmake, and make. That is for linux. On windows, some arguments are needed for qmake to pick up libusb. WinUsb driver needs to be installed for KeyboardClient to work on windows. No special driver is needed on Linux.

You can change the default layout in firmware. Edit definition of logical_to_hid_map_default in file hardware/katy.c. Make sure you will not modify GPIO related code in katy.c (by modifying it very badly you could damage the hardware, not probable but may happen). Recompile firmware (make -f Makefile.lufa) and update the firmware with bootloadHID.

You can also use longer ethernet patch cable than the one I sent. But make sure your ethernet cable is not crossed. A crossed cable may damage the hardware.

Edit: Fix link to firmware.
Last edited by vvp on 02 Feb 2016, 12:02, edited 1 time in total.

User avatar
vvp

31 Jan 2016, 02:04

And for the few guys who are trying to build v0.7 themselves.
I made a simple tilting stand.
k80cs-in-stand.jpg
k80cs-in-stand.jpg (130.64 KiB) Viewed 18132 times
If you want it then the STL files are here.

User avatar
vvp

14 Feb 2016, 19:49

I'm being asked about adding LEDs to the keyboard. Therefore here are some notes about it.

The biggest problem with LED backlight is that we have only 100 mA of current available till the keyboard is enumerated (which happens at the start of the keyboard firmware boot). We can draw 500 mA of current after the keyboard is booted up. I'm not sure how much USB controllers in a PC or a hub would cope with a device which draws full 500 mA of power even before the enumeration is done. My guess is that it would not matter most of the time.

Katy was not designed to support back-lightning. If I would do it then it should be done properly; i.e. an ability to control brightness of each LED separately from software as it is currently possible with the 4 status LEDs. This requires a new schematic and PCB.

But there is an option to add simple LED back-light to current Katy electronics. First the simple constant colour/brightness option:
I would add a single LED into each switch. The goal is to save power as much as possible so that we have a chance to get enough light even ... hopefully within 100 mA. That means selecting high brightness LED which we will drive significantly below its maximum current and preferably LED which has forward voltage at 2 V or below. Low forward voltage allows us to connect two LEDs in series and we still get below 2+2 < 5V available from USB power lines.
An example is here: http://sk.farnell.com/vishay/tlhf42u1v2 ... dp/2251288
The LED package is T1 ... it will still fit below the standard OEM or SP DCS keycaps. A problem may be with some special low profile keycaps ... in such a case you can file the top plastic dome of the LED ... just do not file it down to the metal parts inside the plastic package :) Filling the top of the LED may be a good idea also as a way to increase light dispersion.
Low forward voltage requirement means that green/white/blue colors will not be available since these typically require about 3V ... and we would not be able to connect two LEDs in series ... and we would consume more power.
The LED luminosity is 0.7 cd at 20 mA or about 52.5 mcd at 1.5 mA. Let's assume that is enough. The power consumption will be 80 * 1.5 / 2 = 60 mA for back-lightning. Plus about 30 mA the consumption of the keyboard itself and we get below 100 mA which is very safe and will always work.
When we look at the forward current versus forward voltage of this diode then we get about 1.67 V for forward current of 1.5 mA. Therefore the resistor needed for each two LEDs in series is (5 - 2*1.67)/1.5 = 1.1kΩ
So schematic for two LEDs will be:
sch.png
sch.png (1.89 KiB) Viewed 18010 times
Lets say that we want much more brightness. If so then we need to either find more bright LED (more efficient) or break the 100 mA limit for maximum current before enumeration. Let go and break the maximum current limit. To do so I would recommend to add a mechanical switch which will allow to turn off all the backlight LEDs at once. This may be needed if the keyboard would not boot after connecting to a computer (because we are above 100 mA before enumeration). The solution would be to turn off backlight with the switch, re-connect the keyboard and after it is enumerated (i.e. working) then we can turn the back-light LEDs on.
Lets use 400 mA for back-light which is about the maximum available. For one diode we get 400/(80/2) = 10 mA. The LEDs I selected will be crazy bright at this current (0.35 cd).
When we look at the forward current versus forward voltage of this diode then we get about 1.83 V for forward current of 10 mA. Therefore the resistor needed for each two LEDs in series is (5 - 2*1.83)/1.5 = 134Ω ... well the nearest higher value on farnell is 137Ω. So that would be the one we would use.

Second option is a more complicated but it would allow to control brightness of all back-light LEDs from firmware at once. No individual LED control. This is possible to do by removing power saving features from the photo-sensor and using the freed pin to control the LED current (through a transistor). You can do this only if you have also some experience with C programming since you would need to adjust the firmware. If there is such person who is able to do a bit of C programming and wants back-light then ask and I'll post more information about this option.

atagunov

03 Apr 2016, 17:56

Hi, I'm wondering if CubeX can build parts for Katy. It's mostly suited for PLA and has no heated platform but the build area is 26.5 * 23cm. What are your thoughts Peter, would PLA work?

User avatar
vvp

03 Apr 2016, 21:01

CubeX build area is big enough. The common build plate dimensions are 20×20 cm, and that is enough too. The required build height is below 4 cm. That can be handled ... well probably by any printer.

The main difference is that PLA is stiffer. And it starts to melt at 60°C while ABS starts to melt at 80°C. I printed some key well prototypes from PLA when I was looking for the best switch positions. They were acceptable but they turned out slightly worse than the ABS ones. But it might have been because of my relative inexperience with PLA compared to ABS. I did not try to print a whole case from PLA. Bridges were turning slightly worse with PLA too. I may be because I printed at 120 cm/s with PLA as I do with ABS. My suspicion is that PLA may need lower print speed to get good results.

I'm not sure how to properly treat surface of a PLA print. I have seen a proposal to paint it with ABS juice (ABS melted in acetone but much thinner). And I'm not sure what is the best option for gluing PLA parts together. Superglue is typically used. But it dries very quickly and it may be hard to attach the palm and key parts together precisely in the short time superglue gives you. But this may not be an actual problem. There are superglues which are drying out longer (I have one here ... it is also rather thick compared to a common superglue). So it is a good idea to get a slower drying and thicker superglue and an cyanoacrylate accelerator to speed up drying when the parts are properly attached. If it works then it may be even better than ABS glue since when you spray superglue with the accelerator it will flash dry instantly. So one does not need to wait once everything is matched properly. Just spray it and you are done.
If the painting PLA with ABS juice works well then it may be possible to try plain ABS glue on PLA. If ABS juice would not work on PLA then one definitely can find some paint which will stick well. ABS advantage is that you can just paint it with acetone. It is quick and hassle free and the result is acceptable. And for people who want better results ... well those can experiment with ABS vapour bath. Though I would rather try sanding before acetone painting first.

In general, I think that PLA will work and you can achieve a nice case with it. But, as far as I know, it will take longer to finish the case from PLA compared to ABS. PLA is harder to post-process compared to ABS. Many people prefer PLA to ABS since it is considered healthier. At the end, PLA is much nearer to what we eat than ABS :) PLA is easier to print. You may print without heated bed, print head temperature is lower, and it does not curl so much. It does not do bridges so well as ABS at high high speed (it may be ok at lower speeds). But the raw printouts are harder to post-process. You can still cut thin PLA with scissor or knife. It is just a bit harder.

You can try to search more about PLA at (forums.)reprap.org.

Just a general note to everybody: I'm considering making v0.8. The keywell will be exactly the same as v0.7. I'm very satisfied with it. Thumb cluster will be the same but about 4 mm lower. This will be probably slightly better but especially it will alow more space for a palm key and a track point. If v0.8 will be finished then it will have the palm keys but probably will not have track points yet. Do not expect v0.8 sooner than in a year, if at all. But if I would have something unfinished but worth a post then I'll post.

User avatar
vvp

13 Apr 2016, 23:42

Tetrahydrofuran (THF) can be used to paint PLA parts but it dulls colours. I did not try it myself yet.
http://forums.reprap.org/read.php?178,650551

User avatar
vvp

03 May 2016, 21:31

I have written that I would post some real build times instead of estimates only. So here they are. Those times are from me or kko. So that means they are from somebody who already has few hours of experience in each activity performed.

setup 3dPrinter job: 0.25 h
right key part print time: 4.25 h (material: 116 g ABS)
* clean-up time : 2.67 h
right palm part print time: 1.28 h (material: 34 g ABS)
* clean-up time : 1.0 h
right side :
* switch hole check & seating M3 nuts: 1 h
* glueing key & paml parts: 1.25 h
left key part print time: h (material: g ABS)
* clean-up time : 2.33 h
left palm part print time: h (material: 35 g ABS)
* clean-up time : 0.5 h
left side:
* switch hole check & seting M3 nuts: 1.25 h
* glueing key & paml parts: 1.33 h
right bottom part print time: 2.25 h (material: 63 g ABS)
* clean-up time : 0.75 h
left bottom part print time: 2.22 h (material: 62 g ABS)
* clean-up time : 0.83 h
led holder print time: 0.12 h (material 1 g ABS)
* clean-up time : 0.17 h
glueing template print time: ? h (material ? g ABS)
* clean-up time : 0.17 h
seating diodes and swithes (both sides): 2 h
soldering switch matrix (both sides): 3.45 h
puting all parts except pin headers on PCBs:
* left side PCB: 0.83 h
* right side PCB: 3.75 h
pin headers and plugs, PCB seating:
* left side: 2.42 h
* right side: 5.72 h
RJ45 cable/connectors for left side: 1.12 h
RJ45 cable/connectors for right side: 2 h

Sum of all times: 36.54 h
Notice the sum above does not include:
* 3d printer running time (this does not need to be attended)
* home etching PCBs (no real times since factory PCBs were used)
* loading firmware (if you have toolchain ready ... maybe 5 minutes?)

And here is a proposal for v0.8. Just to let you know that there was a little bit of progress. It should be somewhat easier to print. Otherwise the only changes from v0.7 are:
  • 2 mm more stagger for pinkie columns
  • thumb cluster is lower (about 4 mm?)
  • one more thumb cluster key (I guess it will be easier to access than the original layer shift (the key below space key))
  • the new palm button (not visible on the key part of the case)
v0.8.png
v0.8.png (75.56 KiB) Viewed 17648 times

MRudat

11 Aug 2016, 23:09

On the subject of FN keys, given that the modifier cluster is duplicated for both thumbs, it might be feasible to use a fn-key keypad to support the function keys, as they're typed with far less frequency than the regular keys...

In terms of off the shelf components, one thing that's been crossing my mind to attempt since I've recently bought a Voltera PCB printer, is to print up some flexible PCB strips to mount the keys on, then use ribbon cable to wire parallel strips of keys together; that way the curvature and spacing of the strips could be changed, while using mass produced pcbs, removing a certain amount of the fiddly manual effort involved with producing a curved keyboard, including possible support for backlit keys.

I think that ideally, there could be a generator where you fill in joint length, finger width, ...?, and it calculates a shape to hold the keys in just the right positions to fit your hands.

Given it's feasible to 3d print keycaps, and dual material printers are available, it should be feasible to do custom-sized double-shot key-caps to support people whose fingers are not exactly 1.0 standard fingers wide.

User avatar
vvp

12 Aug 2016, 11:19

Yes, function keys are in keypad layer now. The next version (0.8) will introduce two more keys in each half which can be used as additional layer shift/switch keys. I intend to add at least one more layer (Fn2) to firmware. So there will be KeypadShift (i.e. Fn1) and at least one more layer shift (Fn2). This additional layer (Fn2) can contain small macros e.g. something like this for the right side (the keys Ctrl-F7, Ctrl-F8, Ctrl-F9, and Ctrl-F10 are on the home positions):

Code: Select all

   6       7       8       9       10
Shft-F6 Shft-F7 Shft-F8 Shft-F9 Shft-F10
Ctrl-F6 Ctrl-F7 Ctrl-F8 Ctrl-F9 Ctrl-F10
Alt-F6  Alt-F7  Alt-F8  Alt-F9  Alt F10
This way one can press complicated combinations like e.g. Ctrl-Alt-F6 more easily either as Fn2-Ctrl-AltF6 or Fn2-Alt-CtrlF6. I do not really use function keys much but this looks to me like a better option than adding one more rows of keys for function keys. It is easy to remember and one can press all function key combinations without needing to press one more modifier (KeypadShift) as it is now. That is the rough idea. I'll see how it behaves after I use it for a few months.

Not sure how to efficiently/cheaply make flexible column strips which would lead to non-flexible keywell so that the keyboard does not feel mushy. The option to generate a custom keywell for each hand sounds better to me. It just needs to be implemented ... which is not trivial. Only the generation of keywell part is about 1000 lines of pyton code which drives OpenCascade through FreeCAD. The problem with this approach is that OpenCascade was rather buggy when I was trying to do it (maybe it improved in the meantime). I also missed some way to query the generated 3d model. The OpenCascade would need to be extended. In other words - it is a lot of programming to generate full contoured keyboard case automatically from hand dimensions. Or one needs to find much more powerful library than OpenCascade. Anyway generating keyboard case from hand dimensions would be an interesting service for the keyboard enthusiasts. The problem is that it is a significant work which hardly can be done without funding.

Keycaps can be printed but I'm just getting some cheap leftovers from 7bit for 10-20 ¢ a piece. It is much easier than print them but they are without (or with wrong) legends. After learning touch typing legends do not really matter to me. It is nicer when the legends are there but I'm not going to put additional effort into it in the near future.

atagunov

26 Aug 2016, 16:17

Hi VVP, could you please remind me how to do on-the-fly remap on v0.7?

User avatar
vvp

29 Aug 2016, 16:21

I guess you have firmware for v0.6 from 2016-01-11. The special Program layer keys did not change from that time and are the same for v0.6 and v0.7:

Code: Select all

#define SPECIAL_HKEY_CONFIG_LOAD   HID_KEYBOARD_SC_E
#define SPECIAL_HKEY_CONFIG_SAVE   HID_KEYBOARD_SC_S
#define SPECIAL_HKEY_CONFIG_DELETE HID_KEYBOARD_SC_D
#define SPECIAL_HKEY_MACROS_ENABLE HID_KEYBOARD_SC_Q
#define SPECIAL_HKEY_MACRO_RECORD  HID_KEYBOARD_SC_W
#define SPECIAL_HKEY_REMAP         HID_KEYBOARD_SC_R
#define SPECIAL_HKEY_REBOOT        HID_KEYBOARD_SC_B
#define SPECIAL_HKEY_RESET_CONFIG  HID_KEYBOARD_SC_C
#define SPECIAL_HKEY_RESET_FULLY   HID_KEYBOARD_SC_F
#define SPECIAL_HKEY_TOGGLE_BUZZER HID_KEYBOARD_SC_Z
Press Program key together with one of the above keys. So the remap is Prg-R.
Config load/save/del need also config number key pressed (i.e. three keys at once).
Reset fully needs also reset (i.e. it is Prg-F-C).
If you would need to change "Program" triggers, then you need to modify katy.h file, recompile the firmware, and load it to the keyboard.
Sorry, I was on vacation, so it took longer to respond.

User avatar
vvp

09 Oct 2016, 17:52

Well, I printed a mock-up of v0.8 keywell. That is the only significant thing I did from May. Looks good. I though that the new (green) layer shift key will be easier to access than the current layer shift (the key to the right of the green key). But it is about the same thanks to the fact that the current layer shift is a bit easier to reach compared to v0.7. This happened because the whole thumb cluster areas is deeper by about 5 mm now. Well, even better.
mockup-v0.8.jpg
mockup-v0.8.jpg (85.44 KiB) Viewed 16968 times

User avatar
vvp

05 Nov 2016, 19:24

Proposal for the left side. The green buttons are new. I will probably finish it as it is (without changing the shape). Then I use it for few months and possibly experiment with the palm rest and the palm button shapes.
I guess I should call it K84CS now.
Yeah, I run out of the blue filament :roll:
K84CS v0.8 left side
K84CS v0.8 left side
v0.8-left.jpg (92.02 KiB) Viewed 16830 times

FAHall

26 Nov 2016, 08:54

Hey there,

Been suffering from RSI and looking for a keyboard exactly like this. I've not built a keyboard before, but can get help from friends if needed. I have some questions.

1. Are the case models for v0.8 available for purchase?
2. I'm in the US, so I don't think I can buy a PCB from you (can I?) but my University has a PCB printer. Do you have the schematics for the PCBs available?
3. Is there a parts list anywhere? Are there other parts I can buy from you to support the project? Shipping might be a killer, but thought I'd check.
4. I can get access to quite a bit of equipment through my University's makerspace including a 3D Printer, PCB printer, Soldering stations, and electronics experts to help when I inevitably mess up. Anything major I might be missing in the tool department?

I'm only a grad student, so funds are limited, but I'm happy to contribute to this project in any way I can. And, I REALLY want to make one of these.

Please keep up the excellent work, and let me know if I can help in any way.

Best,
-Alex

User avatar
vvp

26 Nov 2016, 21:02

FAHall wrote: 1. Are the case models for v0.8 available for purchase?
Not yet. They will be available when it is finished. I need to build at least one v0.8 to check it all fits/works. Which will not happen this year, probably. But January is possible. Well it all depends how much it will rain here. When it is not muddy outside I'm bicycling. When it is muddy I move the keyboard forward a bit. Anyway, winter weather is quite wet here so there should be a significant progress.

Whoever bought v0.7 3D models (and of course atagunov) will get v0.8 case models when they are finished for free. If they are finished. But there is very high probability now that v0.8 will be finished. The same license as v0.7. Just send me a PM with your share-it sale id if you will want v0.8 STL files. Do it only after I announce that v0.8 is finished.
FAHall wrote: 2. I'm in the US, so I don't think I can buy a PCB from you (can I?) but my University has a PCB printer. Do you have the schematics for the PCBs available?
Unfortunately there are export restrictions on ATXmega(*). Probably because of the DES/AES crypto hardware. Of course, it would be possible to export it to US but that would mean paperwork and I'm not willing to do it for a few PCBs. You can check e.g. with CrimsonFlame. He indicated that he can do PCBs and I think he is from US. Maybe he can help you.
The electronics design files are here. The firmware is here. That is all for v0.7. V0.8 is not finished yet.

(*) ATXmega is unpopular but at one time I was limited by ATmega FLASH size and ATXmega was the most easy porting target for firmware. If there ever will be any work on v0.9 then it may contain a different MCU. Probably STM32F373. It is too powerful for a keyboard but it is cheap and I already know it. If there will be any v0.9 then it will probably have one trackpoint on each side. Yeah, and backlight. Surprisingly to me that seems to be a requested feature. Notice v0.8 will still use ATXmega MCU. It has only very slightly modified electronics compared to v0.7.
FAHall wrote: 3. Is there a parts list anywhere? Are there other parts I can buy from you to support the project? Shipping might be a killer, but thought I'd check.
The v0.7 BOM is here.
The only thing which makes sense for people outside EU is the case 3D models. People in EU can also get finished PCBs.
I could ship you the raw printouts to US but it probably does not make sense because of the shipping. And you would still need to post-process them yourself. Just find somebody with a cheap RepRap 3D printer which has build area of 20x20 cm or bigger. There is lot of them. Surely somebody must be near you. Almost every maker space will have them. A well tuned cheap RepRap can print the case. Of course, professional 3D printing services can do even more easily and the printouts will be prettier than from a RepRap. But Shapeways wanted about 200-300 € for it the last time I checked (about 2 years ago).
FAHall wrote: 4. I can get access to quite a bit of equipment through my University's makerspace including a 3D Printer, PCB printer, Soldering stations, and electronics experts to help when I inevitably mess up. Anything major I might be missing in the tool department?
A 3D printer able to print ABS preferably with a heat chamber. It is possible to print it on a printer without a heat chamber. The parts will warp a bit more but it can be salvaged with ABS-glue. You will need also acetone from the less common stuff. But it should be easy to buy it in a home improvement shop. Just make sure you a buying a clean acetone, not some kind of mix. Actually, if your UNI maker space prints with ABS they probably also have clean acetone. Some metric M3 bolts and nuts ... well check the BOM - everything should be there.
FAHall wrote: I'm only a grad student, so funds are limited, but I'm happy to contribute to this project in any way I can. And, I REALLY want to make one of these.
Well if you can program then firmware can be improved. I have some list of ideas. One somewhat important for v0.8 is to alow merging of a running macro with the current keyboard input. Currently, when a macro runs, it blocks other keyboard input until the macro finishes.
Collaboration the case files themselves is not practical. I wanted to do it in free tools (e.g. OpenCascade, FreeCAD) but they are too buggy for a project as complicated as this. I could not move on because the tools misbehaved too often or did not have important features (like history replay after a modification of a past operator). So it is in a cheap commercial CAD which allows only STL export. Modifying STL files is hard and not useful to me since I cannot reimport it back to the CAD without breaking all the development history. The proper history is important for any model modification. It is possible the original CAD fill will be released in the future for free. But that happens only after me and KKO definitely decide that we do not want to continue in the keyboard project any more. That decision will not come anytime soon if ever.
FAHall wrote: Please keep up the excellent work, and let me know if I can help in any way.
Well, the work will continue as long as it is fun or if it would move fully commercial.

If you have RSI (like) problems then I would say the first thing is to check is the posture and taking breaks from typing. I think it is important to have a split keyboard (so that you can tent it) but it does not really need to be contoured. Preferably column staggered than row staggered. Contouring is good for comfort and I think also for speed but some people say that flat keyboard is better for speed. There are many threads about posture at least on geekhack. I do not think it is much about ergonomics here. This site is more about how to repair ancient keyboards :-D And of course the buckling spring keyboards. Not sure why people like them so much. I had one in about 1995 and that loud monster finished in a garbage bin. :-)

No complicated finger gymnastics when typing. Rather move your hands than trying to stretch fingers to extreme positions to reach far keys. I cannot really comment much more on health problems. I never had any finger or hand problems despite typing almost every working day from my teens. But maybe it is thanks to the fact that as soon as partially split keyboards (aka MS Natural Ergonomic which is not ergonomic at all) came out I bought one. And I switched to Kinesis advantage quite soon (probably in 2002?). And then Katy primarily to get a layer/keypad shift and somewhat more comfortable keywell (lower thumb cluster, more staggered pinkie columns). But the current Kiness Advantage 2 almost for sure has a layer/keypad shift. Unfortunately it is still not split.
Or maybe I never had typing related health problems because I do not have any predisposition for it. But a physician can comment on your health problems. If you did not see one yet then you should consider it.

FAHall

26 Nov 2016, 22:07

Thanks for the response.

I'm already seeing a physical therapist and an RSI specialist. I have wide shoulders and need a split keyboard to keep my ulnar nerve from getting messed up. So, split keyboard is indicated. I want a thumb cluster, which pretty much puts me in DIY land. This design is more in line with my needs than an ergodox, so here I am.

Excuse my newbie question: if I build the version 0.7, would it be fairly easy to swap over to version 0.8? I'm imagining I'd have to print, clean, and assemble the new case, transfer the keyswitches and electronics, and add the two new keys. I'm excited about those extra keys.

I'll clone your firmware repo this afternoon and take a look at the macro code. It's been awhile since I've worked in C/C++, but I'm sure it'll come back to me. I spend my time in Matlab and Python OpenCV these days.

User avatar
vvp

26 Nov 2016, 23:22

V0.7 PCBs can be hacked for v0.8. That is what I'm doing with V0.8. It will have only PCB's which were hacked from V0.7.
I recommended to glue switches so that they hold well and cannot be pulled out when a keycap is being changed. So maybe you can just not glue them and be very careful when changing keycaps. (*) Still you would build the case, wire the whole key matrix and then tear it apart. That is work you would throw away. Look at this post to get an idea how much work you would waste to build v0.7 only temporarily. Notice the times are for somebody who has a few hours of experience in each activity. If you never did some things then there will be a learning curve. Although I would expect no time should be bigger than about two times the specified one. Even for a novice.

Almost all the PCB work would be reused. Only small hacks to the PCBs. I guess they would take about an hour, at most two hours. Case would need to be built from the beginning and key matrix completely rewired. If you would put in the pin headers and the connectors (as I did on my pictures) instead of soldering the key matrix directly to PCBs then you will be able to reuse the connectors/cables. You can reuse LCD exactly as it is in v0.7.

(*) The switch holes were 0.1 bigger (on each side) in v0.7. I made them only 0.05 mm bigger in the v0.8 prototypes. You can try to print v0.7 case with over extrusion of about 5%??? (you would need to do some experiments to find out the right level of over-extrusion). Then they will hold better even without glue. But in this case you risk that you will need to file insides of some switch holes. At the end it boils down to the quality of the 3d printer you use.

FAHall

26 Nov 2016, 23:54

Thanks for the response.

Sounds like it makes the most sense for me to wait until v0.8. In the meantime, I can gather parts and practice those assembly skills =). I'll hack around in the firmware too.

User avatar
vvp

27 Nov 2016, 00:20

I would wait too if I would want the additional switches.
It is almost sure that v0.8 will get out (with a bit of luck in January 2017). Chances of any later version are probably 50/50 :)

User avatar
vvp

14 Dec 2016, 23:00

Here is the hack to v0.7 PCB I was talking about. This is to allow the additional 2 keys on each half. The key matrix was 8x5. It will be 7x6 now. The 8 column lines are shared with LCD so they are still taken even in v0.8. I removed the power saving feature on the light sensor and used the pin for the new - 6th row of the key matrix. This will result in a slightly bigger power consumption (at most about 5 mA on a direct sun) but mostly below 0.8 mA for bright office lightning.
Spoiler:
hack-left-pcb-back.jpg
hack-left-pcb-back.jpg (32.69 KiB) Viewed 16659 times
hack-left-pcb-front.jpg
hack-left-pcb-front.jpg (31.06 KiB) Viewed 16659 times
hack-right-pcb-back.jpg
hack-right-pcb-back.jpg (66.44 KiB) Viewed 16659 times
The v0.8 matrix is numbered like this. It is for the ight side (the left side is a mirror image). The first number is column (0-6). The second number is row (0-5). I.e. the outer thumb cluster keys and the palm key are in "row 0".

Code: Select all

    05  15  25  35  45  55 65
    04  14  24  34  44  54 64
    03  13  23  33  43  53 63
00  02  12  22  32  42  52 62
10  01  11  21  31  41  51 61
20  30  40  50
                60

User avatar
vvp

17 Dec 2016, 14:04

The right side is almost done. You can see the new thumb cluster key at the end of the pointing finger column. The white connector (at the end of the little finger column) connects the palm button to the key matrix. The hex slot screw head in the bottom right corner holds the palm brick. The other such screw is below the PCB (not visible here).
v0.8-inside-right.jpg
v0.8-inside-right.jpg (187.31 KiB) Viewed 16634 times
The picture of the inside of a palm brick with its palm button is below. This is a brick for the left side but the right side brick is just a mirror image.
v0.8-inside-brick-left.jpg
v0.8-inside-brick-left.jpg (27.5 KiB) Viewed 16634 times
The shown key well wiring is an example of how not to do it. The problem started because I soldered all the diodes on switches like in v0.7. It is better to solder enamelled wire on switches so that diode does not get thermally destroyed(*). Because of the diode orientation like in v0.7 I was forced to put the enamelled wire on rows as in v0.7 too. But it would be better to have the enameled wire on columns instead so that at the end of key well column I can easily extend it to the last thumb cluster "row" button. Because I did not have enamelled wires on columns I needed to connect the key well columns with the last thumb cluster switch using a wire with a plastic insulation which can be soldered to diodes at lower temperature. But this means stripping insulation. Which is the work which would not be needed if I would be wise enough to orient the diodes properly.

Summary: It would be much better to solder the diodes with their cathode (the black strip side) to the switch. Then I could connect rows with bare (un-insulated) wire. This would work nice since the row wires are not crossing in v0.8. Then I could connect columns with enamelled wire (directly to switch pins) and easily cross it at the end when extending it to the last button in the thumb cluster "row".

The other thing which should have been done differently is the diodes on the two bottom keys of the pinkie column and the pointing finger column. There is little space there to solder column wires. It would be better if the diodes would be positioned about 5 mm higher (more far away from the end of the columns) to provide more space for soldering.

Otherwise it looks OK.

(*) One needs to solder enamelled wire at a rather high temperature. E.g. for Ø 0.2 mm it is about 400 °C. Using a lower diameter wire would need lower temperature. Next time I'll go for Ø 0.15 mm.

User avatar
Phenix
-p

19 Dec 2016, 15:37

Nice update!
One question tough: As Dactyl pics are floating around, could you maybe point out the differences?

I am still interested in doing my first hand wired build, but i still have to learn more once I feel confident to start building

User avatar
vvp

19 Dec 2016, 21:24

I like Dactyl. It is a great project! From my point of view, it is the second best DIY keyboard ... after mine.
The obvious and not really important differences:
  • Smaller number of keys.
  • Harder to 3d print using an FDM/FFF method (e.g. on a RepRap). You probably really need a commercial SLS service to get a good result printing Dactyl. I would not dare to try to 3d print Dactyl on my cheap RepRap.
  • No LCD, LEDs, light sensor.
Significant thumb cluster difference. The hardest to reach thumb cluster key on Katy (and I bet also on Dactyl) is the top far thumb cluster corner key (Alt in my layout). And Katy has the top two thumb cluster keys shifted nearer to the key well by about ⅓U. They are easier to reach because of that.

Where Dactyl is slightly better than Katy. This is possible mostly since it has less keys and no integrated palm rest.
  • Cheaper to 3d print by a commercial service.
  • Cheaper since it has less keys / keycaps and uses Teensy instead of a custom PCB. Well actually my custom PCBs probably would not be more expensive compared to Dactyl if you already have the tools to etch a PCB and solder at home. Katy's PCBs are designed with a rather big feature size and therefore etch-able even using a toner transfer method. Actually, it would not be hard to make a PCB for Katy which would host Teensy or the future Elf board but who cares?
  • People who want Teensy (probably the most popular keyboard controller) have it right there.
  • Smaller, easier to move around.
Why I would not build a Dactyl for me:
  • Too far away far-top (Alt) key on the thumb cluster. Significant.
  • Smaller pinkie column stagger and not enough curved and raised top two pinkie keys. I would mind this quite a bit. This was one of the primary reasons v0.7 was created so shortly after v0.6. V0.8 is taking long but that is because v0.7 is good enough for me.
  • Less thumb cluster keys. If I would already have Dactyl (with better pinkie columns and the Alt thumb keys) then it needs a different approach than Katy. I would remove PgUp, PgDn, (Home, End on the other side) from thumb clusters and use the outer thumb cluster keys as modifiers: Ctrl, Alt, Shift, Win. One of the big keys would be Space (BackSpace on the other side) and the other big thumb cluster key would be LayerShift. All the missing keys I have on Katy would be in a layer. I would loose standard 104 key compatible numpad in a layer :-/ Not a big deal. It would be harder to have two layers shifts I'm just now adding with Katy v0.8 (one for numpad, one for F-key combinations). I would mind this a bit but not significantly enough to throw away my hypothetical Dactyl.
  • I think that thumb cluster keys with different vertical height are better than Dactyl's curved thumb cluster. But this makes only a difference if one does not use a palm brick on Katy (if you want to hit thumb cluster from a low palm position). Not significant.
  • Dactyl uses ATmega32u4 without additional EEPROM. I would not fit in it my version of chrisandeae's firmware with all the features I want. And I definitely want on-the-fly macros and remap and the virtual machine for interpreting programs (e.g. the strafe-jump macro). As far as I know no other firmware has on-the-fly remap/macros yet. But and I2C EEPROM can be added. It would be enough for macros but probably not for programs (I2C is slow). But I could design my own controller for dactyl. So there is a usable workaround.
  • Dactyl's experiment with flexible PCBs is interesting but I but it is much more work than just hand wire it. Just use a thin bare wire in one direction and a thinner enamelled wire in the other direction. A piece of cake. But I bet it was fun to play with the flexible PCBs. This is a detail. I just would not use the flexible PCBs.
  • Dactyl key well has plastic rims around the keys. Well, it may look better but it makes it harder to clean up the keyboard. You cannot just easily blow away dust, hairs, breadcrumbs, or ash (if you are a smoker) from between the keys. Most of the garbage will stop at the rims and stays in the key well :roll:

User avatar
Phenix
-p

19 Dec 2016, 21:38

thank you a lot for that detailed answer!
Makes me believe even more that your design is the best (for me), and Im still impressed about your skills.

Nevertheless I cant etch pcbs/3D print at home, so I will need to check where to get it made somewhat cneap..

Post Reply

Return to “Workshop”