The battle of FPC design

 Now I am battling with matrix FPC design of Nanaju.

What is so difficult? Please see the photo below. This is P2PPCB design:

Hand wiring is quite flexible. P2PPCB Composer F360 can generate wiring diagram and we just follow the diagram to assemble. But FPC is not very flexible like hand wiring:

The black sheet is PVC and the outline is cut by a cutting machine (Silhouette Portrait 4). A matrix FPC should be made with exact dimensions to fit the keyboard frame. I can imagine an automating software tool for this work, but making such tool requires several months, I guess. So I bought a cutting machine and I am battling with the overlooklings and misunderstandings of myself.

Recent Proceedings (Oct. 2025)

 This is the latest prototype of Nanaju:

Now it has USB 2.0 hub.

I gave up the idea of embedded scroll slider. Just placing a discrete trackpad on the left is far much better. 

The number pad becomes ITU-T E.161-like layout. It is for OTP input, not for tax return. It also works as function keys.

Layer selector switch moves into the back. The knob interferes the fingers if it is placed around the number pad.

I almost beleive that I has removed every bad ideas from Nanaju. Now I am struggling with FPC design.

The Nanaju keycap set will go on sale with two types; dye-sub and laser printing.

Making a prototype into an end-user product

Now I am making Nanaju (see recent posts' photos) prototype into an end-user product.

P2PPCB wiring is good for prototyping but too costly and cumbersome for mass production or DIY kit. I'd like to make the assemlby cost cheaper at the sacrifice of huge initial cost. So I am designing this flex PCBA:

"ツメ" areas don't seem to have any function. They have, of course. BTW in Japanese "ツメ" means a craw or ratchet in this context.

The PCBA mates with this cavity of a frame:

Insert the PCBA vertically:

And slide the PCBA upward:

Now they mates tightly. No need to worry about slipping. The "ツメ" works like this:

This side of the frame mates with a key switch:

Complete:

No tools, no hand soldering. Easy and fast. Ideal for mass production and DIY kit. But hard to design :-) The initial manufacturing cost is expensive too.

Recent Proceedings (Aug 2025)

 Now I am testing a new prototype.

In this iteration, I am trying some new (but small) ideas:

1. Placing 1QAZ keys along with other character keys.
   1QAZ keys along with Tab key (see a past post of this blog) is good for keyboard shortcuts, but not very good for typing.
   So far, I feel hard to stabilize my pinky finger on the keyboard. I am leaning toward rejecting this idea.
2. Placing a rotary switch for default layer selection.
   I myself do not use default layer selection (I use just MO(n)), but I am absolutely disagree with any non-tangible states in a keyboard. All states in a keyboard should be tangible. CapsLock key is evil because it depends on LED. You must see LED or screen to know the CapsLock state. This is not tangible. A rotary switch state is tangible, i.e. you can know the state without looking anything.
   So far, this idea looks good.
3. PIN/function keypad with Fn key.
   In the last iteration, I tested double action switches for number/function keypad. Deep press makes number key signal and shallow press/release makes function key signal. The results are complicated. A small number/function keypad is great. Especially good for entering PIN code. But double action switch is a bad idea.
   So in this iteration, I choose normal tactile switches and utilize Fn key. Number keys are in Fn layer because PIN code is 4 to 6 digits and we can keep Fn key down while entering the digits.

In this iteration, I choose Kailh Saker Mini switch. This is a novel Choc V2 variation and the total travel is just 1.8 mm. I feel that the travel is good, but the actuation force 37 gf is a bit weak.

I placed a scroll slider on the left edge. So far I feel the place is good enough. Sometimes the scroll slider is strikingly valuable, but that doesn't happen very often. There are a lot of work to make the slider excellent, e.g. macOS capability and zoom (two-finger) feature. I am still uncertain whether it is worth the effort or not.

I am preparing the product version too. For the product version, I designed a mainboard with built-in USB 2.0 hub:

A Type-A port on the top of the case. Two downstream ports, Type-A and Type-C, on the back.

