geekhack

geekhack Projects => Making Stuff Together! => Topic started by: komar007 on Tue, 20 November 2012, 09:11:11

Title: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Tue, 20 November 2012, 09:11:11
Please send your layouts!
If you have some cool layouts for the GH60, please send them to me and I'll include them in this thread. Please attach a short description too.

[attach=1][attach=2]

Please download the current beta firmware snapshot for testing:
[attachurl=3] [old pre-release]
[attachurl=4] [deprecated and buggy]
[attachurl=7] [current]
[attachurl=6] [current, preprogrammed with layout]

DISCLAIMER: the current version of firmware is not yet compatible with USB power requirements in sleep mode. It may draw about 20mA or more in sleep. This shouldn't break anything, but you should know anyway.

CHANGELOG
v0.2-rc2
* fixed bug which caused the keyboard to stop working from time to time
* added support for remote wakeup
* pwm-controlled caps-lock LED
* minor code cleanup

v0.1
* first "official build"

Programming instructions in the post below.

Programming gui:
[attachurl=5] [current version, problems on win 7, please test on linux]
[attachurl=8] [current version, please test on windows xp, vista and 7]
[attachurl=11] [current windows version, please test on windows xp, vista and 7]
[attachurl=12] [current linux version]

Using the firmware
The "official" firmware does not contain any layout on its own, so after programming, the keyboard will enumerate but not send any keystrokes. In order to program it with a layout you need to use a program, which is currently in a very early stage and we need your help to find bugs and make it better.


Windows
After the keyboard is connected, windows should detect it and install drivers. The keyboard can be used without any extra drivers, but programming requires libusb driver. This will hopefully change, when we find someone with winapi knowledge who will remove the libusb dependency from the GUI program.


