PolyKybd (Displays In Your Keycaps)

Project Logs

Collapse

Finally, After 2,5 Years!
thpoll • 05/24/2023 at 05:06 • 0 comments

It is finally working! Both sides can be used without modifications! 😁

But that is only for the hardware of course, software is never done as we all know!

Current Software Work

The code is already much cleaner and my current schedule is about testing through the optional devices like rotary encoder, pimoroni trackball and cirque trackpad:

- The rotary encoder works.

- The pimoroni trackball needs a QMK update as it has some issues in my version (the cursor becomes very shaky). To be done soon...

- The 23mm cirque trackpad works after resoling some configuration issues. It is a bit small, so I might try the next size as well.

Open Software Issues

- The status display on the right side (slave) turns on unexpectedly after the turn-off timeout (just resolved minutes ago, so this is also done)

- An issue I had in the past: RGB LED matrix flickers on the master side. Maybe because I changed the LAYOUT macro to reflect the key orientation..? Need to check if I have to do the same for the led_config.

- Easy way to configure the layout. Right now I still have to flash the firmware every time, but at some point I would like to switch to something like Vial so that can be done without flashing anything.

- Some more Icons for all the special function keys.

So you see, there is still plenty of work left.

Further Software Improvements Ahead

- This is out of scope for now but definitely the goal: To have a program on the host side to switch the OS input language and also send program context information to the keyboard so that customized symbols can be displayed.

- To avoid burning out the OLED displays, I plan to shift the displayed content slightly once a while. This is nothing fully developed yet, more an idea.

Final Touches

The PCB is in a production ready state, however I would like to apply a cosmetic change to the silkscreen (some pin markings are on the wrong side - luckily only on the silk screen).

And this is more about the general mechanical design:

If possible, I would like to have some plastic inserts for the flex cable slots:

With that, the edges would be soother and make the flex cables maybe life longer. I had no such issue so far and the edges are not rough, but if it is possible, I'd like to try. It sounds like an improvement to me. I was also thinking about plated slots, but these have size limitations which makes it impossible (at least at JLCPCB).

Layout

Of course everyone can come up with an own layout, but let me quickly show off my current choice (and might change soon again):

I started with a symmetric layout similar to Ergodox. With the number keys 1~5 on the left side and 6~0 on the right and in a similar fashion distributed the letters.

However, I'm really used to the traditional stagger and there, the left and right hand finger assignment is distributed rather un-symmetrical. Maybe this changes at some point, but for now this layout is much easier to type!

Your perfect layout might look different... let me know in the comments below~
Revised Left Side & 3D Print Fine-Tuning
thpoll • 04/27/2023 at 05:20 • 0 comments

As promised in my last post, I transferred the (for now) finalized PCB design from the right to the left side and already ordered 5 assembled boards that are in production right now!

The same thing was needed in the past when transferring the initial PCB design from the left to the right. This time, it turned out less painful (TBH I would like to automate a lot of things, maybe with skidl and pcbflow as mentioned in that article: https://kbd.news/Keyboard-as-Python-code-1834.html).

At the same time, I was iterating on the 3D resin prints. Here is the case, which was an almost 100% fit. I did print it first on my FDM printer before, but the tolerances are just a bit different:

The gap between plate and case is a bit larger than I wanted it to be. The fix was easy and the new version should be spot-on!

On the picture above, the print looks a bit scratchy from the post processing, but it is not so pronounced under normal light conditions. In fact, I was surprised how great all the parts turned out.

Only on my second batch, I had a few parts with some excess material here and there, that in my opinion, comes from a faulty resin printer LCD/mask:

You can see a little blob on the middle element. I hope that was just a one-off issue.

The cirque trackpad mounts do fit. However, I have to raise them a bit higher from the plate, otherwise the finger drops too much down when reaching for the trackpad. Also, the keycap stems need some more tuning:

While I can just push the FDM print onto the MX-cross of the switch, the resin print is not so flexible and then sometimes cracks. Making the cross cutout at the bottom just a little bit bigger should fix that.

While waiting for the assembled PCB, I'm working on the software side and it is about time to do that :)
Revised Right Side: Final Version?
thpoll • 04/08/2023 at 14:59 • 2 comments

If you have been following my blog posts, you know that a little mistake with my last PCB prevented me from using it as a keyboard: Pin 1 of all OLED displays was on the wrong side.

So I had to route half of the PCB again... Of course I took the chance to rectify some things I was not 100% happy with in the first iteration.

Right Side V2 Changes:
- The RP2020 and flash memory moved about 10mm away from the switching regulators as the space in between was very tight.

- The reset and boot button, as well as the debug port moved to another location as it turned out inconvenient.

- The host USB-C port got an ESD protection chip and I added a resettable 300mA polyfuse to the board to give it perfect protection in case of shorts or similar.

- The non-inverting buffers I used were actually for 5V and not 3V3 so I decided to change them with similar ones, now matching the supplied voltage (even though they worked without any issue).

- I set the current limit for the the displays and LEDs to 250mA as all displays together could potentially draw much more current (all pixel on + max brightness), not even considering all LEDs set to fullbright. Why 250mA? The USB 2.0 specification has a limit of 5V at 500mA (2.5 Watts). With both sides connected (2x250mA) and a display voltage supply of 3.7V I could reach 1.85Watts. That leaves enough room for 2 MCUs, 2 status displays, some other components and losses (also the switching regulators are not perfect). If it turns out to be too strict, I can set it to a higher value by swapping a few resistors.

- With esthetics in mind I changed the package of some components, but the IC type stayed :)

