keyplus: Modular wired and wireless split keyboard project

[spindle]

Hi, I've been working on a modular split keyboard firmware and controller. I've posted this elsewhere, but I thought it would be good to post it here as well.

The idea is you can have split keyboards connected together via I2C, and when you disconnect them you can use them as
wireless keyboards using Nordic's nRF24 receivers. You can use one keyboard as a wireless receiver connected via USB, or use an nRF24lu1+ USB dongle for a wireless only setup. Also, since logitech unifying mice also use nRF24 transceiver I've managed to add support to connect to them as well. This image demontrates the connectivitiy options:



Here's a setup I have so far that has 5 keyboard devices and a mouse all connected together. Three of the keyboards are wirelessly connected to the keyboard on the right which has the usb cable. The TRRS cable connects the two devices in the middle.



Some of the Logitech Unifying receiver dongles use the nRF24Lu1+ microcontroller and with a bit
of work I was able to reverse engineer the firmware update process to flash my code to them. So I can use my keyboards and mouse wirelessly just with a unifying dongle that is flashed with my firmware:



Hardware:
The main hardware components I'm using are:

• ATxmega32A4U as the main usb keyboard controller connected to an nRF24L01+ for wireless communication
• nRF24LU1+ for the wireless dongle
• My early wireless only prototypes use ATmega8pa and nRF24L01+, but there's pretty much no reason to use them over the ATxmega32A4U.
• cr2032, 2xAAA, or any other 3V battery for wireless operation.

Firmware:
For firmware, I've written my own that supports upto 64 keyboards that can be used in a split layout or act independently. The firmware works by transmitting the matrix state from the slave devices to the receiving device which combines the matrices together and figures out which key is pressed. This allows you to have layer keys that work across a split keyboard. The only disadvantage to this method is you need to store all the keyboard layouts on all the receiving devices, this is only a minor drawback and can actual be taken advantage of to have different layouts stored on different receivers.

Another advantage of this method is that the wireless devices use very little power because they only need to scan than matrix and transmit it. I managed to get nearly 6 months off one of my early ATmega8 based prototypes with a cr2032 battery, but of course this will all depend on how much you use it. With 2xAAA you could probably get about 2 years battery life.

I've designed the firmware such that you can configure via a USB interface, so you don't have to compile it to update your layout. Here's a configuration file (wip) for the firmware that demonstrates the basics of how the layouts are setup. I haven't released the the firmware yet because there's still a few things I need to work on.

I've also been posting updates to this project on my website: http://blog.seethis.link.

Edit: Hardware and firmware files now on github:
 

• Hardware files
• keyplus firmware

[Parva Ovis]

Seeing stuff like this that improves on standard keyboard technology is always really cool. Is it possible to have two or more receivers plugged into different computers and have the keyboards switch which receiver they're connected to on the fly?

[spindle]

Is it possible to have two or more receivers plugged into different computers and have the keyboards switch which receiver they're connected to on the fly?

I got this feature to work: http://imgur.com/a/Cgdgs. The current implementation is a bit hacky, so it might only register the change key combination the second time it's pressed. To make it work better, I need to make the two receivers talk to each other as well, which shouldn't be too hard, I just never got around to doing it.

[Malachor]

Thank you for posting this here.
I've been wanting to convert a mechanical keyboard to wireless by using a logitech control board, but this is so much better.
How would I determine which dongle has a nRF24Lu1+ microcontroller?

[spindle]

How would I determine which dongle has a nRF24Lu1+ microcontroller?

I pretty sure unifying receivers with firmware version 12.XX.XXXXX are nRF while 24.XX.XXXXX are TI. You can check the firmware version from the Logitech Unifying software (or solaar on linux). Also, you should be able to tell from the products S/N on the metal sheath of the USB connector, however since there's lots of different versions, I haven't got a comprehensive list yet.

When flashing the device, you can tell which chip it uses by the bootloader USB ids. The nRF24LU1+ uses "046D:AAAA", while the TI CC2544 uses "046D:AAAC". So you wouldn't end up bricking it if you have the wrong one.

[hanya]

What protocol are you using to connect between each other, Nordic Gazell? If so, you can use nRF51 Gazell with nRF24Lxx Gazell mixed since it has backward compatibility (its user guide says so).
We can obtain nRF51 module with certification easily but not for nRF24. If we can choose nRF51 modules, that makes easy to make devices.

