Designing Endgame Keeb PCB

[jstein91]

Hey there!

So I've gotten pretty into the mk world over the past year. After spending tons of time trying to find a board that fits all my needs I decided screw it I'll just create my own. So thats what I did.

I went about designing a PCB for a 65% keyboard with a rotary dial and an OLED screen (heavily influenced by the Satisfaction 75 which I would readily buy if someones selling  )

Here is the link to the repo on github: https://github.com/jstein91/Endgame

The V2 is the one Ive put the most time into and the only one thats a completed design.

I would love some input/tips/things i did right/things I ****ed up/etc.

This is the largest PCB I've ever designed, but dont let that stop you from being brutally honest.

I expect it to be an evolving design and as such I played around with designing one that uses an Elite-C (for future proofing). I also plan to add some lighting, either RGB or underglow.
Also I plan to add a TRRS jack and hopefully design an external numpad that can be hooked up via TRRS for the occasions its needed for. Also would love to add some USB hub functionality to the board but thats outside my knowledge/skill at this point.

Here are some pics!

Schematic:



PCB:



3D Front:



3D Back:




TL;DR - I designed a PCB and am looking for advice/input

[Applet]

I think you will get more feedback if you post pics of the layout support, PCB and schematic, rather than the KiCad-files, just a thought from a lazy person (me)

[jstein91]

Here are some photos and such for the PCB:

Here's the schematic:
 Endgame V2 Schem.pdf (258.56 kB - downloaded 263 times.)

Heres the PCB:


3D Front:


3D Back:

[Applet]

Some quick things that come to mind:

• Route the usb-data traces differentially, not just freely.
• There are some 90 degree/sharp turns, those should be avoided
• At some places, ground fill could be poured if you just adjust the routing a bit.

Differential routing:

[jstein91]

Some quick things that come to mind:

• Route the usb-data traces differentially, not just freely.
• There are some 90 degree/sharp turns, those should be avoided
• At some places, ground fill could be poured if you just adjust the routing a bit.
• Polygon pour/fill does not seem to be connected to ground

Differential routing:

Thanks for the input!

As for the USB traces, I know they should properly be routed so that the data lines are around the same length to avoid latency issues, I just had trouble doing that on this one due to where the pins are and it being USB C. I'll have to do some more adjusting though. And I agree about the sharp angles. Im thinking of just deleteing all the traces and giving it another go to see if I can be more efficient.

As to the ground/fill, I get what you mean. It is weird though because there is a ground fill on the entire board and even with that is still made me specifically connect some components to a ground, even after I checked that the fill was linked to the ground netclass. I think(THINK) this is an issue with the Kicad software but if you have any tips on fixing that it would be great.

[Applet]

Yes, it seems some GND is connected to fill, some not.

I'd also recommend adding ICSP/ISP header if you want to change bootloader or if it gets bricked.
I don't think you need a external pull-up on the reset pin, but I'd add one for good measure.
I'd rotate all the switches 180-degrees. South-facing switches hit GMK-keycaps when they bottom out.
You have one Via and trace a bit close to the edge of the PCB.
How are you planning to mount the PCB in a case? I'd add a few mounting holes, even if you currently have no plans for using them.
You have a few traces that I'd move a bit away from the holes for stabilisers and switch holes, there is plenty of room, so no reason for them to be close to the holes (there is always a margin of error from the fab, when drilling).
I'd add more ground vias, especially adjacent to the MCU, crystal and the decoupling capacitors.

Hope I do not come across as bashing

[jstein91]

Yes, it seems some GND is connected to fill, some not.

I'd also recommend adding ICSP/ISP header if you want to change bootloader or if it gets bricked.
I don't think you need a external pull-up on the reset pin, but I'd add one for good measure.
I'd rotate all the switches 180-degrees. South-facing switches hit GMK-keycaps when they bottom out.
You have one Via and trace a bit close to the edge of the PCB.
How are you planning to mount the PCB in a case? I'd add a few mounting holes, even if you currently have no plans for using them.
You have a few traces that I'd move a bit away from the holes for stabilisers and switch holes, there is plenty of room, so no reason for them to be close to the holes (there is always a margin of error from the fab, when drilling).
I'd add more ground vias, especially adjacent to the MCU, crystal and the decoupling capacitors.

Hope I do not come across as bashing