Ready? Set. Go!

I felt very confident and therefore, ordered 5 fully assembled boards with ENIG finish!

And... surprise, surprise: The boards look amazing:

Flashing the RP2040 worked and after connecting all displays without any key switches, I could see that I didn't mess up revision 2 ;) Everything is working!! No bodge wires, no software fixes to work around hardware issues!

Professional 3D Print

Almost at the same time, the SLA 3D prints, I ordered arrived and the quality is amazing! Compared to the 3D prints coming out of my FDM printer the tolerances are a bit tighter, so I had to do a bit of tuning here and there before I could put everything together. However, it worked out and I couldn't be happier:

All 3d prints (case, 1U+1.25U stems, display holder and cirque holder) are designed in OpenSCAD, so fine-tuning for the next batch will be very easy. The resin parts give it a professional look and my personal impression is that it feels more like a real product :)

TA-DA!

Okay, so now with displays and lights on:

I didn't fix the displays indices yet and with that they don't show the correct content. However, I was so happy that it all worked out and just took a quick picture. There is some homework left for me!

Now it is time to bring the same changes to the left side and the hardware of the PolyKybd Split72 is ready!!

Sidenote

You might have noticed that it is really tricky to make good photos when the displays are on because those are much brighter than the environment. At some point I should maybe do some more professional HDR shots!

(until that time, I will just tweak light and contrast of my cell phone pictures)

Thanks for reading and let me know what you think about it in the comments!
Generate A Case With KiCad And OpenSCAD
thpoll • 03/28/2023 at 09:36 • 0 comments

The very first case for the left side was done manually. Just like I did for my macro pad prototype - measure everything and then model a fitting case:

Well, still I had to break away some parts as you can see :-P, this process usually needs multiple iterations to really fit well.

For left side case, I had at least some automatic step, so I haven't had to measure everything: In KiCad, I exported an SVG from the PCB outline and started modelling a case around that:

That worked, but I don't want to repeat that for the right side as it is just too much manual work. Also any changes to the position of the LEDs, USB connector or the mounting holes would be a disaster!

The good part is, that I now know how the case should look like from the design standpoint!

What I also learned, is that there would be less manual modelling needed, if I placed all bottom SMD parts well within the PCB (well at least 2mm+). Then I don't need to modify the edge where the PCB sits on because of colliding parts. Obvious? Right? Seems like I had to experience that first to realize.

Next Iteration

So for the right side I wanted to start with a more generic and automated approach that ideally creates a fitting case based on the PCB alone.

To make the project as open as possible, I resisted to use any modelling software that would need a paid license. With these two ideas in mind I was wondering if I could use OpenSCAD to programmatically generate the case.

I already used OpenSCAD for the keycap stems and the display holder, why not for the case as well?

So How does it work now?