[spindle]

What protocol are you using to connect between each other, Nordic Gazell? If so, you can use nRF51 Gazell with nRF24Lxx Gazell mixed since it has backward compatibility (its user guide says so).
We can obtain nRF51 module with certification easily but not for nRF24. If we can choose nRF51 modules, that makes easy to make devices.

Currently I don't have Gazell support, but it's something I'm planning to add. I haven't integrated it yet because Nordic's license for the Gazell SDK on the nRF24 devices is not compatible with open source licensing. However, this might change with their switch to BSD licensing. If the code in the nRF24go SDK does not end up with a BSD license, I will have to reimplement it which shouldn't be too hard as it's only a thin layer above the nRF24 protocol. I still should be able to support Logitech mice as they appear to use Gazell as well. I can currently interface with them because technically my code is a Gazell device with only one frequency in its channel table.

Another reason I want to support this is the upcoming nRF52840 which can support USB + BTLE + Gazell on one chip.

Edit: it looks like it nRF24go SDK won't be relicensed:

All new software releases developed in-house by Nordic will be released with one of the new licenses. Previously released software with “legacy” licenses will not be updated with a new license.

So I will need to reimplement it.

Edit2: After further examination the nRF51822 has a software device for Enhanched Shock Burst (the base protocol of nRF24), so it should be possible to use nRF51 modules without needing to implement Gazell. However, I will still look into implementing Gazell because frequencing hoping seems like a diserable feature. https://developer.nordicsemi.com/nRF5_SDK/nRF51_SDK_v8.x.x/doc/8.1.0/s110/html/a00139.html

[tristinDLC]

Wow, great project! This is something I could end up using for sure on one of my future custom builds. I had some ideas on a setup that needed similar connectivity and this project shows its potential first-hand. Not only is it a great physical build, but amazing work on the reverse engineering and custom firmware.

Hopefully by the time the nRF52840 is readily available, the BLE issues between Logitech and macOS is fixed. I'll be keeping an eye on this project for sure.

[le-37]

Fantastic work. My wallet is ready when someone can implement this and sell it to me

[spindle]

I made a small controller for use with this project:


Here it is in action:



Some more pics of the build here: http://imgur.com/a/jzdZO. I hope to do a beta run of the new controller soon once I fix up a couple things with the firmware/bootloader.

[Malachor]

I like the design of your case, with the holes for the switch clips.
I'm interested in a controller when it's ready.

[saucybulgogi]

Any update on this project? I知  rebuilding my dactyl and would love to use some of these controllers to make it wireless. If not I値l have to go the bluefruit feather + IO expander route.


Sent from my iPhone using Tapatalk

[saucybulgogi]

Any update on this project? I知  rebuilding my dactyl and would love to use some of these controllers to make it wireless. If not I値l have to go the bluefruit feather + IO expander route.


Sent from my iPhone using Tapatalk

I知 also wondering, would your controller be able to power some RGB strips?


Sent from my iPhone using Tapatalk

[spindle]

Any update on this project? I知  rebuilding my dactyl and would love to use some of these controllers to make it wireless. If not I値l have to go the bluefruit feather + IO expander route.


Sent from my iPhone using Tapatalk

I've started uploading the code here: https://github.com/ahtn/keyplus. It still needs a bit of cleanup, and I need to finish the host software and layout uploading code.

I知 also wondering, would your controller be able to power some RGB strips?

Sent from my iPhone using Tapatalk

This should be possible when running from USB power with wired split over I2C. Since the xmega uses 3V logic and the RGB led strips need 5V logic signals, you need a level shifter to conver from 3V -> 5V.  On my other test PCBs I've used these as level shifters: https://www.diodes.com/assets/Datasheets/74LVC1G07.pdf to control ws2812 LEDs. I should be able to fit one on the next revision of the PCB.

I'll start working on LED support once I have the all the core firmware features working.

[woodkeys]

I've run the RGB strips on a 3.2v microcontroller. Shouldn't need the level converter.

Sent from my Nexus 6P using Tapatalk

[spindle]

I've run the RGB strips on a 3.2v microcontroller. Shouldn't need the level converter.

