Katy keyboard (or K80CS (Key80 Contoured Split))

vvp · 19 Dec 2016, 22:03

You are in EU. I can provide you with finished PCBs if you are afraid to pull it out yourself. Or if you are a little skilled with circuit design you can use some of the common controllers (e.g. Teensy, ...).

Anyway the biggest problem is the access to a 3d printer. The printed case is by far the biggest part of the price. If you are on a budget and can not get free access to at least a cheap RepRap then go for Dactyl. Download the stl files and upload them to e.g. Shapeways to find out how much it would cost. Dactyl'\s case is about half, well maybe ⅔ of Katy case. So it should cost at most ⅔ of Katy case (if done by a commercial service).

If you can find somebody with a well tuned(*) RepRap with a 20x20 cm build area (common dimensions between RepRaps) then the material price is about 10 €. The rest is whatever you can talk the RepRap owner to. It prints on a quick Delta RepRap (120 mm/s, 8000 mm/s²) in about 17 hours (summed time of all the required parts together). That is the minimum printer time you need to get "donated" by the printer owner. If the printer speed is slower it will take more time. The acceleration is also very important for the final print time. If the printer owner is not experienced with setting the slicer parameters for his printer(*) then there will be some failed prints.

(*) Every printer requires slightly different slicer parameters.

Ray · 19 Dec 2016, 22:58

