65% Model F – Open Group Build

User avatar
wcass

06 Oct 2019, 16:53

Manisteinn and I have been chatting since July. I really liked the 3d printed case he designed for a model F keypad and I wanted to test out a few new pad card and controller ideas, so I suggested that we collaborate. Well, we are getting to the point where we need to purchase parts, so I thought it might be a good idea to see if there is any interest – would any of you folks like to participate in a Group Build?

What is a Group Build? It is like a group buy, but you are encouraged to bring something other than money to help design and build the thing for the entire group. Manisteinn is doing the case design and some of the 3d printing. I will be doing the pad card design and will buy some or all of the pad cards. We could use help with additional 3d printing (larger parts can take up to 20 hours each), top plates (plasma or water jet cut and slip roll/curve bending) and maybe someone for soldering, and programming CY8CKit for CommonSense. We could probably use help with project management and communications too. We could do all of this ourselves, but for several reasons – a broader collaboration seems like it might be a fun thing to try.

In the first paragraph, I said that I want to test out a few new ideas, but maybe test is not the right word; refine might be more accurate. My Compact Space Saver Keyboard project used several new ideas and they all worked really well. This one will use a four layer PCB like the CSSK, but with the more traditional curved plate this time. The CSSK used a custom CommonSense controller; this one will use the Cypress CY8CKIT. The CSSK used a one piece compression connector to mate the controller to the pad card; this will use pogo pins for the same kind of effect. And the CSSKs layout … I am probably the only person that actually likes it. I think more folks will like this one. All of the key caps are IBM/Unicomp standard sizes. As with most buckling spring keyboards, you can easily swap ANSI left Shift and Enter for ISO. The stepped caps on the right Shift and right Ctrl should make it easy to find the arrow cluster by feel.
keyboard-layout.jpg
keyboard-layout.jpg (71.73 KiB) Viewed 13460 times

I am going to use this space to document the process. Even if you are not interested in this specific project – I hope you will find some value in it. You will be able to get the design files here too.

Build Partners:
manisteinn - case design, 3d printing
wcass - pad card design

Part List, Supplier, Cost, Design Files, Notes:

kmnov2017

06 Oct 2019, 17:43

I am interested to help. I could help program the Cypress Kit...

User avatar
Redmaus
Gotta start somewhere

06 Oct 2019, 18:58

I could help with soldering, communications, or group management. This looks like a great idea!

User avatar
DMA

06 Oct 2019, 20:22

Curved 4-layer will be a bit brittle, I guess. The benefit is a bit less of a "frame" and not needing a conductive underlay, but how much of a benefit that is, exactly, for this particular project?