Based of one ws2812 datasheet, the min threshold for logic high is 0.7*VCC, so that's 3.5V @ VCC=5V. My boards would output about 2.9-3.0V, so I'm not sure if that's going to work. But since you mention it, I'll try it and see what happens.

If your board had a reverse polarity protection diode on the 5V supply, then that'd probably drop VCC to ~4.5V, which would mean V_high = 0.7*4.5 = 3.15, so maybe that's why it worked in your case.

[woodkeys]

I've run the RGB strips on a 3.2v microcontroller. Shouldn't need the level converter.

Based of one ws2812 datasheet, the min threshold for logic high is 0.7*VCC, so that's 3.5V @ VCC=5V. My boards would output about 2.9-3.0V, so I'm not sure if that's going to work. But since you mention it, I'll try it and see what happens.

If your board had a reverse polarity protection diode on the 5V supply, then that'd probably drop VCC to ~4.5V, which would mean V_high = 0.7*4.5 = 3.15, so maybe that's why it worked in your case.

VCC is 3.3V on my board. I haven't actually looked at the spec sheet to see what the valid range for VCC is. Threshold would be 2.3V with VCC=3.3V. As long as the 3.3V VCC is in spec it should work find, and empirically it does.

[spindle]

VCC is 3.3V on my board. I haven't actually looked at the spec sheet to see what the valid range for VCC is. Threshold would be 2.3V with VCC=3.3V. As long as the 3.3V VCC is in spec it should work find, and empirically it does.

When I was using VCC I was refering to the supply voltage for the ws2812 diodes. Are you saying that you are running the ws2812 from a 3.3V supply?

[woodkeys]

That's correct. I'm running it from the 3.3v supply on the Adafruit Feather BLE 32u4. It's running on battery so that's the only supply available.

Sent from my Nexus 6P using Tapatalk

[spindle]

Here's my new controller, the keyplus mini that I made for this project:



Also, I've now put the hardware and software files for this project up on github:

• Hardware files
• keyplus firmware

Still need to add more documentation though.

[rm-rf]

Here's my new controller, the keyplus mini that I made for this project:

Show Image

Also, I've now put the hardware and software files for this project up on github:

• Hardware files
• keyplus firmware

Still need to add more documentation though.

damn, i like that controller.

[lishi]

Absolutely stellar work spindle!! 

[deprecatedcoder]

This is so beyond my level, but even I can see it's going to open up the possibility of some really amazing builds.  Keep up the good work!

[saucybulgogi]

Hey spindle. I just started working on getting keyplus setup on my mac and I've got some questions.

If I'm understanding this correctly, to make the keyplus mini controller work for my board I'd only need to send my layout.yaml file to the controller using the configurator correct? The built firmware on the controllers doesn't need to change?

Also, if you've got any advice on how to get the Configurator up and running I'd greatly appreciate it. Looking forward to rebuilding my dactyl with these!
Thanks!

[saucybulgogi]

Hey Spindle. So I've got your keyplus prototype controllers flashed once with a basic 6x6 matrix. I tested it with a piece of wire and it looked like they were both emitting the correct keycodes.

Since i was able to flash them, I went ahead and wrote a layout file for my dactyl but it doesn't seem to work when I try to flash it. The configurator just sits there when I hit 'Program'.
I figure there's some kind of error in the layout file and the configurator hasn't been edited to show errors yet.
I've forked your github repo and uploaded my layout file here: https://github.com/saucybulgogi/keyplus/blob/dactyl-conversion/layouts/dactyl.yaml

Can you take a look at it and see if i've done anything wrong?

Also, on the Device id and the RF settings flasher, is the layout settings file the same file for the Layout flasher? I generated a new rf settings file and tried to flash my prototypes with it but even with one of the example layout files, it hasn't worked.

Any help is appreciated
Thanks!

Edit: changed wording

[spindle]

Since i was able to flash them, I went ahead and wrote a layout file for my dactyl but it doesn't seem to work when I try to flash it. The configurator just sits there when I hit 'Program'.
I figure there's some kind of error in the layout file and the configurator hasn't been edited to show errors yet.
I've forked your github repo and uploaded my layout file here: https://github.com/saucybulgogi/keyplus/blob/dactyl-conversion/layouts/dactyl.yaml