I really appreciate your advice! Ive been working on implementing some of the changes and have rerouted the traces for the data lines. I also added a pull up resistor to the reset switch and an ISCP header.

But after assigning all my rows and columns and the other components, Im out of pins on the MCU. As I intend to add more features to the board I need more pins to do so. Should I change to an MCU with more pins? Right now its set up for the ATmega 32U4 since this seems to be a very common MCU and I know its QMK compatible. Or do I add some serial registers? Im not sure what to do.

Here is the updated schematic so you can see what Im talking about:

[Applet]

Yes, it seems some GND is connected to fill, some not.

I'd also recommend adding ICSP/ISP header if you want to change bootloader or if it gets bricked.
I don't think you need a external pull-up on the reset pin, but I'd add one for good measure.
I'd rotate all the switches 180-degrees. South-facing switches hit GMK-keycaps when they bottom out.
You have one Via and trace a bit close to the edge of the PCB.
How are you planning to mount the PCB in a case? I'd add a few mounting holes, even if you currently have no plans for using them.
You have a few traces that I'd move a bit away from the holes for stabilisers and switch holes, there is plenty of room, so no reason for them to be close to the holes (there is always a margin of error from the fab, when drilling).
I'd add more ground vias, especially adjacent to the MCU, crystal and the decoupling capacitors.

Hope I do not come across as bashing

But after assigning all my rows and columns and the other components, Im out of pins on the MCU. As I intend to add more features to the board I need more pins to do so. Should I change to an MCU with more pins? Right now its set up for the ATmega 32U4 since this seems to be a very common MCU and I know its QMK compatible. Or do I add some serial registers? Im not sure what to do.

Here is the updated schematic so you can see what Im talking about:

(Attachment Link)

Cool

You could free up the col 14 pin by putting those two switches on row 4. You are also free to use the MISO MOSI and SCK for other stuff, just make sure there is nothing that interferes with the communication (putting pins for the matrix there will not cause trouble). If there is not enough pins after using col14 and the ICSP pins I'd pick another MCU, just pick one that is QMK compatible: https://github.com/qmk/qmk_firmware/blob/master/docs/compatible_microcontrollers.md

The implementation of AT90USB64 / AT90USB128 is very similar to the ATmega32U4, the ARM processors are a bit different. The ATmega32U4 is so widely used, so I'd recommend to stick with that, if you can, many can help troubleshoot it etc.

[gipetto]

I like to use a a square ortho matrix to reduce pin count, like in this picture.

The Crushed paper matrix by gipetto.

A short explanation.
Many moons ago I happened across a lost page on wikipedia mentioning how crushed paper is the most efficient form of storage because it utilizes all available space in the compressed area. Although paper is 3 dimensional, the same principle can be applied in 2d.

Crushed paper seldom tears and can be unfolded again into a flat sheet, or a line in 2d. This is useful because the insulated line property is the ideal dc characteristic of a routed pcb, no vias or jumpers. I have used this technique a few times and thought it was documented when pcb reviewers said it was duplexed. However, duplexing typically uses a complicated schematic of set ratios between rows and columns. The crushed paper matrix can be used with any matrix schematic, though naturally a simple square matrix (10x10, 7x7) maximizes the switch count for the number of mcu pins.

So, to start with, count the switches on your design, take the square root, if it is an even number, great, if it's not, round one number up and one number down, i.e square root of 50 switches is 7.07 so pick 7 for rows and 8 for columns (more cols makes routing easier)
Next, open up a paint program and load a screenshot of a layout from keyboard-layout-editor.com. Following the image, draw a line between each switch, each line can only cover the number of rows in the schematic. Do not cross any lines. Be sure to go back and forth to eliminate any missed keys.

In this image you can see that the goal was to increase the apparent thickness of each column, like the corrugations in cardboard.
It's also helpful to aim for each line being a duplicate of the one next to it, this provides space between the lines for traces which run to the mcu. Be sure to number each line with a column number similar to how your schematic is done, usually left to right incrementing. When routing the pcb later, do each mcu trace from the same direction, so top to bottom, left to right, or clockwise, anticlockwise around a pcb.

