Hybris - A wireless 104 key keyboard from scratch

[RichardH]

I've been working on this for the last few weeks and I thought I'd share here as a project log. The name hybris comes from an old Amiga game I liked as a kid. I'm planning on using the 2 rectangular lights inspired by the Amiga A500 to indicate charging and pairing. I'm also adding a rotary encoder for some basic media controls to the top right of the keyboard. I'm using the new Adafruit nrf52 feather platform for Bluetooth LE, which has pretty limited IO for a keyboard this big. I've built up a little dev kit using the guts from a Velocifire TM01 and a breadboard to start porting TMK over to Arduino where the Bluefruit/Nordic toolchain is. It looks like there's been a few attempts to use TMK with Arduino - so that's promising. Software wise, I have the keyboard and matrix parts ported and am now diving into the action layer.  I'm using this project mostly for educational purposes.

Planned so far:
- Adafruit Bluefruit BLE Feather (NRF52)
- 500mAh lipoly battery
- Universal plate from MK - probably not going to go too radical on key placement
- Small IO expansion using a few 74hc165s
- A nice 24 step rotary encoder with hardware debouncing
- Updating TMK (once I understand it better) and the hardware to use a tiny power budget
- Cherry MX browns and Cherry stabilizers
- Custom aluminum case probably designed in Design Spark Mechanical
- Custom Schematic and PCB using Circuitmaker
- USB for charging/programming only
- Perhaps some lighting effects on the top/bottom when using USB





I've got a gallery started on Flickr: https://www.flickr.com/gp/chaffneue/821407

The ongoing firmware port is here: https://github.com/century-synthetics/hybris/tree/master/firmware/hybris

More to come!

-Rich

[OldIsNew]

Nice! Great work for sure!

[TalkingTree]

- Updating TMK (once I understand it better) and the hardware to use a tiny power budget

I'm following closely.

[RichardH]

Well hell yes! I've got the basic features of TMK running in Arduino's IDE and using the NRF as a host, which is a good step.



I'm getting some compiler errors with action tapping, so I'll re-enable it and tackle that next.  I'll try and clean up and port the debug code to something more usable in Arduino IDE.

This is one that has me scratching my head:

common/action_tapping.c

Code: [Select]

                        process_action(&(keyrecord_t){
                                .tap = tapping_key.tap,
                                .event.key = tapping_key.event.key,
                                .event.time = event.time,
                                .event.pressed = false
                        });

Gives me the error:

Code: [Select]

AppData\Local\Temp\arduino_build_452700\sketch\action_tapping.cpp: In function 'bool process_tapping(keyrecord_t*)':