I got a friend with a printer, who will probalby "donate" that time for me.
But (!) I am not friends witch MX at the moment. Would it be hard for me as a noob to change the files with a free programme, so that it will accept Alps switches? (I don't want him to "donate" his time, only of the printer, as much as possible)
Would it be different on the files for Dactyl or Katy?

vvp · 20 Dec 2016, 12:00

@Ray:
I do not really know how hard it would be to modify all the switch openings to accept Alps or Topre or whatever other switch you prefer. The main problem is that only STL files are available. The cheap CAD I have does not allow to export STEP files. It was possible to upgrade it for 2200 € but that option does not seem to be there after they were bought by 3dSystems. Maybe it was moved somewhere else. Anyway I do not have disposable 2200 € only to provide STEP files too. So the question is how hard it is to use e.g. freely available Blender to modify STL files to accept different switches? I do not know the answer. Anyway the first thing which needs to be done is to check whether different kind of switches will fit when they have a keycap. The key well is contoured so if the alternative switches are taller or require taller keycaps there may not be space there. I probably could create STL files for different kind of switches easily if my CAD does not fail when it will need to replay history long few hundred operations (after changing the switch opening shape which is defined somewhere at the very beginning). My guess is that it will probably fail. If so then the parametric behaviour of the CAD will not help me and would be back to unite (and probably subtract) correcting shape at each hole opening which is a lot of work.
You probably can do this more easily with Dactyl if you know how to script OpenSCAD. I guess the switch opening there is defined by some subroutine and the only thing needed may be to modify the subroutine and let OpenSCAD to compute the new case. And Dactyl is pretty nice keyboard. The only things I really mind on it are the low pinkie column staggering, missing top two pinkie key "elevation", and the top two thumb cluster keys being too far away. The rest of the Dactyl changes compared to Katy are not that significant for me. You may modify the OpenSCAD source files to fix this. All the Dactyl source code seems to be available on github.

@Phenix:
You may also wait for this custom Topre board. It seems to be far from finished but there is a chance for a group buy and it looks that at least the case will not be that expensive. The thumb cluster will be bit further, its top keys are too far, but at least you can easily adjust pinkie column staggering just for the size of your hand. Which can be very useful especially if your hand is significantly different compared to mine.

Ray · 20 Dec 2016, 12:20

Thanks for your info. I guess I could modify the openings in Blender (more like "do it fast, fix it with a Dremel or hotglue"), but before I do that for 50+ Openings, I would try it with MX to test

I also have to mention, from the first visual impression, Dactyl has a slight advantage. I know my thumb can't handle so many keys, three functions per thumb is actually taxing a lot for me. But I also think you are right for the pinky columns (on a non-bowled board, I have 1u stagger compared to index- and middlefinger, and it still is uncomfortable reaching one row above homerow.)

vvp · 20 Dec 2016, 13:23

You are right that dexterity of thumb can be problem for some people. But the good thing about having more keys is that you can use only the ones which are easily reachable for you. Of course, there may be people who can comfortably reach only just between the two keys ... oops.

And then there is a problem of learning into muscle memory all the differences between the thumb keys. It happens to me once in a few days that I get somehow confused and I'm hitting a wrong thumb key and I do not understand why it does not work ... till I look at the keyboard and realize I was hitting the wrong key

Ray · 20 Dec 2016, 16:35

It is definately a brain-thing for me. Once I changed the layout on my split from two different thumb-fns to one thumb-fn and a pinky-fn I still had to figure out "well, it is on the other layer then", but that was much better than "so it is on the other layer, still the other layer, no - not backspace!… DAMN, THE OTHER LAYER!"

PS: I will stop derailing this thread - for now. Thanks for your answers.

vvp · 21 Dec 2016, 11:16

Yes, I agree that layers get confusing when their number goes up. V0.7 has only 2 layers (the normal which is on every keyboard) and the keypad layer (primary reason is numpad almost like on the standard 104 key keyboards and the function keys F1-F12). V0.8 will have one more layer (together 3 layers). I'll call it function layer where there will be function keys F1-F12 always with one modifier(*). I could add another layer (together 4) since I'm adding two buttons on each side. So there would be a comfortable layer shift for it on each side. But I do not know what I would put on it ... so it is probable I will not add it. Maybe people who want separate Mod key on linux can use it. It will probably stay only as an alias for some other layer shift.

(*) So e.g. the keys on the right side at position with numeric keys 6, 7, 8, 9, 0 and below will be something like

Code: Select all

Win-F6  Win-7   Win-8   Win-9   Win-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

To tell the truth I do not have much use for function keys with modifiers. I use function keys quite a bit but hardly ever with additional modifiers. So this is almost only a theoretical experiment for me. I'm curious whether I'll like the new palm button ... or whether I remove it on my version. Support in firmware and hardware will stay there but I may disconnect it and use only a plain brick (without the button) for a palm rest.

Phenix · 21 Dec 2016, 20:56

Well- On my dox I had
arrow
media
symbols-levers, which made comfortable for me..

vvp · 21 Dec 2016, 21:44

You probably do not need the arrow layer on Katy. Arrows are in the bottom row and the bottom row is very well reachable on a contoured keyboard. The bottom row is slightly easier to reach than the top row. Planar bottom row was the biggest problem I did mind on Ergodox. Well and the thumb cluster a bit too far too.

Changing number of layers needs firmware recompile at least. Or porting and loading a different firmware. That is about a day or two of work for a skilled programmer if the source firmware is already based on LUFA. Btw, I learned that suka's firmware supports on-the-fly remap/macros too. And I bet his firmware supports many layers. His keyboards have so little keys that I would feel like typing on a stenograph

In theory, the maximum number of layers depends only on the EEPROM size. At least on some places the current code is generic to support more layers. I'll see how well it is when I'll be adding the new Function layer. If the multiple layers support is very generic I can make the layer count a compile time constant. But it probably will not be already generic enough. In such a case I'll not do this in a near future ... if ever. Somebody else can though

vvp · 24 Dec 2016, 09:47

And the inside of the left side:

: v0.8-inside-left.jpg (160.55 KiB) Viewed 20681 times

I soldered the diodes on all the switches at once => the left side has wrong diode orientation too => there was more work making the keyboard matrix. Just as bad as on the right side.
Happy holiday!

vvp · 02 Jan 2017, 16:12

Hardware is done:

: v0.8-full.jpg (251.16 KiB) Viewed 20716 times

And it seems to be working fine. The basic firmware functionality is working. But I added only one more layer. So there are 3 layers now: normal, keypad, function. Two new buttons were dedicated as function layer shifts. Another two new buttons work as "macro shfit" for now. The idea is that I can assign macros to a key combination (e.g. MacroShift-A, MacroShift-B, ...) without blocking any other key combination which may be useful for OS. Well this is a firmware change and can be used also on V0.7 hardware. One just needs to sacrifice some other key as MacroShift. The basic firmware features seem to be working but it is not tested well yet. The PC client application for easier key remapping, macro management, and program uploading is not updated for V0.8 yet.
Default qwerty like layouts:

: layout-normal.png (51.53 KiB) Viewed 20716 times

: layout-keypad.png (67.07 KiB) Viewed 20716 times

The function layer defaults are the same as the keypad defaults. I plan to finish the PC client application support for v0.8, add mouse wheel support, improve LCD information ... and probably increase the amount of memory which can be used for stored configurations (if e.g. one wants to have an easy way to switch between qwerty like layout and dvorak like layout and more). The current setup can save only 2-3 layouts which differ in almost everything in the normal layer. The saved/inactive configurations are saved as differences from the default. Therefore the more the layouts differ the less can be saved. At the end I may look at some speed optimizations and merging the running macros with the actual matrix scanning results.

vvp · 11 Feb 2017, 17:19

OK, v0.8 is done.
Well I did not do everything I planned but sva built his v0.8 K84CS based on the latest STL files and succeeded. The pictures I posted in January used a bit different STL files. The differences were only from the inside so it does not make any difference for the keyboard use and outside look. Small thin plastic walls were added inside so that it prints more easily. It is a bit easier to print than K80CS files. Firmware is in a better shape. Some bugs were fixed even in K80CS version. So if anybody built K80CS then you may consider firmware update.

The firmware is on github.
The kicad source files for PCBs are here.
The STL case model files are not free. If you want them ... well the most easy way for me is if you buy v0.7 files (follow the link to share-it from this page) and drop me a PM or email with your ShareIt Ref Number and I'll send you also v0.8 STL files. If you insist I can update the share-it web too :-/ Anybody who already has the v0.7 STL files and wants also v0.8 then just drop me a PM or email with the ShareIt Ref Number and the new STL files will be sent back by email.

What I planned to do for v0.8 and I did not do yet (and probably will not do it till the end of this year):

a new macro kind which will merge current keyboard state with the running macro
the PC client application works on linux but not on windows yet

I use K84CS for a bit more than a month and the summary is:

The macro button. I think I like it more than the palm button. Now, when macros cannot steal a key combination from use in the OS, I use macros much more.
The palm button is OK. I'm not delighted but I do not mind it there and I use it. I just do not think it is much better than a well positioned thumb key. But sva likes the new palm buttons a lot. So I guess everybody is different.

Here is the right way how to connect diodes to the switches (notice the orientation of the diodes and also the fact that rows use bare wires (the diode leads themselves in this case) without insulation and the columns use enamelled wire.

: v0.8-sva-right-inside-full_s.jpg (146.55 KiB) Viewed 20612 times

: v0.8-sva-left-inside-full_s.jpg (187.95 KiB) Viewed 20612 times

I do not know whether there ever will be v0.9. If yes then I'll probably add a trackpoint or analog liner switches with software controlled force-feedback curve. I think the force feedback analog switches is a much better way than a trackpoint. CherryMX switches have 4 mm travel that is quite a lot. When a modifier would be pressed then they would behave like simple linear switches (i.e. the programmable tactile force feedback would be changed to simple linear) and the depth of the switch press would specify how quickly mouse moves in the given direction. The home keys (asdf and jkl;) Would use these special programmable keys to control mouse. I have some ideas how to do it. I'll just probably will not have time for it

GEIST · 15 Feb 2017, 18:24

Could you post some images from the outside?

vvp · 16 Feb 2017, 00:14

Well, I can post some from my build. The outside shape of the case is exactly the same as sva's case. The differences are only from the inside. So it will do. I already posted the overall view. The tilt angle was 11° here:

I guess you are interested in side views to have a better idea about the shape/tilting. The tilt angle shown below is 15°. Also different keycaps are used.

: near-side.jpg (30.63 KiB) Viewed 20134 times

: right-side.jpg (26.5 KiB) Viewed 20134 times

: far-side.jpg (33.58 KiB) Viewed 20134 times

: left-side.jpg (36.16 KiB) Viewed 20134 times

: top-view.jpg (41.41 KiB) Viewed 20134 times

: tilt-view.jpg (27.11 KiB) Viewed 20134 times

I forgot to take a picture of the bottom but there is nothing on the bottom. It is just a green plastic plane with cutouts for eight M3x6 hex socket screws (which hold bottom and the top parts together and a Ø 3mm hole through which I can press the reset button.
The left side is the same as the right side but without USB cable, LCD, LEDs, the reset hole, and the PDI hole (the square opening on the near side (the first picture in this message)). PDI hole is the debug port for firmware development.

The pictures are kind of small but I do not want this thread to load long time because of tens of huge images. If you are interested in high resolution pictures of some parts then let me know and I'll probably link them to my web. Though the links will work for only about a week. Or maybe I can upload them here and hide them in a "spoiler". Will that make sure that the pictures are not being loaded until the user presses the "spoiler" button? Still I do not want to load deskthority with megabytes or images.

infowolfe · 28 Mar 2017, 00:28

Will you be updating the files on hck.sk anytime soon?

vvp · 28 Mar 2017, 09:28

I do not expect any hardware changes(*) before the end of this year. There is about 30% chance of v0.9 ever happening but definitely not before the end of this year. Well, there is also a chance that I may design dedicated PCBs for v0.8. The current ones are only modifications ("hacks") of v0.7 PCBs for v0.8. But this will happen only after v0.7 PCBs are spent (6 pieces are unused pairs are still here). The PCB update is unlikely to happen before the end of this year if ever at all. Anyway the PCB update does not matter. It is not important how exactly the traces are routed and which exact parts are used.

Well, the BOM can be updated for v0.8. The new 10k resistor for the left "hack" pcb of v0.8 hardware is missing there. Also 7bit does not sell keycaps for 0.1-0.2 € per piece any more. The cheapest ones I saw were for 0.5 € a piece. And only one MOSFET is needed now. And some replacement (e.g. 2N7002BK) should be mentioned for the MOSFET since NX7002AK was not available the last time I checked. Let me know if you want updated BOM. I can do it by the end of this weekend. Well, I'll not look for the current prices of all the components again.

(*) Improvements to firmware (published on github) are expected and very probable. At least, the macros merge-able with the current keyboard state and configuration names on the LCD. I may also look at why the PC-client application stopped to work on windows (it works well on linux). A password manager in keyboard will probably happen sometimes later too.

Edit: Just a typo in a version number fixed.

Malkavian · 28 Mar 2017, 15:43

Some time ago i read that palm rests not only are not very useful, moreover they usually are harmful, because you tend to put your wrists on them while typing, blocking your tendons. If I want to rest my hands I prefer just to put them at other place.

vvp · 28 Mar 2017, 19:46

Well, I think they are not a problem if:

they do not make you to bend your wrist,
they support the palm and not the wrist.

Proper typing requires you not to use them while typing. If you care and cannot force yourself not to use them while typing then just dismount them. They are detachable. I'll keep them mounted for me.

Malkavian · 29 Mar 2017, 08:56

Fine. You have thought of everything

vvp · 01 Apr 2017, 11:50

I added BOM for K84CS as I indicated on Tuesday.

kiltannen · 27 Apr 2017, 21:18

Hi! Long time since I've been in touch.

I've had a few life hiccups the last 18 months- as a consequence my ability to think about moving forward with this has been on hold till now.

I have available a UK postal address, and I'm wondering how much it would cost for a set of pcbs with the controller loaded with firmware soldere on. I would be happy to populate the rest of the parts myself...

I have just connected with a local community makerspace that will do the printing for quite cheap.

Having brought myself up to speed I'm planning on doing a v0.8 minus the palm key. Still planning to swap left and right sides...

I already had previously got keycaps and switches so that gave me quite the incentive to get back onto the build bandwagon when life started to get back to normal.

vvp · 27 Apr 2017, 22:11

It is the same as specified in this post. That makes it 44 € plus shipping. Shipping to London without tracking number was about 10 € the last time I did it. Two PCBs with parts soldered and firmware and bootloader loaded. The PCBs will be hacks of v0.7 PCBs for v0.8. The offer is valid only till there are some free PCBs in stock. Shipping only to EU. Payment only by SEPA bank transfer.

IIRC, you and CrimsonFlame are both in US. You may want to check with him whether he can give you some advice how to get the parts etc.

BOM for K84CS. You do not need to add the palm bricks and the palm buttons. Though you may want to close the palm brick mounting holes in the model. You can do it with e.g. ABS glue or in a software which can modify STL files. Or screw on some thin cover (instead of a full palm brick with a palm button).

vvp · 30 Apr 2017, 12:25

I implemented the support for macros which merge with the actual keyboard state. It was pushed to github. I used it only a little. There might be some bugs. I wanted to get it out since somebody indicated he might have a look at it and I want to let him know that it is already done.

Macros which are triggered by one key only are merged with the actual keyboard state. For example, if the macro bound to key A in Function layer is Shift-F1 and Ctrl-A is pressed in the Fucntion layer then the actual code emitted to OS is Ctrl-Shift-F1. Macros which are triggered by more than one key continue to be exclusive as they were: they will not be merged with the actual keyboard state. All the macros continue to be defined on the fly as before regardless whether they are merging or exclusive.

This is implemented for all Katy versions (from v0.6 to v0.8). The only difference for v0.8 is that the full-reset will fill <modifierKey>-<functionKey> chords into the function layer like this (the first 4 key rows):

Code: Select all

Win-F11 Win-F1 Win-F2 Win-F3 Win-F4 Win-F5 ScrlLck  NumLck Win-F6 Win-F7 Win-F8 Win-F9 Win-F10 Win-F12
Alt-F11 Alt-F1 Alt-F2 Alt-F3 Alt F4 Alt F5 CapsLck  Applic Alt-F6 Alt-F7 Alt-F8 Alt-F9 Alt F10 Alt F12
Shf-F11 Shf-F1 Shf-F2 Shf-F3 Shf-F4 Shf-F5 VolUp    Insert Shf-F6 Shf-F7 Shf-F8 Shf-F9 Shf-F10 Shf-F12
Ctr-F11 Ctr-F1 Ctr-F2 Ctr-F3 Ctr-F4 Ctr-F5                 Ctr-F6 Ctr-F7 Ctr-F8 Ctr-F9 Ctr-F10 Ctr-F12

That's only the default. People can redefine it whatever way they like.
Notice that LayerShift / LayerLock keys are not included in the number of macro trigger keys. Therefore e.g. FunctionShift-A counts as one key trigger A which triggers a mergable macro Shift-F1.

vvp · 07 Jan 2018, 22:53

There were some Katy improvements this holiday. Much less than I hoped for though:

Prg-B chord was fixed to actually reboot the keyboard (instead of causing it to hang beeping).
KeyboardClient PC application actually works on windows again. I guess it did not work in the past for me because of the state of MS patches on my machine. It started to work without me changing anything in the source code. It was tested on Windows 7 and 8.1.
KeyboardClient supports saving/restoring layout (mapping of keys to HID codes) into/from a file.
KeyboardClient tries to load QT plugins from the directory where the executable is located first. This allows for copy/paste "installation" on a new machine.
Tilting stand for v0.8 model got small protrusions and the keyboard bottom part got the matching indentations so that the parts can "lock" together. If you want to try it then send a PM/email request for the updated stl files.

Phenix · 08 Jan 2018, 01:11

Sounds cool!

vvp · 12 Apr 2018, 10:03

I pushed a firmware update to github. Vertical and horizontal mouse wheel is supported now. Also the way how mouse emulation is done is changed. One can now control (increase/decrease) mouse speed depending on which mouse keys are pressed. When a mouse key for a direction is pressed then the cursor is accelerating in that direction. If two opposing mouse move direction keys are pressed at the same time then the accelerations cancel out and the mouse cursor is moving at a constant speed. This allows to set the desired mouse speed (quicker or slower then the previous speed) interactively.
E.g. press left mouse movement ... the speed starts increasing and when you do not want it to increase any more then press also right movement (while still holding the original left movement). If you want to decrease the speed then release left mouse movement temporarily (while holding right mouse movement).

Do other keyboard firmwares emulate mouse like this?

I'm surprised how well it works. I'm not sure a small joystick or keys which can sense how deeply they are pressed are needed now for a good mouse support.

I plan to make the mouse acceleration configurable.

Edit: Ooops, mouse emulation does not work on windows. Maybe something with device descriptor. I'll look at it later.
Edit2: It is fixed. Works at least on Windows 7.

sanjibukai · 10 Jun 2018, 01:58

Hi,
Awesome build!!
Do you have a demo video or something?
How the palm buttons are used?
Layers switching?
What's the purpose of the screen?

vvp · 10 Jun 2018, 19:42

sanjibukai wrote: ↑Hi,
Awesome build!!

Thanks.

sanjibukai wrote: ↑Hi,
Do you have a demo video or something?

Sorry, I do not.

sanjibukai wrote: ↑Hi,
How the palm buttons are used?

I use them as Function Layer Shift now. But one can redefine them in any other way. If layouts are modified with the PC configuration application then any key can be redefined to anything. If the functionality is redefined with the built-in Program key then special keys (Program, Macro, Layer Lock, Keypad (Layer) Shift, Function (Layer) Shift) cannot be redefined.
I'm considering increasing number of layers to 5 (or maybe at most to 9) but that will not be anytime soon.

sanjibukai wrote: ↑Hi,
Layers switching?

There are 3 layers (Normal/Default, Kepad Lalyer, and Function Layer).
Except layers, there are 10 configurations slots. A configuration is a set of 3 layers which can be backed-up under some number key (0-9). A backed-up configuration can be retrieved later on.

sanjibukai wrote: ↑ What's the purpose of the screen?

It shows:

current layer name (one of Normal, Keypad, Function)
one letter indicator whether macros or programs are enabled
light sensor raw value (it equal to about ½ of lux)
which lock is active (Caps/Scrol/Num) .. these are indicated also by the LEDs (which have brightness control based on the data from the light sensor)
small help indicating what is the state of the keyboard when one is programming macros or remaping keys
a value of the current divisor when configuring how many times the mouse pointer speed or the mouse wheel speed is slower than the keyboard polling rate (which is 2 ms)
error messages (e.g. "USB Wait" when host is not communicating with the keyboard)

The default layouts are below. One can redefine them in any way; these are just defaults.

Spoiler:

vvp · 17 Jun 2018, 23:00

Looks like FDCC0802C-FLYYBW-51LK alphanumeric LCD (5V TTL logic) is discontinued). There is a substitute like e.g. NHD-0208AZ-FSW-GBW-33V3. Unfortunately it is 3.3V CMOS logic. Therefore a small change to the controller PCB is needed. If somebody would need it and is afraid to update it himself then let me know. I can update the controller.

I have found LCDs with proper dimensions and 5V power source but they used 5V CMOS logic. That would not work reliably with the current controller (if it would work at all).

vvp · 13 Nov 2018, 09:28

Kko pointed me to a nice idea how to make PCB using toner transfer method but without heat transfer (iron). Ironing is the most flimsy part of the process. Here is an alternative with acetone and alcohol:
https://www.youtube.com/watch?v=HBIxvwZ_0og

I also added a key press counter to LCD of K84CS. Not really useful; just for fun.