I still export the outline as SVG, however without all the cut-outs for key switches. In KiCad, you can select which layer to export and each layer can be a different SVG. So the most convenient thing is, to copy the board outline to a separate layer (since the key switch cutouts are also on that layer, but we don't need them). Then create a layer for each of the other physical features like:

1. Usb port cut-out (just a rectangle that can be extruded and subtracted)

2. LED cut-out for the status lights (just a line starting from the middle of the part perpendicular to the board outline)

3. Reset and Boot-Select switch cut-outs (again just rectangles)

4. And finally the stand-offs, which I just redraw as circles in a new layer as circles with the exact diameter of the drill hole.

So all together that makes 5 different SVGs (well, I also optionally had cut-outs for debug ports but that will not matter in the end).

All Set?

Unfortunately, my outline was not perfect (tiny gaps) and I had to fix it with InkScape to make one polygon out of it (I don't remember the exact steps, maybe there is some expert who can comment? Maybe there is a command line tool to do that?).

Apart from that, for some reason, all lines in my exported SVGs where in groups and I just got all lines out of any groups and deleted the empty groups as OpenSCAD had issues with objects in groups.

After these little cosmetic operations, I can load the generated SVGs into OpenSCAD:

With the offset command I can make the extra space around the PCB for the case. All that missing is a linear_extrude and we already three dimensional representation:

If the outline or another physical property ever changes, I just regenerate the SVGs and run OpenSCAD again. That's all! I love that!

You can find the current version as usual on my git repo: https://github.com/thpoll83/PolyKeyboard/blob/master/case/right_side.scad

And as usual my apologies for the mess in the repo, I really need to cleanup the structure. It's just like my desk ;)

Remaining Manual Work

There are a few things that might need manual adjustment once a while, but it's really manageable:

- The logo as I just placed it loosely in the middle

- The wedge shape in the front

- The mount points for tenting (on the side)

3D Printing

Of course I 3D printed the case and it turned out well:

I would like...
Read more »
Success And Failure!
thpoll • 03/28/2023 at 09:34 • 0 comments

I had a good time designing the right side and it is really satisfying to see it turning on without any issues:

As you know from earlier posts, I used the right side to test a new hardware iteration that includes an on-board RP2040, USB-C, more flash memory, etc. So there was some risk that the board might not even boot up.

To give myself enough possibilities to tweak and debug things, I added a lot of solder jumpers and also pin headers to connect to the most important data via a logic analyzer:

Before I had to solder some wire to test points here and there just to check my SPI signals.

But the new board has a problem (makes me cry a bit), which makes it only usable as dev board and not as (Poly) keyboard. Disappointing, as all my PCBs on this project so far proved to be fully functional prototypes.

Here comes my list of what works and what doesn't.

Success:

- RP2040 with 8MB Flash and USB-C works (obviously)

- The non-inverting buffers do solve my issue with the data glitches I experienced, it was indeed a fan-out problem (😆 so happy that this is off the table)! Huge thanks to my co-worker Peter who suggested that change. This was my last electrical issue :)

As this problem was solved, it was time to increase my SPI frequency from 400kHz to 16MHz. That success made me go further so that I increased also the frequency for the shift registers to 16MHz and it works! It was a pure software change, but with the data glitches before, I didn't dare to tweak the way the shift registers operate. Finally, updating the displays is amazingly fast, no way to recognize any delay 🤯.
Now everything runs on 16MHz and I can see my 10$ logic analyzer reaching its limit. For hardware debugging I have to reduce the clock, otherwise it misses some signals (Well, I should maybe invested into a proper one... any affordable recommendations? Maybe a Kingst LA2016?).

- Successfully tested the new 0.42" displays with the SSD1315 chip! These were fully compatible with the old ones having the well known SSD1306 - no change needed.

- I also consider the solder jumpers as a big success. These let me re-wire pieces of the circuit without any new iteration (like the power supply of the displays, unfortunately these really need a voltage of about 3.6V, 3.3V is not working). In the future, I will remove them as they needed quite some space on the surface though.

- Right and left side can currently communicate via my RJ45-to-UsbC franken-connector and you cannot damage the boards by confusing the two USB-C plugs:

If you plug the side connector into any other USB-C device it will look like an analog headphone, which is harmless.

- A bit over-enthusiastic, I also decided to use an OLED status display which does not come on a break-out board to avoid any supply-chain issues with 3rd party PCBs. It's a bare OLED display with a 30 pin FPC (I2C) which I got from my trusted display supplier:

It did not turn on right away as I tied all reset lines together and the displays from the keycaps were initialized after the status OLED and so the reset triggered too late. To fix that, I now initialize them together and and we are good!

No Conclusion Yet:

- The pimoroni trackball (see picture above - fits just perfect), which can be used as alternative to the rotary encoder and is already soldered on for the current board, but I just did not configure it in QMK yet.

- There was also no time to check the cirque connector, but this will be still possible of course. It could make a nice addition or alternative to the trackball as mouse input.

Failure:

So here is the problem... Can you spot it? (new one above, old one below)

Well, it's easy if you see it right next to each other...! I changed to another FPC connector with 14 pins because the customized displays will have less pins to get rid of redundant ones (and therefore will be 1mm smaller and fit with more switches). There was even a KiCad footprint for the new socket, so I was...
Read more »
Organizing The Language Table
thpoll • 03/28/2023 at 09:31 • 0 comments

Actually, I planned to write much earlier about the language layer, but the draft never finished itself ;)