For the frame, I shown some time ago that you can make pads just 10mm high (aligned to the bottom of the footprint, unfortunately) - and use newly gained 4mm per row creatively (this doesn't seem to be easy, but seems achievable). Also those dots on top of the key shape can be connected to whatever net, any noise from those will not reach the pad, it's just too far.

Programming the kit is so easy that logistics of sending them out to somebody and back will be the most expensive item on the list - unless there's a significant European participation.

I also can't understand, for this particular case, why not just solder the controller on. Somebody will be soldering pogo pins to the kit anyway and soldered connections are both more reliable and cheaper than pogo pins.

And while we're there, why not make a custom PCB for it (PCB-on-sense-card is not an option because of the curvature).
The reason for a custom PCB is this:
https://www.newark.com/gct-global-conne ... p/72AC6905

Space doesn't seem to be at premium (you found place for the whole kit, after all), so TQFP part (14x14mm, 16x16 with leads) can be used and those are easy to solder, I can easily assemble 50 in a couple of weeks using evenings and weekends.
Size (the headers are standard 2x5, 2.54mm)
Image
Pay no attention to capacitors - my soldering skills are a bit better nowadays.

Risking holywar I'll say that PSoC6 BLE looks possible (CYBLE-416045-02 even has castellated edges hence easily solderable) - but there will be no USB whatsoever until Cypress releases PSoC64 (which they promise for 2 years now but recently even pulled the datasheet), and power/charging controller will be needed (of which I actually have a working prototype).

Saying all that - I can do the controller part, whatever that will be - up to, say, 50 items unconditionally, more than that - PCBA probably will start making sense (and using QFN as a result).

User avatar
wcass

07 Oct 2019, 02:29

The pad card PCB would be 0.8 mm thick - how brittle this is - is worth learning. The bottom plate would be 3d printed, so non-conductive. The smaller footprint for capacitive pads is good to know - i am also working on an MF re-design to take advantage of CommonSense larger matrix support (6x20 matrix for FExt) and reduce trace routing congestion around the tenon holes.

The idea behind using the kit vs custom is cost and simplicity. The thought behind the pogo pins is to make the controller easily to install or upgrade. True, nothing beats a good soldered connection, and that will be the backup plan, but AliExpress pogo pins are only about $4 per hundred and allow the pad card and controller to be completely separate (how reliable these are - also good to learn). When/if a BLE controller becomes available, it might only take a screwdriver and 2 minutes to upgrade.

But a custom CommonSense from DMA is really tempting. I will definitely talk to you about an MF controller.

User avatar
DMA

07 Oct 2019, 03:11

I agree, nothing beats COTS parts. But that part is 20x67mm. That's a lot, especially for 65% form factor. (Also a whole lot of kitprogs..)

Matrix support is actually 8x24 right now.
I can easily make it 10x24 if needed. "8x24" project has 3 pins unassigned. All of them have capacitors, but that just means 2 more minutes of soldering time to get rid of those.

About footprint - get a model F flipper, put some ink on the bottom, stamp the piece of paper with it. All area that doesn't have ink on it is free to use. I remember that space being ~5mm from the top of the flipper leg.

manisteinn

07 Oct 2019, 07:15

Nice to see some interest :)
Image

CAD screenshots, test print (PETG) pics: https://imgur.com/a/aLfioa9

The case design is done in FreeCAD and is mostly parametric and customizable. The top cover is a separate part, easy to edit and replace to change the look (or leave out altogether). I'll eventually publish the complete CAD data.

I don't want to make promises about 3d printed components as the larger printers I use don't belong to me. I might be able to provide some prints if everything works out but no guarantees. There are of course 3d printing services and the possibility to split the case in two parts to fit most printers.