1. Install libusb driver: download libusb-win32 (link: http://sourceforge.net/projects/libusb-win32/files/latest/download?source=files (http://sourceforge.net/projects/libusb-win32/files/latest/download?source=files)), unpack the zip file. Run inf-wizard.exe from the bin subdirectory. Choose the device with vid = 16c0 and pid = 047c. You should see 2 such devices, choose the one with "Interface 1" in its name. Leave all other options unchanged, save the inf file anywhere when asked and then  click "Install driver" in the last screen.
2. Install Python 3.3 (download from here: http://www.python.org/download/ (http://www.python.org/download/))
3. Download ukbdc_gui, the layout programming program, unpack and run gui.py
4. Choose File->Open and load the example layout file, gh60.lay
5. Click the programming button and wait for a message in the status bar. You should get "Programmed 1026 bytes of layout"
6. At this point the keyboard should send keystrokes according to the programmed layout

Linux
1. Download ukbdc_gui, unpack and run: python3 gui.py (or set the executable bit on gui.py and run it). You need python 3, but most distros will already have it
2. Load the layout, as in windows and click the programming button.

Creating layouts in ukbdc_gui

[attachimg=10]

1. Layer selector - there are 16 independent layers which can be programmed into the keyboard
2. Inheritance selector - each layer (except for layer 0) inherits from some other layer whose number must be less than its own.
3. Programming button - clicking programs the board immediately
4. Key properties - after a key is selected, its properties are presented here; every modification takes place immediately, no need to apply.


How to use inheritance
This is handy if you want to have at least 2 layers which differ from each other only by a few keys. In this case, set the derived layer to inherit from the base layer and set all derived layer's keys' mode to "inherited". Then override some of the keys by setting the "defined" mode. We should have a button which sets all the keys to inherited... I know.


What are actions
For each key (on each layer independently) you can define 0, 1 or 2 actions. There are 2 types of actions: "key press" and "key release", and their meaning is self-explanatory. The action basically changes layers. You can change layer by specifying its number ("Go to layer") or in a relative way with respect to the current layer's number ("Change layer by"), in which case you can write either a positive or a negative integer.


How to do X
Fn button: one special button switches to a different layer when pressed, and goes back to previous one when released
define Fn button's press action to go to another layer, then on another layer define that same Fn button's release action to go back to your base layer. This will basically mean for example: "on press go to layer 1, on release go back to layer 0".

More Fn buttons: you can have a few layers, and you can change them by holding multiple Fn keys, for example Fn2 - layer 1,  Fn2 - layer 2, and Fn1 and Fn2 together - layer 3
On layer 0 define Fn1 with press action "change layer by 2", and release action "change layer by -2", then Fn2 with press action "change layer by 1" and release action "change layer by -1". This basically sets Fn1 as the more significant bit and Fn2 as less significant bit of layer number offset. Now define layers 1, 2 and 3 in such a way that they inherit directly or indirectly from layer 0, so that the Fn1 and Fn2 definitions are common to all 4 layers. On layers 1, 2 and 3 make sure that Fn1 and Fn2 are set to "inherited".
This is how your Fn keys should look on the base layer (Fn1 and Fn2, respectively):
[attachimg=9]

How to do X (advanced)
Cycling through layers: one key, when pressed and released, changes to next layer, after the last layer, it goes back to the first one. For example there are 5 layers
On layer 0 define the key with a press action which changes layer by 1. Make layers 1, 2, 3 inherit directly or indirectly from layer 0 (if you're actually starting from 0, that's the only possible way anyway). On layers 1, 2 and 3 make sure the layer cycling key is set to "inherited". On layer 4, set the layer cycling key's press action to go to layer 0 (as opposed to "change by" as in layer 0).

Conditional keys: esc changes to tilde/tick, when shift is pressed, so that esc is easily available and at the same time tilde can be written (by holding shift and pressing esc) without switching to a different layer using Fn - good for linux/vim users
I'm assuming you already have a number of layers, and that conditional esc has to work independently from which layer you're on.
On all your existing layers define key number 0 to be esc (or use inheritance, of course).
For every existing layer create another one, which inherits from the respective layer, for example for 4 existing layers, set layers 4, 5, 6, 7 to inherit from 0, 1, 2, 3, respectively.
On each of the new layers set all the keys to "inherited", except key number 0, which you need to set to tick/tilde of course.
Now on layer 0 set both shifts' press action to "change layer by 4", so that on each of those layers, pressing shift goes to its corresponding layer, where esc becomes tilde/shift. On layers 1, 2 and 3 it's enough to set the shift buttons as inherited, since they all indirectly inherit from layer 0. Alternatively you can just redefine shifts on all those layers.
In order to provide a way to come back from the extra layers, on each of them set both shifts to "change layer by -4" on key release. You have to do it for every layer separately, since they inherit from different layers.
Warning: in order for this to work properly, you need to use only relative actions ("change layer by...") in the existing layers or you will have to redefine the action keys in the newly added layers, so that while on one of the extra layers, the keyboard actually switches between the extra layers, instead of going back to the original ones.

Fn-lock: 2 layers: basic and extra, and Fn key. When Fn is pressed the extra layer is active, when it's released, the keyboard goes back to the basic layer. When Fn+space is pressed, the keyboard stays on the extra layer, where pressing Fn temporarily goes back to basic. Pressing Fn+space again goes back to basic, permanently.
[attach=13][attach=14]
[attach=15][attach=16]
You will need 4 layers for this.
Use layers 0 and 2 to define the basic and extra layers.
(1) Set layer 2 to inherit from layer 0, and redefine whichever keys you need.
Set up the Fn button to switch between these layers:
        (2) on l. 0 set press action to "change by +2" and
        (3) on l.2 set release action to "change by -2".
You have 2 working layers with Fn button.
Now the locking happens when space is pressed while Fn is being held. So that happens on layer 2.
(4) That's why on l. 2 remove the scancode from space and set up press action to "change layer by 1". This will go to layer 3.
(5) Layer 3 needs to be the same as layer 2, so set it to inherit from layer 2.
The only difference is that layer 3 will be used when the keyboard is Fn-locked, as opposed to layer 2 being used when Fn is pressed. We use different layers with the same keys here as internal state of the keyboard which remembers that the keyboard was Fn-locked.
Now on layer 2, space does nothing, so set it to "defined" and define it as regular space with no actions.
Now, being on layer 3, we want to be able to use the basic layer while holding Fn, but Fn can't go to layer 0, since this would loose information about being Fn-locked and after releasing it on layer 0, nothing would happen.
(6) That's why you have to set the press action to "change layer by -2", so that it goes to layer 1 instead.
(7) Now of course layer 1 has to be the same as layer 0, so set all the keys to inherited, and set layer 1 to inherit from layer 0.
( 8) Remember we want to be able to come back from layer 1 to layer 3, so on layer 1 set the Fn's release action to "change by +2".
The last thing to do is to make sure we can Fn-unlock the keyboard. This happens when we press space, while holding Fn being in the locked mode, so it happens on layer 1.
(9) That's why on layer 1 remove the space's scancode and set the press action to "change layer by -1", which will go back to layer 0.
That's it!

Layouts
komar's layout
(this is not the layout included in the ukbdc_gui package; that one is old, deprecated and buggy)
[attach=18][attach=19]
This is my "official" layout for the GH60. It's designed mainly for linux/vim users, but should work well for others too.
The primary layer contains all the standard keys, except in the upper left-hand corner there's escape.
The second modifier from the left in the 5th row is Fn, and when pressed it activates the second layer. On the second layer there are arrows instead of hjkl (that's for vim users mainly), also another set of arrows in the lower right-hand corner (like in the Poker).
There are also the F keys and a few other, which you can see in the pictures.
You can lock to the second layer by pressing Fn+space. Then the layers are swapped and you have the second by default, and Fn switches it to the first one.
One more feature, especially for linux users is conditional escape. If you press escape while holding shift, tick/tilde is sent, so you effectively get the tilde without changing layers.
Download: [attachurl=17]

hasu's poker layout
[attach=20][attach=21]

Original Poker has two locking layers, Fn+Q fixes cursor keys on right bottom area and Fn+Space places Esc instead of back quote(`). I add my layout file just for reference
This layout is comprised of these layers:
0: default(qwerty)
1: Space lock(cursor keys)
2: Q lock(Esc)
3: Space and Q lock
4: Fn layer of default
5: Fn layer of Layer 1
6: Fn layer of Layer 2
7: Fn layer of Layer 3
Download: gh60_poker.lay (http://geekhack.org/index.php?action=dlattach;topic=37570.0;attach=16520)
Title: Re: GH60 prototype betatesting
Post by: komar007 on Tue, 20 November 2012, 09:11:23
Layout errors
These are the errors connected with support for various layouts (wrong switch positions, missing stabilizer holes, wrong dimensions/distances)
Mechanical errors
Problems fitting various cases, wrong position of mounting holes, dimensions
Electrical errors
Routing, EMI, broken traces, not connected switches, etc
Improvements
New ideas
Title: Re: GH60 prototype betatesting
Post by: komar007 on Tue, 20 November 2012, 09:11:49

What you'll get
1. The GH60 rev. A PCB:
[attach=1]
2. A bag of SMD components:
What you won't get:
1. switches
2. keycaps
3. case

Building the prototype (SMD)
For those who are soldering everything on their own
Controller part
1. Start with the microcontroller (hand solder with a soldering iron)
[attach=2][attach=3][attach=4]
a) place IC1 in the marked position (remember about the right rotation!)
b) hold it in place with a pair of tweezers
c) solder a couple of pins, then do one whole side (use much flux to prevent solder bridges)

[attach=5][attach=6]
d) solder everything else
e) clean the flux residue

2. Solder the controller part of the board (hot-air).
This can be done with a regular soldering iron too (I recommend chisel tip), only X1 may cause problems, so beware.
[attach=7][attach=8]
a) place solder paste on all pads around the microcontroller. Leave the top pad of C3 empty (error described above)
b) place all the parts on positions, put C3 horizontally, only on the lower pad

[attach=9][attach=10]
c) blow hot air and watch the components reflow (the best part)
d) done!

3. Fix C3 error
[attach=11][attach=12][attach=13]
a) heat up C3 (either hot-air or regular iron) and tweak the positioning
b) twist a few wires from a solder wick or any other cable and cut a few mm, solder one side to the cap; try to solder as close to the board as possible
c) bend the twisted wires and solder onto the top pad of C3

USB connector part
4. Solder the USB receptacle and components around it (this can be done with a regular soldering iron too)
[attach=14][attach=15]
a) put solder paste on all the pads
b) place the components, place the USB socket close to the top edge of the board, but not too close;)

[attach=16][attach=17]
c) reflow
d) add more solder to the connector's large pads

At this point you should connect the board to a PC with a USB A - USB mini B cable and check that it enumerates as Atmel DFU

Diodes part
5. Solder diodes
[attach=18]
a) put solder paste on all diode pads
... place diodes
... reflow


WhiteFireDragon also added these tips:

S0 button
a) add solder to one pad (any pad)
b) put one of the leg right on top of this pad with solder, and melt the solder again with the iron until the leg is flush to the pad. This will tack the button down and prevent it from sliding around.
c) solder the other 3 legs to the pad
d) (optional) reflow that first pad and/or add a little bit more solder so everything looks even and clean.
LED resistor
a) bend the two leads 90° to the appropriate length
b) insert them through the two tiny through-holes, and (optional) bend the leads 45°
c) flip over the board
d) you can either clip off the excess lead and solder, or solder first and clip off the two excess leads. If you clip after soldering, make sure none of the solder is clipped.
Yellow LED
a) You must have the capslock switch soldered on first
b) insert the leads through the switch, into and through the PCB holes corresponding to the capslock
c) make sure you pay attention to the polarity. The longer lead is the positive side.
d) follow steps b - d in the LED resistor steps above.

And you have the board in the same stage as the final GH60 will be.
If you're sure the board works fine you may want to protect the capacitor C3 with some super-glue, since it's mounted only on one pad.

Switch position and layout guide coming soon!

Programming the firmware (Windows)
1. download and install FLIP (http://www.atmel.com/tools/FLIP.aspx (http://www.atmel.com/tools/FLIP.aspx))
2. connect the keyboard, press the program button (S1) and wait until it enumerates
3. go to device manager, find the atmega32u4 chip and click "update driver"
4. choose location manually: folder named "usb" inside the installation directory of FLIP
5. once the driver is installed, run flip
6. Device -> Select: choose ATMega32U4
7. Settings -> Communication -> USB, FLIP should show the signature at this point (58 1E 95 87)
8. File -> Load HEX file: choose the hex firmware: ukbdc_gh60-0.1.hex (http://geekhack.org/index.php?action=dlattach;topic=37570.0;attach=14474)
9. click "Run"
10. after programming is done, disconnect the device from USB and connect again.


Programming the firmware (Linux)
Download and install/compile/unpack dfu-programmer from http://dfu-programmer.sourceforge.net/ (http://dfu-programmer.sourceforge.net/).
Issue the following commands in the command prompt after connecting the device and pressing the programming button (S1). You may need root permissions or udev rules to do that.
sudo dfu-programmer atmega32u4 erase
sudo dfu-programmer atmega32u4 flash ukbdc_gh60-0.1.hex
sudo dfu-programmer atmega32u4 start
where ukbdc_gh60-0.1.hex (http://geekhack.org/index.php?action=dlattach;topic=37570.0;attach=14474) is the firmware file.
The keyboard should start working. If it doesn't, reconnect the cable.
Title: Re: GH60 prototype betatesting
Post by: dirge on Tue, 20 November 2012, 09:32:51
Looking good :)
Title: Re: GH60 prototype betatesting
Post by: SmallFry on Tue, 20 November 2012, 09:46:30
Agreed... shame about the capacitor... is there any space on top to put it with a couple vias?
Or just move the cap a little.
Title: Re: GH60 prototype betatesting
Post by: jdcarpe on Tue, 20 November 2012, 09:48:07
Just waiting on the prototype board. Will update here when I get mine built!
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Tue, 20 November 2012, 11:21:26
Broken traces, not connected switches... so does it mean it's not functional?
Title: Re: GH60 prototype betatesting
Post by: SmallFry on Tue, 20 November 2012, 11:23:27
Not that we know of yet. I believe that Komar was just giving examples of what to put in those categories.
Title: Re: GH60 prototype betatesting
Post by: komar007 on Tue, 20 November 2012, 11:28:48
Quote from: SmallFry on Tue, 20 November 2012, 09:46:30
Agreed... shame about the capacitor... is there any space on top to put it with a couple vias?
Or just move the cap a little.
There won't be a problem moving. Only for the prototype we need to play around.
Quote from: SmallFry on Tue, 20 November 2012, 11:23:27
Not that we know of yet. I believe that Komar was just giving examples of what to put in those categories.
Yes.
The only major problem now is this cap.
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Tue, 20 November 2012, 11:39:59
I see, too early and I wasn't thinking on full power. I thought it was a list of a problem not just an example.
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Tue, 20 November 2012, 13:41:56
Quote from: SmallFry on Tue, 20 November 2012, 09:46:30
Agreed... shame about the capacitor... is there any space on top to put it with a couple vias?
Or just move the cap a little.
Vias still needs a hole with traces through it. Since these are all SMD, I don't think you can use vias. I think we can just solder a small wire to each of the pad on the PCB, and solder the other side of the wire to the cap.
Title: Re: GH60 prototype betatesting
Post by: __red__ on Tue, 20 November 2012, 18:00:33
Can you flash the Aurduino bootloader via USB or do we need to go all jtag on it's ass?

Thanks,



Red
Title: Re: GH60 prototype betatesting
Post by: SmallFry on Tue, 20 November 2012, 18:01:21
IIRC, the ATMega32U4's come with the default DFU bootloader that Komar used. I don't have one to be certain though.
Title: Re: GH60 prototype betatesting
Post by: komar007 on Tue, 20 November 2012, 23:47:38
Quote from: __red__ on Tue, 20 November 2012, 18:00:33
Can you flash the Aurduino bootloader via USB or do we need to go all jtag on it's ass?

Thanks,



Red
No, you can't flash bootloader with a bootloader, so you have to use SPI. JTAG isn't available, because I didn't make headers;)
But we don't need arduino bootloader. Atmel DFU is fine and it can program the keyboard's firmware via USB.
Title: Re: GH60 prototype betatesting
Post by: alaricljs on Wed, 21 November 2012, 08:06:15
Flip is not too much of a pain and is multi-platform.
Title: Re: GH60 prototype betatesting
Post by: SmallFry on Wed, 21 November 2012, 08:36:12
FLIP is nice. Easy enough to install in a sandbox of you don't want Java on your main machine. :)
Title: Re: GH60 prototype betatesting
Post by: alaricljs on Wed, 21 November 2012, 08:42:42
The irritating part of flip is that it is order of operations sensitive.
Title: Re: GH60 prototype betatesting
Post by: SmallFry on Wed, 21 November 2012, 08:56:00
I call that idiot proofing. :P
Title: Re: GH60 prototype betatesting
Post by: alaricljs on Wed, 21 November 2012, 08:59:49
Idiot proofing would be them making it so you can't do it out of order.  That, and the little message about 'reset before flashing' should be changed to 'restart flip before flashing'... resetting my controller sure didn't do the job.
Title: Re: GH60 prototype betatesting
Post by: SmallFry on Wed, 21 November 2012, 09:07:06
Heh. Oh well... heh.
Title: Re: GH60 prototype betatesting
Post by: __red__ on Mon, 17 December 2012, 06:34:23
So, to be clear.  If we're not using the plastic poke case but making our own then we can solder C3 as you originally intended...
Title: Re: GH60 prototype betatesting
Post by: komar007 on Mon, 17 December 2012, 06:37:23
Depends on how that case looks, but in general, yes...
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Mon, 17 December 2012, 06:38:25
Even if you are, just take a snip or dremel and cut out ~4mm from the plastic support and you'll be good to go. I don't think that C3 should be a problem.
Title: Re: GH60 prototype betatesting
Post by: __red__ on Mon, 17 December 2012, 06:43:37
Sweet! Thank you gentlemen.

Now I just have two missions:
1) Sweet-talk WhiteFireDragon to forward mine on un-soldered as soon as he gets it :-)
2) A decent source for cherry MX blues since someone bought out verical's supply a few weeks ago over doubling the cost.
Title: Re: GH60 prototype betatesting
Post by: komar007 on Mon, 17 December 2012, 06:56:59
I thought WFD is only soldering a couple of them, and the rest will go to people untouched... But apparently something's changed;)
Title: Re: GH60 prototype betatesting
Post by: TheProfosist on Mon, 17 December 2012, 07:24:25
ill be using mine with the poker case i was going to use for DOX v2.
Title: Re: GH60 prototype betatesting
Post by: dirge on Sat, 22 December 2012, 10:51:11
pads on the X1 could be a little larger for those using soldering stations?
Title: Re: GH60 prototype betatesting
Post by: komar007 on Sat, 22 December 2012, 10:57:36
Yes, I did them according to the datasheet, didn't think about that... I hope you coped somehow;)
Title: Re: GH60 prototype betatesting
Post by: __red__ on Sat, 22 December 2012, 11:23:19
So, wfd - do we owe you monies for shipping?  Also, if it costs extra for tracking, I'll pay it.

I'm an obsessive tracking re-loader.
Title: Re: GH60 prototype betatesting
Post by: dirge on Sat, 22 December 2012, 11:28:44
Well plugged in the USB and it tried to install the atmega driver, so some of my soldering at least has worked. :)
Title: Re: GH60 prototype betatesting
Post by: komar007 on Sat, 22 December 2012, 11:46:10
Nice, the third GH60 in the world has just been built!
Title: Re: GH60 prototype betatesting
Post by: SmallFry on Sat, 22 December 2012, 11:51:13
SCHWING! Super excited Komar! Great work!
Title: Re: GH60 prototype betatesting
Post by: dirge on Sat, 22 December 2012, 12:40:21
Who's the other? or did you make 2? :)  Will get some pics up tomorrow.
Title: Re: GH60 prototype betatesting
Post by: komar007 on Sat, 22 December 2012, 12:43:38
I made 2;)
Title: Re: GH60 prototype betatesting
Post by: hasu on Wed, 26 December 2012, 11:28:46
My GH60 is unfinished yet but almost done except for soldering rest of diodes and switches.
I used The_Beast's plate to compensate flimsy poker case, I miss beautiful matte black PCB :)
(http://i.imgur.com/AexHnm.jpg)

At this time I can register some keys successfully with my firmware! I'll finish rest of soldering tomorrow.
Title: Re: GH60 prototype betatesting
Post by: komar007 on Wed, 26 December 2012, 11:35:14
Great!
Send me your e-mail address and I'll send you a beta "official" firmware with layout programming support but no PC-side software yet:D
I'll also post it publicly soon.


EDIT: so we have one fitting plate...
Which layout is it? Standard ISO, 1.25 mods?
Title: Re: GH60 prototype betatesting
Post by: JPG on Wed, 26 December 2012, 11:55:08
I just want to say that this project seems amazing. I am still new to the mech keyboard universe, and already I spent quite a lot of time on this forum reading all kind of super interesting things.

Probably that one day when my budget allows it I will participate on one of these projects, but mainly I wanted to contratulate you all for these amazing projects/keyboards you make.

Continue posting pictures of your creations :)
Title: Re: GH60 prototype betatesting
Post by: absyrd on Wed, 26 December 2012, 12:01:53
Looking good, hasu!
Title: Re: GH60 prototype betatesting
Post by: hasu on Wed, 26 December 2012, 12:06:44
Quote from: komar007 on Wed, 26 December 2012, 11:35:14
EDIT: so we have one fitting plate...
Which layout is it? Standard ISO, 1.25 mods?
It is original poker layout, ANSI with 1.25 mods.
Title: Re: GH60 prototype betatesting
Post by: hasu on Sun, 06 January 2013, 03:37:39
I'd say I'm happy with my GH60 now. Both Komar007's official firmware and my unofficial one work well without problem on this beta PCB. Thanks komar007 and community for making GH60 happen.       
           
Now, I as a beta tester would share my thoughts and suggestions.
             
[Unofficial firmware]
If you want to try my unofficial version you can find here: https://github.com/tmk/tmk_keyboard/tree/gh60/keyboard/gh60
And I put two version of binaries on public storage to let you give it a shot on your board easily.
1) plain layout without Fn layer: https://dl.dropbox.com/u/1033342/gh60_pjrc.hex
2) my current using layout: https://dl.dropbox.com/u/1033342/gh60_lufa.hex
             
[SMD parts soldering]
There were no real difficulties except for wiring C3 during soldering parts on GH60 PCB.
Final product version of GH60 doesn't need to be soldered SMD parts by hand, so this is not problem at all. Though, I'd say soldering these small parts by hand was delicate and cumbersome, I'm not sure I can do this job successfully again. I won't be surprised even if a beta tester mangle his PCB pad or parts.
To be honest, I needed ChipQuick to desolder miss-aligned ATMega chip and peeled off one of C3 pads a bit from board :)                                     
             
[Rotation of switch]
This is not a real problem at all, too.
Some switches are aligned with rotating 90 degree, my keycaps fit into these switches a bit tightly. It looks like vertical part and horizontal part of MX cross stem doesn't have same thickness. Rotation of 180deg will be better for keycap than 90deg, but I can understand that some are inevitable to allow various key layout option. Just whine.
           
[Screw hole]
No problem with Poker stock plastic case but screw hole between Tab and Q may be a bit out of alignment to the left in comparison with Poker? I think the hole of Poker PCB is also not perfect. My suggestion is to change form of the hole to oval like others, in the result you may be able to adjust positon of PCB to various cases even with tiny misalignment.
Title: Re: GH60 prototype betatesting
Post by: komar007 on Sun, 06 January 2013, 04:12:32
Thanks for your input, hasu!
I know the GH60 "official" firmware is not good enough yet, but I'll get back to it just after I end my thesis. I have a deadline on Wednesday so I just have to rush with the final corrections and I'll be working on GH60 again.
Quote from: hasu on Sun, 06 January 2013, 03:37:39

Some switches are aligned with rotating 90 degree, my keycaps fit into these switches a bit tightly.
Well, the main reason was to avoid overlapping of main holes and PCB mounting pins. If we give that up, the switches could be all rotated correctly, I'm just not sure we want that.
So it's not like it's necessary to have them rotated, but it's a matter of deciding which is more important...
           
Quote from: hasu on Sun, 06 January 2013, 03:37:39
No problem with Poker stock plastic case but screw hole between Tab and Q may be a bit out of alignment to the left in comparison with Poker? I think the hole of Poker PCB is also not perfect. My suggestion is to change form of the hole to oval like others, in the result you may be able to adjust positon of PCB to various cases even with tiny misalignment.
Maybe that's a good idea... Everyone could just fiddle with the board to get perfect centering, especially with the cases differing from each other a bit.
Circular hole gives you firm mounting but takes the flexibility.
Title: Re: GH60 prototype betatesting
Post by: komar007 on Tue, 08 January 2013, 05:46:10
Added "official" firmware snapshot for testing and programming guide to the first and third post.
Title: Re: GH60 prototype betatesting
Post by: mashby on Tue, 08 January 2013, 18:07:03
I find this whole project amazing and so grateful that I joined GH when I did so I can watch it all unfold.  :-*
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Tue, 08 January 2013, 23:56:02
After 1 full month in transit and customs, I finally received these and unpackaged the 14 PCBs. The PCBs look very nice overall. The gold pads contrast with the black matte finish really well, especially when it's reflective in the light. I would love to see this color scheme and finish in the final production board as well. One tiny gripe that I have with this is that matte finish tends to scratch easier, and it seems like all of these do have some light scratches right out of the box. Not very visible unless you actually look for the scratches.



I just built two prototype boards, one using all hot air and one was done by hand with an iron just to see if it can be fully built with an iron. Solder paste and hot air was pretty straight forward. Though I did have to manually align the controller and tack down two pins on the opposite sides with an iron first before soldering the rest of the pins with hot air. All other SMD capacitors, resistors, and diodes were done with hot air.

Now the one that I built using an iron took me a while. 166 small pads to solder (not counting any of the tiny pins from the atmega and USB) was really tedious. This board probably isn't a good one to learn SMD soldering by hand if it's your first time. The X1 crystal with 4 pads was almost impossible with just an iron. You can tack down the first pad, but the other 3 pads will nearly be all covered and you won't be able to apply the solder around or underneath. These pads should have been a tiny bit bigger to hand solder. I cheated and ended up using hot air just for the X1 pads. Lots of flux was needed to solder the 44 fine pins from the atmega and 4 USB pins to help prevent solder bridges. The rest of the caps, resistors, and diodes weren't too bad, but just tedious. Lastly, there isn't much room to mess up because these are not the same as desoldering switches. You'll have to desolder 2 pads simultaneously either with 2 irons or hot air. For components with 4 pads or the controller pins, you'd have to use hot air or quikchip with braid if they get misaligned. Pretty much you get one shot to do each component, and I wouldn't have stood a chance if I didn't have a fine chisel tip (<1.4mm) iron and solder wire size 0.020" or smaller.



komar left out soldering steps for a few other components, so here they are:

S0 button
a) add solder to one pad (any pad)
b) put one of the leg right on top of this pad with solder, and melt the solder again with the iron until the leg is flush to the pad. This will tack the button down and prevent it from sliding around.
c) solder the other 3 legs to the pad
d) (optional) reflow that first pad and/or add a little bit more solder so everything looks even and clean.

LED resistor
a) bend the two leads 90° to the appropriate length
b) insert them through the two tiny through-holes, and (optional) bend the leads 45°
c) flip over the board
d) you can either clip off the excess lead and solder, or solder first and clip off the two excess leads. If you clip after soldering, make sure none of the solder is clipped.

Yellow LED
a) You must have the capslock switch soldered on first
b) insert the leads through the switch, into and through the PCB holes corresponding to the capslock
c) make sure you pay attention to the polarity. The longer lead is the positive side.
d) follow steps b - d in the LED resistor steps above.

(http://img.photobucket.com/albums/v288/WhiteFireDragon/keyboard/GH60/th_S0.jpg) (http://smg.photobucket.com/albums/v288/WhiteFireDragon/keyboard/GH60/?action=view&current=S0.jpg)

I'm loading firmware on it now to make sure everything is working....
Title: Re: GH60 prototype betatesting
Post by: dirge on Wed, 09 January 2013, 02:24:40
Nice write up Whitefiredragon, I only used my iron and did find it quite difficult.  I think the pads on the X1 should be enlarged to allow for soldering stations.
Title: Re: GH60 prototype betatesting
Post by: jdcarpe on Wed, 09 January 2013, 06:37:08
Quote from: dirge on Wed, 09 January 2013, 02:24:40
Nice write up Whitefiredragon, I only used my iron and did find it quite difficult.  I think the pads on the X1 should be enlarged to allow for soldering stations.

Good point, but shouldn't be necessary with production boards, as all SMD work will be presoldered at the fab.

Quote from: WhiteFireDragon on Wed, 09 January 2013, 03:17:50
SMD soldering for GH60 is not relevant because the final production boards will come with SMC presoldered on. The only reason that I have to do the SMD soldering is because these are all prototype boards and it's not cost effective only have a few prototype boards soldered at the factory.
Title: Re: GH60 prototype betatesting
Post by: dirge on Wed, 09 January 2013, 07:19:19
Replying like that comes across as impolite jdcarpe.

The X1 is the only component I think I'd have trouble replacing using an iron if it broke.  If the pads were larger with flux and wick may be possible without a gun.  Just depends on whether methods of DIY repair are going to be considered.

If not start the group buy, the board works.
Title: GH60 prototype betatesting
Post by: jdcarpe on Wed, 09 January 2013, 08:01:01
Apologies, dirge. Didn't mean to offend. Post edited accordingly.
Title: Re: GH60 prototype betatesting
Post by: damorgue on Wed, 09 January 2013, 08:36:48
To clearify, for the real production run, the things which we have to solder ourselves are the switches and the LEDs, nothing else, correct? I just want to be sure as I don't know if for instance the USB plug is considered to be SMD. Has it been cleared with a fab yet or is it just the plan for now?
Title: Re: GH60 prototype betatesting
Post by: komar007 on Wed, 09 January 2013, 08:40:20
Quote from: damorgue on Wed, 09 January 2013, 08:36:48
To clearify, for the real production run, the things which we have to solder ourselves are the switches and the LEDs, nothing else, correct? I just want to be sure as I don't know if for instance the USB plug is considered to be SMD. Has it been cleared with a fab yet or is it just the plan for now?
The plan is that the buyers have to solder only switches, THT resistor and caps lock LED. I haven't decided for an assembly fab yet, so that's just plans. I'm getting back to the project again today or tomorrow, and I'll be figuring this all out.
Title: Re: GH60 prototype betatesting
Post by: SmallFry on Wed, 09 January 2013, 08:42:06
Very cool. I can't wait! Thank you once more Komar!
Title: Re: GH60 prototype betatesting
Post by: komar007 on Wed, 09 January 2013, 09:11:41
Quote from: SmallFry on Wed, 09 January 2013, 08:42:06
Very cool. I can't wait! Thank you once more Komar!
There's nothing to thank for so far:D
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Thu, 10 January 2013, 03:11:13
I got a chance to try komar's firmware linked in the OP. It still has a few bugs in the modifier keys. I also flashed it with hasu's hex file and the first layer worked perfectly fine for a poker layout. I don't have switches soldered on yet so I haven't tried the function layer yet.

Also one of the PCBs might have a broken trace, or possible the atmega chip is a dud. The switches that corresponds to keys 8, L, K, and M does not respond. The corresponding diodes for these are D41, D42, D43, and D44. I can't visually see any bad traces though. Still trying to see what's wrong with this area.

Quote from: dirge on Wed, 09 January 2013, 02:24:40
Nice write up Whitefiredragon, I only used my iron and did find it quite difficult.  I think the pads on the X1 should be enlarged to allow for soldering stations.

How long did it take you for iron only? When I tried to solder those X1 pads, I had to desolder a few times to reseat it. I eventually got it, but I wasn't 100% sure all the pads made contact, so I ended up just using hot air to be safe.
Title: Re: GH60 prototype betatesting
Post by: komar007 on Thu, 10 January 2013, 03:56:16
Quote from: WhiteFireDragon on Thu, 10 January 2013, 03:11:13
I got a chance to try komar's firmware linked in the OP. It still has a few bugs in the modifier keys. I also flashed it with hasu's hex file and the first layer worked perfectly fine for a poker layout. I don't have switches soldered on yet so I haven't tried the function layer yet.

Also one of the PCBs might have a broken trace, or possible the atmega chip is a dud. The switches that corresponds to keys 8, L, K, and M does not respond. The corresponding diodes for these are D41, D42, D43, and D44. I can't visually see any bad traces though. Still trying to see what's wrong with this area.
There's probably a problem with column 9 - but the keys that shouldn't work are: 8, I, K, M (I instead of L...).
Please check the trace from pin 8 of the microcontroller. Maybe it's broken or there's a cold joint on it.
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Thu, 10 January 2013, 04:58:19
Ah sorry that was a typo. L is fine, it's 8, I, K, M that are not responding. I reflow everything and even replaced one of the diode to check. It must be a trace or the atmega chip. I don't see anything wrong with the traces connecting these switches, so it's probably near the atmega pin. Which one is pin 8 of the atmega?

Btw I have 4 built, and only 1 of them have this problem.
Title: Re: GH60 prototype betatesting
Post by: JBert on Thu, 10 January 2013, 06:10:47
I wonder if there's anyone going to beta-test the ISO layout... Or will komar007 build one of each anyway?
Title: Re: GH60 prototype betatesting
Post by: komar007 on Thu, 10 January 2013, 06:30:52


Quote from: JBert on Thu, 10 January 2013, 06:10:47
I wonder if there's anyone going to beta-test the ISO layout... Or will komar007 build one of each anyway?
I'll check if the switches fit where they should, but won't build one. I hate ISO:)


EDIT:

Quote from: WhiteFireDragon on Thu, 10 January 2013, 04:58:19
Ah sorry that was a typo. L is fine, it's 8, I, K, M that are not responding. I reflow everything and even replaced one of the diode to check. It must be a trace or the atmega chip. I don't see anything wrong with the traces connecting these switches, so it's probably near the atmega pin. Which one is pin 8 of the atmega?
Please see the ATMega32U4 documentation (http://www.atmel.com/Images/7766S.pdf, page 3). Check continuity with a multimeter between pin 8 and right sides of all diodes on this net. Maybe the via near D44 is broken for example.
Title: Re: GH60 prototype betatesting
Post by: mkawa on Thu, 10 January 2013, 07:11:07
wfd, are you local to socal?

also can you resend your PM to this account?
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Thu, 10 January 2013, 16:29:26
Quote from: komar007 on Thu, 10 January 2013, 06:30:52
Quote from: WhiteFireDragon on Thu, 10 January 2013, 04:58:19
Ah sorry that was a typo. L is fine, it's 8, I, K, M that are not responding. I reflow everything and even replaced one of the diode to check. It must be a trace or the atmega chip. I don't see anything wrong with the traces connecting these switches, so it's probably near the atmega pin. Which one is pin 8 of the atmega?
Check continuity with a multimeter between pin 8 and right sides of all diodes on this net. Maybe the via near D44 is broken for example.

Good news is that there is continuity between pin 8 and those 4 diodes. So at least the PCB is ok because that’s not replaceable. I’ll desolder the atmega controller off this one and try a chip from another PCB. If it works, I’ll just buy a replacement chip for the other PCB. No visible cold joints or broken traces anywhere that I can see, so it must be a bad controller chip:

(http://img.photobucket.com/albums/v288/WhiteFireDragon/keyboard/th_atmega.jpg) (http://smg.photobucket.com/albums/v288/WhiteFireDragon/keyboard/?action=view&current=atmega.jpg)


I'm going to change out the USB mini B connector for a micro B. I think all mico B connectors only has 2 "arms" to solder onto the PCB pads, but the PCB currently has 4. The positions might be different so it might not work. Can you verify that these parts will be ok?

USB micro B (http://www.mouser.com/ProductDetail/FCI/10118192-0001LF/?qs=sGAEpiMZZMulM8LPOQ%252byk2%252bTbV8%2f2X5vivRX5xKgOBI%3d) (SMT, bottom mounted, receptacles)
Atmega32U4-AU (http://www.mouser.com/ProductDetail/Atmel/ATMEGA32U4-AU/?qs=sGAEpiMZZMvqv2n3s2xjsYzXfq0AWv1C4u5a33SlKLw%3d)



Quote from: mkawa on Thu, 10 January 2013, 07:11:07
wfd, are you local to socal?

also can you resend your PM to this account?

For some reason, something triggered me to send the PM to your evil twin, mkawa_ (http://geekhack.org/index.php?action=profile;u=20274) (with the underscore).  I just sent you the PM again to the correct account.
Title: Re: GH60 prototype betatesting
Post by: hasu on Thu, 10 January 2013, 16:48:01
I guess you have bridge between pin8 and 9(PB0 and VBus). This will always keeps PB0 high and means switches off,  it makes sense to me.

Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Thu, 10 January 2013, 17:01:13
Yeah but from the pic, there is a very clear separation between pin 8 and pin 9. There is a small chance of a solder bridge behind the pins that the camera didn't pick up, but I don't think I'm going to diagnose this any further. I'll just put a new chip on to see if that was the problem.
Title: Re: GH60 prototype betatesting
Post by: hasu on Thu, 10 January 2013, 17:07:01
Why not use just multimeter :)
But that pin may be already lactchuped unless you have luck.
Title: Re: GH60 prototype betatesting
Post by: komar007 on Thu, 10 January 2013, 18:01:17

Quote from: WhiteFireDragon on Thu, 10 January 2013, 16:29:26

I'm going to change out the USB mini B connector for a micro B. I think all mico B connectors only has 2 "arms" to solder onto the PCB pads, but the PCB currently has 4. The positions might be different so it might not work. Can you verify that these parts will be ok?

USB micro B (http://www.mouser.com/ProductDetail/FCI/10118192-0001LF/?qs=sGAEpiMZZMulM8LPOQ%252byk2%252bTbV8%2f2X5vivRX5xKgOBI%3d) (SMT, bottom mounted, receptacles)
Atmega32U4-AU (http://www.mouser.com/ProductDetail/Atmel/ATMEGA32U4-AU/?qs=sGAEpiMZZMvqv2n3s2xjsYzXfq0AWv1C4u5a33SlKLw%3d)

I'm afraid all USB micros have the same pin pitch, which is different than the one in USB minis...
I don't think USB micro can be done on this board without redesigning it.


The controller part is ok.
If the chip is indeed broken, that's weird.
Please test it for shorts with other pins, especially VCC, before desoldering.
Title: Re: Re: GH60 prototype betatesting
Post by: SmallFry on Thu, 10 January 2013, 21:33:51
Quote from: komar007 on Thu, 10 January 2013, 18:01:17

Quote from: WhiteFireDragon on Thu, 10 January 2013, 16:29:26

I'm going to change out the USB mini B connector for a micro B. I think all mico B connectors only has 2 "arms" to solder onto the PCB pads, but the PCB currently has 4. The positions might be different so it might not work. Can you verify that these parts will be ok?

USB micro B (http://www.mouser.com/ProductDetail/FCI/10118192-0001LF/?qs=sGAEpiMZZMulM8LPOQ%252byk2%252bTbV8%2f2X5vivRX5xKgOBI%3d) (SMT, bottom mounted, receptacles)
Atmega32U4-AU (http://www.mouser.com/ProductDetail/Atmel/ATMEGA32U4-AU/?qs=sGAEpiMZZMvqv2n3s2xjsYzXfq0AWv1C4u5a33SlKLw%3d)

I'm afraid all USB micros have the same pin pitch, which is different than the one in USB minis...
I don't think USB micro can be done on this board without redesigning it.

Noooooooooooo! Heh, just kidding. I don't mind, but USB micro would have been nice.
Title: Re: GH60 prototype betatesting
Post by: JBert on Fri, 11 January 2013, 02:22:12
Quote from: komar007 on Thu, 10 January 2013, 06:30:52
Quote from: JBert on Thu, 10 January 2013, 06:10:47
I wonder if there's anyone going to beta-test the ISO layout... Or will komar007 build one of each anyway?
I'll check if the switches fit where they should, but won't build one. I hate ISO:)

Never mind, Dirge has actually posted an ISO GH60 on Deskthority - http://deskthority.net/photos-videos-f8/komar-60-board-t4697.html - so it's been tested.
Title: Re: GH60 prototype betatesting
Post by: jdcarpe on Fri, 11 January 2013, 06:30:23
Yes, he did, but you wouldn't be able to find it by searching for "GH60." He never calls it by name, only "komar 60% board." I guess GH is so universally hated at DT you can't even say GH60 there.
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Fri, 11 January 2013, 10:57:06
I shipped out 5 prototype boards today. Each one takes me 2 hours to do, including programming, cleaning the flux, and testing all connection with a multimeter to make sure it all works. I flashed them with hasu's firmware, which will work for the default poker layout (didn't test function layer) so they can be used immediately.
Title: Re: GH60 prototype betatesting
Post by: komar007 on Fri, 11 January 2013, 14:58:07
I could have soldered half of those, but I was sure most people wanted them in parts, shame. I also needn't have packed the parts in separate bags.
I hope it doesn't make a problem...
Title: Re: GH60 prototype betatesting
Post by: mkawa on Sun, 13 January 2013, 07:08:23
i was going to assemble, but when i realized both of you had access to hot air i just facepalmed and had wfd do it. btw, got my board today. thanks dudes. unfortunately it's a little low on the todo right now, but i should be able to sit down and get the switches on next weekend so i can hit the codebase and start testing
Title: Re: GH60 prototype betatesting
Post by: jdcarpe on Mon, 14 January 2013, 17:15:06
Received my GH60 in the mail today and promptly assembled it.

Thoughts:

1. I need to reprogram the firmware (hasu's) that WFD loaded on it. I assembled a 1.5 mod layout, and the R_ALT key acts as R_WIN.
2. If using a 7x spacebar with Cherry stabilizers, you might want to install a stronger spring/switch for the SPACE. I used all browns, and the spacebar has a lazy reset.

Other than that, everything seems to work great. Once the rest of the beta testers assemble theirs and test them, I think we are ready to proceed with a group buy.

Great job, komar! And thanks for the SMD assembly, WFD!

(http://i.imgur.com/7VB2y.jpg)
Title: Re: GH60 prototype betatesting
Post by: __red__ on Mon, 14 January 2013, 17:37:56
Okay - so I have my keyboard.

Who has a suggested first keycap set they can recommend to me.  I want it *fast* :-)  Fast and perty.  Who / what should I buy?

Also, Pi / Prop laptop screen #1 has now been acquired: http://www.ebay.com/itm/271102649447?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1439.l2649
Title: Re: GH60 prototype betatesting
Post by: TheProfosist on Mon, 14 January 2013, 17:47:34
go wasd for caps quick and easy pertaing he has all the keycap sizes you want
Title: Re: GH60 prototype betatesting
Post by: Sai on Mon, 14 January 2013, 20:14:46
Quote from: jdcarpe on Mon, 14 January 2013, 17:15:06
Received my GH60 in the mail today and promptly assembled it.

Thoughts:

1. I need to reprogram the firmware (hasu's) that WFD loaded on it. I assembled a 1.5 mod layout, and the R_ALT key acts as R_WIN.
2. If using a 7x spacebar with Cherry stabilizers, you might want to install a stronger spring/switch for the SPACE. I used all browns, and the spacebar has a lazy reset.

Other than that, everything seems to work great. Once the rest of the beta testers assemble theirs and test them, I think we are ready to proceed with a group buy.

Great job, komar! And thanks for the SMD assembly, WFD!

Show Image
(http://i.imgur.com/7VB2y.jpg)


jdcarpe , it is so beautiful.  :'( :'( :'(
Title: Re: GH60 prototype betatesting
Post by: JPG on Mon, 14 January 2013, 20:24:24
 /drool
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Mon, 14 January 2013, 20:53:28
Quote from: jdcarpe on Mon, 14 January 2013, 17:15:06
2. If using a 7x spacebar with Cherry stabilizers, you might want to install a stronger spring/switch for the SPACE. I used all browns, and the spacebar has a lazy reset.

I'm assuming that you're describing a generic "issue" with a 7x spacebar and cherry stabilizers? It doesn't make sense for this to be specific to only this PCB unless I'm missing something here.
Title: Re: GH60 prototype betatesting
Post by: SmallFry on Mon, 14 January 2013, 21:04:02
Not gonna lie, the space bar looks giant on the small board. I like it. As for WFD's comment, I've never had an issue with my Ergo clears and Cherry Stabs, so I don't know if JDCarpe's problem is isolated or not.
Title: Re: GH60 prototype betatesting
Post by: jdcarpe on Mon, 14 January 2013, 22:51:52
Yeah, basically a generic issue, not anything specifically to do with the GH60. Except that it's the only 60% board I own with a 7x spacebar. :)

I swapped out the stem and spring for a clear and it's better now. I think many Cherry Corp boards with 7x spacebars use a stronger switch for the spacebar, probably for the same reason.
Title: Re: GH60 prototype betatesting
Post by: __red__ on Mon, 14 January 2013, 23:12:34
Non-responsive to USB.  Grrr... working it'
Title: Re: Re: GH60 prototype betatesting
Post by: dirge on Tue, 15 January 2013, 02:17:10
Quote from: jdcarpe on Fri, 11 January 2013, 06:30:23
Yes, he did, but you wouldn't be able to find it by searching for "GH60." He never calls it by name, only "komar 60% board." I guess GH is so universally hated at DT you can't even say GH60 there.
I'm just giving credit to the person who's done all the work so far.  I don't hate geekhack, but some of the people are difficult to get on with.  I don't think geekhack is universally hated at deskthority either.  I'm sure if someone posts a thread on there to offer the gh60 it would be very well received.

(original post edited due to me calming down...)
Title: Re: GH60 prototype betatesting
Post by: komar007 on Tue, 15 January 2013, 03:01:44
Great to see assembled boards!
I've been working on the programming GUI till 4 a.m. today, but the major part is done.
I've decided to go with tkinter/python. Sorry to all who think it's ugly, but this choice has the best dependencies to implementation simplicity ratio for me.
I also have a working communication library in python/pyusb which is capable of sending the layout to the keyboard in run-time.
If someone wants to play with it before I post the GUI or try to run it in windows, please send me a PM.
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Tue, 15 January 2013, 11:30:34
I don't care if it's pretty as long as it makes sense and is easy enough to use.
Title: Re: GH60 prototype betatesting
Post by: __red__ on Wed, 16 January 2013, 01:55:46
Does the ATMEGA32U come with the DFU firmware already on it like the instructions infer?

I'm unable to get the IC to enumerate as a DFU device, I get "Unknown Device" and "Device is malfunctioning".

I've gone over every single connection and discrete and even hooked up the oscillator to an oscilloscope to check that that was running and everything checks out.

Any suggestions as to where to go next?

Thanks


Red
Title: Re: GH60 prototype betatesting
Post by: hasu on Wed, 16 January 2013, 02:16:16
Did you install FLIP and its driver on the device?

I assume you are on Windows.

At first time you start DFU bootloader on Chip 'Found New Hardware Wizard' will come up on Windows.
If you install device driver properly you can find chip name like 'ATmega32U4' under 'LibUSB-Win32 Devices' tree on 'Device Manager'. If not you shall need to update its driver on 'Device Manager'.
You will find the driver in FLIP install directory like: C:\Program Files (x86)\Atmel\Flip 3.4.5\usb\
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Wed, 16 January 2013, 02:26:43
Maybe check for solder bridges behind the atmega's legs and verify everything with a DMM.

The problem that I whined about in the previous page turned out to be a solder bridge between 2 legs, which was impossible to see by eye or camera because it was behind and underneath the two legs. You can see that blown up pic that I posted earlier didn't even show that bridge, but a DMM verified that short. I just flooded that area with flux and reflow.
 
Title: Re: GH60 prototype betatesting
Post by: komar007 on Wed, 16 January 2013, 03:30:28
Quote from: __red__ on Wed, 16 January 2013, 01:55:46
Does the ATMEGA32U come with the DFU firmware already on it like the instructions infer?

I'm unable to get the IC to enumerate as a DFU device, I get "Unknown Device" and "Device is malfunctioning".

I've gone over every single connection and discrete and even hooked up the oscillator to an oscilloscope to check that that was running and everything checks out.

Any suggestions as to where to go next?

Thanks


Red
I'm sorry to read that.
I once had a similar problem, and changing the usb port helped. I don't know what's wrong with one of my usb ports, but the keyboard didn't work on one of them. Strangely, it worked fine on both in linux.

If you're on windows, check what USBlyzer has to say about it.
If you run out of ideas, try to connect to SPI with an AVR programmer if you have one (or make one, like USBasp) and try if you can communicate with the device.

Electrically, the first thing to check would be the D+ and D- resistors R1 and R2 and the crystal. Since the crystal works, check that VCC is 5V and stable.

You can also hook up stabilized 5V (without the usb connector) to VCC and GND pins under the logo. The one under "o" in ".org" is GND and the one under "pr" in "programmable" is VCC. Check that the device drives about 26.5mA.
Then, while still supplying the voltage, press the programming button. The current consumption should drop to about 10mA and then slowly rise and settle at about 16mA.
I hope that if the chip is broken we can see it by observing the currents.
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Wed, 16 January 2013, 04:43:58
^ That kind of detailed diagnostic procedure is something I would never be able to provide.
Title: Re: GH60 prototype betatesting
Post by: __red__ on Wed, 16 January 2013, 06:20:07
Quote from: WhiteFireDragon on Wed, 16 January 2013, 02:26:43
Maybe check for solder bridges behind the atmega's legs and verify everything with a DMM.

Yeah, I walked the pins in pairs (including the corners) and I have no shorts there.

Quote from: komar007 on Wed, 16 January 2013, 03:30:28
If you're on windows, check what USBlyzer has to say about it.

Connection Status: Enumeration of device failed.

IE, The negotiation hasn't even reached the point where the USBID has been declared so driver installation never happens.

Quote
If you run out of ideas, try to connect to SPI with an AVR programmer if you have one (or make one, like USBasp) and try if you can communicate with the device.

Electrically, the first thing to check would be the D+ and D- resistors R1 and R2 and the crystal. Since the crystal works, check that VCC is 5V and stable.

So, funny thing.  Looking at it in more detail the crystal appears to be providing a clean sine wave but at something like 3.2V to 3.4V peak to peak.  I'm suspicious but I don't know what the peak to peak should be and neither the ATMEGA32U or crystal datasheet give me any indication of what I should see there.

That being out of expected range would give my symptoms and I would need to suspect either the oscillator, discretes or the IC itself.

I'm ordering a fresh set of components today as measuring the RC values in circuit is obviously pointless and I don't have the patience to re-use 1c components and attempt to clean solder off the ends :-)

Quote
You can also hook up stabilized 5V (without the usb connector) to VCC and GND pins under the logo. The one under "o" in ".org" is GND and the one under "pr" in "programmable" is VCC. Check that the device drives about 26.5mA.
Then, while still supplying the voltage, press the programming button. The current consumption should drop to about 10mA and then slowly rise and settle at about 16mA.
I hope that if the chip is broken we can see it by observing the currents.

I'll try that when I get back from work this evening!

Thanks!


red
Title: Re: GH60 prototype betatesting
Post by: komar007 on Wed, 16 January 2013, 06:53:46
I forgot that you don't have the firmware on the chip, and that 26.5mA was when the firmware was working, so I think you should be getting something between 10mA to 16mA more likely.

Here's a screenshot of xtal1:
[attach=1]
Note that this is a 60MHz scope and the signal is 16MHz, so it should be a bit higher in reality.
I don't know if this helps, but maybe.

Title: Re: GH60 prototype betatesting
Post by: __red__ on Wed, 16 January 2013, 07:23:40
Yeah, I'm pretty sure my p2p range is very different which may very well point to a problem.

Is that pin 16 or pin 17 you measured that from?

Also - nice scope, what is it?

Also, I'm about to re-purchase the BoM.  Any changes from the latest in github that I need to know about?

Thanks for taking the time!

EDIT: Where did you source your ASX3F?  I'm having issues finding a supplier.



Red
Title: Re: GH60 prototype betatesting
Post by: komar007 on Wed, 16 January 2013, 08:41:27
Quote from: __red__ on Wed, 16 January 2013, 07:23:40
Yeah, I'm pretty sure my p2p range is very different which may very well point to a problem.

Is that pin 16 or pin 17 you measured that from?
It's pin 17. Pin 16 looks similar, but p2p is a bit smaller.

Quote from: __red__ on Wed, 16 January 2013, 07:23:40
Also - nice scope, what is it?
Voltcraft DSO-3062C (aka Hantek DSO5062M, Tekway DST1062B)

Quote from: __red__ on Wed, 16 January 2013, 07:23:40
Also, I'm about to re-purchase the BoM.  Any changes from the latest in github that I need to know about?

Thanks for taking the time!
I've just pushed, but what was before seems correct.

Quote from: __red__ on Wed, 16 January 2013, 07:23:40
EDIT: Where did you source your ASX3F?  I'm having issues finding a supplier.
Unfortunately in a local shop.
Please try to find anything of similar size and footprint.
I'm attaching the datasheet: [attachurl=1].


EDIT: I think these (http://www.digikey.com/scripts/dksearch/dksus.dll?FV=fff4000d%2Cfff8016d&k=16MHz&vendor=0&mnonly=0&newproducts=0&ptm=0&fid=0&quantity=0&PV46=13601) should be fine.
Title: Re: GH60 prototype betatesting
Post by: SmallFry on Wed, 16 January 2013, 09:55:30
You never stated if you got FLIP and drivers installed, but I would assume you have from the steps you've taken already Red.
Title: Re: GH60 prototype betatesting
Post by: komar007 on Wed, 16 January 2013, 10:06:48
Quote from: SmallFry on Wed, 16 January 2013, 09:55:30
You never stated if you got FLIP and drivers installed, but I would assume you have from the steps you've taken already Red.
It shouldn't really matter, the device doesn't enumerate at all:(
Title: Re: Re: GH60 prototype betatesting
Post by: SmallFry on Wed, 16 January 2013, 10:08:21
Quote from: komar007 on Wed, 16 January 2013, 10:06:48
Quote from: SmallFry on Wed, 16 January 2013, 09:55:30
You never stated if you got FLIP and drivers installed, but I would assume you have from the steps you've taken already Red.
It shouldn't really matter, the device doesn't enumerate at all:(
Oh...whoops. That's a shame...:(
Title: Re: GH60 prototype betatesting
Post by: __red__ on Wed, 16 January 2013, 14:36:31
Some laser-porn...  Prototyping in plywood as it smells like campfires instead of ass:

Title: Re: GH60 prototype betatesting
Post by: Glod on Wed, 16 January 2013, 14:54:25
Quote from: __red__ on Wed, 16 January 2013, 14:36:31
Some laser-porn...  Prototyping in plywood as it smells like campfires instead of ass:

Awesome!
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Wed, 16 January 2013, 15:14:07
I recorded two separate prototype soldering, one with hot air only and with iron only.





Title: Re: GH60 prototype betatesting
Post by: alaricljs on Wed, 16 January 2013, 15:22:54
Quote from: __red__ on Wed, 16 January 2013, 14:36:31
Some laser-porn...  Prototyping in plywood as it smells like campfires instead of ass:

So is that a weird camera angle or is your gantry aligned to a vertical plane?
Title: Re: GH60 prototype betatesting
Post by: __red__ on Wed, 16 January 2013, 15:25:59
Weird camera angle.  The camera also appears to be upside down.  Reason for that is that we try to avoid being in front of the laser while it's cutting plywood or MDF since the light is as bright as an arc.

Sure, the polycarbonate screen filters out the laser, but watching it cut or the light reflected from it tires the eyes so we choose not to risk it.
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Wed, 16 January 2013, 15:32:47
_red_,  you're mounting your prototype board on that "plate" made of wood? Post back how the sound and bottom-out feel compared to a steel plate.
Title: Re: GH60 prototype betatesting
Post by: Glod on Wed, 16 January 2013, 15:42:09
Quote from: WhiteFireDragon on Wed, 16 January 2013, 15:14:07
I recorded two separate prototype soldering, one with hot air only and with iron only.

watching your video(s) right now while i'm working :)
Title: Re: GH60 prototype betatesting
Post by: JPG on Wed, 16 January 2013, 15:43:41
Quote from: Glod on Wed, 16 January 2013, 15:42:09
Quote from: WhiteFireDragon on Wed, 16 January 2013, 15:14:07
I recorded two separate prototype soldering, one with hot air only and with iron only.

watching your video(s) right now while i'm working :)

Same here, but more like fast forward style  ;D
Title: Re: GH60 prototype betatesting
Post by: __red__ on Wed, 16 January 2013, 20:08:38
So,
My oscilloscope shows me that my crystal is oscillating at 50khz as well as 16mhz.  The amplitude of the 50khz is greater than the other by quite a margin.

That's bad.

Also, I borrowed a logic analyzer with built-in protocol decoder and the host attempts to sync but the atmega never responds.

Replacement discretes should arrive tomorrow.  Will post again when I'm working.
Title: Re: GH60 prototype betatesting
Post by: mkawa on Wed, 16 January 2013, 22:22:43
damnit i want a laser-cutter :(
Title: Re: GH60 prototype betatesting
Post by: komar007 on Thu, 17 January 2013, 12:49:52
A little teaser of the GUI:
[attach=1]
Title: GH60 prototype betatesting
Post by: jdcarpe on Thu, 17 January 2013, 12:55:04
Loving it!
Title: Re: GH60 prototype betatesting
Post by: modulor on Thu, 17 January 2013, 15:57:48
Quote from: komar007 on Thu, 17 January 2013, 12:49:52
A little teaser of the GUI:
(Attachment Link)
+1 ;D
Title: Re: GH60 prototype betatesting
Post by: TheProfosist on Thu, 17 January 2013, 16:19:35
komar are you using hasu's firmware?
Title: Re: GH60 prototype betatesting
Post by: komar007 on Thu, 17 January 2013, 16:20:44
No, I have my own.
Title: Re: GH60 prototype betatesting
Post by: TheProfosist on Thu, 17 January 2013, 16:28:03
Quote from: komar007 on Thu, 17 January 2013, 16:20:44
No, I have my own.
does it support all the same stuff that hasu's does other wise it the best option would probably be modifying his
Title: Re: GH60 prototype betatesting
Post by: komar007 on Thu, 17 January 2013, 16:30:49
What does hasu's firmware support?
I don't know much about it.


BTW I don't think we need one "official" firmware. The more the merrier;)
Title: Re: GH60 prototype betatesting
Post by: TheProfosist on Thu, 17 January 2013, 16:35:42
Quote from: komar007 on Thu, 17 January 2013, 16:30:49
What does hasu's firmware support?
I don't know much about it.


BTW I don't think we need one "official" firmware. The more the merrier;)
suports media keys, mouse buttons, NKRO, multiple layer both toggle and non
Title: Re: GH60 prototype betatesting
Post by: komar007 on Thu, 17 January 2013, 16:37:45
I don't have media keys and mouse buttons yet, but I was planning on doing it anyway.
Mine supports uploading new layout in less than a second, directly from the GUI;)
Title: Re: GH60 prototype betatesting
Post by: mkawa on Thu, 17 January 2013, 17:20:41
Quote from: komar007 on Thu, 17 January 2013, 12:49:52
A little teaser of the GUI:
(Attachment Link)
thumbs up!!!
Title: GH60 prototype betatesting
Post by: Batmann on Thu, 17 January 2013, 17:34:54
There are some highly skilled people here, this is very inspiring
Keep it up komar! :)
Title: Re: GH60 prototype betatesting
Post by: regack on Thu, 17 January 2013, 17:58:15
Quote from: komar007 on Thu, 17 January 2013, 16:30:49

BTW I don't think we need one "official" firmware. The more the merrier;)

Yes, indeed, the more the merrier!
Title: Re: GH60 prototype betatesting
Post by: TheProfosist on Thu, 17 January 2013, 19:01:39
Quote from: komar007 on Thu, 17 January 2013, 16:37:45
I don't have media keys and mouse buttons yet, but I was planning on doing it anyway.
Mine supports uploading new layout in less than a second, directly from the GUI;)
yea just though you could focus on the GUI if you used a firmware thats already been developed
Title: Re: GH60 prototype betatesting
Post by: JPG on Thu, 17 January 2013, 19:26:45
Quote from: komar007 on Thu, 17 January 2013, 12:49:52
A little teaser of the GUI:
(Attachment Link)

Got teased here  :D

I also have 2 questions:

1. Will it be possible to, for exemple, press the capslock to go to a specific layer on the first press, stay on that layer, and come back to the original layer on the second capslock keypress?

2. What do you use for coding language? Will you share the code or make it open source or something like that at some point?

Thx a lot for doing this by the way!!!
Title: Re: GH60 prototype betatesting
Post by: TheProfosist on Thu, 17 January 2013, 19:34:56
Quote from: JPG on Thu, 17 January 2013, 19:26:45
Quote from: komar007 on Thu, 17 January 2013, 12:49:52
A little teaser of the GUI:
(Attachment Link)

Got teased here  :D

I also have 2 questions:

1. Will it be possible to, for exemple, press the capslock to go to a specific layer on the first press, stay on that layer, and come back to the original layer on the second capslock keypress?

2. What do you use for coding language? Will you share the code or make it open source or something like that at some point?

Thx a lot for doing this by the way!!!
so far everyone that has programmed for that teensy or that chip at least in our community has shared their code I dont know where exactly it is though...
Title: Re: GH60 prototype betatesting
Post by: alaricljs on Thu, 17 January 2013, 20:13:53
Not everyone... Soarer's converter is still closed, and I think there may be a couple others that have very limited exposure that have also chosen not to release.  Several people host on github tho.
Title: Re: GH60 prototype betatesting
Post by: JPG on Thu, 17 January 2013, 20:35:20
It's ok if he prefer to keep it for himself, I understand it perfectly, but if he does make it public I would be interested to look at it (and maybe add some features  :D)
Title: Re: GH60 prototype betatesting
Post by: __red__ on Thu, 17 January 2013, 23:17:07
Quote from: __red__ on Wed, 16 January 2013, 20:08:38
So,
My oscilloscope shows me that my crystal is oscillating at 50khz as well as 16mhz.  The amplitude of the 50khz is greater than the other by quite a margin.

That's bad.

Also, I borrowed a logic analyzer with built-in protocol decoder and the host attempts to sync but the atmega never responds.

Replacement discretes should arrive tomorrow.  Will post again when I'm working.

I replaced C1, C2, C3, C7, R5 and the Crystal.  It immediately fired up.  I was able to type a few characters so the firmware is cool too.

My 17" LCD for my Propeller Pi laptop is on its way.  Once that's measured and a frame built for it I can then find a small, maybe 7" VGA or Composite Video LCD for the propeller.  Then I can machine and build the frame to support the keyboard.

I'm stoked!
Title: Re: GH60 prototype betatesting
Post by: alaricljs on Thu, 17 January 2013, 23:22:02
Damn those flaky flux capacitors.  Glad you are once again in control of the flow of time.  ;)
Title: Re: GH60 prototype betatesting
Post by: komar007 on Fri, 18 January 2013, 01:07:01
Quote from: JPG on Thu, 17 January 2013, 19:26:45

1. Will it be possible to, for exemple, press the capslock to go to a specific layer on the first press, stay on that layer, and come back to the original layer on the second capslock keypress?
Yes
Quote from: JPG on Thu, 17 January 2013, 19:26:45
2. What do you use for coding language? Will you share the code or make it open source or something like that at some point?

Thx a lot for doing this by the way!!!
Coded in C. Most probably yes.


Quote from: __red__ on Thu, 17 January 2013, 23:17:07

I replaced C1, C2, C3, C7, R5 and the Crystal.  It immediately fired up.  I was able to type a few characters so the firmware is cool too.

My 17" LCD for my Propeller Pi laptop is on its way.  Once that's measured and a frame built for it I can then find a small, maybe 7" VGA or Composite Video LCD for the propeller.  Then I can machine and build the frame to support the keyboard.

I'm stoked!

Great!
I wonder what was wrong... We'll never know most probably.
Title: Re: GH60 prototype betatesting
Post by: __red__ on Fri, 18 January 2013, 05:51:47
If i were a betting man, I'd guess wrong values of capacitors across the crystal or a dud crystal.

My human error is more likely than a crystal failing qa imho.


Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Fri, 18 January 2013, 18:26:35
Another batch of prototype boards when out yesterday. I'm down to the last few before I build mine, after that the real testing can begin for me.


Quote from: __red__ on Fri, 18 January 2013, 05:51:47
If i were a betting man, I'd guess wrong values of capacitors across the crystal or a dud crystal.

My human error is more likely than a crystal failing qa imho.

If it was indeed it was a defective crystal, I'm just glad that one defective part whet to you haha. If it was one of the 12 that I had to solder, I wouldn't have known what to do. At least you have an oscilloscope to test it. I only have a DMM. I'm glad you got it all figured out.
Title: Re: GH60 prototype betatesting
Post by: TheProfosist on Fri, 18 January 2013, 19:39:05
Quote from: WhiteFireDragon on Fri, 18 January 2013, 18:26:35
Another batch of prototype boards when out yesterday. I'm down to the last few before I build mine, after that the real testing can begin for me.


Quote from: __red__ on Fri, 18 January 2013, 05:51:47
If i were a betting man, I'd guess wrong values of capacitors across the crystal or a dud crystal.

My human error is more likely than a crystal failing qa imho.

If it was indeed it was a defective crystal, I'm just glad that one defective part whet to you haha. If it was one of the 12 that I had to solder, I wouldn't have known what to do. At least you have an oscilloscope to test it. I only have a DMM. I'm glad you got it all figured out.
i dont think i paid for mine yet... could you send me an invoice?
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Sat, 19 January 2013, 13:10:40
New switch hole design:

(http://img.photobucket.com/albums/v288/WhiteFireDragon/keyboard/plates/th_switchholedesign3D.png) (http://smg.photobucket.com/albums/v288/WhiteFireDragon/keyboard/plates/?action=view&current=switchholedesign3D.png)  (http://img.photobucket.com/albums/v288/WhiteFireDragon/keyboard/plates/th_switchholedesign.png) (http://img.photobucket.com/albums/v288/WhiteFireDragon/keyboard/plates/switchholedesign.png) 

#2 - this is the design I have on the new phantom plates and the the TKL plates GB I ran.
#3 - some switches on this PCB needs to be rotated 90, so this is just basically a 90 rotation of #2
#1 - a more crazy design that can be put on every switch that allows rotation in any direction


All these are designed to allow opening of the switches without desoldering. Most switches on the GH60 only needs #2, and some needs it to be rotated like #3. If all the switch holes were to be uniform, then #1 design allows any mounting orientation. This would be good for future PCBs to be designed without needing a specific plate to tailor to the specific PCB. If quotes are not much more for the extra details of the #1 design, then probably that design would be best. Comments/opinions before I start drawing up the different layouts?
Title: Re: GH60 prototype betatesting
Post by: jdcarpe on Sat, 19 January 2013, 13:22:51
I like #1, for reasons you already know. :)
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Sat, 19 January 2013, 13:35:00
Have any one else consider underplate? I make some G80 mod like this with MY switch plate. Only need cut to dimension along with thin rubber mat and a few holes to allow the mounting bolts to pass through. Would give it a more sturdy feeling removing flex when use stock plastic case but without taking away from the other pros of pcb mount feel. Only would need one design too, very easy.
Title: Re: GH60 prototype betatesting
Post by: relcc on Sun, 20 January 2013, 01:23:06
#1 would't work because the clip that keeps the switch in place is exactly where the rotated gaps are.

#2 and #3 give the switch less grip than holes with 2 gaps on each side.

I would recommend conventional holes with the conventional mod for top removal.

The ideal situation would also be where the plate is connected to the case, and not the PCB. That means small holes for the screws, not holes to reach for the screws that are actually on the pcb. For this board however that would probably not be feasible.
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Sun, 20 January 2013, 17:50:33
#2 and #3 have all 4 corners and the whole top and bottom to lock in the switch. It's not moving anywhere. These can only be mounted in 2 directions though. I have 40 TKL plates with this design.

#1 would work. It's an overlay of #2 and #3, and I specified the middle tabs to be just long enough so top and bottom of the switch can lock no matter what orientation you mount it. All 4 corners also hold the from any movement.


I'm not sure you fully understand how those hole cutouts work. What exactly do you have in mind for "conventional" holes?
Title: Re: GH60 prototype betatesting
Post by: TheProfosist on Sun, 20 January 2013, 18:01:45
1 should work..
Title: Re: GH60 prototype betatesting
Post by: relcc on Sun, 20 January 2013, 19:55:40
It's a trade-off between a situation where the key barely locks and is barely prevented from moving on one hand, and where the key is firmly locked into place with maximum support on all sides. If the lasercutting (or worse cnc) screws up a corner, the key is only supported by pcb and the plate is (for that key) useless. If you're using pcb mount keys you have some slack, but plate mounted keys leave no room for error.

Maybe you should run a prototype.
Title: Re: GH60 prototype betatesting
Post by: regack on Sun, 20 January 2013, 20:26:23
I like #1 - Even if the key doesn't lock into the plate, size it correctly and there will be enough friction to keep it in there very tightly. 
Title: Re: GH60 prototype betatesting
Post by: hasu on Sun, 20 January 2013, 20:49:31
With tinkering with The_Beast's Poker Plate with MX I found MX has different width at its corner.
My cheap caliper says horizontal width is 13.80mm while 12.95mm at vertical.
This difference causes kind of wiggle when you place MX at 90deg or 270deg rotation in Poker Plate. Unfortunately Poker Plate has a bit too short width of middle tabs to hold at firm part of bottom case not only at lock spring.
Not to mention, Poker Plate works well with proper rotation of switch. This is not a complain about Poker Plate.

Though 4 corners of #1 is not enough to hold firmly, with proper middle tabs #1 would work.


Quote from: WhiteFireDragon on Sun, 20 January 2013, 17:50:33
#2 and #3 have all 4 corners and the whole top and bottom to lock in the switch. It's not moving anywhere. These can only be mounted in 2 directions though. I have 40 TKL plates with this design.

#1 would work. It's an overlay of #2 and #3, and I specified the middle tabs to be just long enough so top and bottom of the switch can lock no matter what orientation you mount it. All 4 corners also hold the from any movement.


I'm not sure you fully understand how those hole cutouts work. What exactly do you have in mind for "conventional" holes?
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Mon, 21 January 2013, 00:31:07
Quote from: hasu on Sun, 20 January 2013, 20:49:31
With tinkering with The_Beast's Poker Plate with MX I found MX has different width at its corner.
My cheap caliper says horizontal width is 13.80mm while 12.95mm at vertical.
This difference causes kind of wiggle when you place MX at 90deg or 270deg rotation in Poker Plate. Unfortunately Poker Plate has a bit too short width of middle tabs to hold at firm part of bottom case not only at lock spring.
Not to mention, Poker Plate works well with proper rotation of switch. This is not a complain about Poker Plate.

I know exactly where you measured it, and those are the wrong places. Move it up a tad. My digital caliper says 13.97mm, which is pretty much spot on with cherry's specs of 14.0mm at those areas. Also, according to the cherry's dimensions, the switch is a perfect square at the areas held in by the plate. Each side of the hole is 0.55" (14mm).

The poker plate you played around with have the exact same switch cutouts as the original phantom. You can rotate the switch 90° and it will still hold it in place fine, but you'll lose option to open up the switch. If you fully mount it where it locks down, it's sturdy and won't move. Here you can see the plate cutout that cherry specified, which is how the phantom switch and stabilizer holes were derived:

http://www.cherrycorp.com/english/switches/key/mx.htm (http://www.cherrycorp.com/english/switches/key/mx.htm)
http://www.cherrycorp.com/english/switches/pdf/mx_cat.pdf (http://www.cherrycorp.com/english/switches/pdf/mx_cat.pdf)
(http://img.photobucket.com/albums/v288/WhiteFireDragon/keyboard/plates/th_switchdimensions.png) (http://img.photobucket.com/albums/v288/WhiteFireDragon/keyboard/plates/switchdimensions.png)
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Mon, 21 January 2013, 00:33:52
Quote from: regack on Sun, 20 January 2013, 20:26:23
I like #1 - Even if the key doesn't lock into the plate, size it correctly and there will be enough friction to keep it in there very tightly.
Quote from: relcc on Sun, 20 January 2013, 19:55:40
It's a trade-off between a situation where the key barely locks and is barely prevented from moving on one hand, and where the key is firmly locked into place with maximum support on all sides. If the lasercutting (or worse cnc) screws up a corner, the key is only supported by pcb and the plate is (for that key) useless. If you're using pcb mount keys you have some slack, but plate mounted keys leave no room for error.

Maybe you should run a prototype.

I've looked at both laser cutting and waterjet to cut the holes. Water jet won't be able to do fine details, but laser cutting has good enough tolerances to cut the plates. The 4 corners as well as the 4 center tabs are actually touching the switch to hold it in place.

I've already prototyped and made a stack of TKL plates with hole design #2/3. I'll promise you #1 hole design will be fine :) . It's not really a question of whether it will work or not, but which design is preferred for these new plates.

(http://img.photobucket.com/albums/v288/WhiteFireDragon/keyboard/plates/th_universalTKLcropped.jpg) (http://img.photobucket.com/albums/v288/WhiteFireDragon/keyboard/plates/universalTKLcropped.jpg)
Title: Re: GH60 prototype betatesting
Post by: kmiller8 on Mon, 21 January 2013, 00:35:54
Quote from: hasu on Sun, 20 January 2013, 20:49:31
With tinkering with The_Beast's Poker Plate with MX I found MX has different width at its corner.
My cheap caliper says horizontal width is 13.80mm while 12.95mm at vertical.
This difference causes kind of wiggle when you place MX at 90deg or 270deg rotation in Poker Plate. Unfortunately Poker Plate has a bit too short width of middle tabs to hold at firm part of bottom case not only at lock spring.
Not to mention, Poker Plate works well with proper rotation of switch. This is not a complain about Poker Plate.

Though 4 corners of #1 is not enough to hold firmly, with proper middle tabs #1 would work.

hasu, I think you were measuring at the wrong point, with my cheap calipers I got 13.57mm x 13.70mm :x

On the sides of the housing with clips
(http://i.imgur.com/L6HlB2fm.jpg) (http://imgur.com/L6HlB2f.jpg)

On the sides without the clips
(http://i.imgur.com/K66Htf3m.jpg) (http://imgur.com/K66Htf3.jpg)

I also replicated your result of 12.70mm

On the side without the clips, measured at a different point
(http://i.imgur.com/xMmKeMnm.jpg) (http://imgur.com/xMmKeMn.jpg)

The 12.70mm is measured from the "bottom" of the switch, while the 13.70 is measured from where the plate comes in contact with the housing, as shown below.

Where I measured 13.70mm
(http://i.imgur.com/c5P2MKHm.jpg) (http://imgur.com/c5P2MKH.jpg)

As long as you make that middle portion on #1 around 6.48mm, it should be able to both hold the switch in the vertical and the horizontal :)

The length of the 13.70mm portion of the switch, that won't interfere with the clips on the housing
(http://i.imgur.com/bHs9i3dm.jpg) (http://imgur.com/bHs9i3d.jpg)
Title: Re: GH60 prototype betatesting
Post by: daerid on Mon, 21 January 2013, 01:32:16
Is there an official GB thread for this?
Title: Re: GH60 prototype betatesting
Post by: TheProfosist on Mon, 21 January 2013, 01:56:10
Quote from: daerid on Mon, 21 January 2013, 01:32:16
Is there an official GB thread for this?
no yeat the board is still in betatesting
Title: Re: GH60 prototype betatesting
Post by: hasu on Mon, 21 January 2013, 03:53:43
My point is that four corners doesn't touch switch case perfectly and we need proper middle tabs to get better support for switch in #1 design.
You'll see small gap at bottom corner and switch case in photos below. On left side large gap is by design, of course.
On the other hand this gap is never problem in #2, #3 and Poker plate with normal rotation switch.

Left bottom corner of switch with normal rotation.
(http://i.imgur.com/cpNsrXim.jpg) (http://i.imgur.com/cpNsrXi.jpg)

with 90deg rotation. Poker Plate's tab is a bit short and can't support rotated switch firmly.
(http://i.imgur.com/2wxckbem.jpg) (http://i.imgur.com/2wxckbe.jpg)

Normal and rotated mount side by side.
(http://i.imgur.com/kRwBhBzm.jpg) (http://i.imgur.com/kRwBhBz.jpg)

[EDIT] replaced photos with a bit better one and added some photos below.

Note that corners can't hold switch sturdily in #1 design as this photo indicates.
Never mind if you already found this yourself. I just wanted to let you guys know this.

This short tab holds switch only at part of plate lock spring. This causes horizontal wiggle.
If it is a bit longer it will hold sturdily at firm part of switch case.
(http://i.imgur.com/vHWV6Pim.jpg) (http://i.imgur.com/vHWV6Pi.jpg)

I think we can have a bit longer tab than Poker Plate without interfering switch open.
(http://i.imgur.com/BCfdkAym.jpg) (http://i.imgur.com/BCfdkAy.jpg)
(http://i.imgur.com/w0KVCl4m.jpg) (http://i.imgur.com/w0KVCl4.jpg)
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Mon, 21 January 2013, 22:41:25
You’re basing all your fittings and pictures on the poker/phantom plate design. But you can’t really make the assumption that these new hole design is exactly the same as the poker/phantom plate, which they’re not. The corner notches on my design is actually a tad bigger, combined with the whole top and bottom edges, that side flap was not needed. Refer to THIS (http://geekhack.org/index.php?topic=36907.msg698752#msg698752) post.

(http://img.photobucket.com/albums/v288/WhiteFireDragon/keyboard/plates/th_IMG_2388.jpg) (http://smg.photobucket.com/albums/v288/WhiteFireDragon/keyboard/plates/?action=view&current=IMG_2388.jpg) (http://img.photobucket.com/albums/v288/WhiteFireDragon/keyboard/plates/th_IMG_2386.jpg) (http://smg.photobucket.com/albums/v288/WhiteFireDragon/keyboard/plates/?action=view&current=IMG_2386.jpg)


The switch holes here are the holes from Figure A. Those corners are as long as possible. If they’re any longer, you won’t be able to open the switch. I do know what you mean by that extra tiny gap next to the corner though, but that gap doesn’t affect anything. The corner alone holds the switches firmly, but the two top and bottom sides also add support. The switch can’t be moved at all. This obviously won’t work if you rotate the switch 90degrees, because that plastic lock spring has nothing to clamp on, and the switch tabs can’t be opened. This is why Fig. B is necessary for a rotated switch, which is basically Fig. A, just rotated 90degrees.

(http://img.photobucket.com/albums/v288/WhiteFireDragon/keyboard/plates/th_switchholesedited.png) (http://smg.photobucket.com/albums/v288/WhiteFireDragon/keyboard/plates/?action=view&current=switchholesedited.png)

Now if you look at Fig. C, it's just an overlap of A and B, and that's why I know the final design will work. The corners as well as the solid blue line at the center of each side hold the switch in place. That solid blue line is actually touching the switch to clamp it down, and it's just long enough to still allow you to open up the switch tabs. If you darkened all the important lines and got rid of all the reference lines from Fig C, then you get Figure D, which is the final design of the switch hole that will allow: 1) any rotation orientation of the switch, 2) opening of the switch, and 3) clamp the switch in place and for the top/bottom plastic clips to lock.


Man this is pretty hard to explain and to point out which parts I'm referring to, but hopefully it's coherent. lol does anyone actually understand me?
Title: Re: GH60 prototype betatesting
Post by: alaricljs on Mon, 21 January 2013, 22:50:20
I do, but that doesn't count... :)
Title: Re: GH60 prototype betatesting
Post by: hasu on Tue, 22 January 2013, 00:37:31
I didn't say your design won't work and I think I understand your design intention.

In design D four corner notches can hold right/left side of switch but not top/bottom side,
so tabs are important in this design, right?
BTW, Poker plate seems to has same size notches as yours in the photo.

My concern is only width of four middle tabs. I found shorter width tab won't hold switch firmly, because it touch only at plastic clip part.

I think middle tab should be long enough to reach solid part of switch case. maybe 6.00mm or so? as far as it doesn't interfere opening switch.
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Tue, 22 January 2013, 01:46:11
Yeah, those tabs in the middle of every side is absolutely necessary in the design so that the two plastic locking clips have something to clamp on. I specified the width of those tabs to be 5.10mm. You really only need 4.25mm for them to properly work. I took tolerance into account, so 6.00mm is probably too close to the switch clips that allow opening of the switches, 5.10mm is a good intermediate.

Anyways, I'll stop ranting about this. I'll move this discussion to the main thread if there is anything else to say since this thread is specifically for actual testing of prototypes.
Title: Re: GH60 prototype betatesting
Post by: hasu on Tue, 22 January 2013, 02:43:18
I'll also stop posting about this :) Sorry for derail, guys.

Hmm, looks like I couldn't convey what I want to say. Or I'm completely confusing about this.
5.10mm is almost same as Poker's size.
I still think switch will wiggle along top/bottom direction with that width tab.
Title: Re: GH60 prototype betatesting
Post by: The_Beast on Tue, 22 January 2013, 14:16:27
Can someone give me the exact size of the PCB (L x W x H) and where the center of the USB port is?
Title: Re: GH60 prototype betatesting
Post by: komar007 on Tue, 22 January 2013, 14:20:22
285mm x 94mm, USB port's center is 17.57mm from the left.

The vertical dimension may change slightly, because the stabilizer holes are too close to the edges now.
Title: Re: GH60 prototype betatesting
Post by: The_Beast on Tue, 22 January 2013, 14:21:59
Quote from: komar007 on Tue, 22 January 2013, 14:20:22
285mm x 94mm, USB port's center is 17.57mm from the left.

Thanks, how thick is the PCB and how thick is the PCB w/ the USB?
Title: Re: GH60 prototype betatesting
Post by: Acetrak on Tue, 22 January 2013, 14:22:09
^^Quick and precise, I like it :D
Title: Re: GH60 prototype betatesting
Post by: komar007 on Tue, 22 January 2013, 14:26:24
Quote from: The_Beast on Tue, 22 January 2013, 14:21:59
Thanks, how thick is the PCB and how thick is the PCB w/ the USB?

Standard FR4 1.6mm, 5.6mm with USB. The connector is subject to change, because it is not available in China + we may switch to micro.
Anyway, it will rather get smaller than larger.
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Tue, 22 January 2013, 14:51:47
komar, a few things to consider changing in the final production board. I know I just designed a switch hole to accommodate switch rotation, but keycaps cannot be rotated. The "+" shape from the switch stems don't have the same thickness. The vertical part is thinner than the horizontal part. If you try to install keycaps, it's very stiff, although you can still force it on. However, once you do this, you'll loosen the female part of the keycap stem. If you install these keycaps on other switches, it might be too loose. This won't be a problem if you buy a set specifically for this keyboard, but if you transfer keycap sets between keyboards a lot, you'll have a few ruined caps.

Now it's a question of whether you value you keycaps more or want more layout options for the PCB.

(http://img.photobucket.com/albums/v288/WhiteFireDragon/keyboard/th_stemwidth.jpg) (http://smg.photobucket.com/albums/v288/WhiteFireDragon/keyboard/?action=view&current=stemwidth.jpg)



For the USB, it shouldn't be too hard to change 5 pads for the pins and the 4 large pads for micro USB support.
Title: Re: GH60 prototype betatesting
Post by: The_Beast on Tue, 22 January 2013, 14:55:42
What caps have to be rotated for what layouts?
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Tue, 22 January 2013, 14:58:01
Almost every key that is not 1x size, and a few of the 1x keys too.
Title: Re: GH60 prototype betatesting
Post by: The_Beast on Tue, 22 January 2013, 15:01:53
well that sucks giant dongs
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Tue, 22 January 2013, 15:38:39
It's not really an issue with keycaps. It dosen't make them so loose they will fall off by themselves if you turn the board upside down, or at least i never had that problem and I have had some boards with 90 rotated switch. The wider crossbar is the important one and that is not the one that will get looser.
If you remove all the rotated switches you end up with many layout not possible anymore.
It might be a consideration to some, but redesign the whole thing and lose layout choice is too drastic for the sake of keycap might get a little looser fit.
Title: Re: GH60 prototype betatesting
Post by: komar007 on Tue, 22 January 2013, 15:41:45
Yes, I'm starting to see this is a bigger problem.
The only thing is when we put a few switch footprints near each other, we loose PCB mounting support.
Maybe we can fix that by adding two pads where the diode normally goes and have the user put a wire there to mount the switch more firmly.
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Tue, 22 January 2013, 15:52:19
Some overlap location is possible but some are not because then you can't even mount the switches properly. Personally, I'd rather keep all the layout possibilities and sacrifice the caps. Those loose caps won't totally but useless, it'll still mount without falling off although it'll just be looser. It might be a problem for people using rare vintage sets or expensive sets, or for resale value. SP sets are known to have loose modifier to begin with, so all the bottom modifiers have rotated switches so that'll make it worst.

Workaround is to just put a thin piece of tape in the female stem of the caps, although that's not as elegant. Personally I don't care for this "problem", but just pointing this out to be considered in case you decide to change anything.
Title: Re: GH60 prototype betatesting
Post by: komar007 on Tue, 22 January 2013, 16:00:13
Well, I don't know. Seems to be the next thing to make a poll for. The first one would be the mini vs micro usb.
Title: Re: GH60 prototype betatesting
Post by: TheSoulhunter on Tue, 22 January 2013, 16:21:41
Humm, I'm strongly against the rotated switches...
To me such "workarounds" are against "an engineers pride" n producing a quality product, if that makes sense.
But then again, I'm from Germany and my profession is to build high speed trains, so my thinking might be biased :D
Title: Re: GH60 prototype betatesting
Post by: The_Beast on Tue, 22 January 2013, 16:28:25
Quote from: TheSoulhunter on Tue, 22 January 2013, 16:21:41
Humm, I'm strongly against the rotated switches...
To me such "workarounds" are against "an engineers pride" n producing a quality product, if that makes sense.
But then again, I'm from Germany and my profession is to build high speed trains, so my thinking might be biased :D

I feel kinda the same way
Title: Re: GH60 prototype betatesting
Post by: komar007 on Tue, 22 January 2013, 16:34:24
Quote from: TheSoulhunter on Tue, 22 January 2013, 16:21:41
Humm, I'm strongly against the rotated switches...
To me such "workarounds" are against "an engineers pride" n producing a quality product, if that makes sense.
But then again, I'm from Germany and my profession is to build high speed trains, so my thinking might be biased :D
Well this is a decision to be made between rotated switches and overlapping drill holes, which means soldering to an incomplete, not fully metalized pad.
The question remains: what is worse, rotated switches and tight keycaps or less durable, harder to solder joints + lack of one PCB support pin on most switches.
I honestly don't know...
Title: Re: GH60 prototype betatesting
Post by: alaricljs on Tue, 22 January 2013, 16:45:54
Kind of boils down to how many people are wanting to use this without a plate.
Title: GH60 prototype betatesting
Post by: jdcarpe on Tue, 22 January 2013, 16:52:19
Quote from: alaricljs on Tue, 22 January 2013, 16:45:54
Kind of boils down to how many people are wanting to use this without a plate.

I personally won't be using it without a plate. The PCB seems a bit flimsier than the Poker PCB and has quite a bit more flex, even with just normal use.

Unless we choose a beefier PCB, anyway.

Also, I am in the process of plate mounting all my Pokers, if that gives any indication if how I feel about it. :)
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Tue, 22 January 2013, 17:01:59
I don't like plates, but if it is decided to go with redesign so plate required, I can just be happy with my prototype and not get anymore.
Title: Re: GH60 prototype betatesting
Post by: TheSoulhunter on Tue, 22 January 2013, 17:26:57
Quote from: komar007 on Tue, 22 January 2013, 16:34:24
Quote from: TheSoulhunter on Tue, 22 January 2013, 16:21:41
Humm, I'm strongly against the rotated switches...
To me such "workarounds" are against "an engineers pride" n producing a quality product, if that makes sense.
But then again, I'm from Germany and my profession is to build high speed trains, so my thinking might be biased :D
Well this is a decision to be made between rotated switches and overlapping drill holes, which means soldering to an incomplete, not fully metalized pad.
The question remains: what is worse, rotated switches and tight keycaps or less durable, harder to solder joints + lack of one PCB support pin on most switches.
I honestly don't know...

Option 3, no compromises in quality but less possible layouts!? :D
But yeah, we should have a poll...
Title: Re: GH60 prototype betatesting
Post by: relcc on Tue, 22 January 2013, 17:34:53
I would also go for plate mount. Personally I think trying to get a 'PCB mount multi-use board' is madness. Turning the switches 'the right way' would also solve the discussion in the other thread about rotated multi-use holes in the plate which may or may not work. And the stabilizer holes that do not fit the PCB size currently is also solved as stabilizers are mounted one the plate.

Another thing you would get; the possibility of running traces on the PCB for LEDs as switches can be mounted with LEDs again. I'm not a LED-person myselve, unless someone designs a board with per key programmable LEDs.
Title: Re: GH60 prototype betatesting
Post by: komar007 on Tue, 22 January 2013, 17:46:33
Let's get one thing straight: rotating the switches back to normal positions will not prevent plateless design. If we decide to do so, it's only a matter of the lack of one pin, which isn't such a big deal, and I'm going to add pads which will allow to mount the switch firmly with a piece of wire.
It's only that more pads will be incomplete and the joints may be more likely to break.
Title: Re: GH60 prototype betatesting
Post by: relcc on Tue, 22 January 2013, 18:06:02
Maybe you can use thicker copper on the PCB to prevent breaking.
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Tue, 22 January 2013, 19:48:39
Quote from: lysol on Tue, 22 January 2013, 17:01:59
I don't like plates, but if it is decided to go with redesign so plate required, I can just be happy with my prototype and not get anymore.

I'm pretty happy with the prototype PCBs as is, so I probably won't be getting a final production board either.

But I'll see to it that these make it to the final revision and production before I go completely MIA from this GH60 project. I already have my fully functional GH60 board  8)
Title: Re: GH60 prototype betatesting
Post by: Tranquilite on Wed, 23 January 2013, 03:11:28
I intend on using mine without a plate, and I don't particularly care about rotated switches, but on the other hand I don't mind doing a bit of finagling to get things working "right" either. My only concern would be if these design changes caused the prototyping phase to last longer (though if you do have to run more prototypes, I already have all of the switches/stabs/keycaps/etc needed to build one of these *wink wink*)
Title: Re: GH60 prototype betatesting
Post by: TheProfosist on Wed, 23 January 2013, 04:27:56
You guys do realise that lots of keyboards use rotated switches already right?
Title: Re: GH60 prototype betatesting
Post by: komar007 on Wed, 23 January 2013, 04:32:46
Which ones?
I've only seen 180 degree rotations.
Title: Re: GH60 prototype betatesting
Post by: TheProfosist on Wed, 23 January 2013, 04:38:42
Quote from: komar007 on Wed, 23 January 2013, 04:32:46
Which ones?
I've only seen 180 degree rotations.
I believe my WASD has some in the right side mods i know for sure that the SteelSeriees 7G i used to have had that as well


ive had caps off too many keyboards to count and good number of them had at random it seems 1-3 switches rotated im sorry i dont have exact models but I havnt touched a non custom keyboard in a long time.
Title: Re: GH60 prototype betatesting
Post by: asura on Wed, 23 January 2013, 05:07:39
0.15mm is well within the elastic deformation of ABS and should be within elastic deformation of PBT - depending on the technical quality of the original casting.
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Wed, 23 January 2013, 11:30:53
For ones with 90... almost every commerical MX numpad. Also... after making an error with WFD in regards to what to solder for me... (some confusion on my part led to the smd diodes not solder and I sure can't do that tiny stuff...) and you mentioning changing it to use a tie down wire. Instead, you could go old school and use in switch diode instead of surface mount so it has a dual purpose. Maybe that will even be cheaper with the fab since they have to do less?
Title: GH60 prototype betatesting
Post by: jdcarpe on Wed, 23 January 2013, 11:36:41
Yeah, the in-switch jumper wire idea would be great. Then I wouldn't have to remove the jumper wire from all these PCB mount switches.
Title: Re: GH60 prototype betatesting
Post by: komar007 on Wed, 23 January 2013, 11:51:01
Quote from: jdcarpe on Wed, 23 January 2013, 11:36:41
Yeah, the in-switch jumper wire idea would be great. Then I wouldn't have to remove the jumper wire from all these PCB mount switches.
But that would be just for modifiers.
So many extra holes will increase the cost and decrease rigidity.
Title: Re: GH60 prototype betatesting
Post by: jdcarpe on Wed, 23 January 2013, 12:16:08
Still a good idea, even if it's just for modifiers. :)
Title: Re: GH60 prototype betatesting
Post by: The_Beast on Wed, 23 January 2013, 13:33:18
Can someone tell me about how far the USB port will hang off the PCB?
Title: Re: GH60 prototype betatesting
Post by: komar007 on Wed, 23 January 2013, 13:41:37
Currently 2.8mm.
What are you making, The_Beast?
Title: Re: GH60 prototype betatesting
Post by: The_Beast on Wed, 23 January 2013, 13:42:40
Custom case brofessor ^__^
Title: Re: GH60 prototype betatesting
Post by: komar007 on Wed, 23 January 2013, 13:45:13
If it's made of wood, count me interested:D
Title: Re: GH60 prototype betatesting
Post by: The_Beast on Wed, 23 January 2013, 13:46:44
Quote from: komar007 on Wed, 23 January 2013, 13:45:13
If it's made of wood, count me interested:D

Alum, wood maybe later
Title: Re: Re: GH60 prototype betatesting
Post by: TheProfosist on Wed, 23 January 2013, 19:14:38
Quote from: The_Beast on Wed, 23 January 2013, 13:46:44
Quote from: komar007 on Wed, 23 January 2013, 13:45:13
If it's made of wood, count me interested:D

Alum, wood maybe later
beast can you make a stainless case? :D
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Thu, 24 January 2013, 01:13:40
Quote from: The_Beast on Wed, 23 January 2013, 13:33:18
Can someone tell me about how far the USB port will hang off the PCB?

Depends on how you solder it. The ones for the prototpe boards are fully surface-mounted, and the pads allow for quite a bit of variability. It can be mounted to stick out anywhere from 1.80mm to 4.00mm and still work fine. All the ones I soldered and sent out stick out about 2.15mm. For reference, both Poker and Pure stick out 2.60mm. They're through-hole, so that's not variable.

Interested in what case design you come up with, although I think I have an idea. My CAD file is pretty much done too, so maybe we can converge the design.
Title: Re: GH60 prototype betatesting
Post by: regack on Thu, 24 January 2013, 07:42:38
wood! wood! wood! wood! wood!

...who am I kidding, I'll take whatever comes, because I can't CAD to save my life D:
Title: Re: GH60 prototype betatesting
Post by: __red__ on Thu, 24 January 2013, 11:45:49
My USB socket is reassessed 2mm.  I didn't want it protruding past the pcb.
Title: Re: GH60 prototype betatesting
Post by: The_Beast on Thu, 24 January 2013, 11:47:50
Quote from: WhiteFireDragon on Thu, 24 January 2013, 01:13:40
Quote from: The_Beast on Wed, 23 January 2013, 13:33:18
Can someone tell me about how far the USB port will hang off the PCB?

Depends on how you solder it. The ones for the prototpe boards are fully surface-mounted, and the pads allow for quite a bit of variability. It can be mounted to stick out anywhere from 1.80mm to 4.00mm and still work fine. All the ones I soldered and sent out stick out about 2.15mm. For reference, both Poker and Pure stick out 2.60mm. They're through-hole, so that's not variable.

Interested in what case design you come up with, although I think I have an idea. My CAD file is pretty much done too, so maybe we can converge the design.

I can open AutoCAD, Solidworks or inventor part files. I designed mine in AutoCAD since all the shops I talked to perfered that over solidworks. Right now I'm having someone check over my design. If you want to send me yours, just PM me
Title: Re: GH60 prototype betatesting
Post by: kmiller8 on Fri, 25 January 2013, 21:49:57
Soo ve fnally gtten arudn to uttng m bar together wth swtcches. Everythngseems t be worng fne, ,ust the swtches ive use seem to e nicredbl finsey andd unreiable. I nee t get some newswtches and test those on the oaor....

On another keyboard: So I've finally gotten around to putting my board together with switches. Everything seems to be working fine, just the switches I've used seem to be incredibly finickey and unreliable. I need to get some new switches and test those on the board.

I know the FW works good, because if I manually short the pins on the back of the board, the controller picks them up instantly.

Assembly was a snap, no problems whatsoever with the PCB mounted switches I installed, and updating the firmware worked just fine. I really like the PCB mount option for stabilizers, and the rotated switches weren't a problem with the POM caps I was using.

Ok, that's about all I've got.

Thanks komar for the board, and WFD for the SMD work :)
Title: Re: GH60 prototype betatesting
Post by: TheProfosist on Sat, 26 January 2013, 07:28:06
lol kmiller I though that first paragraph might have been german at first
Title: Re: GH60 prototype betatesting
Post by: mkawa on Sun, 27 January 2013, 20:58:36
sigh, sorry folks, this is on my kbd todo list right after i make the next two ssk protos
Title: Re: Re: GH60 prototype betatesting
Post by: SmallFry on Sun, 27 January 2013, 22:40:09
Quote from: TheProfosist on Sat, 26 January 2013, 07:28:06
lol kmiller I though that first paragraph might have been german at first
I thought it was written in Prof. :P
Title: Re: Re: Re: GH60 prototype betatesting
Post by: TheProfosist on Mon, 28 January 2013, 01:09:20
Quote from: SmallFry on Sun, 27 January 2013, 22:40:09
Quote from: TheProfosist on Sat, 26 January 2013, 07:28:06
lol kmiller I though that first paragraph might have been german at first
I thought it was written in Prof. :P
i swear its the keyboard not me :P
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Tue, 29 January 2013, 14:25:45
No one brought this up yet, but all the holes for the standoffs are slightly offset to the left. komar, can you move them over by a fraction of a millimeter? For example, the hole for the between the "G  -  H" keys and "]  -  \" keys should be dead center. The other ones are a little harder to reference, but I can give you the exact coordinates for those. I know you have oval holes to account for any offset, but if you fix the holes to exact locations, you won't need a "looser" hole. Also, the USB port is slightly offset too. It should be moved slightly to the right (looking at the top of the PCB).

Any updates on what you want to do with rotated switches or mini vs micro USB? Probably should get a poll up. You can write it or I can write it.
Title: Re: GH60 prototype betatesting
Post by: komar007 on Tue, 29 January 2013, 15:00:43

I'll look into the holes' positions problem more thoroughly.

How do you make a poll on geekhack? Could you do it?
I'm currently fighting with my firmware trying to get it to work on atmega32u2, for the upcoming GHPad;)
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Tue, 29 January 2013, 15:04:46
Ok, I'll take care of the poll.
Title: Re: GH60 prototype betatesting
Post by: kmiller8 on Wed, 30 January 2013, 19:28:39
so I re-built my GH60, I'll take some Keyboard GORE pics later of it. I may not be able to help design custom layouts or do some fancy firmware, but when I say I tortured this poor PCB, I tortured it...

BUT I'm typing on it right now, this PCB is amazingly high quality, after tearing apart a "practically filco" QFR for blue switches, I was HIGHLY disappointed with the PCB quality, but that's just a rant for another day.

So yes, pics soonish, and I'll continue to follow this thread watching for new firmwares to test :)

Once again Thanks Komar for the board, and WFD for the SMD <3
Title: Re: GH60 prototype betatesting
Post by: alaricljs on Wed, 30 January 2013, 19:46:27
Quote from: kmiller8 on Wed, 30 January 2013, 19:28:39
after tearing apart a "practically filco" QFR for blue switches, I was HIGHLY disappointed with the PCB quality, but that's just a rant for another day.

Actually the QFR PCB is nearly identical to the Majestouch 1 Filco, the 2 is where they went dual-layer.  Carter says CM chose single layer PCB on purpose after testing a bunch of variants.
Title: Re: GH60 prototype betatesting
Post by: kmiller8 on Wed, 30 January 2013, 19:50:28
Quote from: alaricljs on Wed, 30 January 2013, 19:46:27
Actually the QFR PCB is nearly identical to the Majestouch 1 Filco, the 2 is where they went dual-layer.  Carter says CM chose single layer PCB on purpose after testing a bunch of variants.

really... hmm. Yeah it was a one sided PCB I tore apart (ripped about 10 traces :/) I hadn't know they specifically chose the one-sided. Like I mentioned in IRC, I destroyed this QFR PCB beyond future use, but the 30 year old Cherry PCB I tore apart at first is still perfectly fine (except for being broken into 5 pieces :P)

Thanks for the infos.
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Wed, 30 January 2013, 20:46:50
@kmiller8, you might have heated it too much so the glue holding the pads (if you can even call it that...) of the switch pins will lift a lot easier. Compounded with the fact that you might not have gotten all the solder off the switch pins/traces before pulling the switch out. 10 out of 87 keys is not a very good error ratio lol. And what kind of torture test did you put the PCB through?

@alaricljs, Of course the single sided PCB was on purpose, but I'm sure it was more of a business decision to save costs. Of course it'll sound much better publicly to say for testing purposes than to say they cheaped out on the PCB to save money.
Title: Re: GH60 prototype betatesting
Post by: alaricljs on Wed, 30 January 2013, 20:49:18
Well Carter did claim that it had something to do with noise... but whatever.

I got quantity pricing for Costar on "the same design" and CMs margins are admirable from a consumer perspective on the QFR sales.
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Wed, 30 January 2013, 21:10:09
Admirable indeed. Small cut in PCB specs that won't matter to most consumers, but huge ~50% reduction in price compared to Filco. But I wouldn't confuse the business decision with performance claims. They claim to worry about noise, yet failed to put a ferrite bead on the cable, something that the Filco cable has (which is not really needed lol). Anyways, I won't go OT on this anymore. Another time and thread for that.
Title: Re: GH60 prototype betatesting
Post by: kmiller8 on Wed, 30 January 2013, 21:29:44
Quote from: WhiteFireDragon on Wed, 30 January 2013, 20:46:50
@kmiller8, you might have heated it too much so the glue holding the pads (if you can even call it that...) of the switch pins will lift a lot easier. Compounded with the fact that you might not have gotten all the solder off the switch pins/traces before pulling the switch out. 10 out of 87 keys is not a very good error ratio lol. And what kind of torture test did you put the PCB through?

I definately heated them too much, but still, I used the same iron on the GH60 board and everything was fine (ok there was ONE pad I thought I lifted, I almost cried)

The torture was my soldering, then desoldering, then resoldering the board with the cheapest Radio Shack Soldering Irons I could find :)

(http://i.imgur.com/7L3T8Ram.jpg) (http://imgur.com/7L3T8Ra.jpg)

(http://i.imgur.com/ihSeq0Vm.jpg) (http://imgur.com/ihSeq0V.jpg)

It's such a bad job, and I wuvs it.

This PCB is so well done, I belive that any newb can use any ****ty iron and make a board that works :)
Title: Re: GH60 prototype betatesting
Post by: jdcarpe on Wed, 30 January 2013, 23:24:52
kmiller8, looks like you may have soldered the switches for R_ALT and R_WIN in the wrong positions? I dunno, maybe it's just how I'm looking at it. I see you placed the Caps Lock in the "Cherry" position, though. Nice. :)

Yeah, if you and I can make these things with our crap Radio Shack equipment (I had to desolder every switch from my board as well, to install the plate), anyone should be able to do it. ;D
Title: Re: GH60 prototype betatesting
Post by: kmiller8 on Wed, 30 January 2013, 23:45:57
Quote from: jdcarpe on Wed, 30 January 2013, 23:24:52
kmiller8, looks like you may have soldered the switches for R_ALT and R_WIN in the wrong positions? I dunno, maybe it's just how I'm looking at it. I see you placed the Caps Lock in the "Cherry" position, though. Nice. :)

Yeah, if you and I can make these things with our crap Radio Shack equipment (I had to desolder every switch from my board as well, to install the plate), anyone should be able to do it. ;D

caps lock and spacebar are cherry position, since I used cherry caps :)

The switches should be in the right place, all my caps fit just fine :x

I had to desolder two boards to build this thing... A Cherry plate mount black with 1/8th working switches, and a plate mount QFR (I used it for 20 minutes before ripping it apart and desoldering the sweet sweet blues)

I went through three soldering irons throughout this project, granted the first two were already half broken from previous "projects"
Title: Re: GH60 prototype betatesting
Post by: jdcarpe on Mon, 11 February 2013, 16:32:23
Finally got around to reprogramming my GH60 today. A bit of a learning curve there, as this was the first time I've programmed a board. I used hasu's firmware to program the Fn layer in Poker-style. Success! I also tried using HHKB layout on both default and Fn layers, and got that to work, as well.

Code: [Select]
    /* Layer 1: Poker mode
     * ,-----------------------------------------------------------.
     * |  `| F1| F2| F3| F4| F5| F6| F7| F8| F9|F10|F11|F12|       |
     * |-----------------------------------------------------------|
     * |     |   |Up |   |   |   |   |   |   |   |   |Hom|Ins|     |
     * |-----------------------------------------------------------|
     * |      |Lef|Dow|Rig|   |   |Psc|Slk|Pus|   |   |End|Enter   |
     * |-----------------------------------------------------------|
     * |Shift   |Del|   |   |Mut|Vl+|Vl-|   |PgU|PgD|Del|Shift     |
     * |-----------------------------------------------------------|
     * |Ctrl|Gui |Alt |      Space                  |Alt |xxx |Crtl|
     * `-----------------------------------------------------------'
     */
Title: Re: GH60 prototype betatesting
Post by: gnubag on Mon, 11 February 2013, 18:25:57
has any one tried to make 2 permanent layers + 1 function layer?

what i mean by that is:
1. layer qwerty
2. layer dvorak/colemak
and function layer as in fn + 1 = f1 , etc.

so switching between layer 1 and 2 with a toggle switch.
Title: Re: GH60 prototype betatesting
Post by: jdcarpe on Mon, 11 February 2013, 18:30:58
You can certainly do that. It's in hasu's keycode.h. From hasu's github (https://github.com/tmk/tmk_keyboard):

Quote
2.2 Layer Actions

This sets default layer into current layer. With this action you can return to default layer.

ACTION_LAYER_DEFAULT
Layer Set action sets given layer argument to current layer. Layer Set action can take 0 to 15 as argument.

ACTION_LAYER_SET(layer)
ACTION_LAYER_SET_TOGGLE(layer)
ACTION_LAYER_SET_TAP_KEY(layer, key)
ACTION_LAYER_SET_TAP_TOGGLE(layer)
Layer Bit action XOR bits with current layer. Layer Bit action can take 0 to 8 as argument.

ACTION_LAYER_BIT(bits)
ACTION_LAYER_BIT_TOGGLE(bits)
ACTION_LAYER_BIT_TAP_KEY(bits, key)
ACTION_LAYER_BIT_TAP_TOGGLE(bits)
These acitons change default layer. ACTION_LAYER_SET_DEFAULT(layer) ACTION_LAYER_BIT_DEFAULT(bits)
Title: Re: GH60 prototype betatesting
Post by: mkawa on Tue, 12 February 2013, 20:22:20
a-ha! i have enough ssk assemblies built now that i don't feel bad about populating my gh60 with switches!

quick q though: it looks like the pads aren't tinned. are they? am i just blind or something?
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Tue, 12 February 2013, 21:10:07
Why would switch pads need to be tinned? If you're talking about all the other pads for SMD components, I already soldered everything on for yours.
Title: Re: GH60 prototype betatesting
Post by: mkawa on Tue, 12 February 2013, 21:46:28
switch pads.

not tinned -> flux -> heat -> flow

tinned -> heat -> flow

not a big deal either way, just curious
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Tue, 12 February 2013, 23:09:16
If you put it that way, then phantom doesn't come "tinned" either. Usually through-hole pads won't come pretinned. Your solder wire has rosin in it, which acts as a flux when you solder. Even if you use solder paste, there's already flux mixed in there.
Title: Re: GH60 prototype betatesting
Post by: mkawa on Tue, 12 February 2013, 23:58:49
yes, i don't remember the phantom boards coming tinned either (but i ended up giving all of mine away so.. ;)). the reason i ask is because if the pads are tinned and i flux them first then flow, i find that i end up having to scrub the crap out of some rosin later. but, if the pads aren't tinned, i like a quick swipe of rosin before applying the iron to get the whole joint up to temp that much quicker.
Title: Re: GH60 prototype betatesting
Post by: __red__ on Wed, 13 February 2013, 08:46:40
<<==--  Not a fan of pre-tinning...
Title: Re: GH60 prototype betatesting
Post by: komar007 on Wed, 13 February 2013, 09:16:40
The pads are not tinned, but they're gold-plated. That's enough for easy soldering.
Title: Re: Re: GH60 prototype betatesting
Post by: __red__ on Wed, 13 February 2013, 09:22:29
Quote from: komar007 on Wed, 13 February 2013, 09:16:40
The pads are not tinned, but they're gold-plated. That's enough for easy soldering.

Enig ftw!
Title: Re: GH60 prototype betatesting
Post by: sordna on Wed, 13 February 2013, 09:52:30
I rarely need to pre-tin stuff... except things like lousy/old visibly corroded capacitor or audio socket terminals, or multi-strand wires. PCBs are almost always fine, unless they are ancient. Unless you do SMD soldering, you don't even need flux in my experience; a good rosin-core solder will do fine by itself.
Title: Re: GH60 prototype betatesting
Post by: __red__ on Wed, 13 February 2013, 16:11:16
Right, but tinned PCBs are **horrible** for doing SMD.  The components fall off the pads.
Title: Re: GH60 prototype betatesting
Post by: mkawa on Thu, 14 February 2013, 00:22:25
gold plated? sweet!
Title: Re: GH60 prototype betatesting
Post by: mkawa on Sat, 16 February 2013, 01:27:01
ok, assembled but not soldered down yet with a vortex poker plate and pcb mount clears i had lying around. only note so far is that the switch fixturing pegs/holes are very tight when the switches are plated. the tolerances in cut and flatness of the plate as well as the pcb conspire to make it difficult at best to make sure all switches are flush against the pcb. a couple of holes in the plate design and board distributed evenly would make this much more straightforward scratch that, it'll just push the plate down..
Title: Re: GH60 prototype betatesting
Post by: sordna on Sat, 16 February 2013, 01:57:34
Push the plate down, and then raise it after soldering the switches? Sounds a bit difficult... couldn't it rip out switches when you pull the plate back up?
How about simply pushing down hard on the PCB during soldering so that the pressure between the table and the PCB will cause the switch to make full contact?
Title: Re: GH60 prototype betatesting
Post by: mkawa on Sun, 17 February 2013, 01:19:51
i actually have a pretty clean solution, but don't have the parts to implement it yet.

take a second plate (luckily, imav has tons), and use that to apply force on the switches against the PCB using the retainer holes. parts needed are: extra plate (1), M2x16 (or longer) machine screws, matching nuts and washers. tighten in a cross pattern. the switches should all lock in using this method.
Title: Re: GH60 prototype betatesting
Post by: gnubag on Sun, 17 February 2013, 01:34:18
Quote from: mkawa on Sun, 17 February 2013, 01:19:51
i actually have a pretty clean solution, but don't have the parts to implement it yet.

take a second plate (luckily, imav has tons), and use that to apply force on the switches against the PCB using the retainer holes. parts needed are: extra plate (1), M2x16 (or longer) machine screws, matching nuts and washers. tighten in a cross pattern. the switches should all lock in using this method.

so the metal picture would be:

PCB-plate/switches/hold down plate
where the hold down plate would be pushing the switches into the pcb?
Title: Re: GH60 prototype betatesting
Post by: mkawa on Sun, 17 February 2013, 03:37:18
yep, exactly. the machine screws and nuts are used to apply pressure between the hold down plate and PCB
Title: Re: GH60 prototype betatesting
Post by: mkawa on Sun, 17 February 2013, 14:33:54
ok my board works ootb; thanks for loading a firmware wfd. i think i reversed the polarity on the caps LED though. i followed the polarity diagram on the bottom of the switch since the pads were all circular and didn't indicate polarity. did you follow the switch diagram in the layout kumar? if not, maybe you should make one of them square and/or add a silkscreen for the pads that are pos
Title: GH60 prototype betatesting
Post by: jdcarpe on Sun, 17 February 2013, 14:43:20
Quote from: mkawa on Sun, 17 February 2013, 14:33:54
ok my board works ootb; thanks for loading a firmware wfd. i think i reversed the polarity on the caps LED though. i followed the polarity diagram on the bottom of the switch since the pads were all circular and didn't indicate polarity. did you follow the switch diagram in the layout kumar? if not, maybe you should make one of them square and/or add a silkscreen for the pads that are pos

Yeah, I had to plug the board in and touch the legs of the LED to the pads to find polarity.
Title: Re: GH60 prototype betatesting
Post by: mkawa on Sun, 17 February 2013, 14:45:54
blech. ok imo that's a bug, but it's easy to fix with any of the above remedies, and it's not a bad idea to put indicate the polarity of all diodes on the board anyway. nothing else really stands out to me, but i literally just got it together.
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Sun, 17 February 2013, 15:20:49
A (+) is marked on the switch housing, does it not match up correctly on the pcb?
Title: Re: GH60 prototype betatesting
Post by: mkawa on Sun, 17 February 2013, 15:33:58
unless i flipped it last night (i was tired...) it doesn't seem to
Title: Re: GH60 prototype betatesting
Post by: komar007 on Mon, 18 February 2013, 09:19:45
Good point. I'll add polarity info to the silkscreen in the final version.
Title: Re: GH60 prototype betatesting
Post by: mkawa on Mon, 18 February 2013, 15:24:14
just test-fit in a PURE case. fit looks good modulo what has already been mentioned
Title: Re: GH60 prototype betatesting
Post by: rknize on Mon, 18 February 2013, 16:41:25
I usually set the assembly on a coaster or similar and apply pressure to the PCB with my palms as I solder the leads in an area.  I've had to do this on Filcos and other commercial boards, too.  You can't completely rely on the plate/PCB geometry to do all of the work for you.  However, being a double-sided PCB, it will probably handle a few unseated switches much better than a Leo or QFR will.
Title: Re: GH60 prototype betatesting
Post by: mkawa on Mon, 18 February 2013, 21:20:29
i think the unique challenge was that i was using pcb-mount switches and a plate. anyway, the board is small enough that you can just mash on it in every which way while it's viced and eventually everything will be flat enough. the second plate trick is quite nice though, particular for builders who will be making these in volume
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Sat, 23 February 2013, 22:19:19
The polarity on the caps lock LED is fine. Marking for A is + just as it is supposed to be. Nothing went amiss for me while building. All the mounting positions for my layout are fine and work correctly. The only minor gripe I have was with the caps lock position switch. The mounting pin shares a center hole. It made it more difficult to align the switch perfectly straight and I had to do some tricky stuff to keep it in place while soldering to make sure my SUPER BLACK was fully seated. I also used a locking switch for my right shift. I find it kind of sucky as you have to bottom it out hard to get it to latch and it is hard to get it to release. Oh well, it might be coming off.
As far as the rotated switches go, I had no problems with that with my Cherry keycaps and it is a non issue for me just as I suspected.
Now comes the hard part of the programming.

So... can someone explain to me like Barney style how I make the layout how I want it... I don't understand.
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Sun, 24 February 2013, 00:22:54
I made some progress and got this far
Code: [Select]
static const uint8_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
/*
* Poker Layer
*/
/* Layer x000: Default Layer
* ,-----------------------------------------------------------.
* |Esc|  1|  2|  3|  4|  5|  6|  7|  8|  9|  0|  -|  =|Backsp |
* |-----------------------------------------------------------|
* |Tab  |  Q|  W|  E|  R|  T|  Y|  U|  I|  O|  P|  [|  ]|    \|
* |-----------------------------------------------------------|
* |Caps  |  A|  S|  D|  F|  G|  H|  J|  K|  L|  ;|  '|Return  |
* |-----------------------------------------------------------|
* |Shift   |  Z|  X|  C|  V|  B|  N|  M|  ,|  .|  /|Shift     |
* |-----------------------------------------------------------|
* |Ctrl|Alt |      Space                 |Fn  |Gui |App |Ctrl|
* `-----------------------------------------------------------'
*/
KEYMAP_ANSI(
ESC, 1,   2,   3,   4,   5,   6,   7,   8,   9,   0,   MINS,EQL, BSPC, \
TAB, Q,   W,   E,   R,   T,   Y,   U,   I,   O,   P,   LBRC,RBRC,BSLS, \
CAPS,A,   S,   D,   F,   G,   H,   J,   K,   L,   SCLN,QUOT,     ENT,  \
LSFT,Z,   X,   C,   V,   B,   N,   M,   COMM,DOT, SLSH,          RSFT, \
LCTL,LALT,          SPC,                     FN2, RGUI,APP, RCTL),
/* Layer x001: Arrow */
KEYMAP_ANSI(
TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS, \
TRNS,TRNS,UP,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS, \
TRNS,LEFT,DOWN,RGHT,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,     TRNS, \
TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,          TRNS,   \
TRNS,TRNS,          TRNS,                    FN2,TRNS,TRNS,TRNS),
/*
* Momentary Fn Layer
*/
/* Layer x100: Default + Fn'd */
KEYMAP_ANSI(
GRV, F1,  F2,  F3,  F4,  F5,  F6,  F7,  F8,  F9,  F10, F11, F12, TRNS, \
TRNS,TRNS, UP,  TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,PSCR,PAUS,VOLU,VOLD,MUTE, \
TRNS,LEFT,DOWN,RGHT,TRNS,TRNS,TRNS,TRNS,TRNS,INS,HOME, PGUP,      TRNS, \
TRNS,TRNS, TRNS,FN0,TRNS,TRNS,TRNS,TRNS,DEL,END,PGDN,           TRNS, \
TRNS,TRNS,          TRNS,                     FN2, TRNS,TRNS,TRNS)
};

/*
 * Fn action definition
 */
static const uint16_t PROGMEM fn_actions[] = {
/* Layout */
[0] = ACTION_LAYER_BIT_TOGGLE(1),              // FN0 Arrow toggle(C)
[2] = ACTION_LAYER_BIT(4),                     // FN2 Fn
};


but when I try and generate the file I only get an error ***missing separator*** I don't understand the problem.

EDIT:  So I tracked down that problem, of some space or whatever it was that it was not expecting, but now am getting another stupid error that makes no sense to me of ***commands commence before target.
What the F*CK does it mean? I am not a programmer if that is not obvious. I need some kind of simple visual programming tool. This sh!t is pissing me off.

EDIT 2: I got a little farther maybe? Now getting ***interrupt/exception caught (code = 0xc00000fd, addr = 0x4217b3) whatever the hell that is supposed to mean. I give up for now.

EDIT 3: OK, so I lied. I kept going... lol. Got passed whatever that was... as I still have no clue but I basically just started over again. Anyway I am now getting a no rule to make target error. This is really incredibly tiresome and convoluted. Nope wait, scratch that back to ***interrupt/exception caught (code = 0xc00000fd, addr = 0x4217b3) FUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU!!!

EDIT 4: So apparently it's not good to install winAVR in program files. How retarded. Ok, so anyway after reinstalling it in the root of C as it requires apparently like it's Windows 3.11 I finally got some crap to appear about compiling such and such mucky muck for it to finally error out on some rubbish about 'expected } before { token on line 109 of keymap.c. I checked line 109 and there is not those character there. I don't understand. I really am giving up for now this time for real. I just hope someone can give me some answer tomorrow on how to make this crap work.
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Sun, 24 February 2013, 09:26:35
So I finally got something to work sort of. The make finishes without error, and I was able to load the hex file. Testing it in aqua most of the primary layer is fine, though there are a couple keys doing something other than what I designated. When trying to use the Fn key all hell breaks loose. It start outputting random character instead of what I designated, then upon release the primary layer types garbage and then just stop responding after a few presses require to unplug the keyboard before any typing will resume. I have no idea what is going on here.
Title: Re: GH60 prototype betatesting
Post by: hasu on Sun, 24 February 2013, 09:53:56
Your FN2 does XOR current layer with 4, this take you to layer 4. But you don't have layer 4.
If you are not familiar with XOR, you can use LAYER_SET action instead. In many case you won't need LAYER_BIT action.


Code: [Select]
static const uint16_t PROGMEM fn_actions[] = {
/* Layout */
[0] = ACTION_LAYER_BIT_TOGGLE(1),              // FN0 Arrow toggle(C)
[2] = ACTION_LAYER_BIT(4),                     // FN2 Fn
};
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Sun, 24 February 2013, 10:22:18
Thank you for responding, but I am not following that completely. I have like zero programming knowledge and was just editing your exisiting keymap_poker.h file. I understand you are saying there is an error for what I am trying to accomplish and where, but can you show me the needed change to make it do what I am looking for?
Title: Re: GH60 prototype betatesting
Post by: hasu on Sun, 24 February 2013, 11:29:58
Im not sure what you are trying on you keymap. But try this.
If this does not work you can still wait for komar's firmware and GUI tool.

Code: [Select]
static const uint16_t PROGMEM fn_actions[] = {
/* Layout */
[0] = ACTION_LAYER_SET_TOGGLE(1),              // FN0 Arrow toggle(C)
[2] = ACTION_LAYER_SET(2),                     // FN2 Fn
};
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Sun, 24 February 2013, 11:56:57
Ah ok I see. That is simple enough. I will give it a try when I get home from work.
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Sun, 24 February 2013, 19:17:47
That sort of worked. The FN layer is accessible and does everything it is supposed to, but when I let go of the Fn key the Fn layer was still engaged instead of returning to the default letters on primary layer. Primary layer was fine before pressing Fn and send everything it should, but stopped working right after. Like Fn is a lock (that does not turn off once engaged) which is not what I was after.

Ok, so playing a hunch based on my way of logic, I changed it back to ACTION_LAYER_BIT but defined it as (1) and did a little tweaking to some things and now it is working perfectly with just 2 layers. So now that I have something with basic functionality I will keep going on with the other layers of cursor lock and embedded numpad one at a time. Also, just in case anyone else like my layout here is the working keymap.h

Code: [Select]
static const uint8_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
    /*
     * Poker Layer
     */
    /* Layer x000: Poker Default Layer */
    KEYMAP_ANSI(
        ESC, 1,   2,   3,   4,   5,   6,   7,   8,   9,   0,   MINS,EQL, BSPC, \
        TAB, Q,   W,   E,   R,   T,   Y,   U,   I,   O,   P,   LBRC,RBRC,BSLS, \
        CAPS,A,   S,   D,   F,   G,   H,   J,   K,   L,   SCLN,QUOT,     ENT,  \
        LSFT,Z,   X,   C,   V,   B,   N,   M,   COMM,DOT, SLSH,          RSFT, \
        LCTL,LALT,NO,          SPC,                     FN0, RGUI,APP, RCTL),
    /*
     * Poker Momentary Fn Layer
     */
    /* Layer x100: Poker Default + Fn'd */
    KEYMAP_ANSI(
GRV, F1,  F2,  F3,  F4,  F5,  F6,  F7,  F8,  F9,  F10, F11, F12, TRNS, \
TRNS,FN1, UP,  TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,PSCR,PAUS,VOLU,VOLD,MUTE, \
TRNS,LEFT,DOWN,RGHT,TRNS,TRNS,TRNS,TRNS,TRNS,INS,HOME, PGUP,      TRNS, \
TRNS,TRNS, TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,DEL,END,PGDN,           TRNS, \
TRNS,TRNS,NO,          TRNS,                     FN0, TRNS,TRNS,TRNS)
};

/*
 * Fn action definition
 */
static const uint16_t PROGMEM fn_actions[] = {
    /* Poker Layout */
    [0] = ACTION_LAYER_BIT(1),                     // FN0 Fn
};

Thanks for the tip and starting off point from your files hasu, I surely would not have gotten anywhere for quite awhile otherwise.
Title: Re: GH60 prototype betatesting
Post by: hasu on Sun, 24 February 2013, 19:45:41
EDIT: I didn't read all of your post. OK. It seems to work now. Ignore me.

Great so far.
It looks like you FN layer doesn't have any return path to primary layer.

Did you read README already? You don't seem to do that. It is not enough but better than nothing.
You'll need to read Section '3 Layer' and '4 Layer Switching' at least.

If you read already it and became lost in your keymap it means my poor documentation and Engrish.
I want to improve it correction, suggestion or any feedback are welcome.
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Sun, 24 February 2013, 19:57:27
I just wanted it to be on while holding only and it seems to be doing that right now so I am satisfied for the moment. I don't use the 2nd layer very much, only very seldom so I just need it to be accessible for a second while I press whatever key I need.
I tend to only skim through readme to get the gist of things then jump in head first. Just looking at the files and stuff I got most of the idea of what I was supposed to be doing there. I am more of a learn by doing and trial and error person. Though sometimes I can frustrate myself on some things that are more technical like this by doing things that way.

I found most of documentation fine, but maybe you assume that people have a higher level of knowledge in some cases. Some thing might not be simple enough or need more detailed explanation for beginner. Like for me, the most advanced thing I have done that resembles any kind of coding was for my rainmeter set up.
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Mon, 25 February 2013, 11:05:46
I seem to be talking to myself a lot here lol.
I have come across one issue, well one for me anyway. This keyboard does not seem to be able to wake my PCs from sleep. I also tried reflash with not my firmware and tried komar again just to see. Does anyone else have this problem?
Title: Re: GH60 prototype betatesting
Post by: alaricljs on Mon, 25 February 2013, 11:08:49
This is normal for Hasu's FW in my experience.  I think he put in a special key combo to intentionally wake the PC...

shift-shift-print screen.

Someone on DT sent me a link to a patch they made to get around this, but it's gone now.  All I have is the description:

Quote
I declared a new state in keyboard.c named STANDBY, added it to the state machine in process_key() and do the processing there. The only downside it has right now is that I evaluate in the same function if the keyboard is in STANDBY or not. I can imagine that this part could be in another place to be more efficient
Title: Re: GH60 prototype betatesting
Post by: komar007 on Mon, 25 February 2013, 11:16:14
It's also normal for my firmware, simply because I haven't implemented it yet, but it will be available for sure.
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Mon, 25 February 2013, 11:25:08
I'm used to be able to press any key at all on any other keyboard to wake the pc don't need a special key, and I have it disable on my mouse to wake the pc because it would wake it randomly.
Title: Re: GH60 prototype betatesting
Post by: jdcarpe on Mon, 25 February 2013, 11:32:40
Quote from: IvanIvanovich on Mon, 25 February 2013, 11:25:08
I'm used to be able to press any key at all on any other keyboard to wake the pc don't need a special key, and I have it disable on my mouse to wake the pc because it would wake it randomly.

My Rosewill won't wake my Dell PC at work (several years old) when connected by USB. No matter what keys you press, nothing happens. I have to keep a PS/2 keyboard connected to wake it, or disable sleep mode on that PC.
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Mon, 25 February 2013, 12:24:24
That is fine, but any other keyboard I own will wake my EVGA P55 and my Zotac H67. So it not a question of my PCs not support wake on usb.
Title: Re: GH60 prototype betatesting
Post by: JPG on Mon, 25 February 2013, 12:25:46
Sometimes you need to play with the bios to make certain key "wake" the computer.
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Mon, 25 February 2013, 12:30:25
But I never need to do that on any other keyboard. Any key will wake the pc using any of my Poker, Cherry G80, etc. Only the GH60 does not wake it. So while I am not sure why, I view it as a 'bug' as it is a basic function in my opinion and certainly a nuisance for me that it is not working.
Title: Re: GH60 prototype betatesting
Post by: alaricljs on Mon, 25 February 2013, 12:32:35
It's already been covered by komar and myself.  The 2 firmwares in question do not at the moment support waking up the PC from sleep/standby/hibernate.
Title: Re: GH60 prototype betatesting
Post by: komar007 on Mon, 25 February 2013, 12:36:55
Quote from: IvanIvanovich on Mon, 25 February 2013, 12:30:25
But I never need to do that on any other keyboard. Any key will wake the pc using any of my Poker, Cherry G80, etc. Only the GH60 does not wake it. So while I am not sure why, I view it as a 'bug' as it is a basic function in my opinion and certainly a nuisance for me that it is not working.

It is not a bug, it's lack of feature;)
Title: Re: GH60 prototype betatesting
Post by: rknize on Mon, 25 February 2013, 12:39:11
It's been a while since I debugged USB protocol stuff, but for the remote resume-from-suspend to work the host sends a special command to the device before suspending it.  IIRC, the device is supposed to go into a low current mode (2.5mA or something).  The USB protocol allows such a peripheral to cause the USB host controller to wake the system via an interrupt.  I'm not sure how the relevant libraries for this controller will handle all of that.
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Mon, 25 February 2013, 12:45:12
I see. So does all the custom DIY boards not resume from sleep?
Title: Re: GH60 prototype betatesting
Post by: alaricljs on Mon, 25 February 2013, 12:46:38
Even though I've had a hefty number of Korean boards pass through my hands that is something I have never tested for.
Title: Re: GH60 prototype betatesting
Post by: hasu on Mon, 25 February 2013, 17:55:31
Quote from: IvanIvanovich on Mon, 25 February 2013, 11:25:08
I'm used to be able to press any key at all on any other keyboard to wake the pc don't need a special key, and I have it disable on my mouse to wake the pc because it would wake it randomly.

^This.  I didn't want to let pc wake randomly with accidental key press :) I don't use this remote wakeup feature myself.
At this time PJRC stack only supports USB remote wakeup and keybind is not flexible. You have to build with PJRC stack and press LShift+RShift+PrintScreen to wake your pc up.

Feature request and bug report also should go with github issue tracker, it is useful to remind me of what to do.
https://github.com/tmk/tmk_keyboard/issues/16
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Mon, 25 February 2013, 19:21:48
Not the friendliest keycombo since my PRT key in a Fn layer and my locking shift should make it really fun, but I might give it a go later. For now I guess it is not that big of a deal to reach over and give a quick tap to the power button to wake the pc.
Title: Re: GH60 prototype betatesting
Post by: alaricljs on Mon, 25 February 2013, 19:30:54
The combo is configurable, config.h has the lshift/rshift combo (IS_COMMAND) and all the different key presses that go with it are in common/command.c.
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Mon, 25 February 2013, 19:38:04
It would be nice if I can use space. Since it is the largest key it is easy to locate before my espresso after rolling out of bed in the morning :))
Title: Re: GH60 prototype betatesting
Post by: alaricljs on Mon, 25 February 2013, 19:49:47
https://github.com/tmk/tmk_keyboard/blob/master/common/command.c line 246 chance KC_PSCREEN to KC_SPACE