From the spreadsheet color scheme above, you can see that I support 10 languages at the moment. Of course at some point I would like to be able to download any language to the keyboard on demand maybe via the HID interface. Then, there would be no need to use a hard-coded lookup table. However, for this even more needs to be done on the software side and today I will focus on how it works at present.

Maybe the main reason why you are looking at the PolyKB is not language, but program context dependent keyboard functions? Don't worry, I think this is not too much different from the language layer. Let's call it the program or context layer, which would be just another lookup (table) to display a customized text or icon, if there is a function defined for that key. So if your focus is function and not language, please just take it as a template that can be also applied to the program context.

Easier Data Handling
Organizing the language lookup table (lang_lut) in source became an unmanable mess after 3 languages, so I started working with an xlsx spreadsheet, which indeed makes things much easier.

Let's look at the following example:

Each language has 3 columns. The first is what's usually displayed on the display, the second when pressing shift and the third, when caps lock is on in case it differs from the second (when pressing shift) case.
This is not uniform! For an english US layout the number keys turn back to numbers when caps lock is turned on (while the letter stay upper case of course), for a german keyboard the wild cards will stay active and behave just like the letters (and therefore there is no entry in the LUT).

Additionally there is a second row for each key to display what the key does together with ALT (GR):

While there is nothing for the US layout, you can see that there is an additional glyph for almost every number key in case of French or Spanish.

Translate the LUT to code

To get the xlsx file into C++ source code I use cog: https://nedbatchelder.com/code/cog/

That's a way to use Python code which is inlined in C++ comments and transform marked sections with that code.

Python is quite handy here because there are libs to do almost anything (including spreadsheet data access).

An example to get all defined languages (lang/lang_lut.h):

Everything between /*[[cog ... ]]]*/ and //[[[end]]] is generated. Just for the available languages, the effort doesn't pay off. It is an example. The python code that generates the LUT for the glyphs isn't much longer and it generates around 600 lines of code (in lang/lang_lut.c), which exactly why I use cog.

Apart from that it makes it very easy updating multiple code pieces at once. A new entry in the spreadsheet is enough and also dependent code will be updated:

That's very handy!

Cog needs to be executed to update the code sections and so I have a little script to run cog on all source files with Python code parts:

There is still much more work ahead to make this work in a more dynamic way, also for the program context, but let's do everything step by step!
More Key Switch Testing While Waiting For The Assembled Right Side
thpoll • 03/28/2023 at 09:29 • 2 comments

After some back-and-forth where to assemble, I finally uploaded my Gerber files at my usual go-to-shop and now waiting for the whole thing to ship in the next weeks (hopefully).

Here is a KiCad rendering how the board currently looks like:

To make good use of the time until the PCBs arrive, I decided to test some more switches.

Compatible Key switches

I'm quite happy with the results: There are now 8 key switches that work as they are, without any modification. When getting the customized displays (with a longer and smaller flex cable), this number should grow to 28 key switches!

Additionally, I tested another 20 switches that work when cutting away the little bar in the middle:

I used my box cutter knife and gave it a little push on both sides and it's gone:

Here a picture of the happy family that can be used for the PolyKB at the moment (without any bigger effort):

And the list in more detail:

The 8 switches, that already work:

Kailh Novel Keys Cream Switch, 55g Linear

Kailh Purple Potato, 63.5g Tactile

Kailh x Domikey Knight Saber, 42g Tactile

Gateron KS-9 (Pro) Red, 45g Linear Gateron KS-9 (Pro) Yellow, 50g Linear Gateron KS-9 (Pro) Green, 80g Clicky Gateron KS-9 (Pro) Blue, 60g Clicky Gateron KS-9 (Pro) Brown, 55g Tactile (they all look the same except the color)

In case you are confused with Gateron switches and their name (like me), better read this article: https://www.keebtalk.com/t/the-many-yellowses-of-gateron/17557

In short you might see KS-9 (Pro) switches with and without the plastic bar and might get the wrong version (=in case of the PolyKB that would be the version with bar), despite the product image showing no bar, because most resellers don't care about that little difference. Better directly ask the resellser about that (or just remove the bar, it's not a big deal).