Next, go to keyboard-layout-editor.com, load your layout, flip the tab over to raw data and delete any non 1U size keycap dimension information for example "{w:1.5}," and re-arrange each key in an ortholinear matrix identical to what you have in your schematic file. save your raw data to a local text file as the website corrupts occasionally.
you can then upload this saved data to kbfirmware.com to get a mostly working code, or a good base to use with a working build from the repo.
If you want to have a standard keymap.c you can rename the center legend on each key to its counterpart from kb.h, for e.g K0000, K0101. Then sort the ortholinear matrix back to its original key position and edit the upper block in kb.h to match.

[Applet]

Yeah, the most efficient conventional matrix should be a 8x9, right (using 68 switches)? So you could get by with 17 gpio, instead of 20

[gipetto]

I'd route it like this, leaving the short trace on column 1 for an iso conversion, but you could also use the 4 spare switch positions, 9x8=72, (72-68) for a rotary encoder, or two without increasing pin count.

[jstein91]

I'd route it like this, leaving the short trace on column 1 for an iso conversion, but you could also use the 4 spare switch positions, 9x8=72, (72-68) for a rotary encoder, or two without increasing pin count.

I dont know why but I just never thought of setting up the matrix that way. I mean it makes perfect sense cause its not like the matrix has to correspond to the actual layout as long as the keys are properly defined for the right pins. I just get so caught up on the visuals of it I guess.

Im slightly confused by your image though. It shows me using 9 COL which I get but how do I come up with the 8 ROWs?

RE using the spare switch positions for a rotary encoder, how would that work? Do I wire the encoder just like it was one of the swites on the column? Ive delt with Rots before but I usually just give them their own pins on.

[jstein91]

So I redid the switch matrix.

Heres how its set up now:



This is what you meant right?

[gipetto]

I illustrated 2 rows to show you how. I didn't do all of them because it would be too confusing. all you do for the first row is to use the key the end of the col trace falls on( in green), for the second row, use the second key down the col trace( in blue)

so, the first row is
1,          2,4,6,7,8,0,=,            home

and the second row is
KC_GRV,q,3,5,y,9,-,backspace,pgup

it's better to sort the keys in keyboard-layout-editor.com because you don't end up with duplicate mistakes.

I don't know how to handle rotary encoders in matrixes tbh. I saw a post by jack humbert on /r/olkb where he said that he added that function in so I assume it is possible. I guess you could look for a keyboard schematic somewhere and reverse engineer it. rotary encoders have two channels and a common ground so they would be covering 2 switches and a third if you wanted to use the push button most alps ec10 come with. of course there would need to be a diode for each switch.

edit yeah, that's what i meant. you could have the short trace on the right hand side to run your rotary encoder off also. it's your choice of course.

edit
you can look at how i did my own if you want, I just allocated the switch names automatically as I was doing everything in the website and firmware files later.

https://github.com/itsnoteasy/misc/tree/master/left_110key

edit, yes that's what i meant. good job, should work well.

[jstein91]

edit, yes that's what i meant. good job, should work well.

Awesome! Really appreciate the help. Ill do some more research on incorporating an encoder into the matrix.

[jstein91]

edit, yes that's what i meant. good job, should work well.

Alright so i got my matrix worked out. Im working on routing the traces. I just want to double check but as long as the keys and the rows are connected together and sent to the right pins, it shouldnt matter the order they are connected in?

Should I do it this way:


or this way:


Or does it matter?

Also can I connect my rows to the MCU from any switch in the row or does it need to be the last in the row?

[gipetto]

either way is fine. from what little i know of rf engineering i understand it's best to avoid loops because they can behave as a resonant circuit (tank circuit) so branches of any kind or just a zig zag line are the ideal. I am appalled that you used a via at every switch, this could add expense and will cause reliability issues. I think you should redo the routing and if necessary, move the mcu beside the usb port to free up room for traces.
this is a pcb i hand routed, i could have done the entire pcb on one side without vias but ran out of room. Though it would be easier to manage through hole diodes than the single sided smt pads you have, nevertheless, I think you should attempt to route it without vias.

in the image you can see the row traces move anti clockwise around the pcb perimeter from the switches, and the column traces move clockwise from the switches through the middle, spaced out in branches. in this way they splice in to each other like two folded hands from opposite directions. your pcb would be easier routed because the diodes are close to the switches and it keeps the trace length short. try to take advantage of your diodes to jump traces where possible, every time you do that it saves a via.

[jstein91]