This at least gets you shift-shift-space to wake.
Title: Re: GH60 prototype betatesting
Post by: komar007 on Tue, 26 February 2013, 17:43:42
I've just published a very preliminary version of the Python GUI and a new firmware version which supports it. Everything is in the first post.
Please help find bugs and get it to work properly.
I'm sorry for the terrible quality of some parts of the code, but this is a work in progress. Because of that, please don't make changes yet which you want to be included in upstream later, since some parts of the code will change greatly.
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Wed, 27 February 2013, 19:39:29
I download the gui files, but I am not sure what is supposed to do with it. I download python files but I could only open it in edit mode. It have been at least a decade since I looked at anything python related so maybe some basic instruction would be good.
Title: Re: GH60 prototype betatesting
Post by: hasu on Thu, 28 February 2013, 05:34:25
komar, really really great work!

I confirmed your app on a tad old xubuntu, I need to install 'python3-minimal' and 'python3-tk' packages for this test.

Writing layout binary from GUI worked flawlessly and quickly. Editing layout also worked well except for one problem.

My problem is that I couldn't define 'layer action without scancode', I just want to change layer without sending any key. I know your gh60.lay has such key on key 57 but I couldn't change existent key(key 61) into such normal layer change key.
Title: Re: GH60 prototype betatesting
Post by: komar007 on Thu, 28 February 2013, 08:51:06
Quote from: hasu on Thu, 28 February 2013, 05:34:25
komar, really really great work!