The 20 switches that work when cutting the little piece of plastic away:

Gateron KS-9 (Pro 2.0) Red, 45g Linear

Gateron KS-9 (Pro 2.0) White, 35g Linear

Kailh BOX V2 Red Switch, 40g Linear

Kailh Box Cream, 45g Linear

Kailh Pro Purple, 50g Tactile Kailh Pro Burgundy, 50g Linear Kailh Pro Light Green, 50g Clicky Kailh Pro Plum, 70g Tactile

Kailh Speed Gold, 50g Clicky Kailh Speed Silver, 50g Linear Kailh Speed Bronze, 50g Clicky Kailh Speed Copper, 40g Tactile Kailh Speed Burnt Orange, 70g Linear/Tactile

Kailh Speed Pro Heavy Army Green, 70g Clicky Kailh Speed Pro Heavy Yellow, 70g Linear

Kailh Black, 60g Linear

Kailh RGB Red, 45g Linear Kailh RGB Black, 60g Linear Kailh RGB Blue, 50g Clicky Kailh RGB Brown, 50g Tactile

Also Kailh naming is not everywhere the same (including the Kailh website), so you might find these switches under slightly different names.

And the 20 switches I expect to work soon:

From left to right, starting with row 1:
Ashkeebs Alexandrite
Owlab Neon
Aflion Tropical
Waters GOJU Works x Tecsee
Safety Switch Blue Dusk Panda (by BSun)
Glorious Panda
Row 2:
Outemu Red
Outemu Brown
Outemu Purple
Outemu Teal
Outemu Black
Outemu Blue
Row 3:
Outemu Dustproof Red
Outemu Dustproof Brown
Outemu Dustproof Black
Outemu Dustproof Blue
LCET Sprout
LCET Joker
Row 4:
LCET Pink Queen
LCET Grace

That's it for today, I hope next time I can already give some feedback on the right side ;)
PCB Design For The Right Side
thpoll • 03/28/2023 at 09:24 • 0 comments
It took me some time to get started with the right side, since I had to make a couple of design decisions.

As a small spoiler, I posted a rendering on twitter (see below)

