GH60 prototype betatesting [Call for layouts, GUI testing]

[WhiteFireDragon]

@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.

[alaricljs]

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.

[WhiteFireDragon]

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.

[kmiller8]

@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





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

[jdcarpe]

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.

[kmiller8]

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.

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"

[jdcarpe]

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|
     * `-----------------------------------------------------------'
     */


[gnubag]

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.

[jdcarpe]

You can certainly do that. It's in hasu's keycode.h. From hasu's github (https://github.com/tmk/tmk_keyboard):

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)

[mkawa]

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?

[WhiteFireDragon]

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.

[mkawa]

switch pads.

not tinned -> flux -> heat -> flow

tinned -> heat -> flow

not a big deal either way, just curious

[WhiteFireDragon]

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.

[mkawa]

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.

[__red__]

<<==--  Not a fan of pre-tinning...

[komar007]

The pads are not tinned, but they're gold-plated. That's enough for easy soldering.

[__red__]

The pads are not tinned, but they're gold-plated. That's enough for easy soldering.

Enig ftw!

[sordna]

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.

[__red__]

Right, but tinned PCBs are **horrible** for doing SMD.  The components fall off the pads.

[mkawa]

gold plated? sweet!

[mkawa]

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..

[sordna]

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?

[mkawa]

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.

[gnubag]

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?

[mkawa]

yep, exactly. the machine screws and nuts are used to apply pressure between the hold down plate and PCB

[mkawa]

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

[jdcarpe]

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.

[mkawa]

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.

[IvanIvanovich]

A (+) is marked on the switch housing, does it not match up correctly on the pcb?

[mkawa]

unless i flipped it last night (i was tired...) it doesn't seem to

[komar007]

Good point. I'll add polarity info to the silkscreen in the final version.

[mkawa]

just test-fit in a PURE case. fit looks good modulo what has already been mentioned

[rknize]

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.

[mkawa]

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

[IvanIvanovich]

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.

[IvanIvanovich]

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.

[IvanIvanovich]

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.

[hasu]

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
};


[IvanIvanovich]

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?

[hasu]

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
};


[IvanIvanovich]

Ah ok I see. That is simple enough. I will give it a try when I get home from work.

[IvanIvanovich]

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.

[hasu]

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.

[IvanIvanovich]

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.

[IvanIvanovich]

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?

[alaricljs]

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:

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

[komar007]

It's also normal for my firmware, simply because I haven't implemented it yet, but it will be available for sure.

[IvanIvanovich]

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.

[jdcarpe]

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.

[IvanIvanovich]

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.