USB 2.0 hub is a den of secrets of the field. You can easily find the secrets if you are interested in USB 2.0 hub, but in many cases, you cannot find the reason unless you are an insider of the field. I am an outsider, and still wonder why there is no reversible Type-A port component on the market.

Today I'd like to tell you an easy secret: All bus-powered USB 2.0 hubs claim "I am a self-powered hub" to the PC.

On Windows, get USB Device Tree Viewer and look at your USB 2.0 bus-powered hubs with the viewer. You will find "Self powered : yes" in "Summary" section in all your bus-powered hubs. Why? This is not a bug of the viewer or the hubs.

1. All USB 2.0 devices claim their maximum demand current (MDC) to the PC.
2. MDC is maximum, not usual. For example, a common USB flash claims 300 mA. But 300 mA is just while reading/writing.
3. According to the USB 2.0 specification, a bus-powered hub cannot run over 100 mA MDC devices on its ports. This limitation is forced by OS of the PC. If a (honest) bus-powered hub port accepts the USB flash, the OS shows an error message and disables the USB flash.
4. The limitation is too much for most of us. For medical or aerospace, the limitation is reasonable. But in most cases, we do not use MDC of two devices at the same time. We want to just rely on overcurrent protection in somewhere, and see an error message when the protection breaks the current.
5. To bypass the limitation, almost all USB 2.0 bus-powered hubs claim "I am a self-powered hub" to the PC.

I did not know the secret. My prototype hub claims "I am a bus-powered hub" and it is almost useless. I will fix the issue in the product, so, it will claim "I am a self-powered hub" to the PC.

P2PPCB Compoer F360 Updated (July 2025)

Release 20250725-v0.2.2:

• Gateron LP stabilizer design has been revised.
• Now Choc V2 clip type stabilizer is available.
• Now key travel can be specified.
• Change Key command has been improved.

Choc V2 stabilizers are novel products (not mine). I have yet to see them sold anywhere other than keeb-on.com.

If you use hot swap sockets with the stabilizers, you should rotate the switches to 90 degree.

Recent Proceedings (June 2025)

 

This is my latest prototype.

The 16 keypad placed at the left bottom is a double action pad for function keys + numpad. Left 12 keys have double action tactile switches, Alps Alpine SKRN series. Right 4 keys have normal tactile switches. SKRN is not very durable, so I placed heavy use keys (0, comma, period, and Enter) into normal tactile switches. Double action keys are function keys for shallow press, number keys (and volume keys) for deep press. Is this a good idea? After my experience of several days, I am a bit skeptical now. I don't want to ship any wrong idea as my consumer product, so I am testing my ideas by my prototypes.

At the righit neigbour of the 16 keypad, a slider is placed. It generates two-finger swipe of Windows Precision Touchpad Protocol (PTP), i.e. it offers smooth and inertial scroll. At first, I made a slider by Cypress' IC, but I found that the scan rate (50 Hz) and resolution (8-bit) are not enough to PTP. So in this prototype, I made the slider with STM32. It gives me 100 Hz scan rate and 12-bit resolution. But I feel that the lineality is not enough. And I wish that the slider can do two-finger pintch. There is work left to do.

In the first place, is built-in slider a good idea? Now I feel that the place is wrong. In the next prototype, I will place it into the left edge of the keyboard.

I think that the iteration of prototyping is coming to an end. I will fix the final specification of my product in this year.

keycap-designer Updated

What's new in v0.1.3:

• The common use scenario has been changed to pip based.
• `DeviceRGBColor` added.

keycap-designer is a Python-based open-source application to design keycap printing images. DecentKeyboards accepts the artifacts as complete printing-ready data.

keycap-designer is good for designing a keycap set. A keycap set should have a consistent design across its keycaps. keycap-designer helps a lot to make a consistent design.

So the learning curve may be too steep if you need just one or two keycaps. In that case, please send me the printing image file, without struggling keycap-designer.