Maybe you already spotted a couple of things, but here is the complete list:
- Kailh hotswap sockets instead of Mill Max sockets (since these are a pain to solder).
- Putting the RP2040 directly on the PCB instead of using the RP2040 Pico board to 1) allow a USB-C socket, 2) access even more IO pins and 3) use a bigger flash chip as I'm not sure that the Pico's 2MB is enough in the end (paranoid?).
- USB-C for the split-link, which I decided after running a poll on Twitter and Mastodon and USB-C was the clear winner on both platforms.
- A more generic footprint for the rotary encoder which allows the a standard Alps encoder, the rotary encoder from the left side EVQWGD001, the Pimoroni Trackball and there is a also a cirque connector (for I2C)
- A non-inverting buffer for each display row on the SPI clock and data line to hopefully overcome the problem (maybe a fan-out issue of the RP2040's IO pins) I described earlier where I saw some kind of noise when updating the displays.
- Status OLED display directly connected to a socket instead of a I2C break-out board from a random Chinese manufacturer.
- I also picked smaller FPC sockets for the displays - only 14 pins - since this is the goal for the kit. And 14 pins only need an FPC of about 7.5mm which will work for much more key switches than before (which was about 8.5mm).
- Plenty of solder jumpers, which allow a lot of different operation modes. For example: I got some newer 0.42" OLED displays for testing, which allow a voltage supply of 3.3V and therefore, I could bypass the 3.8V regulator which was required for the old OLED displays.
So a lot of new stuff and I really hope (fingers crossed) it is not too much at once and the board boots up!

That's it for today. Let me know what you think about these improvements, it's not too late to change some things before assembly!

And of course I which a joyful holiday season whatever you celebrate at your home!!
Synchronizing the Halves
thpoll • 03/28/2023 at 09:07 • 0 comments
Finishing the second hardware prototype turned out to be more involved than expected! I had some troubles (with noise I think) on the signal lines, which went away when I removed the pull-up resistors which I had on the SPI pins (I shouldn't have used them in the first place, as it is not I2C but at some point these solved a problem with floating pins when I was using the STM407F MCU and they just stayed - well, until now).

Once a while, there is still a glitch, which I need to investigate. The strange thing is that also without refresh, I can see some pixel light up one a while. My best guess so far is that I unintentionally introduce some capacitance or resistance due to my soldered together flex-cables (the pitch is only 0.5mm so it is possible that two neighbor lines almost touch each other) and these cause some troubles. That problem would go away if I could get the customized displays with the longer flex cables... but I cannot prove it for now.

Needed Software Changes: Since I have two identical boards for my "test keyboard setup", I started using the eeprom to store which side is the actual left and right side(with `#define EE_HANDS` and make handwired/polykb/wave:default:left` `...right`), but that is not needed as the is a master detection with ChibiOS and it just sets the master to the side with the connected USB cable (just connect the able to the 'correct' side).

Additionally, I had to double the key matrix and num of RGB LEDs as if everything runs on one side (turns out that actually happens - the master just receives the keypress from the other side and runs the logic!). So in the end this is what I changed:
rules.mk:
```
SPLIT_KEYBOARD = yes
```
config.h:
```
#define RGBLED_NUM 72
#define DRIVER_LED_TOTAL RGBLED_NUM
#define RGB_MATRIX_SPLIT { 36, 36 }
#define SERIAL_USART_TX_PIN GP5
#define SPLIT_TRANSPORT_MIRROR
#define SPLIT_LAYER_STATE_ENABLE
#define SPLIT_LED_STATE_ENABLE
#define SPLIT_MODS_ENABLE
#define SPLIT_OLED_ENABLE
//and also define a new LAYOUT to have both sides in one:
#define SPLIT_LAYOUT
```
( ... My first few connection tests failed, however after changing a couple of things back and forth I got some basic input working, however, just for one the master (left side) and !some! key on the slave (right side):

Again, it took me some time to think about it, but after the realization that only the master really executes the logic it was clear that all my static helpers were never updates on the other side (and some initial mistakes when adding the second side to the layout).

The solution to this was to use the housekeeping task and check for changes (as we already configured QMK to sync status changes like modifiers and status LEDs) and then perform the needed updates. As I can do the same on the master the display update now moved from the matrix processing to the housekeeping as well, which should be an improvement for the scan rate!

To also get the language change propagated (which are no QMK layers), I had to add a rpc callback which is triggered by the master to send that information together with the display brightness:

The `user_sync_poly_data_handler` task is executed on the the `slave` side, which just sets the static variables and then asks for a refresh of the displays which will be done in the housekeeping task.
There are still open software issues I need to address at some point (RGB matrix lighting not working correctly at the moment, fade in and out after timeout has some side effects, code cleanup - yes it's messy at the moment, the OLED display update could be faster, ...) but for now you can find the work-in-progress code here: https://github.com/thpoll83/qmk_firmware/tree/PolyKeyboard

And here a small video I posted on Twitter: https://twitter.com/thpoll2/status/1591026041434226688?s=20&t=j8DVR1XFWFR__iBi13svhw
Typing Experience
thpoll • 03/28/2023 at 09:04 • 0 comments

For most people the typing experience itself is the most important part of the keyboard which it is hard to quantify.

So it shouldn't be a surprise that my thoughts circle around that aspect as well when thinking about the PolyKeyboard.

What I cannot influence for now, is the keycap profile from the relegendable keycaps I use. It's maybe close to XDA, however the swale is not that profound, the corners are a bit more distinct and the overall height is only 8mm.

And what about the key-stroke?
How much does the flex cable influence the behavior of the key switches?

To figure that out, I made a little test station and measured how much weight is needed before and after adding the flex cable to the key cap:

The LED on the board will light up when the key switch conducts.

The keycap with the 3D printed stem and the display come with a weight of 2.2g:

My circular tray to hold the weights add another 7g.

First, I did a test without the flex cable, so let's quickly deduct its weight from about 0,5g:

When the LED finally lights up, the following weights rest on the key switch:

Stem with keycap (minus display for the first test): 1.7g

Tray to hold the weights: 7g

Weights: 20g + 20g +1g

That makes a total weight of 49.7g when the switch activates, which matches very good with manufacturer's data for the yellow Gateron switch of 50g for the operating force. So now, how much does that change with the plugged in flex cable? The same thing again, I'm adding weight until the red light turns on:

Stem with keycap and display: 2.2g

Tray to hold the weights: 7g

Weights: 50g + 2g + 1g

Here we have a total of 62.2g, which is 12.5g more. So this is definitely something to consider when choosing switches for the PolyKeyboard!

There is maybe a bit room to get that weight a little bit more down when customizing the flex cable length and maybe also the cable width, but I think the current value of 12.5g added on top of your key switches actuation force is a good orientation.