I can however provide lasercut 2mm EVA foam for the housings, and a full base anti-slip pad (example from a numpad I made last year:https://i.imgur.com/RefEiGc.jpg). I'll also order fasteners in bulk so I could send some envelopes with foam+fasteners

I'll be using components from a 5291, so the only things I'm looking for is the PCB, 5.75u spacebar and modifier keys, ideally the nice ones from Ellipse: https://www.modelfkeyboards.com/product ... d-keycaps/
Hopefully someone can help me out with that
DMA wrote:
06 Oct 2019, 20:22
Programming the kit is so easy that logistics of sending them out to somebody and back will be the most expensive item on the list - unless there's a significant European participation.

I also can't understand, for this particular case, why not just solder the controller on. Somebody will be soldering pogo pins to the kit anyway and soldered connections are both more reliable and cheaper than pogo pins.
I had the same initial reaction, but I can see some value in getting a programmed, soldered CS board and just popping it in a case if someone wants to provide that service. Then there's shipping and import fees for EU as you mentioned, cheaper in bulk.

The pogo pins have the same diameter as the through holes, I'm curious to see if soldering them is actually necessary. I've seen the technique used on backplanes with connector pins press fit into THs. Sure, they're square and dig into the plating, but the CS board is 2mm thick and all contact surfaces are gold plated, I can imagine offsetting the board a few degrees or just having a non-perpendicular base would be enough to maintain tension.

DMA wrote:
06 Oct 2019, 20:22
And while we're there, why not make a custom PCB for it (PCB-on-sense-card is not an option because of the curvature).
The reason for a custom PCB is this:
https://www.newark.com/gct-global-conne ... p/72AC6905
I very much agree on the superiority of the USB-C connector, haven't done a non-c project since 2015 :)
The captive cable would be quite robust though, I also did a test print with multiple cable channels: https://imgur.com/a/EIHrZxR

The other day I realised one way to get a (small) flat section without extending the board footprint is to cut slots on the left side of the spacebar, then cut a USB cable channel to the rear.
Image

DMA wrote:
06 Oct 2019, 20:22
Risking holywar I'll say that PSoC6 BLE looks possible (CYBLE-416045-02 even has castellated edges hence easily solderable) - but there will be no USB whatsoever until Cypress releases PSoC64 (which they promise for 2 years now but recently even pulled the datasheet), and power/charging controller will be needed (of which I actually have a working prototype).
Interesting, I've been checking out Cypress's chips and modules (their 1x1cm BLE ones seem nice) for my beamspring project and was planning to ask about the status of your BLE work.

DMA wrote:
06 Oct 2019, 20:22
Saying all that - I can do the controller part, whatever that will be - up to, say, 50 items unconditionally, more than that - PCBA probably will start making sense (and using QFN as a result).
Great!
DMA wrote:
07 Oct 2019, 03:11
I agree, nothing beats COTS parts. But that part is 20x67mm. That's a lot, especially for 65% form factor. (Also a whole lot of kitprogs..)
The board is contained under the pad card so there isn't really any wasted space.

User avatar
DMA

07 Oct 2019, 18:09

manisteinn wrote:
07 Oct 2019, 07:15
I've seen the technique used on backplanes with connector pins press fit into TH
Those are called "press-fit" and are special kind.
Standard square pins won't hold in CY8CKIT-059, holes are too large :)

User avatar
abrahamstechnology

07 Oct 2019, 19:15

Why don't we try using regular Model M flippers with capacitive foil attached to the bottom?

listofoptions

07 Oct 2019, 19:23

abrahamstechnology wrote:
07 Oct 2019, 19:15
Why don't we try using regular Model M flippers with capacitive foil attached to the bottom?
surface area mostly

User avatar
Muirium
µ

08 Oct 2019, 02:55

Discovering this a little late, I'll ask a likely dumb question: could a 60% Model F build be Poker case compatible? There's many good ones out there in classy materials, and, uh, some of us happen to be 60% purists who find any immediately adjacent extra keys to be a recipe for fodsdyrt/

User avatar
wcass

08 Oct 2019, 03:28

It may be possible, but it would probably have to be flat. Most keyboards mount the switches flat and use different key cap profiles on each row to give contour. Buckling spring key caps all have the same profile and they mount the switches on a curved plate to give contour. I also don't think that the stack-up is the same; what is the distance between the bottom of the switch and the top of the cap? How high up is the switch plate?

orihalcon

09 Oct 2019, 00:34

Awesome project! I've always loved the idea of split spacebars if it's possible to implement something that would handle two "Code" keys from a wheelwriter in the spacebar area, I'd be all over that. I don't think this is suggesting much of a major change, just some extra capsense pads PCB for some extra keys in the spacebar area. The above plate could then have some different variants that would determine the placement of the barrels depending on the desired layout :D

User avatar
wcass

09 Oct 2019, 01:51

Split spacebar was seriously considered. It was not selected for 2.5 reasons; Code key caps are rare (you can't order them from Unicomp); the "small" spacebar is 5.75u wide (could not fill this space with just Code key caps); and we have exactly 70 pads already (5x14 matrix - so would need to activate another column).

That said, it would be very do-able. I remember taking the measurements of a code key cap years ago, but can't find it now. IIRC ... is it 2.25u (42 mm) wide?

manisteinn

09 Oct 2019, 07:42

Muirium wrote:
08 Oct 2019, 02:55
Discovering this a little late, I'll ask a likely dumb question: could a 60% Model F build be Poker case compatible? There's many good ones out there in classy materials, and, uh, some of us happen to be 60% purists who find any immediately adjacent extra keys to be a recipe for fodsdyrt/
Not interested in the compact 62 one?
https://www.modelfkeyboards.com/product ... a-compact/
orihalcon wrote:
09 Oct 2019, 00:34
Awesome project! I've always loved the idea of split spacebars if it's possible to implement something that would handle two "Code" keys from a wheelwriter in the spacebar area, I'd be all over that. I don't think this is suggesting much of a major change, just some extra capsense pads PCB for some extra keys in the spacebar area. The above plate could then have some different variants that would determine the placement of the barrels depending on the desired layout :D
wcass wrote:
09 Oct 2019, 01:51
Split spacebar was seriously considered. It was not selected for 2.5 reasons; Code key caps are rare (you can't order them from Unicomp); the "small" spacebar is 5.75u wide (could not fill this space with just Code key caps); and we have exactly 70 pads already (5x14 matrix - so would need to activate another column).

That said, it would be very do-able. I remember taking the measurements of a code key cap years ago, but can't find it now. IIRC ... is it 2.25u (42 mm) wide?
I suggested it early on and made a mockup :)
Image
A code key on the right would interfere with the 5.75u spacebar pad, but an R-shift key would work there. The left obviously doesn't matter as it's unused PCB space, a code key (2.75u) could fit.
There's no need for separate plates in this configuration and it'd be a trivial change on my end.

When wcass mentioned the matrix limitation I left it at that, but it would indeed be cool...

I could try resin casting split spacebars with modified stem placement, the top mold being of a code key and the bottom a cutout for a 2-part key slider insert and stab rod. For those who want even more keys we could work out the optimal stem/stab placement to fit those pads.

Image

I only have the default 5291 keys so I'd need a code key and stem inserts. The inserts would be glued in place as clips would be a pain/unreliable.

This way you'd have two convex thumb keys without the code text in any color, although it wouldn't precisely match the remaining keys. Some might actually prefer that, like the colorful HHKB PBT spacebar look

If left alt is replaced with a 1.75u key (same housing location) the gap can be eliminated

Image

User avatar
wcass

09 Oct 2019, 20:21

Right now, Enter plus back-slash are using 3 pads; Enter covers two pads, but only uses one (same) pad for sensing in ISO and ANSI config, the second for stabilization, and the third for back-slash - second and third swap depending on ISO or ANSI. Hypothetically, i could use the same column and row for both ISO and ANSI back-slash positions. This would free up a pad to use for a second space bar.

If we are to printer custom space bars, might as well fill the 5.75 space; 2.75 + 3. Maybe check to see what rsbseb is up to.

User avatar
Muirium
µ

09 Oct 2019, 20:27

Bear in mind ANSI backslash is really HHKB backspace for many compact keyboard users. So merging backslashes could be a problem.

User avatar
wcass

09 Oct 2019, 20:55

My fault for not explaining it well. The key cap "value" is not so much a problem - it is possition.

Right now, there are 3 possible configurations; ISO Enter and the cap left of that, ANSI Enter and the cap above that, or 1u + 1.25u + 1.5u on the row above. I could "free up" one pad by saying that you can do the first two options, but not the third.

manisteinn

09 Oct 2019, 23:14

wcass wrote:
09 Oct 2019, 20:21
Right now, Enter plus back-slash are using 3 pads; Enter covers two pads, but only uses one (same) pad for sensing in ISO and ANSI config, the second for stabilization, and the third for back-slash - second and third swap depending on ISO or ANSI. Hypothetically, i could use the same column and row for both ISO and ANSI back-slash positions. This would free up a pad to use for a second space bar.

I'd like to keep the enter section as is, my last image is my ideal layout (well, 3278 enter is even better). I don't like ISO/ANSI and would rather give up split backspace if you don't want to add a row.

If you do end up adding a row to the matrix, even JIS would be possible: https://www.pckeyboard.com/page/product/00UE4KPHA
No idea if there's any actual interest, but it'd be the first model-f with a properly sized spacebar, right?
Image

wcass wrote:
09 Oct 2019, 20:21
If we are to printer custom space bars, might as well fill the 5.75 space; 2.75 + 3. Maybe check to see what rsbseb is up to.
Thanks for linking the thread, very interesting. Here's rshift and code for anyone curious: viewtopic.php?p=366205#p366205

I wouldn't want printed space bars, the surface quality isn't comparable unless you use expensive professional printers/services. Then there's wear and degradation, my cheap SLA prints yellowed within a year.

This is what I get for 0.1€ worth of PU resin:

Image
Image

Provided I get the mold right (doesn't seem too difficult) I could do a bunch of keys and take color requests, although I wouldn't guarantee an exact match.

User avatar
wcass

10 Oct 2019, 20:01

We could make a 3u space bar with posts equivalent to 1.5+1.5 and adjust some things a bit.
Then all of these become available ...
bottom row.png
bottom row.png (6.54 KiB) Viewed 12870 times

manisteinn

10 Oct 2019, 22:32

Let's compare the options

Your suggestion (2):
- The 5.75u spacebar pad interferes (I personally don't mind)
- AFAIK a 3u key doesn't exist. I could attempt slicing my 9.75u spacebar to create one, but there'd be a visible seam. Ordering a quality 3dprinted one and casting it is an option, that's still added cost and wouldn't precisely match the surface finish of the remaining caps.

My suggestion (1):
- Nonstandard 1.75u l-alt key when using split space, a blank/incorrect legend one could be used instead (caps/ctrl/shift/fn), or a standard 1.5u one with a gap.
- Space can't be replaced with 4 1.5u keys, an ugly gap is inevitable.
- A single 2.75u space (red) requires a separate bottom mold due to stem location, the green one is also possible with a separate mold. Annoying but not a big deal.

KLE layout, please correct if I got something wrong

Image

Edit: Realised yet another option with the green spacebar is possible, added

manisteinn

12 Oct 2019, 09:23

After realising that Model-M trackpoints don't actually go through the plate (no room on Model-F) I thought I'd investigate if it'd be an option for this project. This has nothing to do with the pad card so that's not a concern, the ribbon also conveniently goes to the right which is empty space in the lower case.

Module from rubber IBM dome board pictured (through plate so unsuitable). Also an old dell latitude stick

Image

I asked Unicomp about buying only the stick+ribbon, they told me the stick+USB/PS2 assembly is available for $30. Another option is a full board for $105 which also gets you a full keyset with G/H/B key cutouts and a bunch of extra parts.

I've seen some criticism on the tracking quality compared to the IBM TPs, not sure if that's due to the controller or the actual stick. In any case I'd prefer to connect the ribbon cable to an original TP controller which is vastly smaller and also provides a middle scroll button. The resistance curves could be wildly different but it'd be easy enough to try out, the connector looks like an ordinary 0.1" pitch non-ZIF one.

There are different ways to handle the host connection; connecting to the cypress via UART (P12 pins are in use unfortunately) or running both through a usb hub IC (tp > pro micro with tmk > usb).

Mouse keys could be extra ones mounted on the top case and wired to the TP controller. Kailh LP for example, either standard keycaps or TP keys (actually pretty nice doubleshots) glued to the stem.
Another option is to use the extra bottom row keys by wiring GPIOs from the cypress to corresponding TP pins and adding code to trigger them on relevant key activation.

The UART method is obviously more work, I'd use the usb-hub method for testing.
In any case this obviously require a bunch of manual soldering etc.

M13 ribbon: https://youtu.be/iqvHXtp9VSU?t=467
Unicomp ribbon https://youtu.be/_5Eir8rEHbY?t=271
Unicomp review https://www.youtube.com/watch?v=c4ERdrsvQkE
More pictures: https://blog.noq2.net/unicomp-endura-pro.html

The above picture also shows the potential 5.815mm gap between 2.75u space keys (XDA keys pictured), IMO not necessarily a bad thing. discrete LED or edge lit acrylic indicators could look nice, clearly visible between the thumbs.

A few more CAD versions:
Spoiler:
Image
Image
Image
Image
Feedback/ideas appreciated

Edit:

Forgot to add my thoughts on the layout options, I think both have advantages:
- Mine enables nice 2.75u casts and 1.5u ctrl/alt with the option of omitting the win key. And of course the 5.75u spacebar.
- wcass's enables off the shelf keys to be used throughout with 1.25u win/alt for those who prefer. As I mentioned the 3u keys wouldn't be en exact match, but that's not inherently bad. Perhaps someone wants to create a custom flipped spacebar or something :)

As commonsense handles individual thresholds I wonder if using offset pads could actually work reliably.
Also, seeing as both share the same number of pads offset by a couple of millimeters perhaps both versions could be provided if there's enough interest?

User avatar
DMA

15 Oct 2019, 02:15

any GPIO can be used for an UART. i2c is a different beast, but normal UART is non-judgemental about ports.
Current pinouts leaves 3 GPIOs free. Can't remember if that count includes pins with capacitors or excludes them - but there's no need for full 8x24 matrix so pins can be reclaimed.

I have a couple (who am I kidding.. about 20) thinkpad keyboards. They have, among themselves, about 3 different designs of the stick and controller. Are they using the same protocol? If so - I can implement trackpoint interface. If not - I'll need a test device.

I would like to NOT implement "GPIO-based" keys as I want to keep controller doing one thing. This doesn't _completely_ rule out cypress for the mouse keys, as adding diodes will likely not interfere with capacitive sensing on the same row. Needs testing tho.
But if TP controller can handle mouse buttons - you should use that ability.

manisteinn

15 Oct 2019, 07:00

I can imagine most people would harvest components from a XT/5291 as it's the most common F board with the least desirable layout. Here's a parts list:
Spoiler:
XT/5291
=======
Provides:
- 82 housings
- ISO/ANSI alphanumeric keys except ]} key (can be substituted by numpad 1-9 for same color)
- 12 1u grey keys as long as incorrect legends isn't a dealbreaker.

Needs:
5.75 space version:
- 70 housings (12 spare)
- space key, possibly wire clips depending on plate design
- tab, caps, lshift, small rshift, 1.5u ctrl, (1u win), 1.5u alt*2, 1.75u ctrl, ISO/ANSI enter and possibly ANSI \|
- stab housing inserts

Split:
- 73 housings (9 spare)
wcass, perhaps you'd like to add this to the main post? Feel free to edit/add info.

DMA wrote:
15 Oct 2019, 02:15
any GPIO can be used for an UART. i2c is a different beast, but normal UART is non-judgemental about ports.
Current pinouts leaves 3 GPIOs free. Can't remember if that count includes pins with capacitors or excludes them - but there's no need for full 8x24 matrix so pins can be reclaimed.
I wasn't sure about UART, thanks for the info. I did know about the I2C pins though so they were kept clear for BLE or other functionality
DMA wrote:
15 Oct 2019, 02:15
I have a couple (who am I kidding.. about 20) thinkpad keyboards. They have, among themselves, about 3 different designs of the stick and controller. Are they using the same protocol? If so - I can implement trackpoint interface. If not - I'll need a test device.
I also have a bunch of various tp boards :) I believe the protocol is common to all of them, but there are different controller ICs.
Awesome that you're willing to implement it!

Board version comparison: https://geekhack.org/index.php?topic=55 ... msg1291412
Protocol pros and cons: https://beta.docs.qmk.fm/features/feature_ps2_mouse
IBM specifications, design guides and utilities: https://web.archive.org/web/20100526161 ... nload.html
TPM749 datasheet: http://www.datasheetcatalog.com/datashe ... M749.shtml
TPM754 datasheet: https://www.mikrocontroller.net/attachm ... tpm754.pdf
DMA wrote:
15 Oct 2019, 02:15
I would like to NOT implement "GPIO-based" keys as I want to keep controller doing one thing. This doesn't _completely_ rule out cypress for the mouse keys, as adding diodes will likely not interfere with capacitive sensing on the same row. Needs testing tho.
But if TP controller can handle mouse buttons - you should use that ability.
I'd absolutely use the TP controller for mouse keys, what I meant by GPIO is toggling an output pin when a certain key in the main matrix is pressed. I'm not even sure anyone would want that, just thought I'd mention it as a possibility. Not at all something I'd expect you to spend any time on.





New test prints:

Angled CS carrier with pogo pins (not the planned conical head type).

Image

Image

A full width version fits diagonally on the prusa buildplate and can be customized for USB-C breakout board, BLE+battery, trackpoint controller, solenoid etc. Easy to swap out in the future.

Image

I'm planning to print interlocking 2-part base and plate pieces next to see how that turns out.

The trackpoint thumb key test print above uses skcm oranges and printed stems. Video (with sound)
The outer keys are alright but they interfere when pressing the middle button, the travel is way too long. I'll do a kailh LP print later, I don't have any atm.

User avatar
wcass

15 Oct 2019, 19:55

i think it is worth trying - make the bottom row pads slightly wide to accommodate as many different layouts as we can. We would need one more pin for a new column, though. Any suggestions as to what pin to use? And what pins to use for the TP option - with consideration for routing? Though i suggested it, maybe we should just give up on the pogo pin idea.

I will be visiting friends in San Francisco the week of November 9 and plan to go to the meetup in San Jose that Saturday. I will bring the CSSK for folks to play with and will talk up this project.

manisteinn

16 Oct 2019, 18:17

wcass wrote:
15 Oct 2019, 19:55
i think it is worth trying - make the bottom row pads slightly wide to accommodate as many different layouts as we can. We would need one more pin for a new column, though. Any suggestions as to what pin to use? And what pins to use for the TP option - with consideration for routing? Though i suggested it, maybe we should just give up on the pogo pin idea.

I will be visiting friends in San Francisco the week of November 9 and plan to go to the meetup in San Jose that Saturday. I will bring the CSSK for folks to play with and will talk up this project.

A flexible bottom row would indeed be nice :)

