cyber60: 60% Bluetooth PCB running nRF52 and ZMK

[Applet]

Goal: I wanted to play with ZMK and could not find any DIY friendly 60% project, so I made one. The ambition is to use many parts available through JLC, and keep everything at a level that's possible to solder using only a soldering iron. Currently, only the BLE-module and RGB-led below capslock is not available through JLC and need to be hand soldered.

Specs:

• Module: Holyiot YJ-18010
• Standard Tray Mount support + bakeneko-style cases (a battery cutout is generally needed)
• Non constant drain battery measurement
• Lipo charger for single cell 3.7V li-po/li-ion batteries (JST PH and JST SH support, you can use either, not both)
• RGB-led under Caps lock for multi function indicator
• Possible to build with just a soldering iron (no underside pads etc)
• ANSI and ISO layout support with the common options.

Layout support:
NOTE: Split space support will be changed. This image shows the split space layout support in revision A.


Github:
Project: https://github.com/4pplet/cyber60
Latest releases: https://github.com/4pplet/cyber60/releases

Availability:
https://4pplet.com/products/cyber60

Currently test-built in a Tofu and a bakeneko-style case with a custom battery cutout.

Pics of initial proto (Rev A):




Pics of second proto (Rev B):



Todo:

• Decide on layout support change.
• Order and test revision C1 with updated layout support.