Can you take a look at it and see if i've done anything wrong?

You're missing a comma at the end of line 79: https://github.com/saucybulgogi/keyplus/blob/cb8f5c3ff3eaf8b2122a9e4ab33cba6e2a8b18d2/layouts/dactyl.yaml#L79

I'll work on making sure the error messages get through. 

Also, on the Device id and the RF settings flasher, is the layout settings file the same file for the Layout flasher? I generated a new rf settings file and tried to flash my prototypes with it but even with one of the example layout files, it hasn't worked.

Looks like there's a bug in the generator for RF settings. For the mean time if you add these to lines to the generated file it should work:

Code: [Select]

  auto_retransmit_count: 15  # options: 0-15
  transmit_power:  0dB       # options: 0dB, -6dB, -12dB, -18dB

If you run into any more issues feel free to ask. I've been away for a bit, but I should be more active on the updates now.

[saucybulgogi]

Welp that痴 embarrassing. Been writing software for 10 years but still, silly missing commas get me lol

Thanks a lot spindle! I got the two controllers flashed with the fixed layout, rf settings files and device ids. Looks like they池e working as intended; one being the left half and the other the right half.

Next is getting them wired up to some wireless modules and batteries as well as flashing a unifying receiver with your firmware.


Sent from my iPhone using Tapatalk

[kavka1983]

Hi, this is very cool, any new update on this stuff?

[spindle]

I've been looking at different USB C connectors for the keyplus mini, because the current is a bit tricky to work with as it needs tighter tolerances on the PCB, impossible to solder without reflow soldering, and you can't visually inspect all the pins.

Here's the best alternatives I've found so far:

The first one is CX70M-24P1:
https://i.imgur.com/KB1n1Lr.jpg
https://i.imgur.com/pJ2aBXI.jpg

What I like about this one is that since the connector extends lower below the PCB, it would allow for lower profile builds when the keyplus mini is used as a submodule on another PCB.

Thes second one I found off aliexpress:
https://i.imgur.com/8ZpHt5s.jpg

It's a USB 2.0 Type-C connector, so it has fewer contacts to worry about. The only disadvantage to this type of connector is that right now it is pretty hard to find reliable sources for them (at least ones that will let you order in small quantities).

[kavka1983]

Hi spindle,

I've got wired stuff working but stucked on the wireless thing. I got a nRF24LU1+ dev board from taobao and flashed it with nrf24lu1_bootloader-f32.hex that board can be recognized by your keyplus_loader_0_0_0.exe but i was failed to upload yaml files on it even i reset the board. 

[spindle]

I've got wired stuff working but stucked on the wireless thing. I got a nRF24LU1+ dev board from taobao and flashed it with nrf24lu1_bootloader-f32.hex that board can be recognized by your keyplus_loader_0_0_0.exe but i was failed to upload yaml files on it even i reset the board. 

Sorry, right now flashing to the nRF24LU1+ won't work throught the GUI interface. I'll try get that working tomorrow. However, I'm away from my Windows machine at the moment, so I might not be able to get a Windows build setup right away. Also, since Windows treats USB drivers differently than Mac and Linux, I might need to do some more work to get it to work on Windows, but I'll try my best.

It sounds like you have a hardware programmer, since you said you flashed the 'nrf24lu1_bootloader-f32.hex'? If you do I've attached a hex that you can try to flash with a hardware programmer.

Btw, what's the marking on the chip on the dev board?  The only dev boards I've tried from ebay/aliexpress have had the 16kB flash version (labeled 'LU1P16' on the chip), but to fit all the firmware features you need the 32kB flash version (labeled '24LU1P'). If it's the 32kB flash version, I'd be interested in trying one out for myself. Since to use the other dev boards, I have to replace the QFN chip with the 32kB flash version. I can probably get a 16kB flash version to work, but I would have to disable lots of features in the firmware.

A couple of people have got the code running on unifying receivers, but you can only flash it from Linux/Mac at the moment.

Also, as a general update I got the mouse pairing working for the unifying receiver build today. You can see more on the releases page: https://github.com/ahtn/keyplus/releases
I'll try get a new xmega build out soon, but I need to fix some more bugs first.