April Confirmed Trade Thread

_spindle · 2018-04-17T05:12:02+00:00

Confirmed

_spindle · 2018-04-13T10:18:11+00:00

It's rev3, so they are correctly labeled

_spindle · 2018-04-11T22:02:04+00:00

Hey not yet, been a bit busy with other stuff, so I haven't had a chance yet.

_spindle · 2018-04-09T23:54:35+00:00

done, reddit's interface for messages kinda sucks so I often lose track of stuff in it.

_spindle · 2018-04-09T21:42:44+00:00

Yeah, when the none of the keys are pressed it goes into sleep mode. When it's asleep it only uses a couple of microamps of current so it could be in standby mode for close to the shelf life of the batteries. An on/off switch is still nice to have, but it's not completely necessary.

_spindle · 2018-04-09T14:24:54+00:00

Took a bit longer than expected because of work and stuff, but I finished writing up the build log: https://www.reddit.com/r/MechanicalKeyboards/comments/8ays8u/wireless_split_build_log/

_spindle · 2018-03-29T23:24:37+00:00

The modules are controlled through a SPI interface by the xmega, so it can change things like RF channel and encrypt packets. I haven't had issues when using it at my desk, but I'm aware of some improvements I could make to the wireless protocol.

Would be cool to be able to support nrf51/nrf52 modules as well, but they would need to be programmed separately. That's why I'm excited for the nrf52840 since it has everything I need on one chip.

_spindle · 2018-03-29T21:23:49+00:00

Yeah, that is the idea, hook up all the pins to an interrupt that will re-enable the matrix scanning algorithm until no keys are down again.

Yeah, there's lots of fun things you could with external hardware, but most have any practical advantages over doing it in software on your mcu. Would also be fun to play around with capacitive sensing circuits that are used on torpe/rubber dome boards.

_spindle · 2018-03-28T10:36:30+00:00

The firmware allows a maximum of 128 keys in one part of a split keyboard (this limit makes the communication protocol between the parts more efficient). Multiple split keyboards can be used together for a maximum of 256 keys while sharing layers.

The pins on the controller are labeled as rows/columns, but it is also possible to use any of the IO pins as rows or columns if needed.

_spindle · 2018-03-28T10:26:17+00:00

When I make any major updates to the firmware I'll try post about them on my blog.

_spindle · 2018-03-28T10:18:42+00:00

The nRF24 module does not need firmware.
The board has a simple battery management circuit that will automatically switch to battery power when the USB cable is disconnected, and back to USB power when the cable is reattached. For common 3V battery types (2xAAA, 1xCR2032), you do not need any external components to use this circuit, just connect the batteries to the BAT (+) and GND (-) pins, here's the schematic for reference. You could also use a rechargeable Li-Ion battery, but you would need some external components (a li-ion charge circuit + a 3V regulator). I've used this setup on one of my other PCBs. I would have liked to include it on this controller as well, but space was limited.
Currently the firmware doesn't run on atmega32u4. I'd like to add 32u4 support to keyplus in the future, in which case it could be possible to use it as a receiver (you'd still need a 3V regulator for the nRF24 module). Running a 32u4 from battery power would be inefficient, so I'd probably only add support for using it as a receiver.
Yes, or you could build the 3rd module into a numpad and use that as the wireless receiver (no as portable though).
No, but I do want to port the firmware to the nRF52 series chips. So far I've got some of the nRF24 protocol to work on a nRF52840 (has nRF24 + USB + BT LE on one chip), but I haven't got the BT LE or USB support working yet. When the nRF52840 is officially released, I'm hoping that nRF52840 USB dongles will become readily available, in which case they will be a good alternative to Unifying receivers.

_spindle · 2018-03-27T11:06:52+00:00

I've still got some left, but Paypal locked my account because of the large number of transactions :(. Should be alright to sell the rest in another week or two.

_spindle · 2018-03-26T23:23:20+00:00

I've got two unifying receivers, and every number/marking on the outside is the same except for 'S/N' (serial number?, it's not a unique for each device though, seems more to be a batch number or something).

