Add pins for Matias switches if possible

[spuder]

Not impossible, but difficult

[mondalaci]

I've seen two examples of implementing this. I assume that the double hole version probably works better, but maybe we should ask Matias.

[spuder]

I've contacted Matias support a couple of times asking if they have cad files with no response, the VP of engineering will get back to me. I haven't been able to find any github projects that contains a matias libraries, though this one looks promising.

https://github.com/kiibohd/pcb/tree/master/ICED%20-%20Right/prettylib

[spuder]

Matias switch cad files can be downloaded from here:

http://matias.ca/switches/Matias_Switch_3D.zip

They are in the format .EPRT .IGS and .STEP They will need to be converted to a .kicad_mod file

Here are the blueprints:

Quiet Click http://matias.ca/switches/quiet/blueprints/?p=4

Click http://matias.ca/switches/click/blueprints/?p=1

Quiet Linear http://matias.ca/switches/linear/blueprints/?p=1

[mondalaci]

Great job! Looks like all of the above information is indirectly accessible via http://matias.ca/switches/

Just emailed Matias and asked them about the suggested universal switch footprint along with some further info.

[spuder]

I spent some time creating a custom part from the blueprints, only to later find that the buttons library included in kicad already includes a matias part!

The only consideration is that it uses relatively large pads. On the cherry MX, the holes are 1.5 mm inner diameter and 2.5 mm outer diameter.

The matias library has 1.5mm inner diameter and 3mm outer diameter. Not a problem, just needs a little extra clearance.

All 3 of their switches use the same layout.

The other consideration is that the pins numbers are swtiched between the cherry mx and matias libraries (pin 1 is on left in matias, right side on cherry)

[spuder]

This has been completed for the left hand side. https://github.com/spuder/electronics/tree/feature/%2313_matias It has the following considerations that need to be reviewed

• 4 new vias near iso switches are different from the via part that is in the ugl library. I don't see a way to change the built in via into a ugl:via

• Switch 27 has a hole that goes off the end of the board. Will that cause a problem?

The following are items that shouldn't cause problems, but should be closely inspected

• verify that there is enough space for the vertical capacitor

• verify the new layout of capacitors has enough room

Lastly, because of the new switch layout that includes the stabilizing holes for the cherry mx boards, there is a DRC that fails. There is no way around this. We could:

1. Allow the DRC to fail for the overlapping pads
2. Create a new custom part that includes strangely shaped holes

Neither solution is ideal. There has been some discussion in the kicad forms on how to handle this situation.

https://forum.kicad.info/t/multiple-pin-components/2006

[spuder]

I spoke with matias. They don't offer any sample kits, but they will sell me 3 keys (one of each type) for $10. Otherwise we would need to buy a 200 key set for $50 (plus another $50 for the keycaps).

http://matias.ca/order/#switches

[mondalaci]

Sorry for the late reply, these have been busy days.

The most important thing is that the Cherry switches should probably be reversed for optimized backlighting. The reason is that unlike most keyboards the UHK makes heavy use of the front side of the keycaps for featuring the labels of the Mod layer. Because of this, the front labels should be lit. This needs the LEDs to be featured on the user-facing sides of the switches, not the other way.

Above is the KBT Pure 60% keyboard to illustrate my point.

In light (no pun intended) of the above, what route would you take, Spencer? I'd rather vote for reversing the switches which would negate some or all of your work. I'd hate to do that but I think it'd make sense to future-proof the design in this respect.

Please let me answer your other questions too a little bit later.

[spuder]

I agree reversing the part would be best. Doing so would be a very big change and I don't know how soon the board is to being finalized and delivered. I won't be sad if we don't use the work I've done so far because it has been a learning experience. I've used eagle, but never kicad.

Two approaches

Iterative

Keep working on the board in phases. Ship the version that is ready at the final date.

6.0 => matias + cherry mx stabilizer 7.0 => reversed switches 8.0 => led lights (with reversed switches).

Incremental

Overhaul board to have all the desired features

reversed switches + matias + cherry mx stabilizer + led lights

---

It all comes down to timing. I estimate the latter would require changing over 30% of the board layout, and would take several months plus new prototypes. If you think there is time, I'm willing to help either way.

[spuder]

@mondalaci I've been thinking about this more.

I'm ok to throw away the work that I've done on the matias switches, though I think it still might be useful because while adding the cherry mx stabilizer holes, I've moved traces and components out of the way. Rotating the part 180 degrees will reuse those holes.

Here is what I think is the best course of action

To the master branch:

• Add the new pogo plugs
• Swap the atmega for the teensy
• Add the 4P4C

Then try and merge my matias branch. If the merge works, we just need to rotate the components. If the merge doesn't work, then I'm ok to start over. I'm much faster at kicad now.

I suspect this would take a few weeks. Once that is done:

If sufficient time, add the led circuitry If approaching deadline, skip the leds and get a prototype made.

Thoughts?

[spuder]

There is a major obstacle to rotating the keycaps around

switch 13 might need to be rotated 90 degrees, or left upside down not sure if that would make the led lighting look weird.

[mondalaci]

This one shouldn't be a problem. Just talked to Andras and he said that the FFC connector can be moved a little farther away from SW13. Relative to SW13 the new position of the FFC connector should be x-4.364mm and y-11.257mm.

[mondalaci]

Thanks for elaborating on the two approaches, good thinking! I'd rather prefer your incremental approach (reversed switches + matias + cherry mx stabilizer + led lights).

But before executing this complex change it'd be worth to wait for Andras to overhaul the soft keepout areas and slighly tweak the shape of the PCB based on the updated CAD data. He should be ready on the upcoming week, and after that this sweeping change could take place.

At this point I'm only unsure about how to implement LED backlighting for Matias switches. Unlike for Cherry switches this is rather nontrivial but the above overhaul shouldn't be affected by adding Matias LEDs later on.

[mondalaci]

Regarding the overlapping stabilizer pins of the Cherry switches I think the best solution is to create two additional hybrid footprints that are the same as the hybrid footprint except without left / right stabilizer pins. We could use one of these modified footprints wherever necessary.

[mondalaci]

Thanks for looking into Matias keycaps, Spencer! I'm not terribly worried about them right now. I'm rather concerned about future-proofing the PCB to make it compatible with Matias switches. We should be able to scavenge most (if not all) of the Matias keycaps from existing Matias/ALPS keyboards that can be purchased from eBay for example.

[spuder]

For reference, the ergodox infinity was recently updated to support all major keycaps

https://www.massdrop.com/buy/infinity-ergodox?utm_source=Sailthru&mode=guest_open&utm_medium=email&referer=SQPK6L&utm_term=Community%20-%20Style%20-%20MAU%20(Active

• Cherry
• Matias
• Gateron
• Zealios

It also has usb3 support

[mondalaci]

Good find!

I can't see how Gateron differs from Cherry. I think Gateron simply has a single version featuring fixation pins. Is Zealios different from the Cherry? I don't think so. It's nice that Matias is supported but elongated holes might be problematic for soldering purposes.

[mondalaci]

Please let me answer the rest of your questions, Spencer.

It shouldn't be a problem that switch 27 has a hole that goes off the end of the board. Worst case scenario: the stabilizer pin in question will be cut off. But Andras will try to make space for the stabilizer pin in the case.

The vias in question can't be changed to ugl:via because these vias aren't separate modules. You can simply choose the desired via from the via combobox that is located rightwards of the track width combobox below the top menu and then right-click on the via, select it from the pop-up menu, then click on the Change Via Size and Drill menu item.

I think there should be enough space for the vertical capacitor.

When you said "verify the new layout of capacitors has enough room" did you mean resistors? I assume you meant the R22 and its close friends. We'll end up using a resistor network instead of the individual resistors so as long as the DRC is ok the current layout it should be fine.

[spuder]

For reference, it looks like the corsair k70 uses upside down cherry mx leds. The keycaps also have the transparent letters near the top

[mondalaci]

Almost every keyboard on the market uses upside LEDs. Downside LEDs only make sense when the letters are not only top-printed but side-printed, too.

[spuder]

@mondalaci I see you added a git submodule for the kibohd footprints.

I've looked into using their footprint instead of the one I made.

https://github.com/kiibohd/pcb/issues/3

Thoughts on using their footprint?

Pros:

• Tested

Cons:

• Matias switch holes are slightly different from matias blueprints
• Can PCB manufacture drill oblong shaped holes?
• Is CERN license compatible with UHK license?
• PCB will 'look' kind of like the ergodox with the oblong holes

If you don't have a problem with these, then I suggest we just use their footprint instead of the one I made.

[mondalaci]

@spuder I'd prefer to use your version mainly because it should be easier to solder due to the circular drill holes. I've only added the kiibohd repo because it may be worth to use their Kinetis processor module.

I didn't think that license incompatibility may be an isssue. The way I though about it is that these are two separate projects. Would it be problematic to use a CERN-licensed component in a GPL-licensed project?

[mondalaci]

Done.