I confirmed your app on a tad old xubuntu, I need to install 'python3-minimal' and 'python3-tk' packages for this test.

Writing layout binary from GUI worked flawlessly and quickly. Editing layout also worked well except for one problem.

My problem is that I couldn't define 'layer action without scancode', I just want to change layer without sending any key. I know your gh60.lay has such key on key 57 but I couldn't change existent key(key 61) into such normal layer change key.


Thanks, hasu!
I fixed that today, hoping I had introduced the bug just recently, but as it appears it's in 0.1 as well.

My code's in a mess now, so I'll publish the fix later. For now, a workaround is to write 0 as the scancode.
Title: Re: GH60 prototype betatesting
Post by: Acanthophis on Sun, 03 March 2013, 19:36:32
Will this layout be possible?

Link (http://ne0.cc/laygen/#Esc%20%60%7E%3A%3A1%20%201%20%21%20F1%3A%3A1%20%202%20@%20F2%3A%3A1%20%203%20%23%20F3%3A%3A1%20%204%20%24%20F4%3A%3A1%20%205%20%25%20F5%3A%3A1%20%206%20%5E%20F6%3A%3A1%20%207%20%26%20F7%3A%3A1%20%208%20*%20F8%3A%3A1%20%209%20%28%20F9%3A%3A1%20%200%20%29%20F10%3A%3A1%20%20-%20_%20F11%3A%3A1%20%20%3D%20+%20F12%3A%3A1%20%20Backspace%20Del%3A%3A2%24%24%0ATab%3A%3A1.5%20%20Q%3A%3A1%20%20W%20Home%3A%3A1%20%20E%20%5E%3A%3A1%20%20R%20End%3A%3A1%20%20T%20%3A%3A1%20%20Y%20%3A%3A1%20%20U%20PrScr%3A%3A1%20%20I%20Pause%3A%3A1%20%20O%207%3A%3A1%20%20P%208%3A%3A1%20%20%5B%20%7B%209%3A%3A1%20%20%5D%20%7D%20-%3A%3A1%20%20%5C%20%7C%20+%3A%3A1.5%24%24%0ACaps%20Lock%3A%3A1.75%20%20A%3A%3A1%20%20S%20%3C%3A%3A1%20%20D%20v%3A%3A1%20%20F%20%3E%3A%3A1%20%20G%20%3A%3A1%20%20H%20Back%3A%3A1%20%20J%20Play/Pause%3A%3A1%20%20K%20Next%3A%3A1%20%20L%204%3A%3A1%20%20%3B%20%3A%205%3A%3A1%20%20%27%20%22%206%3A%3A1%20%20Enter%20Enter%3A%3A2.25%24%24%0AShift%3A%3A2.25%20%20Z%20Del%3A%3A1%20%20X%20Mute%3A%3A1%20%20C%20VolDn%3A%3A1%20%20V%20VolUp%3A%3A1%20%20B%20%3A%3A1%20%20N%20%3A%3A1%20%20M%20%3A%3A1%20%20%2C%20%3E%3A%3A1%20%20.%20%3E%201%3A%3A1%20%20/%20%3F%202%3A%3A1%20%20Shift%203%3A%3A1.75%20%20FN%3A%3A1%20%24%24%0AControl%3A%3A1.25%20%20FN%3A%3A1%20%20Alt%3A%3A1.25%20%20Space%3A%3A6.25%20%20AltGr%200%3A%3A1.5%20%20FN%3A%3A1%20%20%20Win/%22Meta%22%20.%3A%3A1.25%20%20Control%20Enter%3A%3A1.5%24%24)
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Mon, 04 March 2013, 01:47:22
No. PCB does not support holes where those switches are. Why would you want something like that anyways? It's too much of a mix between 1x, 1.25, and 1.5x sizes on the bottom row.
Title: Re: GH60 prototype betatesting
Post by: Acanthophis on Mon, 04 March 2013, 07:32:18
It's just a individual thing I guess. Suits my typing style and my hand/finger size/reach pretty good, at least I would like to think so.
Well, I guess normal Pure layout will suffice.
Thanks for an answer, though.
Title: Re: GH60 prototype betatesting
Post by: Acanthophis on Mon, 04 March 2013, 09:41:50
Any thoughts on the FN layer?
Is it feasable to program it this way?

Link (http://ne0.cc/laygen/#%60%7E%3A%3A1%20%20F1%3A%3A1%20%20F2%3A%3A1%20%20F3%3A%3A1%20%20F4%3A%3A1%20%20F5%3A%3A1%20%20F6%3A%3A1%20%20F7%3A%3A1%20%20F8%3A%3A1%20%20F9%3A%3A1%20%20F10%3A%3A1%20%20F11%3A%3A1%20%20F12%3A%3A1%20%20Del%3A%3A2%24%24%0A%3A%3A1.5%20%20PgUp%3A%3A1%20%20Home%3A%3A1%20%20%5E%3A%3A1%20%20End%3A%3A1%20%20%3A%3A1%20%20%20%3A%3A1%20%20%20PrScr%3A%3A1%20%20%20Pause%3A%3A1%20%20%207%3A%3A1%20%20%208%3A%3A1%20%20%209%3A%3A1%20%20%20-%3A%3A1%20%20%20+%3A%3A1.5%24%24%0A%3A%3A1.75%20%20PgDn%3A%3A1%20%20%20%3C%3A%3A1%20%20%20v%3A%3A1%20%20%20%3E%3A%3A1%20%20%20%3A%3A1%20%20%20Back%3A%3A1%20%20%20Play/Pause%3A%3A1%20%20%20Next%3A%3A1%20%20%204%3A%3A1%20%20%205%3A%3A1%20%20%206%3A%3A1%20%20Enter%20%3A%3A2.25%24%24%0A%3A%3A2.25%20%20%20Del%3A%3A1%20%20%20Mute%3A%3A1%20%20%20VolDn%3A%3A1%20%20%20VolUp%3A%3A1%20%20%20%3A%3A1%20%20%3A%3A1%20%20%3A%3A1%20%20%3A%3A1%20%20%201%3A%3A1%20%20%202%3A%3A1%20%203%3A%3A1.75%20%20FN%3A%3A1%20%24%24%0A%3A%3A1.25%20%20FN%3A%3A1.25%20%20%3A%3A1.25%20%20SDK60%3A%20FN%20layout%3A%3A6.25%20%200%3A%3A1.25%20%20FN%3A%3A1.25%20%20%20.%3A%3A1.25%20%20Enter%3A%3A1.25%24%24)
Title: Re: GH60 prototype betatesting
Post by: kmiller8 on Mon, 04 March 2013, 10:20:05
Ok so after a few weeks of testing my board. I have two things.

1. Would there be a way to make the Fn button act as a windows key on a short-press, but FN for holding? I have it ingrained in my head to use the left windows key for Win+R and many other windows functions.

2. \\ not sure if that's the cap or the FW \\ It's been like that since day 1 \\ these were brand new blue switches \\ so I don't think there's anything wrong with them, but I could be mistaken since I seem to be the only one with the \\ problem. \\\\\\\\\\\\\\\\ granted, now i can type \\ twice as fast :P
Title: Re: GH60 prototype betatesting
Post by: jdcarpe on Mon, 04 March 2013, 10:25:08
Quote from: Acanthophis on Mon, 04 March 2013, 09:41:50
Any thoughts on the FN layer?
Is it feasable to program it this way?

Link (http://ne0.cc/laygen/#%60%7E%3A%3A1%20%20F1%3A%3A1%20%20F2%3A%3A1%20%20F3%3A%3A1%20%20F4%3A%3A1%20%20F5%3A%3A1%20%20F6%3A%3A1%20%20F7%3A%3A1%20%20F8%3A%3A1%20%20F9%3A%3A1%20%20F10%3A%3A1%20%20F11%3A%3A1%20%20F12%3A%3A1%20%20Del%3A%3A2%24%24%0A%3A%3A1.5%20%20PgUp%3A%3A1%20%20Home%3A%3A1%20%20%5E%3A%3A1%20%20End%3A%3A1%20%20%3A%3A1%20%20%20%3A%3A1%20%20%20PrScr%3A%3A1%20%20%20Pause%3A%3A1%20%20%207%3A%3A1%20%20%208%3A%3A1%20%20%209%3A%3A1%20%20%20-%3A%3A1%20%20%20+%3A%3A1.5%24%24%0A%3A%3A1.75%20%20PgDn%3A%3A1%20%20%20%3C%3A%3A1%20%20%20v%3A%3A1%20%20%20%3E%3A%3A1%20%20%20%3A%3A1%20%20%20Back%3A%3A1%20%20%20Play/Pause%3A%3A1%20%20%20Next%3A%3A1%20%20%204%3A%3A1%20%20%205%3A%3A1%20%20%206%3A%3A1%20%20Enter%20%3A%3A2.25%24%24%0A%3A%3A2.25%20%20%20Del%3A%3A1%20%20%20Mute%3A%3A1%20%20%20VolDn%3A%3A1%20%20%20VolUp%3A%3A1%20%20%20%3A%3A1%20%20%3A%3A1%20%20%3A%3A1%20%20%3A%3A1%20%20%201%3A%3A1%20%20%202%3A%3A1%20%203%3A%3A1.75%20%20FN%3A%3A1%20%24%24%0A%3A%3A1.25%20%20FN%3A%3A1.25%20%20%3A%3A1.25%20%20SDK60%3A%20FN%20layout%3A%3A6.25%20%200%3A%3A1.25%20%20FN%3A%3A1.25%20%20%20.%3A%3A1.25%20%20Enter%3A%3A1.25%24%24)

Yes, that layout is totally possible. hasu's firmware includes all of those media keys, etc., you just have to change your keymap.c to reflect the layout of your Fn layer.
Title: GH60 prototype betatesting
Post by: mkawa on Mon, 04 March 2013, 10:28:28
another call for someone who needs a board to help with software dev (especially with konar's keymapping front-end)
Title: Re: GH60 prototype betatesting
Post by: komar007 on Mon, 04 March 2013, 10:33:09
Quote from: kmiller8 on Mon, 04 March 2013, 10:20:05
Ok so after a few weeks of testing my board. I have two things.

1. Would there be a way to make the Fn button act as a windows key on a short-press, but FN for holding? I have it ingrained in my head to use the left windows key for Win+R and many other windows functions.

We'd need an idea how to implement it... Since you only know if the press is long or short after you've released the button:D
The best I can think of is to delay the keypress until either the threshold has been reached or the key was released before it, in which case press and release events have to be sent instantly.

Quote from: kmiller8 on Mon, 04 March 2013, 10:20:05
2. \\ not sure if that's the cap or the FW \\ It's been like that since day 1 \\ these were brand new blue switches \\ so I don't think there's anything wrong with them, but I could be mistaken since I seem to be the only one with the \\ problem. \\\\\\\\\\\\\\\\ granted, now i can type \\ twice as fast :p
Which FW and OS are you using?
There's a bug in the linux hid support which causes something like that (2 codes mapped to this key). Not sure this is the case here, since this rather caused immediate key release behaviour...


EDIT: on the other hand the solution to this problem is to send both codes at once, which may, in turn, cause windows to freak out and see the keypress twice... I don't know.
Title: Re: GH60 prototype betatesting
Post by: jdcarpe on Mon, 04 March 2013, 10:33:16
komar, does your GUI absolutely require Python 3.0? I need to have Python 2.7 installed on my machine, so I didn't know if your code would run under 2.7.
Title: Re: GH60 prototype betatesting
Post by: komar007 on Mon, 04 March 2013, 10:36:05
I'll see how compatible it is...
BTW, is there a problem with having more pythons? I have 6 on my machine...
Title: GH60 prototype betatesting
Post by: mkawa on Mon, 04 March 2013, 10:40:27
UGH PYTHON
Title: Re: GH60 prototype betatesting
Post by: kmiller8 on Mon, 04 March 2013, 10:50:31
Quote from: komar007 on Mon, 04 March 2013, 10:33:09
We'd need an idea how to implement it... Since you only know if the press is long or short after you've released the button:D
The best I can think of is to delay the keypress until either the threshold has been reached or the key was released before it, in which case press and release events have to be sent instantly.

Which FW and OS are you using?
There's a bug in the linux hid support which causes something like that (2 codes mapped to this key). Not sure this is the case here, since this rather caused immediate key release behaviour...

EDIT: on the other hand the solution to this problem is to send both codes at once, which may, in turn, cause windows to freak out and see the keypress twice... I don't know.

haha, 'twas a silly thought, I'll just have to adjust to windows on the right side.

FW, I have no idea, whatever WFD sent, and Windows 32-bit Pro.

I'll try to update the FW to something newer and see if that fixes it
Title: Re: GH60 prototype betatesting
Post by: kmiller8 on Mon, 04 March 2013, 11:22:05
(http://i.imgur.com/KqiiMKT.png) (http://imgur.com/KqiiMKT.png)

Edit from a phone: it's broken. What did I do wrong ;_;

EDIT 2: reflashed the pre-release FW \ \ \\ \ \ \ \ \ \ \ \ \ it's better now i guess :))
Title: Re: GH60 prototype betatesting
Post by: komar007 on Mon, 04 March 2013, 11:59:11
Unfortunately, I've just found out it doesn't work on win7 and 8:/
I have no idea about windows, so I ask for help.

The best we can do is to provide a windows version of the hid communication layer using winapi.
The worse solution is to make libusb and pyusb work correctly in windows 7 and 8. This has to be doable either in the code or by changing something in the way the driver is installed, since libusb and pyusb are supposed to work at least on windows 7... But again, I need someone who can do this, or I'll be searching blindly.
Title: Re: GH60 prototype betatesting
Post by: kmiller8 on Mon, 04 March 2013, 14:28:57
Quote from: komar007 on Mon, 04 March 2013, 11:59:11
Unfortunately, I've just found out it doesn't work on win7 and 8:/
I have no idea about windows, so I ask for help.

haha ok. well I guess I'm stuck on this pre-release \\ \\ \\
Title: Re: GH60 prototype betatesting
Post by: komar007 on Mon, 04 March 2013, 15:16:02
The FW works all right, you just cannot program the layout.
If you have a winxp somewhere, you can use it to program the keyboard, and then use it in 7.
Though this FW is buggy in general;)
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Mon, 04 March 2013, 15:24:16
You can still use the method from hasu to reprogram for now on Windows, though you really need to read, read, re-read, and read again the instructions. I used that with the winavr and flip on win7 x64 and it work fine.

I'm not a programmer and don't really understand much of those things, but would it be possible to just make a front end gui to work on winavr for this? Seems it would be a good idea to take advantage of that since it is working reliably and just make it more user friendly.
Title: Re: GH60 prototype betatesting
Post by: Acanthophis on Tue, 05 March 2013, 01:18:20
Quote from: jdcarpe on Mon, 04 March 2013, 10:25:08
Quote from: Acanthophis on Mon, 04 March 2013, 09:41:50
Any thoughts on the FN layer?
Is it feasable to program it this way?

Link (http://ne0.cc/laygen/#%60%7E%3A%3A1%20%20F1%3A%3A1%20%20F2%3A%3A1%20%20F3%3A%3A1%20%20F4%3A%3A1%20%20F5%3A%3A1%20%20F6%3A%3A1%20%20F7%3A%3A1%20%20F8%3A%3A1%20%20F9%3A%3A1%20%20F10%3A%3A1%20%20F11%3A%3A1%20%20F12%3A%3A1%20%20Del%3A%3A2%24%24%0A%3A%3A1.5%20%20PgUp%3A%3A1%20%20Home%3A%3A1%20%20%5E%3A%3A1%20%20End%3A%3A1%20%20%3A%3A1%20%20%20%3A%3A1%20%20%20PrScr%3A%3A1%20%20%20Pause%3A%3A1%20%20%207%3A%3A1%20%20%208%3A%3A1%20%20%209%3A%3A1%20%20%20-%3A%3A1%20%20%20+%3A%3A1.5%24%24%0A%3A%3A1.75%20%20PgDn%3A%3A1%20%20%20%3C%3A%3A1%20%20%20v%3A%3A1%20%20%20%3E%3A%3A1%20%20%20%3A%3A1%20%20%20Back%3A%3A1%20%20%20Play/Pause%3A%3A1%20%20%20Next%3A%3A1%20%20%204%3A%3A1%20%20%205%3A%3A1%20%20%206%3A%3A1%20%20Enter%20%3A%3A2.25%24%24%0A%3A%3A2.25%20%20%20Del%3A%3A1%20%20%20Mute%3A%3A1%20%20%20VolDn%3A%3A1%20%20%20VolUp%3A%3A1%20%20%20%3A%3A1%20%20%3A%3A1%20%20%3A%3A1%20%20%3A%3A1%20%20%201%3A%3A1%20%20%202%3A%3A1%20%203%3A%3A1.75%20%20FN%3A%3A1%20%24%24%0A%3A%3A1.25%20%20FN%3A%3A1.25%20%20%3A%3A1.25%20%20SDK60%3A%20FN%20layout%3A%3A6.25%20%200%3A%3A1.25%20%20FN%3A%3A1.25%20%20%20.%3A%3A1.25%20%20Enter%3A%3A1.25%24%24)

Yes, that layout is totally possible. hasu's firmware includes all of those media keys, etc., you just have to change your keymap.c to reflect the layout of your Fn layer.
Thanks, I'll look into hasu's FW. :)
Title: Re: GH60 prototype betatesting
Post by: nano on Tue, 05 March 2013, 06:00:55
I'm very new to GH and this is my first Post  :)

I just wanted to let you know that your code on github is awesome. I've studied it for the last two days and all I can say is wow.
consistent style
well documented
great use of modern c

Continue like this!
Title: Re: GH60 prototype betatesting
Post by: John Fourth on Tue, 05 March 2013, 21:55:50

Any boards left to help with development? I have C/C++ and Linux experience.

Thanks,
John
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Tue, 05 March 2013, 22:02:59
Ask mkawa. I think he offered his to anyone that has more time to help with development since he doesn't have the time himself. I have 2 with me because I did the SMD soldering, but I don't own them. Maybe I can ask the owner if anyone can borrow it, as he doesn't know too much about keyboards.
Title: Re: GH60 prototype betatesting
Post by: agodinhost on Thu, 07 March 2013, 19:06:51
Guys, would not be better to create another topic to the subject "GH60 Keymapper software" ?
Title: Re: GH60 prototype betatesting
Post by: tricheboars on Fri, 08 March 2013, 00:51:13
Quote from: nano on Tue, 05 March 2013, 06:00:55
I'm very new to GH and this is my first Post  :)

I just wanted to let you know that your code on github is awesome. I've studied it for the last two days and all I can say is wow.
consistent style
well documented
great use of modern c

Continue like this!

this post makes me happy.  keep it wutang mother****ers!
Title: Re: GH60 prototype betatesting
Post by: vorn on Fri, 08 March 2013, 01:19:39
Sorry for off-topic... tricheboars: has there ever been a Wu keycap GB?  ;D ;D
Title: Re: GH60 prototype betatesting
Post by: GordonZed on Fri, 08 March 2013, 20:09:44
Quote from: vorn on Fri, 08 March 2013, 01:19:39
Sorry for off-topic... tricheboars: has there ever been a Wu keycap GB?  ;D ;D

Yeah, there is right now. The ZOMG! keycaps GB, I'd ask Ragnorock if there are any extras 'cause orders juat closed last week.
Title: Re: GH60 prototype betatesting
Post by: komar007 on Sat, 09 March 2013, 05:07:34
I noticed that the whole board is moved a bit to the right in the original Poker case. It seems to be about 0.5mm. Can someone confirm this? I'm wondering how much the cases differ from each other. I also know that after a ton of tinkering with the mounting holes it seems the horizontal distance between the left hole and the switches is slightly different than in the Poker PCB, so I need to correct that.


BTW: has anyone tried to put the GH60 into a different case (aluminium anyone...)? Does everything fit all right?
Title: Re: GH60 prototype betatesting
Post by: mkawa on Sat, 09 March 2013, 11:20:17
i didn't notice this when i test fit it into a pure case... do you have a sample of both cases komar?
Title: Re: GH60 prototype betatesting
Post by: komar007 on Sat, 09 March 2013, 11:29:47
No, unfortunately just Poker.
Title: Re: GH60 prototype betatesting
Post by: mkawa on Sat, 09 March 2013, 11:51:38
ok i think i have one for you, pending danucf's approval (he had dibs)
Title: Re: GH60 prototype betatesting
Post by: mkawa on Sat, 09 March 2013, 12:44:23
yep, i've got one for you. can you pm me komar?
Title: Re: GH60 prototype betatesting
Post by: komar007 on Sat, 09 March 2013, 12:55:37
PMd
Title: Re: GH60 prototype betatesting
Post by: WhiteFireDragon on Sat, 09 March 2013, 13:36:36
Quote from: komar007 on Sat, 09 March 2013, 05:07:34
I noticed that the whole board is moved a bit to the right in the original Poker case. It seems to be about 0.5mm. Can someone confirm this? I'm wondering how much the cases differ from each other. I also know that after a ton of tinkering with the mounting holes it seems the horizontal distance between the left hole and the switches is slightly different than in the Poker PCB, so I need to correct that.


BTW: has anyone tried to put the GH60 into a different case (aluminium anyone...)? Does everything fit all right?

I think I mentioned this earlier in the thread that they're all off by just a fraction of a millimeter, including the USB connector pads. I noticed this when I designed my aluminum case. I'll give you the coordinates of exact location of the mounting holes when I can get back to my workstation computer.
Title: Re: GH60 prototype betatesting
Post by: komar007 on Wed, 13 March 2013, 05:24:48
What do you think of making the top-left hole a slot too? I know this will require some twiddling to get the position right and it may allow some movement after fixing the PCB to the case, but since it seems it fits the Pure case just fine and is off in the Poker case, maybe it makes sense...
What about the vertical position of the board? I can see it fits a little to high in the case. Is it just me?
Title: Re: GH60 prototype betatesting
Post by: OrangeJewce on Wed, 13 March 2013, 08:33:37
Quote from: komar007 on Mon, 04 March 2013, 15:16:02
The FW works all right, you just cannot program the layout.
If you have a winxp somewhere, you can use it to program the keyboard, and then use it in 7.
Though this FW is buggy in general;)

Komar, do you need someone to work on a windows API to get the firmware to work on win7/8? Or is it the firmware itself that's broken on anything over XP?

Cheers,
Title: Re: GH60 prototype betatesting
Post by: komar007 on Wed, 13 March 2013, 08:51:20
Quote from: OrangeJewce on Wed, 13 March 2013, 08:33:37
Quote from: komar007 on Mon, 04 March 2013, 15:16:02
The FW works all right, you just cannot program the layout.
If you have a winxp somewhere, you can use it to program the keyboard, and then use it in 7.
Though this FW is buggy in general;)

Komar, do you need someone to work on a windows API to get the firmware to work on win7/8? Or is it the firmware itself that's broken on anything over XP?

Cheers,
Yes, I do. It's only a problem with the GUI. I don't know why it works in xp but not in 7 or 8, but I'd prefer if the windows version used winapi instead of libusb, because as far as I understand it correctly this wouldn't require the users to install any drivers.
I need someone to write code in python that will send and receive interrupt packets (raw reports) to and from a hid class device.
An example of how to do this in C is the teensy raw hid test program here: http://www.pjrc.com/teensy/rawhid.html
If this can't be done in python, I don't mind a small helper binary program and a python library which calls it to perform communication.
Title: Re: GH60 prototype betatesting
Post by: OrangeJewce on Wed, 13 March 2013, 11:33:19
Quote from: komar007 on Wed, 13 March 2013, 08:51:20
Quote from: OrangeJewce on Wed, 13 March 2013, 08:33:37
Quote from: komar007 on Mon, 04 March 2013, 15:16:02
The FW works all right, you just cannot program the layout.
If you have a winxp somewhere, you can use it to program the keyboard, and then use it in 7.
Though this FW is buggy in general;)

Komar, do you need someone to work on a windows API to get the firmware to work on win7/8? Or is it the firmware itself that's broken on anything over XP?

Cheers,
Yes, I do. It's only a problem with the GUI. I don't know why it works in xp but not in 7 or 8, but I'd prefer if the windows version used winapi instead of libusb, because as far as I understand it correctly this wouldn't require the users to install any drivers.
I need someone to write code in python that will send and receive interrupt packets (raw reports) to and from a hid class device.
An example of how to do this in C is the teensy raw hid test program here: http://www.pjrc.com/teensy/rawhid.html
If this can't be done in python, I don't mind a small helper binary program and a python library which calls it to perform communication.

I'll check it out. Maybe this requires some .NET stuff to function on windows correctly. I don't know yet though.

Cheers,
Title: Re: GH60 prototype betatesting
Post by: agodinhost on Wed, 13 March 2013, 13:05:08
Quote from: komar007 on Wed, 13 March 2013, 08:51:20
... but I'd prefer if the windows version used winapi instead of libusb, because as far as I understand it correctly this wouldn't require the users to install any drivers ...
I'm not sure here but I think that the winapi is not multi-platform. Anyway I do prefer LibUsb.

Why would you have to install a driver? the libusb dlls are the "drivers", you just need a different .inf with the "configuration" I'm wrong?
Title: Re: GH60 prototype betatesting
Post by: komar007 on Wed, 13 March 2013, 13:10:43
Quote from: agodinhost on Wed, 13 March 2013, 13:05:08
Quote from: komar007 on Wed, 13 March 2013, 08:51:20
... but I'd prefer if the windows version used winapi instead of libusb, because as far as I understand it correctly this wouldn't require the users to install any drivers ...
I'm not sure here but I think that the winapi is not multi-platform. Anyway I do prefer LibUsb.

Of course libusb stays for linux, I only mean for windows, since most users will prefer if they don't have to do anything to make it work.
Title: Re: GH60 prototype betatesting
Post by: agodinhost on Wed, 13 March 2013, 13:22:20
Quote from: komar007 on Wed, 13 March 2013, 13:10:43
Of course libusb stays for linux, I only mean for windows, since most users will prefer if they don't have to do anything to make it work.
Why don't you use the same idea already used into the Arduino IDE?
It just open one COM port (it's java, they use the TXRXComm library) when it needs any "serial" communication.
The compiled firmware itself (the hex files) is uploaded using avrdude at the command line (in background, sure).

Even when using those "FTDI USB Drivers" it works fine (these FTDI drivers are LibUsb based most times)

Title: Re: GH60 prototype betatesting
Post by: komar007 on Wed, 13 March 2013, 13:32:55
I don't know. Perhaps it was easier to implement rawhid at the time I worked on this.
Title: Re: GH60 prototype betatesting
Post by: agodinhost on Wed, 13 March 2013, 13:41:40
Quote from: komar007 on Wed, 13 March 2013, 13:32:55
I don't know. Perhaps it was easier to implement rawhid at the time I worked on this.
You know your code better than me - I still didn't poked on it ...

Do you have any other option Komar?
Title: Re: GH60 prototype betatesting
Post by: Glissant on Thu, 14 March 2013, 23:16:58
I just re-read the first post, and figured out what my "problem" was.
Don't keyboard in the middle of the night when you are sick and exhausted from coughing :)) .


Back to figuring out how to program a layout from windows 8.


Anybody tried to run the gui under windowsxpmode in windows 8? I'm going to try that after some sleep.
Title: Re: Re: GH60 prototype betatesting
Post by: jdcarpe on Fri, 15 March 2013, 00:28:58
Quote from: Glissant on Thu, 14 March 2013, 23:16:58
I just re-read the first post, and figured out what my "problem" was.
Don't keyboard in the middle of the night when you are sick and exhausted from coughing :)) .


Back to figuring out how to program a layout from windows 8.


Anybody tried to run the gui under windowsxpmode in windows 8? I'm going to try that after some sleep.

I tried it under XP compatible mode in Win7 with no luck.

I went back to using hasu's FW. You have to have WinAVR to compile the keymap to hex, then use Flip to flash the FW.
Title: Re: GH60 prototype betatesting
Post by: Glissant on Fri, 15 March 2013, 01:10:50
I had no luck with virtualbox running XP either. I just ended up running ubuntu in virtualbox and flashing the layout via the gui that way :).
Is there a sneaky way of setting blank keys with the gui? I see the layer switcher is blank, but setting it blank just reverts to the last valid key for me. Loving being able to customize with the gui so far. Can't wait to see where we end up with it.

Going to look into testing the board with hasu's fw later today.
Title: Re: GH60 prototype betatesting
Post by: komar007 on Fri, 15 March 2013, 01:30:00
Quote from: Glissant on Fri, 15 March 2013, 01:10:50
I had no luck with virtualbox running XP either. I just ended up running ubuntu in virtualbox and flashing the layout via the gui that way :) .
Is there a sneaky way of setting blank keys with the gui? I see the layer switcher is blank, but setting it blank just reverts to the last valid key for me. Loving being able to customize with the gui so far. Can't wait to see where we end up with it.