J1 unused pins are 12.0,12.1 (I2C), 12.7, 2.2 (SW1) and 2.1 (LED). P12 can't be used for sensing and I'd like to keep I2C, so I see two options:
- Add a sixth row using 12.7 and split the bottom row. Looking at the current bottom layer that doesn't seem too difficult.
- Add a column using 2.2, the onboard switch can't be used but I don't think that's a problem. 2.1 could also be used by desoldering the LED

The TP option would only use J2 pins so it doesn't affect the pad card. I've already done the pogo pin case design, so unless we're going for a custom controller with a different pinout I can't see that eliminating them makes a difference at this point. In any case I can do another case version where the CS board attaches to the "roof" and wires are used for soldering to the pad card.

User avatar
wcass

17 Oct 2019, 05:32

I finally found my cheat sheet with post position measurements on it. There is about 1 mm between caps, so the actual caps are about 1 mm smaller than this. It is marked to .001 precision, but don't believe that. If you are off by 0.1, everything will work fine and no one will notice. I would not be surprised if IBM designed in millimeters not mils; 1u = 19.00 not 750
Model F key mm spacing.png
Model F key mm spacing.png (25.28 KiB) Viewed 12456 times
It looks like the "Code" cap posts are not where you would expect them to be. All of the other multi-wide caps are composites of other caps; ISO Enter is 1.5 over 1.25; ANSI Enter is 1 + 1.25; ANSI left Shift is 1.25 + 1; right Shift is 1 + 1.75. I was expecting Code to be 1.5 + 1.25 but it is not. It is closer to 1.5 + 1 + 0.25. With the posts where they are, the space bar is best replaced with a Code plus two 1.5u caps.