action_tapping.cpp:160: error: expected primary-expression before ')' token

                         process_action(&(keyrecord_t){

Maybe G++ can't handle this syntax? Kind of a weird error.

-Rich

[RichardH]

Got some keycaps and put 'em on the dev board. I like the profile but I'm gonna keep looking for real GMK goodness Updated the firmware tonight to use SPI for the shift registers and fixed up a few usability things. Up super late coding.. ahh good times



-Rich

[TonyD]

Looking good 

I'm looking forward to seeing more pics as it progresses

[RichardH]

Tonight I finally got some current measurements - sitting at 12.5mA which is probably two or three orders of magnitude higher than I want. I've got a lot of work to do Surprisingly though, even when I comment out all my code from the main loop, the power consumption is still 12-13mA. So I found this issue in Github and I'll see if I can run a nightly build to try and crack this.

https://github.com/adafruit/Adafruit_nRF52_Arduino/issues/51#issuecomment-363652938

Also some sweet sprites from the game! Ohhh the possibilties



-Rich

[RichardH]

After looking over the code for a few days, I found some other people with the same general issue- the current draw is pretty damned high all the time. This particular dev board has a hardware issue. The USB to UART interface, a CP2104 is powered full time, even when using a battery power source. So I've ripped that off the board and opted for an external interface to use when I'm programming and debugging only. It looks like there's a new product coming from Adafruit that has addressed this issue, but there's no ETA yet. Hope it'll be ready for the final design!



This has brought the unmodified TMK firmware down to around 4mA. I think I'll just have a few tweaks in the software and we'll be under 500uA peak, which will be a worthy target.   

-Rich

[RichardH]

I broke out my little FTDI module to replace the in circuit usb to serial converter and it has brought down the power to just 2.3mA with some minor modifications to make the code wait for interrupts. It looks like the dev board hardware has a minimum current draw of 1mA, so I'm getting pretty close to the limit - after that I may be building the bluetooth circuit onto my PCB component by component to better select the power supply parts. The next step will be to wake on keyboard activity and that should knock another milliamp off.

 



-Rich

[RichardH]

More work on firmware today and now we're down to a total of 1.4mA, which means with the quiescent draw from the board's other components, this slightly modified TMK is only drawing 400uA insane! I'll be looking into a sleep mode next for when the user goes AFK - that should bring the current down to 1mA. With this kind of current draw, a 500 mAh battery should get 10 days between charges. I might be looking at picking a better LDO regulator with less current leakage for the final design, but this works as a dev board for now.

The modification adds a diode to each column to a sense interrupt line on the MCU. This way, TMK's keyboard_task() is only run while a key is down and unset once the keys are released (the driver sends a zeroed out packet).





-Rich
                                     

[TalkingTree]

I'm posting only to say that I'm totally supporting this idea and following it closely.
Keep up the good work.

[senso]

Almost all of the Atmega32U4 support PCINT(pin change interrupt), you config the PCINT masks to config which pins fire the PCINT interrupt vector, not sure if/how this would work nicely when the keyboard goes into sleep and there is no row/column scanning going on.

Using high value or switched pull-up resistors is also a thing, for a ultra low power project I used 300K resistors as pull-ups for local i2c switched via a MOSFET, because using 4.7K pull-ups was killing
my power budget and even when on deep sleep even the 300K lead to a much higher battery discharge, got 2 years out a CR2032 with a AtmegaRFA256 with a bunch of sensors, the only thing always up was a RTC, it had lower quiescent than using the built in RTC timer/counter.

Reading all sensor data used 1.3mA, RF comms spiked to 13mA, all turned off, around 0.003-0.007mA(flux residues caused this value to go up, scrubbed the prototype boards real good).

Read a bit about PCINT and see if it can work for you, I know that PCINT wont wake up the micro from all sleep states, but can wake it from some, maybe you already hit this nail and thats why you are using a diode-OR into one of the INT pins that can wake the micro from deep sleep states.

[RichardH]

These Bluefruit nrf52 boards are a different architecture - ARM Cortex M4 - but they do have a PCINT concept. I'm planning to run an extra diode from each column into a single pin to do the task-on-keypress and deep wake stuff.. I'm guessing during sleep it'll mean you'll need to press a key to wake it up and therefore it's going to miss the first keypress. Good call on the pullup/pulldown resistors - sounds like something I need to tune especially with so many columns. I'm not sure where exactly this 1mA quiescent load is coming from (this is while holding reset on the MCU - should be no brain activity there) - maybe a voltage divider, the LDO or other components on the board. It seems like that would be the first big thing to knock down.

In the meantime I got some other features working like the rotary encoder, the battery level report and the indicator for bluetooth connectivity.



-Rich

[pomk]

There is no need to add more diodes or lines to the mcu. In case there is no activity in the matrix, you can set all your rows high and attach active high interrupts to your columns. At the isr you just re-define the matrix pins for regular scanning and restart the matrix scanning timer. You will not miss the first keypress, as the matrix scan finds the pressed button as normal.

With pure nRf51 in minimal config I get around 200uA current when typing and as low as 15uA when only keeping the ble connection active (depending on the connection parameters forced by the host).

Btw. LEDs are your enemy, a single low power led easily multiplies your power usage by a factor of 10-50

[RichardH]

The complication is the shift registers I’m using to expand the i/o - they need to receive a clock signal to read them. That’s why I need the diodes to feed directly to the mcu - that way I can set the rows high and catch activity on the matrix without needing to latch and clock the registers. All of the leds are off during normal operation - I’ll just be using them for indicating charging and when the keyboard has disconnected from Bluetooth.

-Rich

[pomk]

Surely the raytac module supports enough IO by itself? They are about 5 USD per piece if you buy directly from raytac.

[RichardH]

Yeah this was a possible way to go if I want to drop the Adafruit board (might still do that)

-The matrix for a full size is 6x20
-I've got a rotary encoder using 2 pins
-I've got 2 LEDs
-trying to keep the i2c bus for under lighting

so that's a total of 30 pins if I don't want to use registers

Still seems kinda high - the Raytac module itself has 20 total GPIO pins so I'm not sure I'd be able to squeeze it all in. The shift registers use like 10uA when actively clocked, so it's not a big bite out of the power budget.

-Rich

[pomk]

The raytac modules (save for some small footprint ones) have the full 32 io mapped out. Two you’ll probably use for the 32k crystal, but the rest are usable. Though 10uA of excess current is pretty ok regardless.

[RichardH]

I'm almost finished with the schematics for a simple dev board to hand wire into a real keyboard. I'm using Circuit Maker, which is a hobbyist version of Altium. I'll use this schematic and its revisions to develop the full size solution later. I decided not to continue using the Adafruit Feather, but I'll keep the pinout Arduino/Adafruit compatible in case anyone wants to try this out without building a custom PCB. As I was laying things out, I quickly ran out of I/O, so I'm keeping the shift registers which consume only 3 GPIO ports for 24 total columns and a cost of about 20-40uA of current budget. I'll go through the blocks and my decision making process over the next few days. I haven't had a change to number the designators yet, so ignore the 'R?' kind of stuff. I can show how altium/circuitmaker can fix those in a later step. The source PDF document with all of the detail is on github here:

https://github.com/century-synthetics/hybris/blob/master/schematics/Hybris.PDF


But let's look at the first major block, the USB to UART interface:




I chose this configuration for a number of reasons:

• Micro USB, since that's what my shiny fabric cable uses
• FTDI Serial Comms are built into most operating systems, so you don't need more drivers like the CH340s, etc.
• Uses bus power from USB only when programming, so it's completely out of the circuit when the keyboard is working wirelessly on Bluetooth. This helps the current budget significantly.
• Allows for serial debugging in the Arduino IDE using the Adafruit bootloader, which is my target programming interface
• It uses 3.3V internally, so I don't have to level shift from 5V.
• It produces a regulated 3.3v while being bus powered, but I don't plan to use it as the charger should be capable of powering the regulator while charging.
• Added 1K resistors to RX and TX for impedance matching and current limiting
• DTR is connected to RESET on the MCU through a 0.1uF cap in series. This will allow USB to restart the MCU for serial programming

Most of the schematic layout comes from the datasheet here: http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT232R.pdf. I've marked the USB input as differential pairs to help with routing when I get to the PCB layout.

Any feedback on the design is appreciated!

-Rich

[senso]

For 3.3v operation you need to connected 3v3 OUT into VCCIO and use it as the voltage for the leds as well, also, it needs to be decoupled using 1+0.1uF caps for correct operation.

Also, ditch the FT232RL and use the FT230X, lower power usage, same pins available, the same applies regarding the 3.3v operating voltage, but its a much smaller footprint and its cheaper, usually half to less than half in 1 quantity at Mouser/Digikey.

Also the integrated 3.3v internal regulator can only supply 30mA MAX.

And I would also place both caps AFTER the ferrite bead, not one before and one after.

And I always place two 27 ohm resistors on the USB D+ and D- lines, its to limit slew rate and its recommended in either the datasheet or in some app-note from FTDI.

[RichardH]

@senso Thanks for taking the time to look over the design. I really appreciate the great advice - especially the part swap. The FT230x is missing /DTR signal used by the programmer, but the FT231x has it and is right in the same price range, so I'll go with that solution. I put the caps after the bead and added a 10nF before the bead as specified in the FTDI datasheet for the 231 - I might make the 10nF nostuff, since I don't use that cap value anywhere else on the board. The 231 also uses 47pF caps on the signal lines, which is okay since I'm already using that same value in other parts of the design. I can't believe I missed that VCCIO pin config and I also had the LEDs backward (!), so I've patched that up. The latest layout looks like this:




-Rich   

[senso]

Sorry on the part number mix-up, I never need the /DTR signal so thats why I tend to use more the FT230x :/

The 10uF is usefull when you are powering a lot of things from the USB, I think all your board will do with the 5v is to charge the battery and the USB will be more or less relegated to debugging via serial, programming(not sure on this one), and to charge the battery, so I would leave the footprint if there is space on the board(at least in rev0 for testing) and then try without populating it, if everything is OK, leave it out, the 10uF is kinda a shotgun aproach, because by definition you can't put more than 10uF of capacitance on the 5v USB bus, and to compensate crappy cables and whatnot.

I also like the 1k resistors on the RXD and TXD lines, I end up removing them, but in the initial design I always leave them because I fear of mixing up the TX and RX, and having the resistor there make crossing the two pretty easy with either 2 PTH resistors or two pieces of wire.

The reset line already has an internal pull up, but its up to you, it can be hardwired to VCCIO and its right next to the 3v3 OUT so it doesn't make layout any harder.

If you want to follow a couple more rules on the USB side, you can put a 511-USBLC6-4SC6.

Its a zener diode array made for ESD protection of the USB port, this is kinda overkill on the hobby side, its a 40 cents part, and I like to use it, there are other equivalent ones.

[meanagray]

Love it.  Following closely.

One doubt, why zener instead of standard 1N diodes ?

[senso]

Zener to clamp VBus, normal diodes for the rest, not totally normal, because they have to meet slew-rates, min and max clamping voltages, capacitance and some other parameters, its a small SOT23-6L package with 9 diodes inside, 9 1N diodes will use a lot more board area.

[meanagray]

New stuff, never considered. Thanks.

However, partly my mistake, I was asking about choice of zener in switch matrix.

[RichardH]

Sweet! So I got a few minutes to touch up 2 more things:

- I've added the TVS diode to the circuit. The one senso was suggesting was a 4 channel ic. I've opted for the 2 channel version instead - a USBLC6-2SC6.

- After reading the FTDI datasheet some more, it also looks like the rx tx led configuration is not consistent with the FT232, so I've moved them to the right IO pins. I think this should wrap up the serial programmer IC section.



-Rich

[senso]

You can config what the CBUSx pins do using the FTID FT-PROG utility:
http://www.ftdichip.com/Support/Utilities.htm#FT_PROG

Or if you dont want to mess with it, you can use the pins that are pre-assigned to the RX and TX led, but its flexible if the layout isn't favourable to using the stock pin assignments.

[RichardH]

Today, we're gonna look at a couple of components that deal with the power supply for the keyboard. I've updated the latest schematics on Github

https://github.com/century-synthetics/hybris/blob/master/pcb/development/Hybris_Dev_Board.PDF



Let's have a look at some of my reasoning behind this part of the design. Assume that the project uses a 500mAh 3.7V LiPoly Battery Pack charged off USB. The MCU working voltage is 1.7-3.3V, I want to monitor the battery periodically to update Bluetooth's battery service and there's a small likelihood of a dead short if the PCB comes in contact with the aluminum case especially during prototyping. Here's my reasoning for the design choices:

• The battery spec says to charge at 1x the capacity of the battery max (Thanks @senso!), which means you can technically charge it at 500mA
• The USB spec asks devices pull no more than 100mA max bus power for USB 2.0, so the resistor is set to allow 100mA of charge current
• The Bluetooth module is very sensitive to voltages higher than 3.3V, so it's important to regulate the voltage from the battery, which can range from 4.2V down to 2.8V
• LDO regulators can be a bit lossy, since they have ground and quiescent current leaks
• The Datasheet for the MDBT42 says not to use buck converters as it may interfere with the radio
• Therefore, I've selected a linear regulator with a very small quiescent and ground current draw
• I'd like to be able to fully power off the battery circuit and monitoring with a physical switch
• The maximum safe discharge rate for this battery is also 1 Coulomb max, therefore a 500mA PTC re-settable fuse should be a good safety measure if the board is accidentally shorted
• In order to use fancy charge indicator LED patterns like a fade-in/out, I need two signals: one with a battery level (battery voltage to an ADC pin) and one with a USB presence (VCCIO)
• To keep the voltage divider current down, I've used relatively high resistor values and a capacitor. The battery level pin is only checked periodically, so the cap should give a stable reading.

As usual, feedback on this part of the circuit is appreciated!

-Rich

[senso]

Hi, 1C means 1 time the capacity of the battery.

If the battery is a 500mAh 1C means 500mA of max charge/discharge current, if it is a 1000mAh then 1C means 1000mA/1A discharge/charge current, and not 1 Coulomb.

There are batteries that will have much higher discarge capability, like 20C, if you have a 500mAh battery rated for 20C you can safely pull 20x 500mA of current without causing cell degradation.

Given the low power nature of your system a GOOD LDO is the way to go, but bear in mind that a LiPo discharged to 2.8V is dead and should be scrapped because charging it may cause the battery to explode.

I would put the cut-off at around 3.1v and just run the whole system from a 3.0v LDO, also keep in mind that LDO's dont like ceramic caps for decoupling, either use a ceramic with a low ohm resistor to emulate a tantalum, or use a tantalum cap at the input and ouput pins of the LDO, or it can/will oscillate.

A DC/DC regulator for low power usually doesn't make sense, higher quiescent and given the low loads and very low difference in voltages the duty-cycle will be also pretty low leading to more losses.

DC/DC emit RF noise, but it can be tamed down or we wouldn't have cellphones today.

Take a look on this TI part numbers:
http://www.ti.com/product/LM2936

http://www.ti.com/product/tps780/description

Both are low quiescent LDO's that are made for battery operation, on of them is made to use ceramic caps and both have 3v versions.

And LDO's will be always lossy, they are linear regulators, so they will turn the extra energy into heat, but a buck in this situation will do the same due to such small conversion, and its a wide range(3 to 4.2v input into a fix 3v output).

For low current battery level measurement the 10M resistor might turn into a noise generator and nothing much, the usual ADC input impedance is around 10Kohms, if you want to sample from a cap, use a 100nF cap, you already have some on the board for decoupling, so its one less part to stock, but you might need to drop those resistors a lot, I had zero luck using 1M with Atmega, the ADC load causes the values to drop to near zero even with a cap.

Also, study the PTC datasheet, a PTC is a resistor, its resistor goes up as more current passes through, but it is a relatively slow method, so you battery will happily dump a couple or more Amps in case of a short, a 150-200mA PTC might be better.

[RichardH]

Again, super helpful info! Never knew that meaning of the C unit.

I think what I'll try is the LM2936 3.0 Fixed in tandem with the microchip 3.3V one I picked earlier since it can just be populated and tested with an ammeter to see which combination works best. I'm worried my diode ladder on the switch matrix is already getting dangerously close to dropping a volt, so 3.3 might be more reliable logic level, but I'd really like to test the theory.

These batteries come with an auto-cutoff safety circuit integrated into the pack. It cuts off all current at 3.3V in my tests.

According to the datasheet, the MCP1700 can run off ceramic caps on in and out as long as I have an ESR of 0-2ohms (and the TI model is similar), so I think I'm okay there. Tantalum caps kinda bug me since they're a bit outdated and extremely sensitive to voltage spikes. A failed-shorted tantalum especially on the battery side would be annoying and possibly unsafe if the PTC isn't sensitive enough. Microphonics on the ceramic cap shouldn't be much of a problem either since this thing is essentially furniture.

As for the ADC, the NRF52 datasheet says 1M impedance, which should be something I can test on my scope pretty easily since it's also a 1M impedance. I'd like to keep voltage dividers and pull downs as high value as possible. The Adafruit feather board uses a voltage divider of 806k/2M, which is probably fairly low current. I'll give it a go on the scope and share what I find. Wonder if should bump up the 100k pull down value on charge status too.

I agree on the PTC feedback, I'll probably lower it to 200mA for I-Hold just to be totally sure it doesn't trip while charging.

-Rich

[RichardH]

Here's the graph using 4M/10M and a 0.1uF cap.. 20ms looks like plenty of time to take a sample I think.



-Rich

[suicidal_orange]

I have nothing helpful to say as this is beyond my understanding but it's an interesting read so please keep us the updates

[senso]

It was just an heads up on the caps.

I dont like tantalums as well, they have higher capacity for a given size, but tantalum is a rare earth metal that is usually extracted in 3rd world countries in bad conditions, so I avoid it, just make sure you grab X7R or X5R dielectrics for the caps, NP0 is overkill for decoupling and Yanything is crappy due to the voltage/capacitance curves, avoid those.

Yes, 20ms is plenty enough to get a couple ADC readings and average them.

If the battery cuts off at 3.3v then your reg will stop working at around 3.5v on the case of the LM2936 if you choose the 3.3v model, because Vdrop is rated at 200mV at an Iout of 50mA, or it will work all they way down to 3.3v if you use the 3v model.

The MCP1700 is rated with a Vdrop  of 178mV(at a Vout>2.5V) and worst case of 350mV, so it will net you more or less the same results.

Given the diodes, going schottky is mandatory.

If I got the right part number, the nRF used is the nRF51822, the input HIGH Voltage is 0.7xVDD, with 3V that means anything over 2.1V is considered a logic high, with normal diodes, expect 0.6-0.7v Vdrop, 3-0.7 = 2.3, so there is room to be safe, with a schottky at such low currents, I would say a Vdrop of 0.2-0.3v is what you should expect, so even more room to be safe and away for noise to be able to make a false key press. There is no specified IO port capacitance/impedance/minimum current, but 100K pull-up/down will be dependant on what the charging IC can tolerate more than anything.

Just checking your math, might have failed to notice something crucial, if so, sorry.

Keep the good work.

[pomk]

I used a TPS782 with the nRF51 chip without any problems. One 1µF cap near the regulator and another next to the chip. What is the purpose of the fuse? Assuming that the regulator is right after the battery, you should be just fine using the regulator as a fuse as well. I used diodes with 0.25 Vdrop, as I had some chattering problems before when going below 2V for the switches (operating voltage below 2.5V and Vdrop of over 0.5V equals disaster with cherry style switches).

[RichardH]

I'll update the firmware to do an averaged reading - that sounds like a good plan. I guess I'll have to defer the initial battery reading for a few seconds at boot time to allow the capacitor to settle.

Man, schottky diodes are extremely expensive parts for the count I need. I hope it doesn't come to needing those. Your math looks correct to me on the voltage drops. I think I'm going to just order a 3.3 and 3.0 variant of each and see if the system is stable. It's working on the breadboard reliably at 3.3V, but I would like to extend the operating time a little by going to 3.0V.

The fuse is for circuit and battery protection. It's such a cheap part, I'm not worried about it being over-engineering using a fuse. My concerns are the capacitors failing on the battery side or shorting out the PCB or components against the chassis.

Again, thanks for all the insights, guys. I'm really happy to have another set of eyes on this. I'll move onto the logic stuff next.

-Rich

[senso]

If you are making a custom board, and you seem to be ok with SMD, or even PTH, they shouldn't be all that expensive.

BAT54GWJ, in SOD-123-2 aka 7.5 x 3.5mm total size including landing pads.

At Mouser they cost 0.12€ in singles, but at 100 they cost 0.034 € each, that gives 3.40€, low leakage current, Vforward/Vdrop of only 400mV, given a 104 key, plus spares 200 diodes will cost you 6.8€/some 8$, they cost almost twice in Digikey, but you can order from Mouser. They are from NXP, now called Nexperia, so they are good quality parts.

[RichardH]

Oh ... maybe it’s because I was only looking at 0805 and 1206 packaging. I’ll give it another look. The 0805 packaging was $0.74 @25, so that size is out.

-Rich

[senso]

Diodes usually use a bit different names for the packaging, there is a smaller package of the same BAT54, but it might be hard to solder without hot air, the BAT54LP-7B, look it up, a bit more expensive 11€ for 100.

And a pure 1206 might be the SD1206S020S1R0, but it has higher Vforward, and 100x cost 16€.

SOD-123 might be also interesting to search for, with a landing footpring ot 4mm x 1.22mm, smaller than the first one that I suggested by almost 1/4 the area.

[RichardH]

Okay.. now we've got through the power supply, let's have a look at the logic part of the board.



This schematic covers the column inputs for the switches. Some reasoning behind this choice of IO expansion.

• 74 series are extremely cheap and common
• Low quiescent current - measured at about 30uA for all three units
• Having 24 column inputs allows for expansion beyond the 104 key limit
• Using schottky diodes based on feedback from senso
• The diodes allow the system to wake on keypress (the 6 rows are set high when idle)
• 3 wire interface using SPI + latch

And this is the bluetooth module - an MDBT42Q from Raytac based on the Nordic NRF52832 (Arm Cortex M4) MCU. Here's some of the design choices I've made for this part of the circuit:

• Using the preferred layout from Raytac's datasheet, with the reset circuit from the Adafruit Feather NRF52 board http://www.raytac.com/download/MDBT42/MDBT42Q-Version%20E.PDF
• I'm planning on hand soldering this board for prototyping, so pins 41 and 40 are not connected as they are under the board.
• I need a lot of IO for this project, so I'm using an IO expander for the columns shown above
• Attempting to keep the board compatible as possible with the feather in case anyone wants to make this circuit without the custom hardware
• Using the preferred RTC crystal and caps suggested by Raytac, but I may try the circuit with these parts unpopulated to see if the internal oscillator is acceptable.
• Using the preferred internal DC-DC configuration for the radio, but I also don't know if these parts can just be omitted, since the radio is used infrequently in this circuit
• The rotary encoder is for media control (volume up/down) and the click is used to mute. the click is connected to the rest of the keyboard matrix on an unused column
• The design also has two indicator LEDs, one for charging and one for bluetooth pairing - both have some neat effects that need PWM to accomplish
• I'm using 6 rows, giving me a total IO of 144 switches. Should be good for most projects.
• This MCU will be programmed with the adafruit bootloader, so I have included a small header (off-sheet) to interface with a Segger J-Link programmer
• I've routed the i2c bus to some test points (off-sheet) for use with underlighting if needed

With the schematics wrapping up, the next thing I'll have a look at is the PCB design and layout choices

-Rich

[pomk]

Looking good! You can btw use the pins on the bottom side of the raytac module. Just put a plated through hole at that location and just solder through to the pad. Needs a bit of flux and preferrable paste form solder.

[senso]

No decoupling caps, school of leaving them all together on another sheet?

Just to be sure, for your wake_sense to work, you keep all the rows at logic high?

That will lead to an higher sleep current, because to keep the IO's powered you can't go into deep sleep.

I would add pull-ups to the i2c lines, never trust the built in pull-ups, you can leave them unpopulated, and try with and without, but if they are needed and you dont have the landing pads then it takes a bit more effort to put them in.

[pomk]

Decoupling caps are already present in the raytac nRF52 module.

[phorx]

Whoa, this is next-level.  Nice!

[senso]

Its missing caps on the 74HC chips, on the battery charger IC, and on modules like the Raytac, I like to place 1uF near each power pin, solved edge cases that way, start-up+transmit current in short time(muc doing sensor data acquisition then blasting if via RF would cause the local ground to bounce and provoke hard to trace brownouts), and 74HC logic is done on older nodes, so they can make some nice dips when you blast them with data.

[RichardH]

Yup power filtering and segger stuff is off sheet. I have a 1uF on the vcc and 0.1uf on each of the 74 ics. I’m going to need a lot of vias on the power pins I think. I think there might already be internal pull-ups on the i2c bus, but I’ll sanity check that. Good idea on the row control being pulled up.. gonna have to tweak the voltage divider a bit to make the 74s work off pull up and source/sink.

-Rich

[RichardH]

Hooray! Parts have arrived! I've made a few custom footprints and I've gone through and sized them up with the physical components. This is an old habit: Never ever trust footprints from anyone including yourself. With that in mind, I've placed all the ICs on paper and made sure pad 1 lined up.



I haven't routed anything yet, so let's talk about some basic order of component placement and routing. Here's my thinking so far:

• Place all the MX switches
• Place the rotary encoder
• Place the indicator LEDS
• Place the USB port
• Place all the USB related components relatively close to the port
• Place the MCU and support components - probably close to the rear edge of the board so we can keep out the ground plane easily
• Place the MX switch diodes
• Place the matrix column io expander circuit and try to keep the clock signals similar lengths
• Place the battery connector
• Place the power supply and charging components
• Route all signal lines
• Route the positive power lines
• Polygon fill ground

Sound like a good course of action?

-Rich

[RichardH]

Working on the PCB layout and it's coming along nicely. I've placed the switches and screw holes. I found 3D models for pretty much everything except the space bar stabilizer wire. I still need to center it and figure out the designators and I'll do a paper layout test. The physical plate looks like it has a slightly different spacing than 19.05mm center to center which makes me a bit nervous, so I'm going to have to move stuff around by hand. So far I've been using a 3d model from swill's layout editor, but I'll have to go over it once I see the paper copy. I placed mostly 3mm screws to match the plate's holes and 2mm next to the spacebar.



-Rich

[TalkingTree]

The physical plate looks like it has a slightly different spacing than 19.05mm center to center

Most keycaps have 18mm as base unit so you shouldn't be worried about spacing. Also, some people use a 19mm spacing between cutouts because it's cheaper to produce (so they say). Keep in mind that there's some tollerance in the datasheets.

[senso]

Looking good, cant help you on the spacing doubts, have them as well, should read a lot more, because I also want to start laying out my pcb, gonna wait till you confirm everything, and then if you dont mind, post the spacing that you use between switch centers.

[RichardH]

This part of the job is a lot more painstaking than I imagined. I started at 19.05mm and measured it against my plate. The result was a gradual misalignment of the switches. I went down to 19.00mm and found that the measurements were more consistent. Here's the misaligned version:



Another fun thing about this plate is that the gap of the F key row and the arrow keys is a little different than the version that comes out of the swillkb tool. So that just leaves more measurements. I guess the moral of the story is order the plate first and then build the PCB to match. In my case I'm using a universal plate from the mechanical keyboards shop. https://mechanicalkeyboards.com/shop/index.php?l=product_detail&p=2554 - would have been really nice to have the cad files for this!



Getting closer to a match. A little more work and I'll have enough to begin placing the other components.

Also lovin' the PCB mount footprints and models. Looks like they'll fit great!



-Rich

[pomk]

Just be sure to check that your printer is accurate as well. I usually add a 50% opaque ruler in such printouts to rule out scaling issues.

[senso]

How the keyboard going?

Everything OK with you Richard?

[RichardH]

Just a quick update! I've been working on techno recently, so the keyboard design took the back seat last month. I got back into it the last few days and placed the diodes and encoder. Next step will be to place the logic components and power supply. I'll try and describe the hows and whys on that next. I went through and measured everything twice and it looks like everything should fit the first time. I placed the diodes so there was a good bit of space around the drill holes. Other than that, it's boring, methodical work.





-Rich

[RichardH]

Big progress! I finally got some time to finish routing and I've sent the board off to the fab! 

I'll go through some of my routing decisions.

The component side of the board (numpad on the left) board was split up like this:



USB signals were routed first since they're really the only high speed thing on the board. I followed the chip vendor's PCB prints here https://www.ftdichip.com/Support/Documents/PCBData/NerO%20PCB%20Prints.PDF and tried to length match the differential pairs  to 5mil. This will definitely be an annoying area to hand solder due to the density of the parts. I chose fairly big footprints for the passives at 0805 packages, so I'm confident it'll come together.




Next came the Bluetooth MCU. The Bluetooth module was placed right on the edge of the board above the numpad. I kept the crystal close to the module, and as far as I could get it from the other signals. The space was pretty constrained, so I ended up killing a bunch of test points in order to make all the parts fit and still leave a ground keepout zone under the antenna. The rotary encoder is mounted just to the right and the signal lines are pretty short. Since the serial lines are really slow, I routed then wherever they fit later in the layout process



The column layout and diodes were next. I picked a spot and roughly placing the diodes in the same place for most of the 1u switches and did the 1.25/2u ones a little more custom. I'm a little disappointed in the shape of the traces, but this was a good learning experience for what to do better in Rev 2.   



I placed the shift registers next. The data direction ended up being opposite to the breaboard mockup, which ended up making the connection go from the MCU to the register nearest the spacebar. Instead, the data line now goes from the MCU to the register nearest the numpad and daisy chains to the arrow keys then to the spacebar area. I also tried to make the traces not go directly under the stabs, just in case of wear. Any traces routed through the stabs were pulled as close to the mounting holes as possible.



Lastly was the power supply. I was running a little short on space with all of the signal traces, so I picked a convenient spot under the F12 key. Since this will be the highest point of incline, it will let the main board to lay just above the battery inside the case. I'm going to design for a 2000mAh battery, so 60mm x 36mm x 7mm will be the allowance. I've used some fairly beefy traces on the VCC rails just because they have so damn long to go.

I added some more mounting holes to the board after routing all the signals and pulled back the ground plane from all of the holes. That concludes the PCB layout! I'm expecting the boards to arrive as early as tomorrow!

-Rich

[marhalloweenvt]

I just want to say that Your work is very amazing.
Would you allow me to use your design for my design?
Thanks

[RichardH]

@marhalloweenvt by all means. It's open source hardware. Hack away

The PCBs come tomorrow, so I should have some assembly stuff to show off.

-Rich

[marhalloweenvt]

Can't wait for coming home to do some prototype with your design. I have some nrf52823 modules lying around.

[RichardH]

Happy new year everyone. It's been almost a year since the project started and I'm now at a fully built PCB!

Rev.1 of the PCB had a number of problems:

• The Switch spacing ended up being 19.05mm, the printer was scaling as suggested by a previous poster - moral: never trust printers
• The USB protection diode had too much skew and ended up fouling the signal- I've dropped it for now
• Pull up and down resistors were not needed on the Jlink connector

So I've spun a Rev.2 and now the switches fit the plate and the minor signal issues were resolved

Here's some photos from the build - it was hand soldered minutes before these photos were taken, so it's a bit blobby and flux-y:


USB Section





BT module





Battery Section




The bottom side of the board




Thanks for all the help and feedback, guys! I'll follow up with a post on the progress of the case and hopefully get to building the plate and switches soon.

-Rich

[marhalloweenvt]

You're rock.
Do you think about add some underglow RGB led? That should be nice future

[iaman]

This rules, Rich! Glad to see folks doing work on full-size PCBs, finally.

[vvp]

Do you think about add some underglow RGB led?

LEDs would have quite a bad impact on the battery life when switched on.

[RichardH]

Hey again! So today I want to share my case design so far (been working on it during the holidays). First I'll follow up on the LED qustion above. I left the two wire interface open with solder pads on the mcu in case I decide to do that It would need a much bigger battery or to only run lights while on USB. I'm designing the case to support up to a 2000mAh battery, which would run bright lighting for about a day (@ 70mA or so). I guess the other issue is I wanted the base to be black.

So here we go:



My design goals here:

• A metal case top, likely natural color anodized aluminum
• A metal knob for media controls
• A vinyl or silk screened decal in the top right corner
• A plastic base - probably 3d printed to allow a large bluetooth aperture
• A switch on the bottom to physically turn off the board when not in use
• Room for a fairly large capacity battery just in case

I've done laser sintered nylon (SLS) through shapeways before and I liked how it came out. I'm not sure if that's the latest tech these days. The aluminum upper housing might be very expensive as designed due to the cavities on the bottom (the  plate is one level and the top right is another) and I want to cut the back of it up a bit to cause as little signal loss as possible. I'm not sure which bumpons to use, are they normally recessed? I'd love some manufacturing tips if anyone's done this before.

-Rich

[hottrout]

I love what you are doing here and am following very closely.  Can I just say as a man the same age, I loved Hybris on my Amiga, it is one of my all time fav games from one of my all time fav systems.

Do you still game?
Do you collect Amigas/Computers?

[RichardH]

Heh.. I still play most of my favourites on uae - it’s close enough when using a game pad. My friend has my A1200, so I know where to find it waiting to see more about these vampire boards, too. There might be a little retro computing in my future if those turn out as advertised.

-Rich

[RichardH]

So it's time to build! All the internal parts have arrived and I now have enough to build the plate and switches.

The mechkb universal plate I'm using just needs the top tab sawed off to fit the encoder and status leds.



This plate also uses plate mount stabs, so I did a little test fit and installed all the stabilizers. I put a bunch of lube on the ends of the wires and the sides of the housings.



I originally started the project thinking I would use MX browns, but through a twist of fate I ended up with some bags of zilents so 62g zilents for the alphas and 65g for mods/numpad/f row/space



Lubed the side rails, the lower spring mount and a touch on the lower "pin" of the switch




After putting in the anchor switches, I populated the rest of them



Keys, encoder and aluminum knob and battery all installed. using a little cloth to keep the battery connector from hitting the table.



I'm now typing this message from my new board using Bluetooth So happy with how it turned out - Zilents are a dream! Plastics will come probably next month so I'll have a full prototype. If the plastic version looks good, it'll be onto the metal case top.

-Rich


 

[iaman]

Rich, that looks great! So excited to see this project get here!

[AGmurdercore]

I was searching around to gather ideas on a wireless build and I stumbled upon this thread. Any update on this, how are you liking it after some time now?

[RichardH]

Woops missed this It's my primary board now and it's been a workhorse. The nrf52832 version of this board is now obsolete, so I think if I were to go back to this project, I'd look at integrating the Nrf52840 version instead. Adafruit has already made an SDK avaiable. I have issues with the 840 though because the module is no longer hand solderable. It does use a lot less power and no longer needs the UART. About 2 years later I still get a week of battery life on a 500mAh battery. I was hyped about building a case for it, but the price is just too much, so I just use it as a bare board still.

-Rich