Going to look into testing the board with hasu's fw later today.

This is a bug. You can use 0x00 to make blank keys.
Title: Re: GH60 prototype betatesting
Post by: OrangeJewce on Fri, 15 March 2013, 08:12:20
If you guys are still having problems I can try and check out the code this weekend and attempt to debug it.

Cheers,
Title: Re: GH60 prototype betatesting
Post by: Glissant on Fri, 15 March 2013, 11:35:14
I'm not sure if it's worth mentioning, but I will anyway.
My GH60 had suddenly lost it's layout during the night or something. I am 100% sure it was working before I went to bed, but when I woke up and started my computer from standby it no longer responded to input.
I had flashed the firmware from my ubuntu virtualbox and also added the layout from the same virtualbox. For some reason I was unable to reapply or add a new layout as my system didn't recognize the keyboard.
I know this is virtually useless information as I have no data to back it up, but I am willing to test some stuff out later today if anybody needs/wants me to; that way I can see if I can replicate the difficulties I had.

I'm currently testing hasu's firmware to see if I can work with it, but so far it's a little too much to learn when it comes to making my own layouts.

Anybody have any layouts they would like to share for hasu's firmware? I'll search in the different gh60 threads, but I thought I should ask at the same time.


Edit: Just saw keymap.c . :)) Well at least I am slowly but surely figuring everything out.
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Fri, 15 March 2013, 11:48:46
You can use my layout firmware (https://docs.google.com/file/d/0BwnwXcpLx2NpQUFxd2EtS3pzV3c/edit?usp=sharing) if you want to try it, just need to flash it using FLIP.
Title: Re: GH60 prototype betatesting
Post by: jdcarpe on Fri, 15 March 2013, 12:01:42
Glissant, this one is just like a Poker...
Title: Re: GH60 prototype betatesting
Post by: komar007 on Fri, 15 March 2013, 12:17:22
Quote from: Glissant on Fri, 15 March 2013, 11:35:14
I'm not sure if it's worth mentioning, but I will anyway.
My GH60 had suddenly lost it's layout during the night or something. I am 100% sure it was working before I went to bed, but when I woke up and started my computer from standby it no longer responded to input.
I had flashed the firmware from my ubuntu virtualbox and also added the layout from the same virtualbox. For some reason I was unable to reapply or add a new layout as my system didn't recognize the keyboard.
I know this is virtually useless information as I have no data to back it up, but I am willing to test some stuff out later today if anybody needs/wants me to; that way I can see if I can replicate the difficulties I had.

I'm currently testing hasu's firmware to see if I can work with it, but so far it's a little too much to learn when it comes to making my own layouts.

Anybody have any layouts they would like to share for hasu's firmware? I'll search in the different gh60 threads, but I thought I should ask at the same time.

There is a bug in my firmware which causes it to stop sending keys occasionally.
I hope I'll fix it soon.
If the computer didn't recognize it at all, that's weird... It should see it all right, and after reprogramming with the GUI, it should start working again.


Reconnecting the keyboard should help as well.
Title: Re: GH60 prototype betatesting
Post by: Glissant on Fri, 15 March 2013, 15:40:00
I'm not sure if recognized is the right word for what happened. I was unable to communicate with the keyboard with the libusb driver for some reason. It was as if it had frozen. A reboot of my computer didn't fix it either. Unplugging and reconnecting the keyboard didn't solve the issue. I didn't spend a lot of time trying to figure out the issue as I had already spent enough time trying to get the gui to run xD.

I might take some time tomorrow to see if I can figure out what happened.
Title: Re: GH60 prototype betatesting
Post by: jdcarpe on Fri, 15 March 2013, 15:40:55
Did you get it working with the hasu FW?
Title: Re: GH60 prototype betatesting
Post by: Glissant on Fri, 15 March 2013, 15:42:10
Yes, it's running fine with hasu's firmware with different layouts =).
Title: Re: GH60 prototype betatesting
Post by: OrangeJewce on Fri, 15 March 2013, 16:44:22
Quote from: komar007 on Fri, 15 March 2013, 12:17:22
Quote from: Glissant on Fri, 15 March 2013, 11:35:14
I'm not sure if it's worth mentioning, but I will anyway.
My GH60 had suddenly lost it's layout during the night or something. I am 100% sure it was working before I went to bed, but when I woke up and started my computer from standby it no longer responded to input.
I had flashed the firmware from my ubuntu virtualbox and also added the layout from the same virtualbox. For some reason I was unable to reapply or add a new layout as my system didn't recognize the keyboard.
I know this is virtually useless information as I have no data to back it up, but I am willing to test some stuff out later today if anybody needs/wants me to; that way I can see if I can replicate the difficulties I had.

I'm currently testing hasu's firmware to see if I can work with it, but so far it's a little too much to learn when it comes to making my own layouts.

Anybody have any layouts they would like to share for hasu's firmware? I'll search in the different gh60 threads, but I thought I should ask at the same time.

There is a bug in my firmware which causes it to stop sending keys occasionally.
I hope I'll fix it soon.
If the computer didn't recognize it at all, that's weird... It should see it all right, and after reprogramming with the GUI, it should start working again.


Reconnecting the keyboard should help as well.

Komar,

do you have a link to the UI github?

Cheers,
Title: Re: GH60 prototype betatesting
Post by: komar007 on Fri, 15 March 2013, 16:53:05
Quote from: OrangeJewce on Fri, 15 March 2013, 16:44:22
Quote from: komar007 on Fri, 15 March 2013, 12:17:22
Quote from: Glissant on Fri, 15 March 2013, 11:35:14
I'm not sure if it's worth mentioning, but I will anyway.
My GH60 had suddenly lost it's layout during the night or something. I am 100% sure it was working before I went to bed, but when I woke up and started my computer from standby it no longer responded to input.
I had flashed the firmware from my ubuntu virtualbox and also added the layout from the same virtualbox. For some reason I was unable to reapply or add a new layout as my system didn't recognize the keyboard.
I know this is virtually useless information as I have no data to back it up, but I am willing to test some stuff out later today if anybody needs/wants me to; that way I can see if I can replicate the difficulties I had.

I'm currently testing hasu's firmware to see if I can work with it, but so far it's a little too much to learn when it comes to making my own layouts.

Anybody have any layouts they would like to share for hasu's firmware? I'll search in the different gh60 threads, but I thought I should ask at the same time.

There is a bug in my firmware which causes it to stop sending keys occasionally.
I hope I'll fix it soon.
If the computer didn't recognize it at all, that's weird... It should see it all right, and after reprogramming with the GUI, it should start working again.


Reconnecting the keyboard should help as well.

Komar,

do you have a link to the UI github?

Cheers,

Here it is: https://github.com/komar007/ukbdc_gui
You can see that some classes are production-ready and others are crap;)
So the next release will be mainly code cleanup. The bugs are mainly because of how bad this code is, so I'm basically rewriting it from scratch class by class now.
That's why please don't do too much on those ugly classes or you'll have a hard time merging in later.
Title: Re: GH60 prototype betatesting
Post by: OrangeJewce on Fri, 15 March 2013, 16:57:49
Quote from: komar007 on Fri, 15 March 2013, 16:53:05
Quote from: OrangeJewce on Fri, 15 March 2013, 16:44:22
Quote from: komar007 on Fri, 15 March 2013, 12:17:22
Quote from: Glissant on Fri, 15 March 2013, 11:35:14
I'm not sure if it's worth mentioning, but I will anyway.
My GH60 had suddenly lost it's layout during the night or something. I am 100% sure it was working before I went to bed, but when I woke up and started my computer from standby it no longer responded to input.
I had flashed the firmware from my ubuntu virtualbox and also added the layout from the same virtualbox. For some reason I was unable to reapply or add a new layout as my system didn't recognize the keyboard.
I know this is virtually useless information as I have no data to back it up, but I am willing to test some stuff out later today if anybody needs/wants me to; that way I can see if I can replicate the difficulties I had.

I'm currently testing hasu's firmware to see if I can work with it, but so far it's a little too much to learn when it comes to making my own layouts.

Anybody have any layouts they would like to share for hasu's firmware? I'll search in the different gh60 threads, but I thought I should ask at the same time.

There is a bug in my firmware which causes it to stop sending keys occasionally.
I hope I'll fix it soon.
If the computer didn't recognize it at all, that's weird... It should see it all right, and after reprogramming with the GUI, it should start working again.


Reconnecting the keyboard should help as well.

Komar,

do you have a link to the UI github?

Cheers,

Here it is: https://github.com/komar007/ukbdc_gui
You can see that some classes are production-ready and others are crap;)
So the next release will be mainly code cleanup. The bugs are mainly because of how bad this code is, so I'm basically rewriting it from scratch class by class now.
That's why please don't do too much on those ugly classes or you'll have a hard time merging in later.

How would you like me to proceed given this information Komar?

Cheers,
Title: Re: GH60 prototype betatesting
Post by: komar007 on Sat, 16 March 2013, 02:13:35
Quote from: OrangeJewce on Fri, 15 March 2013, 16:57:49
How would you like me to proceed given this information Komar?

Cheers,
You can do whatever you want, just bear in mind this will code will be changing a lot soon.
If you have any questions concerning the code, just drop me a PM.

Quote from: Glissant on Fri, 15 March 2013, 11:35:14
I'm not sure if it's worth mentioning, but I will anyway.
My GH60 had suddenly lost it's layout during the night or something. I am 100% sure it was working before I went to bed, but when I woke up and started my computer from standby it no longer responded to input.
I had flashed the firmware from my ubuntu virtualbox and also added the layout from the same virtualbox. For some reason I was unable to reapply or add a new layout as my system didn't recognize the keyboard.
I know this is virtually useless information as I have no data to back it up, but I am willing to test some stuff out later today if anybody needs/wants me to; that way I can see if I can replicate the difficulties I had.

I'm currently testing hasu's firmware to see if I can work with it, but so far it's a little too much to learn when it comes to making my own layouts.

Anybody have any layouts they would like to share for hasu's firmware? I'll search in the different gh60 threads, but I thought I should ask at the same time.


Edit: Just saw keymap.c . :)) Well at least I am slowly but surely figuring everything out.

I just found the bug. I didn't zero a malloc'ed area:P


EDIT: I updated the op with the new version with the bug fixed. I also added a version preprogrammed with layout, so that you can test on systems where the GUI doesn't work yet. Link: ukbdc_gh60-0.2_rc2_std_layout.hex  (http://geekhack.org/index.php?action=dlattach;topic=37570.0;attach=15860)
Title: Re: GH60 prototype betatesting
Post by: hasu on Sat, 16 March 2013, 06:19:24
I tried new v0.2 feature PWM controled Caps Lock LED and it really works like charm, haha. I love it!
Title: Re: GH60 prototype betatesting
Post by: komar007 on Sat, 16 March 2013, 07:34:55
Thanks;)
Title: Re: GH60 prototype betatesting
Post by: Glissant on Sat, 16 March 2013, 09:09:35
Ahhh. That's more like it. I finally got my raspberry pi set up on my network. That way I can now just connect my Gh60 board to it when I want to program my layout.