Status:
- x: Currently planning for Revision C redesign and order of protos.
- x: Revision B2 long term tested in my personal build and others. Revision done and released.
- 2021-06-07: Testing of revision B1 done, some changes made and released as B2. Will be ordering protos and verify B2 soon. ( (https://geekhack.org/index.php?topic=109628.msg3035159#msg3035159))
- 2021-03-21: Testing revision B1, mostly works, but some minor changes need to be made for being fully functional. (https://geekhack.org/index.php?topic=109628.msg3028003#msg3028003)

Useful links:
- ZMK website: https://zmkfirmware.dev/
- ZMK discord: https://discord.com/invite/sycytVQ

[nevin]

I've been playing with layer lights in qmk. Have some good working exampes. Does zmk have the same implimentation or not yet?

[Applet]

I've been playing with layer lights in qmk. Have some good working exampes. Does zmk have the same implimentation or not yet?

afaik, no. Don't think there is any LED-support yet other than basic underglow, ZMK is still very new. I have big expectations for it in the future tho.

[nevin]

In qmk you can specify layer segments, of an led strip or underglow and get it to function as lock & layer indicators. So it might not ba a far stretch to get it to work. i'll look at it then.

[parablol]

Cool feature set!!! Assuming all goes well, please consider an ortholinear version in the future!

[Applet]

In qmk you can specify layer segments, of an led strip or underglow and get it to function as lock & layer indicators. So it might not ba a far stretch to get it to work. i'll look at it then.

The undergow is for adressable leds. This PCB uses a dumb common anode led without logic, so I can't use the underglow code. I'm planning to implement a PWM driver for it. I disslike the adressable leds for a project like this, since they have a constant current draw, even when off. This could be solved using a transistor to fully turn them off, but I prefer it this way. It's probably a bit more if a hassle to implement the code, but it should be more power efficient.

There is no lock states in ZMK yet and no support for userspace-code yet.

Cool feature set!!! Assuming all goes well, please consider an ortholinear version in the future!

Thanks

[nevin]

adddressible led draw.... good to.know. That makes total sense, and important aspect being wireless.

[ice9js]

Very cool! I've got a question - how's your experience been with the reception inside an aluminum case so far?
I see it's a common pattern to put the radio module in the spacebar area and use a non-metallic plate but I don't really have the tools or the experience to verify how that affects the rf signal vs a more traditional design like a patch antenna or not having metal at all around that part on the case.

[Applet]

Very cool! I've got a question - how's your experience been with the reception inside an aluminum case so far?
I see it's a common pattern to put the radio module in the spacebar area and use a non-metallic plate but I don't really have the tools or the experience to verify how that affects the rf signal vs a more traditional design like a patch antenna or not having metal at all around that part on the case.

I've not done much testing on signal strength yet. Having the antenna under space bar is the only feasible location with this layout and module, with another layout and PCB size, I would have placed it on top. Generally I would not recommend using the Tofu case at all, since it is a big metal piece, shielding the antenna, but so far it has been working great. I start to loose connection about 3-4m from my PC, but it's working great with the ~1m distance from my desk to my PC. I had the case, so I thought it would be a good test. The acrylic/plastic Tofu or some other plastic case is of course a better option from a RF and reception perspective, but metal case and plastic plate seems to be good enough at least for my use case.

I have now patched the PCB to work like rev A2, and the battery circuit seems to work like I intended it to. Flipped one transistor, removed series resistance between enable pin and MCU and added a pull down so it defaults to off. Not pretty but it works (I restored the series resistance/gate resistance, don't know what I was thinking...)

[nevin]

nice when things start going your way....

[Applet]

Tiny update:

• Still waiting on my smaller batteries and eventually the box60 to test the PCB in.
• I put together a ALPS PCB, very similar and uses the same software implementation. I'll make a pre-release on my github soon, but changes may still be added to A1 (same applies for the MX-release A2)
• Still have more testing to do (Leds test, current measurements etc)

Edit:
Link to pre-release: https://github.com/4pplet/cyber60/releases/tag/A1_ALPS

[nevin]

looking good.

yeah, i've been eyeing up the Box60 case as well. Haven't purchased one yet though. Love the different styles they've done them in. So far i've seen two translucent ones, black & most recently they have a beige with commodore 64 stickers... Looks like a versatile, cute little case with plenty of room for modifications.

[paperassgasket]

I just stumbled upon this looking for ZMK implementations. This is a cool project, I'll be watching 

[Applet]

Tiny update:
I've been working on a new revision (B) with rotary, underglow and buzzer added that I will order prototype for soon. Rotary placement is either off board, or in split backspace position (replaces tilde-key). All of these additions is optional, and you can just skip mounting them if not needed. I also simplified the voltage measurement circuit to the basic voltage divider that is commonly used. This adds a tiny bit of current leak, but it is very low compared to the self leakage of a lipo battery.

The RGB-led under capslock and buzzer is something not supported by ZMK currently, but hopefully we can work that out

As mentioned previously, addressable leds have a constant current draw, even when off, so there is a transistor added to cut power to the leds when off.

[nevin]

nice additions.
do you think these will eventually go to a GB? or just open source?

[Applet]

Currently no plans to take this to GB, especially since there is features that is not yet supported by ZMK. If there is interest, we could do a small scale GB, most of the components is supported by JLC assembly, so it's pretty cost effective.

Files are also open and license support it if someone else want to run a GB.

I'd recommend to wait until after my first proto-run tho.

[Applet]

Tiny update:

My modules for testing revision B1 is still stuck in customs (been waiting for a month soon). In the mean time, I got some help to test out the RGB-led, and code for indicating which BLE-profile/device is connected is in the works, thanks to Megamind.

The idea is to make it easier to see which device you currently have selected in the keeb. The led is on for a short while and the color depends on which device.

[nevin]

nice! love single, multifunction leds. i'm not a big RGB guy but implementations like this are totally worth it.

[Applet]

Update on Revision B:

For starters: revision A2 MX and revision A1 for ALPS and SMK is tested and I consider revision A done for now. I finally got the bluetooth modules after 2 months of waiting and has gotten started on testing the revision B protos

My findings so far:
- Basic functions carried over from A2/A1 work great
- Rotary encoder has issues when using the common encoder filter, but works great without the filter. I'm using low frequency pins, and all works great.
- Design error in the circuit that cuts off power to the underglow. Annoying rookie mistake. I'm using a p channel mosfet as a high side switch, but I did not account for the control voltage being lower than the voltage I'm powering the leds with (battery voltage). This results in that the p mosfet does not close 100%, especially when battery voltage is high. I will add a n channel mosfet in the B2 release to make sure that the p mosfet close fully. Current situation will leak a bit of current to leds, even when they are turned off.
- One of the downside of the added functions from revision A to revision B is my use of pads that is partly cut away due to stabilizer and mx switch holes and thus making it a bit more difficult to solder. I found it OK to solder (success!), so I'll keep the new functions in revision B. My backup plan was to simply revert to how it is in revision A and that feature set.

Updates to B2:
- Removing encoder filter from design
- Adding complementary transistor to underglow shut off, so it fully closes
- Add reverse polarity protection for battery connector

To do in Revision B:
- Test buzzer circuit to verify function and volume
- Update design and verify function.

Current plan for revision C:
This will be a bit further in the future, but I'll gladly take suggestions. My current plan is to wait for a good nRF53-module (probably ~a year away) before changing anything in current design/feature set aside from bug fixes like above. My current plan is the following:
- Update to a nRF53 based module
- Change to ws2812c in 2020-package for underglow
- Possibly remove the support of having two different JST battery connectors and stick to one.
- Possibly do a transistor based battery switch.

I try to document more of what I do, so I put together a short vid if anyone is interested

[Applet]

Patched the underglow issue on my B1 build and in code, it will work like this in the B2 revision. Power to underglow is now completely off, when they are turned off in code.


Still to do now is to test and verify the buzzer

[nevin]

nice. i know that has been an issue with led's for a long time.

[Applet]

Small update: 

I believe I've tested and verified everything on revision B1 now and updated the things that needed to be changed for B2 release. B2 release is now on github, I will be ordering protos soon to verify function, then it should be mostly done for now. B2 revision should be safe to use, but I'd recommend to wait for my proto-round, so I can verify it.

MX: https://github.com/4pplet/cyber60/releases/tag/B2_MX
ALPS: https://github.com/4pplet/cyber60/releases/tag/B2_ALPS
SMK: https://github.com/4pplet/cyber60/releases/tag/B2_SMK

I tested the buzzer with a simple arduino sketch just to verify the circuit. Should not be any problem using it with ZMK, but it needs to be implemented in code.

Functionality for LED under capslock-switch is still very limited, but under development.

EDIT: The volume is a bit low in the video, it's not loud IRL, but ok.

Stay safe!

[Hapi]

I can't wait for this... i need couple of MX version, couple of SMK version, couple of ALPS version...

[Applet]

TLDR: I'll be changing the split space layout support for the next revision. Will be releasing it soon.

So, I was hoping that with the B-revision, it would be the long term revision for this project. Unfortunately I'd like to do another split space layout change, so I'll be doing a C-revision soon.

The issue: 2u stabs for 3u keycaps. 3u keycaps using 2u stabilizers (or support both) are fairly uncommon and the new ones from GMK is only 3u from what I've been told. So, I'd like to change the split spacebar support to accommodate keycap sizes and stabilizer-sizes that is more common. Unfortunately, there is no space for 3u stabilizers, so that gives me two options that I have been considering:

• 7u split into 2.75u + 1.5u + 2.75u (like the h60).
• 6.5u split into 2.75u + 1u + 2.75u, this is already supported for the ALPS and SMK-layout

If space was not an issue, I do both of these two options for split space:

• 7u split into 3u + 1u + 3u
• 6.25 split into 2.25u + 1.25u + 2.75u

I'll be doing this for my waffling-project. But, due to the size of the bluetooth-module, it's not possible. I tried the 6.25u split in rev A and B, it's doable, but it's harder to solder, so I won't revert it to that. One of the goals of this project is that is should be relatively easy to DIY. Another option would be to change module to a smaller one, but I like this one for the fact that it can be soldered fairly easily using only an iron.

7u split vs 6.5u split:


Personally, I'm not a fan of the 1.5u center key I find the two larger keycaps to be too spaced out. I've been using the 6.5u split into 2.75u 1u 2.75u for quite some time now on my AEK-build and I think it works well. It would also simplify things a bit, since that layout is already supported for ALPS and SMK versions of the PCB. So, this will be my suggestion. Unless someone has a good argument to do the 7u split into 2.75u 1.5u 2.75u (or some other split), I'll be going with that.

The big downside with using the 6.5u split is that it will not work in a WKL case and I'll likely do the hotswap version without split space. It will work in a MX-HHKB case.

Let me know what you think

Availability:
I've been starting to keep these in stock here:
https://4pplet.com/products/cyber60

They'll always be available open source also, but I wanted to give an option to DIY (it's not for everyone).

Instructions:
I started doing a bootloader flash instruction on github:
https://github.com/4pplet/cyber60/blob/master/BL_FLASH_INSTRUCTION.md

If anyone tried it, please let me know if you tried it and found it lacking something. I'm slowly working on a instruction on how to change the keymap, but it'll be released further on.

Short update on ZMK implementation:

• Buzzer is now implemented and can indicate what bluetooth profile is changed to. Thanks to Megamind who have been adding features to the project!

[Applet]

I will be going ahead with the 6.5u split like mentioned above. Pre-releases for revision D is up on github. Note that I will clean up the routing a bit compared to what is up now, but functionally, they will be identical to the pre-releases.

EDIT:
Code for bootloader and ZMK for revision D is not done yet, but in the mean time, the code for rev C can be used. Nothing has changed here, I'll just update the identifiers, so it shows up as revision D.