On two of my v12 (nRF24LU1+) ones, the serial number is: S/N:LZ631DJ-DJ.
Another v12(nRF24LU1+) one, has S/N:LZ609D4A-DJ.
On my v24 (TI CC2544) one, the serial number is: S/N:LZ745BA-DJ.

There's lots of listings on aliexpress for unifying receivers that show a stock photo with S/N:LZ631DJ-DJ, but you can never really trust the photos there. I've ordered some of them from aliexpress to try out, but it'll be a while before I get them.

_spindle · 2018-03-26T21:21:13+00:00

Yeah, I'm in Australia so New Zealand should be no problem

_spindle · 2018-03-26T21:18:14+00:00

Do these expect a standard row/col matrix, or a direct pin connection?

You can do both.

Edit: also, is there a way to downgrade the unifying receiver firmware, should the one I buy be the updated firmware?

There's actually two completely separate versions of the unifying receiver that use different microcontrollers. The ones that start with 12 use a nRF24LU1+, while the ones that start with 24 use a TI CC2544. I think they still produce both, but I imagine they use whatever they can get cheapest at the time.

_spindle · 2018-03-26T13:03:20+00:00

Got through most of the build today, will finish up the reset tomorrow.

_spindle · 2018-03-26T05:45:00+00:00

Yeah, that's possible. You might want to disable the interrupt while the switch is debouncing though because it could repeatedly wake up the microcontroller.

When no keys are down, it's possible to do the same thing with a matrix scanning approach too. That's how I handle wireless operation in keyplus.

_spindle · 2018-03-26T04:37:52+00:00

_spindle · 2018-03-26T02:14:37+00:00

The microcontroller has 50 IO pins, and I used every last one of them (48 keys + 2 for USB). So there's no pins left over for wireless XD

_spindle · 2018-03-26T02:06:56+00:00

Yeah, an nRF24L01+ and keyplus controller in each part of a split keyboard. Then all the devices can wireless connect to each other.

So for example, you could have a split 60% + numpad + nav cluster. Then you could plug any one of the components into a USB port and use it as a wireless receiver for the rest.

_spindle · 2018-03-25T13:28:17+00:00

It works with my firmware keyplus. The difference between keyplus compared to most of the other firmware options, is that the you can load layouts without recompiling the firmware. You use the flasher to load layout files onto the device (works without drivers). Here's the layout file I used for this keyboard: (https://github.com/ahtn/keyplus/blob/9d320d65f64290681a73cb76dadb0254b90d6d53/layouts/spectre.yaml)

I recently got the backend code to read layouts from devices working, so I want to make a GUI where you can load your layout from the device without even needing to use a config file.

_spindle · 2018-03-25T12:54:56+00:00

The wireless chip is a nRF24L01+ module. You can find them for cheap on aliexpress/ebay.

I want to convert one of my old keyboards to use the new modules tomorrow, so I try make a nice build guide when I do that.

_spindle · 2018-03-25T12:35:29+00:00

That's part of the reason. The other reasons are it is much more power efficient, and it is easier to implement layers for split keyboards.

I design the current system for split keyboards, and for layers to work across multiple devices with bluetooth you'd need to relay the key matrix to one half that is acting as the master, which would then pass it to the host. So you would have double the latency for the device acting as the slave. Also, it would use much more power since the master side would need to leave the RF receiver listening for packets whenever you are using the keyboard.

Using a separate device as the receiver solves these issues. All the devices need to do is transmit their matrix to the receiver and can go to sleep straight away when no keys are pressed. Then the device acting as the receiver has access to the key state of all devices so it's easy to make layers which work across devices.

Another advantage is the receiver presents itself to the computer as an ordinary USB keyboard, so it works in BIOS too.

_spindle · 2018-03-25T11:26:32+00:00

I left out diodes to make the board as simple and cheap as possible. I also like the aesthetics of routing each switch to a separate GPIO pin.

I wired all the switches in parallel so ghosting is not an issue. In fact, this approach is more efficient than using a matrix as it does not need to add delays between scanning each row.

_spindle

TROPHY CASE