Excellent work, komar :) .

On that note, I am unsure if you have gotten any error reports from what happens in win8 and winxp.


This is from win8, but the error is the same under a virtualbox guest winxp.
Code: [Select]

Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python33\lib\tkinter\__init__.py", line 1442, in __call__
    return self.func(*args)
  File "D:\GH60\ukbdc_gui\gui.py", line 757, in <lambda>
    command = lambda: command("program"),
  File "D:\GH60\ukbdc_gui\gui.py", line 664, in on_menu_action
    u.attach()
  File "D:\GH60\ukbdc_gui\ukbdc_lib\ukbdc.py", line 124, in attach
    idProduct = self.productId
  File "D:\GH60\ukbdc_gui\usb\core.py", line 846, in find
    raise ValueError('No backend available')
ValueError: No backend available

Just tell me if I should stop talking and just keeping stuff to myself xD.




I have a couple of questions too.
Can I program GH60 with komar's firmware to have fn-lock. And if so, can I make it turn the LED on if fn is locked to a specific layer?
Title: Re: GH60 prototype betatesting
Post by: komar007 on Sat, 16 March 2013, 09:19:45
Quote from: Glissant on Sat, 16 March 2013, 09:09:35
Ahhh. That's more like it. I finally got my raspberry pi set up on my network. That way I can now just connect my Gh60 board to it when I want to program my layout.

Excellent work, komar :) .

On that note, I am unsure if you have gotten any error reports from what happens in win8 and winxp.


This is from win8, but the error is the same under a virtualbox guest winxp.
Code: [Select]

Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python33\lib\tkinter\__init__.py", line 1442, in __call__
    return self.func(*args)
  File "D:\GH60\ukbdc_gui\gui.py", line 757, in <lambda>
    command = lambda: command("program"),
  File "D:\GH60\ukbdc_gui\gui.py", line 664, in on_menu_action
    u.attach()
  File "D:\GH60\ukbdc_gui\ukbdc_lib\ukbdc.py", line 124, in attach
    idProduct = self.productId
  File "D:\GH60\ukbdc_gui\usb\core.py", line 846, in find
    raise ValueError('No backend available')
ValueError: No backend available
Thanks, unfortunately I know what happens, I just don't know why, but I hope with a few people already looking into the code, we'll manage to fix that.

Quote from: Glissant on Sat, 16 March 2013, 09:09:35
Just tell me if I should stop talking and just keeping stuff to myself xD.

I have a couple of questions too.
Can I program GH60 with komar's firmware to have fn-lock. And if so, can I make it turn the LED on if fn is locked to a specific layer?
Certainly do talk. This is beta testing!

Do I understand correctly that fn-lock means you press fn, the layer changes, and then press again to change back?
If so, you can do it. Just set key press action to go to another layer, and on that another layer set a key press action to go to the first layer (as opposed to key release, which is how most keyboards with layers work).
Currently there's no LED control except behaving as caps lock though.
Title: Re: GH60 prototype betatesting
Post by: jdcarpe on Sat, 16 March 2013, 09:34:06
We needed Glissant doing beta testing from the beginning!

I didn't even think about using my Raspberry Pi to program the GH60 using the gui...
Title: Re: GH60 prototype betatesting
Post by: Glissant on Sat, 16 March 2013, 09:38:42
Ah yes, of course. That makes perfect sense when I'm looking at it. I was just stuck on the Poker way of doing it where the combination fn+space changes the layer so that the rshift, rgui, menu and rctrl are arrow keys. But the way that you are proposing will work just fine.
I'm hoping we might be able to include LED control in the future :) .

Sorry to hear that the issue is being a pain in your behind. I was searching google for a while trying to see if I could help, but I'm useless as nothing I tried worked. Well at least I can upload layouts in linux =D.


J.D. I'm just hoping I won't add too much nonsense or misinformation because of my inexperience :).
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Sat, 16 March 2013, 21:07:31
I just want to scream and smash this right now due to how ridiculously frustrating dealing with the firmware is to someone that only knows C as a letter. I really wanted to update with the functioning wake from sleep, but apparently a LOT of other things were changed too and the keymap I had before won't work. I just get a bunch of errors about keymap_key_to_keycode and undefined overlay_bit. I have no idea what the f*ck it is talking about. I don't think the older version I used before had any of whatever that is. I didn't use whatever those are before, so why the f*ck do I have to 'define' them now when I have no idea what it is and there is no reference to them anywhere in my keymap.c?
I am tired of trying to understand C and I have no interest in learning anything about it. Will someone who understands this stuff please just make update firmware for me with my desired layout?
Code: [Select]
     /* Layer 0: qwerty */
    KEYMAP_ANSI(
        ESC, 1,   2,   3,   4,   5,   6,   7,   8,   9,   0,   MINS,EQL, BSPC, \
        TAB, Q,   W,   E,   R,   T,   Y,   U,   I,   O,   P,   LBRC,RBRC,BSLS, \
        CAPS,A,   S,   D,   F,   G,   H,   J,   K,   L,   SCLN,QUOT,     ENT,  \
        LSFT,Z,   X,   C,   V,   B,   N,   M,   COMM,DOT, SLSH,          RSFT, \
        LCTL,LALT,NO,          SPC,                     FN0, RGUI,APP, RCTL),
    /* Layer 1: GH60 Fn */
    KEYMAP_ANSI(
GRV, F1,  F2,  F3,  F4,  F5,  F6,  F7,  F8,  F9,  F10, F11, F12, TRNS, \
TRNS,FN1, UP,  TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,PSCR,PAUS,VOLU,VOLD,MUTE, \
TRNS,LEFT,DOWN,RGHT,TRNS,TRNS,TRNS,TRNS,TRNS,INS,HOME, PGUP,      TRNS, \
TRNS,TRNS, TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,DEL,END,PGDN,           TRNS, \
TRNS,TRNS,NO,          TRNS,                     FN0, TRNS,TRNS,TRNS)
};
Title: Re: GH60 prototype betatesting
Post by: OrangeJewce on Sat, 16 March 2013, 21:09:27
Quote from: IvanIvanovich on Sat, 16 March 2013, 21:07:31
I just want to scream and smash this right now due to how ridiculously frustrating dealing with the firmware is to someone that only knows C as a letter. I really wanted to update with the functioning wake from sleep, but apparently a LOT of other things were changed too and the keymap I had before won't work. I just get a bunch of errors about keymap_key_to_keycode and undefined overlay_bit. I have no idea what the f*ck it is talking about. I don't think the older version I used before had any of whatever that is. I didn't use whatever those are before, so why the f*ck do I have to 'define' them now when I have no idea what it is and there is no reference to them anywhere in my keymap.c?
I am tired of trying to understand C and I have no interest in learning anything about it. Will someone who understands this stuff please just make update firmware for me with my desired layout?
Code: [Select]
     /* Layer 0: qwerty */
    KEYMAP_ANSI(
        ESC, 1,   2,   3,   4,   5,   6,   7,   8,   9,   0,   MINS,EQL, BSPC, \
        TAB, Q,   W,   E,   R,   T,   Y,   U,   I,   O,   P,   LBRC,RBRC,BSLS, \
        CAPS,A,   S,   D,   F,   G,   H,   J,   K,   L,   SCLN,QUOT,     ENT,  \
        LSFT,Z,   X,   C,   V,   B,   N,   M,   COMM,DOT, SLSH,          RSFT, \
        LCTL,LALT,NO,          SPC,                     FN0, RGUI,APP, RCTL),
    /* Layer 1: GH60 Fn */
    KEYMAP_ANSI(
GRV, F1,  F2,  F3,  F4,  F5,  F6,  F7,  F8,  F9,  F10, F11, F12, TRNS, \
TRNS,FN1, UP,  TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,PSCR,PAUS,VOLU,VOLD,MUTE, \
TRNS,LEFT,DOWN,RGHT,TRNS,TRNS,TRNS,TRNS,TRNS,INS,HOME, PGUP,      TRNS, \
TRNS,TRNS, TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,DEL,END,PGDN,           TRNS, \
TRNS,TRNS,NO,          TRNS,                     FN0, TRNS,TRNS,TRNS)
};


lysol,

     Does the UI not work for you?

Cheers,
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Sat, 16 March 2013, 21:27:35
No, I am on Windows 7 x64 and don't have access to anything else and have no interest setting up a linux. I was able to trial and error though editing the text before to make something that worked with hasu files but after the new changes I don't get it. I really don't know anything about this stuff.
Title: Re: GH60 prototype betatesting
Post by: OrangeJewce on Sat, 16 March 2013, 21:33:00
Quote from: IvanIvanovich on Sat, 16 March 2013, 21:27:35
No, I am on Windows 7 x64 and don't have access to anything else and have no interest setting up a linux. I was able to trial and error though editing the text before to make something that worked with hasu files but after the new changes I don't get it. I really don't know anything about this stuff.

I hear ya. I've been reading up on the UI code. Unfortunately tk is a maze. I'll have to talk to my other python friend and see if we can figure out what is / isn't working for Windows.

Komar:

from tkinter import *

C'mon man! >.<" Cut a brother some slack :P

Cheers,
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Sat, 16 March 2013, 21:44:00
Success, it works now with resume from sleep. I am satisfied with it and I am probably done tinkering with it now. Here is what I had to do to get it to work... I scrapped the old file I was using from before and copy pasta into the new keymap.c replacing the 'funky' layout with mine.

Code: [Select]
/*
Copyright 2012,2013 Jun Wako <wakojun@gmail.com>

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 2 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program.  If not, see <http://www.gnu.org/licenses/>.
*/
#include <stdint.h>
#include <stdbool.h>
#include <avr/pgmspace.h>
#include "keycode.h"
#include "action.h"
#include "action_macro.h"
#include "layer_switch.h"
#include "report.h"
#include "host.h"
#include "print.h"
#include "debug.h"
#include "keymap.h"


/* GH60 keymap definition macro
 * K2C, K31 and  K3C are extra keys for ISO
 */