either way is fine. from what little i know of rf engineering i understand it's best to avoid loops because they can behave as a resonant circuit (tank circuit) so branches of any kind or just a zig zag line are the ideal. I am appalled that you used a via at every switch, this could add expense and will cause reliability issues. I think you should redo the routing and if necessary, move the mcu beside the usb port to free up room for traces.
this is a pcb i hand routed, i could have done the entire pcb on one side without vias but ran out of room. Though it would be easier to manage through hole diodes than the single sided smt pads you have, nevertheless, I think you should attempt to route it without vias.

in the image you can see the row traces move anti clockwise around the pcb perimeter from the switches, and the column traces move clockwise from the switches through the middle, spaced out in branches. in this way they splice in to each other like two folded hands from opposite directions. your pcb would be easier routed because the diodes are close to the switches and it keeps the trace length short. try to take advantage of your diodes to jump traces where possible, every time you do that it saves a via.

Alright. I took your advise and decided to reroute the switches to use less vias. I ended up switching from the Khail hotswap sockets to just a regular switch footprint as it made it easier to route. Maybe I'll try using the hotswaps after I have more experience. Thanks to the change I was able to route it only having to use 4 vias. Take a look and let me know what you think.

[gipetto]

It's serviceable and not bad at all. I can't see very well the traces in the low res image. I don't think you have to compromise by removing the sockets though. electrically they are the same as what you have now. you generally can't help but have vias around the mcu, but even if one fails in the voltage supply the others can carry it. If you upload the files to your github i'll have a go at routing them in the clockwise/anticlockwise manner.

[jstein91]

It's serviceable and not bad at all. I can't see very well the traces in the low res image. I don't think you have to compromise by removing the sockets though. electrically they are the same as what you have now. you generally can't help but have vias around the mcu, but even if one fails in the voltage supply the others can carry it. If you upload the files to your github i'll have a go at routing them in the clockwise/anticlockwise manner.

That would be awesome!

Heres the link to the git: https://github.com/jstein91/Endgame/tree/master/Endgame

V2.5 is the one that has the most recent changes.

[gipetto]

could take a few days to figure this one out. you said you knew how the encoder would be wired up. I have no experience in that, could you describe how it's done, are both encoder pins taking two positions in the matrix?

[gipetto]

I moved around the traces to have a solid ground plane.

[Gondolindrim]

I moved around the traces to have a solid ground plane.

Just a reminder: KiCad needs all files, including your .pro file, to open the schematic and PCB. You only provided the PCB file.

I am not able to open it from here. I checked the GitHub repo but the V2.5 and V3 PCBs seem to be incomplete.

The V2 schematic seems to be intact, so I took a look at that.

Regarding the pullup resistor for the reset, you absolutely need it. Since the reset pin is active low, it needs to be pulled high; making it unconnected might make you run into floating voltages and issues. I even recommend using a debounce RC net (see the debounce picture attached, from the Elongate PCB).

Connector schematic seems perfect; I'd use a 1.5A trip fuse. A USB2.0 connector can hold up to 900mA current, so adopting a 1A hold, 1.5A trip fuse seems more logic in my opinion.

Rotary encoder is fine; however I'd use a debounce net to prevent issues (see rotary_debounce figure attached, from the Tsuki PCB). I'd also recommend using a rotary encoder that has a built-in switch, which very very easy to integrate into the switch matrix. For an example on how to do it, look at the Tsuki or the SharkPCB. This is weird because in the PCB, the encoder used has S1 and S2 pins but they are not present in the schematic, so you used the wrong symbol.

As far as PCB goes, V2 is fine, except for two small details. The MCU crystal is not well routed: one trace has to go to the MCU XTAL_IN pin (I believe pin 16) from the crystal and XTAL_OUT (pin 17) has to go to the capacitor. In your implementation both go to the crystal, which might generate some incoveniences. Also USB data traces should be wired as a differential pair, and you can adjust that using KiCad's integrated routing -- Route > Tune Differential Pair Skew/Phase, which will make little zig-zags on the shortest of the two traces and even them out. This is imperative and using unbalanced differential pairs can effectively brick the PCB, making it unusable.

[gipetto]

I only edited the pcb file, all you need to do is download the github and replace the pcb file with the attachment above.

edit: USING KICAD NIGHTLY.

here's the whole thing.

https://github.com/itsnoteasy/misc/blob/master/Endgame.zip