As rare as Code caps are, i expect that we would have to make these - and convex 1.5 and 3.0 to complete the row options we want to offer. If we commit to that, It may be more efficient to ignore the Code and just do just two - 1.4375 and 2.875 - like this ...
F65 pad card.png
F65 pad card.png (32.35 KiB) Viewed 12456 times

manisteinn

18 Oct 2019, 20:06

Measuring across 9 1u keys on my 5921 plate it seemed closer to 6" than 152mm

Thanks for the graphic, good to know.

I suspected my red option above might be the actual code key stem placement, isn't that what you're suggesting? L>R: 1.5u key, 1u key and 0.25u gap.

Ignoring the code key doesn't make sense to me as it's the only one that can be cloned practically 1:1 with minimal investment. Convex 1.5u keys occurred to me too, I'd like to experiment with splicing and smoothing casts for new molds and see what results I can get. 3u is also an option using this method.

Do you have another process in mind for these keys?

User avatar
DMA

19 Oct 2019, 12:46

Almost accidentally I'll also be visiting Bay Area on that week and also plan to attend the meetup.

Updaet: disassembled the trackpoint board I have. Not that hard to direct-sense, although translation of the inputs may be difficult (especially if click detection is desired - it's currently built as "sense total current consumed by trackpoint assembly").

I would prefer to sense strain gauge resistances directly, but that is a bit problematic with current stick designs.

As for pins - once you guys determine final matrix size, we'll have lots of unused pins.

..or we can always go for the 100-pin part. that's +16 GPIOs right there.

manisteinn

28 Oct 2019, 23:24

Didn't notice the edit until now.
DMA wrote:
19 Oct 2019, 12:46
Updaet: disassembled the trackpoint board I have. Not that hard to direct-sense, although translation of the inputs may be difficult (especially if click detection is desired - it's currently built as "sense total current consumed by trackpoint assembly").

I would prefer to sense strain gauge resistances directly, but that is a bit problematic with current stick designs.
Interesting, would you mind elaborating on the stick design issues? I personally don't care for click detection, but good drift detection would be important. Looking forward to your results in any case!

DMA wrote:
19 Oct 2019, 12:46
As for pins - once you guys determine final matrix size, we'll have lots of unused pins.
Unless you need specific pins there's plenty available on J2, none of them are used for the matrix. I can't imagine there's a need for more than the single extra row/col pin
DMA wrote:
19 Oct 2019, 12:46
..or we can always go for the 100-pin part. that's +16 GPIOs right there.

What do you have in mind for these extra pins?
I do like the idea of a custom controller with an onboard type-C port, FFC connector for the trackpoint, BLE+battery charger, LEDs etc...

I've been down the road of feature creep before using extra boards, wires, connectors etc and ended up doing a single board with no clutter. In this case there are very few required components (as seen on the CSSK controller) and all the extra functionality is a bit of a pain with separate modules. I wouldn't mind spending some time on a custom board for this project, whether it be just adapting the case or layout. All useful experience for my planned beamspring board.

As I mentioned I've already done the 059 board case design so unless we change the connector (is there any reason to?) that's still an option if anyone wants off the shelf stuff with no SMD soldering and an integrated cable.

Case update

I found a (second!) steelseries M800 in the recycling room and did a bottom row + TP buttons test print with some harvested switches. I suspect the previous owner got a little frustrated with the notoriously awful stems :)
Spoiler:
Image
These switches are 5.15mm taller than Kailh choc but have identical travel, using chocs wouldn't require any major case modifications. I'm still not quite happy with the original middle keycap with 3mm travel, they were designed to pivot after all...

Album

TP keycaps
Square keycaps
Turn sound on if you've ever wondered what a cardboard PCB sounds like :)

I may have some model M components lined up but if anyone has a wheelwriter code key I'm still interested, I could even return it after making the mold.

Post Reply

Return to “Workshop”