#define KEYMAP( \
    K00, K01, K02, K03, K04, K05, K06, K07, K08, K09, K0A, K0B, K0C, K0D, \
    K10, K11, K12, K13, K14, K15, K16, K17, K18, K19, K1A, K1B, K1C, K1D, \
    K20, K21, K22, K23, K24, K25, K26, K27, K28, K29, K2A, K2B, K2C, K2D, \
    K30, K31, K32, K33, K34, K35, K36, K37, K38, K39, K3A, K3B, K3C, K3D, \
    K40, K41, K42,           K45,                     K4A, K4B, K4C, K4D  \
) { \
    { KC_##K00, KC_##K01, KC_##K02, KC_##K03, KC_##K04, KC_##K05, KC_##K06, KC_##K07, KC_##K08, KC_##K09, KC_##K0A, KC_##K0B, KC_##K0C, KC_##K0D }, \
    { KC_##K10, KC_##K11, KC_##K12, KC_##K13, KC_##K14, KC_##K15, KC_##K16, KC_##K17, KC_##K18, KC_##K19, KC_##K1A, KC_##K1B, KC_##K1C, KC_##K1D }, \
    { KC_##K20, KC_##K21, KC_##K22, KC_##K23, KC_##K24, KC_##K25, KC_##K26, KC_##K27, KC_##K28, KC_##K29, KC_##K2A, KC_##K2B, KC_##K2C, KC_##K2D }, \
    { KC_##K30, KC_##K31, KC_##K32, KC_##K33, KC_##K34, KC_##K35, KC_##K36, KC_##K37, KC_##K38, KC_##K39, KC_##K3A, KC_##K3B, KC_##K3C, KC_##K3D }, \
    { KC_##K40, KC_##K41, KC_##K42, KC_NO,    KC_NO,    KC_##K45, KC_NO,    KC_NO,    KC_NO,    KC_NO,    KC_##K4A, KC_##K4B, KC_##K4C, KC_##K4D }  \
}

/* ANSI valiant. No extra keys for ISO */
#define KEYMAP_ANSI( \
    K00, K01, K02, K03, K04, K05, K06, K07, K08, K09, K0A, K0B, K0C, K0D, \
    K10, K11, K12, K13, K14, K15, K16, K17, K18, K19, K1A, K1B, K1C, K1D, \
    K20, K21, K22, K23, K24, K25, K26, K27, K28, K29, K2A, K2B,      K2D, \
    K30, K32, K33, K34, K35, K36, K37, K38, K39, K3A, K3B,           K3D, \
    K40, K41, K42,           K45,                     K4A, K4B, K4C, K4D  \
) KEYMAP( \
    K00, K01, K02, K03, K04, K05, K06, K07, K08, K09, K0A, K0B, K0C, K0D, \
    K10, K11, K12, K13, K14, K15, K16, K17, K18, K19, K1A, K1B, K1C, K1D, \
    K20, K21, K22, K23, K24, K25, K26, K27, K28, K29, K2A, K2B, NO,  K2D, \
    K30, NO,  K32, K33, K34, K35, K36, K37, K38, K39, K3A, K3B, NO,  K3D, \
    K40, K41, K42,           K45,                     K4A, K4B, K4C, K4D  \
)


#if defined(KEYMAP_PLAIN)
    #include "keymap_plain.h"
#elif defined(KEYMAP_POKER)
    #include "keymap_poker.h"
#elif defined(KEYMAP_POKER_SET)
    #include "keymap_poker_set.h"
#elif defined(KEYMAP_POKER_BIT)
    #include "keymap_poker_bit.h"
#else
static const uint8_t PROGMEM keymaps[][MATRIX_ROWS][MATRIX_COLS] = {
    /*
     * GH60
     */
    /* Keymap 0: Default Layer
     */
    KEYMAP_ANSI(
        ESC, 1,   2,   3,   4,   5,   6,   7,   8,   9,   0,   MINS,EQL, BSPC, \
        TAB, Q,   W,   E,   R,   T,   Y,   U,   I,   O,   P,   LBRC,RBRC,BSLS, \
        CAPS,A,   S,   D,   F,   G,   H,   J,   K,   L,   SCLN,QUOT,     ENT,  \
        LSFT,Z,   X,   C,   V,   B,   N,   M,   COMM,DOT, SLSH,          RSFT, \
        LCTL,LALT,NO,          SPC,                     FN0, RGUI,APP, RCTL),
    /* Overlay 1: Fn mode
     */
    KEYMAP_ANSI(
GRV, F1,  F2,  F3,  F4,  F5,  F6,  F7,  F8,  F9,  F10, F11, F12, TRNS, \
TRNS,FN1, UP,  TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,PSCR,PAUS,VOLU,VOLD,MUTE, \
TRNS,LEFT,DOWN,RGHT,TRNS,TRNS,TRNS,TRNS,TRNS,INS,HOME, PGUP,      TRNS, \
TRNS,TRNS, TRNS,TRNS,TRNS,TRNS,TRNS,TRNS,DEL,END,PGDN,           TRNS, \
TRNS,TRNS,NO,          TRNS,                     FN0, TRNS,TRNS,TRNS)
};

static const uint8_t PROGMEM overlays[][MATRIX_ROWS][MATRIX_COLS] = {};

/*
 * Fn action definition
 */
static const uint16_t PROGMEM fn_actions[] = {
    [0] = ACTION_KEYMAP_MOMENTARY(1),
};
#endif



#define KEYMAPS_SIZE    (sizeof(keymaps) / sizeof(keymaps[0]))
#define OVERLAYS_SIZE   (sizeof(overlays) / sizeof(overlays[0]))
#define FN_ACTIONS_SIZE (sizeof(fn_actions) / sizeof(fn_actions[0]))

/* translates key to keycode */
uint8_t keymap_key_to_keycode(uint8_t layer, key_t key)
{
    /* Overlay: 16-31(OVERLAY_BIT(0x10) | overlay_layer) */
    if (layer & OVERLAY_BIT) {
        layer &= OVERLAY_MASK;
        if (layer < OVERLAYS_SIZE) {
            return pgm_read_byte(&overlays[(layer)][(key.row)][(key.col)]);
        } else {
            // XXX: this may cuaes bootlaoder_jump incositent fail.
            //debug("key_to_keycode: overlay "); debug_dec(layer); debug(" is invalid.\n");
            return KC_TRANSPARENT;
        }
    }
    /* Keymap: 0-15 */
    else {
        if (layer < KEYMAPS_SIZE) {
            return pgm_read_byte(&keymaps[(layer)][(key.row)][(key.col)]);
        } else {
            // XXX: this may cuaes bootlaoder_jump incositent fail.
            //debug("key_to_keycode: base "); debug_dec(layer); debug(" is invalid.\n");
            // fall back to layer 0
            return pgm_read_byte(&keymaps[0][(key.row)][(key.col)]);
        }
    }
}

/* translates Fn keycode to action */
action_t keymap_fn_to_action(uint8_t keycode)
{
    action_t action;
    if (FN_INDEX(keycode) < FN_ACTIONS_SIZE) {
        action.code = pgm_read_word(&fn_actions[FN_INDEX(keycode)]);
    } else {
        action.code = ACTION_NO;
    }
    return action;
}
Title: Re: GH60 prototype betatesting
Post by: komar007 on Sun, 17 March 2013, 02:29:57
Quote from: OrangeJewce on Sat, 16 March 2013, 21:33:00
Quote from: IvanIvanovich on Sat, 16 March 2013, 21:27:35
No, I am on Windows 7 x64 and don't have access to anything else and have no interest setting up a linux. I was able to trial and error though editing the text before to make something that worked with hasu files but after the new changes I don't get it. I really don't know anything about this stuff.

I hear ya. I've been reading up on the UI code. Unfortunately tk is a maze. I'll have to talk to my other python friend and see if we can figure out what is / isn't working for Windows.

Komar:

from tkinter import *

C'mon man! >.<" Cut a brother some slack :p

Cheers,

There are no problems with tkinter on windows. Everything currently works, it's only a problem with the libusb/pyusb code.
Please write to me if you have any questions.
Title: Re: GH60 prototype betatesting
Post by: SmallFry on Sun, 17 March 2013, 03:06:33
Wait LibUSB is 32bit only isn't it?
Title: Re: GH60 prototype betatesting
Post by: OrangeJewce on Sun, 17 March 2013, 07:16:34
Quote from: komar007 on Sun, 17 March 2013, 02:29:57
Quote from: OrangeJewce on Sat, 16 March 2013, 21:33:00
Quote from: IvanIvanovich on Sat, 16 March 2013, 21:27:35
No, I am on Windows 7 x64 and don't have access to anything else and have no interest setting up a linux. I was able to trial and error though editing the text before to make something that worked with hasu files but after the new changes I don't get it. I really don't know anything about this stuff.

I hear ya. I've been reading up on the UI code. Unfortunately tk is a maze. I'll have to talk to my other python friend and see if we can figure out what is / isn't working for Windows.

Komar:

from tkinter import *

C'mon man! >.<" Cut a brother some slack :p

Cheers,

There are no problems with tkinter on windows. Everything currently works, it's only a problem with the libusb/pyusb code.
Please write to me if you have any questions.

Komar,

I'm sorry mate, Just giving you a hard time. I'm just working through the gui.py file little by little and I'll pm you with qs.

Cheers,
Title: Re: GH60 prototype betatesting
Post by: OrangeJewce on Sun, 17 March 2013, 07:16:56
Quote from: SmallFry on Sun, 17 March 2013, 03:06:33
Wait LibUSB is 32bit only isn't it?

That shouldn't be a problem on win7/8.

Cheers,
Title: Re: GH60 prototype betatesting
Post by: hasu on Sun, 17 March 2013, 08:11:17
I ran across this issue of python. Looks like this is our problem and PyUSB doesn't work on Windows with Python3.3 but it works with Python 2. GUI script seems to depend on some features of Python3. I couldn't run it with Python2 because I don't know about even syntax of the language. I live in very country of red jewel, you know :)

Someone can port komar's scripts to Python 2 and see if it works on Windows?

Title: Re: GH60 prototype betatesting
Post by: hasu on Sun, 17 March 2013, 08:12:29
Sorry for double post :(

The issue is this.
https://github.com/walac/pyusb/issues/14
Title: Re: GH60 prototype betatesting
Post by: komar007 on Sun, 17 March 2013, 08:58:20
Quote from: hasu on Sun, 17 March 2013, 08:12:29
Sorry for double post :(

The issue is this.
https://github.com/walac/pyusb/issues/14 (https://github.com/walac/pyusb/issues/14)

Good job. Thanks!
I'll work around that bug.


Ok, so I got down to debugging and went deep into pyusb, and there are a couple of problems which cause it.
1. The bug in Python mentioned by hasu, I worked around it by adding the ".dll" extension to library's name
2. when I fixed it, python started screaming about an undefined variable inside pyusb, and that was indeed an error in pyusb, so I fixed it
3. after that, it couldn't retrieve the interface descriptor for interface 1, claiming that bNumInterfaces was 1, which is in fact 2...
4. now I have no idea why this is so or where the bug is, so I just removed that code, since I needed it only to get wMaxPacketSize and hardcoded it as 64:)


Please test if it works now.
[attachurl=1]
Title: Re: GH60 prototype betatesting
Post by: Glissant on Sun, 17 March 2013, 11:45:24

Really glad you are making some progress with the firmware. I am currently trying it, and this is what happens when I try to send the layout to the keyboard in windows 8.
Code: [Select]
Exception in Tkinter callback
Traceback (most recent call last):
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\ukbdc_lib\ukbdc.py", line 129, in attac
h
    usb.util.claim_interface(self.dev, self.interface)
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\usb\util.py", line 191, in claim_interf
ace
    device._ctx.managed_claim_interface(device, interface)
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\usb\core.py", line 112, in managed_clai
m_interface
    self.backend.claim_interface(self.handle, i)
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\usb\backend\libusb01.py", line 462, in
claim_interface
    _check(_lib.usb_claim_interface(dev_handle, intf))
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\usb\backend\libusb01.py", line 384, in
_check
    raise USBError(errmsg, ret)
usb.core.USBError: [Errno None] b'usb_claim_interface: could not claim interface
 1, invalid configuration 0'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Python33\lib\tkinter\__init__.py", line 1442, in __call__
    return self.func(*args)
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\gui.py", line 757, in <lambda>
    command = lambda: command("program"),
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\gui.py", line 664, in on_menu_action
    u.attach()
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\ukbdc_lib\ukbdc.py", line 131, in attac
h
    self.dev.detach_kernel_driver(self.interface)
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\usb\core.py", line 712, in detach_kerne
l_driver
    self._ctx.backend.detach_kernel_driver(self._ctx.handle, interface)
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\usb\backend\libusb01.py", line 546, in
detach_kernel_driver
    _check(_lib.usb_detach_kernel_driver_np(dev_handle, intf))
  File "C:\Python33\lib\ctypes\__init__.py", line 366, in __getattr__
    func = self.__getitem__(name)
  File "C:\Python33\lib\ctypes\__init__.py", line 371, in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
AttributeError: function 'usb_detach_kernel_driver_np' not found
Title: Re: GH60 prototype betatesting
Post by: IvanIvanovich on Sun, 17 March 2013, 11:55:41
I can get the gui tool to work, so that portion seem ok now. For some key, you can just press a character and it can assign it this way which is good and easy. For others you need to enter scancode specifically for all the non character key. Including a table of these with the package would be a good thing so don't have to go hunting for them somewhere. Also confused of how to assign a Fn key here.
Also get same as Glissant when try to move past the assign stage to send to keyboard.
Title: Re: GH60 prototype betatesting
Post by: komar007 on Sun, 17 March 2013, 13:20:41
Quote from: Glissant on Sun, 17 March 2013, 11:45:24

Really glad you are making some progress with the firmware. I am currently trying it, and this is what happens when I try to send the layout to the keyboard in windows 8.
Code: [Select]
Exception in Tkinter callback
Traceback (most recent call last):
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\ukbdc_lib\ukbdc.py", line 129, in attac
h
    usb.util.claim_interface(self.dev, self.interface)
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\usb\util.py", line 191, in claim_interf
ace
    device._ctx.managed_claim_interface(device, interface)
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\usb\core.py", line 112, in managed_clai
m_interface
    self.backend.claim_interface(self.handle, i)
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\usb\backend\libusb01.py", line 462, in
claim_interface
    _check(_lib.usb_claim_interface(dev_handle, intf))
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\usb\backend\libusb01.py", line 384, in
_check
    raise USBError(errmsg, ret)
usb.core.USBError: [Errno None] b'usb_claim_interface: could not claim interface
 1, invalid configuration 0'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Python33\lib\tkinter\__init__.py", line 1442, in __call__
    return self.func(*args)
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\gui.py", line 757, in <lambda>
    command = lambda: command("program"),
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\gui.py", line 664, in on_menu_action
    u.attach()
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\ukbdc_lib\ukbdc.py", line 131, in attac
h
    self.dev.detach_kernel_driver(self.interface)
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\usb\core.py", line 712, in detach_kerne
l_driver
    self._ctx.backend.detach_kernel_driver(self._ctx.handle, interface)
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\usb\backend\libusb01.py", line 546, in
detach_kernel_driver
    _check(_lib.usb_detach_kernel_driver_np(dev_handle, intf))
  File "C:\Python33\lib\ctypes\__init__.py", line 366, in __getattr__
    func = self.__getitem__(name)
  File "C:\Python33\lib\ctypes\__init__.py", line 371, in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
AttributeError: function 'usb_detach_kernel_driver_np' not found
Thanks for info. I've tested it on windows 7, and it worked, so apparently there's still something with windows 8, but I've read that libusb is not supported on this system yet.

Could you try and change line 131 of /ukbdc_lib/ukbdc.py from:
self.dev.detach_kernel_driver(self.interface)
to:
pass
and see what happens?


Quote from: IvanIvanovich on Sun, 17 March 2013, 11:55:41
I can get the gui tool to work, so that portion seem ok now. For some key, you can just press a character and it can assign it this way which is good and easy. For others you need to enter scancode specifically for all the non character key. Including a table of these with the package would be a good thing so don't have to go hunting for them somewhere. Also confused of how to assign a Fn key here.
Also get same as Glissant when try to move past the assign stage to send to keyboard.
Good idea. Ideally, we should have a list or grid of most common scancodes to choose from by clicking. For now you can see all available scancodes and their names in /ukbdc_lib/mnemonics.py.
What do you mean by Fn? A key which changes layer when pressed?
You just put 0x00 as scancode, so that it doesn't send anything (this is a bug, you should be able to leave it empty) and assign a press action that goes to another layer. Then on that layer set that same key to go back to layer 0 (release action).
You can use layer inheritance for this. Define layer 0, then set layer 1 to inherit from layer 0, and only change the keys that are different than on layer 0.
Title: Re: Re: GH60 prototype betatesting
Post by: SmallFry on Sun, 17 March 2013, 15:36:40
Quote from: OrangeJewce on Sun, 17 March 2013, 07:16:56
Quote from: SmallFry on Sun, 17 March 2013, 03:06:33
Wait LibUSB is 32bit only isn't it?

That shouldn't be a problem on win7/8.

Cheers,
Don't mind me then:)
Title: Re: GH60 prototype betatesting
Post by: Glissant on Sun, 17 March 2013, 15:51:03
I wish I knew more code so I could help out more than just post error messages xD.
This is what happens after 131 has been changed.
Code: [Select]
Exception in Tkinter callback
Traceback (most recent call last):
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\usb\core.py", line 178, in get_endpoint
_type
    return self._ep_type_map[key]
KeyError: (3, 0, 0)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Python33\lib\tkinter\__init__.py", line 1442, in __call__
    return self.func(*args)
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\gui.py", line 757, in <lambda>
    command = lambda: command("program"),
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\gui.py", line 664, in on_menu_action
    u.attach()
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\ukbdc_lib\ukbdc.py", line 140, in attac
h
    self.reset()
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\ukbdc_lib\ukbdc.py", line 166, in reset

    self.write_packet(Reset())
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\ukbdc_lib\ukbdc.py", line 151, in write
_packet
    self.dev.write(self.ep_out, bytes(p), timeout = self.tm_out)
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\usb\core.py", line 611, in write
    fn = fn_map[self._ctx.get_endpoint_type(self, endpoint, intf)]
  File "D:\GH60\ukbdc_gui_win7\ukbdc_gui\usb\core.py", line 181, in get_endpoint
_type
    etype = util.endpoint_type(e.bmAttributes)
AttributeError: 'NoneType' object has no attribute 'bmAttributes'


Edit:


By the way! Is it possible to have two or three switches instead of the right shift? I hardly use the right shift, and thought I might enjoy putting more switches there, but I was unsure if I would be able to make them work or not. And if it's possible I was also thinking about putting two switches instead of the left shift too. Hmmmm.
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: komar007 on Mon, 18 March 2013, 08:21:19
You can have either right shift, or short shift + one button, either to the left or to the right of shift. You can't have 3 though, since the 2 footprints on the sides of shift are connected to the same row and column.
On the left side you can have either just shift or short shift and a button to the right of it.
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: komar007 on Mon, 18 March 2013, 08:57:49
Please, anyone with windows 7 or older wants to test?
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: Nask on Mon, 18 March 2013, 09:02:28
Yeah sure, I'm on Windows 8 Pro, if I can help, :)
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: komar007 on Mon, 18 March 2013, 09:03:47
But I need someone with the GH60 prototype...:/
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: Nask on Mon, 18 March 2013, 09:05:40
Hehe, I knew I should have bought one.
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: hasu on Mon, 18 March 2013, 09:19:41
I got same error on Windows7 64bit as Glissant when I tried to program the device.

But I got different error with code change of ukbdc_lib/ukbdc.py.
Code: [Select]
Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python33\lib\tkinter\__init__.py", line 1442, in __call__
    return self.func(*args)
  File "C:\Users\noname\Desktop\ukbdc_gui\gui.py", line 757, in <lambda>
    command = lambda: command("program"),
  File "C:\Users\noname\Desktop\ukbdc_gui\gui.py", line 664, in on_menu_action
    u.attach()
  File "C:\Users\noname\Desktop\ukbdc_gui\ukbdc_lib\ukbdc.py", line 132, in atta
ch
    config = self.dev[0]
  File "C:\Users\noname\Desktop\ukbdc_gui\usb\core.py", line 727, in __getitem__

    return Configuration(self, index)
  File "C:\Users\noname\Desktop\ukbdc_gui\usb\core.py", line 419, in __init__
    configuration
  File "C:\Users\noname\Desktop\ukbdc_gui\usb\backend\libusb01.py", line 408, in
 get_configuration_descriptor
    return dev.config[config]
ValueError: NULL pointer access
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: jdcarpe on Mon, 18 March 2013, 09:42:57
Quote from: komar007 on Mon, 18 March 2013, 08:57:49
Please, anyone with windows 7 or older wants to test?

I will test it. I have Win7 32-bit

Code: [Select]
Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Users\Jonathan Carpenter\Downloads\ukbdc_gui\ukbdc_lib\ukbdc.py", lin
e 129, in attach
    usb.util.claim_interface(self.dev, self.interface)
  File "C:\Users\Jonathan Carpenter\Downloads\ukbdc_gui\usb\util.py", line 191,
in claim_interface
    device._ctx.managed_claim_interface(device, interface)
  File "C:\Users\Jonathan Carpenter\Downloads\ukbdc_gui\usb\core.py", line 112,
in managed_claim_interface
    self.backend.claim_interface(self.handle, i)
  File "C:\Users\Jonathan Carpenter\Downloads\ukbdc_gui\usb\backend\libusb01.py"
, line 462, in claim_interface
    _check(_lib.usb_claim_interface(dev_handle, intf))
  File "C:\Users\Jonathan Carpenter\Downloads\ukbdc_gui\usb\backend\libusb01.py"
, line 384, in _check
    raise USBError(errmsg, ret)
usb.core.USBError: [Errno None] b'usb_claim_interface: could not claim interface
 1, invalid configuration 0'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\Python33\lib\tkinter\__init__.py", line 1442, in __call__
    return self.func(*args)
  File "C:\Users\Jonathan Carpenter\Downloads\ukbdc_gui\gui.py", line 757, in <l
ambda>
    command = lambda: command("program"),
  File "C:\Users\Jonathan Carpenter\Downloads\ukbdc_gui\gui.py", line 664, in on
_menu_action
    u.attach()
  File "C:\Users\Jonathan Carpenter\Downloads\ukbdc_gui\ukbdc_lib\ukbdc.py", lin
e 131, in attach
    self.dev.detach_kernel_driver(self.interface)
  File "C:\Users\Jonathan Carpenter\Downloads\ukbdc_gui\usb\core.py", line 712,
in detach_kernel_driver
    self._ctx.backend.detach_kernel_driver(self._ctx.handle, interface)
  File "C:\Users\Jonathan Carpenter\Downloads\ukbdc_gui\usb\backend\libusb01.py"
, line 546, in detach_kernel_driver
    _check(_lib.usb_detach_kernel_driver_np(dev_handle, intf))
  File "C:\Python33\lib\ctypes\__init__.py", line 366, in __getattr__
    func = self.__getitem__(name)
  File "C:\Python33\lib\ctypes\__init__.py", line 371, in __getitem__
    func = self._FuncPtr((name_or_ordinal, self))
AttributeError: function 'usb_detach_kernel_driver_np' not found

Okay, changed line 131 like you asked Glissant to "pass"

and got the same error as hasu got

Code: [Select]
Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python33\lib\tkinter\__init__.py", line 1442, in __call__
    return self.func(*args)
  File "C:\Users\Jonathan Carpenter\Downloads\ukbdc_gui\gui.py", line 757, in <l
ambda>
    command = lambda: command("program"),
  File "C:\Users\Jonathan Carpenter\Downloads\ukbdc_gui\gui.py", line 664, in on
_menu_action
    u.attach()
  File "C:\Users\Jonathan Carpenter\Downloads\ukbdc_gui\ukbdc_lib\ukbdc.py", lin
e 132, in attach
    config = self.dev[0]
  File "C:\Users\Jonathan Carpenter\Downloads\ukbdc_gui\usb\core.py", line 727,
in __getitem__
    return Configuration(self, index)
  File "C:\Users\Jonathan Carpenter\Downloads\ukbdc_gui\usb\core.py", line 419,
in __init__
    configuration
  File "C:\Users\Jonathan Carpenter\Downloads\ukbdc_gui\usb\backend\libusb01.py"
, line 408, in get_configuration_descriptor
    return dev.config[config]
ValueError: NULL pointer access
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: komar007 on Mon, 18 March 2013, 10:11:09
Come on, why are all these errors different? Crazy
It works for me on windows 7 32-bit...
Is GH60 (Interface 1) visible under libusb-win32 devices in Device Manager?


EDIT: okay, I'll download windows 8...
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: jdcarpe on Mon, 18 March 2013, 10:19:58
Quote from: komar007 on Mon, 18 March 2013, 10:11:09
Come on, why are all these errors different? Crazy
It works for me on windows 7 32-bit...
Is GH60 (Interface 1) visible under libusb-win32 devices in Device Manager?


EDIT: okay, I'll download windows 8...

Well, my error code validates hasu's :)

Here's my Device Manager:

(http://i.imgur.com/A1QC146.png)
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: komar007 on Mon, 18 March 2013, 10:22:31
Quote from: jdcarpe on Mon, 18 March 2013, 10:19:58
Quote from: komar007 on Mon, 18 March 2013, 10:11:09
Come on, why are all these errors different? Crazy
It works for me on windows 7 32-bit...
Is GH60 (Interface 1) visible under libusb-win32 devices in Device Manager?


EDIT: okay, I'll download windows 8...

Well, my error code validates hasu's :)

Here's my Device Manager:

Show Image
(http://i.imgur.com/A1QC146.png)


This doesn't seem correct, please run inf-wizard again and reinstall the libusb driver.


You should get something like this:
[attachimg=1]
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: jdcarpe on Mon, 18 March 2013, 10:30:16
Hmmm...reinstalled and got the same result.

(http://i.imgur.com/2taSHD0.png)
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: hasu on Mon, 18 March 2013, 10:30:55
I have GH60 (Interface 1) under LibUSB-Win32 Devices.

(http://i.imgur.com/JKQpHHC.png)
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: jdcarpe on Mon, 18 March 2013, 10:36:18
I have Flip installed, if that matters.
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: komar007 on Mon, 18 March 2013, 10:39:19
I think I have it too. I don't understand how my windows differs from yours...:/
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: Glissant on Mon, 18 March 2013, 12:42:25
I spent some time today trying a couple of libusb fixes that were used for win7, but nothing changed the error messages that I get. I'm still testing the gui in win 8. Interface 1 shows under libusb-win32 devices in device manager.
I will spend some time now testing this stuff on my father's windows seven machine. I'll come back with a response in a bit.


I changed my rshift to a 1x and short shift, so now I am wondering how I can program the new 1x. The rshift is working just fine =). (I really want to do 1.5 - 1 - 1.5 - 7 - 1.5 - 1 - 1.5, but I need a stabilizer wire for my 7x spacebar.
[attach=1]
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: komar007 on Mon, 18 March 2013, 13:06:21

Quote from: Glissant on Mon, 18 March 2013, 12:42:25
I changed my rshift to a 1x and short shift, so now I am wondering how I can program the new 1x. The rshift is working just fine =). (I really want to do 1.5 - 1 - 1.5 - 7 - 1.5 - 1 - 1.5, but I need a stabilizer wire for my 7x spacebar.
(Attachment Link)
You have to change gh60.xml accordingly. Add the key definition for your extra key (the number for this key is 54) - add it where it says "here goes extra \"fn\" key after or befor rshift". You'll also need to change the size of shift (number 55) to 14 x 8. (the units used are 1/8th of the side length of a 1x key)
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: mkawa on Mon, 18 March 2013, 14:35:30
we have a new development volunteer who will looking at and hopefully look at some of these issues in the front-end. his board is on its way to him right now. hopefully he will introduce himself in the thread ;)
Title: GH60 prototype betatesting [Please test the GUI]
Post by: jdcarpe on Mon, 18 March 2013, 14:48:10
Mr. E. Kawa strikes again!
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: komar007 on Mon, 18 March 2013, 16:12:24
I tested the GUI on my dad's Windows 7 64-bit with Python 3.3, both 32-bit and 64-bit and ukbdc firmware version 0.2_rc2 and everything works fine. I can program the layout.
I used the exact package I'm attaching in this post. It doesn't differ from the ones I posted earlier in the USB code, but you can try anyway.
[attachurl=1]


Now I'm getting down to cleaning the code further and implementing new features. I won't be wasting more time on debugging this on a system I have no idea about, mainly because I don't know what else I can do, since it works for me on 3 computers with win7 32-bit, win7 64-bit and winxp. I hope others will come up with some clues. I'm counting on you. ;)


You may also want to look at the first post, I added some tutorials how to make various layouts. I'll be adding more.
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: agodinhost on Mon, 18 March 2013, 17:32:12
windows 7 ultimate here, 64

what should I do to help on the test? I did executed the gui and it launched okay at here - although I don't know what's ready to test ...
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: komar007 on Mon, 18 March 2013, 17:36:45
You need the GH60 board to test it.
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: agodinhost on Mon, 18 March 2013, 17:45:35
I do have the teensy 2.0 here (a compatible board) and a 8x8 matrix keyboard ...
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: komar007 on Mon, 18 March 2013, 17:46:39
Great. Can you program it with the firmware in the first post, version 0.2_rc2 and see if the gui can program an empty layout?
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: Glissant on Mon, 18 March 2013, 17:47:22
Just a tiny update and a question at the same time.
I had no problems uploading a new layout from my dad's win7(64bit enterprise) box.

Setting up the new layout with the new key was easy as pie. Thank you for the information about that. Now I have a nice little "locked" layer button for arrows and some other stuff :D .

And my question is this; Is there a way we can log what the keyboard is doing? The reason I am asking is because I think the keyboard crashed while switching layers earlier, because I had to unplug and reconnect it to get it back to life. I am thinking it would be easier if there was some sort of logging in place.
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: komar007 on Mon, 18 March 2013, 17:49:29

Thanks!
Any ideas how your and your dad's windowses differ?

I've just done something similar, this simply happened because it went to an undefined layer, because of my mistake making a layout.
I'm going to add indication about which layer the keyboard is on, but I need to rewrite some of the code first.
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: agodinhost on Mon, 18 March 2013, 17:53:58
Quote from: komar007 on Mon, 18 March 2013, 17:46:39
Great. Can you program it with the firmware in the first post, version 0.2_rc2 and see if the gui can program an empty layout?
I'll try ...

By the way: why python 3.3? wouldn't be easier to use 2.7??
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: komar007 on Mon, 18 March 2013, 17:54:48
How would it be easier?
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: agodinhost on Mon, 18 March 2013, 18:03:14
IMO 2.7 is more mature.

"Python 3.3.0 was released on September 29th, 2012." according to it's site.
There are some libraries without binding/port yet.

Almost all pythonists I do know at here (a dozen, tops) are still using the 2.7.
I'm not a pythonist (I only use it when there is no other option or just when I do need something quick).
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: Glissant on Mon, 18 March 2013, 18:07:32
Quote from: komar007 on Mon, 18 March 2013, 17:49:29

Thanks!
Any ideas how your and your dad's windowses differ?

I've just done something similar, this simply happened because it went to an undefined layer, because of my mistake making a layout.
I'm going to add indication about which layer the keyboard is on, but I need to rewrite some of the code first.
They differ in the way that mine is windows 8 and his is windows 7 :) .

I'll look over the layout to see if I have any undefined layers.

Did I mention I LOVE this thing? Well, I LOVE THIS THING!
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: OrangeJewce on Mon, 18 March 2013, 18:25:03
Quote from: agodinhost on Mon, 18 March 2013, 18:03:14
IMO 2.7 is more mature.

"Python 3.3.0 was released on September 29th, 2012." according to it's site.
There are some libraries without binding/port yet.

Almost all pythonists I do know at here (a dozen, tops) are still using the 2.7.
I'm not a pythonist (I only use it when there is no other option or just when I do need something quick).

The problem is python 3 changed a huge number of things in std API. It's extremely difficult to migrate from 2 to 3 and vice versa. For that reason, many of the popular APIs have either a) not moved or b) released a completely separate version just for Python 3.

Cheers,
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: jdcarpe on Mon, 18 March 2013, 18:38:20
This is super frustrating. At home under Win7 x64, I get this crap again:

Code: [Select]
Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python33\lib\tkinter\__init__.py", line 1442, in __call__
    return self.func(*args)
  File "C:\Users\Jonathan\Downloads\ukbdc_gui_w7_new\gui.py", line 900, in <lamb
da>
    command = lambda: command("program"),
  File "C:\Users\Jonathan\Downloads\ukbdc_gui_w7_new\gui.py", line 807, in on_me
nu_action
    u.attach()
  File "C:\Users\Jonathan\Downloads\ukbdc_gui_w7_new\ukbdc_lib\ukbdc.py", line 1
24, in attach
    idProduct = self.productId
  File "C:\Users\Jonathan\Downloads\ukbdc_gui_w7_new\usb\core.py", line 846, in
find
    raise ValueError('No backend available')
ValueError: No backend available

Device manager still shows Atmel USB, not libusb. I don't know what I'm doing wrong, but this sucks. Can you just setup the GUI where it will output a .hex file? I can flash the FW with Flip with no problem.
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: agodinhost on Mon, 18 March 2013, 18:43:02
Quote from: OrangeJewce on Mon, 18 March 2013, 18:25:03
The problem is python 3 changed a huge number of things in std API. It's extremely difficult to migrate from 2 to 3 and vice versa. For that reason, many of the popular APIs have either a) not moved or b) released a completely separate version just for Python 3.
Yes, I think it's the major reason.
Two weeks ago I tried to use the GTK with the 3.3 on 64, no way to get a port of pyCairo, pygObject nor pyGtk. I had to move back to 2.7.
It depends on what you are planning to use: if you are planning to use only common and already ported libraries you are okay with 3.3 - otherwise I would stay with 2.7.
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: komar007 on Mon, 18 March 2013, 18:51:39
Quote from: jdcarpe on Mon, 18 March 2013, 18:38:20
This is super frustrating. At home under Win7 x64, I get this crap again:

Code: [Select]
Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python33\lib\tkinter\__init__.py", line 1442, in __call__
    return self.func(*args)
  File "C:\Users\Jonathan\Downloads\ukbdc_gui_w7_new\gui.py", line 900, in <lamb
da>
    command = lambda: command("program"),
  File "C:\Users\Jonathan\Downloads\ukbdc_gui_w7_new\gui.py", line 807, in on_me
nu_action
    u.attach()
  File "C:\Users\Jonathan\Downloads\ukbdc_gui_w7_new\ukbdc_lib\ukbdc.py", line 1
24, in attach
    idProduct = self.productId
  File "C:\Users\Jonathan\Downloads\ukbdc_gui_w7_new\usb\core.py", line 846, in
find
    raise ValueError('No backend available')
ValueError: No backend available
Doesn't simply re-running inf-wizard and reinstalling the driver help? Have you tried removing the driver associated with this Atmel device?

Quote from: jdcarpe on Mon, 18 March 2013, 18:38:20
Device manager still shows Atmel USB, not libusb. I don't know what I'm doing wrong, but this sucks. Can you just setup the GUI where it will output a .hex file? I can flash the FW with Flip with no problem.
Good idea. I'll do it.


Quote from: Glissant on Mon, 18 March 2013, 18:07:32
Quote from: komar007 on Mon, 18 March 2013, 17:49:29

Thanks!
Any ideas how your and your dad's windowses differ?

I've just done something similar, this simply happened because it went to an undefined layer, because of my mistake making a layout.
I'm going to add indication about which layer the keyboard is on, but I need to rewrite some of the code first.
They differ in the way that mine is windows 8 and his is windows 7 :) .

I'll look over the layout to see if I have any undefined layers.

Did I mention I LOVE this thing? Well, I LOVE THIS THING!



Can you send me the layout which causes the keyboard to crash?
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: IvanIvanovich on Mon, 18 March 2013, 20:21:06
Ok, I had the same problem I think as jd. In devmgmt, I choose update driver and point it to the libusb folder. It's ok now. I guess since the atmel driver was assigned to the device the tool was not able to initialize the command through the expected driver so it fail of course.
So now, to make it really easy to use, have gui for layout physical arrange or at least some default like when launch pick ANSI 61, winkeyless, ISO, etc. Make modifiers and such some menu selection or something if can't simple assign it by key press on working other keyboard. Finally, if possible make the whole thing an exe for us Windows dummies.
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: jdcarpe on Mon, 18 March 2013, 20:34:46
Every time I try to do Update Driver Software, and point it to the libusb folder, it tells me that "The best driver software for your device is already installed."
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: hasu on Mon, 18 March 2013, 20:59:57
I'm about to give up running it on my Windows7 64bit, looks like I missed something and screwed up.

Which version of software should I use on Windwos7 64bit?
I tried to use Python 64bit and LibUSB amd64 but LibUSB installer install x86 version of drivers every time.
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: IvanIvanovich on Mon, 18 March 2013, 21:07:18
You have to force it. Use the I will pick the driver option. If you still have a hard time, from elevated CMD
set devmgr_show_nonpresent_devices=1
start devmgmt.msc

then once devmgmt opens in the view option choose show hidden device. Find the Atmel and choose uninstall, and choose delete drivers software. Then try to install libusb driver again.
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: John Fourth on Mon, 18 March 2013, 21:29:06

As mkawa mentioned, I started working on a non-libusb option for windows over the weekend. I don't have a GH60 board yet, but I am testing with a teensy board. Currently working through resolving some Python/Windows/C linking errors. I am targeting a 32-bit Python distribution for windows. I am basing it on komar's recommendation of the teensy raw hid source code. Cross your fingers.

Thanks,
John
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: sordna on Mon, 18 March 2013, 21:54:32
The gui runs right away on ubuntu 12.10. Just had to do this beforehand: sudo apt-get install python3-tk
I see a keyboard layout gui thing, and I can save .lay files. Don't have board to test though :-)
Title: GH60 prototype betatesting [Please test the GUI]
Post by: jdcarpe on Mon, 18 March 2013, 21:57:45
Quote from: sordna on Mon, 18 March 2013, 21:54:32
Don't have board to test though :-)

Yet?

I suspect!
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: komar007 on Tue, 19 March 2013, 05:37:56
Okay, here's the version with firmware generation.
Set what you need to set, and click file->generate firmware. The hex extension doesn't get added automatically in windows. I don't know why. Just type it in the file name.


It should work in linux too, at least it works for me.
[attachurl=1]
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: Glissant on Tue, 19 March 2013, 12:05:23
That's working beautifully :). Thanks to your help everything is working smoothly now.
Everyone should have this board in their arsenal. It's definitely my favorite style for everyday use.
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: agodinhost on Tue, 19 March 2013, 16:04:06
I didn't found my keyboard matrix - I'm soldering a few buttons in order to get one 20 keys keypad yet ...

btw: the arduino micro (http://www.ebay.com/itm/Leonardo-Pro-Micro-ATmega32U4-Arduino-IDE-1-0-3-Bootloader-replace-Pro-Mini-/310634777706?pt=LH_DefaultDomain_0&hash=item4853468c6a) is finally being sold on ebay - 15 bucks!!!
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: esoomenona on Thu, 21 March 2013, 05:14:25
Is it possible to set a MX Lock as a NumLock with a layer for numbers? I assume its as easy as setting a numpad layer and setting the Lock switch as key_down for the Fn on that layer?
Title: Re: GH60 prototype betatesting [Please test the GUI]
Post by: agodinhost on Thu, 21 March 2013, 09:22:03
Quote from: jdcarpe on Mon, 18 March 2013, 18:38:20
This is super frustrating. At home under Win7 x64, I get this crap again:

Code: [Select]
Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python33\lib\tkinter\__init__.py", line 1442, in __call__
    return self.func(*args)
  File "C:\Users\Jonathan\Downloads\ukbdc_gui_w7_new\gui.py", line 900, in <lamb
da>
    command = lambda: command("program"),
  File "C:\Users\Jonathan\Downloads\ukbdc_gui_w7_new\gui.py", line 807, in on_me
nu_action
    u.attach()
  File "C:\Users\Jonathan\Downloads\ukbdc_gui_w7_new\ukbdc_lib\ukbdc.py", line 1
24, in attach
    idProduct = self.productId
  File "C:\Users\Jonathan\Downloads\ukbdc_gui_w7_new\usb\core.py", line 846, in
find
    raise ValueError('No backend available')
ValueError: No backend available

Device manager still shows Atmel USB, not libusb. I don't know what I'm doing wrong, but this sucks. Can you just setup the GUI where it will output a .hex file? I can flash the FW with Flip with no problem.
Just out of curiosity: have you tried avrdude?
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: jdcarpe on Thu, 21 March 2013, 10:41:33
Quote from: agodinhost on Thu, 21 March 2013, 09:22:03
Quote from: jdcarpe on Mon, 18 March 2013, 18:38:20
This is super frustrating. At home under Win7 x64, I get this crap again:

Code: [Select]
Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python33\lib\tkinter\__init__.py", line 1442, in __call__
    return self.func(*args)
  File "C:\Users\Jonathan\Downloads\ukbdc_gui_w7_new\gui.py", line 900, in <lamb
da>
    command = lambda: command("program"),
  File "C:\Users\Jonathan\Downloads\ukbdc_gui_w7_new\gui.py", line 807, in on_me
nu_action
    u.attach()
  File "C:\Users\Jonathan\Downloads\ukbdc_gui_w7_new\ukbdc_lib\ukbdc.py", line 1
24, in attach
    idProduct = self.productId
  File "C:\Users\Jonathan\Downloads\ukbdc_gui_w7_new\usb\core.py", line 846, in
find
    raise ValueError('No backend available')
ValueError: No backend available

Device manager still shows Atmel USB, not libusb. I don't know what I'm doing wrong, but this sucks. Can you just setup the GUI where it will output a .hex file? I can flash the FW with Flip with no problem.
Just out of curiosity: have you tried avrdude?

I have WinAVR installed...


I really like being able to use the GUI to output a .hex file. Thanks, komar!
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: Strelok on Thu, 21 March 2013, 20:38:33
Question about the programming:

Can you use the Fn layer to toggle the normal keys?

Like Fn+z changed the layout to Dvorak, Fn+x changes it to Qwerty.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: hasu on Fri, 22 March 2013, 00:43:17
It seems like Layer 4 and above layers are not editable.

Code: [Select]
$ python3 ./gui.py
Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python3.2/tkinter/__init__.py", line 1402, in __call__
    return self.func(*args)
  File "/usr/lib/python3.2/tkinter/__init__.py", line 3125, in __call__
    self.__callback(self.__value, *args)
  File "./gui.py", line 713, in on_change_layer
    kd = self.layout[l, b]
  File "/home/noname/Dropbox/KEYBOARD/GH60/ukbdc_gui_w7_new/ukbdc_lib/layout.py", line 119, in __getitem__
    return self.layers[lay][key]
IndexError: list index out of range
Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python3.2/tkinter/__init__.py", line 1402, in __call__
    return self.func(*args)
  File "/usr/lib/python3.2/tkinter/__init__.py", line 3125, in __call__
    self.__callback(self.__value, *args)
  File "./gui.py", line 713, in on_change_layer
    kd = self.layout[l, b]
  File "/home/noname/Dropbox/KEYBOARD/GH60/ukbdc_gui_w7_new/ukbdc_lib/layout.py", line 119, in __getitem__
    return self.layers[lay][key]
IndexError: list index out of range
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Fri, 22 March 2013, 00:50:38
Quote from: hasu on Fri, 22 March 2013, 00:43:17
It seems like Layer 4 and above layers are not editable.

Code: [Select]
$ python3 ./gui.py
Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python3.2/tkinter/__init__.py", line 1402, in __call__
    return self.func(*args)
  File "/usr/lib/python3.2/tkinter/__init__.py", line 3125, in __call__
    self.__callback(self.__value, *args)
  File "./gui.py", line 713, in on_change_layer
    kd = self.layout[l, b]
  File "/home/noname/Dropbox/KEYBOARD/GH60/ukbdc_gui_w7_new/ukbdc_lib/layout.py", line 119, in __getitem__
    return self.layers[lay][key]
IndexError: list index out of range
Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python3.2/tkinter/__init__.py", line 1402, in __call__
    return self.func(*args)
  File "/usr/lib/python3.2/tkinter/__init__.py", line 3125, in __call__
    self.__callback(self.__value, *args)
  File "./gui.py", line 713, in on_change_layer
    kd = self.layout[l, b]
  File "/home/noname/Dropbox/KEYBOARD/GH60/ukbdc_gui_w7_new/ukbdc_lib/layout.py", line 119, in __getitem__
    return self.layers[lay][key]
IndexError: list index out of range
That' because the gh60.lay file is broken. Please use the new layout file from the bottom of the OP
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: hasu on Fri, 22 March 2013, 02:39:45
Thanks komar,  I can edit 4 and above layers flawlessly now.

I finished layout emulating Poker Fn layers. This is better than original a bit, I think :)
Original Poker has two locking layers, Fn+Q fixes cursor keys on right bottom area and Fn+Space places Esc instead of back quote(`). I add my layout file just for reference.

This layout is comprised of these layers:
0: default(qwerty)
1: Space lock(cursor keys)
2: Q lock(Esc)
3: Space and Q lock
4: Fn layer of default
5: Fn layer of Layer 1
6: Fn layer of Layer 2
7: Fn layer of Layer 3
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: Glissant on Fri, 22 March 2013, 16:34:45
Thanks a lot for that hasu. People could also use your layout to understand how to now cross contaminate layers.

Could someone take the time to explain how adding keys work? I tried making my lshift into two keys like my rshift, but I can't seem to get the numbers right or something as they don't want to work xD. I'll attach my gh60.xml in case that will make it easier to explain it to me.


Edit: I'm going to try to multiply the keys at the end of the row (rshift) again to see if that will work.


Edit2: I'll just leave this here for someone to use as a reference if they need in the future.
It worked out well when I multiplied the last to keys in the shift row (I call it that now) by 8. The next to last key ends up looking weird in the gui, so maybe someone can help me figure that out instead?
[attach=2]

As you can see when the keys work the layout looks a little weird on a couple of keys, but it looks completely normal in the xml that doesn't work for me. Sorry if I'm unclear. This week has been a ***** xD.


adding my xml again to show the updated file. The updated xml file has 104 and 112 as the x value in the last two keys in the shift row.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Fri, 22 March 2013, 16:50:02
I think you just have to move it to the left a bit. To the position where 53 ends, so that would be 98 (since 53's x in 90, and width is 8 ), then change the size appropriately. This is a 1.75 shift, multiply that by 8 and it's width is 14.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: Glissant on Fri, 22 March 2013, 18:51:19
Yeah I think I did it right the first time, and I tried my "non working"-xml again, and now it works just fine. Well at least I know that I understood how it works more or less, but I still have no clue why it didn't register correctly the first time. Maybe I uploaded the wrong hex file. Sorry for the confusion.
Thanks for the help, komar :) .


edit: My previous post just makes me wish there was something that would log everything I do on the computer. Changes in documents, opened and closed windows etc.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: engicoder on Wed, 27 March 2013, 12:26:18
Komar....how should I send you my layout? PM doesn't seem to support attachments.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: engicoder on Wed, 27 March 2013, 12:26:51
Also, anyone know scan code for the context menu key? ( I think they call it the applications key)
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Wed, 27 March 2013, 12:40:21
Quote from: engicoder on Wed, 27 March 2013, 12:26:18
Komar....how should I send you my layout? PM doesn't seem to support attachments.
Please upload it somewhere and send me a link. Or you can attach it here in a post.

Quote from: engicoder on Wed, 27 March 2013, 12:26:51
Also, anyone know scan code for the context menu key?

It's 0x65. For other codes, this document is useful: www.usb.org/developers/devclass_docs/Hut1_12v2.pdf (http://www.usb.org/developers/devclass_docs/Hut1_12v2.pdf) (start at page 53)
I'll add sensible names for some useful codes which are not available yet in the next version.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: engicoder on Thu, 28 March 2013, 12:45:02
Here is my layout...nothing earth shattering. I'm a coder, so its oriented for that usage.
Includes:
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: engicoder on Thu, 28 March 2013, 13:28:02
@Komar

The link to "GH60 Project" in your sig is dead.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Thu, 28 March 2013, 14:05:03
Quote from: engicoder on Thu, 28 March 2013, 13:28:02
@Komar

The link to "GH60 Project" in your sig is dead.
Fixed, thanks.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: osxoep on Thu, 28 March 2013, 14:14:31
How do I define an ISO enter key in the layout gh60.xml?
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Thu, 28 March 2013, 14:35:59
Quote from: osxoep on Thu, 28 March 2013, 14:14:31
How do I define an ISO enter key in the layout gh60.xml?

As far as I remember it's the same number.
You may want to modify this file and change the position (x and y) and size (width and height). The units are 1/8th of 0.75".
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: Glissant on Sun, 31 March 2013, 15:02:01
Does the newest firmware support the wake on sleep & pulsing caps_lock light? Nothing is happening on my end, and I have powered USB on while sleeping too.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Sun, 31 March 2013, 15:49:19
It worked on my computer at least. Though there's no pulsing.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: Glissant on Sun, 31 March 2013, 18:23:05
Maybe it's just my useless computer *shrug*.

I had a different thing I want to talk about too.
In windows 8 something weird has started happening. When I send the controller into DFU mode, my usb devices and network card seem to crash and then reconnect. The same thing happens when I "restart" the keyboard from DFU to normal mode.
Anybody else seen this happen?

I'm beginning to think I should switch to Linux for the most part as I don't hardly play anymore.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: hasu on Sun, 31 March 2013, 18:37:34
Glissant, if you are on Windows you need to grant your GH60 permission for wake up with 'Power Management' tab of 'Device Manager'. It worked on my Windows 7(64bit).
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: Glissant on Sun, 31 March 2013, 19:00:24
It does have that already, hasu :) . It's probably just my stupid windows 8.


Edit: Anybody able to try it on a laptop? I can wake my computer from sleep with my steelseries raw mouse without a problem, but the keyboard does nothing. Going to give my Poker a try to see if it might be a driver issue.


Edit2: Poker doesn't wake the computer and neither do my Filcos, and I also tried waking the laptop with my integrated keyboard, but it didn't respond to that either. Not sure what's wrong with my computer.
I installed hasu's firmware to see if that would change how windows reacts to the unplugging and plugging of the GH60; it did. No drivers crash and the keyboard is smoothly recognized.
Maybe it's the libusb driver that's doing it?
I'll spend some more time looking at the behavior later.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: WhiteFireDragon on Mon, 01 April 2013, 22:34:05
Currently, there are over 30 DIY PCBs ordered. komar, you should expand the four x1 pads of the crystal. There won't be enough space for iron-soldering. I'm not speaking for myself since I already have a hot air station, but for all the other guys that will probably have trouble with it.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Tue, 02 April 2013, 12:45:21
Quote from: hasu on Fri, 22 March 2013, 02:39:45
Thanks komar,  I can edit 4 and above layers flawlessly now.

I finished layout emulating Poker Fn layers. This is better than original a bit, I think :)
Original Poker has two locking layers, Fn+Q fixes cursor keys on right bottom area and Fn+Space places Esc instead of back quote(`). I add my layout file just for reference.

This layout is comprised of these layers:
0: default(qwerty)
1: Space lock(cursor keys)
2: Q lock(Esc)
3: Space and Q lock
4: Fn layer of default
5: Fn layer of Layer 1
6: Fn layer of Layer 2
7: Fn layer of Layer 3

Thanks, added to the OP

Quote from: engicoder on Thu, 28 March 2013, 12:45:02
Here is my layout...nothing earth shattering. I'm a coder, so its oriented for that usage.
Includes:
  • Caps Lock change to Control.
  • Fn where Control was, lgui retained.
  • Caps  Lock added to right of Right Shift.
  • Altered layout for arrow key cluster on Layer 2.
  • no-op keys on layer 2 for all letters and such to avoid accidentals.
  • Layer for Keypad...I still use those Alt-XXX combos on occasion.
  • NumLock layer
There are a couple of problems with your layout. Have you actually tested it on the keyboard?
The 2 lower-left modifiers send you to different layers depending on the order they were released, was that intended? Also, when you press both these modifiers and then numlock (no 34), it goes to layer 8, which is empty. There's no coming back from there.
There's one more thing, the extra fn button to the right of rshift is number 54. In the gh60.xml you changed shift to 54, and made that button 55. How does that work? Did you modify the firmware too?
Don't take it as an attack, just trying to get to know what's going on here;)
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: codyeatworld on Tue, 16 April 2013, 20:07:22
So im back on windows finally and I will be giving this a whirl shortly.

Going for a winkeyless iso layout just like dirge's gh60, except ill have fn keys instead of blockers
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: codyeatworld on Tue, 16 April 2013, 22:40:48
I want to update my firmware but how do I put the keyboard in program mode?

Quote
2. connect the keyboard, press the program button (S1) and wait until it enumerates

I've tried holding Esc, 1, and caps lock while plugging it in and FLIP cannot find it and my keyboard is not in program mode cause I can still type?

- Cody
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Tue, 16 April 2013, 23:33:42
Quote from: hellocodes on Tue, 16 April 2013, 22:40:48
I want to update my firmware but how do I put the keyboard in program mode?

Quote
2. connect the keyboard, press the program button (S1) and wait until it enumerates

I've tried holding Esc, 1, and caps lock while plugging it in and FLIP cannot find it and my keyboard is not in program mode cause I can still type?

- Cody

S1 is the microswitch on the back of the keyboard;)
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: codyeatworld on Tue, 16 April 2013, 23:51:18
Ahh, thank you komar!! I didn't even think of that...

It updated perfectly.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: TheQsanity on Tue, 23 April 2013, 02:46:46
Just here to bookmark this thread.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: engicoder on Tue, 23 April 2013, 12:05:43
Hi Everyone

I've been busy with other things for a while and just got back to tinkering with the GH60. I am trying to figure out how to update the firmware via Flip. I downloaded the firmware initially with Flip a while back and all was fine, but never tried updating the firmware. Now I am having some trouble doing that.

When I push the switch on the back of the board and try to connect with Flip it says "Could not open USB device".

Using the GUI to program the layout results in a "device not found" error in the output window.

Also, the instructions everywhere say switch (S1)....but on my board at east, its labeled S0.

Thanks
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Tue, 23 April 2013, 13:08:46
Quote from: engicoder on Tue, 23 April 2013, 12:05:43
Hi Everyone

I've been busy with other things for a while and just got back to tinkering with the GH60. I am trying to figure out how to update the firmware via Flip. I downloaded the firmware initially with Flip a while back and all was fine, but never tried updating the firmware. Now I am having some trouble doing that.

When I push the switch on the back of the board and try to connect with Flip it says "Could not open USB device".

Using the GUI to program the layout results in a "device not found" error in the output window.

Also, the instructions everywhere say switch (S1)....but on my board at east, its labeled S0.

Thanks
Since the time you first programmed it with flip, did you install the libusb drivers? If sou, you have to "update driver" for this device and point to the flip driver's location.

And S1 is en error, of course;)
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: engicoder on Tue, 23 April 2013, 14:23:20
I have not installed libusb since.
In Device Manager, when I plug in the GH60 the following devices are added:

Human Interface Devices
 - HID-compliant device
 - USB Input Device

Keyboards
 - HID Keyboard Device

Universal Serial Bus controllers
 - USB Composite Device

All of them a listed as using the Microsoft drivers, and as such attempting to update the driver results in "Driver is up to date".

At one time after downloading the original firmware, I remember there being an Atmel entry in the device tree that listed the ATMega32U4, but I don't see that any more.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Tue, 23 April 2013, 14:24:53
Maybe try reinstalling flip
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: engicoder on Tue, 23 April 2013, 14:45:49
Same result.
This is Windows 7 x64. I tried it in another machine and it shows up in the device manager the same way.

At this point, I'm longing for a ISP header...

Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: jdcarpe on Tue, 23 April 2013, 15:05:50
When you press the switch on the GH60, does it show up as a different device in your device manager?
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: engicoder on Tue, 23 April 2013, 15:19:05
No... it does not change. Nothing visible happens when I push the switch.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: jdcarpe on Tue, 23 April 2013, 15:22:41
Then it's never jumping into program mode. Something is definitely wrong...
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Tue, 23 April 2013, 15:30:45
Quote from: engicoder on Tue, 23 April 2013, 15:19:05
No... it does not change. Nothing visible happens when I push the switch.
Does it work correctly before you push the switch?
Which firmware is it running now?
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: codyeatworld on Tue, 23 April 2013, 15:42:02
Quote from: engicoder on Tue, 23 April 2013, 12:05:43

Using the GUI to program the layout results in a "device not found" error in the output window.

I had this problem and I had to install a java run time.

I was running Windows 8.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: Photekq on Tue, 23 April 2013, 16:42:11
Sorry to be a pain. I'm sure there are answers to these somewhere, but frankly there are too many pages for me to look through and my searches have been unyielding. Could anyone help me out?

1. How far is the left edge of the USB receptacle from the left edge of the PCB?
2. How far is the right edge of the USB receptacle from the left edge of the PCB?
2. What are the dimensions of the PCB?

Sorry again and thanks in advance. I'm just trying to quickly design something.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Wed, 24 April 2013, 03:50:13
Quote from: Photekq on Tue, 23 April 2013, 16:42:11
Sorry to be a pain. I'm sure there are answers to these somewhere, but frankly there are too many pages for me to look through and my searches have been unyielding. Could anyone help me out?

1. How far is the left edge of the USB receptacle from the left edge of the PCB?
2. How far is the right edge of the USB receptacle from the left edge of the PCB?
2. What are the dimensions of the PCB?

Sorry again and thanks in advance. I'm just trying to quickly design something.
I don't have answers to any of there questions yet. The position of the receptacle and exact dimensions of the board are one of the last things I have left to do before the boards are done;)
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: engicoder on Wed, 24 April 2013, 07:44:38
Quote from: komar007 on Tue, 23 April 2013, 15:30:45
Does it work correctly before you push the switch?
Which firmware is it running now?

Ok, I sorted things out. I tried jumping pin 13 (RESET) to ground to test things and it did reset, so it was definitely a connection problem. I reflowed the switch and microcontroller with a little more solder and its working now.


Thanks for all your help and sorry for the hassle...I should have gone straight to the schematic to begin with.

A question on the schematic...rev A shows an ISP header. From gerbers, it appears that the six through holes near the GH60 logo at the bottom center of the board are the ISP pinouts, correct?
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: engicoder on Wed, 24 April 2013, 07:56:44
My quick measurements of the prototype for you quick design  :D But as Komar said....The production one will probably be different.

Quote from: Photekq on Tue, 23 April 2013, 16:42:11
1. How far is the left edge of the USB receptacle from the left edge of the PCB?
263 mm
Quote from: Photekq on Tue, 23 April 2013, 16:42:11
2. How far is the right edge of the USB receptacle from the left edge of the PCB?
8.5 mm
Quote from: Photekq on Tue, 23 April 2013, 16:42:11
2. What are the dimensions of the PCB?
284.5 mm x 94 mm
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Wed, 24 April 2013, 08:11:44
Quote from: engicoder on Wed, 24 April 2013, 07:44:38
Quote from: komar007 on Tue, 23 April 2013, 15:30:45
Does it work correctly before you push the switch?
Which firmware is it running now?

Ok, I sorted things out. I tried jumping pin 13 (RESET) to ground to test things and it did reset, so it was definitely a connection problem. I reflowed the switch and microcontroller with a little more solder and its working now.


Thanks for all your help and sorry for the hassle...I should have gone straight to the schematic to begin with.

A question on the schematic...rev A shows an ISP header. From gerbers, it appears that the six through holes near the GH60 logo at the bottom center of the board are the ISP pinouts, correct?

Great you sorted it out!
Yes, that's regular an ISP connector (SPI interface), only the pins' order is random.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: Photekq on Wed, 24 April 2013, 10:22:16
Thanks engicoder and komar. I didn't realise work was still being done to the pcb :o keep up the good work!
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: domoaligato on Wed, 24 April 2013, 13:33:11
deleted. wrong thread.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: engicoder on Thu, 25 April 2013, 09:52:27
Got my layout corrected and working (Thanks for the feedback Komar). Here it is:

0: Base layer
    - Control in place of Caps_Lock
    - Caps_Lock to right of RShift ( with a little wire and dremel work, have led in that position)
    - Fn in standard Control location
2: Fn layer
    - Functions keys
    - Arrow / Page cluster
3: Fn + Caps_Lock locked layer
    - Keypad cluster
    - Num_lock in place of Caps_Lock
    - Fn or Num_Lock to return to base layer
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: engicoder on Thu, 25 April 2013, 09:53:16
Out of curiosity, what is format of the layout (.lay) file?
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Thu, 25 April 2013, 11:42:15
Quote from: engicoder on Thu, 25 April 2013, 09:53:16
Out of curiosity, what is format of the layout (.lay) file?
I lost the description I once made. I'll post it here when I find it:)

Got it.
Quote
Layout starts from address 0x2700. First byte is number of keys (leave it
64(0x40)), then number of layers (the GUI always sets it to 16).
Next there are all 16 layers, each consisting of 64 keys, each 4 bytes long.
A key definition is:
* first byte: scancode (as in USB HID) - 0 means no scancode (do not send)
* second byte: actions (0 means no actions (only regular keypress is
sent), then 2 next bytes are undefined)
  - high half - action on pressing down
  - low half - action on releasing
  Each 4-bit action can be: 0 - no action, 1 - go to layer number n
(absolute jump), 2 - go to layer number current_layer + n (relative
jump)
  If an action is defined (not 0), then the argument n is passed as
third (press down action) or fourth (release action) byte of a key's
description.
* third byte: argument for press down action
* fourth byte: argument for release action.
The argument is either an 8-bit unsigned integer (absolute jump) or 8-bit signed integer (2's complement).
Example: define a key which sends no scancode and changes the layer to
number 1 when pressed:
00 20 01 00
00 - no scancode
20 - (2) go to layer n on key down, (0) no action on key up
01 - argument to action "go to layer n on key down", setting n to 1
00 - can be anything (no argument to release action, because there is
no release action)
Then you can define in a similar way an action on layer 1 (the same
key), that will go to layer 0 on key release, and this way you have
two layers with an "fn" button which when pressed, changes to
alternative layer.
The firmware does not support inheritance, so the GUI resolves the inheritance tree before sending the layout. In the format saved in a file the inherited keys are represented by 0xffffffff. In this format there is also the inheritance tree in the end of the file. It's saved as n-1 bytes (where n is the number of layers). The bytes are the numbers of layers that layers 1, 2, ..., n-1 inherit from, respectively.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: engicoder on Thu, 25 April 2013, 13:17:02
Thanks....I love me some HxD spelunking  ;D
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: engicoder on Tue, 14 May 2013, 11:41:07
Komar, is the source for the official firmware available?
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Tue, 14 May 2013, 12:49:53
Yes, here: https://github.com/komar007/ukbdc
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: domoaligato on Thu, 16 May 2013, 13:06:04
I have found a little bug with the gui.
if I check the radio button to make a key defined instead of inherited. there is no way to select inherited again as it is greyed out.

edit:Yes I have clear the entire layer to make it all inherited but not the individual keys.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Thu, 16 May 2013, 13:15:03
Quote from: domoaligato on Thu, 16 May 2013, 13:06:04
I have found a little bug with the gui.
if I check the radio button to make a key defined instead of inherited. there is no way to select inherited again as it is greyed out.

edit:Yes I have clear the entire layer to make it all inherited but not the individual keys.

I can't reproduce that. Could you give exact steps which led to this situation?

Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: domoaligato on Thu, 16 May 2013, 14:50:46
after you posted this I decided to start from scratch instead of the old file I was using. I must have a corrupted/depreciated layout file.
thanks for trying to help.
btw in the OP

komar's layout
(this is not the layout included in the ukbdc_gui package; that one is old, deprecated and buggy)

what is the scancode for 0x65 used for?

also... where can I find all the accepted scancodes?
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: domoaligato on Thu, 16 May 2013, 14:56:54
I want to make
FN + Esc = ~
Shift + Esc = `

edit: let me add a example of my setup.
on layer 1 button 0 = `
if I hold FN on layer 0 it brings me to layer 1 release takes me back to layer 0
does this mean I would need to hold FN + Shift to get to ~ ?
or is there a way to make it go directly to ~ without holding FN + Shift ?
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Thu, 16 May 2013, 15:09:18

Quote from: domoaligato on Thu, 16 May 2013, 14:50:46
after you posted this I decided to start from scratch instead of the old file I was using. I must have a corrupted/depreciated layout file.
thanks for trying to help.
btw in the OP

komar's layout
(this is not the layout included in the ukbdc_gui package; that one is old, deprecated and buggy)

what is the scancode for 0x65 used for?

also... where can I find all the accepted scancodes?
 
Ok, I'm glad it works. The old layout file is indeed deprecated and causes problems.
0x65 is Application (that is interpreted as "context menu" on most systems)
Inside the ukbdc_gui directory there is a file called ukbdc_lib/mnemonics.py which includes the symbolic names for most USB HID scancodes. You can use these names in the program.
The list of all HID scancodes is in the HID documentation: www.usb.org/developers/devclass_docs/Hut1_12v2.pdf (http://www.usb.org/developers/devclass_docs/Hut1_12v2.pdf), from page 53.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Thu, 16 May 2013, 15:16:12
Quote from: domoaligato on Thu, 16 May 2013, 14:56:54
I want to make
FN + Esc = ~
Shift + Esc = `
You can't really do this, because ~ and ` is one code. If you're holding shift, your OS will interpret ~/` as ~, not `...
You can do the opposite though.
Set fn to go to layer 1 on press and layer 0 on release, set shift the same. On layer 1 inherit all the keys from layer 0 and redefine esc to be ~/`
On layer 1 inherit all keys from layer 0 and redefine esc ti
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: domoaligato on Thu, 16 May 2013, 15:19:40
attached are my layout and xml file.
they are a slightly modified version of the gh60 max keys layout.
it does not include Prtsc/scroll Lock/Pause or pretty much any other keys that I do not use.
I will prob add arrows for wasd and Home/End PgUp/PgDn to it later.

Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: mkawa on Thu, 16 May 2013, 15:27:56
wasn't john supposed to be on this?
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: domoaligato on Thu, 16 May 2013, 17:14:26
Quote from: komar007 on Thu, 16 May 2013, 15:16:12
Quote from: domoaligato on Thu, 16 May 2013, 14:56:54
I want to make
FN + Esc = ~
Shift + Esc = `
You can't really do this, because ~ and ` is one code. If you're holding shift, your OS will interpret ~/` as ~, not `...
You can do the opposite though.
Set fn to go to layer 1 on press and layer 0 on release, set shift the same. On layer 1 inherit all the keys from layer 0 and redefine esc to be ~/`
On layer 1 inherit all keys from layer 0 and redefine esc ti

Thanks komar!
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: domoaligato on Tue, 28 May 2013, 15:36:51
Could the gh60 software have a option added to export the generated hex file?
This way we could make backups of the firmware and flash it manually and/or share the completed firmware with others?
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: engicoder on Tue, 28 May 2013, 16:23:03
Komar already created a version that does this...

http://geekhack.org/index.php?topic=37570.msg827049#msg827049 (http://geekhack.org/index.php?topic=37570.msg827049#msg827049)
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: domoaligato on Tue, 28 May 2013, 17:50:28
Quote from: engicoder on Tue, 28 May 2013, 16:23:03
Komar already created a version that does this...

http://geekhack.org/index.php?topic=37570.msg827049#msg827049 (http://geekhack.org/index.php?topic=37570.msg827049#msg827049)

Thanks! I do not know how I missed that. :(
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: domoaligato on Sat, 06 July 2013, 13:41:12
komar does your firmware have a debug mode?
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Sat, 06 July 2013, 13:48:01
No, it doesn't. What would the debug mode do? I was thinking about implementing one where it sends the current layer number to the GUI and the GUI presents the actual keycodes on this layer. Any other ideas?
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: Tranquilite on Sat, 06 July 2013, 14:22:19
The most useful keyboard debug feature for me is in hasu's firmware where you can enable debug print statements. Very useful for making sure the parts of code you are working on are executing as expected.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Sat, 06 July 2013, 14:38:12
Oh, you mean for development. It can be done, sure.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: domoaligato on Sat, 06 July 2013, 17:31:13
Quote from: Tranquilite on Sat, 06 July 2013, 14:22:19
The most useful keyboard debug feature for me is in hasu's firmware where you can enable debug print statements. Very useful for making sure the parts of code you are working on are executing as expected.

this is what I was thinking of.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Sun, 07 July 2013, 10:32:04

GH60 rev. B prototype dimensions


EDIT: I decided to move this to the original GH60 development thread: http://geekhack.org/index.php?topic=34959.msg954124#msg954124 (http://geekhack.org/index.php?topic=34959.msg954124#msg954124)
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: TheSoulhunter on Tue, 09 July 2013, 14:42:00
I will go with this layout...

(http://soulhunters-crappy-website.com/misc/GH60-SHv2.png)

It fixes most things I didn't like on the Poker or on standard keyboards:

1. Capslock
As most other people I never really used Capslock, so I replaced it with "DEL" on my Poker, but on my GH60 layout I will use it as secondary Layer modifier -> It's easy to locate and doesn't interfere much with the assigned 3rd layer buttons (most important the arrow buttons which would be used with the right hand while left presses the layer button).

2. Right Winkey
I never used the right winkey (right "ALT" and "CTRL" not that much either) so I removed the key, put "MENU" and "CTRL" one position to the left, and used the rightmost key as Layer button. Again, it's location is easy to find and it doesn't infer much with the assigned 2nd layer buttons (most important the WASD nav cluster which would be used with the left hand while the right presses the layer button).

3. Arrow keys
These are placed bottom right (as supposed to be) displaced one button to the left so they don't use the shift for "UP" as on the poker. They can be used by either by pressing Layer2 with the right pinky (while the other fingers press the arrow keys) or by pressing Layer3 with the left hand, whatever fits the situation best (single quick taps or continuous presses like when cycling through something).

4. Nav keys
I put these on WASD, mainly because it's position is easy to locate (if you game... and don't use one of the less common gaming key bindings). Also it's possible to use these keys along with the arrow keys without much interference.

5. Delete key and Backspace
I never liked that "\|" is assigned to a non 1x1 key which is also in a relative prominent position (outer edge between enter and backspace, wtf!?), also I really liked how the HKKB uses its position for "DEL/Backspace" (takes just some hours getting used to it) so I picked up that idea but gave delete a separate key (by splitting backspace) and put it top right, left to it I put the tilde/grave key (its imo a much better position for it than on FN+Esc as all other "signs" are on the num row and right side of the board as well). Considered putting backspace on the top right corner and "DEL" where "\|" was, but I think that backspace should get the bigger key and that "DEL" should be on the other end of "ESC".

6. Numberpad keys
On Layer3 I put the numpad numbers in the numrow (what a sentence, huh?) simply because some applications I use demand numpad inputs (numrow keys wont work).

7. Umlauts and Add-Ons
As I'm from Euroland I sometimes need Umlauts, so I put em on appropriate keys on Layer3. I also added Pause/Print on "P" and a taskmanager shortcut on "TAB".
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: Kdash on Fri, 13 September 2013, 03:08:09
Hello,guys! I made that PCB on my country. depend on pcbcart_gh60_rev_b_v2 version. when I received the PCB and SMT components and I assembled all together. I flash the  ukbdc_gh60-0.2_rc2.hex and  ukbdc_gh60-0.1.hex firmwares and it does't work... And the ukbdc_gh60-0.2_rc2_std_layout.hex firmware I flashed it can work but the "8, I. K, M"(col9) key can't work. Can any one help me ?
sorry for my poor english  :)
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: jen1982 on Fri, 13 September 2013, 03:34:03
I also met upstairs this problem.!!!!
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: hasu on Fri, 13 September 2013, 04:11:38
Checked rev B schematic and found its pin configuration diffesr from rev A! Firmware of rev A is incompatibile to rev B PCB.
RevB use PB7 for col9(8,I,K,M) instead of PB0 of RevA. You need to change source and build firmware.

Rev A PCB won't be supported by future release of firmware anymore?
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: Kdash on Fri, 13 September 2013, 04:26:39
Quote from: hasu on Fri, 13 September 2013, 04:11:38
Checked rev B schematic and found its pin configuration diffesr from rev A! Firmware of rev A is incompatibile to rev B PCB.
RevB use PB7 for col9(8,I,K,M) instead of PB0 of RevA. You need to change source and build firmware.

Rev A PCB won't be supported by future release of firmware anymore?
thank you for your reply! So i need to modify the source code and build my own version of firmware? I did the rev B PCB.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: hasu on Fri, 13 September 2013, 05:36:34
Kdash,
Right.

I think you got rev B gerber files from this komar's blog page. I downloaded, checked the gerbers and confirmed it uses PB7 for col9.
http://blog.komar.be/projects/gh60-programmable-keyboard/


I guess you need change this line, replace B0 with B7.
https://github.com/komar007/ukbdc/blob/master/platforms.c#L49
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: domoaligato on Fri, 13 September 2013, 08:46:10
Quote from: hasu on Fri, 13 September 2013, 04:11:38
Checked rev B schematic and found its pin configuration diffesr from rev A! Firmware of rev A is incompatibile to rev B PCB.
RevB use PB7 for col9(8,I,K,M) instead of PB0 of RevA. You need to change source and build firmware.

Rev A PCB won't be supported by future release of firmware anymore?

Can rev a be copied to a new folder so that development of rev b doesn't overwrite it? Please :D
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: Kdash on Fri, 13 September 2013, 11:50:41
Quote from: hasu on Fri, 13 September 2013, 05:36:34
Kdash,
Right.

I think you got rev B gerber files from this komar's blog page. I downloaded, checked the gerbers and confirmed it uses PB7 for col9.
http://blog.komar.be/projects/gh60-programmable-keyboard/


I guess you need change this line, replace B0 with B7.
https://github.com/komar007/ukbdc/blob/master/platforms.c#L49
Thank you! hasu~ I fix it, and it works correctly.  I can't build the komar's version ,so I modify your source code I find it and change it.
 Yes! It works!
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: metalliqaz on Fri, 13 September 2013, 11:52:46
The Rev B design is the final design?
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: MOZ on Fri, 13 September 2013, 13:22:38
IN the GB thread, WFD did say he wanted to make a few changes, I'll wait for the team to reply.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Thu, 19 September 2013, 03:02:45
Hi,
sorry for the delays, I've just come back from holidays.
I'm slowly catching up with life, so bear with me.
As you've correctly noticed, the topology of the board has changed slightly, so the firmware needs an update.
Of course the old rev. A will still be supported by the official firmware.
It's also good to hear people are producing rev. B boards themselves

Rev. B is the final design (electrically speaking), only minor mechanical changes will be made, so rev. C will be firmware-compatible.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: The_Beast on Thu, 19 September 2013, 09:10:44
Quote from: komar007 on Thu, 19 September 2013, 03:02:45
Hi,
sorry for the delays, I've just come back from holidays.
I'm slowly catching up with life, so bear with me.
As you've correctly noticed, the topology of the board has changed slightly, so the firmware needs an update.
Of course the old rev. A will still be supported by the official firmware.
It's also good to hear people are producing rev. B boards themselves

Rev. B is the final design (electrically speaking), only minor mechanical changes will be made, so rev. C will be firmware-compatible.

Very good news! I can't want to test Rev B!
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: MOZ on Thu, 19 September 2013, 10:13:00
I will shamelessly ask if anyone has extra PCB with/without components.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: gropingmantis on Thu, 19 September 2013, 17:39:00
In the GUI how do us funny ISO types work out which numbers apply to which positions? For example |\ and ~# and split backspace.
I mean I've modified the .xml but what switch numbers should relate to which keys?
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Fri, 20 September 2013, 06:27:40
Good question.
The layouts have a few levels of indirection.
First of all every switch is connected to some row and some column. These correspond to inputs and outputs of the microcontroller.
In the firmware, the lowest I/O layer handles these hardware pins by assigning numbers to them. Next, the matrix scanning module is configured by passing a list of pin numbers for columns and a list for rows, so each switch is represented by the column and row numbers (which can be converted to particular pin numbers and later to microcontroller ports). In order to simplify things and provide compatibility of layouts between different revisions of the board, the keys are assigned numbers (so each row-col pair becomes a simple number).
You can see the matrix number to col-row pairs assignment and row and column list to pin numbers assignment here: https://github.com/komar007/ukbdc/blob/master/main_gh60.c#L20-L29 (this is for rev. A)
As you can compare with the GUI, between the left shift and the next key, I left one number (43), so that the order is kept sensible for ISO, and also there is one number omitted between right shift and the preceding key and between enter and preceding key.
As for split backspace, the extra key will have to have a higher number (64 I suppose, since the last one is 63 so far), because it wasn't taken into account before. This is not available in the firmware yet, because I don't have the rev. B board yet;)
This way the old layouts will be compatible with the new revision and it's possible to create an ISO/ANSI combo layout which works correctly on both physical layouts.
I hope this clears things a bit.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: hasu on Fri, 20 September 2013, 12:40:51
Quote from: komar007 on Thu, 19 September 2013, 03:02:45
Of course the old rev. A will still be supported by the official firmware.

It is good news for betatesters with their Rev A PCB!
Thank you, komar.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: gropingmantis on Fri, 20 September 2013, 13:49:27
Yes that makes it much clearer. Thanks kormar.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: Kdash on Fri, 20 September 2013, 19:20:07
 :thumb: Well done!
I modified the tmk_keyboard's source code,and build the rev B version's firmware. I tested it  and it works very fine. Thank you~
and  I will test your layout programming GUI in another day ~
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: Kdash on Tue, 24 September 2013, 10:24:44
Hi komar, My friend wired the leds himself, but he found the blacklight dose not work and he also found the lcol14 connected with the GPIO2  in your PCB design. so he can't simply wired the leds, he cut the connection, the blacklight works fine..  is it a bug or meaning other things?
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Tue, 24 September 2013, 10:34:27
Quote from: Kdash on Tue, 24 September 2013, 10:24:44
Hi komar, My friend wired the leds himself, but he found the blacklight dose not work and he also found the lcol14 connected with the GPIO2  in your PCB design. so he can't simply wired the leds, he cut the connection, the blacklight works fine..  is it a bug or meaning other things?

Unfortunately, this is an error:(
It will be fixed in the final revision. For rev. B, either Fn led will work or the last column of backlight:/
Cutting is not necessary with correct handling in the firmware.

Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: Kdash on Tue, 24 September 2013, 10:42:12
Thank you！ I got it～ :thumb:
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: Kdash on Wed, 30 October 2013, 09:42:06
Hi komar, how can i add the Mute, Volume Up or Volume Down key using your GUI tools?
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Wed, 30 October 2013, 10:11:26
Quote from: Kdash on Wed, 30 October 2013, 09:42:06
Hi komar, how can i add the Mute, Volume Up or Volume Down key using your GUI tools?
As far as I know the volume controls are available in the Consumer Page (0x0C). Adding support for these requires changing the HID report descriptor.
We still need a sensible solution for this. We either have to split the key bitmap between a couple most-frequently used pages (currently there's just one - keyboard page (0x07)) or generate the descriptor each time for a particular layout. But none of these are implemented yet in the firmware.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: Kdash on Wed, 30 October 2013, 11:05:05
Ok, I see.
I simply modified the source code but it does't work..
so..  wait for your good news  :thumb: or I'll  try to modify it other days~ :p
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Wed, 30 October 2013, 11:10:02
You can take the current HID report descriptor, and use the USB HID tool (don't remember the name now, but there is a program which simplifies creation of descriptors) and split it up in such a way that instead of some higher codes (preferably those unused) it includes the Consumer Page. Then you can use those codes to achieve what you want. It will require some documentation reading though.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Fri, 08 November 2013, 09:55:58
Okay,
rev. A testing is over now. Please check out the new thread: http://geekhack.org/index.php?topic=50685.0
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: yasuo on Sun, 08 December 2013, 09:08:00
My layout :D
(http://i.imgur.com/szQhRbQ.png)
I want SW1:swap bs>space,SW2:swap caps>enter

Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: metalliqaz on Sun, 08 December 2013, 09:32:26
Quote from: yasuo on Sun, 08 December 2013, 09:08:00
My layout :D
Show Image
(http://i.imgur.com/szQhRbQ.png)

I want SW1:swap bs>space,SW2:swap caps>enter

I think he means layouts that can actually be built with the GH60...
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: yasuo on Sun, 08 December 2013, 10:42:20
Quote from: metalliqaz on Sun, 08 December 2013, 09:32:26
Quote from: yasuo on Sun, 08 December 2013, 09:08:00
My layout :D
Show Image
(http://i.imgur.com/szQhRbQ.png)

I want SW1:swap bs>space,SW2:swap caps>enter

I think he means layouts that can actually be built with the GH60...
yep,thanks 
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: Manchias on Tue, 02 December 2014, 09:57:10
Please help,

After I run inf-wizard, there are 4 devices came out, but none of them with vid 16c0 and pid 047c. Instead of that :
(http://i.imgur.com/0hPQZVm.jpg?1)

Any idea ?
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Tue, 02 December 2014, 10:03:45
Quote from: Manchias on Tue, 02 December 2014, 09:57:10
Please help,

After I run inf-wizard, there are 4 devices came out, but none of them with vid 16c0 and pid 047c. Instead of that :
Show Image
(http://i.imgur.com/0hPQZVm.jpg?1)


Any idea ?

Please write the revision of PCB, where you bought it and the revision of firmware (if you installed it yourself).
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: Manchias on Tue, 02 December 2014, 11:57:33
Quote from: komar007 on Tue, 02 December 2014, 10:03:45
Quote from: Manchias on Tue, 02 December 2014, 09:57:10
Please help,

After I run inf-wizard, there are 4 devices came out, but none of them with vid 16c0 and pid 047c. Instead of that :
Show Image
(http://i.imgur.com/0hPQZVm.jpg?1)


Any idea ?

Please write the revision of PCB, where you bought it and the revision of firmware (if you installed it yourself).

Once again, sorry for spaming your topic, blog and email.

My pcb is rev B. I got it from taobao.com and I did not installed it myself. I just try to apply poker layout into your pcb somehow it doesn't work. I spent like a week browse around to find solution but most of my friends haven't own a GH60 before.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: hasu on Tue, 02 December 2014, 12:07:08
Your board doesn't have official firmware, just install it.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Tue, 02 December 2014, 12:12:28
Quote from: Manchias on Tue, 02 December 2014, 11:57:33
Quote from: komar007 on Tue, 02 December 2014, 10:03:45
Quote from: Manchias on Tue, 02 December 2014, 09:57:10
Please help,

After I run inf-wizard, there are 4 devices came out, but none of them with vid 16c0 and pid 047c. Instead of that :
Show Image
(http://i.imgur.com/0hPQZVm.jpg?1)


Any idea ?

Please write the revision of PCB, where you bought it and the revision of firmware (if you installed it yourself).

Once again, sorry for spaming your topic, blog and email.

My pcb is rev B. I got it from taobao.com and I did not installed it myself. I just try to apply poker layout into your pcb somehow it doesn't work. I spent like a week browse around to find solution but most of my friends haven't own a GH60 before.

Quote from: hasu on Tue, 02 December 2014, 12:07:08
Your board doesn't have official firmware, just install it.

Yup.
Try installing the newest firmware from here: https://geekhack.org/index.php?topic=50685.0 (https://geekhack.org/index.php?topic=50685.0)
using instructions from here: https://geekhack.org/index.php?topic=37570.msg717519#msg717519 (https://geekhack.org/index.php?topic=37570.msg717519#msg717519) (bottom of the post)


Also, you might have tried to send a broken layout file.
It's hard to tell if that could brick the board, but I don't have any error-checking of the layout file format, so if the file contains garbage, it might make the keyboard do unpredictable stuff, and almost certainly make it impossible to send new layout. In this case, firmware re-flash is the only option.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: Manchias on Sat, 06 December 2014, 06:50:26
Thank you for your help Komar.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Sat, 06 December 2014, 07:25:11
Quote from: Manchias on Sat, 06 December 2014, 06:50:26
Thank you for your help Komar.

No problem.
Have you fixed the board?
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: Manchias on Sat, 06 December 2014, 07:43:59
Quote from: komar007 on Sat, 06 December 2014, 07:25:11
Quote from: Manchias on Sat, 06 December 2014, 06:50:26
Thank you for your help Komar.

No problem.
Have you fixed the board?

I already re-flash the firmware. However, there is little problem with mapping key using rev B gui.

I copied USB folder from previous version for Win 7, replace base_firmware.hex with ukbdc_gh60_revB-0.3-dev. After gui.py, the layout came out with 4 extra button with id: 40,64,54,43. I deleted them in gh60.xml. But when I load poker.lay, and hit the programming button, this is what I get from the cmd screen:

 (http://i.imgur.com/SJlE3rI.jpg)
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Sat, 06 December 2014, 16:03:26
Quote from: Manchias on Sat, 06 December 2014, 07:43:59
Quote from: komar007 on Sat, 06 December 2014, 07:25:11
Show Image
Quote from: Manchias on Sat, 06 December 2014, 06:50:26
Thank you for your help Komar.

No problem.
Have you fixed the board?

I already re-flash the firmware. However, there is little problem with mapping key using rev B gui.

I copied USB folder from previous version for Win 7, replace base_firmware.hex with ukbdc_gh60_revB-0.3-dev. After gui.py, the layout came out with 4 extra button with id: 40,64,54,43. I deleted them in gh60.xml. But when I load poker.lay, and hit the programming button, this is what I get from the cmd screen:

 (http://i.imgur.com/SJlE3rI.jpg) (http://i.imgur.com/SJlE3rI.jpg)

The extra buttons are supposed to be there, they are used for other physical layouts.
As for programming, I know it's hard to force the GUI to run on windows, and I can't do anything about it so far.
This might not be very helpful, but the best option is to run the program in any linux distribution, and it should work correctly.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: Manchias on Tue, 09 December 2014, 02:35:30
Quote from: komar007 on Sat, 06 December 2014, 16:03:26
Quote from: Manchias on Sat, 06 December 2014, 07:43:59
Quote from: komar007 on Sat, 06 December 2014, 07:25:11
Show Image
Quote from: Manchias on Sat, 06 December 2014, 06:50:26
Thank you for your help Komar.

No problem.
Have you fixed the board?

I already re-flash the firmware. However, there is little problem with mapping key using rev B gui.

I copied USB folder from previous version for Win 7, replace base_firmware.hex with ukbdc_gh60_revB-0.3-dev. After gui.py, the layout came out with 4 extra button with id: 40,64,54,43. I deleted them in gh60.xml. But when I load poker.lay, and hit the programming button, this is what I get from the cmd screen:

 (http://i.imgur.com/SJlE3rI.jpg) (http://i.imgur.com/SJlE3rI.jpg)

The extra buttons are supposed to be there, they are used for other physical layouts.
As for programming, I know it's hard to force the GUI to run on windows, and I can't do anything about it so far.
This might not be very helpful, but the best option is to run the program in any linux distribution, and it should work correctly.

I used linux, try to mapping key. But same mistake like Windows.

ubuntu@ubuntu:~/Desktop/ukbdc_gui$ sudo python3 gui.py
Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python3.3/tkinter/__init__.py", line 1478, in __call__
    return self.func(*args)
  File "gui.py", line 939, in <lambda>
    command = lambda: command("program"),
  File "gui.py", line 847, in on_menu_action
    u.program_layout(binary)
  File "/home/ubuntu/Desktop/ukbdc_gui/ukbdc_lib/ukbdc.py", line 188, in program_layout
    raise RuntimeError("device returned status: %s" % Status.name(s))
RuntimeError: device returned status: unexpected cont packet

This is list of my device, in Linux, may I know how to point the py.gui program to 16c0:047c

Bus 002 Device 003: ID 8087:07da Intel Corp.
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 04f2:b370 Chicony Electronics Co., Ltd
Bus 001 Device 003: ID 138a:003d Validity Sensors, Inc.
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 004: ID 03f0:ae07 Hewlett-Packard
Bus 003 Device 003: ID 045e:0039 Microsoft Corp. IntelliMouse Optical
Bus 003 Device 002: ID 16c0:047c Van Ooijen Technische Informatica Teensy Keyboard
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Thank you for your time.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Tue, 09 December 2014, 04:20:01
Quote from: Manchias on Tue, 09 December 2014, 02:35:30
[...]

I used linux, try to mapping key. But same mistake like Windows.

ubuntu@ubuntu:~/Desktop/ukbdc_gui$ sudo python3 gui.py
Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python3.3/tkinter/__init__.py", line 1478, in __call__
    return self.func(*args)
  File "gui.py", line 939, in <lambda>
    command = lambda: command("program"),
  File "gui.py", line 847, in on_menu_action
    u.program_layout(binary)
  File "/home/ubuntu/Desktop/ukbdc_gui/ukbdc_lib/ukbdc.py", line 188, in program_layout
    raise RuntimeError("device returned status: %s" % Status.name(s))
RuntimeError: device returned status: unexpected cont packet

This is list of my device, in Linux, may I know how to point the py.gui program to 16c0:047c

Bus 002 Device 003: ID 8087:07da Intel Corp.
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 04f2:b370 Chicony Electronics Co., Ltd
Bus 001 Device 003: ID 138a:003d Validity Sensors, Inc.
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 004: ID 03f0:ae07 Hewlett-Packard
Bus 003 Device 003: ID 045e:0039 Microsoft Corp. IntelliMouse Optical
Bus 003 Device 002: ID 16c0:047c Van Ooijen Technische Informatica Teensy Keyboard
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Thank you for your time.


This is weird. It's clearly communicating with the keyboard but there's a protocol error. That's different than windows, where there was no communication at all, the program wasn't recognizing the keyboard at all.
Have you tried programming with the provided gh60b.lay file? Does this work?
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: Manchias on Tue, 09 December 2014, 07:11:01
Quote from: komar007 on Tue, 09 December 2014, 04:20:01
Quote from: Manchias on Tue, 09 December 2014, 02:35:30
[...]

I used linux, try to mapping key. But same mistake like Windows.

ubuntu@ubuntu:~/Desktop/ukbdc_gui$ sudo python3 gui.py
Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python3.3/tkinter/__init__.py", line 1478, in __call__
    return self.func(*args)
  File "gui.py", line 939, in <lambda>
    command = lambda: command("program"),
  File "gui.py", line 847, in on_menu_action
    u.program_layout(binary)
  File "/home/ubuntu/Desktop/ukbdc_gui/ukbdc_lib/ukbdc.py", line 188, in program_layout
    raise RuntimeError("device returned status: %s" % Status.name(s))
RuntimeError: device returned status: unexpected cont packet

This is list of my device, in Linux, may I know how to point the py.gui program to 16c0:047c

Bus 002 Device 003: ID 8087:07da Intel Corp.
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 004: ID 04f2:b370 Chicony Electronics Co., Ltd
Bus 001 Device 003: ID 138a:003d Validity Sensors, Inc.
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 004: ID 03f0:ae07 Hewlett-Packard
Bus 003 Device 003: ID 045e:0039 Microsoft Corp. IntelliMouse Optical
Bus 003 Device 002: ID 16c0:047c Van Ooijen Technische Informatica Teensy Keyboard
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Thank you for your time.


This is weird. It's clearly communicating with the keyboard but there's a protocol error. That's different than windows, where there was no communication at all, the program wasn't recognizing the keyboard at all.
Have you tried programming with the provided gh60b.lay file? Does this work?
I try with gh60_poker.lay provided in this topic. Haven't tried with original gh60b.lay file
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Tue, 09 December 2014, 07:16:52
Quote from: Manchias on Tue, 09 December 2014, 07:11:01

I try with gh60_poker.lay provided in this topic. Haven't tried with original gh60b.lay file
This file is for the previous revision of the board and firmware and it doesn't work with the current firmware.
Still, it shouldn't cause the problems you're getting, but for now please just check if gh60b.lay works for you on a clean firmware.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: Manchias on Tue, 09 December 2014, 10:13:32
Quote from: komar007 on Tue, 09 December 2014, 07:16:52
Quote from: Manchias on Tue, 09 December 2014, 07:11:01

I try with gh60_poker.lay provided in this topic. Haven't tried with original gh60b.lay file
This file is for the previous revision of the board and firmware and it doesn't work with the current firmware.
Still, it shouldn't cause the problems you're getting, but for now please just check if gh60b.lay works for you on a clean firmware.

Thank you Komar, I will try using original gh60 lay tomorrow and let you know.
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: Manchias on Fri, 12 December 2014, 03:23:28
Quote from: komar007 on Tue, 09 December 2014, 07:16:52
Quote from: Manchias on Tue, 09 December 2014, 07:11:01

I try with gh60_poker.lay provided in this topic. Haven't tried with original gh60b.lay file
This file is for the previous revision of the board and firmware and it doesn't work with the current firmware.
Still, it shouldn't cause the problems you're getting, but for now please just check if gh60b.lay works for you on a clean firmware.

I tried with gh60b.lay on Ubuntu. Same thing happen :( error :(. Do you have any other suggestion ?
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: Manchias on Fri, 12 December 2014, 12:39:32
This is the error when I tried to mapping key using Win7 32bits. I don't what it mean by no backend avaiable.

(http://i.imgur.com/heH7U1P.jpg)
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: tlt on Wed, 12 August 2015, 15:15:33
Is ukbdc_gh60-0.2_rc2_std_layout.hex the latest firmware and the one I should be using?
Title: Re: GH60 prototype betatesting [Call for layouts, GUI testing]
Post by: komar007 on Wed, 12 August 2015, 15:23:09
Quote from: tlt on Wed, 12 August 2015, 15:15:33
Is ukbdc_gh60-0.2_rc2_std_layout.hex the latest firmware and the one I should be using?

Nope, use 0.3, here: https://geekhack.org/index.php?topic=50685.msg1109357#msg1109357